Manual:TE tunnel auto bandwidth: Difference between revisions
m format |
No edit summary |
||
Line 137: | Line 137: | ||
actual bandwidth must be allowed to fluctuate to some extent - e.g. if <b>bandwidth-limit</b> will be configured to 100% (this effectively means that rate will be limited to the bandwidth reserved for tunnel), tunnel | actual bandwidth must be allowed to fluctuate to some extent - e.g. if <b>bandwidth-limit</b> will be configured to 100% (this effectively means that rate will be limited to the bandwidth reserved for tunnel), tunnel | ||
will not have any chance to increase its reservation. Therefore either <b>bandwidth-limit</b> should be configured to more than 100%, or <b>auto-bandwidth-reserve</b> should be configured to more than 0%. | will not have any chance to increase its reservation. Therefore either <b>bandwidth-limit</b> should be configured to more than 100%, or <b>auto-bandwidth-reserve</b> should be configured to more than 0%. | ||
[[Category:Manual]] |
Revision as of 14:24, 8 March 2010
Overview
By default MPLS TE tunnels do not apply any rate limitation on traffic that gets sent over tunnel. That way "bandwidth" settings for MPLS TE enabled interfaces and TE tunnels are only used for reservation accounting. There are also no means to adjust bandwidth that gets reserved for tunnel other than changing tunnel configuration no matter what is actual amount of traffic sent over tunnel. To make TE tunnels more flexible and easy to use, the following features have been introduced:
- Bandwidth limitation
- Automatic bandwidth adjustment
These features operate on tunnel head end (ingress) router. These features can either be used alone or in combination.
Bandwidth limitation
TE tunnel can be configured to limit the rate at which traffic is allowed to enter the tunnel. Limit is specified on ingress router in percent of tunnel bandwidth. E.g. creating the following tunnel:
[admin@R1] /interface traffic-eng> add name=te1 from-address=9.9.9.1 to-address=9.9.9.5 \ bandwidth=100000 bandwidth-limit=120 primary-path=stat
means that tunnel will reserve bandwidth of 100 kilobits per second across MPLS backbone from 9.9.9.1 to 9.9.9.5 and that ingress router will limit the rate of traffic entering the tunnel to 120 kilobits per second (120% of 100 kilobits per second bandwidth). This can be confirmed by monitoring tunnel interface:
[admin@R1] /interface traffic-eng> monitor te1 tunnel-id: 3 primary-path-state: established primary-path: stat secondary-path-state: not-necessary active-path: stat active-lspid: 1 active-label: 20 reserved-bandwidth: 100.0kbps rate-limit: 120.0kbps rate-measured-last: 0bps rate-measured-highest: 0bps
Note that by default any limiting is disabled. By specifying limit as percentage of tunnel bandwidth, TE tunnel bandwith limits can be configured in rather flexible ways - some tunnels can be configured to hard limit while others can be configured with reasonable reserve, achieving different classes of service.
Automatic bandwidth adjustment
Auto bandwidth adjustment feature enables MPLS TE network to follow the changes of amount of data transmitted over tunnel. Bandwidth adjustment feature works as follows:
- Actual amount of data entering tunnel during averaging interval (auto-bandwidth-avg-interval) is measured, producing average rate.
- Tunnel keeps track of highest average rate seen during update interval (auto-bandwidth-update-interval)
- When update interval expires, TE tunnel bandwidth is updated to highest observed average rate, taking into account specified range over which bandwidth is allowed to change (auto-bandwidth-range)
Auto bandwidth adjustment feature gets enabled by specifying auto-bandwidth-range. For example, adding the following tunnel:
[admin@R1] /interface traffic-eng> add name=te1 from-address=9.9.9.1 to-address=9.9.9.5 \ bandwidth=100000 primary-path=stat auto-bandwidth-range=10000-500000 \ auto-bandwidth-avg-interval=10s auto-bandwidth-update-interval=1m
means that tunnel will measure average rate over 10 second periods and once per minute will update bandwidth in range from 10 to 500 kilobits per second. Tunnel bandwidth setting specifies the initial bandwidth of tunnel. The above tunnel in complete absence of data over it after 1 minute will change its bandwidth to specified minimum 10 kbps:
[admin@R1] /interface traffic-eng> monitor te1 tunnel-id: 3 primary-path-state: established primary-path: stat secondary-path-state: not-necessary active-path: stat active-lspid: 2 active-label: 21 reserved-bandwidth: 10.0kbps rate-limit: 12.0kbps rate-measured-last: 0bps rate-measured-highest: 0bps
Additionally, tunnel can be configured to reserve more bandwidth than measured. This can be achieved with auto-bandwidth-reserve setting which specifies percentage of additional bandwidth to reserve - so setting auto-bandwith-reserve to 10 means that tunnel will reserve 10% more bandwidth than measured (but will still obey the auto-bandwidth-range). For example changing above tunnel and running constant stream of 50kbps through it will yield the following results:
[admin@R1] /interface traffic-eng> set te1 auto-bandwidth-reserve=30
In the beginning tunnel reserves its initially specified bandwidth:
[admin@R1] /interface traffic-eng> monitor te1 tunnel-id: 6 primary-path-state: established primary-path: stat secondary-path-state: not-necessary active-path: stat active-lspid: 1 active-label: 27 reserved-bandwidth: 100.0kbps rate-limit: 120.0kbps rate-measured-last: 48.8kbps rate-measured-highest: 48.8kbps
After update period and after previous reservations are torn down notice how reserved bandwidth exceeds average rate by 30%. Also notice that rate-limit correctly changes to 120% of reserved-bandwidth:
[admin@R1] /interface traffic-eng> monitor te1 tunnel-id: 6 primary-path-state: established primary-path: stat secondary-path-state: not-necessary active-path: stat active-lspid: 2 active-label: 28 reserved-bandwidth: 64.4kbps rate-limit: 77.3kbps rate-measured-last: 48.8kbps rate-measured-highest: 48.8kbps
Note that in case reservation must be updated to lower value, brief period after update period reserved-bandwidth will still display previous reservation value. The reason for this is that new reservation is made without disrupting the previous tunnel and therefore shares its reservation until old reservation is torn down. rate-limit on turn is correctly updated to intended value. In the above example, after stopping the 50kbps stream and after update period will pass with tunnel being idle, for a brief period after update tunnel info can be:
[admin@R1] /interface traffic-eng> monitor te1 tunnel-id: 6 primary-path-state: established primary-path: stat secondary-path-state: not-necessary active-path: stat active-lspid: 2 active-label: 34 reserved-bandwidth: 63.4kbps rate-limit: 12.0kbps rate-measured-last: 0bps rate-measured-highest: 0bps
After previous reservation (63.4kbps) is torn down, reserved-bandwidth correctly changes to 10kbps:
[admin@R1] /interface traffic-eng> monitor 1 tunnel-id: 6 primary-path-state: established primary-path: stat secondary-path-state: not-necessary active-path: stat active-lspid: 2 active-label: 34 reserved-bandwidth: 10.0kbps rate-limit: 12.0kbps rate-measured-last: 0bps rate-measured-highest: 0bps
Note that auto-bandwidth-reserve is applied to actual measured bandwidth, before range checking according to auto-bandwidth-range - therefore 10kbps gets reserved, instead of 13kbps.
Combining bandwidth limitation with automatic bandwidth adjustment
Auto bandwidth adjustment can be used in combination with bandwidth limit feature - bandwidth-limit setting will apply to bandwidth actually reserved for tunnel. In order to successfully cobine both features, actual bandwidth must be allowed to fluctuate to some extent - e.g. if bandwidth-limit will be configured to 100% (this effectively means that rate will be limited to the bandwidth reserved for tunnel), tunnel will not have any chance to increase its reservation. Therefore either bandwidth-limit should be configured to more than 100%, or auto-bandwidth-reserve should be configured to more than 0%.