OSPF with Multiple ABR & ASBR

devang patel devangnp at gmail.com
Fri Nov 14 15:52:12 UTC 2008


Sorry about that!!!

1.  Do these remote areas have multiple paths to the central area for
failover?  E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL
secondary?
2.  Does the central area have multiple routers for failover?  E.g. a Cisco
7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660
for the slower secondary connections?
3.  Are there any tie-ins between the remote sites that bypass the central
site?  E.g. site1 and site2 both communicate to the central site via Metro
Ethernet, and they also communicate to eachother via DSL.


Answers:
 I have two T1 line to the non-backbone area and both T1s are terminated to
the two different routers on non-backbone area as well as to backbone area,
and I dont want to achieve primary and secondary role, I want to go for the
load sharing kind of scenario. All sites are connected with the central
site.

ABR means Area border router only.

I am attaching one generalized diagram, please look at that one.
Now I want to achieve the load balancing between the traffic going from R1
to R8, I want to achieve some of the networks on R1 should be reachable via
R2 and some of them via R3 for the traffic coming from the R8.  assume all
links are same.

regards
Devang Patel


On Fri, Nov 14, 2008 at 9:29 AM, Patrick Darden <darden at armc.org> wrote:

>
> First, without any details, it sounds like you might be better off with
> static routes than with OSPF.  I'm not trying to be patronizing, but you
> don't mention many details, and some of the details you omit are the crucial
> ones for OSPF.
>
> 1.  Do these remote areas have multiple paths to the central area for
> failover?  E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL
> secondary?
> 2.  Does the central area have multiple routers for failover?  E.g. a Cisco
> 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660
> for the slower secondary connections?
> 3.  Are there any tie-ins between the remote sites that bypass the central
> site?  E.g. site1 and site2 both communicate to the central site via Metro
> Ethernet, and they also communicate to eachother via DSL.
>
> If none of the above are true, then static routes would be better for you
> (for the remote area/s in question).  E.g. area1 has multiple paths, so ospf
> is warranted; however, area2 has just one path so a static approach would
> usually be better.
>
> Your language seems to indicate that OSPF is warranted (area0, area1, two
> ABRs).  I am assuming you mean Area Border Router not Associative Based
> Routing (vs. OSPF).  I am also assuming this is a non-public system
> (internal network, probably a MAN or WAN).
>
> If so, without any further details, I would set it up for
> bandwidth/failover.  Weight the paths appropriately.  Keep it as simple as
> you can.  OSPF can become a morass.
>
> If you sketch your situation out more, we can be more helpful....  Campus?
>  MAN?  How public?  Multi-pathed?  Multi-homed?  Multiple interlinks?  Are
> there some lines with reliability problems where the lower bandwidth links
> are actually preferred?  Do you have any decentralized concentration points
> that might have problems due to multiple remote sites shuttling traffic
> through it (due to multiple interlinks)?
>
> --p
>
>
> devang patel wrote:
>
>> Hi All,
>>
>> I am not sure is this the good place to ask this question or not!!!
>>
>> I am looking for feed back on having OSPF multi-area, lets say if you have
>> multiple location in nonbackbone areas and those nonbackbone areas are
>> connected with the one backbone area. For example: OSPF AREA1 has the
>> connectivity to OSPF AREA0 using two ABR, so what is the optimum way to
>> achieve the load balancing or load sharing for traffic entering or leaving
>> the area, what are the possible way to configure it?
>>
>> regards
>> Devang Patel
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSPF.jpg
Type: image/jpeg
Size: 51738 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081114/0f241be7/attachment.jpg>


More information about the NANOG mailing list