From: Reinhold Fischer (Reinhold.Fischer@gmx.net)
Date: Wed Mar 29 2006 - 05:32:03 GMT-3
Hello,
see comments inline. Hope this is still readable :-)
regards
reinhold
On Tue, Mar 28, 2006 at 12:32:40PM -0800, Gopal@Yahoo wrote:
> Good discussion.
>
> I want to add-
>
> - you use 'bgp next-hop loop-1' for the VRFs whose
> traffic shd not ride on the low BW link. Other Vrf's
> do not need that command, hence use the default
> bgp-nexthop, say loop-0. This is what Reinhold meant
> to begin with.
>
> I wd agree with Reinhold's solution for most part
> except:
>
> - "filter your LDP so it is not assigning and
> > distributing any labels for this second loopback" --
>
> * This doesn't serve any purpose. Though this will
> make the VPN to fail on non-TE links, it will not save
> the low BW link. The traffic will go over the low BW
> link and be dropped at the egress PE.
RF: My mail was not clear here. I meant to apply a filter
RF: for these loopbacks on LDP on _all_ routers. So no
RF: router will assign labels for the loopback addresses of
RF: the VPNs that have to avoid the low bw backup link.
RF: When you filter LDP only on the egress PE routers, then
RF: you see exactly what you described.
> - "add your second loopback interface into your igp
> > so it is reachable"
>
> * you should not advertise the loop-1 IP in OSPF. TE
> will work fine without loop-1 IP in routing table. If
> this IP is in routing table the problem is when the TE
> tunnel is DOWN. When the TE tunnel is down, with IP in
> routing table, it follows the IP routing table which
> include the low BW link (when prefered link goes
> down).
RF: The new loopbacks have to be in the routing table
RF: because they are used as tunnel destination addresses for
RF: the MPLS-TE tunnels and they are the BGP nexthop addresses
RF: for the VPNs associated with that loopbacks..
RF: If they would not be in the IGP, how would the IGP (wich
RF: is doing the calculations for MPLS-TE) then be able to
RF: calculate a path to this loopback? How would the ingress PE
RF: select a LSP to the egress PE if it does not know how to
RF: reach the BGP nexthop for this VPN? When the TE-Tunnel is
RF: down, because it is not allowed to go through the low bandwidth
RF: links, there will still be IGP routes to these loopbacks.
RF: But since we restricted LDP from assigning labels there
RF: is no LSP to the loopbacks and the VPNs associated with them
RF: do not work anymore.
RF:
RF: At least this is my understanding and what i have seen as
RF: i have set it up.
> - in summary, you do everything except advertising the
> loop-1 in IGP. So far I assumed your IGP is OSPF :-).
> But if it is not, then it is easier.
>
> - If your IGP is eigrp or RIP, then you don't need TE
> tunnels. you may use distribute-list to stop taking
> the loop-1 prefix over the low BW link.
RF: This is an _excellent_ idea and brings in the second solution
RF: for this scenario. By far more simple as the TE way:
RF:
RF: 1. create separate loopbacks on the PE-Routers and move the
RF: BGP-Nexthop for the VPNs that you want to avoid the low bw link.
RF:
RF: 2. add the new loopbacks to your IGP.
RF:
RF: 3. Filter your IGP on the low bandwidth link, so it does not announce
RF: the new loopback ip addresses on this connection. This is probably
RF: not possible with OSPF or ISIS but we assume a distance-vector
RF: protocol for this scenario. At least on the low-bw-link.
RF:
RF: This should be all. As soon as your main link fails, the ingress pe
RF: routers have no igp route to the special loopbacks and therefore no
RF: LSP. This breaks the VPNs associated with these loopbacks.
> - ACL tweaking is not possible(i wd guess) because
> they are label packets.
RF: I thought also about this but see no possibility to filter on the
RF: IP-Addresses inside a labeled packet. Another thing could have been
RF: to filter on the vpn-label in the packets. But again: I don't think
RF: these labels are deterministic and we have no possibility to filter
RF: on labels. Especially since it is the inner label.
> My 2c. PLease let me know if you have any questions.
>
> CHeers,
> Gopal
> --- sheherezada@gmail.com wrote:
>
> > Hi all,
> >
> > Many thanks for your input. The original
> > requirement was indeed to
> > allow certain VPNs on the backup link (but not all
> > of them). BTW, all
> > routers were PE.
> >
> > I'll go play around with the Reinhold's solution.
> >
> > Thanks again,
> >
> > Mihai
> >
> > On 3/26/06, Ravi Ramaswamy (raramasw)
> > <raramasw@cisco.com> wrote:
> > >
> > >
> > > Hi - I agree with you. I guess I was not reading
> > the question
> > > correctly.
> > >
> > > It depends on the topology in the core. If the
> > backup link became the
> > > best IGP path to the BGP NH PE, then clearly that
> > link won't be used if
> > > tag-switching is enabled, but then VPN traffic
> > won't flow at all. I
> > > guess the requirement is VPN traffic should flow,
> > but not on the backup
> > > link.
> > >
> > > You could try and assign a higher IGP metric to
> > the backup link, in
> > > which case VPN traffic will not flow across this
> > backup link. However,
> > > if there a topology change in the core, you will
> > end up with the same
> > > issue above.
> > >
> > > (In general, if some link in the IGP path from PE
> > to PE has
> > > tag-switching disabled, then VPN traffic will be
> > forwarded into the
> > > core, and be dropped at that P router).
> > >
> > > The TE approach to force the LSP to bypass the
> > backup link is the best
> > > approach....
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Olopade Olorunloba
> > [mailto:lolopade@ipnxnigeria.net]
> > > Sent: Saturday, March 25, 2006 6:57 PM
> > > To: Ravi Ramaswamy (raramasw); 'Reinhold Fischer';
> > sheherezada@gmail.com
> > > Cc: 'Cisco certification'; comserv@groupstudy.com
> > > Subject: RE: OT: how to filter out several VPNs
> > from a MPLS backbone
> > > backup path
> > >
> > > Disabling MPLS on the link between the 2 PEs will
> > not stop them from
> > > trying
> > > to use the link. The path the MPLS VPN traffic
> > takes is determined by
> > > the
> > > path the IGP has for the BGP next-hop of that MPLS
> > VPN. If the IGP,
> > > therefore thinks the BGP next-hop should be
> > reached across the backdoor
> > > link
> > > (on which you have disabled MPLS). It will try and
> > send the traffic
> > > across
> > > the link, but will not be successful.
> > >
> > > I will rather go with the other suggestion of
> > using MPLS TE tunnels. The
> > > important thing to note is that the path the MPLS
> > VPN traffic takes is
> > > the
> > > path you to reach the BGP next-hop. And MPLS TE,
> > are your best tools to
> > > use
> > > to determine which path a traffic should take.
> > >
> > > Regards.
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com] On Behalf Of
> > > Ravi
> > > Ramaswamy (raramasw)
> > > Sent: 25 March 2006 23:22
> > > To: Reinhold Fischer; sheherezada@gmail.com
> > > Cc: Cisco certification; comserv@groupstudy.com
> > > Subject: RE: OT: how to filter out several VPNs
> > from a MPLS backbone
> > > backup
> > > path
> > >
> > > Assuming the picture is like this
> > >
> > > PE1 --- P1 ---- P2 ------ PE2
> > > | |
> > > |--------------------------------|
> > >
> > > And that PE1 and PE2 "backdoor" link is also in
> > the global space, then
> > > why not simply disable tag-switching on the
> > backdoor link? It will
> > > never be used for VPN traffic between PE1 and PE2.
> > >
> > > Ravi Ramaswamy, Cisco Systems Inc.
> > > Advanced Services Central Engg
> > > (732) 261 3814
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com] On Behalf Of
> > > Reinhold Fischer
> > > Sent: Friday, March 24, 2006 4:26 PM
> > > To: sheherezada@gmail.com
> > > Cc: Cisco certification; comserv@groupstudy.com
> > > Subject: Re: OT: how to filter out several VPNs
> > from a MPLS backbone
> > > backup path
> > >
> > > 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
> === message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3