cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5760
Views
8
Helpful
21
Replies

Pseudowire over MPLS-TE Tunnels

g.rodegari
Level 1
Level 1

Hi guys,

I'm tring to test interoperability between Cisco an Juniper Boxes about

pseudowire services.

Let assume that I've an MPLS backbone, where the label distribution protocol used is RSVP, then MPLS-TE tunnels, I do not want to enable LDP on my backbone.

Well, as far as I know, pseudowires requires LDP as control protocol... then:

from Juniper side I've enable a feature that they calling "LDP-Tunneling" in order to connect different LDP "islands" through my RSVP Backbone.

Is there a similar feature into IOS? what I've tested is to configure targeted LDP and MPLS-TE tunnels, but seems to do not work fine.

What is happening is that Juniper and Cisco established correctly the LDP targeted session, but discarding the FEC into the advertisement...

Any ideas? Have anyone already tested it before???

Any suggestions is more than appreciated,

Best Regards,

G.

21 Replies 21

Harold Ritter
Cisco Employee
Cisco Employee

Graziano,

All you need on either side is the targeted LDP session.

The JunOS LDP tunneling feature is not needed in this scenario. It is equivalent to enabling LDP on a TE tunnel interface on the IOS side.

On the JunOS side, the targeted LDP session is enabled by the following set of commands:

protocols {

l2circuit {

neighbor x.x.x.x {

interface ge-0/1/0.0 {

virtual-circuit-id 100;

}

}

}

On the IOS side, the targeted LDP session is enabled by the xconnect command.

This type of scenario is common and should work just fine.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hello,

thank you for your suggestion but actually I do not have LDP on my backbone and on the JunOS side I've to enable LDP tunneling, just to transport LDP into the RSVP backbone.

Forget for a second the pseudowire stuff... we have just to connect two LDP network through and RSVP backbone

The LDP tunneling features allow JunOS box to start targeted LDP session toward other boxes with, as source and transport address of this session his Loopback, without using WAN interfaces.

On the IOS side I've configured Tunnel TE interfaces and targeted LDP sessions as ususal... from juniper perspective the tunnel is RSVP and LDP do not needed... the targeted LDP session is established but FECs do not used...

There is a mismatch but I do not know where...

Thanks,

G.

Graziano,

I completely understand the fact that you do not need LDP in the network. LDP is just required between the two PEs in order to succesfully run l2vpn.

You absolutely do not need ldp-tunneling for that purpose.

The targeted LDP session started by ldp-tunneling on one side and running ldp on the tunnel interface on the other side will not help as l2vpn starts its own targeted LDP session.

For the FEC to be used you would need to have a route installed with the LSP or tunnel as the next-hop.

Again if you all you need to achieve is l2vpn between the Juniper and Cisco box, the config I proposed yesterday should be fine.

Let me knoe if you need a more detailed configuration example.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hello Harold,

thank you for your suggestions.Sorry, but,

probably I didn't explane well myself.

Actually L2vpn is just one application, we should have also L3VPN...

The more general stuff is that I need to transport LDP information from one island to an other island through RSVP backbone.

Thanks

G.

Graziano,

Thanks for the additional info. It shouldn't be a problem to get the JunOS ldp-tunneling to work with the IOS ldp over the TE tunnel interface.

As I said, for the FEC received from the targeted LDP session to be used, you need routes to be installed in the FIB with a next hop via the tunnel interface (or the LSP on the JunOS side).

Then in your case, you need to make sure the LDP peer id (targeted LDP peer address) is know via the tunnel interface.

Let me know if you have any issue,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Thank you Harold,

I'll verify that.

Best Regards,

G.

Graziano,

By the way, you do not need to configure LDP over the TE tunnel interface in the case of l3vpn either if the LSP goes all the way from the ingress to the egress PE. Just wanted to make sure that I didn't leave you with the wrong impression.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

So the question drills down to the following scenario: two routers, Cisco and Juniper, they are on two ends of a RSVP domain, you want to tunnel LDP over this RSVP domain, you have configured "tag switching ip" on Cisco's TE interface and "ldp-tunneling" on Juniper's RSVP-LSP, and targeted LDP session is established between Cisco and Juniper, but LDP is not using prefix-FECs advertised from either side.

At this stage, the only reason a prefix-FEC is not used is because the prefix's LDP next hop does not match its IGP next hop, I would check to make sure ospf shortcut is enabled on juniper side and auto-announce is configured on cisco side. Cisco or Juniper box should not be aware that the otherside is a different box, unless, of course, if you want to run MPLS TE FRR between the two.

Can you post the following:

On juniper side, do,

sh route

show ldp database inet session

on Cisco side, do,

sh ip route

sh mpls ldp bindings

Jian,

Depending on the topology, enabling ospf shortcuts might not be sufficient as this will only impact the BGP learnt routes. If IGP routes need to be resolved via the LSP, the mpls traffic-engineering bgp-igp needs to be configured on the JunOS side.

At the end of the day, it largely depends on the topology and whether the TE LSPs are end to end between the PEs. If they are then there is no need to use LDP at all (except for l2vpn signalling) as the PE to PE LSP is already signalled via RSVP.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Forget my comment about the bgp-igp since if the tunnel was between the core routers you wouldn't need to install the route in inet.0 anyway. The only route that would matter in the core would be the one in mpls.0.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi Guys,

thank you for your support, probably I've found something interesting that I'll can check next week.

From JunOS command reference:

" Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks "

Some other vendors use an OSPF metric of 1 for the loopback address. Juniper

Networks routers use an OSPF metric of 0 for the loopback address. This can cause

interoperability problems when you configure LDP tunneling over RSVP LSPs in

heterogeneous networks.

When a Juniper Networks router is linked to another vendor?s router through an

RSVP tunnel, and LDP tunneling is also enabled, by default the Juniper Networks

router might not use the RSVP tunnel to route traffic to the LDP destinations

downstream of the other vendor?s egress router if the RSVP path has a metric of 1

larger than the physical OSPF path.

To ensure that LDP tunneling functions properly in heterogeneous networks, you

can configure OSPF to ignore the RSVP LSP metric by including the

ignore-lsp-metrics statement:

set protocols ospf traffic-engineering shortcuts ignore-lsp-metrics; "

Actually this is the case... indeed Cisco announce via OSPF loopbacks with metric 1...

I'll let you know,

Best Regards,

G.

Hi Guys,

actually it works... now I've to deep understand why? ;-)

Best Regards,

G.

Graziano,

Good catch. The command "ignore-lsp-metrics" makes perfect sense in this context. If JunOS was to consider the metric of LSP when shortcut is configured, it wouldn't push anything through the LSP since the metric of the LSP is one more than the IGP metric to the LSP tail end router. This is because IOS uses a cost of 1 for the loopback interface while JunOS normally uses a cost of 0.

Once the ignore-lsp-metrics is configured all prefixes behind the tail end router should start being seen via the LSP.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi Harold,

the strange thing is that no "shortcuts" have been configured before... but is a Juniper story ;-)

Thanks,

G.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: