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:
Compatible network types:
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.
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!
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.
(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:
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
>