LDP/IGP Sync may seem complex, but I hope by the end of the article you find this feature intuitive and easy to understand.
In an MPLS environment, the IGP is generally needed to advertise and provide reachability to the /32 loopbacks of PEs in the network. These /32s are the endpoints that identify ingress and egress routers for VPN services.
LDP is needed to advertise labels for these /32 loopbacks to directly connected neighbors. If the IGP is up, and a router has a route to the /32 of PE, but LDP is not up, the router may IP route the traffic instead of label switch the traffic. This can break VPNs. The packet becomes unlabeled, and the LSR in the middle has no idea that the traffic actually belongs to an L2VPN or L3VPN.
The workaround to prevent this issue is to have the IGP (OSPF or ISIS) wait for LDP to be up. This is called LDP Sync - the IGP synchronizes with LDP. But how does it do this? To achieve syncronization, the IGP simply advertises the link cost as the maximum metric until the LDP session is up. This discourages the use of this link for existing labeled traffic while the LDP session is in the process of forming. If there is any other path to the destination, that path is going to be used, which will prevent the labels from getting popped off. Once LDP is up on the interface, the IGP metric is advertised with its normal value again. This ensures that labeled traffic takes alternative paths until LDP is actually up on the interface, so that the traffic can be label switched end-to-end.
What if LDP goes up before the IGP neighborship goes up? This isn’t a concern, as the router will use the best IGP path to each /32 prefix. If the IGP neighborship is not up, the router has the label bindings from its neighbor, but no best paths through that neighbor. So the traffic will use alternative routes until the IGP comes up. There is no syncronization needed in this case. LDP sync is only used to make the IGP wait for LDP - not the other way around.
The Issue Which LDP/IGP Sync Solves
We’ll use the following topology to explain the theory behind LDP/IGP sync.
All IGP link costs are 1. PE1 and PE2 are the PEs for an L3VPN service that CE1 and CE2 participate in. Under normal circumstances, traffic from CE1 to CE2 is label switched along the path PE1-P3-P4-PE2. At P3 and P4 the traffic is double labeled, with the top label being the transport label identifying PE2’s loopback and the bottom label being the L3VPN label which is only signficant to PE2.
Let’s imagine there is some issue with LDP between P3 and P4. The IGP neighborship is still up but LDP is down. P3 has a labeled path for PE2’s loopback via P5, however the IGP shortest path is via P4 unlabeled. Upon receiving traffic from PE1, P3 will pop both MPLS labels and send the packet to P4. P4 will try to route the traffic in its global routing table, breaking the L3VPN. We will explore this scenario in the lab later in the article.
The outage caused by this situation could be avoided if we could just force P3 to send the traffic via P5. The labels would stay intact and the L3VPN service would stay up. If we had LDP sync turned on, the IGP would advertise the P3-P4 link with the max metric, making the P3-P5-P4 path better. Only once the LDP session comes up again will the metric for the P3-P4 link be advertised as 1.
Lab (OSPF)
Here are the startup configs, using the diagram above.
#PE1
hostname PE1
!
line con 0
logging sync
!
int Gi2
ip add 10.1.3.1 255.255.255.0
no shut
ip ospf network point-to-point
mpls ip
!
int lo0
ip address 1.1.1.1 255.255.255.255
!
vrf definition CUSTOMER_A
rd 1:1
route-target both 1:1
address-family ipv4 unicast
exit
!
int Gi1
vrf forwarding CUSTOMER_A
ip add 100.64.0.1 255.255.255.252
no shut
!
router ospf 1
network 10.1.3.0 0.0.0.255 area 0
network 1.1.1.1 255.255.255.255 area 0
!
router bgp 100
neighbor 2.2.2.2 remote-as 100
address-family vpnv4 unicast
neighbor 2.2.2.2 activate
address-family ipv4 unicast vrf CUSTOMER_A
neighbor 100.64.0.2 remote-as 65000
#P3
hostname P3
!
line con 0
logging sync
!
int Gi1
ip add 10.1.3.3 255.255.255.0
no shut
ip ospf network point-to-point
mpls ip
!
int Gi2
ip add 10.3.4.3 255.255.255.0
no shut
ip ospf network point-to-point
mpls ip
!
int Gi3
ip add 10.3.5.3 255.255.255.0
no shut
ip ospf network point-to-point
mpls ip
!
int lo0
ip address 3.3.3.3 255.255.255.255
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
#P5
hostname P5
!
line con 0
logging sync
!
int Gi1
ip add 10.3.5.5 255.255.255.0
no shut
ip ospf network point-to-point
mpls ip
!
int Gi2
ip add 10.4.5.5 255.255.255.0
no shut
ip ospf network point-to-point
mpls ip
!
int lo0
ip address 5.5.5.5 255.255.255.255
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
#P4
hostname P4
!
int Gi0/0/0/0
ip add 10.2.4.4/24
no shut
!
int Gi0/0/0/1
ip add 10.3.4.4/24
no shut
!
int Gi0/0/0/2
ip add 10.4.5.4/24
no shut
!
int lo0
ip address 4.4.4.4/32
!
router ospf 1
area 0
int gi0/0/0/0
network point-to-point
int gi0/0/0/1
network point-to-point
int gi0/0/0/2
network point-to-point
int lo0
!
mpls ldp
int gi0/0/0/0
int gi0/0/0/1
int gi0/0/0/2
#PE2
hostname PE2
!
vrf CUSTOMER_A
address-family ipv4 unicast
import route-target 1:1
export route-target 1:1
!
int Gi0/0/0/0
vrf CUSTOMER_A
ip add 100.64.0.5/30
no shut
!
int Gi0/0/0/1
ip add 10.2.4.2/24
no shut
!
int lo0
ip address 2.2.2.2/32
!
router ospf 1
area 0
int gi0/0/0/1
network point-to-point
int lo0
!
mpls ldp
int gi0/0/0/1
!
route-policy PASS
pass
end-policy
!
router bgp 100
address-family ipv4 unicast
address-family vpnv4 unicast
neighbor 1.1.1.1
remote-as 100
update-source lo0
address-family vpnv4 unicast
vrf CUSTOMER_A
rd 1:1
address-family ipv4 unicast
neighbor 100.64.0.6
remote-as 65001
address-family ipv4 unicast
route-policy PASS in
route-policy PASS out
#CE1
hostname CE1
!
line con 0
logging sync
!
int Gi1
ip add 100.64.0.2 255.255.255.252
no shut
!
int lo0
ip address 10.1.1.1 255.255.255.0
!
router bgp 65000
neighbor 100.64.0.1 remote-as 100
network 10.1.1.0 mask 255.255.255.0
#CE2
hostname CE2
!
line con 0
logging sync
!
int Gi1
ip add 100.64.0.6 255.255.255.252
no shut
!
int lo0
ip address 10.1.2.1 255.255.255.0
!
router bgp 65001
neighbor 100.64.0.5 remote-as 100
network 10.1.2.0 mask 255.255.255.0
Pings between CE1 and CE2 should succeed and take the path PE1-P3-P4-PE2
CE1#ping 10.1.2.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/18/50 ms
CE1#traceroute 10.1.2.1 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 10.1.2.1
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 1 msec
2 10.1.3.3 [MPLS: Labels 21/24008 Exp 0] 13 msec
3 10.3.4.4 [MPLS: Labels 24005/24008 Exp 0] 9 msec
4 10.2.4.2 [MPLS: Label 24008 Exp 0] 10 msec
5 100.64.0.6 12 msec
P3#show mpls forwarding-table 2.2.2.2
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
21 24005 2.2.2.2/32 2977 Gi2 10.3.4.4
To expose the issue when LDP sync is not configured. We’ll bring down LDP between P3 and P4 but leave the IGP up. To accomplish this, we’ll implement LDP authentication on all routers, P3, P4, P5 but “forget” to put the password for neighbor 3.3.3.3 on P4.
#P3
mpls ldp neighbor 4.4.4.4 password my_password
mpls ldp neighbor 5.5.5.5 password my_password
#P5
mpls ldp neighbor 3.3.3.3 password my_password
mpls ldp neighbor 4.4.4.4 password my_password
#P4
mpls ldp neighbor 5.5.5.5:0 password clear my_password
! We are not configuring the password for neighbor 3.3.3.3:0 in order to purposefully break the session.
After you clear LDP sessions, you should see no LDP session between P3 and P4:
RP/0/0/CPU0:P4#show mpls ldp neighbor br
Tue Jul 26 23:35:41.927 UTC
Peer GR NSR Up Time Discovery Addresses Labels
ipv4 ipv6 ipv4 ipv6 ipv4 ipv6
----------------- -- --- ---------- ---------- ---------- ------------
2.2.2.2:0 N N 00:22:18 1 0 2 0 10 0
5.5.5.5:0 N N 00:00:39 1 0 3 0 10 0
P3’s shortest path to 2.2.2.2 is still via P4 though. Remember the OSPF neighborship is still up between P3 and P4, but P3 is not learning P4’s label binding for the 2.2.2.2 prefix. Therefore P3 will forward labeled traffic destined to 2.2.2.2 unlabeled to P4.
P3#show mpls forwarding-table 2.2.2.2
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
21 2.2.2.2/32 254 Gi2 10.3.4.4
Traffic between the CEs no longer works:
CE1#ping 10.1.2.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
.....
Success rate is 0 percent (0/5)
Let’s enable LDP sync and see if that fixes the issue. LDP sync is configured under the IGP configuration.
#P3, P4, P5
router ospf 1
mpls ldp sync
P3’s nexthop for 2.2.2.2/32 is now R5:
P3#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 10.3.5.5 on GigabitEthernet3, 00:00:58 ago
Routing Descriptor Blocks:
* 10.3.5.5, from 2.2.2.2, 00:00:58 ago, via GigabitEthernet3
Route metric is 4, traffic share count is 1
P3#show mpls forwarding-table 2.2.2.2
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
21 2.2.2.2/32 77 Gi3 10.3.5.5
Through P3’s LDP session with P5, it has learned P5’s label binding for 2.2.2.2. Traffic between the CEs is working again:
CE1#ping 10.1.2.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/10/11 ms
CE1#traceroute 10.1.2.1 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 10.1.2.1
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 1 msec
2 10.1.3.3 [MPLS: Labels 21/24008 Exp 0] 11 msec
3 10.3.5.5 [MPLS: Labels 22/24008 Exp 0] 12 msec
4 10.4.5.4 [MPLS: Labels 24005/24008 Exp 0] 10 msec
5 10.2.4.2 [MPLS: Label 24008 Exp 0] 11 msec
6 100.64.0.6 11 msec
How does this work? P3 and P4 know that they should be forming an LDP neighborship on the link between themselves, since there is an OSPF neighborship up. However, since the LDP session is down, they each advertise the link with the max metric, which is 65535 in OSPF. This means that the associated link is always going to be the least preferred path. This roughly similar to the STP uplinkfast feature, in which a switch’s bridge priority changes from 32768 to 49152 and port costs are increased by 3000. The idea with LDP sync is to make the link undesirable. The idea with uplinkfast is to make the switch undesirable to become the root bridge.
Let’s bring the LDP session up between P3 and P4 by configuring the correct password on P4:
P3#show mpls forwarding-table 2.2.2.2
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
21 24005 2.2.2.2/32 91378 Gi2 10.3.4.4
The interface metric is back to the normal metric value of 1:
While the LDP session was coming up, I ran an extended ping between CE1 and CE2 and did not lose a single ping:
CE1#ping 10.1.2.1 source lo0 repeat 10000
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 7/10/29 ms
Lab (ISIS)
For completeness, we’ll tear down OSPF, implement ISIS, and test LDP sync again.
First we will replace OSPF with ISIS:
#PE1
no router ospf 1
!
router isis
net 49.0001.0000.0000.0001.00
is-type level-2-only
!
int Gi2
no ip ospf network point-to-point
ip router isis
isis network point-to-point
!
int lo0
ip router isis
#P3
no router ospf 1
!
router isis
net 49.0001.0000.0000.0003.00
is-type level-2-only
!
int range Gi1-3
no ip ospf network point-to-point
ip router isis
isis network point-to-point
!
int lo0
ip router isis
#P5
no router ospf 1
!
router isis
net 49.0001.0000.0000.0005.00
is-type level-2-only
!
int range Gi1-2
no ip ospf network point-to-point
ip router isis
isis network point-to-point
!
int lo0
ip router isis
#P4
no router ospf 1
!
router isis 1
net 49.0001.0000.0000.0004.00
is-type level-2-only
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
int Gi0/0/0/2
point-to-point
address-family ipv4 unicast
int lo0
address-family ipv4 unicast
#PE2
no router ospf 1
!
router isis 1
net 49.0001.0000.0000.0002.00
is-type level-2-only
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
int lo0
address-family ipv4 unicast
CE1 should be able to ping CE2 again:
CE1#ping 10.1.2.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/12 ms
CE1#traceroute 10.1.2.1 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 10.1.2.1
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.0.1 2 msec
2 10.1.3.3 [MPLS: Labels 21/24008 Exp 0] 12 msec
3 10.3.4.4 [MPLS: Labels 24005/24008 Exp 0] 10 msec
4 10.2.4.2 [MPLS: Label 24008 Exp 0] 9 msec
5 100.64.0.6 11 msec
We’ll break the LDP session again by removing the neighbor 3.3.3.3 password on P4
no mpls ldp neighbor 3.3.3.3:0 password
Our L3VPN is broken again (feel free to test this yourself). Let’s turn on LDP sync under the ISIS config on P3, P4 and P5.
#P3, P5
router isis
mpls ldp sync
Before we configure P4, let’s stop here and consider what the state of our L3VPN is right now. Do you think it is fully broken, half broken, or fixed?
P3 has adjusted its Gi2 metric to the max metric (which is 63 since we did not enable wide-metrics).
P3#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "isis", distance 115, metric 40, type level-2
Redistributing via isis
Last update from 10.3.5.5 on GigabitEthernet3, 00:04:39 ago
Routing Descriptor Blocks:
* 10.3.5.5, from 2.2.2.2, 00:04:39 ago, via GigabitEthernet3
Route metric is 40, traffic share count is 1
P3#show isis data P3.00-00 detail
IS-IS Level-2 LSP P3.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
P3.00-00 * 0x00000007 0x706A 866/* 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: P3
Metric: 10 IS PE1.00
Metric: 10 IS P5.00
Metric: 63 IS P4.00
IP Address: 3.3.3.3
Metric: 10 IP 10.1.3.0 255.255.255.0
Metric: 63 IP 10.3.4.0 255.255.255.0
Metric: 10 IP 10.3.5.0 255.255.255.0
Metric: 10 IP 3.3.3.3 255.255.255.255
However, P4 does not have LDP sync turned on yet, so its Gi0/0/0/1 interface is still at the default metric (10), even though LDP is not up on the interface.
P3#show isis data P4.00-00 detail
IS-IS Level-2 LSP P4.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
P4.00-00 0x00000007 0x149F 1059/1199 0/0/0
Area Address: 49.0001
Metric: 10 IS P3.00
Metric: 10 IS P5.00
Metric: 10 IS PE2.00
Metric: 10 IP 4.4.4.4 255.255.255.255
Metric: 10 IP 10.2.4.0 255.255.255.0
Metric: 10 IP 10.3.4.0 255.255.255.0
Metric: 10 IP 10.4.5.0 255.255.255.0
NLPID: 0xCC
IP Address: 4.4.4.4
Hostname: P4
This means that traffic will be one-way only. Traffic from CE1 to CE2 works, but traffic from CE2 to CE1 is dropped at P4.
Here is a pcap at the PE2-CE2 link. CE2 is replying to the ICMP request:
At the PE1-P3 link, only the ICMP request from CE1 is seen:
Let’s add LDP sync under isis in P4 now. On IOS-XR for ISIS, ldp sync is configured per-interface under the interface address-family:
router isis 1
int gi0/0/0/0
address-family ipv4 unicast
mpls ldp sync
int gi0/0/0/1
address-family ipv4 unicast
mpls ldp sync
int gi0/0/0/2
address-family ipv4 unicast
mpls ldp sync
P4 now advertises its link to P3 as metric 63:
P3#show isis data P4.00-00 detail
IS-IS Level-2 LSP P4.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
P4.00-00 0x00000010 0xF381 1189/1199 0/0/0
Area Address: 49.0001
Metric: 10 IS PE2.00
Metric: 10 IS P5.00
Metric: 63 IS P3.00
Metric: 10 IP 4.4.4.4 255.255.255.255
Metric: 10 IP 10.2.4.0 255.255.255.0
Metric: 10 IP 10.3.4.0 255.255.255.0
Metric: 10 IP 10.4.5.0 255.255.255.0
NLPID: 0xCC
IP Address: 4.4.4.4
Hostname: P4
Traffic between CE1 and CE2 is working again, and taking the P3-P5-P4 path:
Actually, first, one more pop quiz,. What happens when two neighbors have differing metric stlyes? Will the neighborship go down? If not, will there still be reachability?
First I configure PE1 for wide metrics, but not P3. The neighborship is still up, but P3 does not know how to reach 1.1.1.1/32. A handy command show isis topology displays ** for the metric of PE1, which lets us know that there is a metric-style mismatch.
P3#show isis neighbors
System Id Type Interface IP Address State Holdtime Circuit Id
PE1 L2 Gi1 10.1.3.1 UP 23 02
P4 L2 Gi2 10.3.4.4 UP 24 00
P5 L2 Gi3 10.3.5.5 UP 25 01
P3#show ip route 1.1.1.1
% Network not in table
P3#show isis topology
IS-IS TID 0 paths to level-2 routers
System Id Metric Next-Hop Interface SNPA
PE1
PE2 30 P5 Gi3 5254.0018.94af
P3 --
P4 20 P5 Gi3 5254.0018.94af
P5 10 P5 Gi3 5254.0018.94af
After configuring metric-style wide on all routers, we can see that the P3-P4 link has a metric of 16777214! This is 2^24 -2. As a note, narrow metrics (the default) are 6 bits, and the max value is 2^6 - 1 = 63. It is interesting that the max wide metric is not 16777215. I’m not quite sure why Cisco subtracts 2 from 2^24 instead of 1.
Cisco will allow you to use 16777215, but warns you that this is for compatibility with older versions:
P3(config-if)#isis metric ?
0 metric 0 for compatibility with older versions
16777215 maximum metric for compatibility with older versions
<1-16777214> Default metric
maximum Maximum metric. All routers will exclude this link from their
SPF
P3#show isis data P3.00-00 detail
IS-IS Level-2 LSP P3.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
P3.00-00 * 0x00000014 0xD989 1084/* 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: P3
Metric: 10 IS-Extended PE1.00
Metric: 16777214 IS-Extended P4.00
Metric: 10 IS-Extended P5.00
IP Address: 3.3.3.3
Metric: 10 IP 3.3.3.3/32
Metric: 10 IP 10.1.3.0/24
Metric: 16777214 IP 10.3.4.0/24
Metric: 10 IP 10.3.5.0/24
P3#show isis data P4.00-00 detail
IS-IS Level-2 LSP P4.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
P4.00-00 0x00000011 0x5C1E 1130/1199 0/0/0
Area Address: 49.0001
NLPID: 0xCC
IP Address: 4.4.4.4
Hostname: P4
Metric: 10 IS-Extended PE2.00
Metric: 16777214 IS-Extended P3.00
Metric: 10 IS-Extended P5.00
Metric: 10 IP 4.4.4.4/32
Metric: 10 IP 10.2.4.0/24
Metric: 10 IP 10.3.4.0/24
Metric: 10 IP 10.4.5.0/24
P3#
LDP IGP Sync Holddown Timer
By default, the IGP will wait indefinitely for LDP to come up. The idea is that the IGP will not even form an adjacency on the link if LDP is not up. (I have found in my own labbing that I can only reproduce this when the routers have never established an IGP adjacency in the first place. If they have already established an IGP adjancency, and then I break LDP, I can't get them to then never establish IGP adjacency again. See the article on "Troubleshooting OSPF Adjacencies" here for more information on this.)
On IOS-XE you can configure a holddown timer. If this timer expires and LDP is still not up, the IGP will form an adjancency anyways, and advertise the link as the max metric. I could not find a way to implement this in IOS-XR.
This would configure the holddown time for 10 seconds:
P3(config)#mpls ldp igp sync holddown ?
<1-2147483647> Hold down time in milliseconds
P3(config)#mpls ldp igp sync holddown 10000
Sync Delay
On both IOS-XE and IOS-XR, you can delay IGP metric adjustment after LDP establishes using the sync delay timer. On IOS-XE you can configure a time of 5-60 seconds. On IOS-XR the timer range is 5-300 seconds.
We’ll configure a timer on both P3 and P4, then add the LDP authentication to P4 again. LDP will wait for the specified delay interval before notifying the IGP that it is up. You may want to use this in case LDP bounces up and down. This command requires that LDP stay up for the entire delay interval before the IGP adjusts the link back to the default metric.
*Jul 27 14:43:03.812: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (3) is UP
P3#show clock
*14:43:08.422 UTC Wed Jul 27 2022
P3#show isis data P3.00-00 detail | in 10.3.4.0
Metric: 16777214 IP 10.3.4.0/24
P3#show clock
*14:43:59.288 UTC Wed Jul 27 2022
P3#show isis data P3.00-00 detail | in 10.3.4.0
Metric: 16777214 IP 10.3.4.0/24
P3#show clock
*14:44:04.471 UTC Wed Jul 27 2022
P3#show isis data P3.00-00 detail | in 10.3.4.0
Metric: 10 IP 10.3.4.0/24
LDP/IGP Sync is a feature that prevents blackholing of VPN traffic by de-preferring an IGP link if there is no functional LDP session on that link. The IGP (OSPF or ISIS) advertises the link with the maximum metric. This ensures that if there is any other path to the destination, that other path will be used. Once the LDP session is up on the interface, the IGP advertises the link with the normal metric again. You can configure a sync delay time, so that LDP will wait up to 60 seconds (IOS XE) or up to 300 seconds (IOS XR) before notifying the IGP that the LDP is up. This ensures that LDP is stable before reducing the IGP metric back to the normal metric value.
LDP/IGP Sync is a feature that you should always have configured in your core. There is no reason not to have this configured. Failing to configure the feature in fact leaves you open to issues if and when LDP and IGP reconverge. In this lab we broke LDP purposefully to examine the functionality of the feature. But even if the IGP simply converges faster than LDP for a second or two, you can drop traffic during that period.
A huge benefit of SR (Segment Routing) is that there is no need to worry about this sync problem. In SR, the labels are advertised within the IGP itself using new TLVs (ISIS) or LSAs (OSPF). LDP is no longer needed to disseminate label bindings for IGP prefixes. If you migrate to SR, you can completely remove LDP and LDP sync.
