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

Roger Wiklund roger.wiklund at gmail.com
Thu Jun 1 15:45:47 EDT 2017


Hi

Try 14.1X53-D43, it has some fixes for L2PT.

/Roger

On Sat, May 27, 2017 at 9:50 PM, Giuliano C. Medalha
<giuliano at wztech.com.br> wrote:
> 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


More information about the juniper-nsp mailing list