Description

During MLA testing in 22.3R3-S1, I noticed LDP label advertisement issue to LDP speaking nodes following link flap.

 

R1--(ae20.10)--R2--(ae30)--R3---(ae20.10)---R4

|                                                                        |

|------------------------(ae30)-----------------|

 

In the above topology, all the nodes are running OSPF/SR along with LDP/SR stitching and uLoop avoidance enabled. There is an LDP speaking node hanging of R2 and as per test topology it is sending traffic to a destination that sits behind R3.

 

VLLG (LDP only node) ----(ae302)----R2----(ae30)----R3----ae112----

 

 

When ae30 is down and up again, R2 stops advertising LDP label to VLLG for the loopback IP of R3 (1.1.1.1) for around 30 seconds hence causing a traffic blackhole.

 

R2> show ldp database session 2.2.2.2 | match "in|out|1.1.1.1" | refresh 2

 

---(refreshed at 2024-02-19 17:34:18 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

1369 1.1.1.1/32

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

683 1.1.1.1/32

 

 

ae30 is already down, and now it has been enabled again, it can be seen from the output below it is advertising label 683 to VLLG for the destination 1.1.1.1

 

---(refreshed at 2024-02-19 17:37:11 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

1369 1.1.1.1/32

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

683 1.1.1.1/32

 

 

when the ae30 is up and OSPF is in full state it stops advertising the LDP label for a couple of seconds and starts advertising label 3 which is not expected.

 

 

---(refreshed at 2024-02-19 17:37:13 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

---(refreshed at 2024-02-19 17:37:15 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

---(refreshed at 2024-02-19 17:37:17 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

3 1.1.1.1/32

 

---(refreshed at 2024-02-19 17:37:19 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

1379 1.1.1.1/32

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

3 1.1.1.1/32

 

 

after 25-30 seconds it starts advertising a new LDP label and after that traffic is fully recovered.

 

---(refreshed at 2024-02-19 17:37:39 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

1381 1.1.1.1/32

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

830 1.1.1.1/32

 

---(refreshed at 2024-02-19 17:37:41 AEDT)---

 

Input label database, 3.3.3.3:0--2.2.2.2:0

 

1381 1.1.1.1/32

 

Output label database, 3.3.3.3:0--2.2.2.2:0

 

830 1.1.1.1/32

 

 

 

When MLS is disabled, this behaviour is not observed and LDP outgoing label never changes.

Symptoms

When the Microloop Avoidance is enabled for Segment Routing for OSPF, the LDP label advertisement gets stopped for approximately 25 seconds. When the label advertisement is stopped traffic loss will be seen. This issue will be specifically seen when the interface between LDP domains flaps and is coming up.

Solution

This problem is fixed by PR1793148 in below releases onwards.

evo:22.3R3-S3-EVO evo:23.4R2-EVO evo:24.1R2-EVO evo:24.2R1-EVO evo:24.3R1-EVO

junos:23.4R2 junos:24.1R2 junos:24.2R1

Modification History

2024-04-02 : Article Created