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 < [email protected]> wrote: > On Sep 20, 2022, at 1:36 PM, Chuck Anderson via juniper-nsp < > [email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
