Container LSP
In the first part of the article I tried to describe the possibilities of some approaches to balancing traffic in the MPLS domain, the idea was to show the unique requirements for the hardware implementation of the chip, which allow to achieve success, in one case or another. The second part will be devoted to the story of the relatively recent draft [Multi-path Label Switched Paths Signaled Using RSVP-TE] from Kireeti Kompella, and a description of the application of its implementation from Juniper to solving some problems.
The task of efficient utilization of communication channels in the RSVP-TE network has much in common with the task of packing things in bags, suitcases or containers before vacation. Everyone who did this will say that things of about the same size fit much easier and more evenly. It’s good if the size of things is noticeably smaller than the size of the container, but when suddenly there is a need to fit a voluminous object into one of the bags ready for departure, re-sorting is inevitable. In the RSVP-TE world, this is called the bin-packing problem, to understand what I'm talking about, look at Figure 1, the green and blue lines are the installed LSP1 along the ACDE path and LSP2 along the BCE path at time points T = 1 and T = 2, respectively. If at time point T = 3 the LSP2 band would need to be expanded to a value of 8, the capacity of the CE channel would not allow this. In the world of things and suitcases, we would spend some time re-sorting things to solve this problem. RSVP-TE allows you to do the same with certain reservations, for this they came up with setup and hold LSP priorities, potentially wider LSPs can be given high priority so that narrow LSPs move, however this approach works exactly until LSPs with the same priorities come into play, and then everything repeats.
This happens for two reasons:
Returning to the problem of suitcases, we could try to disassemble a suddenly discovered thing to such an extent that all its parts evenly fill the free space of several suitcases. A similar idea was proposed by Kireeti Kompella for optimal utilization of communication channels in an RSVP-TE environment. Instead of signaling one thick path, the router, taking into account the current topology and utilization of channels, calculates and signals several less demanding lanes, in the draft they are called sub-LSPs. Figure 2 shows what this might look like when expanding the LSP2 band to the value 8, the router lays a pair of sub-LSP with bands of 4 and lays out the traffic in two possible ways.
So, in the draft, a new MLSP concept or container appears; this concept defines a configuration and control object for a set of sub-LSPs. In other words, the TE properties and requirements recorded in the container generate a certain set of physical LSPs that satisfy the
given network limitations and capabilities. The exact algorithm for calculating the number of sub-LSPs and the reserved redundant sub-LSP band is not described, it is all given to the vendors for free implementation, there are only two caveats to this:
sub-LSPs belonging to a particular MLSP instance are signaled in such a way that transit routers can determine this affiliation; for this, the Path message assumes the use of an RSVP ASSOCIATION object with a unique value for each MLSP. Interestingly, before the 4th draft version, it was supposed to use the Sender Template fields as an identifier. Identifying sup-LSP ownership is useful in that it allows you to implement a fairly simple label-saving mechanism; there is no need for the downstream router to reserve a unique label for each sub-LSP, it is enough to determine which MLSP the installed sub-LSP belongs to and return the common label to the upstream router.
Depending on the capabilities of the switching chip of the transit router, the draft describes two options for organizing the transfer of traffic at the data plane level. The first option, called Equi-bandwidth LSP, is to evenly distribute traffic flows across all sub-LSPs on each transit router, while the behavior of traffic flows fully corresponds to per-hop ECMP balancing with the ability to use all, not just IGP Best, paths. The second option involves the weighted distribution of traffic flows on the sub-LSP in accordance with the reserved band. The possibility of alternative (at the discretion of the vendor) options for organizing data-plane is also stipulated.
Such a data-plane organization has an interesting property - in some topologies, fast convergence in case of accidents is a natural consequence even without involving mechanisms like MPLS TE Protection, so if the BC channel fails in Figure 3, Router B does not establish any repair paths , it is able to independently restore the transmission of traffic by simply removing one next-hop from the table before the information about the accident will be available to router A.
Further analysis of the draft risks turning into a retelling, so we turn to examples of use. At the moment, I know only one option, which with certain reservations can be called at least the ideological implementation of the draft. The main complaint is that label-saving and sub-LSP identification mechanisms have not yet been implemented; nevertheless, a convenient tool for solving some TE problems has turned out. By the way, Juniper Container LSP is fully compatible with classic RSVP-TE implementations of other manufacturers, which, in my opinion, is a serious plus of this form of implementation.
Attractive is the possibility of using Full Mesh Container LSP between PE routers in combination with P devices without serious hash of the label stack. Instead of balancing traffic on each transit router, the Container LSP uses a flexible sub-LSP calculation and signaling mechanism. The algorithm is capable of autonomously matching the number of sub-LSPs, their paths and occupied bands to the capabilities and network topology. The configuration parameters of the container, or a set of sub-LSPs, their properties and limitations are transmitted to the input of the algorithm:
The aggregated band is periodically updated based on the band statistics of each sub-LSP and represents the sum of these values. The remaining parameters of the container are set manually in accordance with the desired values. Autonomous operation is supported by periodically repeating normalization events; at this moment in time, the algorithm makes one of the following decisions:
The current version of the normalization algorithm performs the calculation, as a result of which a set of sub-LSP with an equal band appears. For example, if the aggregated band is 10, as a result of the calculation, sub-LSPs with the following parameters may appear: 2 by 5, 5 by 2, or 3 by 3.3, if there are several options, the algorithm selects one that requires a smaller number of sub-LSPs. Between normalization events, the band of each sub-LSP can be individually changed using the auto-bandwidth mechanism. At the next iteration of normalization, the algorithm will collect the current strip readings and perform one of its possible actions, the delete or add sub-LSP actions are performed if the current strip of any sub-LSP is outside the splitting / merging range. Adding or removing sub-LSPs is accompanied by band recalculation subject to the following restrictions:
The smallest N value satisfying these inequalities is used to calculate the new sub-LSP band using the simple formula
If the CSPF algorithm is not able to find the paths with the required free band, for example, due to fragmentation of the free band, N increases by one, which reduces the individual sub band -LSPs, and the pathfinding process is repeated.
To demonstrate the behavior of the Container LSP, I put together this diagram. The bandwidth of each interface is reduced to 10Mbit / s.
Let's start with the configuration on router A, you must explicitly enable the collection of LSP statistics (lines 1-3), specify the template from which sub-LSPs will be created (lines 4-11) and write the properties of the LSP container to router B (lines 12-22 )
After activating the code, the container is initialized, and, since. no traffic statistics yet set the minimum number of sub-LSPs with a band equal to the splitting band. After some time, the auto-bandwidth mechanism accumulated statistics (zero in this case) and adjusted the band.
In a live network, it is better to pre-evaluate the order of traffic, and prepare the right amount of sub-LSP with an approximate bandwidth. This can be done using the minimum-member-lsps and merging-bandwidth parameters (lines 15 and 17).
Now we’ll generate something around 7Mbps of traffic, and analyze what happened. I waited some time to sort out the chronology after the normalization event.
Before the occurrence of the events of updating the auto-bandwidth and normalization, only statistics change. Pay attention to the values of Max AvgBW util and Sampled Aggregate bandwidth, the first is the current sub-LSP band, the second is the current container band.
After some time, the auto-bandwidth mechanism corrected the band of a single sub-LSP, in history this can be seen from the record
After some time, the moment of normalization came, and since the band actually occupied by the LSP is outside the range of merging / splitting, the algorithm decided to add another sub-LSP.
Now let's add about 2Mbps of traffic, judging by the Sampled Aggregate bandwidth and
Max AvgBW util statistics, the statistics have crept up.
After some time, auto-bandwidth corrected the band of both sub-LSBs.
And the normalization algorithm added another sub-LSP.
In the case when the entropy of packets transmitted to the LSP is high, the passive auto-bandwidth mode can be activated, in this case, the band will be updated only during the normalization process, thereby some processor time can be saved.
The task of efficient utilization of communication channels in the RSVP-TE network has much in common with the task of packing things in bags, suitcases or containers before vacation. Everyone who did this will say that things of about the same size fit much easier and more evenly. It’s good if the size of things is noticeably smaller than the size of the container, but when suddenly there is a need to fit a voluminous object into one of the bags ready for departure, re-sorting is inevitable. In the RSVP-TE world, this is called the bin-packing problem, to understand what I'm talking about, look at Figure 1, the green and blue lines are the installed LSP1 along the ACDE path and LSP2 along the BCE path at time points T = 1 and T = 2, respectively. If at time point T = 3 the LSP2 band would need to be expanded to a value of 8, the capacity of the CE channel would not allow this. In the world of things and suitcases, we would spend some time re-sorting things to solve this problem. RSVP-TE allows you to do the same with certain reservations, for this they came up with setup and hold LSP priorities, potentially wider LSPs can be given high priority so that narrow LSPs move, however this approach works exactly until LSPs with the same priorities come into play, and then everything repeats.
This happens for two reasons:
- local, non-deterministic order of calculation and optimization of paths on each router;
- lack of mechanisms to coordinate the calculation of paths between routers.
Returning to the problem of suitcases, we could try to disassemble a suddenly discovered thing to such an extent that all its parts evenly fill the free space of several suitcases. A similar idea was proposed by Kireeti Kompella for optimal utilization of communication channels in an RSVP-TE environment. Instead of signaling one thick path, the router, taking into account the current topology and utilization of channels, calculates and signals several less demanding lanes, in the draft they are called sub-LSPs. Figure 2 shows what this might look like when expanding the LSP2 band to the value 8, the router lays a pair of sub-LSP with bands of 4 and lays out the traffic in two possible ways.
So, in the draft, a new MLSP concept or container appears; this concept defines a configuration and control object for a set of sub-LSPs. In other words, the TE properties and requirements recorded in the container generate a certain set of physical LSPs that satisfy the
given network limitations and capabilities. The exact algorithm for calculating the number of sub-LSPs and the reserved redundant sub-LSP band is not described, it is all given to the vendors for free implementation, there are only two caveats to this:
- sub-LSPs should inherit all (except bandwith) TE container restrictions, for example, the Administrative group or Setup / Hold Priority should inherit;
- the amount of reserved band of sub-LSPs should be no less than the requirements of the container.
sub-LSPs belonging to a particular MLSP instance are signaled in such a way that transit routers can determine this affiliation; for this, the Path message assumes the use of an RSVP ASSOCIATION object with a unique value for each MLSP. Interestingly, before the 4th draft version, it was supposed to use the Sender Template fields as an identifier. Identifying sup-LSP ownership is useful in that it allows you to implement a fairly simple label-saving mechanism; there is no need for the downstream router to reserve a unique label for each sub-LSP, it is enough to determine which MLSP the installed sub-LSP belongs to and return the common label to the upstream router.
Depending on the capabilities of the switching chip of the transit router, the draft describes two options for organizing the transfer of traffic at the data plane level. The first option, called Equi-bandwidth LSP, is to evenly distribute traffic flows across all sub-LSPs on each transit router, while the behavior of traffic flows fully corresponds to per-hop ECMP balancing with the ability to use all, not just IGP Best, paths. The second option involves the weighted distribution of traffic flows on the sub-LSP in accordance with the reserved band. The possibility of alternative (at the discretion of the vendor) options for organizing data-plane is also stipulated.
Such a data-plane organization has an interesting property - in some topologies, fast convergence in case of accidents is a natural consequence even without involving mechanisms like MPLS TE Protection, so if the BC channel fails in Figure 3, Router B does not establish any repair paths , it is able to independently restore the transmission of traffic by simply removing one next-hop from the table before the information about the accident will be available to router A.
Further analysis of the draft risks turning into a retelling, so we turn to examples of use. At the moment, I know only one option, which with certain reservations can be called at least the ideological implementation of the draft. The main complaint is that label-saving and sub-LSP identification mechanisms have not yet been implemented; nevertheless, a convenient tool for solving some TE problems has turned out. By the way, Juniper Container LSP is fully compatible with classic RSVP-TE implementations of other manufacturers, which, in my opinion, is a serious plus of this form of implementation.
Attractive is the possibility of using Full Mesh Container LSP between PE routers in combination with P devices without serious hash of the label stack. Instead of balancing traffic on each transit router, the Container LSP uses a flexible sub-LSP calculation and signaling mechanism. The algorithm is capable of autonomously matching the number of sub-LSPs, their paths and occupied bands to the capabilities and network topology. The configuration parameters of the container, or a set of sub-LSPs, their properties and limitations are transmitted to the input of the algorithm:
- aggregated band;
- minimum and maximum number of sub-LSP;
- splitting and merging bands.
The aggregated band is periodically updated based on the band statistics of each sub-LSP and represents the sum of these values. The remaining parameters of the container are set manually in accordance with the desired values. Autonomous operation is supported by periodically repeating normalization events; at this moment in time, the algorithm makes one of the following decisions:
- add one or more sub-LSP
- remove one or more sub-LSPs
- let it be as it is
The current version of the normalization algorithm performs the calculation, as a result of which a set of sub-LSP with an equal band appears. For example, if the aggregated band is 10, as a result of the calculation, sub-LSPs with the following parameters may appear: 2 by 5, 5 by 2, or 3 by 3.3, if there are several options, the algorithm selects one that requires a smaller number of sub-LSPs. Between normalization events, the band of each sub-LSP can be individually changed using the auto-bandwidth mechanism. At the next iteration of normalization, the algorithm will collect the current strip readings and perform one of its possible actions, the delete or add sub-LSP actions are performed if the current strip of any sub-LSP is outside the splitting / merging range. Adding or removing sub-LSPs is accompanied by band recalculation subject to the following restrictions:
N - количество sub-LSP, X - агрегированная полоса, minimum-member-lsps - минимальное количество sub-LSP, maximum-member-lsps - максимальное количество sub-LSP, splitting-bandwidth - полоса расщепления, merging-bandwidth - полоса слияния
[X/splitting-bandwidth] ≤ N ≤ [X/merging-bandwidth]
minimum-member-lsps ≤ N ≤ maximum-member-lspsThe smallest N value satisfying these inequalities is used to calculate the new sub-LSP band using the simple formula
B = X / N If the CSPF algorithm is not able to find the paths with the required free band, for example, due to fragmentation of the free band, N increases by one, which reduces the individual sub band -LSPs, and the pathfinding process is repeated.
To demonstrate the behavior of the Container LSP, I put together this diagram. The bandwidth of each interface is reduced to 10Mbit / s.
Let's start with the configuration on router A, you must explicitly enable the collection of LSP statistics (lines 1-3), specify the template from which sub-LSPs will be created (lines 4-11) and write the properties of the LSP container to router B (lines 12-22 )
[edit protocols mpls]
- set protocols mpls statistics file mpls-lsp-stats
- set protocols mpls statistics interval 50
- set protocols mpls statistics auto-bandwidth
- set protocols mpls label-switched-path lsp-template template
- set protocols mpls label-switched-path lsp-template retry-timer 3
- set protocols mpls label-switched-path lsp-template optimize-timer 0
- set protocols mpls label-switched-path lsp-template least-fill
- set protocols mpls label-switched-path lsp-template adaptive
- set protocols mpls label-switched-path lsp-template auto-bandwidth adjust-interval 300
- set protocols mpls label-switched-path lsp-template auto-bandwidth minimum-bandwidth 1k
- set protocols mpls label-switched-path lsp-template auto-bandwidth maximum-bandwidth 10m
- set protocols mpls container-label-switched-path to-b-cnt label-switched-path-template lsp-template
- set protocols mpls container-label-switched-path to-b-cnt to 172.19.1.2
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging maximum-member-lsps 50
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging minimum-member-lsps 1
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging splitting-bandwidth 4m
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging merging-bandwidth 2m
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization normalize-interval 650
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization failover-normalization
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization normalization-retry-duration 5
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging normalization normalization-retry-limits 3
- set protocols mpls container-label-switched-path to-b-cnt splitting-merging sampling use-percentile 95
[edit protocols mpls]
After activating the code, the container is initialized, and, since. no traffic statistics yet set the minimum number of sub-LSPs with a band equal to the splitting band. After some time, the auto-bandwidth mechanism accumulated statistics (zero in this case) and adjusted the band.
[email protected]# run show mpls container-lsp ingress extensive
Ingress LSP: 1 sessions
Container LSP name: to-b-cnt, State: Up, Member count: 1
Normalization
Min LSPs: 1, Max LSPs: 50
Aggregate bandwidth: 1000bps, Sampled Aggregate bandwidth: 57.6003bps
NormalizeTimer: 650 secs, NormalizeThreshold: 10%
Max Signaling BW: 4Mbps, Min Signaling BW: 2Mbps, Splitting BW: 4Mbps, Merging BW: 2Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 0, Percentile 95 of Aggregate
Normalization in 639 second(s)
14 Apr 26 22:21:25.954 Avoid normalization: not needed as already running with max-members
13 Apr 26 22:21:25.954 Normalize: normalization with aggregate bandwidth 57 bps
12 Apr 26 22:21:25.954 Normalize: normalizaton with 57 bps
11 Apr 26 22:21:22.050 Avoid normalization: not needed as already running with max-members
10 Apr 26 22:21:22.050 Normalize: normalization with aggregate bandwidth 56 bps
9 Apr 26 22:21:22.049 Normalize: normalizaton with 56 bps
8 Apr 26 22:21:03.558 Clear history and statistics: on container (to-b-cnt)
7 Apr 26 22:20:29.353 Avoid normalization: not needed as already running with max-members
6 Apr 26 22:20:29.353 Normalize: normalization with aggregate bandwidth 56 bps
5 Apr 26 22:20:29.353 Normalize: normalizaton with 56 bps
4 Apr 26 22:17:43.539 Normalization complete: container (to-b-cnt) with 1 members
3 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) into 1 members - each with bandwidth 2000000 bps
2 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) create 1 LSPs, min bw 2000000bps, member count 0
1 Apr 26 22:17:43.529 Normalize: normalization with aggregate bandwidth 0 bps
172.19.1.2
From: 172.19.1.1, State: Up, ActiveRoute: 0, LSPname: to-b-cnt-1
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Least-fill
Autobandwidth
MinBW: 1000bps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 57.6003bps, Bandwidth Adjustment in 67 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 1000bps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
172.19.250.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.19.250.2
17 Apr 26 22:21:23.060 Make-before-break: Switched to new instance
16 Apr 26 22:21:22.370 Self-ping ended successfully
15 Apr 26 22:21:22.057 Record Route: 172.19.250.2
14 Apr 26 22:21:22.057 Up
13 Apr 26 22:21:22.057 Manual Autobw adjustment succeeded: BW changes from 2000000 bps to 1000 bps
12 Apr 26 22:21:22.057 Self-ping started
11 Apr 26 22:21:22.057 Self-ping enqueued
10 Apr 26 22:21:22.050 Originate make-before-break call
9 Apr 26 22:21:22.050 CSPF: computation result accepted 172.19.250.2
8 Apr 26 22:17:44.002 Self-ping ended successfully
7 Apr 26 22:17:43.539 Selected as active path
6 Apr 26 22:17:43.538 Record Route: 172.19.250.2
5 Apr 26 22:17:43.538 Up
4 Apr 26 22:17:43.538 Self-ping started
3 Apr 26 22:17:43.538 Self-ping enqueued
2 Apr 26 22:17:43.530 Originate Call
1 Apr 26 22:17:43.530 CSPF: computation result accepted 172.19.250.2
Created: Wed Apr 26 22:17:44 2017
Retrytimer: 3
Total 1 displayed, Up 1, Down 0
[edit protocols mpls]
[email protected]#
In a live network, it is better to pre-evaluate the order of traffic, and prepare the right amount of sub-LSP with an approximate bandwidth. This can be done using the minimum-member-lsps and merging-bandwidth parameters (lines 15 and 17).
Now we’ll generate something around 7Mbps of traffic, and analyze what happened. I waited some time to sort out the chronology after the normalization event.
[email protected]# run show mpls container-lsp ingress extensive
Ingress LSP: 1 sessions
Container LSP name: to-b-cnt, State: Up, Member count: 2
Normalization
Min LSPs: 1, Max LSPs: 50
Aggregate bandwidth: 7.10478Mbps, Sampled Aggregate bandwidth: 6.94114Mbps
NormalizeTimer: 650 secs, NormalizeThreshold: 10%
Max Signaling BW: 4Mbps, Min Signaling BW: 2Mbps, Splitting BW: 4Mbps, Merging BW: 2Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 0, Percentile 95 of Aggregate
Normalization in 497 second(s)
23 Apr 26 22:27:43.570 Clear history and statistics: on container (to-b-cnt)
22 Apr 26 22:26:07.615 Normalization complete: container (to-b-cnt) with 2 members
21 Apr 26 22:26:07.562 Normalize: container (to-b-cnt) into 2 members - each with bandwidth 3552392 bps
20 Apr 26 22:26:07.562 Normalize: normalization with aggregate bandwidth 7104784 bps
19 Apr 26 22:26:07.562 Normalize: normalizaton with 7104784 bps
18 Apr 26 22:25:59.138 Avoid normalization: not needed as already running with max-members
17 Apr 26 22:25:59.138 Normalize: normalization with aggregate bandwidth 57 bps
16 Apr 26 22:25:59.138 Normalize: normalizaton with 57 bps
15 Apr 26 22:22:43.557 Clear history and statistics: on container (to-b-cnt)
14 Apr 26 22:21:25.954 Avoid normalization: not needed as already running with max-members
13 Apr 26 22:21:25.954 Normalize: normalization with aggregate bandwidth 57 bps
12 Apr 26 22:21:25.954 Normalize: normalizaton with 57 bps
11 Apr 26 22:21:22.050 Avoid normalization: not needed as already running with max-members
10 Apr 26 22:21:22.050 Normalize: normalization with aggregate bandwidth 56 bps
9 Apr 26 22:21:22.049 Normalize: normalizaton with 56 bps
8 Apr 26 22:21:03.558 Clear history and statistics: on container (to-b-cnt)
7 Apr 26 22:20:29.353 Avoid normalization: not needed as already running with max-members
6 Apr 26 22:20:29.353 Normalize: normalization with aggregate bandwidth 56 bps
5 Apr 26 22:20:29.353 Normalize: normalizaton with 56 bps
4 Apr 26 22:17:43.539 Normalization complete: container (to-b-cnt) with 1 members
3 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) into 1 members - each with bandwidth 2000000 bps
2 Apr 26 22:17:43.529 Normalize: container (to-b-cnt) create 1 LSPs, min bw 2000000bps, member count 0
1 Apr 26 22:17:43.529 Normalize: normalization with aggregate bandwidth 0 bps
172.19.1.2
From: 172.19.1.1, State: Up, ActiveRoute: 0, LSPname: to-b-cnt-1
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Least-fill
Autobandwidth
MinBW: 1000bps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 3.56199Mbps, Bandwidth Adjustment in 147 second(s).
Overflow limit: 0, Overflow sample count: 1
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 3.55239Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
172.19.250.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.19.250.2
39 Apr 26 22:28:01.331 Make-before-break: Cleaned up old instance: Hold dead expiry
38 Apr 26 22:27:00.512 Make-before-break: Switched to new instance
37 Apr 26 22:26:59.981 Self-ping ended successfully
36 Apr 26 22:26:59.509 Record Route: 172.19.250.2
35 Apr 26 22:26:59.509 Up
34 Apr 26 22:26:59.509 Self-ping started
33 Apr 26 22:26:59.509 Self-ping enqueued
32 Apr 26 22:26:59.503 Autobw adjustment succeeded due to normalization: BW changes from 7105130 bps to 3552392 bps
31 Apr 26 22:26:59.501 Originate make-before-break call
30 Apr 26 22:26:59.501 CSPF: computation result accepted 172.19.250.2
29 Apr 26 22:26:59.498 Make-before-break: Cleaned up old instance: Hold dead expiry
28 Apr 26 22:26:07.563 Pending old path instance deletion
27 Apr 26 22:26:00.148 Make-before-break: Switched to new instance
26 Apr 26 22:25:59.874 Self-ping ended successfully
25 Apr 26 22:25:59.146 Record Route: 172.19.250.2
24 Apr 26 22:25:59.146 Up
23 Apr 26 22:25:59.146 Manual Autobw adjustment succeeded: BW changes from 1000 bps to 7105130 bps
22 Apr 26 22:25:59.145 Self-ping started
21 Apr 26 22:25:59.145 Self-ping enqueued
20 Apr 26 22:25:59.139 Originate make-before-break call
19 Apr 26 22:25:59.139 CSPF: computation result accepted 172.19.250.2
18 Apr 26 22:22:24.539 Make-before-break: Cleaned up old instance: Hold dead expiry
17 Apr 26 22:21:23.060 Make-before-break: Switched to new instance
16 Apr 26 22:21:22.370 Self-ping ended successfully
15 Apr 26 22:21:22.057 Record Route: 172.19.250.2
14 Apr 26 22:21:22.057 Up
13 Apr 26 22:21:22.057 Manual Autobw adjustment succeeded: BW changes from 2000000 bps to 1000 bps
12 Apr 26 22:21:22.057 Self-ping started
11 Apr 26 22:21:22.057 Self-ping enqueued
10 Apr 26 22:21:22.050 Originate make-before-break call
9 Apr 26 22:21:22.050 CSPF: computation result accepted 172.19.250.2
8 Apr 26 22:17:44.002 Self-ping ended successfully
7 Apr 26 22:17:43.539 Selected as active path
6 Apr 26 22:17:43.538 Record Route: 172.19.250.2
5 Apr 26 22:17:43.538 Up
4 Apr 26 22:17:43.538 Self-ping started
3 Apr 26 22:17:43.538 Self-ping enqueued
2 Apr 26 22:17:43.530 Originate Call
1 Apr 26 22:17:43.530 CSPF: computation result accepted 172.19.250.2
Created: Wed Apr 26 22:17:43 2017
Retrytimer: 3
172.19.1.2
From: 172.19.1.1, State: Up, ActiveRoute: 0, LSPname: to-b-cnt-2
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Least-fill
Autobandwidth
MinBW: 1000bps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 3.5582Mbps, Bandwidth Adjustment in 147 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 1, Underflow Max AvgBW: 3.53934Mbps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 3.55239Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
172.19.250.25 S 172.19.250.9 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.19.250.25 172.19.250.9
8 Apr 26 22:26:07.888 Self-ping ended successfully
7 Apr 26 22:26:07.615 Selected as active path
6 Apr 26 22:26:07.613 Record Route: 172.19.250.25 172.19.250.9
5 Apr 26 22:26:07.613 Up
4 Apr 26 22:26:07.613 Self-ping started
3 Apr 26 22:26:07.613 Self-ping enqueued
2 Apr 26 22:26:07.564 Originate Call
1 Apr 26 22:26:07.564 CSPF: computation result accepted 172.19.250.25 172.19.250.9
Created: Wed Apr 26 22:26:07 2017
Retrytimer: 3
Total 2 displayed, Up 2, Down 0
[edit protocols mpls]
[email protected]#
Before the occurrence of the events of updating the auto-bandwidth and normalization, only statistics change. Pay attention to the values of Max AvgBW util and Sampled Aggregate bandwidth, the first is the current sub-LSP band, the second is the current container band.
After some time, the auto-bandwidth mechanism corrected the band of a single sub-LSP, in history this can be seen from the record
23 Apr 26 22:25:59.146 Manual Autobw adjustment succeeded: BW changes from 1000 bps to 7105130 bps
After some time, the moment of normalization came, and since the band actually occupied by the LSP is outside the range of merging / splitting, the algorithm decided to add another sub-LSP.
22 Apr 26 22:26:07.615 Normalization complete: container (to-b-cnt) with 2 members
21 Apr 26 22:26:07.562 Normalize: container (to-b-cnt) into 2 members - each with bandwidth 3552392 bps
Now let's add about 2Mbps of traffic, judging by the Sampled Aggregate bandwidth and
Max AvgBW util statistics, the statistics have crept up.
[email protected]# run show mpls container-lsp ingress extensive | match "Max AvgBW util|Bandwidth:"
Aggregate bandwidth: 7.13661Mbps, Sampled Aggregate bandwidth: 9.07548Mbps
Max AvgBW util: 4.79669Mbps, Bandwidth Adjustment in 5 second(s).
Bandwidth: 3.57257Mbps
Max AvgBW util: 4.80336Mbps, Bandwidth Adjustment in 5 second(s).
Bandwidth: 3.56403Mbps
[edit protocols mpls]
[email protected]#
After some time, auto-bandwidth corrected the band of both sub-LSBs.
[email protected]# run show mpls container-lsp ingress extensive | match "Max AvgBW util|Bandwidth:"
Aggregate bandwidth: 9.60991Mbps, Sampled Aggregate bandwidth: 9.57293Mbps
Max AvgBW util: 4.79669Mbps, Bandwidth Adjustment in 254 second(s).
Bandwidth: 4.79669Mbps
Max AvgBW util: 4.81322Mbps, Bandwidth Adjustment in 253 second(s).
Bandwidth: 4.81322Mbps
[edit protocols mpls]
[email protected]#
And the normalization algorithm added another sub-LSP.
[email protected]# run show mpls container-lsp ingress extensive | match "Max AvgBW util|Bandwidth:"
Aggregate bandwidth: 9.57292Mbps, Sampled Aggregate bandwidth: 9.57293Mbps
Max AvgBW util: 4.79669Mbps, Bandwidth Adjustment in 110 second(s).
Bandwidth: 3.19098Mbps
Max AvgBW util: 4.81322Mbps, Bandwidth Adjustment in 210 second(s).
Bandwidth: 3.19098Mbps
Max AvgBW util: 0bps, Bandwidth Adjustment in 10 second(s).
Bandwidth: 3.19098Mbps
[edit protocols mpls]
[email protected]#
In the case when the entropy of packets transmitted to the LSP is high, the passive auto-bandwidth mode can be activated, in this case, the band will be updated only during the normalization process, thereby some processor time can be saved.
