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. 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 <+16039695549> > e: [email protected] > tg: jasonrokeach <https://t.me/jasonrokeach> > > Sent with ProtonMail <https://pr.tn/ref/QKTX33CHXPK0> secure email. Get > my PGP Public Key > <https://gist.githubusercontent.com/jrokeach/3afd92bc82dc72bbc8f71214c02977e8/raw/63d4835670c42e809818c02f7e368adabb16a61a/publickey.ja...@rokea.ch-6753531f6f093f4facf1bf5289624a56c5271cf1.asc> > . > > ------- 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 > <https://teams.microsoft.com/l/chat/0/[email protected]> > > >
