[j-nsp] QFX5110 : Q-in-Q in VXLAN

[Alexandre Guimaraes]

Well...

	From my experience with QFX5100, Q-inQ, does not work at all, only one(in one) vlan have the right to pass(VXLAN), L2TP Protocols don't have the rights to pass, funny thing....

	For years I discuss with local Juniper representative or Juniper team itself... but... no one cent about a solution.... once again, when I need a QinQ(full services), I use Cisco Catalysts

	Don't expend time and energy trying to find a solution for this neglect....

	I heard the same thing about the version 18.x, but honestly... leave it there... I still prefer keep my environment work and running with 14.1X53 with Mpls stuffs and an EX facing the customer.....   flow like water....

 
Att.,
Alexandre Guimarães
+55.19. 3517-7724
+55.19. 99822.4866
 
alexandre.guimaraes at ascenty.com
www.ascenty.com <http://www.ascenty.com/>
 
 

Em 11/09/2018 09:46, "juniper-nsp em nome de Alain Hebert" <juniper-nsp-bounces at puck.nether.net em nome de ahebert at pubnix.net> escreveu:

         Hi,
    
         On QFX5100 the L2TP/Q-in-Q services has limitations.  I have to dig 
    through my pile of tickets for details...  but I remember something 
    about PVST+ packets not being forwarded at all.
    
         So we just switched everything to MPLS/l2circuits/VLAN CCC (for 
    now) instead of battling with the QFX5100 platforms.  We'll deploy 
    EVPN/VXLAN to our customers once we find a solution but we're not in a rush.
    
         PS: I heard a rumor that there is a fix in 18.x for the QFX5100...
    
         To note that the QFX5110 platform do not seem to be suffering from 
    the same issues...  I suggest to get a demo to confirm the functionality.
    
    -----
    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 09/10/18 17:20, Pavel Lunin wrote:
    > Hey,
    >
    > 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.
    >>
    > I am curious if the packets don't leave the ingress VTEP at all or the
    > tail-end VTEP can't treat them.
    >
    > "ping -f -s 1000" and "monitor interface traffic" can help to figure out
    > where the packets are dropped. And if the VXLAN packets leave the
    > core-facing interface of the ingress VTEP, I'd suggest to put a sniffer in
    > the middle and take a look at the packets closely.
    >
    > Not that I am sure that it will work but... Juniper explicitly says that
    > it's supported on all Trident2/2+/3-based switches in the very very fresh
    > JUNOS (make sure that you don't miss this point).
    >
    > I suspect that it's not a honest Q-in-Q-in-VXLAN but some cheating, e. g.
    > pop the VLAN tags and push them back on the other side, while VXLAN tunnel
    > carries untagged / single-tagged frames. (Yes this requires per-vlan
    > tunnels and might not work for your need).
    >
    > This is how VLAN-based Martini pseudowires work on those switches (even on
    > EX4550, if memory serves). It's officially supported in EX-to-EX/QFX-to-QFX
    > mode, where it works out-of-the-box, while in case where you have an
    > MX-like router on the other end, you need to manually push/pop VLAN tags
    > and disable control-word on the MX side (discussed many times in this list).
    >
    >
    > --
    > Pavel
    > _______________________________________________
    > 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