[j-nsp] Outgrowing a QFX5100

[Mike Gonnason]

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 at puck.nether.net> wrote:

> On Sep 20, 2022, at 1:36 PM, Chuck Anderson via juniper-nsp <
> juniper-nsp at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>