<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 5/6/22 10:09, Saku Ytti wrote:<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAAeewD_a4pB-Csj0XxM=M8mW_KY-uQCiM5aNjarGsmgmkmGNgQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
<font face="Tahoma">My response is to be taken in the context of
running a (large) network, and not the view of a single box.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
Mark.<br>
</font>
</body>
</html>