Re: Question on OSPF virtual-links computed via a router with in RFC-3137 "overload"

[Erblichs <[e-mail]>]

Group,

        Sorry...

>         the delay should each time


          the delay should increase each time ...


        Mitchell Erblich
        ---------------

Erblichs wrote:
>
> Group,
>
>         My two cents..
>
>         The level of "overload" is adjustable by
>         adjusting the cost of the advertised route.
>         This way some routers may use the route as
>         as preferred even when another is available.
>
>         If a router is OVERLOADED, it is concieveable
>         that the former may be the alternative. If it
>         is, then link could be advertised with MAXAGE
>         for the duration of the overload, and be
>         re-advertised after some period of time that
>         the overload state is no longer present. The
>         delay should minimize the route flapping, and
>         the delay should each time the route is pre-aged
>         or its cost adjusted due to overload.
>
>         Please realize that each time that the route is
>         re-advertised, minimally their is overhead resources
>         that will be consumed by the other routers, and thus
>         routers should protect themselves from routes that are
>         repeatedly being re-advertised.
>
>         Mitchell Erblich
>         -------------------
>
> Liem Nguyen wrote:
> >
> > Don,
> >
> > On Fri, Jul 30, 2004 at 04:53:28PM -0400, Don Goodspeed wrote:
> > > All,
> > >
> > > I have a question on a topology where I mix virtual-links with
> > > a router set in a RFC-3137 compliant "stub router" or "overload"
> > > state.
> > >
> > >  BB<->Router A <--> Router B <--> Router C <--> Router D
> > > Area 0  ABR   Area 1       Area 1  ABR   Area 2
> > >
> > > If everything lines up, Router A is an ABR between area 0
> > > and area 1.  Router C is an ABR between area 1 and area 2.
> > >
> > > I configure a virtual-link between routers A and C so router
> > > D can communicate to the backbone routers in area 0.
> > >
> > > If Router B is then set to an overload state compliant with
> > > RFC-3137, it advertises it's transit links with a metric of
> > > 65535.  Router C then computes the cost of the virtual-link
> > > to A as 65535 + the metric of its link to B.
> > >
> > > My question is should the virtual-adjacency between A and C
> > > be declared down, or should A and C advertise the virtual-link
> > > metric in their router LSAs as 65535?  This issue does not
> >
> > The latter.
> > Note that RFC3137 is a little different than the IS-IS overload
> > feature in that RFC3137 only discourages transit traffic through the
> > "stub" router; however, if there are no alternate paths,
> > the "stub" router can still be used.
> >
> > Liem
> >
> > > seem to be covered in either RFC-3137 or RFC-2328.
> > >
> > > This could also be done without an RFC-3137 situation by
> > > setting the path metrics such that the cost of the virtual-
> > > link also exceeds 65535.
> > >
> > > My feeling is that since the path metric exceeds 65535 the
> > > virtual adjacency should be torn down (since there is no better
> > > path between A and C).
> > >
> > > Any other opinions?
> > > Don
> > >
> > > _______________________________________________
> > > Join Excite! - http://www.excite.com
> > > The most personalized portal on the Web!
> >
> > --
> >
> > Liem Nguyen