A few questions regarding configuring VLANs (long time VyOS user)

I have three questions about configuring a VLAN in VyOS (long time VyOS user, first time using VLANs):

First, if configuring four VLANs/sub-interfaces (vif IDs 100, 200, 300, and 900 with IPs, 20.1/24, 30.1/24, and 90.1/24) on a physical interface (eth2), is it necessary to have a non-VLAN interface IP address, too? Or can the interface itself be without an IP address, while the VLANs provide all the IP addresses necessary. For example, is the following valid?

eth2 { vif 100 { address } vif 200 { address } vif 300 { address } vif 900 { address } }

Or does eth2 have to have its own IP address, too, like the following?

eth2 { address vif 100 { ... }

What is the purpose of this IP address on the master interface if no other devices will have IP addresses on its subnet? What is the side effect of not having this IP address on the master interface? I see examples with this IP address but no explanation of its purpose, and I also see examples without it.

Second, is it appropriate for me to have all the DHCP subnets for these VLANs on the same shared network name, as below? VyOS warns me that this implies they’re on the same physical network when I commit, but if I understand correctly, they are on the same physical network. Am I doing something wrong here?

shared-network-name BONDED_PORTS { ... subnet { ... } subnet { ... } subnet { ... } subnet { ... } }

Finally, given that I’ve enabled SSH but haven’t yet set up my firewall (I’m not yet connected to a public network, so there’s no danger), should I not be able to ping or SSH into VyOS through from a client that successfully got the IP address from the DHCP server? Because I can’t ping or SSH.

You can think of VLANs as a way of adding more ports to your router - except that the additional ports share the same cable. On the cable, Ethernet frames are extended to have a so called VLAN “tag” which contains the VLAN ID - a few bytes added to the header. Having this extension, such packets are called “tagged”. However, it is still possible to send Ethernet frames “untagged” on an interface and this is what the “master” interface is doing. In fact it is just doing what it does when you haven’t configured VLAN "sub"interfaces.

The connected router or switch will have a way of differentiating between tagged and untagged packets. It depends on your scenario whether sending untagged packets makes sense - and so some examples show an address configured for the untagged interface and some do not.

Your ability to ping a tagged VLAN interface depends on sending VLAN tagged Ethernet frames from your side. PCs usually just use untagged frames and it is the duty of a switch then add a VLAN tag - on the interface that connects to your VyOS router.

Okay, that makes sense. Later in the day I started to suspect that the “master” IP was for untagged packets, but I wasn’t sure. Thanks for confirming it.

What about my above proposed DHCP config? Is it valid, given that all these VLANs are on the same physical interface? Or do I actually need separate shared-network-names, one for each tagged VLAN and one for the untagged/native VLAN?

One additional (slightly-unrelated) question. I’m soon going to have a pool of 8 static public IPv4 addresses and a static /60 delegation of IPv6 addresses that I’m going to assign to publicly-facing servers behind a DMZ VLAN. Obviously, one IPv4 and one IPv6 will need to be dedicated to my WAN interface (the gateway). But will I also need to dedicate one of the IPv4 and one of the IPv6 for the VLAN sub-interface? And/or the master (physical) interface? Or is it sufficient to enter some routing rules and have just the IP on the WAN and configure the interface on each server with a public IP to use that gateway?

I cannot really comment on the DHCP question because we’re not using that in our network. However, if the DHCP configuration syntax needs you to bind a pool (with one or more subnets) to an interface, you would have to do that using the VLAN interface names - and one for the untagged interface too, if you connect a segment with untagged Ethernet frames.

WRT your DMZ question - please consider the layers involved: At the IP “routing” level, which is layer 3, your layer 2 decisions (VLAN etc.) are irrelevant. I.e. your VLAN interfaces connect you to truly separate network segments in the IP sense - as if you had more real interfaces on your router - and each interface in a segment needs to have an IP address (if it wants to communicate using IP). Therefore, your router VLAN interface, which is the default gateway for your servers, needs to have one address too - be it IPv4 and/or IPv6.

I get that the VLAN interface needs AN IP address. I just wasn’t sure whether it specifically needed one of the public IP addresses allocated to me, or if it could just have a private IP address. In other words, I wasn’t sure if only a private IP address on that VLAN interface could sit between the public IP address on the WAN and the public IP address on the server, or if there had to be a public IP address from the same block sitting between them.

The interface that the VLANs sit on doesn’t actually need an IP address at all. I have a few routers configured this way.

I agree that using untagged frames on a router is not often used - usually the cable goes to a switch and the switch would do the untagging for the ports with servers etc… So, yes, if untagged frames aren’t needed, there’s no need for an IP address at all.
I was just trying to explain why some examples show addresses for the untagged interfaces - maybe the better explanation would have been that these people had them on there because they don’t know really :slight_smile:

Turns out, I had a three-fold problem:

Problem 1: I had to support untagged frames / the native VLAN for the switch to live on. It would sometimes work, but not reliably, otherwise.

Problem 2: I had the DHCP subnets for the various VLANs all on the same “shared-network-name” pool. My understanding after reading the documentation, and especially based on the warning the config gave me (“You have created multiple subnets on the same shared network. This implies all the subnets share the same physical network.”), was that, because the VLANs were all on the same physical interface, they should be on the same shared network name pool. This was apparently incorrect.

Problem 3: I had the DHCP shared network name pools (both when using an individual shared network name with multiple subnets and after splitting it out into multiple shared network names each with one subnet) set to “authoritative enable.” This was apparently incorrect.

Only after I corrected all three of these problems did everything start working. Correcting just one or two did not fix it.