Hey, 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). -- Pavel _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp