vxlan auto pull vlans and vrfs #405
Conversation
* Sessions are established between adjacent nodes whenever their real or local AS numbers are different * The remote AS number (real or local) and the local AS are stored in the neighbor data structure * Session type is set to 'localas_ibgp' when creating an IBGP session that results from having the local AS equal to the AS of the remote node. * local-as and in-VRF local-as are device features and are checked against defaults.device.features. Viability of IBGP local-as is not checked yet.
…BGP module documentation
…ab up' or 'netlab initial' Also, accept 'args.Namespace' or 'Box' whenever dealing with CLI arguments -- sometimes we have to pass fake parsed arguments to common routines, and it's easier to pass an empty Box
…pspace#372) Co-authored-by: Jeroen van Bemmel <[email protected]>
Co-authored-by: Pierre <[email protected]>
* Add device feature checks * Deal with all possible combinations of unnumbered/ipv4/ipv6 attributes * Set separate neighbor flags for IPv6 LLA session and RFC 8950-type AF * Update user and contributor documentation
Co-authored-by: Jeroen van Bemmel <[email protected]>
…dress to loopback.ipv4
Co-authored-by: Jeroen van Bemmel <[email protected]>
Co-authored-by: Jeroen van Bemmel <[email protected]>
…es (ipspace#394) Co-authored-by: Jeroen van Bemmel <[email protected]>
Co-authored-by: Jeroen van Bemmel <[email protected]>
…ault (ipspace#397) Co-authored-by: Jeroen van Bemmel <[email protected]>
Co-authored-by: Jeroen van Bemmel <[email protected]>
…ethod in the codebase) to automatically pull in any vlans or vrfs used in vxlan.vlans This allows a user to simply declare a top-level vxlan.vlans: [ red, blue ] statement, without also having to declare referenced vlans and vrfs on those nodes. This is particularly useful in overlay scenarios, where the VRFs only exist on the nodes without physical interfaces attached
There was a problem hiding this comment.
Nope.
- VXLAN module requires VLAN module, so there's no way VLAN module would NOT be applied. The reason for that particular error message is that you can disable VNI auto-generation, but still list a VLAN in the node.vxlan.vlans list.
- There is no need to pull global VLANs and VRFs into a node. Creating VLANs and VRFs should be based on actual needs, which are interface-driven.
I don't think we need this PR at all.
|
I still believe there are uses for being able to say that you want to create certain VRFs and VLANs on a bunch of nodes, without having interfaces attached. Those interfaces may come later, when servers are connected or VMs are spun up. This effect can be achieved with loopbacks or stub interfaces, but then you have to create/define those everywhere. OK to close this for now |
If someone wants to use netlab in that way (not that it was ever intended to be used like that), then I can add deploy_to attribute to VLANs and VRFs. However, I would love to see someone coming along and saying "I'd love to do this particular thingy" first, otherwise we'll get into an ever-expanding forest of cool-to-have-but-never-used nerd knobs. |
This adds a 'node_pre_default' hook in the vxlan module (first such method in the codebase) to automatically pull in any vlans or vrfs used in vxlan.vlans
This allows a user to simply declare a top-level vxlan.vlans: [ red, blue ] statement, without also having to declare referenced vlans and vrfs on those nodes.
This is particularly useful in overlay scenarios, where the VRFs only exist on the nodes without physical interfaces attached