Symptom

For intersite l3out the spines at the local site have outbound route-maps pointing to the VPNv4 neighbors (spines at the remote site). This route-map is called "infra-intersite-l3out". The entries in this route-map match the pteps of each fabric leaf and sets the next-hop to an IP from the routable pool of that pod. When this bug is seen the spines will not have a route-map entry for the BL that is originating routes. For instances, in the below output leaf 205 (node id 205) is missing: show route-map infra-intersite-l3out route-map infra-intersite-l3out, permit, sequence 1 Match clauses: ip next-hop prefix-lists: IPv4-Node-entry-204 ipv6 next-hop prefix-lists: IPv6-Node-entry-204 Set clauses: ip next-hop 172.16.22.229/32 route-map infra-intersite-l3out, permit, sequence 3 Match clauses: ip next-hop prefix-lists: IPv4-Node-entry-206 ipv6 next-hop prefix-lists: IPv6-Node-entry-206 Set clauses: ip next-hop 172.16.22.227/32 This results in routes not being advertised across sites.

Conditions

This bug is seen when an intersite l3out is configured while the configured border leaf is not active in the fabric from the perspective of the spines. When the border leaf goes active and receives a ptep the spine route-map is not updated. An easy way to reproduce this is to configure an intersite l3out, decom (remove from controller) the border leaf on which the l3out is deployed, and then rediscover it into the fabric. The route-map entry on the spines doesn't get recreated.

Workaround

Through MSO... 1 Under infra configuration remove the "Routable TEP Pool(s)" from the site(s) that are missing the route-maps. 2. Deploy the configuration. 3. Add the Routable TEP Pools back 4. Deploy the configuration Route-maps should now be created

Further Problem Description