This article demonstrates with an example that brief traffic loss is expected during Make Before Break (MBB) when traffic passes over RSVP LSP that has LDP tunneling enabled and when multiple FECs are advertised, LDP aggregation is enabled, and bypass LSP is also in place.
Figure 1
In the topology above, RSVP-LSP with LDP tunneling is up from TL2 to TL1 and bypass LSP is also up. LDP aggregation is enabled on TL1 and TL2.
Every time loss was observed, the following events were registered on the TL router where autobandwidth triggered an MBB switchover to a new LSP instance:
Traffic loss was observed shortly after "Make-before-break: Switched to new instance" event in LSP.
Ingress PFE statistics "Normal discard" counter increases with the number equal to number of packets lost.
In case TL2 to TL1 LSP was re-signaled due to autobandwidth event, LDP labels change on BR3 router to GW1 loopback FEC.
Example
LSP switching to new instance
root@TL2> show mpls lsp ingress up name TEST extensive | refresh 2 -------------- snip --------------- 16 Oct 15 16:31:42.833 Link-protection Up 15 Oct 15 16:31:42.776 Make-before-break: Switched to new instance << Traffic loss observed shortly after MBB. 14 Oct 15 16:31:42.776 Link-protection Down 13 Oct 15 16:31:12.774 Record Route: 1.1.1.1(flag=0x20) 2.2.2.2(Label=0) 12 Oct 15 16:31:12.774 Up 11 Oct 15 16:31:12.774 Automatic Autobw adjustment succeeded: BW changes from 1000000 bps to 491437376 bps 10 Oct 15 16:31:12.768 Originate make-before-break call -------------- snip ---------------
Increase in ingress PFE traffic statistics "Normal discard" counter
root@TL2> show pfe statistics traffic fpc 2 | match "normal" | refresh 2 ---(refreshed at 2020-10-15 16:31:43 EDT)--- Normal discard : 0 ---(refreshed at 2020-10-15 16:31:45 EDT)--- Normal discard : 74 ---(refreshed at 2020-10-15 16:31:47 EDT)--- Normal discard : 3302 < --- Packets dropped on ingress router ingress PFE as "Normal discard"
LDP label change twice on BR3 router
root@BR3> show route <Destination IP> detail | match push | refresh 2 ---(refreshed at 2020-10-15 15:31:44 EST)--- Label operation: Push 347392 ---(refreshed at 2020-10-15 15:31:46 EST)--- Label operation: Push 347376 ---(refreshed at 2020-10-15 15:31:48 EST)--- Label operation: Push 347472 <--- Label changes twice.
This behavior is expected with known LDP aggregation behavior below.
By default, routers aggregate labels if the following conditions are met:
All IP routes have the same next hop.
The label advertised for these routes advertised by the next-hop router is also the same.
There is an exception to this behavior when the corresponding route has a back-up next hop. If, for instance, an LDP tunnel is configured and the label-switched path (LSP) link-protection is also configured, the LDP routes will have a back-up next hop. In this case, Junos OS will not aggregate the label. On the other hand, when the back-up next hop is gone, LDP will aggregate the label.
Consider that the following labels were advertised (see Figure 2):
GW1 advertises an implicit-null label to TL1 for two FECs (loopback IP addresses).
TL1 advertises an aggregate label for two GW1 FECs to TL2.
TL2 de-aggregates labels upon advertisement to BR3 because LSP to TL1 has backup next-hop (bypass LSP).
Figure 2
When autobandwidth triggers an MBB switchover to a new LSP instance, the following happens:
Autobandwidth triggers MBB switchover.
New LSP is signaled with updated bandwidth.
After LSP self-ping is successful, switchover is initiated.
Link protection for old LSP instance goes DOWN. This event removes backup next-hop to LDP advertised routes and triggers LDP labels aggregation. See Figure 3.
LSP switchover completes.
Link protection for new LSP instance goes UP. This event creates backup next-hop to LDP advertised routes and triggers LDP labels to de-aggregate.
Figure 3
Since labels must be re-advertised twice from TL2 to BR3 (De-aggregated Label ---- Aggregated Label ----- De-aggregated Label), there is traffic loss. This is expected and no action is required.