trunking

[dakota56]

Hi everybody !

I made a simple lab based on the full2-qfx. Two VM (vqfx-re) are linked between each other using a bridge aggregation in trunk mode. It seems the problem is related to the trunk (vlan tagging). After a few research I found that the VirtualBox Intel Pro/1000 interface (82540EM) could strip the VLAN tag. So I tried using other kind of interface available (PCnet,..,virtio-net). The problem is that the lab doesn't work at all (link RE - PFE down) if I change the interface type. So my question is did anyone manage to make trunking work ?

Dimitri

[akosiaris]

I 've met this as well. While trying to debug it I 've set the following extra configuration in vqfx.conf.j2

--- a/full-2qfx/vqfx.conf.j2
+++ b/full-2qfx/vqfx.conf.j2
@@ -55,6 +55,28 @@ interfaces {
         }
     }
 {% endfor %}
+    xe-0/0/4 {
+       unit 0 {
+               family ethernet-switching {
+                       interface-mode trunk;
+                       vlan {
+                               members [ lalakis lalakis2 ];
+                       }
+               }
+       }
+    }
+    irb {
+       unit 10 {
+               family inet {
+                       address 10.20.30.1/24;
+               }
+       }
+       unit 20 {
+               family inet {
+                       address 10.20.40.1/24;
+               }
+       }
+    }
     em0 {
         unit 0 {
             family inet {
@@ -70,13 +92,16 @@ interfaces {
         }
     }
 }
-protocols {
-    lldp {
-        interface all;
-    }
-}
 vlans {
     default {
         vlan-id 1;
     }
+    lalakis {
+       vlan-id 10;
+       l3-interface irb.10;
+    }
+    lalakis2 {
+       vlan-id 20;
+       l3-interface irb.20;
+    }
 }

And after provisioning I 've changed the IPs for the irb.10 and irb.20 on vqfx2 (sorry I did not feel like correctly templating the irb interfaces). Note that I 've disabled LLDP, that is to remove some noise from the dumps

Then I issued

> monitor traffic interface xe-0/0/4 layer2-headers no-resolve size 9000

On both vqfx's

And pinged the irb.10 vqfx2's IP from vqfx1. This is what I got

vqfx1

13:43:23.781587 Out 02:05:86:71:4b:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, arp who-has 10.20.40.2 tell 10.20.40.1

vqfx2 never registered anything.

Setting a native-vlan-id for one of the 2 VLANs works just fine and packets show up in monitor traffic, so indeed there's something (virtualbox probably?) that is blocking 802.1Q packets.

Some basic nic tracing with vboxmanage modifyvm --nictraceX=on (NOT for the management/reserved/internal_with_pfe interfaces) and a quick study of the PCAP file shows no VLAN tagged packets. So even as the VLAN tagged packets leave the VM, they are dropped ?

[akosiaris]

I can confirm Virtualbox is not to blame here. Nor is the VLAN type. I 've added 2 ubuntu trusty VMs to the full2-qfx and configured them to issue 802.1Q ARP packets. The 2 VMs can normally see that packets in tcpdump and are able to discern the correct ethertype, e.g.

vagrant@box2:~$ sudo tcpdump -eni eth1
...
12:54:47.750513 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 100, p 0, ethertype ARP, Request who-has 255.255.255.255 tell 50.50.50.50, length 46
12:54:48.751217 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 100, p 0, ethertype ARP, Request who-has 255.255.255.255 tell 50.50.50.50, length 46
12:54:49.752319 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 100, p 0, ethertype ARP, Request who-has 255.255.255.255 tell 50.50.50.50, length 46
12:54:50.752691 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 100, p 0, ethertype ARP, Request who-has 255.255.255.255 tell 50.50.50.50, length 46
12:54:54.564860 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 255.255.255.255 tell 50.50.50.50, length 46
12:54:55.565522 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 255.255.255.255 tell 50.50.50.50, length 46
12:54:56.565382 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 255.255.255.255 tell 50.50.50.50, length 46

Note the change that happens midway through the dump as I switch from from sudo arping -B -S 50.50.50.50 -i vlan100 to sudo arping -B -S 50.50.50.50 -i eth1 on the first VM.

In case you are wondering in Vagrantfile the network config for the VMs is

config.vm.network "private_network", ip: "192.168.33.10", auto_config: false, nic_type: '82540EM', virtualbox__intnet: "#{UUID}_seg5"

At the same time the vqfx's monitor traffic no-resolve layer2-headers interface xe-0/0/4 output is (as in normal physical switches) not very forthcoming. Setting the interface to family inet

vagrant@vqfx1# show interfaces xe-0/0/4     
unit 0 {
    family inet;
}

causes

13:00:05.685139  In 08:00:27:65:49:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: arp who-has 255.255.255.255 tell 50.50.50.50

no matter if I send tagged or untagged packets. I guess that's expected though. Setting family to ethernet-switching makes monitor traffic not catch anything, but IIRC this happens anyway on QFXs and EXs as well, so it's expected as well I think.

I don't know how to debug this further but overall, this seems to be related to the VQFX platform and not virtualbox/vagrant/emulated NICs

[dakota56]

I didn't found out also. So as a workaround I used Qemu instead, following this tutorial : https://docs.gns3.com/144QvvLxBT69_fv-pPHf4etc5xjdItiA_a8s8gVmSTDk/index.html

[ferfemar]

I have the same issue w/ the lastest Vagrant images. So annoying.

[slinderud]

I got the same issue. Currently a huge issue as i wanted to use vqfx for an education project. With the lack of support of trunking this is currently hard to achieve.

[Jajao555]

I didn't found out also. So as a workaround I used Qemu instead, following this tutorial : https://docs.gns3.com/144QvvLxBT69_fv-pPHf4etc5xjdItiA_a8s8gVmSTDk/index.html

I used the same method but used vQFX 18.1R1.9 and ran into the same issue with trunking but it actually caused my interfaces to disappear. I ran a quick test on 15.1X53-D60.4 and trunking seemed to work fine using qemu. I'll have rebuild my lab with 15.1 I guess.

[Jajao555]

I didn't found out also. So as a workaround I used Qemu instead, following this tutorial : https://docs.gns3.com/144QvvLxBT69_fv-pPHf4etc5xjdItiA_a8s8gVmSTDk/index.html

I used the same method but used vQFX 18.1R1.9 and ran into the same issue with trunking but it actually caused my interfaces to disappear. I ran a quick test on 15.1X53-D60.4 and trunking seemed to work fine using qemu. I'll have rebuild my lab with 15.1 I guess.

I actually found this was some weird behavior when connecting the vQFX to a Cisco switch image. I ran into the same issue when reverting ti 15.1 so I saw an 18.4 version had been uploaded. This time I built the lab in steps testing each phase and found tagging and RSTP worked fine all the way until the Cisco images were added. I had them setup with RPVST and dot1q trunk to the vQFXs. I'll have to look into it more to see if I'm inadvertently causing a loop from incompatible spanning tree protocols or there something else weird going that would cause the vQFX to lose their interfaces.