[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: AS border router.
From:       Alex Zinin <azinin () NEXSI ! COM>
Date:       2001-10-12 23:59:09
[Download RAW message or body]


Acee,

  Not trying to argue which one is better, just putting some
  reasons behind using the second approach you mentioned:

   1. Router-LSA origination (!E -> E) should not be a big
      deal as other (ASE) LSAs are already originated or
      flushed.

   2. Not announcing the E-bit without actual ASEs maybe better
      because other routers won't have to maintain state for
      the ASBR, as well as type-4s won't have to be originated.

 To back this up, I had to debug a huge (really), multi-area
 OSPF network, where administrators decided to configure
 the "redistribute" command on _all_ access routers though most
 of them didn't have any externals to announce and the E-bit
 was set regardless of whether ASEs were originated or not...
 Imagination will help with the rest of the story ;)

--
Alex Zinin

Wednesday, September 26, 2001, 7:52:08 AM, Acee Lindem wrote:

> "Xie, Feng" wrote:
>>
>> Hi, Hans:
>>
>>     The access of the OSPF MIB object:ospfASBdrRtrStatus is read-write. This
>> means that this object is configurable. Usually, a user command is provided
>> to configure a router to be an ASBR.

> Feng, Hans,

> While the dynamics of route redistribution are typically an implementation
> specific matter, my opinion is that providing a user ASBR command is not the
> best alternative. Rather, I'd take one of the approaches suggested by Hans.

>   1. Set the E bit in router LSAs and ospfASBRBdrRtrStatus if the router
>      has the potential to advertise type 5/7 LSAs. A router will
>      potentially advertise type 5/7 LSAs if:

>        A) Route redistribution is configued
>        B) Default origination is configured
>        C) The router is an ABR and has one or more attached NSSAs

>   2. Monitor the count of type 5 LSAs and re-originate the router LSAs
>      for normal areas when the count changes from 0 to 1 or 1 to 0. Also,
>      monitor the count of type 7 LSAs and re-originate the router LSA
>      for the corresponding NSSA when the count changes from 0 to 1 or 1 to 0.

> There are trade-offs between the two. I prefer #1 since it reduces the
> potential for router LSA re-originations.


>> If the router is configured as an ASBR
>> (or an ABR in NSSA case) and the area to which the router lsa is flooded is
>> not a stub area, then the E bit should be set in the router lsa no matter
>> whether type-5 lsas have been generated by this router or not. This also
>> answers your third question. That is the setting of the OSPF MIB
>> object:ospfASBdrRtrStatus doesn't mean that the E-bit is set in every
>> router-lsa generated by the router because the former is per ospf instance
>> and the later is per area.
>>
>> Feng Xie
>>
>> -----Original Message-----
>> From: Hans DE VLEESCHOUWER [mailto:Hans.DE_VLEESCHOUWER@ALCATEL.BE]
>> Sent: Wednesday, September 26, 2001 9:17 AM
>> To: OSPF@DISCUSS.MICROSOFT.COM
>> Subject: AS border router.
>>
>> I have a couple of questions related to the E-bit in the
>> router LSA. (This bit, when set, indicates that the router
>> is a AS-border router)
>>
>> 1. I do not find any direct configuration option for this
>>    option in the OSPF-MIB, hence I assume that this bit is
>>    always set by the protocol engine itself?
>>
>> 2. If this is correct, then I still see 2 options, of which
>>    I do not know if both are equally good:
>>     option 1: we set the bit when we actually generate
>>         an LSA type 5/7; i.e. the option reflects very
>>         dynamically that we actually did generate AS external
>>         information.
>>
>>     option2: we set the bit when we know that some kind
>>         of redistribution is configured.
>>
>> 3. Is it true to say that the setting of the E-bit is
>>    reflected one to one by the OSPF MIB object:ospfASBdrRtrStatus?
>>
>> Thanks for any feebback,
>>
>> hans.

> -- Acee

[prev in list] [next in list] [prev in thread] [next in thread]