Problem with GVRP on eth while having a bridge
Subsystems (2)
Hello list,
this was tested using vanilla 3.7.6 kernel.
When i add a vlan to an ethernet device supporting gvrp everything is fine until this ethernet device also had a bridge.
This works fine as long as eth1 is not attached to a bridge.
# ip link add link eth1 name eth1.99 type vlan id 99 gvrp on # ip link set eth1.99 up
The dynamic VLAN stays up at the switch - no problems.
If eth1 has a bridge the dynamic vlan is created at the switch so the initial packet was send but it disappears after a few seconds.
Wireshark shows that the kernel has stopped sending GVRP packets. After adding a bridge to eth1.
Greets,
Stefan
Quoted 12 lines · Stefan Priebe - Profihost AG
Hello list,
this was tested using vanilla 3.7.6 kernel.
When i add a vlan to an ethernet device supporting gvrp everything is fine until this ethernet device also had a bridge.
This works fine as long as eth1 is not attached to a bridge.
# ip link add link eth1 name eth1.99 type vlan id 99 gvrp on # ip link set eth1.99 up
Quoted 7 lines
The dynamic VLAN stays up at the switch - no problems.
If eth1 has a bridge the dynamic vlan is created at the switch so the initial packet was send but it disappears after a few seconds.
Wireshark shows that the kernel has stopped sending GVRP packets. After adding a bridge to eth1.
Well, there's no reason why it should continue sending packets after the switch has been updated unless it receives a message indicating that the switch is about to remove it from it's tables again. So please describe the entire GVRP message exchange that's going on.
Also you probably want to add the VLAN device on top of the bridge device, otherwise it will get passed to the bridge after untagging, which might not work, depending on the MAC addresses used.
Hi Patrick,
thanks for your fast response.
Quoted 2 lines
So please describe the entire GVRP message exchange that's going on.
I've attached two small pcap files.
has_bridge.pcap: is where eth1 has a bridge and the dynamic vlan disappears after a few seconds.
no_bridge.pcap: no bridge is assigned to eth1 - the dynamic vlan stays as long as i remove it
Quoted 3 lines
Also you probably want to add the VLAN device on top of the bridge device, otherwise it will get passed to the bridge after untagging, which might not work, depending on the MAC addresses used.
That's working fine in vanilla kernel 3.7.6 but it does not with RHEL 6. Also i looks more complicated as i need another bridge on top of the vlan to assign the needed tap devices. I looked at ovirt for the network setup:
http://www.ovirt.org/Vdsm_Network
and they also add the vlan directly on top of the nic and then the bridge on top of the VLANs.
Greets,
Stefan
Am 07.02.2013 12:22, schrieb Patrick McHardy:
Quoted 30 lines · Stefan Priebe - Profihost AG
Quoted 12 lines
Hello list,
this was tested using vanilla 3.7.6 kernel.
When i add a vlan to an ethernet device supporting gvrp everything is fine until this ethernet device also had a bridge.
This works fine as long as eth1 is not attached to a bridge.
# ip link add link eth1 name eth1.99 type vlan id 99 gvrp on # ip link set eth1.99 upQuoted 7 lines
The dynamic VLAN stays up at the switch - no problems.
If eth1 has a bridge the dynamic vlan is created at the switch so the initial packet was send but it disappears after a few seconds.
Wireshark shows that the kernel has stopped sending GVRP packets. After adding a bridge to eth1.
Well, there's no reason why it should continue sending packets after the switch has been updated unless it receives a message indicating that the switch is about to remove it from it's tables again. So please describe the entire GVRP message exchange that's going on.
Also you probably want to add the VLAN device on top of the bridge device, otherwise it will get passed to the bridge after untagging, which might not work, depending on the MAC addresses used.
Quoted 18 lines · Stefan Priebe - Profihost AG
Hi Patrick,
thanks for your fast response.
Quoted 2 lines
So please describe the entire GVRP message exchange that's going on.
I've attached two small pcap files.
has_bridge.pcap: is where eth1 has a bridge and the dynamic vlan disappears after a few seconds.
no_bridge.pcap: no bridge is assigned to eth1 - the dynamic vlan stays as long as i remove it
Quoted 3 lines
Also you probably want to add the VLAN device on top of the bridge device, otherwise it will get passed to the bridge after untagging, which might not work, depending on the MAC addresses used.
Quoted 8 lines
That's working fine in vanilla kernel 3.7.6 but it does not with RHEL 6. Also i looks more complicated as i need another bridge on top of the vlan to assign the needed tap devices. I looked at ovirt for the network setup:
http://www.ovirt.org/Vdsm_Networkand they also add the vlan directly on top of the nic and then the bridge on top of the VLANs.
What seems to be happening is that the switch is constantly requesting GVRP updates. Once eth0 is added to the bridge, the bridge has preference over local protocol (LLC) delivery. Since the packet has a link local destination and your bridge doesn't seem to have STP enabled, the bridge decides to forward the packet. Since its a multicast destination, the packet is finally passed up to LLC, but the receiving device is the bridge, not eth0. When the packet reaches the GARP input handler, no garp_port is associated to the device and the packet is dropped. This result is that the GARP protocol doesn't notice that the switch expects an update and the switch finally removes the VLAN.
So the solution is: put the VLAN on the bridge device.