IEOC - Internetwork Expert's Online Community

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)

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

nydimka23:

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)

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 :-)

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)."

It seems that you have R3 interface confiugred as priority 0, try chaning it to anything else.

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.

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 :-)

 

 

Internetwork Expert - The Industry Leader in CCIE Preparation
http://www.internetworkexpert.com

Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx

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?

Scott Morris:

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,

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?

Scott Morris:

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,

Internetwork Expert - The Industry Leader in CCIE Preparation
http://www.internetworkexpert.com

Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx

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.

Scott Morris:

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.  :)

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#

Scott Morris:

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).

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 ....

nikola:

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.

 

Scott Morris:

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.  :)

 

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.

 

Scott Morris:

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.  :)

 

Internetwork Expert - The Industry Leader in CCIE Preparation
http://www.internetworkexpert.com

Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx