From: Danny Cox (dandermanuk@gmail.com)
Date: Mon Oct 17 2005 - 14:32:09 GMT-3
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
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3