Guest

Preview Tool

Cisco Bug: CSCvs18150 - default transit route tag for tn-common vrf deleted

Last Modified

Dec 18, 2019

Products (13)

  • Cisco Nexus 9000 Series Switches
  • Cisco Nexus 9516 Switch
  • Cisco Nexus 9396PX Switch
  • Cisco Nexus 9396TX Switch
  • Cisco Nexus 93120TX Switch
  • Cisco Nexus 9504 Switch
  • Cisco Nexus 9508 Switch
  • Cisco Nexus 9332PQ Switch
  • Cisco Nexus 93128TX Switch
  • Cisco Nexus 9372PX-E Switch
View all products in Bug Search Tool Login Required

Known Affected Releases

12.2(1o) 14.2(2g)

Description (partial)

Symptom:
After a certain set of steps it is observed that the deny-external-tag route-map used for transit routing loop prevention gets set back to the default tag 4294967295. Since routes arriving in aci with this tag are denied from being installed in the routing table, if the vrf that has the route-tag policy is providing transit for another vrf in aci (for instance and inside and outside vrf with a fw connecting them) and the non-transit vrf has the default route-tag policy, routes from the non-transit vrf would not be installed in the transit vrf.

This bug is also particularly impactful in scenarios where transit routing is being used and ospf or eigrp is used on a vpc BL pair. VPC bl's peer with each other, so if member A gets a transit route from bgp, redistributes into ospf, and then advertises to member B (since they are peers)...without a loop prevention mechanism mem B would install the route through ospf since it has a better admin distance and would then advertise back into BGP. This vrf tag is set on redistribution of BGP > OSPF and then as a table map in ospf that blocks routes with the tag from getting installed in the routing table. When hitting this bug the route-map used for redistributing into OSPF still sets the tag to the correct value, however the table map no longer matches the correct tag. Rather it matches the default tag. So as a result, member A (could be B) would install the route through OSPF pointing to B. It would then redistribute it back into BGP with the med set to 1. The rest of the fabric (including member B) would install the BGP route pointing to member A since its med is better than the original route's med.

Conditions:
1. Configure a non default route-tag policy in the common tenant. Associate to a vrf in the common tenant
2. Deploy an l3out in the common tenant.

At this point you should see the correct tag set in the default deny route-map on the leaf where the l3out is deployed:

leaf# moquery -c rtmapMatchRtTag -f 'rtmap.MatchRtTag.dn*"3014698-deny-external"'
Total Objects shown: 1

***non-default tag sets to 10 , 3014698 is vnid for common tenant vrf
# rtmap.MatchRtTag
tag          : 10
childAction  :
descr        :
dn           : sys/rpm/rtmap-exp-ctx-3014698-deny-external-tag/ent-1/mrttag-10

3. Configure another l3out that is not in the common tenant but does leverage the vrf that is the common tenant.

At this point you should see the default export route tag policy get set back to the default value.

leaf# moquery -c rtmapMatchRtTag -f 'rtmap.MatchRtTag.dn*"3014698-deny-external"'
Total Objects shown: 1

# rtmap.MatchRtTag
tag          : 4294967295
childAction  :
descr        :
dn           : sys/rpm/rtmap-exp-ctx-3014698-deny-external-tag/ent-1/mrttag-4294967295
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.