VLAN Bridge issue from Server 2019 Guest

pashadee

Active Member
Jan 11, 2014
34
0
26
Hi guys,

A little puzzled by what else to try here so I thought I'd reach out to this awesome community for some ideas.

I configured a bond interface to have 5 different vlans.

auto bond0
iface bond0 inet manual
bond-slaves enp3s0
bond-miimon 100
bond-mode active-backup

auto bond0.100
iface bond0.100 inet manual
vlan-raw-device bond0

auto bond0.213
iface bond0.213 inet manual
vlan-raw-device bond0

-- bond0.100 is management vlan -- bond0.213 is Server 2019 vlan.

auto vmbr0
iface vmbr0 inet static
address 10.100.0.15
netmask 255.255.255.0
gateway 10.100.0.1
bridge-ports bond0.100
bridge-stp off
bridge-fd 0

auto vmbr213
iface vmbr213 inet manual
bridge-ports bond0.213
bridge-stp off
bridge-fd 0


The gateway for vlan 213 is 10.213.0.1 -- I can ping this from the host machine no problems.
I assign vmbr213 as the network interface to my Server 2019 VM, configure it with a staic ip of 10.213.0.210 same gateway as mentioned above, and get "Destination host unreachable" ...

I've tried everything I could think of with no success...

If I change the VMs bridge to vmbr0 and just give it an ip of 10.100.0.123 ... everything works fine... for some strange reason just the vlan 213 is going dead...

Thanks guys!

Pasha
 
I also noticed that in /proc/net/vlan/config I have this:

VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.100 | 100 | bond0
bond0.201 | 201 | bond0
bond0.210 | 210 | bond0
bond0.211 | 211 | bond0
bond0.212 | 212 | bond0
bond0.214 | 214 | bond0
bond0.215 | 215 | bond0
bond0.100.213 | 213 | bond0.100
bond0.213 | 213 | bond0

I'm guessin the bond0.100.213 is there because I tried using vmbr0 as the VMs network bridge and added TAG 213, just to see if it would work that way.... guessing it never removed that after I changed it back to just vmbr213
 
Thanks aliistif,

If all else fails I could try that approach, just setting the vlan on the VM itself instead of on the host see if it makes any difference that way. For security I was hoping to be able to set it on the host instead though. Like I mention the strange thing in my setup is that I can ping the gateway (on the router) through the bridge interface on the host through which the VM is supposed to communicate, but the routing gets blocked/lost somewhere on the VM itself.
 
I also noticed that in /proc/net/vlan/config I have this:

VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.100 | 100 | bond0
bond0.201 | 201 | bond0
bond0.210 | 210 | bond0
bond0.211 | 211 | bond0
bond0.212 | 212 | bond0
bond0.214 | 214 | bond0
bond0.215 | 215 | bond0
bond0.100.213 | 213 | bond0.100
bond0.213 | 213 | bond0

I'm guessin the bond0.100.213 is there because I tried using vmbr0 as the VMs network bridge and added TAG 213, just to see if it would work that way.... guessing it never removed that after I changed it back to just vmbr213

until you use ifupdown2 to do network reload, the classic ifupdown1 don't work well, even on networking service (better to reboot).
but your config seem ok.
 
until you use ifupdown2 to do network reload, the classic ifupdown1 don't work well, even on networking service (better to reboot).
but your config seem ok.

I'll have to look in to that as I've just been using ifdown bond0 ... ifup bond0 ... but haven't really had to do that too much as I'm not sure what the problem is, and the fact that I can ping the gateway from the host no problem indicates to me that both the bond, the vlan and the bridge are functional.... I'm not seeing something between the vm host and the vm guest ...
 
So a little more info... working on my network diagnostics a little more :)

When I ping from the VM guest and capture using tcpdump -i vmbr213 I get

00:17:47.811607 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:48.835228 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:49.811602 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:50.811591 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:51.833287 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:52.812710 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:53.812727 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:54.829995 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:55.812687 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46
00:17:56.812645 ARP, Request who-has 10.213.0.1 tell 10.213.0.211, length 46

with no response obviously...

while capturing still and pinging from the host I get nothing... so it seems that the VM host server uses something other than vmbr213 to send and receiving on the 10.213.0.0 network...
 
here's the capture from VM host:

00:28:11.377345 IP 10.100.0.15 > 10.213.0.1: ICMP echo request, id 64151, seq 1, length 64
00:28:11.377490 IP 10.213.0.1 > 10.100.0.15: ICMP echo reply, id 64151, seq 1, length 64
00:28:12.400844 IP 10.100.0.15 > 10.213.0.1: ICMP echo request, id 64151, seq 2, length 64
00:28:12.400962 IP 10.213.0.1 > 10.100.0.15: ICMP echo reply, id 64151, seq 2, length 64
00:28:13.424839 IP 10.100.0.15 > 10.213.0.1: ICMP echo request, id 64151, seq 3, length 64
00:28:13.424949 IP 10.213.0.1 > 10.100.0.15: ICMP echo reply, id 64151, seq 3, length 64

So it's apparent it's not routing vlan 213 through vmbr213 ... it's sending it through vmbr0 for some reason...
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!