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
> 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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
