Strange behavior on the Juniper MX240

Saku Ytti saku at ytti.fi
Fri May 6 08:09:51 UTC 2022


On Fri, 6 May 2022 at 10:59, Mark Tinka <mark at tinka.africa> wrote:

> These are the reasons why I was saying that while there may be some commands to move FIB allocations around, it's a lot of admin. because the DFZ is very dynamic, and FIB programming issues due to lack of slots that affect different prefixes in different ways can have you chasing your tail for weeks before you figure things out.
>
> I think doing this should be a short-term solution as you make plans to get newer hardware. As a long-term strategy, it will tax day-to-day operations.

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.




--
  ++ytti


More information about the NANOG mailing list