[j-nsp] EX4600 or QFX5110

[Alex Martino]

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://apps.juniper.net/feature-explorer/
>
> 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://www.juniper.net/documentation/en_US/junos/topics/concept/vxlan-constraints-qfx-series.html 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://twitter.com/#!/mountainrescuer
> > > > LinkedIn http://www.linkedin.com/in/grahamcbrown
> > > > 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