From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Mon Oct 17 2005 - 14:40:58 GMT-3
Danny,
What does your "show frame-relay map" output on these devices
show? It looks like an error in Frame Relay Inverse-ARP due to a bad
order of operations in your configuration.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Danny Cox
> Sent: Monday, October 17, 2005 12:32 PM
> To: Cisco certification
> Subject: EIGRP neighbours not coming up on frame-relay
>
> 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