And PFE crashing when de-provisioning some IP customer in VCP with
a CCC customer near by =D
-----
Alain Hebert [email protected]
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
<[email protected]> 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
[email protected]<mailto:[email protected]>
________________________________
From: juniper-nsp <[email protected]> on behalf of Andrew Osnach
<[email protected]>
Sent: Wednesday, May 24, 2017 11:33:20 AM
To: Alexandre Guimaraes; Allan Eising
Cc: [email protected]
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 <[email protected]> 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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
