Mailing List Archive

EX4600 or QFX5110
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
Re: EX4600 or QFX5110 [ In reply to ]
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
Re: EX4600 or QFX5110 [ In reply to ]
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@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
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: EX4600 or QFX5110 [ In reply to ]
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@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
>>
> _______________________________________________
> 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: EX4600 or QFX5110 [ In reply to ]
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@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@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
> >
> > 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: EX4600 or QFX5110 [ In reply to ]
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@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@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
Re: EX4600 or QFX5110 [ In reply to ]
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 +0000, 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 +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@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@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
Re: EX4600 or QFX5110 [ In reply to ]
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@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@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@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
Re: EX4600 or QFX5110 [ In reply to ]
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@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@wpi.edu>
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 <cra@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&amp;data=02%7C01%7Cgiuliano%40wztech
> .com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412
> b8ae504%7C1%7C0%7C636885310604161408&amp;sdata=osFWynJitRqbvJIPRQiZ9f5
> %2BL%2F3mzsjJg3vrcR9vGwI%3D&amp;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&amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&amp;sdata=vZF%2F0rtiAsSfrCxsKXwVCHy9XfgFhrAbRsad7gVX4Zw%3D&amp;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@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&amp;data=02%7C01%7Cgiulian
> > > > o%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b07
> > > > 7bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&amp;sdata=p
> > > > %2FL2jKVlXSVVAyRZGzhm82%2FNSjayi07P1KQueLptH2I%3D&amp;reserved=0
> > > > LinkedIn
> > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> > > > www.linkedin.com%2Fin%2Fgrahamcbrown&amp;data=02%7C01%7Cgiuliano
> > > > %40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077
> > > > bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&amp;sdata=ei
> > > > Dxnf6j76g2tDkkb%2FjjBvum0SHqgqOaCskIvfcESZE%3D&amp;reserved=0
> > > > On Wed, 13 Mar 2019 at 08:00, Anderson, Charles R cra@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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7C470b4953c00e459ab04a08d6abd0cbce%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C636885310604161408&amp;sdata=tXzEH2CyWtctCQQHV19lEq%2FaB%2FgYPL3HB6awoY%2FAxOY%3D&amp;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.

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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: EX4600 or QFX5110 [ In reply to ]
Hi,

On Mon, Mar 18, 2019 at 06:50:26PM +0000, 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 gert@greenie.muc.de
Re: EX4600 or QFX5110 [ In reply to ]
Hi,

Am 18.03.2019 um 19:57 schrieb Gert Doering:
> On Mon, Mar 18, 2019 at 06:50:26PM +0000, 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: EX4600 or QFX5110 [ In reply to ]
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&VC/QFX5100&VC/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&platforms=EX4600%7CEX4600-VC%7CQFX5100%7CQFX5100-VC%7CQFX5110&stat=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" <ankost@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://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_-23-21_mountainrescuer&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=cTV0pAFqsQD-PJn397s8yFxrYi5_Td3BXqYmWl0_Gcs&s=JeCSPPwIhrNqfuNXYtdQkRe8e9n9iJs0QJwHMatRPAc&e=>
> LinkedIn <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_grahamcbrown&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=cTV0pAFqsQD-PJn397s8yFxrYi5_Td3BXqYmWl0_Gcs&s=J-tTcOhEN7cue_PvsqqE_C8GFGuxCylOHYtAX0n35kg&e=>
>
>
>> On Wed, 13 Mar 2019 at 08:00, Anderson, Charles R <cra@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://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=cTV0pAFqsQD-PJn397s8yFxrYi5_Td3BXqYmWl0_Gcs&s=b8z41JkZEQOyETTB1383fKUcodrj2NyfQ6FrpfJnW-c&e=
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=cTV0pAFqsQD-PJn397s8yFxrYi5_Td3BXqYmWl0_Gcs&s=b8z41JkZEQOyETTB1383fKUcodrj2NyfQ6FrpfJnW-c&e=




_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp