From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Sat Sep 21 2002 - 11:38:09 GMT-3
At 4:17 PM -0600 9/20/02, Joe Martin wrote:
>Yes, it seems some people are confusing the Process ID with the Area ID.
>
>The process ID is stated when enabling OSPF or when entering an existing
>OSPF process. The process ID is only locally significant.
>
>router(config)#router ospf 100 <--- this is the Process ID
>
>The Area ID is not locally significant or OSPF would never work. The area id
>is carried in the LSA. This is how you can see all areas in your OSPF
>internetwork with the "sh ip ospf database" command.
>
>Someone PLEASE correct me if I'm wrong.
This may seem roundabout, but I think you can learn a good deal about
the semantics of the OSPF Opaque LSA, and then expanding on it.
Opaque LSAs (see http://www.ietf.org/rfc/rfc2370.txt ) are part of a
trend to use routing protocols as general-purpose signaling
protocols, carrying information to all concerned routers. That trend
is quite controversial, but that is a tale for another time.
Anyway, it defines three kinds of LSA:
> The flooding scope associated with each Opaque link-state type is
> defined as follows.
>
> o Link-state type 9 denotes a link-local scope. Type-9 Opaque
> LSAs are not flooded beyond the local (sub)network.
>
> o Link-state type 10 denotes an area-local scope. Type-10 Opaque
> LSAs are not flooded beyond the borders of their associated area.
>
> o Link-state type 11 denotes that the LSA is flooded throughout
> the Autonomous System (AS). The flooding scope of type-11
> LSAs are equivalent to the flooding scope of AS-external (type-5)
> LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout
> all transit areas, 2) not flooded into stub areas from the
> backbone and 3) not originated by routers into their connected
> stub areas. As with type-5 LSAs, if a type-11 Opaque LSA is
> received in a stub area from a neighboring router within the
> stub area the LSA is rejected.
So you have three conceptual scopes of knowledge: single subnet,
area, and "OSPF AS" (really OSPF domain). Add another conceptual
scope, single router. There's also a subtle distinction between true
all-AS and certain-kinds-of-area only.
With this addition:
Data element Scope
------------ -----
Router ID Single router
Designated router ID Single subnet
Type 2 LSA Single area
Type 5 LSA All non-stubby areas
In principle, anything can be flooded as long as it's uniquely
identifiable within its scope.
In practice, why try to reuse resources of which there are plenty?
Surely 32 bits (well, minus 1 for 0.0.0.0) gives you enough area
identifiers to suit any need. You can't use the argument that you are
delegating administration, because the backbone area administrator
has to know about all areas.
And even more to the point here, why reuse ANYTHING if it might cause
30 seconds of ambiguity under the time pressure of the CCIE lab?
Reuse, in general, tends to lead to troubleshooting confusion -- do
it only when the resource in question truly is scarce.
>
>Joe
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Joseph Rinehart
>Sent: Friday, September 20, 2002 3:13 PM
>To: ccielab@groupstudy.com
>Subject: Re: OSPF area ID (big fight at work)
>
>
>I assume by area ID that you mean process id (e.g., router bgp 100), and if
>that is true yes the process ID is local to the router only. Area id (area
>0, area 10, etc), is definitely not local to the router or OSPF would never
>work.
>
>Can you clarify?
>
>Joed
>----- Original Message -----
>From: "Rick" <ccie_2003@hotmail.com>
>To: "Ccielab (E-mail)" <ccielab@groupstudy.com>
>Sent: Friday, September 20, 2002 11:49 AM
>Subject: OSPF area ID (big fight at work)
>
>
>> Can someone tell me that I can use the same OSPF area multiple times in
>the
>> same process as long it is talking to area 0. The area ID is not carried
>in
>> the LSA header.
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:59 GMT-3