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

[Erblichs <[e-mail]>]

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