Fix: Activate VRF IGP interface only when there are viable neighbors#2524
Fix: Activate VRF IGP interface only when there are viable neighbors#2524
Conversation
The original VRF IGP code checked whether the IGP should be active in the VRF based on whether adjacent nodes were running the same IGP, but not whether they could form an IGP adjacency with the node. This fix is not perfect, but better than the original -- when checking whether a neighbor is a viable IGP neighbor, it checks not just the IGP module (for example, are both running OSPF), but also whether the two devices have any AF in common on the shared link. That results in IGP not being run between a router connected to a switch with L2-only VLAN (but might still result in IGP being active if the switch has an IP address but does not run IGP in that VRF). The relevant transformation test was modified to: * Run OSPF in the underlay * Put VLANs into a VRF on the router-on-a-stick (to trigger the VRF interface migration code) * Have a single OSPF router in the overlay (the original test had two routers, so we'd always get OSPF adjacencies). Fixes #2275 (mostly, without going into too many edge cases)
| node.vrfs[l.vrf][proto].active = True | ||
| for af in ['ipv4','ipv6']: # ... and has at least one AF in common | ||
| if af in l and af in neighbor: # ... with our interface | ||
| node.vrfs[l.vrf][proto].active = True # Found one? Let's keep the routing protocol active |
There was a problem hiding this comment.
Should we track this by address family? OSPFv2 and OSPFv3 are not the same thing...
There was a problem hiding this comment.
Can break the outer for loop once the flag has been set
There was a problem hiding this comment.
Should we track this by address family? OSPFv2 and OSPFv3 are not the same thing...
The address families are tracked elsewhere (based on what is configured on global/VRF interfaces). Here, we're just checking whether there's an AF match between current device and its neighbors.
However, the "for" loop could be rewritten as "for af in ...[proto].af" if the af dictionary is already set at that moment. Thanks for the suggestion: have to check...
There was a problem hiding this comment.
Update: the VRF proto.af data is not set, so it cannot be used here. We might fix this bit if we ever implement #2398.
2 participants
The original VRF IGP code checked whether the IGP should be active in the VRF based on whether adjacent nodes were running the same IGP, but not whether they could form an IGP adjacency with the node.
This fix is not perfect, but better than the original -- when checking whether a neighbor is a viable IGP neighbor, it checks not just the IGP module (for example, are both running OSPF), but also whether the two devices have any AF in common on the shared link. That results in IGP not being run between a router connected to a switch with L2-only VLAN (but might still result in IGP being active if the switch has an IP address but does not run IGP in that VRF).
The relevant transformation test was modified to:
Fixes #2275 (mostly, without going into too many edge cases)