From: Olopade Olorunloba (lolopade@ipnxnigeria.net)
Date: Fri Mar 31 2006 - 18:15:26 GMT-3
Hello Arun,
I will like to disagree with you. First, the introduction of TE tunnels does
not add many problems to the MPLS VPN setup, if properly configured. After
configuring an MPLS TE tunnel and ensuring that it is not advertised to IGP,
via the autoroute announce command, the setup and operation of the MPLS VPN
has in wise changed. The TE tunnel will not carry any traffic and
complexities has been added.
With respect to peering on physical addresses for iBGP sessions, this is
strongly not recommended for MPLS VPN. Allow me to explain. MPLS VPN traffic
are tagged with a two label stack, the topmost being the label for the BGP
next-hop and second being the VPN label assigned by the egress PE router.
For MPLS VPN to operate properly, the VPN label must never be exposed until
the label packet reaches the egress PE router. When the iBGP peerings are
across loopbacks addresses, the egress PE advertises a POP label for the
loopback to all her LDP peers. Hence, VPN traffic reaches the router with
just the VPN label (one label stack). The situation is not too different, if
the peering is done with physical addresses, as those addresses are
advertised with POP labels as well. However, there is an exception. In the
case of the loopback, the interface exists only on the egress PE router, so
it is the only router on the network that advertises the POP label. However,
when using the physical address for peering, at least two routers will
advertise the POP labels, the egress PE router and the other router at the
end of the link. If the path of the VPN traffic passes through the other
router, then the VPN label will be exposed before getting to egress PE
router, breaking the VPN.
It would seem that if the backup link is a direct connection between the 2
PE routers that the solution might work, but then it will not scale. And
considering the Inter-AS possibilities, you would definitely have more
problems with the broken LSPs.
Let me describe the other solution, because I think it is simple (can even
be achieved without TE tunnels).
Using TE Tunnels
Step 1.
Establish the simple VPN.
Step 2.
Assign one additional loopback each on the PEs where the VPNs are located
that you need.
interface Loopback1
ip address a.b.c.d 255.255.255.255
end
Step 3
Create an MPLS TE tunnel from the PEs ensuring that autoroute announce is
not used i.e. it is not advertised into IGP. Also, the path option should be
through the backup link. You can use any means to achieve this like explicit
path, affinity bits etc.
interface Tunnel0
ip unnumbered Loopback1
tunnel destination
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 explicit name VDT
end
At this stage, everything still works normal and the operation of the
network has not changed.
Step 4
Use a static route to route the remote loopback address down the TE tunnel,
on both PEs
ip route a.b.c.d 255.255.255.255 Tunnel0
Step 5
Change the bgp next-hop on the VPNs by using the bgp next-hop command on the
vrf configuration. This will now make the traffic to go down the TE tunnel
and which is through the backup link.
ip vrf VPN
bgp next-hop Loopback1
Without TE tunnels
Step 1.
Establish the simple VPN.
Step 2.
Assign one additional loopback each on the PEs where the VPNs are located
that you need.
interface Loopback1
ip address a.b.c.d 255.255.255.255
end
Step 3
Create static routes for the remote PEs along the path between the two PEs.
Ensure that the mask of the static routes are the same along the path, and
the same with the mask of the loopback address.
At this stage, everything still works normal and the operation of the
network has not changed.
Step 4
Change the bgp next-hop on the VPNs by using the bgp next-hop command on the
vrf configuration. This will now make the traffic to go down the path of the
static routes you have created, which is through the backup link.
The disadvantage of using the static route option is that the traffic can
not failover.
I do not see any problems also with Inter-AS solutions. Note that you will
not create a TE across ASes.
I hope this helps.
_____
From: Arun Kumar Arumuganainar [mailto:aarumuga@hotmail.com]
Sent: 31 March 2006 19:54
To: lolopade@ipnxnigeria.net; jbrentfoster@yahoo.com;
ccielab@groupstudy.com; comserv@groupstudy.com
Subject: RE: OT: how to filter out several VPNs from a MPLS backbone backup
path
Hi all ,
I would think brent has hit the nail on its head . The real solution to the
problem has been hijacked by our discussion over TE and its related solution
. I think we should think out of the boxhere . I would think , the
introduction of TE in MPLS VPN set up adds up many problems than it is
intended to solve .
First of all TE solution will not be scable . TE has serious limitation when
it comes to inter-as setup. Hence scalability of the solution is big
question mark . On the other hand we do have a simple and elegant solution .
Let me describe this .
Pls. Note : First build a simple VPN ( with out configuring the backup link
) . Over that setup perform the following step
Step 1 : Create a BGP Peering ( Either iBGP or eBGP ) using physical
interface of the back up link as the peering address .
Discussion on the configuration :- There is no need to configure addtional
loopback even when your setup is a simple single AS setup . Pls. Note : Loop
Back peering is not a requirement of iBGP it is just an option . It just
gives us a more reliability to the BGP peering during the events of internal
topology changes . In our case there is no need to protect backup peering
and hence we need not use any loopback.
step 2 :- Activate vpnv4 address family for this peering on both sides .
step 3 :- Filter out vpnv4 prefixes so that only the routes belongs to VRF
that are eligible for BACKUP link usage gets advertised . This can be done
in the following ways .
Let us say allowed VRF are has got export RT set to say 100:100 100:101
100:1002 then skeleton configuration will look like this .
router bgp 100
no bgp default ipv4 unicast
neighbor 10.10.10.1 remote-as 100
address-family vpnv4
neighbor 10.10.10.1 activate
neighbor 10.10.10.1 route-map rt-based-filter out
route-map rt-based-filter permit 10
match extcomm 10
ip ext-community 10 permit rt 100:100 100:101 100:102
step 4: use an incoming prefix list and set a very low admin wight for this
peering . This in effect will prevent the backup link to be use when primary
is up .
Pls. Note : This design is very elegant in the sense existing MPLS VPN
setup is not touched at all . Only thing you add is bgp peering for vpnv4
address family. It is also scalable and will work just fine even for
inter-as-vpn .
Thanks and Regards
ARun
_____
From: "Olopade Olorunloba" <lolopade@ipnxnigeria.net>
Reply-To: "Olopade Olorunloba" <lolopade@ipnxnigeria.net>
To: "'Brent Foster'" <jbrentfoster@yahoo.com>, "'Cisco certification'"
<ccielab@groupstudy.com>, <comserv@groupstudy.com>
Subject: RE: OT: how to filter out several VPNs from a MPLS backbone backup
path
Date: Thu, 30 Mar 2006 21:54:14 +0100
I do not think that you can use this feature.
The ip extcommunity-list is helpful in import and export route-map
configuration. It can help to give a tighter control on which routes are
imported into which VPN or not.
You could also consider applying the filtering on a per-link basis. However,
iBGP is often established over loopback addresses, and the actual link over
which the connection is established is determined by the IGP. Also, you
would need to have two connections active between the routers, implying that
both routers would need to have 2 loopbacks addresses. This is necessary,
since on one connection the desired vpn routes will be filtered out, and on
the other, they will be the only one permitted.
Asides all these, you will still need to ensure via your IGP, that one
loopback is reachable across a link, the other loopback across the other
link. This almost reduces the solution to the previous one. This scheme
sounds more troublesome to me.
One thing to note is that for a BGP learnt route, the actual forwarding path
depends on the forwarding path for the BGP next-hop according to the IGP.
Also, MPLS VPN routes are learnt via BGP, hence to modify the forwarding
path for the VPN, it is the forwarding path of the BGP next-hop in the IGP
that needs to be modified.
The use of the BGP next-hop command in the Vrf and the TE tunnel (unless,
you want to configure static routes all the way from the ingress to the
egress) seems to me a very good solution.
By the way, I have this solution working on my network.
Regards.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brent Foster
Sent: 30 March 2006 16:31
To: Cisco certification; comserv@groupstudy.com
Subject: Re: OT: how to filter out several VPNs from a MPLS backbone backup
path
So, I think I answered my own question here. See this
link...
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r
/rte_bgh1.htm#wp1074763
"The ip extcommunity-list command is used to configure
named or numbered extended community lists. Extended
community attributes are used to filter routes for VPN
routing and forwarding instances (VRFs) and
Multiprotocol Label Switching (MPLS) Virtual Private
Networks (VPNs)."
I'll test this, but I believe this may be a better
solution to the problem.
--Brent
--- Brent Foster <jbrentfoster@yahoo.com> wrote:
> I went back and looked at the original problem
> statement on this thread. We want to restrict
> certain
> VPN traffic from the backup link, right? It might
> even be desirable to have the backup link carry this
> VPN traffic if there is a failure on the primary
> links
> right?
>
> Could there be a different approach using BGP
> filtering techniques since VPNs are simply carried
> as
> MP-BGP routes with route-targets carried as extended
> BGP communities? Could we somehow filter on those
> communities and even use advertise-map/non-exist-map
> techniques to allow the backup link to carry these
> VPNs if there is a failure?
>
> Just thinking out of the box for a different
> solution
> to this problem. It is an interesting one!
>
> --Brent
>
> --- Reinhold Fischer <Reinhold.Fischer@gmx.net>
> wrote:
>
> > On Fri, Mar 24, 2006 at 12:50:28PM +0200,
> > sheherezada@gmail.com wrote:
> > > Hi all,
> > >
> > > I have four routers linked in a row, let's say
> > A-B-C-D, and a lower
> > > bandwidth backup link between A and D. I have
> just
> > added MPLS and set
> > > up several VPNs, but I don't want all VPNs to
> > generate traffic on the
> > > backup link when it comes up. Any idea of how to
> > do it?
> > >
> > > Thanks,
> > >
> > > Mihai
> > >
> >
> > Hi Mihai,
> >
> > here is a possible solution. I have put also the
> > CCIE SP list on CC
> > since this is more a topic for there...
> >
> > - create a second loopback interface on the
> > pe-routers.
> >
> > - add your second loopback interface into your igp
> > so it is reachable
> >
> > - filter your LDP so it is not assigning and
> > distributing any labels
> > for this second loopback
> >
> > - change the next-hop ip-address that bgp will
> > advertise for the
> > VPN that you do not want to have on the
> > low-bandwidth backup link
> >
> > Example> Assuming Lo1 is the Loopback where you
> > are not distributing labels
> > for:
> > !
> > ip vrf TWO
> > rd 2:1
> > route-target export 2:1
> > route-target import 2:1
> > bgp next-hop Loopback1
> > !
> >
> > - at this point this VPN will not work anymore,
> > because you have no
> > LSP to the new Loopbacks
> >
> > - enable MPLS Traffic Engineering, use the new
> > loopback ip as router-id
> > for mpls traffic engineering
> >
> > - build mpls-te tunnels between the new loopback
> > addresses. Use an
> > explicit path that excludes the ip addresses of
> > the low-bandwidth
> > backup link.
> >
> > - at this point the VPN will work again. LSPs are
> > provided through
> > MPLS-TE. As soon as the main link between your
> PE
> > routers goes
> > down the MPLS-TE Tunnel will also go down
> because
> > they are not
> > allowed to signal a path through your
> > low-bandwidth link.
> >
> > hope the explanation is not too confusing.
> >
> > regards
> >
> > reinhold
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3