cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4635
Views
5
Helpful
4
Replies
dmalla
Beginner

T-LDP over RSVP-TE

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

!

4 REPLIES 4
Mohammed Imran Khan
Cisco Employee

Hi,

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

1st 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”.

2nd 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.

3rd 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

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.

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

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."