Glad you like the art!
The 1.2.100.0 cable is in area 0 to prevent area 0 from being partitioned
- because the link to the core from Rtr2 is a dialup link (used for
failover if the main path goes belly-up), it usually isn't connected - so
without the 1.2.100.0 connection, Rtr2 doesn't have an area 0 connection
to the rest of the backbone. Rtr2 really needs to be an ABR so that when
the dialup link is used there is an ABR somewhere between the backbone
area and the rest of the network ;-)
Also, way way back in the dawn of time when this was first put together, I
will admit we thought it would get all the through traffic off the local
ethernets - we worked out in testing that it only worked in one direction
for that, but hey, glass half full, and that was a secondary reason
anyway.
I don't usually have to get down to the level of what LSAs are being
generated by what routers when I'm troubleshooting OSPF (it would probably
help if I did so more often - I have a bad tendency to assume routes are
being passed between routers, not LSAs). I'd like to think that has
something to do with the network being well-designed in the first place
(not that I can take all the credit for that though) ;-)
The switches don't fail often, but there are about twenty of these areas,
so that ups the odds a bit. And it's a bit drastic when it does happen -
up to a dozen or so sites off the air until the support guys glue them up
with sticky tape and string or the configuration equivalent.
JMcL
----- Forwarded by Jenny Mcleod/NSO/CSDA on 04/04/2002 03:34 pm -----
"Priscilla Oppenheimer"
Sent by: [EMAIL PROTECTED]
04/04/2002 12:50 pm
Please respond to "Priscilla Oppenheimer"
To: [EMAIL PROTECTED]
cc:
Subject: Re: OSPF design - with ascii art [7:40269]
Your ASCII art is beautiful. I feel bad that you haven't gotten a reply
after all that work! ;-) My guess is that you know more than most of us
about design and troubleshooting of an OSPF network of this size. (Well,
Howard would know as much too, of course.)
I haven't thought this through, but a gut instinct makes me ask:
Why is the 1.2.100.0 cable between Rtr1 and Rtr2 in Area 0? Would it solve
your problem by any chance if it were in area 2.1.0.0?? It could cause all
sorts of unwanted ramifications too, though.
Or, I like your suggestion from your first e-mail which was to install
another direct connection between Rtr1 and Rtr2 and put it in area
2.1.0.0.
Hey, can I use this as a case study in a book? ;-) It has great
educational
value. Easy for us to say. Hopefully you don't run into the actual problem
too often as the Switches and trunk between them shouldn't fail too often.
Priscilla
At 06:57 PM 4/3/02, [EMAIL PROTECTED] wrote:
>A few people have asked for a diagram, so here goes...
>
>We have many instances of this design - this is an example. Don't bother
>commenting on the use of address ranges - they were assigned pre-RFC1918
>and there has been no compelling reason to change them. It makes address
>assignment for new sites easy, and means I get no practice at binary
maths
>;-)
>
>Addresses in the core are generally in the 1.0.0.0/8 range.
>The local switches have addresses 2.0.1.0/24 (e1), 2.0.2.0/23 (e2),
>2.0.4.0/23 (e3). They are all in ospf area 2.1.0.0.
>The WAN links are frame relay point to point sub-interfaces. The remote
>sites each have an address range 2.x.0.0/16, where x is 100 or greater
>(the WAN links are included in these ranges). If x is 128 or greater,
>then the site is in ospf area 2.2.0.0 (and must be attached to Rtr2).
>Sites with address ranges from 2.100.0.0 to 2.127.0.0 are in area 2.1.0.0
>and may be attached to either router. If there aren't any sites with an
>address range 2.128.0.0 or greater, then ospf area 2.2.0.0 is not used
>(it's usually defined, though, to make adding new sites more
idiot-proof).
>
>In the diagram below, siteX is in ospf area 2.2.0.0 and other sites are
in
>ospf area 2.1.0.0 (assume siteA has an address range of 2.102.0.0/16).
>Rtr1 has ospf areas 0.0.0.0 (link to core and e0) and 2.1.0.0 (local
>ethernets and all WAN links).
>Rtr2 has ospf areas 0.0.0.0 (dialup link to core and e0), 2.1.0.0 (local
>ethernets and some or all WAN links), and 2.2.0.0 (remaining WAN links -
>possibly none).
>
>The area range statements on Rtr2 are...
>[various area 0 range statements snipped]
> area 2.1.0.0 range 2.0.0.0 255.128.0.0
> area 2.2.0.0 range 2.128.0.0 255.224.0.0
>
>On Rtr1 the statements are...
>[same area 0 range statements snipped]
> area 2.1.0.0 range 2.0.0.0 255.128.0.0
>
>If sw1 or sw2 fails, or the trunk between them fails, SiteD and SiteE
will
>no longer be able to contact the core.
>
> | :
> |to core to core :
> | (dialup):
> -------- 1.2.100.0/24 --------
> | Rtr1 |e0 ------------------- e0| Rtr2 |
> | | --- --- | |
> | |e1---| |trunk| |---e1| |
> | |e2---|sw1| |sw2|---e2| |
> | |e3---| | | |---e3| |
> | | --- --- | |
> | | /|\ /|\ | |
> -------- local switches --------
> | (dual homed) |
> /|\ /|\
> / | \ 2.120.0.0/16 / | \ 2.130.0.0/16
>siteA/ | \__siteC siteD__/ | \__siteX
> siteB 2.101.0.0/16 siteE
> 2.109.0.0/16 2.104.0.0/16
>
>JMcL
>
>----- Forwarded by Jenny Mcleod/NSO/CSDA on 04/04/2002 08:50 am -----
>
>
>"[EMAIL PROTECTED]" Sent by: [EMAIL PROTECTED]
>03/04/2002 12:05 pm
>Please respond to "[EMAIL PROTECTED]"
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: OSPF design [7:40269]
>
>
>Hi all,
>
>This is actually a real-life scenario, but I think it throws up some
>interesting points about OSPF that some people may not have come across.
>And it has a couple of bits that I don't understand. Please excuse the
>verbosity.
>
>Currently, (part of) this particular network is as described below. It
>normally works fine, but during certain types of failures, connectivity
>breaks although there is still a physical path. I am contemplating what
>the best way to fix it would be, and would be interested in comments.
>
>Set-up - I don't think my ascii art is up to this but I'll give it a go
if
>
>the description isn't clear enough:
>
>Two ABRs (Rtr1 and Rtr2), running IOS 12.1, connected to each other by a
>direct ethernet cable in area 0, and also by several local ethernet
>networks in area 2.1.0.0. The details of the local ethernets can
probably
>
>remain a fluffy cloud, but note that failure of a single component can
>potentially cause all area 2.1.0.0 neighbour connectivity between Rtr1
and
>
>Rtr2 to be lost, although the local ethernets may remain up on one or
both
>
>routers.
>
>Both routers have a connection back to the core of the network (on Rtr2
it
>
>is dialup, so not usually active), which is in area 0. Both routers have
>WAN links to several sites (not dual-homed - each site has a link to only
>one ABR), in area 2.1.0.0. Rtr2 may also have WAN links to several sites
>in area 2.2.0.0, but that's probably not too relevant.
>
>Both ABRs summarise the networks in area 2.1.0.0 to a single summary
>network (Rtr2 summarises the networks in 2.2.0.0, if any, to another
>summary network).
>
>This usually works fine - traffic from the core to sites connected to
Rtr2
>
>(in area 2.1.0.0) travels from Rtr1 to Rtr2 across the local ethernets
>(area 2.1.0.0), and in reverse from Rtr2 to Rtr1 across the Area 0
>ethernet. This, while perhaps not ideal, is as expected, and works well
>under normal circumstances. (If you're not sure why this is expected,
>read up on hot potato routing policy - Howard gave a good description in
>the context of stub areas in
>http://www.groupstudy.com/archives/cisco/200001/msg01579.html)
>
>The problem happens if the area 2.1.0.0 neighbour connections between
Rtr1
>
>and Rtr2 are lost. Even though there is still an area 0 link between
>them, area 2.1.0.0 sites connected to rtr2 lose connectivity to the core.
>Area 2.2.0.0 sites are OK (this is good - I'd be really confused if they
>lost it too).
>Despite Doyle claiming that partitioned non-backbone areas are not a
>problem (he does, on page 462 of Routing TCP/IP Vol 1), it seems they can
>be. As far as I can see, it's because when summarising the 2.1.0.0
>networks, Rtr1 also installs a route to null0 for the summary route -
>which overrides the summary route that Rtr2 generates (and which would
>otherwise cover the 'lost' sites).
>
>I can see a couple of possibilities for fixing this...
>1) Install a second direct ethernet cable between Rtr1 and Rtr2, in area
>2.1.0.0. This may not be particularly elegant, but it should be
>comparatively easy to do and effective (there are plenty of spare
ethernet
>
>ports). It also has the useful side-effect of getting the through
traffic
>
>off the local ethernets.
>
>2) Use the "no discard-route internal" command - this doesn't appear to
be
>
>documented but is mentioned at
>http://www.cisco.com/warp/public/104/3.html#12.0
>I haven't tested it, but I think it should prevent the null0 route from
>being installed by Rtr1, so my theory is that then the summary generated
>by Rtr2 should come into play. This, of course, goes against all Cisco
>recommendations, which say that having the null0 route is A Good Thing to
>prevent routing loops.
>
>3) Muck about with the arrangement of switches within the internal
>networks. I think this will cause more trouble than it's worth, since
any
>
>rearrangement has to be duplicated at twenty sites. In theory at least,
>the whole network may be redesigned from scratch over the next year or
so,
>
>so a quick and dirty fix isn't necessarily a problem.
>
>BUT... I am also not positive that my understanding of what is happening
>and why is correct, because the support guys have told me that this
>problem has been around since we were running IOS 11.2 on the ABRs (not
>that long ago, believe it or not), and I'm pretty sure that no route to
>null0 was being generated then (summarisation was the same).
>So can anyone explain to me why connectivity would fail even if no null0
>route was being generated? What am I missing?
>And does anyone feel like commenting on the options for fixing it?
>
>JMcL
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=40442&t=40269
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
