- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: OT: how to filter out several VPNs from a MPLS backbone backup path posted 03/31/2006
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

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 remote-as 100

address-family vpnv4

neighbor activate

neighbor 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



  From:  "Olopade Olorunloba" <lolopade@xxxxxxxxxxxxxxx>
  Reply-To:  "Olopade Olorunloba" <lolopade@xxxxxxxxxxxxxxx>
  To:  "'Brent Foster'" <jbrentfoster@xxxxxxxxx>, "'Cisco
  certification'" <ccielab@xxxxxxxxxxxxxx>, <comserv@xxxxxxxxxxxxxx>
  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
  imported into which VPN or not.

  You could also consider applying the filtering on a per-link basis.
  iBGP is often established over loopback addresses, and the actual
  link over
  which the connection is established is determined by the IGP. Also,
  would need to have two connections active between the routers,
  implying that
  both routers would need to have 2 loopbacks addresses. This is
  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
  loopback is reachable across a link, the other loopback across the
  link.  This almost reduces the solution to the previous one. This
  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
  Also, MPLS VPN routes are learnt via BGP, hence to modify the
  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
  you want to configure static routes all the way from the ingress to
  egress) seems to me a very good solution.

  By the way, I have this solution working on my network.


  -----Original Message-----
  From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On Behalf
  Brent Foster
  Sent: 30 March 2006 16:31
  To: Cisco certification; comserv@xxxxxxxxxxxxxx
  Subject: Re: OT: how to filter out several VPNs from a MPLS backbone

  So, I think I answered my own question here.  See this

  "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 Foster <jbrentfoster@xxxxxxxxx> 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@xxxxxxx>
  > wrote:
  > > On Fri, Mar 24, 2006 at 12:50:28PM +0200,
  > > sheherezada@xxxxxxxxx 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:
  > >
  > >
  > >
  > > Subscription information:
  > >
  > >
  > Brent Foster
  > jbrentfoster@xxxxxxxxx
  > __________________________________________________
  > Do You Yahoo!?
  > Tired of spam?  Yahoo! Mail has the best spam
  > protection around
  > Subscription information:

  Brent Foster

  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam protection around

  Subscription information:

  Subscription information: