[j-nsp] EX4600 or QFX5110

Mon Mar 18 14:50:26 EDT 2019

Hello

EVPN-VXLAN in general is supported using PFL license (QFX) ... that is not too much expensive

AFL license will support MPLS (L2circuit) and EVPN MPLS features in some platforms ... but is costs more.

https://forums.juniper.net/t5/Enterprise-Cloud-and/Welcome-QFX5120-48Y/ba-p/329900

    The Base software includes basic Layer 2 switching, basic Layer 3 routing, multicast, automation, programmability, zero touch provisioning (ZTP), and basic monitoring. A Base software features license comes with the purchase of the hardware and does not require any explicit license unlocking keys.

    The Premium software feature license includes all the Base features along with BGP, IS-IS, and EVPN Virtual Extensible LAN (VXLAN). This tier requires the QFX5K-C1-PFL

    The Advanced software features license includes all the features from Premium tier along with MPLS feature set. These features require the QFX5K-C1-AFL

C2 license are for 5210 and 10k I think.

Att,

Giuliano

-----Original Message-----
From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of Alex Martino via juniper-nsp
Sent: segunda-feira, 18 de março de 2019 15:35
To: Anderson, Charles R <cra at wpi.edu>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] EX4600 or QFX5110

Thank you for that link, it's quite useful.

Would someone be able to confirm if EVPN with VXLAN data plane encapsulation would require or not the Advanced Feature Licenses, EX4600-AFL license?

Thanks,
Alex

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 15, 2019 11:14 PM, Anderson, Charles R <cra at wpi.edu> wrote:

> Check feature explorer, select EX4600, latest Junos:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.
> juniper.net%2Ffeature-explorer%2F&data=02%7C01%7Cgiuliano%40wztech
> .com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412
> b8ae504%7C1%7C0%7C636885310604161408&sdata=osFWynJitRqbvJIPRQiZ9f5
> %2BL%2F3mzsjJg3vrcR9vGwI%3D&reserved=0
>
> EVPN with VXLAN data plane encapsulation Junos OS 18.2R1 EVPN-VXLAN
> support of Virtual Chassis and Virtual Chassis Fabric Junos OS 18.2R1
> Tunneling Q-in-Q traffic through an EVPN-VXLAN overlay network Junos
> OS 18.2R1 Layer 2 Circuits Ethernet-over-MPLS (L2 circuit) Junos OS
> 14.1X53-D10 Layer 3 VPN (L3 VPN) Layer 3 VPN (L3 VPN) Junos OS
> 14.1X53-D10 Layer 3 virtual private network (VPN) for IPv4 (RFC 2547
> and 4364) Junos OS 13.2X51-D25† Virtual router (VRF-lite) - PIM, IGMP
> Junos OS 13.2X51-D25† Virtual routing and forwarding (VRF-lite) -
> ISIS, BGP Junos OS 13.2X51-D25† Virtual routing and forwarding
> (VRF-lite) - RIP, OSPF Junos OS 13.2X51-D25†
>
> On Fri, Mar 15, 2019 at 09:16:52PM +0000, Alex Martino wrote:
>
> > Hi,
> > Thank you all for sharing your expertise.
> > I am wondering if the EX4600 supports VXLAN as VXLAN-to-VLAN. I see many parts of the documentation which refers to VXLAN, such as https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.juniper.net%2Fdocumentation%2Fen_US%2Fjunos%2Ftopics%2Fconcept%2Fvxlan-constraints-qfx-series.html&data=02%7C01%7Cgiuliano%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&sdata=vZF%2F0rtiAsSfrCxsKXwVCHy9XfgFhrAbRsad7gVX4Zw%3D&reserved=0 but the datasheet does not mention VXLAN or EVPN anywhere.
> > Can people confirm if the EX4600 does support EVPN, SPB, TRILL, FABRIC or just VXLAN?
> > Thanks,
> > Alex
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Wednesday, March 13, 2019 6:37 PM, Andrey Kostin ankost at podolsk.ru wrote:
> >
> > > Hi guys,
> > > My 0.02: we use QFX5100 in VC and it's pretty solid. But. As
> > > mentioned, it's a single logical switch and by design it can't run
> > > members with different Junos versions that means downtime when you
> > > need to upgrade it. There is an ISSU but it has it's own caveats,
> > > so be prepared to afford some downtime for reboot. For example,
> > > there was an issue with QoS that required both Junos and host OS
> > > upgrade, so full reboot was inevitable in that case. Maybe I'm
> > > missing something, would like to hear about your best practice regarding VC high-availability.
> > > For simple L3 routing QFX5100 works well, but when I tried to run
> > > PIM on irb interfaces it behaved in strange way so I had to
> > > rollback and move PIM to the routers because didn't have time to investigate.
> > > We run VC with two members only. Tried EX4300 up to 8 members but
> > > it was very sluggish. Thankfully for us 96 ports is enough for ToR
> > > switch in the most of the cases.
> > > Regarding VCF, as per reading docs my understanding about it is
> > > that it's the same control plane as VC but with Spine-Leaf
> > > topology instead of ring. Because we use only 2 member VCs, there
> > > is no added value in it. Seems to me that VCF can't eliminate
> > > concern about reboot downtime and more switches you have more impact you can get.
> > > I'm interested to hear about experience of running EVPN/VXLAN,
> > > particularly with QFX10k as L3 gateway and QFX5k as spine/leaves.
> > > As per docs, it should be immune to any single switch downtime, so
> > > might be a candidate to really redundant design. As a downside I
> > > see the more complex configuration at least. Adding vlan means
> > > adding routing instance etc. There are also other questions, about
> > > convergence, scalability, how stable it is and code maturity.
> > > I'd be appreciated if somebody could share a feedback about
> > > operation of EVPN/VXLAN.
> > > Kind regards,
> > > Andrey
> > > Graham Brown писал 2019-03-12 15:40:
> > >
> > > > Hi Alex,
> > > > Just to add a little extra to what Charles has already said; The
> > > > EX4600 has been around for quite some time, whereas the QFX5110
> > > > is a much newer product, so the suggestion for the QFX over EX
> > > > could have been down to this.
> > > > Have a look at the datasheets for any additional benefits that
> > > > may suit one over the over, table sizes / port counts / protocol
> > > > support etc etc. If in doubt between the two, quote out the
> > > > solution for each variant and see how they best fit in terms of
> > > > features and CAPEX/OPEX for your needs.
> > > > Just to echo Charles, remember that a VC / VCF is one logical
> > > > switch from a control plane perspective, so if you have two ToR
> > > > per-rack, ensure that the two are not part of the same VC or
> > > > VCF. Then you can afford to lose a ToR / series of ToRs for
> > > > maintenance without breaking a sweat.
> > > > HTH,
> > > > Graham
> > > > Graham Brown
> > > > Twitter - @mountainrescuer
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Ftwitter.com%2F%23!%2Fmountainrescuer&data=02%7C01%7Cgiulian
> > > > o%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b07
> > > > 7bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&sdata=p
> > > > %2FL2jKVlXSVVAyRZGzhm82%2FNSjayi07P1KQueLptH2I%3D&reserved=0
> > > > LinkedIn
> > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> > > > www.linkedin.com%2Fin%2Fgrahamcbrown&data=02%7C01%7Cgiuliano
> > > > %40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077
> > > > bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&sdata=ei
> > > > Dxnf6j76g2tDkkb%2FjjBvum0SHqgqOaCskIvfcESZE%3D&reserved=0
> > > > On Wed, 13 Mar 2019 at 08:00, Anderson, Charles R cra at wpi.edu wrote:
> > > >
> > > > > Spanning Tree is rather frowned upon for new designs (for good
> > > > > reasons).
> > > > > Usually, if you have the ability to do stright L2 bridging,
> > > > > you can always do L3 on top of that. A routed Spine/Leaf
> > > > > design with EVPN-VXLAN overly for L2 extension might be a good
> > > > > candidate and is typically the answer given these days.
> > > > > I'm not a fan of proprietary fabric designs like VCF or
> > > > > MC-LAG. VC is okay, but I wouldn't use it across your entire
> > > > > set of racks because you are creating a single
> > > > > management/control plane as a single point of failure with
> > > > > shared fate for the entire 6 racks. If you must avoid L3 for
> > > > > some reason, I would create a L2 distribution layer VC out of
> > > > > a couple QFX5110s and dual-home independent Top Of Rack
> > > > > switches to that VC so each rack switch is separate. I've used
> > > > > 2-member VCs with QFX5100 without issue.
> > > > > Just be sure to enable "no-split-detection" if and only if you
> > > > > have exactly
> > > > > 2 members. Then interconnect the distribution VCs at each site
> > > > > with regular LAGs.
> > > > > On Tue, Mar 12, 2019 at 06:36:49PM +0000, Alex Martino via
> > > > > juniper-nsp
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > > I am seeking advices.
> > > > > > I am working on a L2/L3 DC setup. I have six racks spread
> > > > > > across two locations. I need about 20 ports of 10 Gbps (*2
> > > > > > for redundancy) ports per rack and a low bandwidth between
> > > > > > the two locations c.a. 1 Gbps.
> > > > > > Nothing
> > > > > > special here.
> > > > > > At first sight, the EX4600 seems like a perfect fit with
> > > > > > Virtual Chassis feature in each rack to avoid spanning tree across all racks.
> > > > > > Essentially,
> > > > > > I would imagine one VC cluster of 6 switches per location
> > > > > > and running spanning-tree for the two remote locations, where L3 is not possible.
> > > > > > I have been told to check the QFX5110 without much context,
> > > > > > other than not do VC but only VCF with QFXs. As such and
> > > > > > after doing my searches, my findings would suggest that the
> > > > > > EX4600 is a good candidate for VC but does not support VCF,
> > > > > > where the QFX5110 would be a good candidate for VCF but not
> > > > > > for VC (although the feature seems to be supported). And I
> > > > > > have been told to either use VC or VCF rather than MC-LAG.
> > > > > > Any suggestions?
> > > > > > Thanks,
> > > > > > Alex

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&data=02%7C01%7Cgiuliano%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&sdata=tXzEH2CyWtctCQQHV19lEq%2FaB%2FgYPL3HB6awoY%2FAxOY%3D&reserved=0

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta mensagem não for o seu destinatário, fica desde já notificado de que não poderá divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta mensagem não for o seu destinatário, fica desde já notificado de que não poderá divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.