From: Gopal@Yahoo
Date: Wed Mar 29 2006 - 20:30:08 GMT-3
Pls see inline..
--- Reinhold Fischer <Reinhold.Fischer@gmx.net> wrote:
> 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.
GK: TE calculates the path to the headend from its TE
topo database. RSVP path messages follow the path.
This is processed hop-by-hop. At every hop, next-hop
is determined either from the path message(explicit)
or from its own TE database. Resv will carry the
label. routing table is not used. If you have a
working setup, simply do not advertise the headend
router-id in IGP(make it disappear from the routing
table), TE tunnel shd be working fine. Pls let us know
what you see.
>
> > - 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,
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3