Mailing List Archive

MPLS VPN traffic engineering tunnel selection
Hi,

I have this really "simple" thing about MPLS TE that I don't understand.
I have TE working nicely-ish in the lab with no problems, but I'm
missing a crucial part in my understanding of the MPLS VPN + TE
combination.

The setup is as follows:

+-----+ +-----+
+-----+ | |-------------| | +-----+
| CE1 |--| PE1 | +----+ | PE2 |--| CE2 |
+-----+ | |---| P1 |----| | +-----+
+-----+ +----+ +-----+

It's ISIS for an IGP. PE's and P are all 6500/Sup720 running SXF.
Regular MPLS VPN (rfc2547) works with no problems. TE configuration went
smooth too, having what seems like all the right information in the ISIS
database. For PE-CE I tried both BGP and static routing.

I tested MPLE TE explicit path, and it works like a charm. Natural path
(PE1 directly to PE2) is replaced by an explicit path through P1. I
haven't tested CBR yet, but can't see why it shouldn't work.

Now to the problem: What I don't understand is how I can use a tunnel
selectively in a specific VRF. Right now, any traffic from PE1 to PE2
uses the tunnel. In "regular" MPLS VPN, a prefix from CE2 looks
something like "impose {X Y}" on PE1, with X and Y being VPN and
next-hop/loopback-labels. Using explicit path, I get "impose {Z Y}",
with Z being the new LSP to PE2 through the tunnel. That works fine, but
I would like to have only e.g. VRF A use a specific path, not all MPLS
traffic between PEs. And I really can't seem to find out how that's
accomplished.

I tried (creatively) something like:

ip route vrf A 10.66.0.0 255.255.255.0 Tunnel40 10.22.0.1 global

explicitly on PE1, where 10.66.0.0/24 is a net originating from CE2 and
10.22.0.1 is PE2s loopback. This semi "works": I can have the packets
use the TE LSP, but PE1 then only imposes the TE label on entry, not the
VPN label. How the fudge does it work? ;-) I'm probably overlooking
something simple. Can anybody give me a clue?

I tried browsing through LOTS of documents on cisco.com, but can't seem
to find any that describe how to use tunnels selectively, apart from
Class Based Tunnel Selection, which is not what I want.

Thanks in advance,
Peter


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS VPN traffic engineering tunnel selection [ In reply to ]
Peter,

this was just recently discussed on the list, check out the thread
"Cisco 10K MPLS VPN", for example at
http://www.gossamer-threads.com/lists/cisco/nsp/83117
Let me know if you need more info..

oli

Peter Rathlev <> wrote on Thursday, April 10, 2008 2:35 PM:

> Hi,
>
> I have this really "simple" thing about MPLS TE that I don't
> understand. I have TE working nicely-ish in the lab with no problems,
> but I'm missing a crucial part in my understanding of the MPLS VPN +
> TE combination.
>
> The setup is as follows:
>
> +-----+ +-----+
> +-----+ | |-------------| | +-----+
>> CE1 |--| PE1 | +----+ | PE2 |--| CE2 |
> +-----+ | |---| P1 |----| | +-----+
> +-----+ +----+ +-----+
>
> It's ISIS for an IGP. PE's and P are all 6500/Sup720 running SXF.
> Regular MPLS VPN (rfc2547) works with no problems. TE configuration
> went smooth too, having what seems like all the right information in
> the ISIS database. For PE-CE I tried both BGP and static routing.
>
> I tested MPLE TE explicit path, and it works like a charm. Natural
> path (PE1 directly to PE2) is replaced by an explicit path through
> P1. I haven't tested CBR yet, but can't see why it shouldn't work.
>
> Now to the problem: What I don't understand is how I can use a tunnel
> selectively in a specific VRF. Right now, any traffic from PE1 to PE2
> uses the tunnel. In "regular" MPLS VPN, a prefix from CE2 looks
> something like "impose {X Y}" on PE1, with X and Y being VPN and
> next-hop/loopback-labels. Using explicit path, I get "impose {Z Y}",
> with Z being the new LSP to PE2 through the tunnel. That works fine,
> but I would like to have only e.g. VRF A use a specific path, not all
> MPLS traffic between PEs. And I really can't seem to find out how
> that's accomplished.
>
> I tried (creatively) something like:
>
> ip route vrf A 10.66.0.0 255.255.255.0 Tunnel40 10.22.0.1 global
>
> explicitly on PE1, where 10.66.0.0/24 is a net originating from CE2
> and
> 10.22.0.1 is PE2s loopback. This semi "works": I can have the packets
> use the TE LSP, but PE1 then only imposes the TE label on entry, not
> the VPN label. How the fudge does it work? ;-) I'm probably
> overlooking something simple. Can anybody give me a clue?
>
> I tried browsing through LOTS of documents on cisco.com, but can't
> seem to find any that describe how to use tunnels selectively, apart
> from Class Based Tunnel Selection, which is not what I want.
>
> Thanks in advance,
> Peter
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS VPN traffic engineering tunnel selection [ In reply to ]
Hi Oliver,

On Thu, 2008-04-10 at 15:08 +0200, Oliver Boehmer (oboehmer) wrote:
> this was just recently discussed on the list, check out the thread
> "Cisco 10K MPLS VPN", for example at
> http://www.gossamer-threads.com/lists/cisco/nsp/83117
> Let me know if you need more info..

Thank you for the pointer, I have it working now. I followed that thread
somewhat, but overlooked that it actually was about something similar.

The "trick" is that it's at the origin I do the configuration, and let
the box figure it out, whereas I before thought I should configure it at
the far end with destination based routing.

I tried it out, and I had btw also overlooked the fact that "mpls
traffic-eng router-id" under "router isis" should not be the regular
loopback also used for BGP next-hop, but instead my TE loopback. And all
explicit-path hops should be the TE loopbacks. Stupid thing to overlook,
but I'm glad I found out. :-)

I still have one question though: Is there any way of doing "destination
based" routing? I was thinking about something along the line of PBR,
with explicit selection of path/tunnel based on source and destination
at both ends, e.g. somehow using the tunnel as next hop in the VRF. I
guess I can adjust the BGP next-hop in an inbound route-map on PE1 just
as well as I can outbound on PE2. But that only solves part of the
problem. What if I'd like to treat different source networks in the same
VRF on the same PE differently? I know this is asking much, but maybe
there's a way...

Thank you very much again. For interested parties, the configuration
ended up as below. It's only TE one way, and just uses two different
paths for two different prefixes in this example. It's tested from a
cleared config on 6500/Sup720/SXF13.

Regards,
Peter


! *** PE1 ***
hostname PE1
!
mpls label protocol ldp
mpls traffic-eng tunnels
mpls ldp router-id Loopback0
mls mpls tunnel-recir
!
ip explicit-path name through_P1 enable
next-address 10.0.1.3 ! P1
next-address 10.0.1.2 ! PE2
exit
!
ip vrf A
rd 65530:1
route-target both 65530:1
exit
!
interface Loopback0
description "Regular" loopback
ip address 10.0.0.1 255.255.255.255
ip router isis
no shutdown
exit
!
interface Loopback1
description MPLS TE loopback
ip address 10.0.1.1 255.255.255.255
ip router isis
no shutdown
exit
!
interface Tunnel1
description MPLS TE tunnel to PE2
ip unnumbered Loopback1
tunnel destination 10.0.1.2
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 10 explicit name through_P1
tunnel mpls traffic-eng record-route
no shutdown
exit
!
interface TenGigabitEthernet9/1
description -> PE2
ip address 10.0.2.1 255.255.255.252
ip router isis
mpls traffic-eng tunnels
mpls ip
no shutdown
exit
!
interface TenGigabitEthernet9/2
description -> P1
ip address 10.0.2.5 255.255.255.252
ip router isis
mpls traffic-eng tunnels
mpls ip
no shutdown
exit
!
interface GigabitEthernet5/2
description -> CE1
ip vrf forwarding A
ip address 10.66.0.1 255.255.255.0
no shutdown
exit
!
router isis
metric-style wide
mpls traffic-eng router-id Loopback1
mpls traffic-eng level-1
net 49.fc00.0000.0000.0001.00
is-type level-1
exit
!
router bgp 65530
bgp router-id 10.0.0.1
neighbor CORE peer-group
neighbor CORE remote-as 65530
neighbor CORE update-source Loopback0
neighbor 10.0.0.2 peer-group CORE
!
address-family vpnv4
neighbor CORE activate
neighbor CORE next-hop-self
neighbor CORE send-community both
neighbor 10.0.0.2 peer-group CORE
exit-address-family
!
address-family ipv4 vrf A
network 10.66.0.0 mask 255.255.255.0
exit-address-family
!
exit
!
ip route 10.0.1.2 255.255.255.255 Tunnel1 10.0.1.2
!

! *** P1 ***
hostname P1
!
mpls label protocol ldp
mpls traffic-eng tunnels
mpls ldp router-id Loopback0
mls mpls tunnel-recir
!
interface Loopback0
description "Regular" loopback
ip address 10.0.0.3 255.255.255.255
ip router isis
no shutdown
exit
!
interface Loopback1
description MPLS TE loopback
ip address 10.0.1.3 255.255.255.255
ip router isis
no shutdown
exit
!
interface TenGigabitEthernet9/1
description -> PE1
ip address 10.0.2.6 255.255.255.252
ip router isis
mpls traffic-eng tunnels
mpls ip
no shutdown
exit
!
interface TenGigabitEthernet9/2
description -> PE2
ip address 10.0.2.9 255.255.255.252
ip router isis
mpls traffic-eng tunnels
mpls ip
no shutdown
exit
!
router isis
metric-style wide
mpls traffic-eng router-id Loopback1
mpls traffic-eng level-1
net 49.fc00.0000.0000.0003.00
is-type level-1
exit
!

! *** PE2 ***
hostname PE2
!
mpls label protocol ldp
mpls traffic-eng tunnels
mpls ldp router-id Loopback0
mls mpls tunnel-recir
!
ip prefix-list TE-TEST-pl seq 5 permit 10.66.1.0/24
!
route-map TE-TEST permit 10
match ip address prefix-list TE-TEST-pl
set ip next-hop 10.0.1.2
exit
!
route-map TE-TEST permit 20
exit
!
ip vrf A
rd 65530:1
route-target both 65530:1
exit
!
interface Loopback0
description "Regular" loopback
ip address 10.0.0.2 255.255.255.255
ip router isis
no shutdown
exit
!
interface Loopback1
description MPLS TE loopback
ip address 10.0.1.2 255.255.255.255
ip router isis
no shutdown
exit
!
interface TenGigabitEthernet9/1
description -> P1
ip address 10.0.2.10 255.255.255.252
ip router isis
mpls traffic-eng tunnels
mpls ip
no shutdown
exit
!
interface TenGigabitEthernet9/2
description -> PE1
ip address 10.0.2.2 255.255.255.252
ip router isis
mpls traffic-eng tunnels
mpls ip
no shutdown
exit
!
interface GigabitEthernet5/2
description -> CE2
ip vrf forwarding A
ip address 10.66.1.1 255.255.255.0
ip address 10.66.2.1 255.255.255.0 secondary
no shutdown
exit
!
router isis
metric-style wide
mpls traffic-eng router-id Loopback1
mpls traffic-eng level-1
net 49.fc00.0000.0000.0002.00
is-type level-1
exit
!
router bgp 65530
bgp router-id 10.0.0.2
neighbor CORE peer-group
neighbor CORE remote-as 65530
neighbor CORE update-source Loopback0
neighbor 10.0.0.1 peer-group CORE
!
address-family vpnv4
neighbor CORE activate
neighbor CORE next-hop-self
neighbor CORE send-community both
neighbor CORE route-map TE-TEST out
neighbor 10.0.0.1 peer-group CORE
exit-address-family
!
address-family ipv4 vrf A
network 10.66.1.0 mask 255.255.255.0
network 10.66.2.0 mask 255.255.255.0
exit-address-family
!
exit
!

! *** CE1 ***
interface GigabitEthernet0/1
description -> PE1
no switchport
ip address 10.66.0.50 255.255.255.0
no shutdown
exit
!
ip route 0.0.0.0 0.0.0.0 10.66.0.1
!

! *** CE2 ***
interface GigabitEthernet0/1
description -> PE2
no switchport
ip address 10.66.1.50 255.255.255.0
ip address 10.66.2.50 255.255.255.0 secondary
no shutdown
exit
!
ip route 0.0.0.0 0.0.0.0 10.66.1.1
!


! Trace from CE1 to CE2:10.66.1.50
! This uses the explicit path through P1
CE1#trace 10.66.1.50

Type escape sequence to abort.
Tracing the route to 10.66.1.50

1 10.66.0.1 0 msec 0 msec 0 msec
2 10.0.2.6 8 msec 0 msec 0 msec
3 10.66.1.1 0 msec 0 msec 0 msec
4 10.66.1.50 0 msec * 0 msec
CE1#

! Trace from CE1 to CE2:10.66.2.50
! This uses the shortest (regular) path to PE2
CE1#trace 10.66.2.50

Type escape sequence to abort.
Tracing the route to 10.66.2.50

1 10.66.0.1 0 msec 0 msec 0 msec
2 10.66.1.1 0 msec 0 msec 0 msec
3 10.66.1.50 0 msec * 0 msec
CE1#




_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: MPLS VPN traffic engineering tunnel selection [ In reply to ]
Peter Rathlev <mailto:peter@rathlev.dk> wrote on Thursday, April 10,
2008 5:34 PM:

> Hi Oliver,
>
> On Thu, 2008-04-10 at 15:08 +0200, Oliver Boehmer (oboehmer) wrote:
>> this was just recently discussed on the list, check out the thread
>> "Cisco 10K MPLS VPN", for example at
>> http://www.gossamer-threads.com/lists/cisco/nsp/83117
>> Let me know if you need more info..
>
[...]
>
> I tried it out, and I had btw also overlooked the fact that "mpls
> traffic-eng router-id" under "router isis" should not be the regular
> loopback also used for BGP next-hop, but instead my TE loopback.

Well, not necessarily.. Trick is to set your BGP next-hop to something
which is only routed over the tunnel. There are several ways to do this.
If the BGP next-hop is different from the TE router-id, you need to
enable LDP on the tunnel ("mpls ip") in order to transport tagged
packets. Actually: You almost always want to enable LDP on the tunnel if
you use TE for MPLS pkts (L2VPN/L3VPN)..

> And
> all explicit-path hops should be the TE loopbacks. Stupid thing to
> overlook, but I'm glad I found out. :-)

You can also use interface addresses to force tunnels over (or away
from) specific interfaces.

> I still have one question though: Is there any way of doing
> "destination based" routing? I was thinking about something along the
line of PBR,
> with explicit selection of path/tunnel based on source and destination
> at both ends, e.g. somehow using the tunnel as next hop in the VRF. I
> guess I can adjust the BGP next-hop in an inbound route-map on PE1
> just as well as I can outbound on PE2. But that only solves part of
the
> problem. What if I'd like to treat different source networks in the
> same VRF on the same PE differently? I know this is asking much, but
maybe
> there's a way...

You can use policy-based routing on the VRF interface, but this requires
a recent 12.2SR or 12.2SXH to work in a VRF context. You then just match
the pkts using an ACL, and set the outgoing interface to the TE tunnel.

oli
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/