Mailing List Archive

On Fri, 16 Sept 2022 at 22:12, Jason Healy via juniper-nsp
<juniper-nsp@puck.nether.net> wrote:

Hey Jason,

> My question is, what would be the logical "step up" from the qfx on a small network? I'm thinking the MX240 as it's the smallest router that has redundant REs. However, I have no experience with the router family (we're all EX/QFX). I'd consider a newer member of the QFX family, but I'd need to know I'm not going to bump into a bunch of weird "unsupported on this platform" issues.

Yes. I don't immediately cannot think of any feature that isn't
supported on MX that is supported on EX/QFX.

Broadly speaking if you are not cost-sensitive, and you don't need the
density, always buy an NPU box such as MX, because it's inherently
more feature complete.

Pipeline boxes like EX/QFX make sense if you are cost sensitive or
need high density and can answer what your requirements are ahead of
time and run a field trial against those specific requirements. In my
experience for access providers your requirements are not a knowable
variable, because you will introduce a new product during the life
cycle of a device, therefore you will be carrying additional risk with
pipeline compared to NPU. If you're a cloudy shop or incumbent telco
you likely can have a frozen set of requirements that are knowable
a-priori, which supports pipeline use-case.

> I'm fine with EOL/aftermarket equipment; we've got a pretty traditional layer-2 spoke-and-hub setup with layer-3 for IRB and a default route to our ISP (no VXLAN, tunneling, etc). Our campus isn't growing so capacity isn't a huge issue (we're 1g/10g uplinks everywhere, and the 10g aren't close to saturation). I *might* want 40g as a handoff to an aggregation layer, but that's about it. Thus, I'm OK with a relative lack of new features.

Your problem is the slow rate interfaces and getting reasonable
support for them. With MX if you are buying from a channel for chassis
boxes you should be only buying LC9600, which is 24x400GE, another
alternative is fixed config MX304. Both may be highly unsatisfactory
to you in the front-plate. ACX portfolio may have some middle-ground
to you.


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

Hi Jason,

Do you have any more details about what limitations you are encountering on
the QFX? Is it hardware related or software?

You can use the feature explorer to see what is supported:
https://apps.juniper.net/feature-explorer/feature-family-info.html?ffKey=102&familyName=Authentication%20and%20Access%20Control

MX will generally support more features or be more capacity than the
EX/QFX, but as you can see 802.1x is a wide ranging topic with plenty of
corner-case features.

As for a "step-up", it is really just a different use case and
requirements. The QFX is a solid switching performer, with plenty of
support for modern data center tech. I have deployed a bunch of QFX5120 in
a EVPN config but also have some in VC or standalone, however none doing
802.1x.

-Mike Gonnason




On Fri, Sep 16, 2022 at 12:12 PM Jason Healy via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Looking for a little wisdom from the list.
>
> We're a small school campus that's been running a QFX 5100 as our core
> switch/router for several years. It's been a good piece of equipment but
> we continue to hit weird limitations and I'm wondering if we're pushing the
> platform too hard.
>
> My question is, what would be the logical "step up" from the qfx on a
> small network? I'm thinking the MX240 as it's the smallest router that has
> redundant REs. However, I have no experience with the router family (we're
> all EX/QFX). I'd consider a newer member of the QFX family, but I'd need
> to know I'm not going to bump into a bunch of weird "unsupported on this
> platform" issues.
>
> Does the MX line handle all the layer-2 stuff that the QFX has, like DHCP
> snooping, vlan firewall filters, or even dot1x? Coming from the switching
> family, I wasn't sure how prevalent those features are on the layer-3
> equipment, or if they're configured in some totally different way.
>
> I'm fine with EOL/aftermarket equipment; we've got a pretty traditional
> layer-2 spoke-and-hub setup with layer-3 for IRB and a default route to our
> ISP (no VXLAN, tunneling, etc). Our campus isn't growing so capacity isn't
> a huge issue (we're 1g/10g uplinks everywhere, and the 10g aren't close to
> saturation). I *might* want 40g as a handoff to an aggregation layer, but
> that's about it. Thus, I'm OK with a relative lack of new features.
>
> Thanks,
>
> Jason
> _______________________________________________
> 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

On Sep 20, 2022, at 12:57 AM, Mike Gonnason <gonnason@gmail.com> wrote:
> Do you have any more details about what limitations you are encountering on the QFX? Is it hardware related or software?

The example that spurred my email was DDOS protection on the QFX. We're getting lots of L3NHOP errors (still, I wrote to the list a while back about it) and have been trying to track them down. On some platforms you can capture the flows causing the DDOS violation, but not the QFX. We've been forced to perform random packet captures in the hope of finding the traffic on the right interface.

Another bug causes DHCP relay to fail when an ACL is applied on an interface, even if the filter explicitly permits DHCP traffic.

The chipset has a "feature" where IPv6 counters aren't incremented at all (they claim this is "working as designed").

Filter-based forwarding is not supported on IPv6 (the documentation on this has been corrected, but only after we escalated our case through ATAC).

There's a bug where setting a 0.0.0.0/0 match in an inet firewall filter prevents ipv6 traffic from passing (incorrect hardware programming). We have to use ether-type instead in order to hack around it.

There are limitations on egress filters that don't appear to apply on other platforms.

Many of these issues were not stated in the official documentation, and some still aren't (you have to search KB articles to find the limitations). That makes product evaluation very difficult and is part of why I was asking the list.

Most of our problems seem to center around L3 stuff (ACLs, forwarding, etc), which I why I asked about the router line. It seems like I'm asking "too much" of the QFX as a core router, though it does pretty well as a switch. The full router line is overkill for me (I don't need a full table, for example), but if it means some of these other features will actually work as designed, it might be worth it.

The mx304 is an interesting option, as is the ACX line. Maybe one of the newer QFX models will fix some issues that the broadcom chipset had, but I'll need to test the heck out of that first.

Thanks,

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

Why would you want DHCP snooping or dot1x on a campus core router? Those functions are typically implemented at the access layer switches connected directly to end users.

On Fri, Sep 16, 2022 at 03:11:22PM -0400, Jason Healy via juniper-nsp wrote:
> We're a small school campus that's been running a QFX 5100 as our core switch/router for several years. It's been a good piece of equipment but we continue to hit weird limitations and I'm wondering if we're pushing the platform too hard.
>
> Does the MX line handle all the layer-2 stuff that the QFX has, like DHCP snooping, vlan firewall filters, or even dot1x? Coming from the switching family, I wasn't sure how prevalent those features are on the layer-3 equipment, or if they're configured in some totally different way.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Sep 20, 2022, at 1:36 PM, Chuck Anderson via juniper-nsp <juniper-nsp@puck.nether.net> wrote:
> Why would you want DHCP snooping or dot1x on a campus core router? Those functions are typically implemented at the access layer switches connected directly to end users.

My understanding is that DHCP relay only works on layer-3 devices; all our edge switches are layer-2 (the core trunks VLANs to the edge switches; all inter-VLAN traffic is routed on the core only). Thus, the core does DHCP relay.

dot1x is primarily done on our edge switches as you describe. However, we occasionally connect dumb layer 2 switches for very small closets over fiber (we're a small enough campus that all our buildings are cabled directly to the qfx), so it's nice to have the option to have a core device provide the same "edge" dot1x functionality for those devices. That one isn't as big of a deal; I could use Juniper switch with dot1x as an aggregation device if the core won't handle it.

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

Obviously I lack context/scale and all that, so please ignore if
unwarranted.

What if you broke your buildings up into separate L3 domains: have an EX at
each building that does the "access" L3 features, and rely on the QFX5100
as your L3 core. Still doesn't solve your FBF-IPv6 though. Hmmm

Pros:
Spread the features across platforms
Reduce broadcast failure/domain
Cons:
More subnets and all that entails
Maybe more licensing?
Limits your deployment of simple L2 switches

Then you wouldn't need a spendy MX to do it all in one box.

-Mike Gonnason

On Wed, Sep 21, 2022 at 7:00 AM Jason Healy via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> On Sep 20, 2022, at 1:36 PM, Chuck Anderson via juniper-nsp <
> juniper-nsp@puck.nether.net> wrote:
> > Why would you want DHCP snooping or dot1x on a campus core router? Those
> functions are typically implemented at the access layer switches connected
> directly to end users.
>
> My understanding is that DHCP relay only works on layer-3 devices; all our
> edge switches are layer-2 (the core trunks VLANs to the edge switches; all
> inter-VLAN traffic is routed on the core only). Thus, the core does DHCP
> relay.
>
> dot1x is primarily done on our edge switches as you describe. However, we
> occasionally connect dumb layer 2 switches for very small closets over
> fiber (we're a small enough campus that all our buildings are cabled
> directly to the qfx), so it's nice to have the option to have a core device
> provide the same "edge" dot1x functionality for those devices. That one
> isn't as big of a deal; I could use Juniper switch with dot1x as an
> aggregation device if the core won't handle it.
>
> Jason
> _______________________________________________
> 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