Having some oddness in a lab and can't seem to figure out this behavior. Please see the attached diagram: https://ibb.co/S0VpXZ0
-------------
1). Both sets of "CORE" switches are Nexus vPC pairs acting as a collapsed core
2). "VPN Pri" and "VPN Sec" are just vendor-managed VPN devices
\- these must be "active/passive" \- We can only static route to them
3). Static routes are pointed from each vPC set to their respective VPN device
\- Site B has a route preference of 250 added to the static route so it prefers Site A's redistributed eigrp route until it disappears from the table, then it uses the floater. \* (ip route x.x.x.x/24 x.x.x.x track 20 name VPN 250) \- Site A has a default preference of 1 \* (ip route x.x.x.x/24 x.x.x.x track 20 name VPN)
Site B# show ip route 192.168.1.0/24 192.168.1.0/24, ubest/mbest: 1/0 (Site A route)*via 10.0.0.1, Vlan10, [170/51968], 00:43:11, eigrp-100, external (Local floater)via 172.16.0.1, [250/0], 00:39:44, static
This works beautifully. When Site A's track goes down, this is what happens at Site B:
Site B# show ip route 192.168.1.0/24 192.168.1.0/24, ubest/mbest: 1/0 (Site A route is deleted from RIB) via 172.16.0.1, [250/0], 00:39:44, static
However, when Site A's track comes back up and redistributes... I never see it get relearned by Site B again, and Site B continues to use it's own local static (and consequently, it redistributes it to the WAN). I would EXPECT that Site B would just re-learn the Site A route again via EIGRP, but it doesn't until I force the track to go down at Site B (which removes the floater). At this point it re-learns the EIGRP route and then when I bring the track back online, the floater gets put back in as a backup path.
In my mind, the floater shouldn't have to be removed/re-added just so Site B learns the dynamic route again from EIGRP. I'm thinking it could be a GNS3 bug but I'm curious if anyone knows whether or not this is indeed expected behavior? using N9Kv 9.3(1)
No comments:
Post a Comment