Routed vlan prefixes

[jbemmel]

netlab/tests/topology/expected/vlan-vrf-lite.yml

Line 1094 in c6ef55a

ipv4: 172.16.1.0/24

The above prefix associated with the blue vlan confuses me, since:

• https://github.com/ipspace/netlab/blob/dev/tests/topology/expected/vlan-vrf-lite.yml#L373 ipv4: 172.16.3.1/24

For routed vlans, perhaps we should not be allocating a prefix globally?

[jbemmel]

A test case for addressing of routed vlans:

defaults.device: srlinux
provider: clab

module: [vlan]

addressing:
  lan:
    ipv4: 192.168.0.0/20
    prefix: 24

  p2p:
    ipv4: 172.16.0.0/16
    prefix: 30

  routed-pool-1:
    ipv4: 100.0.0.0/24
    prefix: 31

  routed-pool-2:
    ipv4: 200.0.0.0/24
    prefix: 31

vlans:
  routed-1:
    mode: route
    pool: routed-pool-1 # Default == lan for irb, p2p for routed vlans

  irb-1:
    mode: irb

nodes:
  r1:
  r2:
  r3:
    vlans:
      routed-1:
        pool: routed-pool-2  # Override at node level

links:
- r1: # Currently (dev) taken from p2p pool
  r2:
  vlan.access: routed-1

- r2: # Currently (dev) taken from p2p pool
  r3:
  vlan.access: routed-1 # Outside of trunk, should get overridden by r3.vlans.routed-1.pool

- r1: # Currently (dev) becomes a vlan_member with ip from lan pool
  r3:
  vlan.trunk: [ routed-1 ] # Inside trunk, should get overridden by r3.vlans.routed-1.pool

- r1: # Currently (dev) becomes vlan_members with ips from lan pool ( routed vlan_member + svi for irb )
    vlan.trunk:
      routed-1:
        pool: routed-pool-2  # Override at trunk level
  r2:
  vlan.trunk: [ irb-1, routed-1 ]

Currently (dev branch) a routed vlan becomes a p2p link when used as access vlan, but it remains 'lan' when used in a trunk.
None of the pool override cases work as one might expect

• Should we convert routed vlans to link.type = p2p for addressing purposes?
• Should we support node or trunk level override of the 'pool'

[ipspace]

#1 and #2 can be solved by following the new "don't use routed VLANs on access links" deployment recommendation ;)

#3: we don't look into node VLAN attributes when setting link attributes. Node VLAN attributes are only used to augment interfaces. Setting pool on node VLAN thus does nothing.

#4: as above. Interface attributes are not affecting link parameters.

Finally, where do you get all these edge cases? They are smack in the middle "it might work, but you'd be the only one in the world doing it" territory ;) (BTW, I got the quoted response from Cisco TAC when asking about hierarchical route reflectors in early 1990s)

[jbemmel]

Just discussing with myself here - the issue is https://github.com/ipspace/netlab/blob/dev/tests/topology/input/vlan-routed-vrf.yml#L44

vlan.mode can be set globally as 'route', but overridden locally as 'bridge' ( e.g. by a switch ). IPs still need to be allocated consistently from the same pool

[ipspace]

For routed vlans, perhaps we should not be allocating a prefix globally?

Every segment in a routed VLAN needs a separate globally allocated prefix as we never know whether it will be used in a VRF or in the global routing table (and per-VRF address pools aren't pretty high up on the wish list ;)

[ipspace]

I'd guess we have something along these lines in the VLAN/VRF module. In any case, I don't think anyone wants to touch that blob of code.