2

Can someone please explain is it a good practice to change RSVP bandwidth value of an interface?

We have two bundle links between R1 and R2 namely ae13 and ae22 . Both R1 and R2 are Juniper MX series. AE13 bundle link has 16 x 10G member links and has been running quite long.

We recently add 1 x 100G link between R1 and R2. We made it a part of bundle link AE22. We also hard code the IS-IS cost values of BOTH Bundle links to be 10 to enable load balancing (ECMP).

On Both bundle links , AE13 and AE22 , RSVP , MPLS , IS-IS , Micro BFD are running.

But when we run command 'show rsvp interface' on R1/R2 , it shows more bandwidth reservations (almost all) on previous bundle link (AE13) while very few reservations (below 10) were on new bundle link AE22. By default RSVP bandwidth value of AE13 was showing to be 160 Gbps (as it as 16 x 10G Links) while for AE22 it was showing to be 100 Gbps.

When we change RSVP bandwidth value of AE13 (using command 'set protocols rsvp interface ae13.3 bandwidth 100g') we saw 'active rsvp' decreased on both AE13 and AE22.

*************Before Configuring bandwidth value of AE13*********************

RSVP interface: 6 active
                          Active  Subscr- Static      Available   Reserved    Highwater
Interface          State  resv    iption  BW          BW          BW          mark
ae0.3                  Up      41   100%  200Gbps     199.2Gbps   800Mbps     51.3225Gbps
ae1.3                  Up      13   100%  90Gbps      87.5431Gbps 2.4569Gbps  26.1529Gbps
ae13.3                 Up     101   100%  140Gbps     126.788Gbps 13.2123Gbps 101.843Gbps
ae22.3                 Up      34   100%  100Gbps     72.3477Gbps 27.6522Gbps 27.6522Gbps
ae28.3                 Up     178   100%  170Gbps     133.481Gbps 36.5188Gbps 130.511Gbps
ae8.3                  Up     147   100%  170Gbps     145.125Gbps 24.8747Gbps 136.584Gbps

***************After configuring bandwidth value of AE13********************

RSVP interface: 6 active
                          Active  Subscr- Static      Available   Reserved    Highwater
Interface          State  resv    iption  BW          BW          BW          mark
ae0.3                  Up      39   100%  200Gbps     199.2Gbps   800Mbps     51.3225Gbps
ae1.3                  Up      14   100%  90Gbps      88.7145Gbps 1.28549Gbps 26.1529Gbps
ae13.3                 Up      93   100%  100Gbps     96.0119Gbps 3.98813Gbps 101.843Gbps
ae22.3                 Up      19   100%  100Gbps     85.975Gbps  14.025Gbps  27.6522Gbps
ae28.3                 Up     177   100%  170Gbps     141.339Gbps 28.6607Gbps 130.511Gbps
ae8.3                  Up     147   100%  180Gbps     158.668Gbps 21.3322Gbps 136.584Gbps

So is it a good practice to change RSVP bandwidth value of an interface? What are its shortcomings / drawbacks / after effects if there are any?

Thank you very much.

1 Answer 1

3

Firstly, there looks to be something wrong with ae13 - if you have 16x 10G interfaces attached to it, you should have an RSVP interface bandwidth of 160Gbps, not 130Gbps as per your output?

So is it a good practice to change RSVP bandwidth value of an interface?

There is nothing inherently good or bad about manually overriding the speed of an interface in RSVP - it is a perfectly fine way to limit the bandwidth of any LSPs that run across it.
We have used this quite successfully in environments where the link is attached to sub-rate services (eg: a 400Mbps microwave service attached on a 1G port) and we need to override the reported interface speed.

What are its shortcomings / drawbacks / after effects if there are any?

As you can see from your output, the after-effects are that there is now 30G (or 60G as per issue above) of capacity across that ae13 link that will never be available for RSVP LSPs.

When you changed the speed value, RSVP would have re-run it's CSPF algorithm and re-signalled all your LSPs accordingly.

Depending on the bandwidth of each LSP and the order they were re-signalled in (and any priorities you have configured on them) would determine which links they flow across.

The number of Active reservations on each link is not really relevant - it's the bandwidth in use that is being distributed.

7
  • @Benjamin.Thank you Benjamin for providing answer. For you first question , ae13 has 16 x 10G links but available bandwidth shown by rsvp was 140 Gbps because at the time of writing this query 2 x 10G links [member of ae13] between R1 and R2 were down. Hence the available bandwidth shown by R1 was 140 Gbps instead of 160 Gbps
    – Nabeel
    Commented Mar 21, 2019 at 18:12
  • @Benjamin.So you mentioned that 'the after-effects are that there is now 30G (or 60G as per issue above) of capacity across that ae13 link that will never be available for RSVP LSPs' , this means that R1 and R2 thinks that now available bandwidth of ae13 is 100 Gbps (as they would advertise this in Traffic engineering database to rest of network via IS-IS TLVs) and thus we can say 60 Gbps of bandwidth (which in fact is there physically there are 16 x 10Gbps) would not be usable in the network
    – Nabeel
    Commented Mar 21, 2019 at 18:12
  • @Benjamin.Thus what I think is to revert back by removing the 100Gbps bandwidth from ae13 so that 60 Gbps would be reserved in the network as wel
    – Nabeel
    Commented Mar 21, 2019 at 18:13
  • @Benjamin.Furthermore if the links ae13 and ae22 gets 90% utilized and there needs to make more reservations against some LSPs (due to increase traffic flow) , this means R1 and R2 would signal that they can't reserve more bandwidth because they are thinking both links ae13 and ae22 are 100 Gbps and both are 95% utilized whereas ae13 has physical capacity of 60 Gbps !!
    – Nabeel
    Commented Mar 21, 2019 at 18:13
  • @Benjamin.It would be very nice of you if you please read comments so that we can conclude this.
    – Nabeel
    Commented Mar 21, 2019 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.