Re: OSPF multiple-area network
James Huang <James.Huang <at> watchguard.com>
2010-01-26 01:07:08 GMT
Hi Acee,
I thought Sec 16.5 is about receiving a new summary LSA for a
network N. It is not about transit area path changes (in which case it
will be new router-LSAs or new network-LSAs for the transit area).
Let's say network N is in one region of area 0 (area0-a), the transit
area is area 1, and the virtual link in area 1 connects area-0a to
another region of area-0 (area0-b) from ABR router R1 to ABR router R2.
ABR router R3 connects to area-0b and area-1. When R3 receives a new
summary-LSA for N from R2 that increases the cost to N, R3 needs to
re-compute 16.1/16.2 for area-0 and 16.3 for network N (for network N
and all destinations in area-0a reachable through N). Why does R3 have
to re-compute intra-area routes for area-1 or any other areas it
attaches to?
This brings up another question: why sec 16.3 does not mention about
re-computing area 0's intra-area routes for those destinations behind N
if it find a better route to N than what was originally found in
16.1/16.2?
Thanks,
James Huang
-----Original Message-----
From: Acee Lindem [mailto:acee.lindem <at> ericsson.com]
Sent: Monday, January 25, 2010 4:13 PM
To: James Huang
Cc: ospf <at> ietf.org
Subject: Re: [OSPF] OSPF multiple-area network
Hi James,
On Jan 25, 2010, at 6:35 PM, James Huang wrote:
> Hi Acee,
>
> Thanks for the reply.
> I agreed with you that RFC 2328 assumes each network can only
> reside in one area and that is what I always assume too. But when I
> tried to find a scenario to explain the reason for re-running the
> complete SPF route computation starting from sec 16.1 in Case 2 of sec
> 16.5 (incremental updates: summary-LSAs), I just cannot find one
unless
> there is a multi-area network. If you have one scenario to explain
Case
> 2 of sec 16.5, can you show it?
If the path through the transit area was used to update intra-area path
through the backbone as described in 16.3 and now the cost of a transit
area path increases, you must rerun the intra-area SPF which, in the
case of RFC 2328, implies rerunning the complete SPF. This isn't to say
that the intra-area portion couldn't be done incrementally as well but
it isn't described in RFC 2328.
Hope this helps,
Acee
>
> Thanks,
> James Huang
>
>
> -----Original Message-----
> From: Acee Lindem [mailto:acee.lindem <at> ericsson.com]
> Sent: Monday, January 25, 2010 2:48 PM
> To: James Huang
> Cc: ospf <at> ietf.org
> Subject: Re: [OSPF] OSPF multiple-area network
>
> Hi James,
> The excerpted text is referring to multiple LSAs in the same area -
not
> LSAs in different areas. If you read it closely you'll see that the
> example given is a transient condition. While some vendors do, in
fact,
> support an IP subnet connected to multiple areas, this is not
> considered to be a valid topology and is not addressed by RFC 2328.
> Consider the following excerpt from page 6 of RFC 2328:
>
>
> OSPF allows sets of networks to be grouped together. Such a
> grouping is called an area. The topology of an area is hidden
> from the rest of the Autonomous System. This information
hiding
> enables a significant reduction in routing traffic. Also,
> routing within the area is determined only by the area's own
> topology, lending the area protection from bad routing data.
An
> area is a generalization of an IP subnetted network.
>
>
> Hope this Helps,
> Acee
>
> On Jan 25, 2010, at 4:30 PM, James Huang wrote:
>
> Hi all,
> When a network is connected to multiple areas (maybe as
> a stub network), what is the expected behavior according to RFC 2328?
> In RFC 2328, a "network" route is always associated with a single
area.
> But in the following topology, router R will receive two network-LSAs,
> one from each attached area: R is connected to area-1 and area-2.
R's
> area-1 neighbor R1 has an interface (part of area-1) connected to a
stub
> network N. R's area-2 neighbor R2 has an interface (part of area-2)
> also connected to the stub network N.
>
> RFC 2328, Sec 16.1, Step (4) has some consideration for
> resolving conflicting intra-area network routes. But is it applicable
> to this case?
>
> If the routing table entry already exists
> (i.e., there is already an intra-area route to the
> destination installed in the routing table), multiple
> vertices have mapped to the same IP network. For example,
> this can occur when a new Designated Router is being
> established. In this case, the current routing table entry
> should be overwritten if and only if the newly found path
is
> just as short and the current routing table entry's Link
> State Origin has a smaller Link State ID than the newly
> added vertex' LSA.
>
> Also I do not understand this RFC 2382 logic above.
Why
> does it have to compare both the distance and the link state ID.
> Suppose there are two possible paths, P1 and P2, to a network. P1 is
> shorter than P2 but P1 has an origin of smaller link state ID.
> According to this rule, which path will be installed in the routing
> table depends on the order the LSAs are examined. That seems very
> strange to me.
>
> Thanks,
> James Huang
>
>
>
> _______________________________________________
> OSPF mailing list
> OSPF <at> ietf.org<mailto:OSPF <at> ietf.org>
> https://www.ietf.org/mailman/listinfo/ospf
>
RSS Feed