OSPF neighbor statements disapearing
I am trying to work on one of the labs and the issue i keep running into is that OSPF neighbor statements are GONE ... this is VERY frustrating ... and even more frustrating to think that if i finish the lab and proctor reloads the rack and statements will be missing .... that wont be good :-( ....Has anyone had this happen to them before?
I finished basic connectivity and IGP cofniguration last night for lab 7 (version 5). I was able to verify that everything was working (all local links and protocols) and thought i was gonna hit redistribution today ... i power up my rack and ... umm ... no neighbors for OSPF between R1 (DR) to R3 and R2. OK .. they got lost .. i am trying to ut them back on ... and NOTHING they do not show up in the config .. is this normal? or am i loosing my head?
Topology R3 -> R1 <-R2 .... all links set to non-broadcast so i have to have neighbor statements configured ... another issue is on R1, i am trying to configure neighbor command and getting following error :
Rack1R1(config-router)#neigh 163.1.12.2
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
Rack1R1#sh ip ospf int s0/0
Serial0/0 is up, line protocol is up
Internet Address 163.1.12.1/24, Area 2
Process ID 1, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 64
Interface is NBMA ...??? tried reloading the routers and still the same ... Now, i tried putting neibor command on R2 and it DOES NOT show up in the config BUT it works ... in debug i see router unicasting hello's to R1 peer IP and i see neighor come up .... at this point i am hitting WTF moment ...
any help is greatly appriciated ... (i am VERY close to opening my window and dead lifting my rack and throwing out the window ... yes it cost me thousands and thousands of dollars and countless hours of frustration ... but grrrrr)
Comments
Here is some more stuff on this ... (while i was typing all that ...OSPF decided to work)
I will take snapshot from R3 and R1 to show configs and outputs ....
Rack1R3#sh run | sec router ospf
router ospf 1
router-id 150.1.3.3
log-adjacency-changes
redistribute connected metric 1 subnets route-map CONNECTED->OSPF
network 163.1.13.3 0.0.0.0 area 1
network 163.1.35.3 0.0.0.0 area 1
Note ... there is NO neighbor statement cofnigured
Rack1R3#sh run int s1/2
Building configuration...
Current configuration : 272 bytes
!
interface Serial1/2
ip address 163.1.13.3 255.255.255.0
encapsulation ppp
ip ospf network non-broadcast
ip ospf priority 0
no peer neighbor-route
serial restart-delay 0
clock rate 64000
ppp authentication pap
ppp pap sent-username Rack1R3 password 0 CISCO
end
Rack1R3#sh ip ospf int s1/2 | inc NON
Process ID 1, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 64
Rack1R3#
Interface is NON-BROADCAST
Rack1R3#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.5.5 0 FULL/ - 00:00:39 163.1.35.5 Serial1/0
150.1.1.1 255 FULL/DR 00:01:49 163.1.13.1 Serial1/2
Rack1R3#debug ip ospf hello
Rack1R3#
*Mar 2 05:22:16.763: OSPF: Send hello to 224.0.0.5 area 1 on Serial1/0 from 163.1.35.3
*Mar 2 05:22:17.003: OSPF: Send hello to 163.1.13.1 area 1 on Serial1/2 from 163.1.13.3
*Mar 2 05:22:17.023: OSPF: Rcv hello from 150.1.1.1 area 1 from Serial1/2 163.1.13.1
*Mar 2 05:22:17.023: OSPF: End of hello processing
*Mar 2 05:22:17.611: OSPF: Rcv hello from 150.1.5.5 area 1 from Serial1/0 163.1.35.5
*Mar 2 05:22:17.611: OSPF: End of hello processing
Rack1R3#
I am unicasting hello's to R1 as expected ....
R1
Rack1R1#sh run | sec router ospf
router ospf 1
router-id 150.1.1.1
log-adjacency-changes
area 1 virtual-link 150.1.5.5
redistribute connected metric 1 subnets route-map CONNECTED->OSPF
network 163.1.12.1 0.0.0.0 area 2
network 163.1.13.1 0.0.0.0 area 1
Rack1R1#sh ip ospf int s0/1 | inc NON
Process ID 1, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 64
Rack1R1#sh ip ospf int s0/0 | inc NON
Process ID 1, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 64
Rack1R1#
Rack1R1#
*Mar 2 07:26:39.659: OSPF: Send hello to 163.1.13.3 area 1 on Serial0/1 from 163.1.13.1
*Mar 2 07:26:39.663: OSPF: Rcv hello from 150.1.3.3 area 1 from Serial0/1 163.1.13.3
*Mar 2 07:26:39.663: OSPF: End of hello processing
*Mar 2 07:26:53.655: OSPF: Rcv hello from 150.1.2.2 area 2 from Serial0/0 163.1.12.2
*Mar 2 07:26:53.655: OSPF: End of hello processing
Rack1R1#
*Mar 2 07:27:03.627: OSPF: Send hello to 163.1.12.2 area 2 on Serial0/0 from 163.1.12.1
Rack1R1#u all
I haven't a clue why this is happening, it certainly isn't default behavior :-)
I had a similarly frustrating case with some bridging over FR a few days ago and after a day of hair pulling I just saved all configs, put them in a folder called 'mad cases' and might revisit it at some point. It will probably work straight away then...
All I can say is don't lose sleep over it and get on with other stuff - it is much like in the lab - if you hit something you can't solve within 15 min, make a note and move on, come back to it later. More over in this case you describe it looks very much like a bug.
No matter how much you know there will always be a chance of you failing - it is arrogant to think otherwise. Go easy on yourself and your equipment ;-)
PS
My lab is more or less next week.
Yes i agree with you ... usually i do that and move on .... just hard to let go when you know it is configured right and not working ... :-)
Thanks for advice
Good luck on your lab :-)
Bloody hell mate, that is some piece of information!! :-)
Labbed up and confirmed... OSPF neighbor statement will disappear on reload if the router has ip ospf pri 0 on the interface and neighbors will not come up again if the neighpor statement was configured on the spokes only.
I am really pissed off that no workbook I have done has mentioned this. On the contrary, here is a quote from one of those workbooks, from a VERY respected provider:
"NON-BROADCAST network types can't do multicast traffic either. They will need the "neighbor" command to get things working. This can be configured on both sides if you want but is only necessary on one side. Typically it's done on the hub to keep the configuration simpler, but COULD be either side."
Capitalisation was there, bold is mine...
Having in mind that EVERYONE recommends to use ip ospf prority 0 on all spokes, the above quote is dangerously misleading. If there is the odd mistake in the solution guide or some initial config is not working as it should, I can somewhat live with that. But this could easily cost someone's exam!!!!
P.S.
As much as this is the IEOC, I should say the qoute is not from any of their workbooks.
If I get to use this in my lab exam I will have to find you and buy you a beer Starvoise :-)
..this reads to me that as long as the neighbour statements are on the 'hub' which should 'not' have a priority of zero, then everything is ok and the neighbour statements will remain after reboot. Given that you only need the neighbour statement on one end, this should be ok... ?
PLease correct me if i've misunderstood the concepts.
cheers
Andy
Exactly.
One rule I created for myself is that I will never again configure neighbor statements under the spoke router in a non-broadcast ospf network.
As you need to assign a priority of 0 to the spoke routers, any neighbor statements will not remain after a reboot. Untill a reboot is done they can potentially mask a problem with the configuration of the hub router. At best a problem like that will need debugging at a later stage when you are not sure what to look for, at worst it will break your connectivity and fail your exam.
I don't have physical 3825 and 3725 routers to test this on so there is a possibility that this is not universally valid across platforms and IOS versions, but you gain nothing by configuring it and can lose everything, so the math is easy.
Sorry for coming in late to this one, but I noticed all the caps.
That would be expected behavior. If you aren't going to be DR/DBR
anyway, and aren't going to fully participate in the network election
then what's the point of initiating communication?
Made sense to someone anyway.
Scott Morris, CCIEx4
(R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI #21903, JNCI-M, JNCI-ER
[email protected]
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
nikola wrote:
It makes sense for this part ... any comments on this:
Rack1R1(config-router)#neigh 163.1.12.2
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
R1 is the DR but it doesnt let me configure neighbor statement ... from debug i do see unicast hello's but no neighbor configured ... another thing i noticed, if i configure neighbor on spokes, even though it doesnt show up in the config, neighbor comes up eventually (5 min or longer) and i see unicast hello's .. again there is no neighbor to WHO is my perr should be .. how does the router know's who to unicast it too?
Now if you're seeing that message IN your configuration, then I'd
reload and try again. make sure "show ip ospf interface" show
non-broadcast or P2MP-non-broadcast as your network type.
On reload, it tends to be something just looked at.
You can remove the priority, add your neighbor and put your priority
back on!
Or if you're required to do it otherwise, you can simply make other
arrangements to priority (e.g. increase the hub's).
Scott Morris, CCIEx4
(R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI #21903, JNCI-M, JNCI-ER
[email protected]
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
nydimka23 wrote:
It is not expected behavior to me... I actually find it very counterintuitive that a router accepts a command and acts on it only to drop it after a reload.
I am thinking this could be a reason why some people have had the feeling the proctor is messing with their lab... they had a neighbor, and then the neighbor is gone and the command is missing... no kron/eem to be seen, got to be the proctor...
Why CISCO has implemented it in this way I don't know, just like I don't know why this isn't present in bold capitals in every workbook as an explicit warning.
Did reload multiple times ... but lets see it again ... i will replicate the issue ..... Sorry for a big post but i try to get all details.
R1 information ..................
Rack1R1#sh run | sec router ospf
router ospf 1
router-id 150.1.1.1
log-adjacency-changes
area 1 virtual-link 150.1.5.5
redistribute connected metric 1 subnets route-map CONNECTED->OSPF
redistribute rip metric 1 subnets route-map RIP->OSPF
network 163.1.12.1 0.0.0.0 area 2
network 163.1.13.1 0.0.0.0 area 1
Rack1R1#
NOTE >>> NO NEIGHBOR STATEMENTS .... THIS IS THE HUB ROUTER
interface Serial0/0
ip address 163.1.12.1 255.255.255.0
encapsulation frame-relay
ip ospf priority 255
serial restart-delay 0
frame-relay map ip 163.1.12.2 102 broadcast
no frame-relay inverse-arp
end
NOTE >>>> NON-BROADCAST IS NOT MANUALY CONFIGURED (interface already non-broadcast see below)
Rack1R1#sh run int s0/1
Building configuration...
Current configuration : 256 bytes
!
interface Serial0/1
ip address 163.1.13.1 255.255.255.0
encapsulation ppp
ip ospf network non-broadcast
ip ospf priority 255
no peer neighbor-route
serial restart-delay 0
ppp authentication pap
ppp pap sent-username Rack1R1 password 0 CISCO
end
TRIED CONFIGURING ONE INTERFACE TO NON-BROADCAST TO SEE IF IT WILL MAKE A DIFFERENCE
Rack1R1#sh ip ospf int s0/0 | inc NON
Process ID 1, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 64
Rack1R1#sh ip ospf int s0/1 | inc NON
Process ID 1, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 64
Rack1R1#
NOTE >>>> INTERFACE NON-BROADCAST TYPE
Rack1R1#sh ip ospf neigh
Rack1R1#
NO NEIGHBOR RELATIONSHIP HERE
Rack1R1#debug ip ospf hello
OSPF hello events debugging is on
Rack1R1#
NOTHING OUTPUTS
Rack1R1#
Rack1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R1(config)#router ospf 1
Rack1R1(config-router)#neigh
Rack1R1(config-router)#neighbor 163.1.12.2
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
Rack1R1(config-router)#neighbor 163.1.13.3
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
Rack1R1(config-router)#
TRYING TO CONFIGURE NEIGHBOR COMMAND ON THE HUB ROUTER AND GETTING ERROR .... FOR THIS TASK I AM REQUIRED TO CONFGIURE r1 AS THE DR.
Rack1R2
Rack1R2#sh run | sec router ospf
router ospf 1
router-id 150.1.2.2
log-adjacency-changes
redistribute connected metric 1 subnets route-map CONNECTED->OSPF
redistribute rip metric 1 subnets route-map RIP->OSPF
network 163.1.12.2 0.0.0.0 area 2
Rack1R2#
interface Serial0/0
ip address 163.1.12.2 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
ip ospf priority 0
frame-relay map ip 163.1.12.1 201 broadcast
no frame-relay inverse-arp
Rack1R2#sh ip ospf int s0/0 | inc NON
Process ID 1, Router ID 150.1.2.2, Network Type NON_BROADCAST, Cost: 64
Rack1R2(config-router)#do sh ip ospf neigh
Rack1R2(config-router)#
R3 - testing
*Mar 2 07:06:25.871: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/1 from 163.1.13.1
Rack1R1(config-if)#ip ospf ne
Rack1R1(config-if)#ip ospf network non
Rack1R1(config-if)#ip ospf network non-broadcast
Rack1R1(config-if)#end
Rack1R1#
*Mar 2 07:06:30.931: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.3.3 on Serial0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 2 07:06:31.687: %SYS-5-CONFIG_I: Configured from console by console
Rack1R1#
Rack1R1#
*Mar 2 07:06:34.399: OSPF: Rcv hello from 150.1.2.2 area 2 from Serial0/0 163.1.12.2
*Mar 2 07:06:34.399: OSPF: End of hello processing
Rack1R1#
Rack1R1#
*Mar 2 07:06:35.735: OSPF: Send hello to 163.1.12.2 area 2 on Serial0/0 from 163.1.12.1
Rack1R1#
HERE IS WHAT COMFUSES ME .... WHAT I DID HERE IS CHANGED PRIORITY ON R3 INTERFACE TO 1 AND YES NEIGHBOR CAME UP FINE ... THEN I CHANGED PRIORITY BACK TO 0 AND CONFIGURED TYPE NON-BROADCAST AGAIN ..... SO ... IF THERE IS PRIORITY OF 0 COFNIGURED ON SPOKE ROUTER, THEN WHY SHOULD WE INITIATE THE SESSION RIGHT? THEN WHY DO WE SEE HELLO COMING FROM R3 TO RIGHT AFTER THE SESSION HAS BEEN TAKEN DOWN?
i WOULD EXPECT R1 TO SEND INITIAL HELLO AND R3 TO RESPOND ..., BUT R1 CAN'T SEND HELLO SINCE THERE IS NO NEIGHBOR STATEMENT CONFIGURED
*Mar 2 07:06:39.667: OSPF: Rcv hello from 150.1.3.3 area 1 from Serial0/1 163.1.13.3
*Mar 2 07:06:39.667: OSPF: Send immediate hello to nbr 150.1.3.3, src address 163.1.13.3, on Serial0/1
*Mar 2 07:06:39.667: OSPF: Send hello to 163.1.13.3 area 1 on Serial0/1 from 163.1.13.1
*Mar 2 07:06:39.671: OSPF: End of hello processing
*Mar 2 07:06:39.679: OSPF: Rcv hello from 150.1.3.3 area 1 from Serial0/1 163.1.13.3
*Mar 2 07:06:39.679: OSPF: End of hello processing
Rack1R1#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.3.3 0 2WAY/DROTHER 00:01:40 163.1.13.3 Serial0/1
150.1.2.2 0 FULL/DROTHER 00:01:34 163.1.12.2 Serial0/0
Rack1R1#
I agree with you .. its really frustrating to see command been accepted and not doing anything ... and i bet it did cost people their lab since this is the core section ... after reload OSPF doesnt work ....
Well... While I can't fix the first part... I can certainly try to
fix the second!
I'll try to make sure we put the note someplace in the workbook!
Scott Morris, CCIEx4
(R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI #21903, JNCI-M, JNCI-ER
[email protected]
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
nikola wrote:
Talking about unexpected behavior .... check this out .... again sorry for the long out put but follow the steps i took and see what happens
VERIFYING CONFIG ON R2 ....... S0/0 PRIORITY REMOVED AND IT IS DEFAULT "1"
Rack1R2(config)#do sh run int s0/0
Building configuration...
Current configuration : 195 bytes
!
interface Serial0/0
ip address 163.1.12.2 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
frame-relay map ip 163.1.12.1 201 broadcast
no frame-relay inverse-arp
end
ADDING NEIGHBOR COMMAND ON SPOKE
Rack1R2(config)#router ospf 1
Rack1R2(config-router)#neighbor 163.1.12.1
*Mar 2 07:29:57.579: OSPF: Starting 0.0.0.0 address 163.1.12.1 on Serial0/0
Rack1R2(config-router)#do sh run | sec router ospf
router ospf 1
router-id 150.1.2.2
log-adjacency-changes
redistribute connected metric 1 subnets route-map CONNECTED->OSPF
redistribute rip metric 1 subnets route-map RIP->OSPF
network 163.1.12.2 0.0.0.0 area 2
neighbor 163.1.12.1
Rack1R2(config-router)#
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 255 EXSTART/BDR 00:01:52 163.1.12.1 Serial0/0
Rack1R2#
NOTE THAT EVEN THOUGH MY PRIORITY IS 1 ... I AM TRYING TO BE THE DR FOR THAT SEGMENT .... SHOULDNT R1 BE THE DR WITH PRIORITY OF 255
CHECKING R1 FOR CONFIG.
Rack1R1(config-router)#do sh run int s0/0
Building configuration...
Current configuration : 241 bytes
!
interface Serial0/0
ip address 163.1.12.1 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
ip ospf priority 255
serial restart-delay 0
frame-relay map ip 163.1.12.2 102 broadcast
no frame-relay inverse-arp
end
Rack1R1(config-router)#do sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 1 2WAY/DROTHER 00:01:58 163.1.12.2 Serial0/0
Rack1R1(config-router)#
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 255 EXSTART/BDR 00:01:49 163.1.12.1 Serial0/0
Rack1R2#
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 255 FULL/BDR 00:01:58 163.1.12.1 Serial0/0
Rack1R2#
Rack1R1#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 1 FULL/DR 00:01:32 163.1.12.2 Serial0/0
Rack1R1#
PEERING ESTABLISHED AND R2 IS THE DR ... I WOULD EXPECT R1 TO BE ON WITH PRIORITY OF 255 ... NOW THE CONFIG IS CORRECT (AS FAR AS I SEE) BUT THE RESULT IS NOT ... TO ME THIS IS FAILED TASK IF ON REBOOT I CAN'T BE SURE WHICH ROUTER IS THE DR (HENCE WHY I FEEL MORE COMFORTABLE TO SET PRIORITY TO "0")
NOW ... LETS TO A QUICK TEST AGAIN AND SHUT AND NO SHUT INTERFACE ON R2
Rack1R2(config)#int s0/0
Rack1R2(config-if)#shu
Rack1R2(config-if)#no shut
*Mar 2 07:33:20.835: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.1.1 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Rack1R2(config-if)#no shut
Rack1R2(config-if)#en
*Mar 2 07:33:22.835: %LINK-5-CHANGED: Interface Serial0/0, changed state to administratively down
Rack1R2(config-if)#end
Rack1R2#
*Mar 2 07:33:24.919: %SYS-5-CONFIG_I: Configured from console by console
Rack1R2#
*Mar 2 07:33:25.223: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
Rack1R2#
Rack1R2#
Rack1R2#
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
N/A 0 ATTEMPT/DROTHER 00:01:52 163.1.12.1 Serial0/0
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
N/A 0 ATTEMPT/DROTHER 00:01:45 163.1.12.1 Serial0/0
Rack1R2#sh run int s0/0
Building configuration...
Current configuration : 195 bytes
!
interface Serial0/0
ip address 163.1.12.2 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
frame-relay map ip 163.1.12.1 201 broadcast
no frame-relay inverse-arp
end
Rack1R2#
Access_Router#1
[Resuming connection 1 to r1 ... ]
Rack1R1#
Rack1R1#
Rack1R1#sh run int s0/0
Building configuration...
Current configuration : 241 bytes
!
interface Serial0/0
ip address 163.1.12.1 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
ip ospf priority 255
serial restart-delay 0
frame-relay map ip 163.1.12.2 102 broadcast
no frame-relay inverse-arp
end
Rack1R1#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 1 FULL/DR 00:01:11 163.1.12.2 Serial0/0
Rack1R1#
Access_Router#2
[Resuming connection 2 to r2 ... ]
Rack1R2#sh run int s0/0
Building configuration...
Current configuration : 195 bytes
!
interface Serial0/0
ip address 163.1.12.2 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
frame-relay map ip 163.1.12.1 201 broadcast
no frame-relay inverse-arp
end
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 255 EXSTART/DR 00:01:56 163.1.12.1 Serial0/0
Rack1R2#
*Mar 2 07:34:05.655: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.1.1 on Serial0/0 from LOADING to FULL, Loading Done
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 255 FULL/DR 00:01:56 163.1.12.1 Serial0/0
Rack1R2#
Access_Router#1
[Resuming connection 1 to r1 ... ]
*Mar 2 07:33:01.
Rack1R1#
Rack1R1#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 1 FULL/DR 00:01:49 163.1.12.2 Serial0/0
Rack1R1#
FINAL RESULT ... R1 AND R2 HAVE PEERING ESTABLISHED AND THEY BOTH DR'S FOR THE SAME SEGMENT? (RIGHT ABOUT NOW I AM SCRATCHIGN MY HEAD) ... SOME TIME LATER THEY RESOLVE THEIR DIFFERENCES (ONLY 1 DR PER SEGMENT) AND R1 BECOMES THE DR .. NOW THIS IS WHAT I WOULD EXPECT TO SEE ...
Rack1R1#
Rack1R1#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 1 FULL/BDR 00:01:54 163.1.12.2 Serial0/0
Rack1R1#
Access_Router#2
[Resuming connection 2 to r2 ... ]
Rack1R2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 255 FULL/DR 00:01:48 163.1.12.1 Serial0/0
Rack1R2#
Forgive me if I hadn't read the whole output very carefully, but it is not clear to me if you had reloaded/cleared ospf processes on both devices after the priory change. Also it would be great to see what IOS version is loaded on those routers if not too much trouble.
Cheers,
Stan
Honestly I do recall either Scott or Brian mentioning it in one their recpective Live CD's, however I am way past the point of having those voices intermingled in my head by nowand I am not even sure if I had actually heard it or just me getting old/crazy..:)
Judging by your first sentence you sound Aussie and I do have a great respect for the beer down under, so yeah look me up if you get it on the lab (although sure hope you don't)!
Cheers mate!
Stan
All routers run the same code ...
Rack1R1#sh ver | inc IOS
Cisco IOS Software, 3600 Software (C3640-JK9O3S-M), Version 12.4(10a), RELEASE SOFTWARE (fc2)
Rack1R1#
neighbor was in DOWN state ... no hello's going out until neighbor command is configured. So, i configured neighbor statement on R2 and then they formed adjacency ... that's when i noticed that R2 was the DR ... later on when i came back to my configs, R1 was the DR (may be 5 minutes later) ..
Just replicated that again and with spokes configured priority of "1" and hub "255", neighbor statements on spokes, it works fine ...
For looking at your own configuration/perspective of the world, check
out:
"do sh ip o i | in is up|Type|State"
Scott Morris, CCIEx4
(R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI #21903, JNCI-M, JNCI-ER
[email protected]
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
nydimka23 wrote:
The second example is a "normal" behaviour of OSPF. The priority is used only if both hub and spoke start-up at the same time. In other case DR will be the first router. That's why we use priority 0
.
But problem with priority 0 and neighbor sounds no good. I can't believe Cisco made non-broadcast implementation in such way. What a mess. Have you checked other IOS versions?
Yes .. it's a mess ... Need to be real carefull with it .. If you have interface configured with priority 1 and neighbor under OSPF, then lets say you decide to change to priority 0 ... it will remove neighbor automaticaly ...
I did not check any other releases of the code .. What throws me off, is that i can't put neighbor command on the hub where i would normaly configure it.
good and short output :-) i know my posts are too long to read .. sorry ....
Actully I verified it last night on both my racks and it still appears to be the behaviour in IOS Version 12.4(25).
There is no sense to use nonbroadcast without priority 0. You will make reload and get lotto location of OSPF DR. Such task will kill me on the lab exam
.
Too bad. I had a hope It's just a bug
.
I think I remember reading something about a bug which involved virtual links and the neighbor statement. Try removing the VL on the hub?
nydimka... i can't see the scenario you are trying to get working in Lab 7 Version 5. Out of interest, I was just going to take a look at the question a little further.
andychis .... it is related to task 2.7 OSPF (Lab 7 version 5).
hmm... i didn't have any problems with this section. the only notes i made were to make sure i configured priority 0 on R3 & R2... which doesn't help you much.
I'd be inclined to try your configs on a different IOS if you get the time.
This was it ... virtual-link is what was causing the issue on the hub router and was preventing me from putting neighbor commands there ....
Rack1R1(config-router)#area 1 virtual-link 150.1.5.5
Rack1R1(config-router)#neigh 163.1.12.2
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
Rack1R1(config-router)#no area 1 virtual-link 150.1.5.5
Rack1R1(config-router)#neigh 163.1.12.2
Rack1R1(config-router)#
I added virtual-link to connect area 2 and area 0 (should have used GRE tunnel which i was thinking about in the first place). Once i remove VL then everything works fine with priority "0" on the spokes and neighbor commands on the hub.
Dont remmber seen this in OSPF workbook but i think it's worth mentioning even though this is a bug .. could be frustrating to try to pick a solution ... GRE tunnel would be the way to go ...
Thanks all for putting your time and effort into helping me resolve this :-)
Dmitriy
Here is a link to a thread with a reference to the bug in quesion and explanation by Scott M.:
http://ieoc.com/forums/p/6363/23396.aspx