Hello Sean
When using QinQ, you are able to tunnel multiple VLANs (inner VLAN tag) with a single QinQ VLAN (outer VLAN tag).
I hope this has been helpful!
Laz
hi,
I build my lab with two cisco routers and 3 arista switches. I configured all of boxes as same as the example but it did not work. I captured the packets among all of the boxes and I found out that the switch 2 did not pass the arp request to router 2. the arp passes switch 1 and 3 and once it goes to sw2, it did not forward it to router 2. please help?
Hello Manaf
Based on your description, I don’t have a definitive answer for why you see this behavior. Assuming everything else is configured correctly, there seems to be a problem with the configuration on SW2 and R2 and how they exchange information. I can give you some guidelines for troubleshooting that may be helpful:
- Do you find that ARP requests in the opposite direction are working, or do you see a similar behavior between R1 and SW1? If they’re working there, you can check to see the differences in configs…
- The ARP broadcasts must traverse both inner and outer VLAN tags. This can be blocked at the location between SW2 and R2 if there is a native VLAN mismatch, or if R2’s MAC address is in the incorrect VLAN.
- Are the ARP requests arriving at SW2 with both VLAN tags?
- Check the Ethertype being used on either end of the link (see this Cisco command reference)
- It could be an issue with inter-vendor operation. I don’t know how Arista deals with QinQ, so it may be something specific to this interoperability, which may need to be further explored.
Let us know how you get along and if we can help you any further!
I hope this has been helpful!
Laz
Hi,
I tested this exact same setup, but the ping doesn’t work. ARP request reached to the R2. But R2 doesn’t initiate ARP Reply.
Then I captured traffic on SW1’s trunk port directed towards SW3, and it has only one 802.1Q Tag, which is 123. It should include VLAN_12 as well, right?
Hello Pamod
Yes, on that link between SW1 and SW3 you should see two 802.1Q tags, but you see only one. That means that something is not right with the config. The key here is the configuration on Fa0/1 of SW1, and Fa0/2 of SW2. Those are the ports that have the “special” configuration that accommodates the double tagging.
You must make it an access port with the service provider’s VLAN that will contain the multiple customer VLANs. In the lesson, that’s VLAN 123. Then you must enable the switchpot mode dot1q-tunnel command. That will enable the QinQ mechanism. You should also make sure that VLAN 123 exists on all three switches.
Note that in your packet capture, you see the ARP messages being sent, but you don’t see a double tag on those, and you should. That seems to indicate that the config of the Fa0/1 port on SW1 needs troubleshooting (assuming your R1 is sending those ARPs). Take a look and let us know!
I hope this has been helpful!
Laz
Hey, it is exactly configured as described in the lesson.
SW1’s e0/1 & e0/0 configuration,
SW2’s e0/0 & e0/1 configuration,
SW3’s e0/0 & e0/1 configuration,
R1’s e0/0 configuration,
R2’s e0/0 configuration,
Hello Pamod
I suspect that the only thing missing is the configuration of VLAN 123 in SW3. I don’t see it in your config. Check that VLAN 123 is allowed on both trunks that connect to SW1 and SW3. Once that’s done you should see it working.
Now it is strange that you don’t see the double tagging on the packet capture between SW1 and SW3 even if VLAN 123 is not configured on SW3. I went into the lab and tried to disable VLAN 123 on SW3, and I did a packet capture. Indeed no ARP reply was sent, but I did see the double tagging like so:
Check out the VLAN setting on SW3 and test it out again and let us know how you get along.
I hope this has been helpful!
Laz
Hi Laz,
This is SW3. Both VLAN 12 & 123 are allowed in the trunk ports.
May be this is an issue with Eve-Ng. What platform are you testing these labs?
Hello Pamod
If that’s the case, then it looks like your setup is correct, and should work. I was using Cisco CML to test it out, and I saw that it behaved correctly. It could be an issue with EVE-NG.
Just a clarification, SW3 would not need to have VLAN 12 allowed, or even configured for that matter. SW3 would never see VLAN 12 since it is encapsulated within the 123 VLAN. Only the outer VLAN tag (e.g. 123) would be read by SW3. Of course this does not change the behavior of the topology, it should still work, but I’m just mentioning it here for clarity.
I hope this has been helpful!
Laz
1 Like