This article outlines a scenario that may lead to the failure of multiple E-Line services on a router
Local End
root@PE1_RE> show l2circuit connections neighbor 5.5.5.5
Layer-2 Circuit Connections:
...
Neighbor: 5.5.5.5
Interface Type St Time last up # Up trans
ge-0/0/1.100(vc 100) rmt VC-Dn ----- 0
Remote PE: 5.5.5.5, Negotiated control-word: Yes (Null)
Incoming label: 18, Outgoing label: 17
Negotiated PW status TLV: No
Local interface: ge-0/0/1.100, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
root@PE1_RE> show ldp session
Address State Connection Hold time Adv. Mode
5.5.5.5 Operational Open 22 DU
root@PE1_RE> show route 5.5.5.5
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.5.5.5/32 *[BGP/170] 18:06:10, localpref 100, from 22.22.22.22
AS path: 65000 65011 I, validation-state: unverified
> to 192.168.10.5 via ge-0/1/1.0
Remote End
root@PE2_RE> show l2circuit connections neighbor 3.3.3.3
Neighbor: 3.3.3.3
ge-0/0/2.100(vc 100) rmt OL
root@PE2_RE> show ldp session
3.3.3.3 Operational Open 22 DU
root@PE2_RE> show route 3.3.3.3
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
3.3.3.3/32 *[BGP/170] 18:06:45, localpref 100, from 4.4.4.4
AS path: 65000 65010 I, validation-state: unverified
> to 192.168.11.5 via ge-0/1/1.0
inet.3: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
3.3.3.3/32 *[BGP/170] 18:06:42, localpref 100, from 4.4.4.4
> to 192.168.11.5 via ge-0/1/1.0, Push 26
L2CKT Label Advertisement - Only PE2 advertising L2CKT label
root@PE1_RE> show ldp database session 5.5.5.5 | match "input|output|l2ckt"
Input label database, 3.3.3.3:0--5.5.5.5:0
17 L2CKT CtrlWord VLAN VC 100
Output label database, 3.3.3.3:0--5.5.5.5:0
root@PE2_RE> show ldp database session 3.3.3.3 | match "input|output|l2ckt"
Input label database, 5.5.5.5:0--3.3.3.3:0
Output label database, 5.5.5.5:0--3.3.3.3:0
According to the logs, PE1 (3.3.3.3) is missing a valid BGP-labeled route to PE2 (5.5.5.5) in the inet.3 table, which may impact L2VPN or L3VPN service reachability.
root@PE1_RE> show route 5.5.5.5 hidden
inet.3: 9 destinations, 9 routes (6 active, 0 holddown, 3 hidden)
5.5.5.5/32 [BGP/170] 18:07:18, localpref 100, from 22.22.22.22
Unusable
root@PE1_RE> show route 5.5.5.5 hidden extensive | match prot
Protocol next hop: 22.22.22.22
root@PE1_RE> show route 22.22.22.22
22.22.22.22/32 *[IS-IS/18] 18:08:09, metric 10
Based on the logs, the protocol nexthop for route 5.5.5.5 received on PE1 was set to 22.22.22.22. However, 22.22.22.22 did not have a valid MPLS label, preventing proper packet forwarding.
Upon investigation, we found that a policy change on the Route Reflector had modified the nexthop from 2.2.2.2 to 22.22.22.22. Further inspection of PE1 revealed that 2.2.2.2 was a labeled route, while 22.22.22.22 was not.
After correcting the configuration (details not shown here) to advertise route 5.5.5.5 with nexthop 2.2.2.2, the issue was resolved.
Note: This policy change was only affecting PE1.
5.5.5.5/32 *[BGP/170] 00:00:13, localpref 100, from 2.2.2.2
5.5.5.5/32 *[BGP/170] 00:00:12, localpref 100, from 2.2.2.2
> to 192.168.10.5 via ge-0/1/1.0, Push 39
root@PE1_RE> show route 5.5.5.5 extensive | match prot
Protocol next hop: 192.168.10.1
Protocol next hop: 192.168.10.1 Metric: 20
Protocol next hop: 2.2.2.2
Protocol next hop: 2.2.2.2 Metric: 1
root@PE1_RE> show route 2.2.2.2
2.2.2.2/32 *[IS-IS/18] 21:46:25, metric 10
2.2.2.2/32 *[LDP/9] 18:20:34, metric 1
ge-0/0/1.100(vc 100) rmt Up Jul 17 01:06:57 2025 1
ge-0/0/2.100(vc 100) rmt Up Jul 17 01:06:57 2025 1
Remote PE: 3.3.3.3, Negotiated control-word: Yes (Null)
Incoming label: 17, Outgoing label: 18
Local interface: ge-0/0/2.100, Status: Up, Encapsulation: VLAN