That's it! Wow, very cool. That's really been bugging me. I posted it to the TAC Open Q&A Forum, so we'll see if they come up with the right answer! :-)
Thanks for letting me know about that, I appreciate it. John ---- On Sun, 13 Jan 2002, Stefan Dozier ([EMAIL PROTECTED]) wrote: > John, I've been following your thread and think I found a possible > answer > to your question on why the neighbor statement gets ignored when entered > on spoke routers! > > In the OSPF Desig Guide "Section 1" under "Adjacencies on Non- Broadcast > Multi-Access (NBMA) Networks" the next to last statement in the > paragraph > gives us a clue. > > "The neighbor command applies to routers with a potential of being DRs > or > BDRs > (interface priority not equal to 0)." > > So to test that theory, I changed the priority on one of my spokes to 1 > from 0 and viola, it takes the neighbor statement just fine. Prior to > changing the interface priority I could enter the neighbor statement > under > the OSPF process, but it didn't show up in the config. > > Spoke Router: > > interface Serial0 > ip address 192.1.1.1 255.255.255.0 > no ip directed-broadcast > encapsulation frame-relay IETF > logging event subif-link-status > logging event dlci-status-change > frame-relay map ip 192.1.1.2 100 broadcast > frame-relay map ip 192.1.1.3 100 broadcast > frame-relay lmi-type ansi > ! > router ospf 64 > network 192.1.1.0 0.0.0.255 area 0 > neighbor 192.1.1.2 > > Hub Router: > > interface Serial0 > ip address 192.1.1.2 255.255.255.0 > encapsulation frame-relay IETF > frame-relay map ip 192.1.1.1 100 broadcast > frame-relay map ip 192.1.1.3 200 broadcast > frame-relay lmi-type ansi > ! > router ospf 64 > log-adjacency-changes > network 2.2.2.2 0.0.0.0 area 0 > network 192.1.1.0 0.0.0.255 area 0 > neighbor 192.1.1.3 > neighbor 192.1.1.1 priority 1 I thought you only need the neighbor > statement on one side of > the > > connection? > > > > Once a router accepts the hello, adjacencies are formed with > information > > from the hello via unicast communication from that point > forward. > > > > Sort of like if I shout over a hill, "Hey Routerman are you > there, this > > is > > Jim." Then you would respond back to me by name. > > > > -----Original Message----- > > From: Router Man [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, January 13, 2002 10:28 AM > > To: [EMAIL PROTECTED] > > Subject: Re: OSPF and The Disappearing Neighbor Statement > [7:31656] > > > > > > I was able to reproduce your exact scenario. I had a hub > with two > > spokes > > and the neighbor statements only appeared on the hub. This is > very > > interesting and I'm not sure what the reason behind it is. I > am glad > > that > > this was brought up, because I would love to get to the > bottom of this > > situation. I'll keep you posted ""John Neiberger"" wrote in > message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > The network statement definitely was there, but the > neighbor > > > statements would only appear on the hub router. > Interestingly, I just > > > > > saw a sample configuration similar to this on CCO and they > only had > > > the neighbor statement on one router, not both. I think as > long as > > > one router has a neighbor statement configured, the > adjacency will > > > form assuming all other things being equal (network type, > etc.) > > > > > > The adjacencies formed but I had to cycle the interfaces to > get things > > > started. Even if the neighbor statement is only required > on one > > side, > > > I still don't understand why the router wouldn't let me add > it. The > > > adjacencies would eventually form, however, and routing > occurred > > > exactly as I expected it. > > > > > > I did notice a minor issue with the neighbor statements on > the hub. I > > > > > had three of them, and one of them inserted 'priority 1' at > the end, > > > yet the other two remained as I entered them. > > > > > > >>> "Router Man" 1/11/02 3:08:03 PM >>> > > > The only time that the "neighbor" statement will not show > up in the > > > running-config, is if you do not have a "network" statement > under the > > > "router ospf" process. I am doubting that the neighbors > formed an > > > adjacency without the neigbor or network statements showing > up under > > > the ospf config. > > > If the adjacency was actually formed, then it must be a bug. > > > > > > Another thing that I have noticed is than when trying to > use the > > > neighbor statement to set the priority, "neighbor 1.1.1.1 > priority > > > 255" the priority > > > will change to something other than what I set it too. It > took me a > > > while > > > to figure this one out. The problem is that I have to > have matching > > > "ip > > > ospf priority 255" statements under the interfaces running > ospf . > > > ""John Neiberger"" wrote in message > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > It was hot, too hot. Our detective had been working > feverishly to > > > > configure OSPF over NBMA without the use of ip ospf > network > > > statements. > > > > He knew that to do this he must explicitly add neighbor > statements > > > or > > > > adjacencies would not form. > > > > > > > > He logs into the hub router and types in his three > neighbor > > > statements. > > > > All seems well. It's still too hot, but it's a dry heat. > > > > > > > > He now logs into one of the spoke routers and types in > his neighbor > > > > statement. He pauses momentarily and then checks the OSPF > > > adjacencies. > > > > Something seems to be wrong, he thinks to himself. This > ought to be > > > > > > working, but it isn't. Why not? He looks through the > running > > > > config > > > to > > > > look for any errors and notices the the neighbor > statement that he > > > just > > > > entered is missing! > > > > > > > > He slowly and deliberately types it in again making sure > there are > > > no > > > > mistakes but yet it still does not show up in the running > > > configuration. > > > > Is this an IOS issue? Operator error? Some rift in the > space-time > > > > > > continuum? > > > > > > > > He jumps to another spoke router running a different IOS > and tries > > > the > > > > same thing with the same result. He is frantic now, > beads of sweat > > > > pouring down his face. What if this were the real CCIE > lab exam? > > > Could > > > > this be a fatal stumbling block? > > > > > > > > He finally notices that adjacencies do eventually form > after > > > clearing > > > > the relevant interfaces. This must be because the hub > router > > > accepted > > > > the neighbor statements. But what if it hadn't, he > ponders. He > > > thinks > > > > forward into the future when--a day after taking the lab > exam--he > > > > receives the dreaded email that says, "We're sorry, it is > apparent > > > that > > > > you have no clue." > > > > > > > > Back to the real world.... > > > > > > > > What was the cause of the missing neighbor statements? > Have any of > > > you > > > > run into this before? I've never bothered to explicitly > use > > > neighbor > > > > statements as I'm in the habit of using the ip ospf > network command > > > to > > > > make them unnecessary. > > > > > > > > Any thoughts? > > > > > > > > Thanks, > > > > John > [EMAIL PROTECTED] [EMAIL PROTECTED] > > ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=31794&t=31656 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
