FR Routing Control of Interface Configuration

[d307473]

Any plans for supporting 802.1Q Vlan Sub-Interfaces?

[donaldsharp]

@schadom -> Can you be a bit more specific about the behavior you'd like to see?

[d307473]

Yes, it would be very nice to have tagged Vlan (802.1Q) support in vtysh. Ideally with subinterfaces (like for example interface eno1.123 for Vlan 123). Debian-based distros will require the vlan package, but writing the config into /etc/network/interfaces should be very straightforward.

[eqvinox]

We don't create any interfaces, just create them in kernel by whatever means your system has.

=> doc update?

[d307473]

We don't create any interfaces, just create them in kernel by whatever means your system has.

Thanks @eqvinox for clarifying this. I think it would be much clearer if the docs would state that interfaces have to be configured manually on OS-level and not via vtysh. What about removing the ip address and ipv6 address subcommands completely from vtysh's interface context for now to avoid confusion?

For example, with the current implementation someone could accidentally configure different ip addresses for a interface via vtysh and on OS-level which could lead to unexpected results. Speaking of the future, I'd love to configure everything (including interfaces and vlans) via vtysh, but I guess that's not a top priority for the frr project at the moment.

[netravnen]

For example, with the current implementation someone could accidentally configure different ip addresses for a interface via vtysh and on OS-level which could lead to unexpected results. Speaking of the future, I'd love to configure everything (including interfaces and vlans) via vtysh, but I guess that's not a top priority for the frr project at the moment.

"FRR provides the control plane, it only concerns itself with calculating and installing routes into the kernel." (1) imo describes frr very well.

[netravnen]

For somebody coming from Cisco-world used to Cisco-ish CLI it's weird to see an interface command which actually does not do what it's intended to do

GNU Linux (or FRR) should not ever be compared to Cisco IOS. Their history and initial purpose for coming into this world has different roots, which imo should hardly be comparable. (I think of the previous comparisson as similar to IOS vs. JUNOS, their purpose very much the same, works quite differently under the hood and configuring them)

[EasyNetDev]

Hi,

Few years ago I was starting to write a separate daemon, something like named layer2d for quagga, which was only based on creating layer 2 interfaces (802.1q, IPIP tunnels, GRE, VXLAN etc). I dropped the idea because of lack of time and also I've started only for Linux based distros. In my opinion, if we want to implement such commands, they should be added in a totally different daemon and not integrated in zebra or other protocols.

Kind regards, Adrian

[jmiezitis]

I would give my support to FRR taking on the management of interfaces and assignment of addresses etc. With all the distros doing different things with regard to networking and changing every few years, it would be great to install frr to have a consistent interface of my choice.

Cheers.

[riw777]

Changed the title based on final parts of the conversation here. I doubt anyone is going to take this on--not certain the community would want to actually do this for reasons outlined above ... Closing this and adding it to the roadmap board, however, in case someone wants to pick it up in the future.