On Wed, Oct 18, 2023 at 7:38 AM Tom Beecher <[email protected]> wrote: > > Auto-bandwidth won't help here if the bandwidth reduction is 'silent' as > stated in the first message. A 1G interface , as far as RSVP is concerned, is > a 1G interface, even if radio interference across it means it's effectively a > 500M link. > > Theoretically, you could have some sort of automation in place that > dynamically detected available bandwidth over the path, and then re-configure > the RSVP configured bandwidth for the interface to reflect that so the next > auto-bandwidth calculation would take that into account. However, the > efficacy of this would depend on the length of the RF disruption that caused > BW reduction. Assuming your detection time was near instant ( which is saying > something ) ,you'd still have to have very aggressive auto-BW timers to > adjust to it quickly enough, and there are other downsides to doing that.
I have always been curious as to what extent RED is deployed on junOS? (in for example mpls networks) I had had some pretty bad results with some mx gear out of my control, a while back, couldn't fix it, slapped cake on it, grumpily blogged, moved on. https://blog.cerowrt.org/post/juniper/ What kind of latency swings are observable today? > > On Wed, Oct 18, 2023 at 10:16 AM Jason R. Rokeach via NANOG <[email protected]> > wrote: >> >> Hi Adam, >> This sounds like a use case for MPLS-TE with TWAMP-Light. TWAMP-Light >> handles the latency concern and can encode your measured latency in IS-IS. >> Juniper docs: >> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/topic-map/enable-link-delay-advertise-in-is-is.html. >> The configuration in steps 5 and 7 is all thats required (from a config >> standpoint) to get the data into IS-IS. >> You then, when building an RSVP LSP, would specify a constraint for the >> latency. Alternatively you can route by latency on its own by setting the >> metric to latency, but as you've alluded to, this can be pretty dangerous in >> environments with mixed bandwidth availability. >> >> The other option afforded for the second point on traffic balance is to use >> auto-bandwidth >> (https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/basic-lsp-configurtion.html#id-configuring-automatic-bandwidth-allocation-for-lsps >> - see also >> https://archive.nanog.org/sites/default/files/tues.general.steenbergen.autobandwidth.30.pdf). >> >> Other vendors support this as well. >> SR supports the use of TWAMP-Light as well if you prefer that over RSVP, but >> it doesn't support auto-bandwidth. >> >> _______________________ >> Jason R. Rokeach >> m: 603.969.5549 >> e: [email protected] >> tg: jasonrokeach >> >> Sent with ProtonMail secure email. Get my PGP Public Key. >> >> ------- Original Message ------- >> On Wednesday, October 18th, 2023 at 9:13 AM, Adam Thompson - athompson at >> merlin.mb.ca <[email protected]> wrote: >> >> Using a mix of Juniper hardware... >> >> Network provides VPLS to customer, over MPLS (obviously) in a >> dual-redundant-ring radio topology. Each site is connected to one or more >> neighbors, generally with two radios, in two different bands, to *each* >> neighbor. So an ordinary node might have 4 radios, 2 pointing in each >> direction. >> >> Every single radio link has different bandwidth, different latency, and >> different interference characteristics. >> >> These radio links do run at 100% capacity at least some of the time. >> >> It's possible to set each link's relative cost in OSPF or IS-IS, of course, >> but I haven't found a way to make the router react to latency changes on one >> link or the other. (Right now, I think costs are set equal so traffic will >> use both links.) This means interference in one band invisibly diminishes >> the Ethernet bandwidth available and silently increases the latency on that >> link, sometimes dramatically. This seems to do interestingly unpleasant >> things to the client's flows. >> >> It's generally true that one band will be much more severely affected than >> the other, in any interference event. Before anyone asks, I'm told the >> network is a mixture of licensed and unlicensed bands, that's not changing >> anytime soon. >> >> In a perfect world, I'd like the routers to dynamically adjust traffic >> balance, but even just temporarily halting use of the impaired link would be >> helpful (or so I believe right now, at least). >> >> Is this a pipe dream? I'm not seeing anything in JunOS that could >> accomplish this... I'm not even sure if a mesh protocol could handle dual >> active links like this? >> >> Ideas, comments, etc. all appreciated. >> >> Also, I'm not the direct operator of use network. I'm involved, but mostly >> just trying to help them find better solutions. Nor am I an MPLS expert, as >> is obvious here. >> >> Thanks, >> -Adam >> >> Adam Thompson >> >> Consultant, Infrastructure Services >> >> MERLIN >> >> 100 - 135 Innovation Drive >> >> Winnipeg, MB R3T 6A8 >> >> (204) 977-6824 or 1-800-430-6404 (MB only) >> >> https://www.merlin.mb.ca >> >> Chat with me on Teams >> >> -- Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html Dave Täht CSO, LibreQos
