Guest

Preview Tool

Cisco Bug: CSCvs18150 - Default transit route tag for tn-common VRF gets deleted

Last Modified

Jul 22, 2020

Products (24)

  • Cisco Nexus 9000 Series Switches
  • Cisco Nexus 9516 Switch
  • Cisco Nexus 9396TX Switch
  • Cisco Nexus 9396PX Switch
  • Cisco Nexus 93108TC-FX Switch
  • Cisco Nexus 93120TX Switch
  • Cisco Nexus 93240YC-FX2 Switch
  • Cisco Nexus 9504 Switch
  • Cisco Nexus 9372TX-E Switch
  • Cisco Nexus 93108TC-EX 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 Cisco ACI with this tag are denied from being installed in the routing table, if the VRF table that has the route-tag policy is providing transit for another VRF table in Cisco ACI (for instance and inside and outside vrf with a fw connecting them) and the non-transit VRF table has the default route-tag policy, routes from the non-transit VRF table would not be installed in the transit VRF table.

This bug is also particularly impactful in scenarios where transit routing is being used and OSPF or EIGRP is used on a vPC border leaf switch pair. vPC border leaf switches 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, member 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. 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 table 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 switch 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 table 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.