[j-nsp] A wierd problem with QinQ at QFX5100

[Alexandre Guimaraes]

That's my friend Giuliano!!!! My mentor!!

All information that he provides is 100% correct.

att
Alexandre

> Em 27 de mai de 2017, às 16:51, Giuliano C. Medalha <giuliano at wztech.com.br> escreveu:
> 
> Andrew
> 
> Good afternoon.
> 
> Q-in-Q works fine here for us in our production networks and in our labs.
> 
> Do you need the a sample config ?
> 
> We need to umderstand the topology to help. You can contact us in private.  Can you share with us ?
> 
> The problem is not qinq itself ... the problem is the limited numbers of protocols supported by L2PT in Junos ELS ( for qfx5100 )
> 
> My sugestion is to buy the EDGE license and use MPLS L2circuit to transport protocols PDUs ... only if you need it.
> 
> But if you does not need the pdu transport and need point to multipoint solutions ... another way is to use VXLAN / EVPN config.  Works fine for the QFX family
> 
> We have this solutions implemented in some service providers and DC environments ... and they use an access switch ( like ex2200 ) to encapsulate pdu using qinq before the qfx5100. Works fine and we can automate it with a tool that we developed ( in cloud ) to provision the vxlan tunnel on each qfx5100 interface.
> 
> Hope this helps
> 
> Att,
> 
> Giuliano C. Medalha
> WZTECH NETWORKS
> +55 (17) 98112-5394
> giuliano at wztech.com.br<mailto:giuliano at wztech.com.br>
> ________________________________
> From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> on behalf of Andrew Osnach <andrew at osnach.kiev.ua>
> Sent: Wednesday, May 24, 2017 11:33:20 AM
> To: Alexandre Guimaraes; Allan Eising
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] A wierd problem with QinQ at QFX5100
> 
> Hi guys,
> 
> Thank you for the answers. It's really sad to hear about it and there're
> two equally unsatisfactory solutions: vlan mapping or vlan ranges
> reservation..
> 
> Thanks again for the explanation!
> 
> 
>> On 23.05.17 14:52, Alexandre Guimaraes wrote:
>> Andrew
>> 
>> Unfortunately, Allan is correct... don't expect use QinQ in ELS system, will be very annoying trying to find a way the let the packets flow inside. And they don't flow gracefully....
>> 
>> A friend told to me:  QFX are Ferraris.... I answer him: then Juniper, don't knows how to drive.
>>  :)
>> 
>> att
>> Alexandre
>> 
>>> Em 23 de mai de 2017, às 06:00, Allan Eising <eising at nordu.net> escreveu:
>>> 
>>> Excerpts from Andrew Osnach's message of May 23, 2017 10:31 am:
>>>> Hello,
>>>> 
>>>> I have a mixed VC (QFX5100 and 3500, if it means) with 14.1X53-D40.8.
>>>> There's an interface that incapsulates C-VLANs into S-VLAN:
>>>> 
>>>> set interfaces ae31 flexible-vlan-tagging
>>>> set interfaces ae31 mtu 9216
>>>> set interfaces ae31 encapsulation extended-vlan-bridge
>>>> set interfaces ae31 unit 3174 vlan-id-list 21-22
>>>> set interfaces ae31 unit 3174 input-vlan-map push
>>>> set interfaces ae31 unit 3174 input-vlan-map vlan-id 3174
>>>> set interfaces ae31 unit 3174 output-vlan-map pop
>>>> 
>>>> The other side:
>>>> 
>>>> set interfaces ae0 flexible-vlan-tagging
>>>> set interfaces ae0 mtu 9216
>>>> set interfaces ae0 encapsulation extended-vlan-bridge
>>>> set interfaces ae0 unit 3174 vlan-id 3174
>>>> 
>>>> S-VLAN configured like this:
>>>> set vlans sv3174-qinq interface ae0.3174
>>>> set vlans sv3174-qinq interface ae31.3174
>>>> 
>>>> At this point everything works fine, but if I create a VLAN with the
>>>> same ID as a C-VLAN (21 or 22):
>>>> set vlans v21-user vlan-id 21
>>>> the traffic in the C-VLAN 21 stops.
>>>> When I delete v21-user the traffic in C-VLAN 21 restores.
>>>> 
>>>> What's wrong with it and how can I fix it?
>>>> 
>>> Hi,
>>> 
>>> QinQ on the QFX and all the other boxes running the ELS style is a bit
>>> of an abomination.
>>> 
>>> VLANs configured with extended-vlan-bridge interfaces are forwarded
>>> using a different daemon than VLANs forwarded using the
>>> classic ethernet-switching daemon.
>>> 
>>> It's quite likely that you cannot share VLAN IDs between the two methods of forwarding.
>>> 
>>> I would bug Juniper about this, but I wouldn't expect them to be able to
>>> fix it.
>>> 
>>> Best regards,
>>> 
>>> Allan Eising
>>> 
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp