Well, in fact I rather meant a different way of setting the role based costs rather than treating real link bandwidth as 1/cost.
>For LAG you should set minimum links to a number which allows you to >carry traffic you need. OK, good point. Though I am not sure that all vendors allow to do it this way. Basically I agree with your concept, but it's worth to note that you assume the current traffic as "given" and that links can't be saturated. This assumption only holds when there is a great number of short-lived low bandwidth sessions, like residential broadband subscribers traffic, and enough bandwidth to accommodate all the traffic. In this case, a saturated link and consequent drops is equivalent to "no service". However in some environments (many enterprise networks, some DCs) hight traffic periods are observed during backups/replications/etc. This normally implies relatively low number of high bandwidth long-lasting TCP flows. Being forwarded through a saturated link, TCP slows down and traffic "adapts" to network conditions. Your backup will take 4 hours instead of 2. This is where real bandwidth might be a meaningful metric. If I understand correctly, it was supposed to work like this in the era when you always had more traffic than available bandwidth. 25 окт. 2017 г. 10:50 ПП пользователь "Saku Ytti" <s...@ytti.fi> написал: > I disagree. Either traffic fits or it does not fit on SPT path, > bandwidth is irrelevant. > > For LAG you should set minimum links to a number which allows you to > carry traffic you need. > > Ideally you have capacity redundancy on SPT level, if best path goes > down, you know redundant path, and you know it can carry 100% of > demand. If this is something you cannot commercially promise, you need > strategic TE to move traffic on next-best-path when SPT is full. > > > On 25 October 2017 at 23:25, Pavel Lunin <plu...@gmail.com> wrote: > > Reference bandwidth might however be useful for lags, when you may want > to > > lower the cost of a link if some members go down (though I prefer ECMP in > > the core for most cases). > > > > And you can combine the role/latency approach with automatic reference > > bandwidth-based cost, if you configure 'bandwidth' parameter on the > > interfaces instead of IGP cost. > > > > 25 окт. 2017 г. 10:08 ПП пользователь "Saku Ytti" <s...@ytti.fi> > написал: > > > >> Hey, > >> > >> This only matters if you are letting system assign metric > >> automatically based on bandwidth. Whole notion of preferring > >> interfaces with most bandwidth is fundamentally broken. If you are > >> using this design, you might as well assign same number to every > >> interface and use strict hop count. > >> > >> On 25 October 2017 at 22:41, Luis Balbinot <l...@luisbalbinot.com> > wrote: > >> > Never underestimate your reference-bandwidth! > >> > > >> > We recently set all our routers to 1000g (1 Tbps) and it was not a > >> > trivial task. And now I feel like I'm going to regret that in a couple > >> > years. Even if you work with smaller circuits, having larger numbers > >> > will give you more range to play around. > >> > > >> > Luis > >> > > >> > On Tue, Oct 24, 2017 at 8:50 AM, Alexander Dube <n...@layerwerks.net> > >> > wrote: > >> >> Hello, > >> >> > >> >> 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? > >> >> > >> >> Kind regards > >> >> Alex > >> >> _______________________________________________ > >> >> juniper-nsp mailing list juniper-nsp@puck.nether.net > >> >> https://puck.nether.net/mailman/listinfo/juniper-nsp > >> > _______________________________________________ > >> > juniper-nsp mailing list juniper-nsp@puck.nether.net > >> > https://puck.nether.net/mailman/listinfo/juniper-nsp > >> > >> > >> > >> -- > >> ++ytti > >> _______________________________________________ > >> juniper-nsp mailing list juniper-nsp@puck.nether.net > >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > ++ytti > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp