This is why I didn't make too big of a deal about the two instances of area one. I know a discontiguous area 0 is bad, but I seemed to recall that it doesn't matter if there are multiple instances of other areas. I wasn't sure of that, though, it was just in the back of my mind.
It will be interesting to see how this turns out. John >>> "Chuck Larrieu" 2/5/02 12:07:24 AM >>> Two comments: 1) so long as there is an area 0, and all other areas connect to it, those other areas can all be area 1 ( or any other arbitrary number ) and there will be no reachability problems. This assumes no overlapping subnets. Other than making summarization a bear, there is nothing "wrong" with doing it this way. Bad practice and bad design, but not bad behaviour. 2) I'm interested in your rationale as to why a discontiguous area 1 would in and of itself cause a problem with routers in either of the discontiguous areas such that they cannot see area 0 routes. I can't think of one myself, which may or may not mean anything. Chuck ""Dusty Harper"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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=34460&t=34379 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
