CSC - LDP Peering drops between CSC-PE and CSC-CE

Unanswered Question
Sep 4th, 2009


I am doing CSC with IGP/LDP between carriers.

R1 is the second level carrier.

R9 is in the backbone carrier.

R9 has a VRF interface towards R1 with MPLS enabled.

The network is

Because this in a VRF, R9 creates a VPN label for and advertises it to the other PEs.

However, when the R1/R9 LDP session comes up, R9 sends this same label to R1!

R1 then uses this label (I believe erroneously) when sending LDP/TCP keepalives to R9. R9 pops the label off and forwards the packet back out the interface (following the LFIB). R1 then sends it right back! Eventually the LDP session dies because the keepalives are never processed locally by R9. The LFIB flushes, LDP comes back up and the whole thing starts again.

The workaround I have in place is to deny labels for the directly network ( on R1 when received from R9. This works great and things are stable. However, I want to know if there is something else I am missing here.

What is the underlying issue?

Have I misconfigured something?

Is this a bug?

Is this by design?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Peter Paluch Sat, 09/05/2009 - 15:09

Hello Bryan,

This is strange and this is not how things should be working under normal circumstances.

I have put together a very hasty configuration with the basic CSC configuration using IGP/LGP (I've used EIGRP as the IGP - what are you using?) On the R1, I see this regarding the network:

R1#show mpls ip binding 24 detail, rev 4

in label: imp-null

Advertised to:

out label: 21 lsr:

You can see that the R9 (the IP advertised the label 21 for the network (it's the BGP label that is also advertised to the other PE). However, because the is directly connected on R1, the label mapping advertised by R9 never made it into the LFIB on R1:

R1#show mpls forwarding-table 24 detail

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface


Thus, it seems normal that R9 announced the mapping. However, it is not clear why the R1 has taken this label from the LIB and inserted it into its LFIB. I believe we should try to focus on this point - why does R1 use the mapping at all? By the, what does the "show mpls forwarding-table detail" on your R1 and R9 say about the network

And one more question, what kind of link layer technology is used to interconnect the R1 and R9?

Looking forward to hearing from you soon.

Best regards,


dodgerfan78 Tue, 09/08/2009 - 07:25

Thanks for the reply Peter. Your test is exactly as I understand it should be. What model/IOS were you using? I had this issue on 7200s running 12.2S. I tried it with some 3640s and I did not have the issue. I am using a serial HDLC link between R1 and R9.

Here is how it looked on the 7200s, notice the label is being used.

R1#sho mpls ip binding 24 de, rev 2, chkpt: none

in label: imp-null (owner LDP)

Advertised to:

out label: 20 lsr:

R1#sho mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface

None 20 0 Se1/0 point2point

R1#sho ip cef

attached to Serial1/0 label 20


And just to show the route as connected:

R1#sho ip route

Routing entry for

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via Serial1/0

Route metric is 0, traffic share count is 1


Thanks again.

Peter Paluch Sat, 09/12/2009 - 00:05

Hello Bryan,

I'm sorry for replying so lately.

I have used 2691 IOSes to experiment on dynamips - I believe it was 12.4(12) Advanced IP Services or so.

Can you please also post the output of the following commands on R1?

show ip route

show mpls ip binding

show ip cef detail

Also, please, what routing protocol are you using between the R1 and R9?

Best regards,


ulatif Thu, 09/17/2009 - 16:55


I dont think I understand the issue properly, why do you think R1 would use a label when signalling LDP session to a directly connected neighbor i.e. R9 ? should be null label.

I presume this is your scenario:


And you are having a LDP based CsC configuration on R9 for R1 - right?

If that is the case and your LDP session between R1 and R9 is flapping, can you tell me what protocol you are using between R1 and R9 ? e.g. is it OSPF ?

If yes, is OSPF stable between R1 and R9 ?

The only reason LDP would flap is if there is a L1/L2/L3 issue between R1 and R9 e.g. one of the following:

- link issue

- TCP issue

- IGP not configured properly

- CPU related

- keepalives dropping

It is normal (in LDP unsolicited label distribution) for routers to send all labels to each other as LFIB is built using the LIB.

So I think we are not troubleshooting a label issue here but more like how you would troubleshoot a protocol neighbor flapping or TCP session flapping between directly connected peers.

dodgerfan78 Fri, 09/18/2009 - 06:21

What do you mean "Why do I think...". That's exactly what was happening. I posted the output. It's a bug.


This Discussion