Setting mode=route removes native vlan

[jbemmel]

A vlan with mode=route cannot be set as native; the resulting YAML does not include it

Is that intended?

Note that SR Linux only supports bridged untagged vlans on trunk ports, we should probably have a flag for this and validate/error out

[ipspace]

A vlan with mode=route cannot be set as native; the resulting YAML does not include it. Is that intended?

Yes. There's no difference between a regular interface and a native routed VLAN.

Note that SR Linux only supports bridged untagged vlans on trunk ports, we should probably have a flag for this and validate/error out

That's exactly as it should be. Native VLAN makes sense only on trunk ports, it's called access VLAN on non-trunk ports.

[jbemmel]

In my case it breaks the topology

I want to pass multiple vlans to a node, hence I put a trunk port. I need one of those vlans to be untagged - used for PXE boot - so I set a native vlan. If I add 'mode: route' to that vlan, the setting is silently ignored

The code should not auto-convert a native routed vlan to a regular interface if its part of a trunk port

[ipspace]

Look, you want to pass pure IP traffic to a node. You also want to have the switch-to-node link to be in a separate IP subnet (thus mode: route). That means you want to have an IP address on the physical switch interface.

Now please explain what's the difference between native VLAN and no VLAN in that scenario?

[jbemmel]

- leaf1a:
  h1:
  vlan.trunk: [ internet, openstack-external, openstack-internal, storage, pxeboot ]
  vlan.native: pxeboot

I want to pass multiple vlans to h1, including a native untagged one.

If I add mode: route to the pxeboot vlan, it gets removed and there is no untagged vlan on the port anymore

The difference is having a working setup, or not

[ipspace]

I'm still claiming that untagged routed VLAN and native IP interface are the same thing. Please explain how they are not.

However, adding mode: route to a native VLAN breaks many things really badly (like: all other VLANs get mode: route). That definitely needs to be fixed, opening an issue

[jbemmel]

If an untagged routed VLAN is the only vlan on a port, then it can be replaced by a native IP interface

However, if an untagged routed VLAN is part of a trunk containing other VLANs, then the interface needs to be tagged.
On SR Linux, the untagged VLAN needs to be configured using vlan: encap: untagged: { } - and you can only do that for bridged VLANs, not routed ones

So, in order to realize a "routed" native VLAN, it needs to be configured as "bridged", added to a mac-vrf together with a separate IRB interface which has the IP and performs the routing ("irb" effectively, unless mac learning would be disabled explicitly). If the native VLAN is the only VLAN, none of this is necessary and you can put an untagged, routed native IP interface instead.

[ipspace]

Ah, so we're back to "SR Linux does things in this particular way". You should have started with that -- I'm always telling networking engineers to start with "this is the challenge I'm trying to solve" instead of "how do you configure technology X to behave in some weird way" ;)

Looks like you can't have routed native VLAN on SR Linux, so maybe we need a feature flag for that.

In your particular PXE boot case, it might work to model it as a VLAN within the node (not global), so it will get a different prefix for each node, and then the default mode: irb will make it work. Obviously you'd have all connected servers in the same IP segment, but there's nothing we can about that.

... and with that I'm off to fixing #421. Fun times ahead...

[jbemmel]

If I were to focus solely on SR Linux, I'd simply refrain from using routed native vlans in my designs, and there would be no issue.

However, SR Linux runs on top of Broadcom chipsets, and they have certain limitations and particularities. I suspect this is one of them. The feature flag solves that

That would leave users of platforms that do support routed native vlans hanging though - so in my mind, the issue starts there (Setting mode=route removes native vlan)

[ipspace]

However, SR Linux runs on top of Broadcom chipsets, and they have certain limitations and particularities. I suspect this is one of them. The feature flag solves that

Most platforms running on top of Broadcom chipsets don't support a mix of bridged and routed VLANs on a single interface anyway, so who knows what Broadcom can do.

That would leave users of platforms that do support routed native vlans hanging though - so in my mind, the issue starts there (Setting mode=route removes native vlan)

You still don't get it. There is no need for native VLAN if the native traffic is routed. There is no need for extra subinterface in the router interface/subinterface config model if the IP traffic is untagged. Who cares what the native VLAN is in that case. Think about the fundamentals, not SR Linux config data model idiosyncrasies.

BTW, routed native VLANs work just fine with FRR and Cisco IOS (tests/integration/vlan/vlan-routed-native.yml).

[jbemmel]

With all due respect, I may not "get it" but the current implementation remains broken for platforms that don't supported routed native vlans. Meaning netlab create -d srlinux -p clab vlan-routed-native.yml doesn't throw an error.

The issue is that the 'native' flag gets removed before 'check_native_routed_vlan' gets a chance to run.

There is no need for native VLAN in the final output, but it needs to remain in place long enough for the check to happen. I would suggest moving it earlier: As soon as a 'native' vlan is defined on a port, check if it's mode is not "routed" or the platform supports routed vlans

[jbemmel]

See #441

Note that a mix of routed and bridged vlans does work, the limitation is only for an untagged routed vlan in combination with other tagged (bridged or routed) vlans on the same port

With the current code, the native vlan is removed and the ip is placed on the untagged trunk port, with additional tagged vlans as vlan_members. Technically it's no longer a native vlan, but it's still not supported :(

[ipspace]

Some of the above has been addressed with fixes in VLAN module.