On 2/6/24 18:53, Saku Ytti wrote:
Not just opinion, fact. If you see everything, ORR does nothing but adds cost.
You only need AddPath and ORR, when everything is too expensive, but
you still need good choices.
But even if you have resources to see all, you may not actually want
to have a lot of useless signalling and overhead, as it'll add
convergence time and risk of encouraging rare bugs to surface. In the
case where I deployed it, having all was not realistic possibly, in
that, having all would mean network upgrade cycle is determined when
enough peers are added, causing RIB scale to demand triggering full
upgrade cycle, despite not selling the ports already paid.
You shouldn't need to upgrade your boxes, because your RIB/FIB doesn't
scale, you should only need to upgrade your boxes, if you don't have
holes to stick paying fiber into.
I agree.
We started with 6 paths to see how far the network could go, and how
well ECMP would work across customers who connected to us in multiple
cities/countries with the same AS. That was exceedingly successful and
customers were very happy that they could increase their capacity
through multiple, multi-site links, without paying anything extra and
improving performance all around.
Same for peers.
But yes, it does cost a lot of control plane for anything less than 32GB
on the MX. The MX204 played well if you unleased it's "hidden memory"
hack :-).
This was not a massive issue for the RR's which were running on CSR1000v
(now replaced with Cat8000v). But certainly, it did test the 16GB
Juniper RE's we had.
The next step, before I left, was to work on how many paths we can
reduce to from 6 without losing the gains we had made for our customers
and peers. That would have lowered pressure on the control plane, but
not sure how it would have impacted the improvement in multi-site load
balancing.
Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
