something interesting i noticed about OSPF non-broadcast

while mucking around with my home lab i noticed something that i found to be interesting.

I have an OSPF non-broadcast network configured over a frame-relay switch. So as you know in a non-broadcast network you need to specify the neighbors using the nieghbor command.

So i have my hub router setup with a few neighbor commands and everything is good. I decide to remove a neighbor command to see some of the debug logs. What i found was that even though i removed the neighbor command for a specific network, the routers were still neighbors. I thought i would have to wait for the dead time to expire before they lost their adjacencies but they never did, the dead timer kept getting refreshed so obviously hellos were still being received.

Once i shutdown an interface and brought it back up the routers in question lost the adjacency, but i just found it interesting that they remained neighbors even thou i removed the neighbor command.

So is this standard OSPF behavior?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

mikej412

I'd say so -- sometimes you have to clear the ospf process to get it to recognize a change that affects the existing configuration.

cristi.grigore

You said that you have neighbor commands on the hub router. Do you have the same neighbor commands on the spoke routers as well?

In Cisco IOS you only have to configure one router with a neighbor command (the second one does not have to have the mirroring neighbor command configured) in order to get an OSPF adjacency. But this could also be a glitch needing an OSPF process reset, as mikej412 said.

mikej412

cristi.grigore wrote:

In Cisco IOS you only have to configure one router with a neighbor command (the second one does not have to have the mirroring neighbor command configured) in order to get an OSPF adjacency.

Key Point -- and the first thing I thought of -- but since the adjacency didn't reform after the shut/no shut I decided it wasn't the case.

I remember thinking about mentioning it.... since it is an important fact to know.

I'd guess it was more of a programmer code size/memory issue..... and let the admin control the update flood in case there lots of changes to make.

cristi.grigore

mikej412 wrote:

Key Point -- and the first thing I thought of -- but since the adjacency didn't reform after the shut/no shut I decided it wasn't the case.

I tend to agree with you, but I would still like a confirmation from rakem

rakem

cristi.grigore wrote:

You said that you have neighbor commands on the hub router. Do you have the same neighbor commands on the spoke routers as well?

nope neighbor command was only on the hub.

cristi.grigore

rakem wrote:

nope neighbor command was only on the hub.

That is rather strange. I tried this myself. R1 is connected to R2 through frame relay, ospf network type is set to non-broadcast and the neighbor command is only issued on R1

R1

Neighbor ID     Pri   State           Dead Time   Address         Interface
N/A               0   ATTEMPT/DROTHER 00:00:12    192.168.1.2     Serial1/0
R1-hub#
*Sep 17 15:24:00.435: %OSPF-5-ADJCHG: Process 1, Nbr 200.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done
R1-hub#
R1-hub#
R1-hub#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
200.2.2.2         1   FULL/DR         00:01:50    192.168.1.2     Serial1/0
R1-hub#
R1-hub#
R1-hub#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1-hub(config)#router ospf 1
R1-hub(config-router)#no nei
R1-hub(config-router)#no neighbor 192.168.1.2
R1-hub(config-router)#end
R1-hub#
R1-hub#
*Sep 17 15:24:31.607: %OSPF-5-ADJCHG: Process 1, Nbr 200.2.2.2 on Serial1/0 from FULL to DOWN, Neighbor Down: Neighbor deconfigured
R1-hub#
R1-hub#
R1-hub#
*Sep 17 15:24:32.659: %SYS-5-CONFIG_I: Configured from console by console
R1-hub#sh ip ospf ne
R1-hub#sh ip ospf neighbor

R1-hub#

As soon as I took out the neighbor command, the adjacency was cut. You problem is one of those "sometimes..." situations

By the way, I was running IOS 12.4(16)

dtlokee

Yeah that "neighbor deconfigured" message showed up a few IOS versions ago, I don't remember when but I noticed the change when doing this in the lab. Not all IOS versions will trigger a reset of the connection for this type of configuration change.