Volume IV, Lab 1 R4 & R5 OSPF adjacencies to R3 help

Argh!  I've tried this twice, and both times (using GradedLabs), I keep running into a problem with R4 & R5 not fully becoming adjacent with R3 over the frame relay network.  But this adjacency issue isn't one of the problem tickets, nor is it really addressed by the Baseline description (except to say that R3 is configured as point-to-point).  I finally broke down, cheated and looked at R3's config as well as did show runs on both R4 & R5 and I still can't figure out why this is happening.  Has anybody else who did this lab seen the same thing?  If so, what did you do to fix it?

%OSPF-5-ADJCHG: Process 1, Nbr 150.21.3.3 on Serial0/0 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions

Comments

  • OSPF adjacency will require:

    • Identical hello and dead timers
    • The same MTU (should not be a problem with frame-relay) or ip ospf mtu-ignore in the case of dot1q tunneling
    • Compatible network types (DR vs. no DR)

    Compatible network types:

    • broadcast & non-broadcast (adjust timers) - uses DR
    • point-to-multipoint, point-to-point & point-to-multipoint non-broadcast (adjust timers) - does not use DR

    You will also need to enable broadcast/multicast support on the DLCIs unless using a non-broadcast option

    You will need to manually configure neighbors for the non-broadcast options

  • Well, I don't want to give anything away to anybody else who plans on doing this workbook.  But I will say that I've triple-checked the timers (identical), MTU (identical over frame), and network types (point-to-point and identical) and they all match up like they should.

    If anybody else happens to run into this issue while doing the lab, I'd like to know if you got the same thing, or if it's just me.  I appreciate the help.

    OSPF adjacency will require:

    • Identical hello and dead timers
    • The same MTU (should not be a problem with frame-relay) or ip ospf mtu-ignore in the case of dot1q tunneling
    • Compatible network types (DR vs. no DR)

    Compatible network types:

    • broadcast & non-broadcast (adjust timers) - uses DR
    • point-to-multipoint, point-to-point & point-to-multipoint non-broadcast (adjust timers) - does not use DR

    You will also need to enable broadcast/multicast support on the DLCIs unless using a non-broadcast option

    You will need to manually configure neighbors for the non-broadcast options

     

     

  • Well, I figured out what I did wrong.  As it turns out, the initial configs are large enough that when I copy/pasted them in, any pause in the router would cause the paste function to overrun and chunks of the config would not get put in.  I was trying to stay true to the integrity of the practice lab by not peeking at the configs beforehand.  So, just be careful when you're copy/pasting the configs and do chunks at a time, but don't peek! :)

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





    You need to use the Transfer > Send Ascii function of SecureCRT
    instead of just doing copy paste.  This usually prevents buffer
    overflow.  Also go up to Options > Global Options and set the "Line
    send delay" to something like 25ms.





    Brian McGahan, CCIE #8593
    (R&S/SP/Security)

    [email protected]



    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987 x 705

    Outside US: 775-826-4344 x 705

    Online Community: http://www.IEOC.com

    CCIE Blog: http://blog.internetworkexpert.com






    jsnmngwn wrote:

    Well, I figured out what I did wrong.  As it turns out, the
    initial configs are large enough that when I copy/pasted them in, any
    pause in the router would cause the paste function to overrun and
    chunks of the config would not get put in.  I was trying to stay true
    to the integrity of the practice lab by not peeking at the configs
    beforehand.  So, just be careful when you're copy/pasting the configs
    and do chunks at a time, but don't peek! :)







    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

  • Thanks for the tip. Putty doesn't appear to have the same feature, tho. :(

    On Tue, Sep 15, 2009 at 3:11 PM, Brian McGahan
    wrote:
    > You need to use the Transfer > Send Ascii function of SecureCRT instead of
    > just doing copy paste.  This usually prevents buffer overflow.  Also go up
    > to Options > Global Options and set the "Line send delay" to something like
    > 25ms.
    >
    >
    > Brian McGahan, CCIE #8593 (R&S/SP/Security)
    > [email protected]
    >
    > Internetwork Expert, Inc.
    > http://www.InternetworkExpert.com
    > Toll Free: 877-224-8987 x 705
    > Outside US: 775-826-4344 x 705
    > Online Community: http://www.IEOC.com
    > CCIE Blog: http://blog.internetworkexpert.com
    >
    >
    > jsnmngwn wrote:
    >
    > Well, I figured out what I did wrong.  As it turns out, the initial configs
    > are large enough that when I copy/pasted them in, any pause in the router
    > would cause the paste function to overrun and chunks of the config would not
    > get put in.  I was trying to stay true to the integrity of the practice lab
    > by not peeking at the configs beforehand.  So, just be careful when you're
    > copy/pasting the configs and do chunks at a time, but don't peek! :)
    >
    >
    > 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
    >
    >
    >
    > 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
    >
Sign In or Register to comment.