Pull in vrfs associated with vlans #482
Conversation
…dency on the order of vlans in the topology
|
As you can see in the commit history, at first I did not sort the vrfs. This lead to failed test cases, because pulling in the vrfs associated with vlans changed the order in which they got added to the nodes in some cases. I didn't like that, the way vlans are associated with nodes and the order in which they are listed should not impact the vrfidx assignment imho. Those are the kinds of small irregularities that can cause operational issues. For SR OS and SR Linux I can remove those dependencies on vrfidx altogether and use globally unique My use case is here, I'm using a custom script to generate BGP policies and need to reference all the ipv4 prefixes associated with all vlans - not just the ones on the local node. I also need the export community from each customer vrf. I could instead reference each vrf and vlan on each leaf explicitly, instead of relying on the grouping mechanism or the pulling in of the customer vrf through the vlan - but that could lead to inconsistencies. I want to define things once, and derive the corresponding configs automatically |
That's an interesting one -- it would be nice to understand which part of Python3 is not deterministic. I also wonder why we never hit it so far.
And why does that matter?
What operational issues exactly? We're talking about a lab-building tool. But OK, let's say I'm persuaded that consistency is good, so let's sort VRFs by ID.
Plugin.
Ah, now I understand why you try to pull VLAN and VRF data into nodes that don't need them. What you're trying to do is outside of the scope of netlab VLAN and VRF configuration modules, but could be easily solved with a plugin. |
Some module (like EVPN) modify global VRF data and expect the modified global VRF data to be used for node VRF data. Code introduced in #482 pulls global VRF data into node VRF data very early in the transformation process -- in those cases, the global changes are never copied into the node VRF data. This PR fixes the #482 logic to create stub node VRF structures, and carefully populates them with auto-generated or global ID/RD/RT values. The full global VRF data is then merged with node VRF data in post_link_transform hook. Modules that want to use merged (global + node) VRF data are OK to use node VRF data in post_transform hook, otherwise they should use `vrf.get_node_vrf_data` function to get the merged data. Modules that want to modify VRF data have to do so before the post_link_transform hook.
As illustrated here there are cases where vlans get pulled into a node without being referenced from an interface.
Currently, any vrf associated with such a vlan does not get pulled in - while I believe it should
This may be another case of some underlying issue that is better fixed elsewhere - just submitting the case and a straightforward fix to start with
This PR also ensures there is a deterministic order in which local vrfidx values get assigned, by sorting the vrfs on their global id. This avoids a dependency on the order in which vlans (with associated vrfs) appear in the file