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)

«1

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

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    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:

    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?

    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,


  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





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


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

     

    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#

     

     

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

    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.

     

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

     


  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    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:

    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.

     


    imageScott
    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

  • 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

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

     

     

     

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

     

     

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    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:

    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#







    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

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

    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?


  • good and short output :-) i know my posts are too long to read .. sorry ....

  • 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?

    Actully I verified it last night on both my racks and it still appears to be the behaviour in IOS Version 12.4(25).

     

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

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

    Actully I verified it last night on both my racks and it still appears to be the behaviour in IOS Version 12.4(25).

    Too bad. I had a hope It's just a bug :) .

  • What throws me off, is that i can't put neighbor command on the hub where i would normaly configure it.

     

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

    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.


  • 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

     


    What throws me off, is that i can't put neighbor command on the hub where i would normaly configure it.

     

    I think I remember reading something about a bug which involved virtual links and the neighbor statement. Try removing the VL on the hub?


  • 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

Sign In or Register to comment.