On 5/6/22 10:09, Saku Ytti wrote:

This seems like a strange position. The device has 16MB+16MB jtree
segments. The first is IP, the second is filters (Broadly).

OP has 16MB of first used.
OP has <5MB of second used.

What if the platform had originally shipped with a different balance
between filters and IP, and OP would have never hit this problem?

It is easy to see in many scenarios filter growth is negligible toi 0,
IP growth is not. OP would technically have 70% FIB growth left, so
DFZ of about 1.7M, which puts him in the year >2030 (potentially far
beyond, but at least that).

I view the recarving as fixing poorly dimensioned memory use. And had
it shipped with more sensible carving this discussion didn't exist,
and no one would suggest they are in any sort of tactical situation.
Saying there is a problem is logical fallacy, what if your platform
shipped carving of 1 prefix, and rest for filters, and you could do
50M+50M by config toggle. By your logic, this would be a tactical
temporary fix. No, we need to understand what we are doing, what is
the problem, what the solution is, we cannot categorically say this is
a tactical fix.

My response is to be taken in the context of running a (large) network, and not the view of a single box.

We have run into issues with platforms that have shipped with FIB's in favour of IPv4 and less for IPv6 and MPLS labels. Shifted around, you could give up whatever is left for IPv6 and ACL's to give more to IPv4, but you then end up losing native IPv6 scalability. And, of course, whatever other permutation you may think of that leaves you in a babysitting scenario for the protocol(s) assigned to peasantry.

When considered against the backdrop of a (large) network, one has to also consider the FIB requirements for the IGP, MPLS label space, e.t.c. And not to mention that IPv6 will require more FIB space than IPv4, both for the IGP and BGP.

I'd love to say people's ACL's are simple, but who knows what folk populate into every RADIUS PPPoE session that they think filters are a solution for?

So yes, it is important to understand the limitations (or capabilities) of your specific platform, but also look at the overall picture of your entire backbone, and get a full understanding of what re-juggling FIB memory may mean in the short and long term; of course, bearing in mind that for some operators, short-term could also be 10 years or more.

So all I'm saying is if there is a hack like this to help you delay moving to newer hardware, go for it. But know your hardware in the global context of your network, which will require a lot more attention to avoid getting caught out when you least expect it. I'd be remiss if I suggested that "implement, move on and forget" is a normal way to treat this hack.

Mark.