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 <ank...@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 c...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp