[j-nsp] QFX5110 : Q-in-Q in VXLAN
raphael at zoreole.com
Mon Sep 10 15:22:50 EDT 2018
There is some limitation on the qfx due to the Broadcom chip. On the 10k, you don’t have all the limitations to the cheap chip ^^
On the 5100 you have a lot of limitation on the 5110, you have less, but not sure it support the double tag encapsulated frames (Broadcom)
I have a bunch of evpn infrastructure deployed, but I never tried to use q-in-q, so not sure if 5k will support this.
I have 10k’s in the lab I may be able to test it
Envoyé de mon iPhone
> Le 10 sept. 2018 à 20:48, Brian Rak <brak at gameservers.com> a écrit :
> Are you trying to push multiple .1q tags onto the VXLAN traffic? (meaning you're trying to add a C-VLAN *and* a S-VLAN)?
> If so, JTAC has told me that QFX series devices (apparently the entire line...) do not support adding multiple .q1 tags
>> On 9/10/2018 2:32 PM, Olivier FRUQUET wrote:
>> We've got an IP fabric composed with 2 MX204 routers as cores, 2 QFX5110
>> switches as Provider Edges, and 2 EX2300 as Customer Edges.
>> The MX and the QFX communicate together with BGP underlay and overlay
>> groups, the overlay group use evpn signaling.
>> Everything to run fine except when we want to make Q-in-Q vlans transiting
>> through the VXLAN tunnel (only one VNI : 1001).
>> 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.
>> We tested some scenarios : for example when we stop the Q-in-Q and just
>> putting VLAN 1001 tagged from the CE switches, the ping is OK through the
>> VXLAN tunnel.
>> We used the pattern 3 from your documentation on the Juniper's website :
>> Do you have some ideas ?
>> Thank you !
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp