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

dodgerfan78 · ‎09-04-2009

Hello,

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 123.1.9.0/24.

Because this in a VRF, R9 creates a VPN label for 123.1.9.0 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 (123.1.9.0/24) 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?

Peter Paluch · ‎09-05-2009

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 123.1.9.0/24 network:

R1#show mpls ip binding 123.1.9.0 24 detail

123.1.9.0/24, rev 4

in label: imp-null

Advertised to:

10.255.255.2:0

out label: 21 lsr: 10.255.255.2:0

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

R1#show mpls forwarding-table 123.1.9.0 24 detail

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

R1#

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 123.1.9.0/24?

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,

Peter

dodgerfan78 · ‎09-08-2009

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 123.1.9.0 24 de

123.1.9.0/24, rev 2, chkpt: none

in label: imp-null (owner LDP)

Advertised to:

123.1.9.9:0

out label: 20 lsr: 123.1.9.9:0

R1#sho mpls forwarding-table 123.1.9.0

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface

None 20 123.1.9.0/24 0 Se1/0 point2point

R1#sho ip cef 123.1.9.9

123.1.9.0/24

attached to Serial1/0 label 20

R1#

And just to show the route as connected:

R1#sho ip route 123.1.9.0

Routing entry for 123.1.9.0/24

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

R1#

Thanks again.

Peter Paluch · ‎09-12-2009

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 123.1.9.9

show mpls ip binding

show ip cef 123.1.9.9 detail

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

Best regards,

Peter

ulatif · ‎09-17-2009

Hi,

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:

R1(CE)----R9(PE)---

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 · ‎09-18-2009

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