From: kevin gannon (kevin@gannons.net)
Date: Mon Oct 17 2005 - 14:53:09 GMT-3
If you are getting unicast through then the cable is fine.
I take it a good ping works fine and is arriving at the
router you expect as seen in a debug?
The config snippets look fine.
Regards
Kevin
On 10/17/05, Danny Cox <dandermanuk@gmail.com> wrote:
> I've been working on the InternetworkExpert lab - just the first lab,
> the sample lab, in their workbook. The fact that it's that lab is
> by-the-by, but I mention it if it's interesting to anyone. There's a
> requirement to build a frame network between three routers - the hub
> is R2 and the spokes are R1 and R3. The instruction is to use the
> physical network interfaces so there's all the good split-horizon
> stuff there, but that's not what I'm confused by.
>
> The addresses are from the range 183.3.123.0/24 - .1 on R1, .2 on R2, .3 on R3
>
> The equipment I have so far won't bring up the eigrp neighbour
> relationships between the spokes and the hub although the frame works
> fine and hub can ping the spokes etc. I'm completely puzzled by this
> and the various troubleshooting guides talk about checking unicast
> pingability and routing tables which all look correct. Checking the
> debug eigrp packet and debug eigrp events gives output like:
>
> *Mar 1 05:41:34.002: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.3.123.3 (
> Serial0/0) is down: retry limit exceeded
> *Mar 1 05:41:34.002: destroy peer: 183.3.123.3
> *Mar 1 05:42:17.710: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.3.123.3 (
> Serial0/0) is up: new adjacency
>
>
>
> This is on the hub - the neighbour 18.3.123.3 is the spoke. Looking
> on the spoke ends, they both show messages about
>
> *Mar 1 15:54:48.584: EIGRP: Received UPDATE on Serial1/1 nbr 183.3.123.2
> *Mar 1 15:54:48.584: AS 100, Flags 0x9, Seq 519/0 idbQ 0/0
> *Mar 1 15:54:48.584: EIGRP: Neighbor(183.3.123.2) not yet found
>
> Output of "show ip eigrp neighb" on R2 shows a neighbour relationship:
>
> R2#sh ip eigrp n
> IP-EIGRP neighbors for process 100
> H Address Interface Hold Uptime SRTT RTO Q Seq Typ
> e
> (sec) (ms) Cnt Num
> 2 183.3.123.3 Se0/0 135 00:01:35 1 5000 1 0
> 1 183.3.123.1 Se0/0 161 00:02:06 1 5000 1 0
>
> There's nothing much to the config really - on the hub:
>
> R2#sho run int s0/0
> Building configuration...
>
> Current configuration : 243 bytes
> !
> interface Serial0/0
> ip address 183.3.123.2 255.255.255.0
> encapsulation frame-relay
> no ip split-horizon eigrp 100
> no arp frame-relay
> frame-relay map ip 183.3.123.1 201 broadcast
> frame-relay map ip 183.3.123.3 203 broadcast
> no frame-relay inverse-arp
> end
>
> On the stubs - R3 is, for example:
>
> interface Serial1/1
> ip address 183.3.123.3 255.255.255.0
> encapsulation frame-relay
> serial restart_delay 0
> no arp frame-relay
> frame-relay map ip 183.3.123.2 302 broadcast
> no frame-relay inverse-arp
> end
>
> R1 is similar:
>
> interface Serial0/0
> ip address 183.3.123.1 255.255.255.0
> encapsulation frame-relay
> no arp frame-relay
> frame-relay map ip 183.3.123.2 102 broadcast
> no frame-relay inverse-arp
> end
>
> R3#sho ip eigrp n
> IP-EIGRP neighbors for process 100
> H Address Interface Hold Uptime SRTT RTO Q Seq Typ
> e
> (sec) (ms) Cnt Num
> 0 183.3.123.1 Se1/1 150 00:02:17 1 5000 1 0
> 1 183.3.123.2 Se1/1 139 00:04:20 306 1836 0 526
>
> Finally doing a 'debug eigrp packet' on R3 shows:
>
> *Mar 1 16:11:44.167: EIGRP: Sending UPDATE on Serial1/1 nbr 183.3.123.1, retry
> 6, RTO 5000
> *Mar 1 16:11:44.167: AS 100, Flags 0x9, Seq 266/0 idbQ 0/0 iidbQ un/rely 0/0
> peerQ un/rely 0/1 serno 1-17
> *Mar 1 16:11:44.407: EIGRP: Sending HELLO on Serial1/1
> *Mar 1 16:11:44.407: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0u a
> ll
>
> The number after 'retry' in the first line increments until the
> neighbour relationship is torn down.
>
> So, from this I conclude that some packets (hellos) are getting
> through, but update packets aren't, and after that I conclude I'm
> confused.
>
> This should be a very simple exercise and I'm wondering whether it's
> pointing to something like a damaged pin in the cable between R2 and
> the frame-relay switch.
>
> Anyone got any insights?
>
> cheers
> Danny
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3