On Fri, Oct 14, 2022 at 01:50:55PM -0400, Jonathen Landis wrote: > On Thu, Oct 13, 2022 at 9:59 AM Saku Ytti via juniper-nsp > <[email protected]> wrote: > > I lost a fight with JTAC about whether the TCAM exhausting filter > should be a commit failure or not. > > In lieu of failing the commit, would it make sense for TCAM exhaustion to > trigger a system/chassis alarm? Or display a parameter in either the > operational command output, or even comments in the "show configuration" > output beside the filter. I don't recall if these logs repeat, or are only > shown after a commit operation, so I could see them getting missed as well.
An alarm is a good idea. The messages have not repeated in my scenario. They only appear on bootup, or when new hardware is inserted (e.g. insert an optic, Junos creates the interface and tries to program the filters and fails.) > > I think you're gonna need JTAC. Already engaged. The current theory is IP Source Guard filters are filling up the Dynamic filter slices, leaving no slices available to program a Class-of-Service Dynamic filter group. Also, it appears that when Junos was changed to support DHCP Snooping, Dynamic ARP Inspection, and IP Source Guard on trunk ports, even though trunk ports are in "trusted" mode by default, the switch is learning bindings on the trusted trunk ports (i.e. the uplink) and then *programming them into TCAM* at least for IPSG. If this is true, then Junos has created a situation where one cannot deploy IPSG effectively unless the switch can scale to the number of entries needed for an entire *VLAN* which may have thousands of hosts, rather than just the access ports on a single switch stack which would normally have only hundreds of hosts or less. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
