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=34430&t=34379
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to