From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Mon Apr 03 2006 - 09:58:37 GMT-3
Hi Brent and others ,
I did lab it up this scenario . For the shake of making my initial
configuration simple , I did used my existing interas-setup . Here are the
details .
LAB TOPOLOGY .
~~~~~~~~~~~~~
CE1--| RR1 RR2 |---CE3
|---Pe1---|---ASBR---ASBR2---|---PE2---|
Ce2--| | |
|---CE4
|----------------------------------|
172.16.16.0
<--------BACKUP LINK ---->
Some notes on topology .
~~~~~~~~~~~~~~~~~
This is an existing functional inter-as setup . I did only the following to
simulate the conditions that we are discussion over the thread .
1) Added one link to the existing topolgy
2) Added additional BGP peering and activated it only under VPNV4 address
family .
3) Note : Redistributed connected interface was done in order to advertise
/32 bit address of the backup link in to IGP .This is needed otherwise MPLS
connectivity will fail
*****And absolutely nothing *****.
Here are some relevant configuration and Router output.
~~~~~~~~~~~~~~~~~~~~~
Pls. note : Here CE1 and CE3 forms VPN1 ( with RD and RT set to 10:30) and
are only allowed to use backup link in the event of primary failure .
Ce2 and CE4 forms VPN2 ( with RD and RT set to 20:40 ) . These prefixes are
not allowed to primary link in the event of primary failure .
router bgp 200
!
! *** irrelevant configuration removed ****
!
no bgp default ipv4-unicast
bgp log-neighbor-changes
! *** Peering added for the physical address of Backup link ***
neighbor 172.16.16.6 remote-as 100
!
!
address-family vpnv4
! ****Activated for VPNV4 address family ***
! *** Metric value is forced to higher so that route is least preferred ***
! *** routes that have RT 10:30 (vpn1 ) alone is imported
neighbor 172.16.16.6 activate
neighbor 172.16.16.6 send-community extended
neighbor 172.16.16.6 route-map filter-vrf-routes in
neighbor 172.16.16.6 route-map set-metric out
exit-address-family
!
ip extcommunity-list 100 permit RT:10:30
ip bgp-community new-format
!
route-map set-metric permit 10
set metric 50
!
route-map filter-vrf-routes permit 10
match extcommunity 100
!
===============================================
Verification :-
~~~~~~~~~~
When primary is up : "sh ip bgp vpn all " ...shows all the routes are
learned and routes points to PE2 loopback interface( primary link ) . You
can also note back up routes are learned only for VPN1
Router1#sh ip bgp vpn all
BGP table version is 31, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10:30 (default for vrf vpn1)
*> 10.10.1.1/32 192.168.10.10 11 32768 ?
*>i30.30.3.3/32 172.16.6.6 0 100 0 100 ?
* 172.16.16.6 50 0 100 ? ==> Back
up route not selected
*> 192.168.10.0 0.0.0.0 0 32768 ?
*>i192.168.30.0 172.16.6.6 0 100 0 100 ?
* 172.16.16.6 50 0 100 ? ==> Back
up route not selected
Route Distinguisher: 20:40 (default for vrf vpn2) ==> Back up route doest
not exisist
*> 20.20.2.2/32 192.168.20.10 11 32768 ?
*>i40.40.4.4/32 172.16.6.6 0 100 0 100 ?
*> 192.168.20.0 0.0.0.0 0 32768 ?
*>i192.168.40.0 172.16.6.6 0 100 0 100 ?
Router1#
When primary link goes down ( To simulate it , just shut RRs loopback
address ) . Following is ouput
~~~~~~~~~~~~~~~~~~~~
Router1#sh ip bgp vpn all
BGP table version is 37, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
/*** VPN1 routes going through back path ***/
/***Remote routes for VPN2 is not learned via backup path***/
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10:30 (default for vrf vpn1)
*> 10.10.1.1/32 192.168.10.10 11 32768 ?
*> 30.30.3.3/32 172.16.16.6 50 0 100 ?
*> 192.168.10.0 0.0.0.0 0 32768 ?
*> 192.168.30.0 172.16.16.6 50 0 100 ?
Route Distinguisher: 20:40 (default for vrf vpn2)
*> 20.20.2.2/32 192.168.20.10 11 32768 ?
*> 192.168.20.0 0.0.0.0 0 32768 ?
==============================================
Ping output when Primary is down .
~~~~~~~~~~~~~~~~~~~~~~~~
1) VPN1 ping is success full
ce1#ping 30.30.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 30.30.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
ce1#
2) VPN2 ping is unsuccessful
ce2#ping 40.40.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 40.40.4.4, timeout is 2 seconds:
....
Success rate is 0 percent (0/5)
ce2#
Hope this would help .
Thanks and Regards
Arun
----- Original Message -----
From: "Brent Foster" <jbrentfoster@yahoo.com>
To: "Arun Kumar Arumuganainar" <aarumuga@hotmail.com>;
<lolopade@ipnxnigeria.net>; <ccielab@groupstudy.com>;
<comserv@groupstudy.com>
Sent: Saturday, April 01, 2006 12:49 AM
Subject: RE: OT: how to filter out several VPNs from a MPLS backbone backup
path
> Arun,
>
> Would you please expand on "Step 4"? I'm not clear on
> that step.
>
> --Brent
>
> --- Arun Kumar Arumuganainar <aarumuga@hotmail.com>
> wrote:
>
>
> ---------------------------------
>
> 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
> > >
> > >
> >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> >
> _____________________________________________________________________
> > > Subscription information:
> > > http://www.groupstudy.com/list/comserv.html
> > >
> >
> >
> > Brent Foster
> > jbrentfoster@yahoo.com
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
> >
> _____________________________________________________________________
> > Subscription information:
> > http://www.groupstudy.com/list/comserv.html
> >
>
>
> Brent Foster
> jbrentfoster@yahoo.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
> _____________________________________________________________________
> Subscription information:
> http://www.groupstudy.com/list/comserv.html
>
> _____________________________________________________________________
> Subscription information:
> http://www.groupstudy.com/list/comserv.html
>
>
>
>
> Brent Foster
> jbrentfoster@yahoo.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _____________________________________________________________________
> Subscription information: http://www.groupstudy.com/list/comserv.html
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:56 GMT-3