[j-nsp] QFX5110 : Q-in-Q in VXLAN

Pavel Lunin plunin at gmail.com
Mon Sep 10 17:20:59 EDT 2018


The Q-in-Q encapsulation comes from the EX2300 switches to the QFX switches
> (the S-VLAN Q-in-Q tag is also 1001), but on the other end of the tunnel we
> don't have the Q-in-Q frames coming.

I am curious if the packets don't leave the ingress VTEP at all or the
tail-end VTEP can't treat them.

"ping -f -s 1000" and "monitor interface traffic" can help to figure out
where the packets are dropped. And if the VXLAN packets leave the
core-facing interface of the ingress VTEP, I'd suggest to put a sniffer in
the middle and take a look at the packets closely.

Not that I am sure that it will work but... Juniper explicitly says that
it's supported on all Trident2/2+/3-based switches in the very very fresh
JUNOS (make sure that you don't miss this point).

I suspect that it's not a honest Q-in-Q-in-VXLAN but some cheating, e. g.
pop the VLAN tags and push them back on the other side, while VXLAN tunnel
carries untagged / single-tagged frames. (Yes this requires per-vlan
tunnels and might not work for your need).

This is how VLAN-based Martini pseudowires work on those switches (even on
EX4550, if memory serves). It's officially supported in EX-to-EX/QFX-to-QFX
mode, where it works out-of-the-box, while in case where you have an
MX-like router on the other end, you need to manually push/pop VLAN tags
and disable control-word on the MX side (discussed many times in this list).


More information about the juniper-nsp mailing list