Auto-Bandwidth
Load mpls.te.base.config.with.ospf.cfg
Configure a TE tunnel from CSR8 to XR11, and from XR11 to CSR8. Use a dynamic path option. Ensure the routers install a path to the destination through the TE tunnel.
Configure auto-bandwidth on both tunnels using the following parameters:
Use the lowest application timer
Set the min BW as 10 kbps and max as 50 mbps
Set the initial bandwidth as 5 kbps
Answer
Explanation
Auto-Bandwidth is a feature that automatically adjusts the signalled-bandwidth of a TE tunnel based on how much traffic is actually being forwarded out the tunnel. The idea is that, in times of low utilization, less bandwidth is reserved in the network, allowing for more LSPs to be created. However, if a tunnel starts utilizing a lot of bandwidth, the actual RSVP control-plane signalled-bandwidth matches the data plane bandwidth. This allows higher priority tunnels to take precendence in times of congestion.
Auto-Bandwidth essentially works by just watching the output traffic rate of the tunnel over a given amount of time (the collection interval). The highest bandwidth usage seen is configured on the TE tunnel every application interval. You will literally see the signalled-bandwidth on the TE change in the running config for IOS-XE.
The collection frequency is how often the output rate is inspected. This is 5 minutes and does not appear to be configurable. The application frequency is how often to take the highest value seen from every collection period, and apply it to the TE tunnel’s signalled-bandwidth. This is by default 24 hours but can be adjusted as low as 5 minutes.
Besides setting the min and max values, and the application frequency interval, as we did in this lab, you can also set the adjustment-threshold, which gives a percentage threshold that bandwidth on the tunnel must exceed before making a change. You can also set collect-bw which simply collects the bandwidth information without actually making a change to the tunnel.
You can also configure an overflow threshold which triggers an early bandwidth update if a percentage threshold is exceeded. On IOS-XE you use the following command, where X is the number of consecutive samples exceeding the threshold, and Y is the percent threshold which triggers the early bandwidth update.
On IOS-XR, the syntax is just reversed:
IOS-XR also gives us an underflow parameter we can use, which allows an early bandwidth update if the bandwidth falls below a given percentage threshold.
Verification
After running a full size ping for several minutes on each router, we can see that the auto-bw feature manually applied a signalled-bw to the tunnel.
Using the familiar show mpls traffic-eng tunnels command, we can see some statistics about auto-bw:
300 is the application frequency (in seconds). This is how often the signalled-bandwidth is applied to the TE tunnel.
225 is the time remaining (in seconds) until the application of the bandwidth to the TE tunnel is triggered.
191 is the current value of the bandwidth requested by the TE tunnel
We can also see this on XR11. However, the bandwidth does not appear to be literally applied to the tunnel in the show run config.
However, we can see that even though the configured bandwidth is 5kbps, the actual requested bandwidth is currently 760 kbps:
Using Auto-BW with path option lockdown
On IOS-XE, if you have a path-option in effect that has the lockdown keyword, the path is still re-signalled every time the auto-bw feature applies the new bandwidth.
On IOS-XR, the bandwidth is not applied because of the lockdown keyword on the path-option. If we lockdown the dynamic path-option, notice that the Auto-bw section says “no BW application because Tunnel is in lockdown”:
Instead you would need to apply the bandwidth to the TE tunnel using a manual exec command:
Now we see the highest-seen BW is actually applied to the tunnel, even though it is in lockdown. Note that I had to do this twice. The first time, it only applies the minimum bandwidth, (10 kbps in my case). The following time, it applies what it has seen as the highest bandwidth in the previous collection period.
Last updated
