Options
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?
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?
CCIE# 38186
showroute.net
showroute.net
Comments
-
Optionsmikej412 Member Posts: 10,086 ■■■■■■■■■■I'd say so -- sometimes you have to clear the ospf process to get it to recognize a change that affects the existing configuration.:mike: Cisco Certifications -- Collect the Entire Set!
-
Optionscristi.grigore Member Posts: 18 ■□□□□□□□□□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. -
Optionsmikej412 Member Posts: 10,086 ■■■■■■■■■■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.
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.:mike: Cisco Certifications -- Collect the Entire Set! -
Optionscristi.grigore Member Posts: 18 ■□□□□□□□□□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 -
Optionsrakem Member Posts: 800cristi.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.CCIE# 38186
showroute.net -
Optionscristi.grigore Member Posts: 18 ■□□□□□□□□□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
R2Neighbor 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) -
Optionsdtlokee Member Posts: 2,378 ■■■■□□□□□□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.The only easy day was yesterday!