search

ipspace / netlab

Making virtual networking labs suck less
https://netlab.tools
Other
456 stars 69 forks source link

VLAN and VRF groups #1529

Closed ipspace closed 1 week ago

ipspace commented 1 week ago

This PR generalizes "node groups" into "object groups" and adds VLAN and VRF groups. The new group types are identified with the type attribute, whereas a group with no type attribute is assumed to be a node group.

ipspace commented 1 week ago

Need to clarify and test the semantics of instance attribute override: If a vlan has ospf.cost=X and gets put in a group with ospf.cost=Y, what happens?

This is no different than any other group, explained in https://github.com/ipspace/netlab/pull/1529/files#diff-ce3fd91438d1613c389915da67500215790d50ca4629d051ed66bc2bb87d3fbfR81

I do agree it would be nice to test multiple members and attribute inheritance though. Will add.

DanPartelly commented 1 week ago

Could this mechanism be extended with plugins to classify links as underlay/overlay so for example you could generate for a dmvpn all required tunnels and nhrp maps ?

jbemmel commented 1 week ago

Could this mechanism be extended with plugins to classify links as underlay/overlay so for example you could generate for a dmvpn all required tunnels and nhrp maps ?

We have role as implied link groups (e.g. used for consistent addressing), but I agree explicit link type groups could make sense

ipspace commented 1 week ago

We have role as implied link groups (e.g. used for consistent addressing)

That's exactly what I wanted to suggest to identify (for example) underlay links.

but I agree explicit link type groups could make sense

We had them for quite a while: https://netlab.tools/links/#link-groups

Will add a pointer to them into the groups.md documentation