FW: OSPF for 400+ Locations

From: Michael Snyder (msnyder@revolutioncomputer.com)
Date: Wed Feb 19 2003 - 13:45:29 GMT-3


I like hammock design for these things.

                  --(site 1)--
                 / \
                 ---(site 2)---
                / \
(East Coast NOC)----(Site 3)-----(West Coast NOC)
                \ /
                 ---(Site 4)--/
                  \ /
                   -(Site 5)-

Each site has two frame-relay pvc's, one going to each NOC.

Not necessary to have high cir's on both site pvcs thought. Use ospf
delay to select the primary pvc for each office. The backup pvc can
have zero cir.

The NOC's have a fat pipe between them.

It would be hard to knock down such a redundant design.

BTW, the fat pipe between nocs and the main router loopbacks are
assigned to area 0 if you are using ospf.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chuck Church
Sent: Tuesday, February 18, 2003 7:37 PM
To: Aaron Woody; mohammed@sulafsolutions.com; ccielab@groupstudy.com
Subject: Re: OSPF for 400+ Locations

Aaron,

    With as large as this is getting, you really want to do this right
from
the start. Has the company given any thought to disaster recovery?
With a
thousand remote sites, this can't be a small company, so a circuit loss
at
the main site could be horrific. Backup PVCs to another location are
the
norm for a network of this size. But it's nothing that OSPF can't
handle.
Just design it right, and maybe you'll get a big bonus for a good job!

Chuck Church
CCIE #8776, MCNE, MCSE

----- Original Message -----
From: "Aaron Woody" <awoody@columbus.rr.com>
To: <mohammed@sulafsolutions.com>; <ccielab@groupstudy.com>
Sent: Tuesday, February 18, 2003 5:50 PM
Subject: RE: OSPF for 400+ Locations

> I just found out today they will be growing to 1000 sites and I will
still
> have to design dial backup solution.
>
> Aaron
>
> -----Original Message-----
> From: Mohammed Al-zubi [mailto:mohammed@sulafsolutions.com]
> Sent: Tuesday, February 18, 2003 3:40 AM
> To: 'Aaron Woody'; ccielab@groupstudy.com
> Subject: RE: OSPF for 400+ Locations
>
>
> Aaron,
> I've seen similar configurations, specially at banks (ATMs running
FR/OSPF).
> to be honest, if there are no networks behind the spoke routers (I
think
> there are none because you were going to configure them as Totally
stubby)
I
> would just implement static routes, you would just have to put a
default
at
> the remote sites, and 400 statics at the hub, its MUCH less work and
> headache, and this way when you roll it out you have less
configuration to
> deal with. If you still need these routes to appear in the OSPF
domain
> beyond the hub, then redistribute it back to OSPF at the hub with a
summary
> address, so 400 networks would show up in your site routing table as
one
> route, and you just simplified the configuration of 400 sites.
>
>
> Thanks,
> Mohammed
>
> <><><><><><><><><><><><><><><><><><><><>
> Mohammed Al-Zubi
> VP Professional Services
> 24 Werner Ave. #21
> Daly City, CA 94014
> Tel: (650) 438-6384
> Fax: (720) 293-4897
> Email: mohammed@sulafsolutions.com
> Web: www.sulafsolutions.com
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Aaron Woody
> Sent: Tuesday, February 11, 2003 3:21 PM
> To: ccielab@groupstudy.com
> Subject: OSPF for 400+ Locations
>
>
> I have experience with OSPF but I am looking for suggestions on how to
> implement OSPF in a Frame-Relay Hub/Spoke topology for 400+ locations.
Each
> location only needs to know about the host through a default. My first
idea
> is to have a separate area for each location and make it a totally
stubby
> area. Is there a better way. My concern is that there will be 400+
areas
in
> the OSPF Database at the host. The host will be a Cisco 3745. The
remotes
> will all be Cisco 1751.
>
> Thanks!
>
> Aaron
>
> [GroupStudy.com removed an attachment of type application/ms-tnef
which
had
> a name of winmail.dat]
> .



This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:32 GMT-3