Open dakota56 opened 7 years ago
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 ?
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
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 have the same issue w/ the lastest Vagrant images. So annoying.
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.
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 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.
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