VLAN module: device behaviour option

[ssasso]

Reading at the VLAN module doc, it seems you define if the device is behaving like a router or a switch depending on the presence of vlan_subif_name or routed_subif_name.

However, some devices (i.e., VyOS and Mikrotik) can have both behaviours, depending on the use case (or user preferred config).
Could it make sense, in your opinion, to add an additional option (i.e., behaviour: <router|switch>), that can be used to select the config mode when both the above parameters are specified?

[ipspace]

Of course we can do it. For example, we could add vlan.model (or similar) node-level attribute, and use it to select the desired behavior. That attribute could be specified in device defaults, and then overwritten in individual nodes.

Alternatively, we could document the weird settings one has to use to force VyOS or Mikrotik to behave like router or switch -- after all, you can change any device defaults in topology file.

[jbemmel]

In my view there are already far too many knobs with various interpretations of their meaning, especially in the new vlan module

In my (simplistic) world, a VLAN interface is routed if it has an IP address assigned. If not, it is switched

[ipspace]

In my view there are already far too many knobs with various interpretations of their meaning, especially in the new vlan module

Agreed. I had absolutely no idea how convoluted VLANs could get until I tried making a somewhat-sane data model describing them, and look where it ended :(

In my (simplistic) world, a VLAN interface is routed if it has an IP address assigned. If not, it is switched

While we all agree with that, some devices use VLAN interfaces and switchports, and other devices use subinterfaces to reach the same goal... and then there are devices (VyOS, Mikrotik) where you can use either approach.

But yeah, I would also prefer documenting existing nerd knobs (device defaults) over implementing another nerd knob ;)

[jbemmel]

For devices that support both, let the template creator pick one. And if they want to support both, they can add a flag in topology-defaults to let the user pick

The current code is trying to sort out differences between vendors and devices by extending the data model, complicating life for everyone. I would prefer to go back to a simple model ( like has IP address -> routed ) and put device specific modeling in the device specific templates only

[ipspace]

The current code is trying to sort out differences between vendors and devices by extending the data model, complicating life for everyone. I would prefer to go back to a simple model ( like has IP address -> routed ) and put device specific modeling in the device specific templates only

That is true, but the alternative is worse: business logic and reverse-engineering in Jinja2 templates. We all love that 🤪

[jbemmel]

That is what I am doing right now (in SR Linux templates), reverse-engineering based on (for me) irrelevant flags and concepts

I have no experience with Cisco-esque networking models, terms like 'svi' and 'bvi' have no meaning for me. In my world, VLANs are just tags on an interface, not systemwide resources.

I guess what seems logical to me may seem different from other people's perspective.

[ipspace]

That is what I am doing right now (in SR Linux templates), reverse-engineering based on (for me) irrelevant flags and concepts

I knew we would face a tons of challenges in the VLAN world, that's why I wrote https://netsim-tools.readthedocs.io/en/dev/dev/config/vlan.html

Assuming you read it, I did a bad job. How could I improve it?

[ipspace]

After mulling this over for a while, and sleeping on it ;)

• We have to support a wide range of use cases (see Create simple VLAN test cases in tests/integration/vlan #309), from simple bridging to router-on-a-stick
• We have to support devices with widely different capabilities and configuration approaches
• Everyone hates complex logic in Jinja2 templates, and it's probably better to have the complexity in Python code.

Ergo: the Python code has to create interface- and VLAN data models that are close enough to what devices expect that a platform implementer could use them without too much Jinja2 hassle.

However, the current approach to figuring out what needs to be done is broken (thanks for pointing it out, albeit a bit indirectly). We should use an explicit device flag (example: vlan.model) and set it to router or switch, replacing the awkward "if this attribute is defined then we go down this path, otherwise we go down that path" decisions. I will try to make the code extensible, so we'll be able to add (for example) sub-categories of switches like l3-switch.

I will rewrite the code in a week or two; can't do it before then.

[ipspace]

Implemented in 35fbf70. Hope the documentation and the code is (slightly) easier to read now.