# LDP/IGP Sync

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 <a href="#dafeebc0-7beb-4fe1-9289-a16933713de8" id="dafeebc0-7beb-4fe1-9289-a16933713de8"></a>

We’ll use the following topology to explain the theory behind LDP/IGP sync.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FWwYo84HxNf4K2JKao3Ry%2FUntitled.png?alt=media&#x26;token=2f500c70-d1f8-485f-842d-b15dc0cba93c" alt=""><figcaption></figcaption></figure>



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) <a href="#c2385232-bf21-468a-b2a8-5b043f52a63a" id="c2385232-bf21-468a-b2a8-5b043f52a63a"></a>

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.

<pre><code>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         <a data-footnote-ref href="#user-content-fn-1">No Label</a>   2.2.2.2/32       254           Gi2        10.3.4.4
</code></pre>



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:

<pre><code>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         <a data-footnote-ref href="#user-content-fn-2">22       </a>  2.2.2.2/32       77            Gi3        10.3.5.5
</code></pre>



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.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2Fl7Idco9Rv7t6xitm2P71%2FUntitled%201.png?alt=media&#x26;token=a441a952-97ac-4686-8113-2ce7d23de82d" alt=""><figcaption></figcaption></figure>



Let’s bring the LDP session up between P3 and P4 by configuring the correct password on P4:

```
mpls ldp neighbor 3.3.3.3:0 password clear my_password
```



P3 now has a next-hop of P4 for 2.2.2.2/32

```
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:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FMqB5rdA30PmUXfFI9ZuM%2FUntitled%202.png?alt=media&#x26;token=04c4ee11-c5c8-44e5-9c67-d06f7a865ed3" alt=""><figcaption></figcaption></figure>



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
```

#### &#x20;<a href="#b3ce7ac3-ac0e-49af-8b8b-3f7814be5821" id="b3ce7ac3-ac0e-49af-8b8b-3f7814be5821"></a>

### Lab (ISIS) <a href="#b3ce7ac3-ac0e-49af-8b8b-3f7814be5821" id="b3ce7ac3-ac0e-49af-8b8b-3f7814be5821"></a>

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:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FJqxRymfjbEEQ5UuIjvFj%2FUntitled%203.png?alt=media&#x26;token=2e2aa2ef-10f1-4f23-8e54-6eee3a8c6b58" alt=""><figcaption></figcaption></figure>



At the PE1-P3 link, only the ICMP request from CE1 is seen:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FR1XOXvy1wGghuZGNDjlt%2FUntitled%204.png?alt=media&#x26;token=f01613f4-7af0-478b-87cd-77e70ec42a5d" alt=""><figcaption></figcaption></figure>



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:

```
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.5.5 [MPLS: Labels 22/24008 Exp 0] 11 msec
  4 10.4.5.4 [MPLS: Labels 24005/24008 Exp 0] 11 msec
  5 10.2.4.2 [MPLS: Label 24008 Exp 0] 11 msec
  6 100.64.0.6 12 msec
```



Pop quiz! If we change the ISIS metrics to wide-metrics, do you know what the metric will be on the P3-P4 link?



Let’s try it to find out:

```
#PE1, P3, P5
router isis
metric-style wide

#P4, PE2
router isis 1
 address-family ipv4 unicast
  metric-style wide
```



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.

<pre><code>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                  <a data-footnote-ref href="#user-content-fn-3">**</a>
PE2                  30         P5                   Gi3         5254.0018.94af 
P3                   --
P4                   20         P5                   Gi3         5254.0018.94af 
P5                   10         P5                   Gi3         5254.0018.94af 
</code></pre>



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#
```

#### &#x20;<a href="#id-3a43b0b7-08b6-4bda-883f-adce1fcaa973" id="id-3a43b0b7-08b6-4bda-883f-adce1fcaa973"></a>

### LDP IGP Sync Holddown Timer <a href="#id-3a43b0b7-08b6-4bda-883f-adce1fcaa973" id="id-3a43b0b7-08b6-4bda-883f-adce1fcaa973"></a>

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 ](https://ccnp-sp.gitbook.io/studyguide/routing/ospf/troubleshooting-ospf-adjacencies#cc97575f-2048-4ee4-b4bf-cff999771e7a)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
```

#### &#x20;<a href="#id-4e81104b-ea6c-45e6-ac41-cf37e3f4b2a2" id="id-4e81104b-ea6c-45e6-ac41-cf37e3f4b2a2"></a>

#### Sync Delay <a href="#id-4e81104b-ea6c-45e6-ac41-cf37e3f4b2a2" id="id-4e81104b-ea6c-45e6-ac41-cf37e3f4b2a2"></a>

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.

```
#P3
int Gi2
 mpls ldp igp sync delay 60

#P4
mpls ldp neighbor 3.3.3.3:0 password clear my_password
mpls ldp int Gi0/0/0/1
 igp sync delay on-session-up 60
 
```

```
*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
```

#### &#x20;<a href="#b390c4b1-5095-4585-bd94-048cd2172fc3" id="b390c4b1-5095-4585-bd94-048cd2172fc3"></a>

### Verification <a href="#b390c4b1-5095-4585-bd94-048cd2172fc3" id="b390c4b1-5095-4585-bd94-048cd2172fc3"></a>

```
P3#show mpls ldp igp sync
    GigabitEthernet1:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync achieved; peer reachable.
        Sync delay time: 0 seconds (0 seconds left)
        IGP holddown time: infinite.
        Peer LDP Ident: 1.1.1.1:0
        IGP enabled: ISIS null
    GigabitEthernet2:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync not achieved; peer reachable.
        Sync delay time: 60 seconds (0 seconds left)
        IGP holddown time: infinite.
        IGP enabled: ISIS null
    GigabitEthernet3:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync achieved; peer reachable.
        Sync delay time: 0 seconds (0 seconds left)
        IGP holddown time: infinite.
        Peer LDP Ident: 5.5.5.5:0
        IGP enabled: ISIS null


RP/0/0/CPU0:P4#show mpls ldp igp sync br
Wed Jul 27 14:56:29.072 UTC

Interface                  VRF Name                          Status   
-------------------------  --------------------------------  ---------
Gi0/0/0/0                  default                           Ready    
Gi0/0/0/1                  default                           Not ready
Gi0/0/0/2                  default                           Ready

RP/0/0/CPU0:P4#show mpls ldp igp sync 
Wed Jul 27 14:56:27.312 UTC

GigabitEthernet0/0/0/0:
  VRF: 'default' (0x60000000)
  Sync delay: Disabled
  Sync status: Ready
    Peers:
      2.2.2.2:0

GigabitEthernet0/0/0/1:
  VRF: 'default' (0x60000000)
  Sync delay: 60 sec
  Sync status: Not ready (No peer session)

GigabitEthernet0/0/0/2:
  VRF: 'default' (0x60000000)
  Sync delay: Disabled
  Sync status: Ready
    Peers:
      5.5.5.5:0
```

#### &#x20;<a href="#f7c43fc4-7487-4300-a653-9a85ccac80ab" id="f7c43fc4-7487-4300-a653-9a85ccac80ab"></a>

### Conclusion <a href="#f7c43fc4-7487-4300-a653-9a85ccac80ab" id="f7c43fc4-7487-4300-a653-9a85ccac80ab"></a>

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.

[^1]: This indicates that P3 has not learned a label for 2.2.2.2/32 from its neighbor, P4. (The LDP session is down).

[^2]: P3 is now using R5 as the next hop. P3 has learned label 22 from R5 over their LDP session.

[^3]: This indicates a metric style mismatch
