Defining group level VLAN with prefix

[jbemmel]

I would like to configure the default VLAN 1 with a different prefix for different groups:

groups:
  _auto_create: True
  members: [ r1, r2 ]
  vlans:
    v1:
      id: 1
      prefix: 10.0.0.0/24

Unfortunately, this doesn't work:

netlab/netsim/modules/vlan.py

Line 1274 in b76b2bd

groups.export_group_node_data(topology,'vlans','vlan',copy_keys=['id','vni'])

copies group VLANs into the global topology. The prefix isn't copied, but it's still not allowed to set a prefix for "global" vlan v1

As a workaround, one can define the VLAN at each node instead - but I'm wondering if it wouldn't be better to change the logic in export_group_node_data to not create a global vlan if one doesn't exist already

[ipspace]

I'm pretty sure we had another version of this same discussion in which you argued the group VLANs have to be copied into global VLANs so you can define VLANs in groups for whatever EVPN scenario. I remember having to reorganize quite a bit of stuff to make that work.

On a more constructive note: could you set the VLAN ID in global vlans.v1 and the desired prefix in groups.g1.vlans.v1 for group g1?

[jbemmel]

There have been different use cases related to VLANs in the past, yes.

In this case, it doesn't make a difference if I set the VLAN ID in global vlans.v1.
Defining prefix at the group level isn't allowed

This change fixes it:

def export_group_node_data(
      topology: Box,
      key: str,
      module: str,
      copy_keys: typing.List[str] = [],
      unique_keys: typing.List[str] = []) -> None:

  if not unique_keys:
    unique_keys = copy_keys
  for gname,gdata in topology.groups.items():
    if gname.startswith('_'):                                         # Skip groups starting with '_'
      continue                                                        # ... those are group settings
    #
    # Find groups with node_data dictionaries
    # and check that the key within node_data dictionary we're interested in is also a dictionary
    #
    if must_be_dict(gdata,f'node_data.{key}',f'groups.{gname}',module=module,create_empty=False):
      for obj_name in list(gdata.node_data[key].keys()):              # Iterate over VLANs/VRFs within the group
        if gdata.node_data[key][obj_name] is None:                    # ... replace None values with
          gdata.node_data[key][obj_name] = {}                         # ... empty dictionaries
        if not obj_name in topology[key]:
          continue                                                    # Skip over items that do not exist globally
        elif topology[key][obj_name] is None:
          topology[key][obj_name] = {}                                # Make sure global object is also a dictionary

        obj_data =  gdata.node_data[key][obj_name]                    # Now get the data to work with
        for attr in unique_keys:                                      # Check whether we have an overlap in unique keys
          if attr in topology[key][obj_name] and attr in obj_data and \
             topology[key][obj_name][attr] != obj_data[attr]:         # Unique key present on both ends and not equal
            log.error(
              f'Cannot redefine {key} attribute {attr} for {key}.{obj_name} from node_data in group {gname}',
              log.IncorrectValue,
              module)
        for attr in copy_keys:                                        # Finally, copy missing values from group to global object
          if attr in obj_data and attr not in topology[key][obj_name]:
            topology[key][obj_name][attr] = obj_data[attr]

i.e only export and make consistent if it already exists globally.
This would affect both vlans and vrfs

I'm not trying to "argue", I am trying to discuss whether it makes sense to change this behavior

[ipspace]

I'm not trying to "argue", I am trying to discuss whether it makes sense to change this behavior

No ;)

[ipspace]

There have been different use cases related to VLANs in the past, yes.
In this case, it doesn't make a difference if I set the VLAN ID in global vlans.v1. Defining prefix at the group level isn't allowed

Also known as "I want to have seven red lines, all of them perpendicular to each other, and two of them in green" You can't have it both ways.

[jbemmel]

Fine, in that case I'd argue that

netlab/netsim/modules/vlan.py

Line 1274 in 9816fd9

groups.export_group_node_data(topology,'vlans','vlan',copy_keys=['id','vni'])

should include 'prefix' as a key to be copied globally

[ipspace]

Fine, in that case I'd argue that

@Astrotokii found a solution that solves your problem. You can stop arguing. Thank you.

[Astrotokii]

I was able to group members into vlans by grouping through link groups.

vlans:
V1:
id: 1
prefix: 10.0.0.0/24
mode: irb

V2:
id: 1
prefix: 10.1.1.0/24
mode: irb

!
links:

• group: vlan_v1
  members: [ r1-h1 ]
  vlan.access: V1
• group: vlan_v2
  members: [ r2-h2 ]
  vlan.access: V2
  !

Doesnt this accomplish the same goal? It works as of right now, and it applies the different prefixes; so stuff wouldn't have to be moved around.

[ipspace]

@Astrotokii -- thanks a million. In a nutshell, the trick is to use different VLAN names but the same VLAN ID.

[jbemmel]

In other words, an exception to the rule: https://github.com/ipspace/netlab/blob/dev/docs/module/vlan.md#vlan-connectivity-model

The VLAN configuration module assumes you're creating a sane design in which:

* VLAN numbers are globally unique (you're not reusing 802.1q values)

[Astrotokii]

Technically, shouldn't the rule be that the VLAN numbers are unique at the organization level, with proper separation at the WAN level. So long as the VLANs don't overlap on the WAN edge routers, wouldn't it avoid conflict?

[jbemmel]

Technically you could configure this and it will work, but some (most?) network engineers would expect VLAN 10 to be connected in this case. Hence Netlab "strongly encourages" globally unique VLAN IDs.

I didn't realize that wasn't being enforced

[Astrotokii]

For consistency and sanity it makes sense to infer vlan 10s are the same. However, since vlans are L2 concepts, wouldn't the relative vlan numbers be irrelevant to the routers between vlans so long as they dont overlap with the neighbor (as long as the addresses are also globally unique). The routers would likely use some form of routing protocol, allowing the hosts to talk between the "vlan 10s" as long as the relative addresses are globally unique.

The only time I can see a conflict is in the picture you presented. If the routers are using routed interfaces, that would cause a conflict since both routers think their vlan 10 is the correct vlan 10. If you add a router or a l3 switch behind them and set up trunking between those two routers/switch and router, thatd create enough separation between the vlans, essentially creating two organization level LANs separated by another LAN/WAN (whatever you want to call it) between the central 2 routers.

[ipspace]

In other words, an exception to the rule: https://github.com/ipspace/netlab/blob/dev/docs/module/vlan.md#vlan-connectivity-model

The VLAN configuration module assumes you're creating a sane design in which:

* VLAN numbers are globally unique (you're not reusing 802.1q values)

So we're finally to the "I want do something that the documentation is saying I shouldn't be doing" phase again.

I didn't realize that wasn't being enforced

I can make that change ;) (no, I won't)

[ipspace]

@Astrotokii: the root cause for the described behavior (and the recommendation) is the way netlab figures out what a node neighbors are (for example, to set up BGP neighbors or to figure out if an OSPF interface should be a stub interface). Instead of implementing a connectivity graph traversal routine, I decided to go with "we're assuming a VLAN is contiguous".

As this discussion shows, we can get away with reusing the VLAN ID for multiple VLANs, but netlab still assumes each VLAN is contiguous. I would have to look into the code (or run a few tests) to figure out whether the "contiguous VLAN" assumption applies to VLAN name or ID, but will leave that to anyone who likes to ignore the documentation and live on the bleeding edge ;))

[Astrotokii]

Haha That sounds like a good idea, works for me!