[j-nsp] Best practice for igp/bgp metrics

Saku Ytti saku at ytti.fi
Wed Oct 25 14:47:10 EDT 2017


Hey Alexander,

> we're redesigning our backbone with multiple datacenters and pops currently and looking for a best practice or a recommendation for configuring the metrics.
> What we have for now is a full meshed backbone with underlaying isis. IBGP exports routes without any metric. LSP are in loose mode and are using isis metric for path calculation.
>
> Do you have a recommendation for metrics/te ( isis and bgp ) to have some values like path lengh ( kilometers ), bandwidth, maybe latency, etc inside of path calculation?

Length and latency are same thing.


There are to principal IGP designs. One would be role based, where
metric is static depending on roles of A and B end of connection. Such
as P-P, P-PE, PE-PE. This strategy is well suited for networks where
hop count is similar to geographic distance or where network spans so
short geographic distance that it is not relevant.
This is very simple, requires almost 0 maintenance. If this works for
your topology, I high recommend it.

Another strategy would be to encode latency cost to link, and always
choose lowest latency path. Hybrid could penalise for example P-PE
links, but otherwise use mostly latency on P-P, and document
exceptions. Particularly if you rely on strategic TE as opposed to
tactical TE,  latency cost makes lot of sense, as then TE can find
next-lowest-latency path when you are out of capacity, and if you keep
monitoring paths which are not on SPT, you will know where you need to
buy more capacity.
If your network spans large geographic areas with lot of redundancy,
you will need this or hybrid, role based alone will cause too many
exceptions to document.

Luckily SPF is super simple to implement, and I think there is even
free webtool for playing with costs.





-- 
  ++ytti


More information about the juniper-nsp mailing list