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

[Alain Hebert]

     And PFE crashing when de-provisioning some IP customer in VCP with 
a CCC customer near by =D

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 06/01/17 15:45, Roger Wiklund wrote:
> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp