Re: T-LDP over RSVP-TE

dmalla · ‎04-09-2013

Hi all,

I have a following scenario where I need to ping between CPE1 and CPE2.

RSVP RSVP RSVP RSVP

CPE1 ---------- R7 --------------------- R3 --------------------- R1 ------------------- R5 ------------------ R11 ----------- CPE2

10.0.0.1/24 |<---------------------->| <--------------------------------------------> | <------------------> | 10.0.0.2/24

OSPF Area 1 OSPF Area 0 OSPF Area 2

NSSA with NSSA with

no summary no summary

| <------------------------------------------------------------------------------------------------>|

Pseudowire VC ID 100

(R3, R1, and R5 loopbacks are on area 0)

There is a TE tunnel between R7 to R3, R3 to R5, and R5 to R11 and vice-versa. All TE tunnels are up in both directions and "mpls ip" is enabled on all TE tunnels (for LDP tunneling). There is a Pseudowire configured between R7 and R11 and it is up. However, I am unable to ping from CPE1 to CPE2.

Any help to identify the issue would be much appreciate. I have posted the configuration from R7 and R11.

Configuration on R7

!

pseudowire-class PRIMARY-PATH

encapsulation mpls

preferred-path interface Tunnel73

!

interface Tunnel73

ip unnumbered Loopback0

mpls ip

tunnel mode mpls traffic-eng

tunnel destination 172.16.0.3

tunnel mpls traffic-eng path-option 1 dynamic

!

interface FastEthernet0/0

xconnect 172.16.2.11 100 pw-class PRIMARY-PATH

!

Configuration on R11

!

pseudowire-class PRIMARY-PATH

encapsulation mpls

preferred-path interface Tunnel115

!

interface Tunnel115

ip unnumbered Loopback0

mpls ip

tunnel mode mpls traffic-eng

tunnel destination 172.16.0.5

tunnel mpls traffic-eng path-option 1 dynamic

!

interface FastEthernet0/0

xconnect 172.16.1.7 100 pw-class PRIMARY-PATH

!

Mohammed Imran Khan · ‎04-10-2013

Hi,

I see that this solution will not work because there are 3 major issues here:

1^st is using no-summary with NSSA will install a default route. That means no label will be generated for the remote end loopback. LSP will simply fail. For this use only “area x nssa”.

2^nd is even if all the prefixes are now present after using the “area x nssa”, there will be no outgoing label (only local labels) because there is no ldp on the interfaces, only on the tunnel. For this autoroute announce need to be used on all the tunnels. This will resolve the lsp issue.

Again using “area x nssa no-summary” and autoroute announce will show the prefixes in the forwarding table but will not show any outgoing labels.

3^rd is using the “preferred-path tunnel x” within the pseudowire. You should not use it because the tailend is core, not the remote end PE. See the usage guidelines here:

http://www.cisco.com/en/US/docs/ios/12_2sr/12_2sra/feature/guide/srtunsel.html#wp1057815

With preferred-path command, only 1 label is seen.

R7#show mpls l2transport vc deta

Local interface: Et0/1 up, line protocol up, Ethernet up

Destination address: 9.9.0.11, VC ID: 100, VC status: up

Output interface: Tu73, imposed label stack {1100} >> this will cause pseudowire ping to fail as there is no outer label to reach 9.9.0.11

Without preferred-path command, 2 labels are seen.

R7#sh mpls l2 vc 100 det

Local interface: Et0/1 up, line protocol up, Ethernet up

Destination address: 9.9.0.11, VC ID: 100, VC status: up

Output interface: Tu73, imposed label stack {304 1108} >> Now we have the outer label also.

CPE1#ping 10.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

CPE1#ping 10.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/2 ms

CPE1#

If these 3 problems are resolved, then you will be able to happily ping the 2 ends.

Please rate the useful posts.

Regards,

Imran

dmalla · ‎04-13-2013

Hi Imran,

Thank you for you response. NSSA no summary in each area is a requirement. This is the main reason to go for RSVP as transport tunnel. There is no Link LDP configuration anywhere except between RSVP tunnel end-points.

In this scenario, we have 3 RSVP segment, viz- R7-R3(Segment 1, area 1), R3-R5 (Segment 2, area 0) and R5-R11 (Segment 3, area 2). I think, we should be able to tunnel LDP packets in each segment to reach to other end.

For issue #1, this is the reason to use RSVP TE as transport tunnel rather than LDP.

Issue #2, there is no outgoing label because the RSVP tunnel tail end is just 1 hop away and PHP is in action.

For issue #3, what is the preferred method to put L2VPN traffic over RSVP-TE tunnels?

Thank you.

Mohammed Imran Khan · ‎04-13-2013

Hi,

>> Issue#1: "this is the reason to use RSVP TE as transport tunnel rather than LDP"

If you are using nssa no-summary in the mpls core, then label bindings will be seen on the control plane, but forwarding plane will show nothing. Using RSVP will resolve control plane issues, but forwarding will not happen.

R7#sh mpls ldp bindings

lib entry: 0.0.0.0/0, rev 6

local binding: label: imp-null

lib entry: 9.9.0.2/32, rev 2

local binding: label: imp-null

remote binding: lsr: 9.9.0.6:0, label: 600

remote binding: lsr: 9.9.0.3:0, label: 300

lib entry: 9.9.0.3/32, rev 7

remote binding: lsr: 9.9.0.6:0, label: 601

remote binding: lsr: 9.9.0.3:0, label: imp-null

lib entry: 9.9.0.4/32, rev 8

remote binding: lsr: 9.9.0.6:0, label: 602

remote binding: lsr: 9.9.0.3:0, label: 301

lib entry: 9.9.0.5/32, rev 9

remote binding: lsr: 9.9.0.6:0, label: 603

remote binding: lsr: 9.9.0.3:0, label: 302

lib entry: 9.9.0.6/32, rev 10

remote binding: lsr: 9.9.0.6:0, label: imp-null

remote binding: lsr: 9.9.0.3:0, label: 303

lib entry: 9.9.23.0/24, rev 4

local binding: label: imp-null

remote binding: lsr: 9.9.0.6:0, label: 604

remote binding: lsr: 9.9.0.3:0, label: imp-null

lib entry: 9.9.34.0/24, rev 11

remote binding: lsr: 9.9.0.6:0, label: 605

remote binding: lsr: 9.9.0.3:0, label: imp-null

lib entry: 9.9.45.0/24, rev 12

remote binding: lsr: 9.9.0.6:0, label: 606

remote binding: lsr: 9.9.0.3:0, label: 304

lib entry: 9.9.56.0/24, rev 13

remote binding: lsr: 9.9.0.6:0, label: imp-null

remote binding: lsr: 9.9.0.3:0, label: 305

R7#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

200 No Label l2ckt() 0 drop

R7#

For this, "no-summary" must be removed. This solution will not work with no-summary.

>> Issue#2: "there is no outgoing label because the RSVP tunnel tail end is just 1 hop away and PHP is in action".

Your destination router R11 is not the very next router. In that case R3 has to generate the local label and pass it on to R7. While tracing LSP from R7 to R11, you will see the first lline as (implicit-null/303). This 303 is the local label generated by R3 for R11 loopback. An implicit-null/PHP label will be generated by R11. R3 will not generate it for R11, right! :-)

>> Issue #3: "what is the preferred method to put L2VPN traffic over RSVP-TE tunnels?"

In this case, "preferred-path int tunnelx" will not work because the remote end is not the egress PE, but a core. If you want the L2 traffic to use the tunnel, you can do 1 thing: Since autorute announce is present (as per the design), the path will take tunnel. Use "preferred-path peer "

HTH!

Please rate the useful posts.

Regards,

Imran

Muhammad Thanveer · ‎04-15-2013

good explanation Imran...

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."