VLAN Tagging KVM Virtual Switch Not Passing Traffic (Srched)

SUSE Product Topics SLES Virtualization
1

Hello All,

I searched and found a thread, however there were no responses.
https://forums.suse.com/showthread.php?3769-KVM-Server-needs-to-be-TAGGED&highlight=kvm+virtual+switch

Here is a synopsis of my issue:

Network A (VLAN 100) 10.10.100.0/24
Gateway 10.10.100.1
Network B (VLAN200) 20.20.200.0/24
Gateway 20.20.200.1

KVM Host Physical network
Eth1 VLAN 100 (tagged) 10.10.100.10
Eth2 VLAN 200 (tagged) 20.20.200.10

Tagged traffic can pass on both physical interfaces from KVM host to network switch:

linux-enrg:~ # ping 10.10.100.1 -I vlan100
PING 10.10.100.1 (10.10.100.1) from 10.10.100.10 vlan100: 56(84) bytes of data.
64 bytes from 10.10.100.1: icmp_seq=1 ttl=64 time=0.857 ms
64 bytes from 10.10.100.1: icmp_seq=2 ttl=64 time=0.730 ms

linux-enrg:~ # ping 20.20.200.1 -I vlan200
PING 20.20.200.1 (20.20.200.1) from 20.20.200.10 vlan200: 56(84) bytes of data.
64 bytes from 20.20.200.1: icmp_seq=1 ttl=64 time=0.482 ms
64 bytes from 20.20.200.1: icmp_seq=2 ttl=64 time=0.468 ms

KVM Virtual Switch Network Interfaces:
VLAN100
VLAN200

KVM Guest:
Eth0 virtual network NAT to 192.168.122.0/24
VLAN100 (host device eth1 macvtap) bridge
VLAN200 (host device eth2 macvtap) bridge

Eth1 vlan 100 tagged
linux-nybj:/etc/sysconfig/network # ping 10.10.100.10 -I vlan100
PING 10.10.100.10 (10.10.100.10) from 10.10.100.10 vlan100: 56(84) bytes of data.
64 bytes from 10.10.100.10: icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from 10.10.100.10: icmp_seq=2 ttl=64 time=0.076 ms

#Fails to ping host or gateway
linux-nybj:/etc/sysconfig/network # ping 10.10.100.1 -I vlan100
PING 10.10.100.1 (10.10.100.1) from 10.10.100.10 vlan100: 56(84) bytes of data.
From 10.10.100.10 icmp_seq=1 Destination Host Unreachable
From 10.10.100.10 icmp_seq=2 Destination Host Unreachable

Eth2 vlan 200 tagged
linux-nybj:/etc/sysconfig/network # ping 20.20.200.10 -I vlan200
PING 20.20.200.10 (20.20.200.10) from 20.20.200.10 vlan200: 56(84) bytes of data.
64 bytes from 20.20.200.10: icmp_seq=1 ttl=64 time=0.087 ms
64 bytes from 20.20.200.10: icmp_seq=2 ttl=64 time=0.073 ms

#Fails to ping host or gateway
linux-nybj:/etc/sysconfig/network # ping 20.20.200.1 -I vlan200
PING 20.20.200.1 (20.20.200.1) from 20.20.200.10 vlan200: 56(84) bytes of data.
From 20.20.200.10 icmp_seq=1 Destination Host Unreachable
From 20.20.200.10 icmp_seq=2 Destination Host Unreachable

I have tried several permutations of bridges, pass-thrus, etc and have not had any success. I have to be missing something, but I need another set of eyes to help me with what I am overlooking. Also, are there any commands I can use to diagnose traffic through the virtual switch?

Regards,
WS

2

[QUOTE=sorgenfw;57314]Also, are there any commands I can use to diagnose traffic through the virtual switch?[/QUOTE]You can sniff network traffic with Wireshark. Check with “# ifconfig” the name of the network interface.

[CODE]# su

dumpcap eth0 -B 10 -w /tmp/test.pcapng

chown foo:users /tmp/test.pcapng[/CODE]

https://wiki.wireshark.org/CaptureSetup/CapturePrivileges

Open test.pcapng in wireshark. => There exists a “VLAN” column in wireshark for easy “VLAN debugging”…

I don’t understand your vlan configuration. “Normally” the setup (for KVM host) is like:

create vlan

[CODE]# modprobe 8021q

vconfig add eth0 100

ifconfig eth0.100 192.168.100.10 netmask 255.255.255.0 up[/CODE]

check vlan configuration

[CODE]# ifconfig

ping 192.168.100.1[/CODE]

delete vlan configuration

ifconfig eth0.100 down vconfig rem eth0.100

3

Thank you I will follow your suggestion. Meanwhile I just tested the ability to pass targeted within the virtual environment. Traffic will pass with tags from VM to VM, but not in or out of the virtual switch.

VM to VM
linux-sles12vm:~ # ping 10.10.100.11 -I vlan100
PING 10.10.100.11 (10.10.100.11) from 10.10.100.10 vlan100: 56(84) bytes of data.
64 bytes from 10.10.100.11: icmp_seq=1 ttl=64 time=0.758 ms
64 bytes from 10.10.100.11: icmp_seq=2 ttl=64 time=0.993 ms

linux-clone:~ # ping 20.20.200.10 -I vlan200
PING 20.20.200.10 (20.20.200.10) from 20.20.200.11 vlan200: 56(84) bytes of data.
64 bytes from 20.20.200.10: icmp_seq=1 ttl=64 time=0.700 ms
64 bytes from 20.20.200.10: icmp_seq=2 ttl=64 time=0.724 ms

VM to gateway:
linux-sles12vm:~ # ping 10.10.100.1 -I vlan100
PING 10.10.100.1 (10.10.100.1) from 10.10.100.10 vlan100: 56(84) bytes of data.
From 10.10.100.10 icmp_seq=1 Destination Host Unreachable
From 10.10.100.10 icmp_seq=2 Destination Host Unreachable

linux-clone:~ # ping 20.20.200.1 -I vlan200
PING 20.20.200.1 (20.20.200.1) from 20.20.200.11 vlan200: 56(84) bytes of data.
From 20.20.200.11 icmp_seq=1 Destination Host Unreachable
From 20.20.200.11 icmp_seq=2 Destination Host Unreachable

[QUOTE=AndreasMeyer;57316]You can sniff network traffic with Wireshark. Check with “# ifconfig” the name of the network interface.

[CODE]# su

dumpcap eth0 -B 10 -w /tmp/test.pcapng

chown foo:users /tmp/test.pcapng[/CODE]

https://wiki.wireshark.org/CaptureSetup/CapturePrivileges

Open test.pcapng in wireshark. => There exists a “VLAN” column in wireshark for easy “VLAN debugging”…

I don’t understand your vlan configuration. “Normally” the setup (for KVM host) is like:

create vlan

[CODE]# modprobe 8021q

vconfig add eth0 100

ifconfig eth0.100 192.168.100.10 netmask 255.255.255.0 up[/CODE]

check vlan configuration

[CODE]# ifconfig

ping 192.168.100.1[/CODE]

delete vlan configuration

ifconfig eth0.100 down vconfig rem eth0.100[/QUOTE]

4

Hi WS,

there’s one detail I didn’t catch by your description:

To me, that sounds incomplete, to which device is vlan100 (inside the guest) connected and where is that bridged to on the host?

I’d have expected a setup like the following interfaces and bridges:

[CODE]
eth1 (host) - vlan100 (host)
- bridgeA (host) - eth1 (guest) - vlan100 (guest)

eth2 (host) - vlan200 (host)
- bridgeB (host) - eth2 (guest) - vlan200 (guest)[/CODE]

In other words, if you need to actually use tagged traffic inside the guest (which may not be required, see below), you need to bridge the guest’s virtual network adapter (eth1, eth2) to the host’s network adapter (eth1, eth2) and put the guest’s vlan adapter (vlan100, vlan200) on top of that. The host can also have a vlan adapter (vlan100, vlan200 ) on top of the host’s physical network adapter.

Since you decided to create individual guest adapters anyhow, you could also bridge the guest’s virtual network adapter to the host’s vlan adapter, and skip the additional vlan interface in the guest:

eth1 (host) - vlan100 (host) - bridgeA (host) - eth1 (guest)
eth2 (host) - vlan200 (host) - bridgeB (host) - eth2 (guest)

Your guest’s IP configuration would then go to the virtual network interfaces eth1/2 (guest), tagging that traffic would be handled by the vlan adapter of the host.

Unless you’re hiding parts of the network picture here (like having many VLANs on the host’s physical adapters), I’d even skip the VLAN tagging at the host level and let the switch handle it, since you have a physical adapter per VLAN anyhow. The server then would send out untagged traffic, the Ethernet switch handling any vlan-related issues.

Regards,
J

5

I apologize for the delay. The tagged traffic from guest to guest works. The tagged traffic that traverses the virtual switch out to the gateway does not.

eth0 is the NAT interface for management.

eth1 (VLAN100) is connected to a bridge to the host as you described.

eth2 (VLAN200) is connected to a bridge to the host as you described.

Physical interfaces:

Is this configuration correct?

Regards,
WS

[QUOTE=jmozdzen;57364]Hi WS,

there’s one detail I didn’t catch by your description:

To me, that sounds incomplete, to which device is vlan100 (inside the guest) connected and where is that bridged to on the host?

I’d have expected a setup like the following interfaces and bridges:

[CODE]
eth1 (host) - vlan100 (host)
- bridgeA (host) - eth1 (guest) - vlan100 (guest)

eth2 (host) - vlan200 (host)
- bridgeB (host) - eth2 (guest) - vlan200 (guest)[/CODE]

In other words, if you need to actually use tagged traffic inside the guest (which may not be required, see below), you need to bridge the guest’s virtual network adapter (eth1, eth2) to the host’s network adapter (eth1, eth2) and put the guest’s vlan adapter (vlan100, vlan200) on top of that. The host can also have a vlan adapter (vlan100, vlan200 ) on top of the host’s physical network adapter.

Since you decided to create individual guest adapters anyhow, you could also bridge the guest’s virtual network adapter to the host’s vlan adapter, and skip the additional vlan interface in the guest:

eth1 (host) - vlan100 (host) - bridgeA (host) - eth1 (guest)
eth2 (host) - vlan200 (host) - bridgeB (host) - eth2 (guest)

Your guest’s IP configuration would then go to the virtual network interfaces eth1/2 (guest), tagging that traffic would be handled by the vlan adapter of the host.

Unless you’re hiding parts of the network picture here (like having many VLANs on the host’s physical adapters), I’d even skip the VLAN tagging at the host level and let the switch handle it, since you have a physical adapter per VLAN anyhow. The server then would send out untagged traffic, the Ethernet switch handling any vlan-related issues.

Regards,
J[/QUOTE]

6

Hi WS,

eth1 (VLAN100) is connected to a bridge to the host as you described.

Not quite.

I don’t know how deep you’re into networking, so pardon me if I provide too much detail here:

  • VLANs are run (at wire-level) in a way that could be described as “putting an envelope around the original packet and writing the VLAN number on the envelope”. That’s what is called “tagged traffic”. The main purpose is to be able to separate traffic and to be able to transfer such traffic for more than one VLAN across a single connection (the latter often run via the protocol “IEEE 802.1q”).

  • The IP stack will only handle “untagged” packets. That is, if you put an IP address on some interface, the corresponding packets are sent without any tags, and only packets without tags are received by the IP stack

  • your host’s connections to the world (via eth1 and eth2) seem to connect to a network link where VLAN traffic is “tagged”. Packets received via eth1/2 directly will show the packets including “tags”.

  • The job of the virtual devices vlan100/vlan200 is to filter for the corresponding VLAN traffic from the enslaved interface and to un-tag the received traffic for its VLAN (and to add the tag when sending packets).

So when you create you guests’ interfaces eth1 as “bridged to vlan100”, you provide a virtual interface inside the guest, i.e. eth1, that will see untagged packets handed from the host machine to the guest (because untagging was done by the vlan100 device on the host and then these untagged packets were forwarded via the bridge).

If I understood you correctly originally, then you additionally create a “vlan100” device inside the guest, enslaving the guests eth1 interface. So it will look for tagged packets (for vlan 100), but none will come from the host - which already had untagged the packets coming from the external network.

But then you have two such guests… so when you ping guest2 from guest1, via your “vlan100” setup inside your guests, the following will happen:

  • guest1 sends an untagged IP packet to guest2 via guest1/vlan100
  • guest1/vlan100 will add the 802.1q tag and send the packet via guest1/eth1
  • guest1/eth1 will forward the packet to host/vlan100 via bridging
  • host/bridge/vlan100 notices the packet is for guest2 and bridges the packet to guest2/eth1
  • guest2/eth1 notices the VLAN tag (added in step 2 above, by guest1/vlan100 device) and forwards the packet to guest2/vlan100
  • guest2/vlan100 untags the packet and forwards it to the IP stack

So guest1 can reach guest2 just fine - but any communication to the outside world fails, because the host/vlan100 expects to see untagged packets coming from the guests via the host bridge, but instead receives tagged packets. And all those packets sent to the guests as untagged packets are ignored by the guests’ IP stacks, because those are listening on the guests’ vlan100 device, which filters out all those untagged packets.

Is this configuration correct?

if you’re using VLAN interfaces inside your VM (like I describe above), then I believe it’s not correct.

Two approaches: Either bridge your guests’ interfaces to the native eth1/eth2 interface on the host and keep the vlan100/vlan200 interfaces inside the guest - or keep bridging to the host’s vlan100/vlan200 interfaces, but skip the vlan100/vlan200 interfaces inside the guests.

I hope the above is understandable :-/

Regards,
J

7

Hello Jmozdzen,

Thank you for your detailed and excellent response. I have been away from networking for a little while and was operating under the general assumption that everything had to be tagged on both ends since I am used to dealing with switches, hardware, etc. Your explanation makes perfect sense.

I did do an initial quick test and I was able to get out of the virtual switch, but did not test side to side yet. Interestingly enough, the host itself can no longer can communicate with the guest. I believe this is expected. Nevertheless, is there a solution that would get me both?

Thank you again for your efforts!

Regards,
WS