Re: [j-nsp] EX4600 or QFX5110

[Richard McGovern via juniper-nsp]

I know this thread is quite old, but wanted to respond with some additional 
info.

As for a generic comparison, the EX4600 is exact same internal hardware (PFE) 
as a QFX5100, just different packaging, and potentially feature support.  In 
this case, feature support is "what is tested and officially supported", not 
what the switch is [potentially] capable of.  BTW, EX4600 base unit comes with 
40 x 1/10GE (48 capable), while the QFX5100/5110 base unit includes 48 x 1/10GE.

EX4600 is 'positioned' as a Campus/Ethernet 10GE capable Switch, while QFX5K 
series is positioned as a DC TOR Switch.  So from feature standpoint EX has 
Campus features, while QFX has DC feature set, in general.

There is a price difference between EX4600 and QFX as well.

As Chuck mentioned in one of his responses, Juniper has a product compare 
function:

https://apps.juniper.net/feature-explorer/compare-multiple.html

This link (hopefully works for all!) compares  EX4600/QFX5100/QFX5110 - 
https://apps.juniper.net/feature-explorer/compare-multiple.html#pkey=30504600%7CJunos%20OS%7C%7C30504601%7CJunos%20OS%7C%7C31705100%7CJunos%20OS%7C%7C31705101%7CJunos%20OS%7C%7C31705110%7CJunos%20OS=EX4600%7CEX4600-VC%7CQFX5100%7CQFX5100-VC%7CQFX5110=0.9677659894813813

QFX5110 DOES support VC, starting with 17.3R1.  Prior SW releases had the 
"capability" but not tested, so not "officially supported".  I "believe" 
QFX5110 does not supported mixed more with EX4300, while QFX5100 and EX4300 
mixed, supported for sure. 

EX4600 DOES NOT support VCF.  Besides ring design vs spine/leaf design for VC 
vs VCF, VCF also supports more members.  VCF supports 20 members max, VC is 10 
members max.

As for EVPN/VXLAN standpoint, Juniper is deploying this network architecture in 
a number of production customer sites.  EX4600 and QFX5100 both support L2 
VXLAN only (VLAN to VNI), while the QFX5110 supports L3 VXLAN, so both VLAN to 
VNI, and VNI to VNI, as well as IP (outside world) to VNI (VXLAN world). Please 
see my other correction email regarding QFX5110 support for IP/VLAN to VNI 
routing.  QFX5110 VC is NOT supported in EVPN/VXLAN use cases.  Should not be 
needed as ESI LAG allows dual or multiple connections to different TOR Leafs. 
QFX5100 does support VC with L2 VXLAN, but not highly recommended. 

MC-LAG is still supported on all of these products, although from a technology 
basis, Juniper (and many others) are moving away from recommending MC-LAG based 
designs, but instead EVPN/VXLAN (or EVPN/MPLS).  Major reasons are EVPN is 
Open, and all MC-LAG types are closed/proprietary. More importantly EVPN can 
scale horizontally (Virtual GW) while MC-LAG is always limited to 2 nodes or 
combinations of 2 nodes. At this time, Juniper is recommending the use of ESI 
LAG over MC-LAG.  VC as the choice is a completely different discussion, at 
least IMHO. 

Hopefully this may help all.

Rich


Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342


On 3/13/19, 1:37 PM, "Andrey Kostin"  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:
> 

Re: [j-nsp] EX4600 or QFX5110

[Tobias Heister]

Hi,

Am 18.03.2019 um 19:57 schrieb Gert Doering:

On Mon, Mar 18, 2019 at 06:50:26PM +, Giuliano C. Medalha wrote:

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


This is for QFX.

The original question was "what license is needed on EX4600 to get
EVPN with VXLAN"?


You will need the AFL. There is no EFL or PFL for EX4600.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/understanding_software_licenses.html#jd0e690

--
Kind Regards
Tobias Heister
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 or QFX5110

[Gert Doering]

Hi,

On Mon, Mar 18, 2019 at 06:50:26PM +, Giuliano C. Medalha wrote:
> 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

This is for QFX.

The original question was "what license is needed on EX4600 to get
EVPN with VXLAN"?

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 or QFX5110

[Giuliano C. Medalha]

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  On Behalf Of Alex 
Martino via juniper-nsp
Sent: segunda-feira, 18 de março de 2019 15:35
To: Anderson, Charles R 
Cc: juniper-nsp@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  wrote:

> Check feature explorer, select EX4600, latest Junos:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.
> juniper.net%2Ffeature-explorer%2Fdata=02%7C01%7Cgiuliano%40wztech
> .com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412
> b8ae504%7C1%7C0%7C636885310604161408sdata=osFWynJitRqbvJIPRQiZ9f5
> %2BL%2F3mzsjJg3vrcR9vGwI%3Dreserved=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 +, 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.htmldata=02%7C01%7Cgiuliano%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408sdata=vZF%2F0rtiAsSfrCxsKXwVCHy9XfgFhrAbRsad7gVX4Zw%3Dreserved=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 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 S

Re: [j-nsp] EX4600 or QFX5110

[Alex Martino via juniper-nsp]

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  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 +, 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 

Re: [j-nsp] EX4600 or QFX5110

[Anderson, Charles R]

There is also a Compare function where you can select two or more products and 
compare all the features side-by-side.

On Fri, Mar 15, 2019 at 10:14:55PM +, Anderson, Charles R 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 +, 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  
> > 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:
> > > >
> > > > > 

Re: [j-nsp] EX4600 or QFX5110

[Anderson, Charles R]

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 +, 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  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 

Re: [j-nsp] EX4600 or QFX5110

[Alex Martino via juniper-nsp]

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  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 +, 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 

Re: [j-nsp] EX4600 or QFX5110

[Andrey Kostin]

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 
LinkedIn 


On Wed, 13 Mar 2019 at 08:00, Anderson, Charles R  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 +, 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?
>
> 

Re: [j-nsp] EX4600 or QFX5110

[Graham Brown]

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 
LinkedIn 


On Wed, 13 Mar 2019 at 08:00, Anderson, Charles R  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 +, 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 or QFX5110

[Anderson, Charles R]

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 +, 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

[j-nsp] EX4600 or QFX5110

[Alex Martino via juniper-nsp]

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