I have this scenario:
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
you can configure a different BGP next hop for each tunnel. This loos like this:
ip route 220.127.116.11 255.255.255.255 Tunnel1
ip route 18.104.22.168 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.
ip vrf A
bgp next-hop 22.214.171.124
ip vrf B
bgp next-hop 126.96.36.199
ip address 188.8.131.52 255.255.255.255
ip address 184.108.40.206 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.
thanks for your answer.
Very very helpful.
P.S. have you some link where I can found something regarding PBR for the TE-qos?
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?
you need to enable MPLS on the TE tunnel interfaces. Otherwise they are considered as "IP only" and LFIB shows "untagged".
mpls label protocol ldp
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"
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.
one further document to look at in your case:
"Implementing an MPLS VPN over TE Tunnels"
I forgot to mention it in the previous posts.
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"
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.)
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.
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 :-).
You probably meant 12.2(33)SRA and SRA1.
Hope this helps,
many many many thanks for all your answer.
Now i'm going to read all your links...