Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Traffic engineering within MPLS VPN

Hi all,

I have this scenario:

---P1---

PE1--| |--PE2

---P2---

On the 2 pE are configured different vrf. I have configured two tunnel LSP (with rsvp): one PE1-P1-PE2 (T1) and the other PE1-P2-PE2 (T2).

The question is: how can I create a FEC based on QoS or vrf to forward a specific VPN trafic on T1 rather than T2?

I'd find a scalable solution avoiding static route....

Many Thanks in advance

Gianluca

11 REPLIES

Re: Traffic engineering within MPLS VPN

Hi,

you can configure a different BGP next hop for each tunnel. This loos like this:

PE1

ip route 1.1.1.1 255.255.255.255 Tunnel1

ip route 2.2.2.2 255.255.255.255 Tunnel2

The statics are to send traffic with a specific next hop down a specific tunnel. This static is only required once, no matter how many VRFs are involved.

PE2

ip vrf A

rd 65000:1

bgp next-hop 1.1.1.1

ip vrf B

rd 65000:2

bgp next-hop 2.2.2.2

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip address 2.2.2.2 255.255.255.255 secondary

Also make sure you have "mpls ip" on all Tunnel interfaces.

With the above approach sorting a VRF into a tunnel will only require one statement "bgp next-hop" under the VRF.

If it comes to QoS-wise sorting traffic into the different tunnels, this gets naturally more complicated as it involves traffic description. AFAIK policy-based routing is the only approach.

Hope this helps! Please rate all posts.

Regards, Martin

Community Member

Re: Traffic engineering within MPLS VPN

Hi Martin,

thanks for your answer.

Very very helpful.

P.S. have you some link where I can found something regarding PBR for the TE-qos?

Gianluca

Community Member

Re: Traffic engineering within MPLS VPN

Hi Martin,

one dubt....regarding the forwarding: in this case a packet from PE1 to PE2 will be sent with two label: the inner one that is the vpn label received from PE2 and the exterior that is the label received via RRO rsvp.

Is it correct?

But, If i do a tunnel LSP between a PE and a P, the packet shold be forwarded with 3 label: the vpn label (received by the egress PE), the ldp label (that router P will use to forward traffic towards PE) and the rsvp label (outer label)? is it correct?

If do, how PE'll receive the ldp label?

Many thanks

Gianluca

Re: Traffic engineering within MPLS VPN

Hi,

you need to enable MPLS on the TE tunnel interfaces. Otherwise they are considered as "IP only" and LFIB shows "untagged".

interface Tunnel1

...

mpls label protocol ldp

mpls ip

This will enable targeted LDP between the two tunnel endpoints. Through the directed LDP session a PE will learn the LDP label for the BGP next hop from the P router. You can check LDP with "show mpls ldp discovery". It will show you the targeted LDP hellos being "xmit/recv" like on a normal interface.

For the PBR configuration I would recommend to read through "Directing MPLS VPN Traffic Using Policy Based Routing"

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008044208d.html

This should answer most if not all questions. If there are further questions do not hesitate to post them.

Hope this helps! Please rate all posts.

Regards, Martin

Re: Traffic engineering within MPLS VPN

Hi,

one further document to look at in your case:

"Implementing an MPLS VPN over TE Tunnels"

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml

I forgot to mention it in the previous posts.

Regards, Martin

Re: Traffic engineering within MPLS VPN

To add more here,

1) QOS based classification cannot be done using PBR, it can be done using classes

with the feature called "Class Based Tunnel Selection"

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00802659b9.html

2) You dont need to enable LDP on your TE tunnels as they span across your PE's.

The end's PE's have full knwoledge of your VPN's. (your head end and tail end are PE's)

As you want to provide per VRF TE tunnel and yes your stack would be Tunnel Label and VPN label.)

3) If you use the Per VRF tunnel method as described by Martin here, you wont be able

to do any QOS, as this service is more like a "Virtual Leased Line" where a certain

provisioned circuit gives a single QOS behavior. Or you may need to have 5 tunnels,

for 5 class of services per customer. (In this case its easier to have

just "Class Based Tunnel Selection Feature") And for this type of Tunnel the tunnel has to span

across the PE's it cant have a stopover in at a 'P' in btwn.)

PE1<--Tunnel-->PE2

4) If in future if you may need to give such VLL service to your L2VPN customer you can used

a feature called "Tunnel Selection". Here there is no next hop manipulation.

http://www.cisco.com/en/US/products/ps6922/products_feature_guide09186a008067cf79.html

HTH-Cheers,

Swaroop

Community Member

Re: Traffic engineering within MPLS VPN

How to do this "Tunnel Selection" with IOS 12.2(18)SXE ou SXF in 6509

it is possible?

Re: Traffic engineering within MPLS VPN

TUnnel Selection is supported only in SRA.

you can start with 12.2(31)SRA or SRA1, and have tested this working and its implemented as well for our customer :-).

HTH-Cheers,

Swaroop

Cisco Employee

Re: Traffic engineering within MPLS VPN

You probably meant 12.2(33)SRA and SRA1.

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

Re: Traffic engineering within MPLS VPN

Yes ur right its 12.2(33)SRA may be the extended weekend is playing on my mind, typo :-)

Community Member

Re: Traffic engineering within MPLS VPN

Hi all,

many many many thanks for all your answer.

Extremely helpful!

Now i'm going to read all your links...

Regards

Gianluca

347
Views
25
Helpful
11
Replies
CreatePlease to create content