From: Brent Foster (jbrentfoster@yahoo.com)
Date: Fri Mar 31 2006 - 10:54:43 GMT-3
Olopade,
I see your point. With using BGP loopbacks and also
the backup link has only one hop, this makes it
difficult to use communities. I will try your
solution and also experiment with the communities.
I'll let the mailer know if I come up with anything
interesting.
Thanks,
--- Olopade Olorunloba <lolopade@ipnxnigeria.net>
wrote:
> 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
> > >
>
=== message truncated ===
Brent Foster
jbrentfoster@yahoo.com
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3