Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

The situation described in that bug appears to be specific to (XenServer?) cases where two interfaces are configured per VM. In my configuration, as far as I can see, only the tap interface is being created, and it is being tagged successfully according to ovs-vsctl.

The situation described in that bug appears to be specific to (XenServer?) cases where two interfaces are configured per VM. In my configuration, as far as I can see, only the tap interface is being created, and it is being tagged successfully according to ovs-vsctl.

ovs-vsctl. FTR, I'm using QEMU/KVM.

Also, I saw that you can see the VLAN (802.1Q) tag for a packet in tcpdump. I was able to see tag information for the DHCP packets I was looking for using, e.g.

# tcpdump -i em2 -n -e port 67
tcpdump: WARNING: em2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
02:28:00.596374 fa:16:3e:9e:d6:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 1003, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:9e:d6:26, length 300

At this point, I began to realise that I'd somehow managed to get the meanings/uses of the 'br-ex' and 'br-int' bridges confused. So I created a couple of new bridges for each host, named after the physical interfaces (i.e. 'br-em1' and 'br-em2'), and moved the physical ports to those bridges. This clarified things a little.

Most importantly, in doing so (and having read a ton more docs by then), I started to figure out what the 'int-*' ports were about and realised that I'd put 'em2' (physical) port on the 'integration' bridge, which was causing two DHCP packets per request to be sent out.

Anyway, the situation now is that it is sending correctly tagged DHCP packets out via the em2 port. The problem seems to be that the switch (NetGear GS724T v3) is not forwarding tagged packets to the other two hosts, as they are not receiving them on their 'em2' interfaces.

Unfortunately, in trying to configure 'VLAN trunking' between the ports on that switch, I've inadvertently locked myself out of it, and am waiting for some on-site staff to unwind a paperclip and do a factory reset :)

The situation described in that bug appears to be specific to (XenServer?) cases where two interfaces are configured per VM. In my configuration, as far as I can see, only the tap interface is being created, and it is being tagged successfully according to ovs-vsctl. FTR, I'm using QEMU/KVM.

Also, the end, I saw that you can see the VLAN (802.1Q) tag for a packet in tcpdump. I was able to see tag information for the DHCP packets I was looking for using, e.g.

# tcpdump -i em2 -n -e port 67
tcpdump: WARNING: em2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
02:28:00.596374 fa:16:3e:9e:d6:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 1003, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:9e:d6:26, length 300

At this point, I began to realise that I'd somehow managed to get the meanings/uses of the 'br-ex' and 'br-int' bridges confused. So I created a couple of new bridges for each host, named after the physical interfaces (i.e. 'br-em1' and 'br-em2'), and moved the physical ports to those bridges. This clarified things a little.

Most importantly, in doing so (and having read a ton more docs by then), I started to figure out what the 'int-*' ports were about and realised that I'd put 'em2' (physical) port on the 'integration' bridge, which was causing two DHCP packets per request to be sent out.

Anyway, the situation now is that it is sending correctly tagged DHCP packets out via the em2 port. The problem seems to be that the switch (NetGear GS724T v3) is not forwarding tagged packets to the other two hosts, as they are not receiving them on their 'em2' interfaces.

Unfortunately, in trying to configure 'VLAN trunking' between the ports on that switch, I've inadvertently locked myself out of it, and am waiting for some on-site staff to unwind a paperclip and do a factory reset :)