Maybe Discontiguous is the wrong word for it. The problem I see with this
design is that there is basically 2 Area 1s. The point -to- point
connections would be fine, however in order for the Areas to function
properly they need to know of each other ( all of Area 1 as a whole needs to
know of the other) This is done via LSA Types 1 and 2. I know the
reasoning for the Area 2, however I still stand behind the notion that if
you were to change the Frame-Relay Area to 3 your problem would be solved
You might also get around this by changing from point to point to a
non-broadcast environment and specify all of your neighbors Router IDs' :
R1 (S0) R2(BRI0) R9(S0) and R8(BRI0) on each of the routers.
-----Original Message-----
From: Chuck Larrieu [mailto:[EMAIL PROTECTED]]
Sent: Mon 2/4/2002 8:33 PM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: OSPF DR problem [7:34379]
Cil, I drew this one out a little differently just to put a fresh
perspective on it. Without seeing the requirements of the particular
practice lab you are using, it's hard to say why you were seeing or not
seeing what you did.
area 0
--------------------------------------------------
| |
R1 R2
| |
frame relay area 1 ISDN area 1
| |
R9 R8
| |
-------------- -------------
area 2
The discontiguous area 1's are irrelevant unless there is overlapping
addressing. The area 2 is placed the way it is in order to force the
creation of a virtual link - common in practice labs and study materials, as
all us CCIE candidates know full well ;->
I am inferring from other comments in other posts that you needed to use the
IP ospf priority command on the R2 ethernet because the requirement is that
R1 is the DR in area 0.
So, given what I see ( not knowing the particulars of your addressing and
various other things, there is no good reason why R9 and R8 should not see
the ethernet network that is area 0.
Along the trail of broken things, I have sometimes run across bizarre issues
which are solved only by reloading routers. My humble pod of 2501's running
enterprise 12.1.11 code sometimes have bizarre problems. I have a theory
that these bloatware images just barely operate within the confined spaces
of 16 megs of DRAM and sometimes you have to clear it out. I have had
bizarre things happen when configuring and unconfiguring various routing
protocols and features. Sometimes, admittedly, mistakes happen when you are
tired, and you can't see straight to correct errors you have made. But other
times, reloads have made magic happen. I am at the point where I am thinking
about backloading to an IOS build that takes less space, just to see if the
occasional weirdness disappears.
Again, based upon what I have seen throughout this thread, and given that
your areas and other configurations are correct, I see no reason why the
area 0 network should not be visible from R9 and R8.
Chuck
PS as has been discussed here and elsewhere many a time, good practice and
good design have little in common with the CCIE Lab ;->
PPS which practice lab are you looking at? I have NLI, IPExpert, and
SolutionLabs at my disposal.
""Priscilla Oppenheimer"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Remember, I think from a design point of view. I say "for some reason
> there's an Area 2" because I think it's a bad design not because I was
> surprised to see it there in the show output. ;-) But thanks for replying,
> because it made me question my expectations.
>
> Here's what part of the network design looks like:
>
> ---R2---Area-1-ISDN----R8---Area-1-Ethernet
> |
> Area 0 |
> Ethernet |
> |
> ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet
>
> When I did a "show ip route" on R9 and R8 I thought I would see the
> Ethernet LAN in Area 0. That was not a logical expectation? I should just
> see a default route on ABRs?
>
> Thanks.
>
> Priscilla
>
> At 07:09 PM 2/4/02, s vermill wrote:
> >Priscilla Oppenheimer wrote:
> > >
> > > There was a virtual link. The virtual link was from R1 over to
> > > another
> > > router across the Frame Relay cloud. R1 is an ABR connecting
> > > Area 0 and
> > > Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay
> > > cloud. For
> > > some unknown reason, there's an Area 2 also on the other side
> > > of Area 1.
> > > Does that ring a bell regarding any gotchas?
> >
> >Priscilla,
> >
> >There must be at least three areas involved in a virtual link. So I am
> >intrigued by the phantom area 2. What area were you expecting to see on
the
> >other side of area 1? In your case, it seems as if the ABRs are directly
> >connected. That is to say, the transit area is in essence a p-t-p
> >connection. That isn't always necessarily the case so I don't think OSPF
> >makes any kind of distinction. As I understand it, the virtual
> >connection/tunnel is treated like an unnumbered one. So the network
> >statements have to be in place for the transit area in both routers, area
0
> >in the backbone ABR, and the discontiguous area in the discontiguous ABR.
> >So that is the basis for my interest in your phantom area 2.
> >
> >Of course, this doesn't seem to be in any way related to why you wouldn't
be
> >able to see the area 0 network across the ISDN connection. The
interesting
> >parallel is that virtual links and demand circuits are both treated the
> >same. That is, the DNA bit is set for routes learned via either one. So
is
> >there anything in your setup not consistent with having DNA show up in
the
> >topo table? I can't imagine what but I have never tried anything like
your
> >setup.
> >
> >Tough one!
> >
> >Scott
> ________________________
>
> Priscilla Oppenheimer
> http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=34436&t=34379
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
