OSPF issue

I ran into an unexpected OSPF issue during the mock lab that totally stumped me and I was hoping someone could shed some light on this.

I was working on the R3-R5 hub and spoke frame relay routers.  Since we had to use only the physical interfaces and could not change the ospf network type, we're stuck using non-broadcast as the ospf network type.  This then requires us to use the neighbor command under ospf to get the adjacencies going.  All of the frame relay interfaces are in area 0.  R4 also has a stub ethernet interface in area 0.  No problems with that setup.

We are later asked to have the point-to-point serial link between R5 (the hub) and R4 (the spoke) added to ospf area 1.  There is a stipulation that the serial link is not to be used unless the frame relay link goes down.  We can't use the backup interface feature to do this.  So my solution was to jack up the cost of the serial link well above the frame relay link to ensure traffic took the frame relay link.  I also setup a virtual link across the area 1 serial link, since we would have disconnected area 0s in that case.  This looked good when I set it up and no routes were using the point-to-point serial link.

This all was working just fine until I rebooted the routers.  After the router reboot, my area 0 adjacencies did not come back up across the frame relay hub and spoke network.  I had my neighbor statements on my hub router, and after some troubleshooting, I saw that they weren't there any more.  So I went to put them back in and got the error that neighbors statements could only be used on NBMA or on other network type that is escaping me at the moment.  So I double check and my serial interfaces still show an ospf type of non-broadcast. So I tried adding the neighbor command to R4 instead and I ran into the same issue there.  I was able to issue the neighbor command on R3 just fine.

Further reboots did not help.  The only thing that allowed me to start using the neighbor command again was to get rid of the virtual link.  But that broke the ability to allow the point to point serial link to be used as a backup to the frame relay link.  I just could not get this to work.  The weird thing is that after I remove the virtual link and get the adjacencies up, I can re-add the virtual link again and all is good until the next reboot.

Can anyone tell me why adding the virtual link broke the ability to use the neighbor statement on the frame relay link upon reboot?  Was I not using the correct solution for the problem?

I ended up just getting rid of the virtual link and taking a few point hit as a result since I would have lost lots more points not having the hub and spoke adjacencies up.

Comments

  • OK, I saw that the solutions guide is already available to me, and I was trying to use the correct solution (use the virtual link and jack up the link cost).  So I guess now it's a question of why wasn't it working.

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





    Cost.   When you changed your auto-cost it boosted the OSPF cost of the
    128k-side of the circuit to 65535.  You can't build a VL over a
    max-cost link.



    Change the bandwidth on the link to reduce that cost and magically your
    VL will come up!






     



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






    jrensink78 wrote:

    I ran into an unexpected OSPF issue during the mock lab that
    totally stumped me and I was hoping someone could shed some light on
    this.

    I was working on the R3-R5 hub and spoke frame relay routers. 
    Since we had to use only the physical interfaces and could not change
    the ospf network type, we're stuck using non-broadcast as the ospf
    network type.  This then requires us to use the neighbor command under
    ospf to get the adjacencies going.  All of the frame relay interfaces
    are in area 0.  R4 also has a stub ethernet interface in area 0.  No
    problems with that setup.

    We are later asked to have the point-to-point serial link between
    R5 (the hub) and R4 (the spoke) added to ospf area 1.  There is a
    stipulation that the serial link is not to be used unless the frame
    relay link goes down.  We can't use the backup interface feature to do
    this.  So my solution was to jack up the cost of the serial link well
    above the frame relay link to ensure traffic took the frame relay
    link.  I also setup a virtual link across the area 1 serial link, since
    we would have disconnected area 0s in that case.  This looked good when
    I set it up and no routes were using the point-to-point serial link.

    This all was working just fine until I rebooted the routers. 
    After the router reboot, my area 0 adjacencies did not come back up
    across the frame relay hub and spoke network.  I had my neighbor
    statements on my hub router, and after some troubleshooting, I saw that
    they weren't there any more.  So I went to put them back in and got the
    error that neighbors statements could only be used on NBMA or on other
    network type that is escaping me at the moment.  So I double check and
    my serial interfaces still show an ospf type of non-broadcast. So I
    tried adding the neighbor command to R4 instead and I ran into the same
    issue there.  I was able to issue the neighbor command on R3 just fine.

    Further reboots did not help.  The only thing that allowed me to
    start using the neighbor command again was to get rid of the virtual
    link.  But that broke the ability to allow the point to point serial
    link to be used as a backup to the frame relay link.  I just could not
    get this to work.  The weird thing is that after I remove the virtual
    link and get the adjacencies up, I can re-add the virtual link again
    and all is good until the next reboot.

    Can anyone tell me why adding the virtual link broke the ability
    to use the neighbor statement on the frame relay link upon reboot?  Was
    I not using the correct solution for the problem?

    I ended up just getting rid of the virtual link and taking a few
    point hit as a result since I would have lost lots more points not
    having the hub and spoke adjacencies up.







    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

  • Hi Scott,

    Thanks for the reply.  But I didn't change the auto-cost.  I just went into the s0/1 interfaces on R4 and R5 and tried doing something like a "ip ospf cost 200".  After my reboots, the area 1 adjacenecy as well as the virtual link across it came up just fine.  The cycle I ran into was that after a reboot with the virtual link configured, my neighbor statements disappeared for the frame relay links and I could not put them back because it kept saying that the interfaces weren't nonbroadcast (even though a show ip ospf interfaces command verifyfied that they were indeed in non-boradcast mode).  Once I took away the virtual link, I could then re-apply the neighbor statements.

    After reapplying my neighbor statements, I could then recreate the virtual link and everything would be just fine until I saved and rebooted.  After the reboot, things broke again.  So it was something to do with the presence of the virtual link itself.  As I watched a few of the reboots, I would even see a few errors when the start config was applying that the neighbor commands were invalid.  So it was actually tossing those commands before any adjacencies even formed.

     

    Cost.   When you changed your auto-cost it boosted the OSPF cost of the
    128k-side of the circuit to 65535.  You can't build a VL over a
    max-cost link.



    Change the bandwidth on the link to reduce that cost and magically your
    VL will come up!

     

     

    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

     


     

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





    Sorry, misunderstood your issue there.  And yes, that's a "feature" in
    the IOS.  With a VL, you are receiving "hellos" from a different
    address/ID than is listed in the network command.  And for whatever
    reason (OSPF Area 0 comes up first?) those are sent out prior to the
    "normal" hellos from the neighbor commands and therefore the router
    believe they don't need them.



    Very strange yes, but replicated behavior.  I wish I had a better
    answer for you than that, but it is a known issue.






     



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






    jrensink78 wrote:

    Hi Scott,

    Thanks for the reply.  But I didn't change the auto-cost.  I just
    went into the s0/1 interfaces on R4 and R5 and tried doing something
    like a "ip ospf cost 200".  After my reboots, the area 1 adjacenecy as
    well as the virtual link across it came up just fine.  The cycle I ran
    into was that after a reboot with the virtual link configured, my
    neighbor statements disappeared for the frame relay links and I could
    not put them back because it kept saying that the interfaces weren't
    nonbroadcast (even though a show ip ospf interfaces command verifyfied
    that they were indeed in non-boradcast mode).  Once I took away the
    virtual link, I could then re-apply the neighbor statements.

    After reapplying my neighbor statements, I could then recreate the
    virtual link and everything would be just fine until I saved and
    rebooted.  After the reboot, things broke again.  So it was something
    to do with the presence of the virtual link itself.  As I watched a few
    of the reboots, I would even see a few errors when the start config was
    applying that the neighbor commands were invalid.  So it was actually
    tossing those commands before any adjacencies even formed.

     


    image Scott
    Morris:

    Cost.   When you changed your auto-cost it boosted the OSPF
    cost of the
    128k-side of the circuit to 65535.  You can't build a VL over a
    max-cost link.



    Change the bandwidth on the link to reduce that cost and magically your
    VL will come up!

     

     

    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

     



     







    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

  • Hi,

    ran into the same situation yesterday. This is acknowledged by CSCse72792, OSPF: neighbor cmd rejected if VL configured (thanks wp).

    It works until you reload your routers, then the neighbor statements are gone from the router ospf process in the running config. The router spits out

    OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks

    after the start, but the mean thing is that you catch this message only if you have buffer logging turned on or watch the router boot. Kinda hard if you reload your entire rack and have activated a reverse telnet session from the TermServ to a different device [:P] Otherwise you scratch your head and wonder why in gods name those statements disappear every time you reload.

    Rack rental runs 12.4(10) iirc - I tested this myself later at home with 12.4(19) where the bug seems to be fixed.

    Ended up with:

    Rack13R5#sh inter description | i Se0/?.*up
    Se0/0 up up *** NOTE: Virtual Link to R4 not configured due to CSCse72792 ***
    Se0/1 up up *** NOTE: Virtual Link to R4 not configured due to CSCse72792 ***

    although I dont think this will give me credit [:D] There already is a Tunnel for v6 connectivity, might be a better workaround to use it for an area0 adjacency. But meh, discovered this at the end of my verification, lost a lot of time narrowing it down and was in a hurry to save my configs and make sure i didnt left any interface shutdown accidentially during testing.

    End of story: reload often, watch evey router come up individually [B]

     

     

  • Nice detective work.  I figured something was up when the solution guide didn't mention having to do anything special to make this work like it is suposed to.  Let's hope that Cisco tests their labs with any new IOS updates that they implement.  Something tells me that they purposefully don't upgrade the IOS in their labs very often for this specific reason.

Sign In or Register to comment.