From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed Jun 15 2005 - 13:52:41 GMT-3
Paste your "show frame-relay map" output. Most likely this is a
problem in your layer 2 topology that should have been addressed before
configuring layer 3 protocols.
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
> ccie2be
> Sent: Wednesday, June 15, 2005 11:40 AM
> To: 'Chris Lewis (chrlewis)'; 'Group Study'
> Subject: RE: f/r & ei
>
> Hey Chris,
>
> Thanks for getting back to me on this.
>
> I turned on debug ip packet on R1, R2 and R3.
>
> And, it looks like you're right - at least partially.
>
> I say partially because even though the eigrp mcast packets from the
> spokes
> look like they're not being forwarded by the hub, R3 stills sometimes
sees
> R1 as a neighbor. That doesn't make sense to me.
>
> In the debugs on R1 and R3, I don't see eigrp packets coming in from
the
> other spoke.
>
> But, what I don't understand is this: If the eigrp aren't coming in
from
> the other spoke, why would one spoke EVER show the spoke as a
neighbor.
>
> And, more fundamentally, are the eigrp spokes suppose to become eigrp
> neighbors?
>
> I can't see reason the spokes need to be neighbors if the hub has
> split-horizon disabled.
>
> Any thoughts?
>
> TIA, Tim
>
>
> -----Original Message-----
> From: Chris Lewis (chrlewis) [mailto:chrlewis@cisco.com]
> Sent: Wednesday, June 15, 2005 12:15 PM
> To: ccie2be; Group Study
> Subject: RE: f/r & ei
>
> Looks like multicast packets are not being sent by R3 to R1 probably
due
> to the broadcast keyword missing on the frame-relay map statement. If
> this is the case, doing a debug ip packet should show that the EIGRP
> hellos to 224.0.0.10 are unroutable.
>
> Chris
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Wednesday, June 15, 2005 10:40 AM
> To: Group Study
> Subject: f/r & ei
>
> Hi guys,
>
> This is interesting but confusing.
>
> R1, R2, and R3 are running eigrp over a hub and spoke f/r cloud with
R2
> as the hub.
>
>
> R1 doesn't ever see R3, the other spoke as an eigrp neighbor, but R3
> sometimes sees R1 as a neighbor.
>
> On R1, the neighbor state with R3 flaps up and down.
>
> On R2, the hub, ip split-horizon has been disabled.
>
> R3#sh ip ei n
> IP-EIGRP neighbors for process 100
> H Address Interface Hold Uptime SRTT RTO
Q
> Seq
> Typ
> e
> (sec) (ms)
Cnt
> Num
> 0 183.1.123.1 Se0/1 172 00:02:03 1 5000
1
> 0
> 1 183.1.123.2 Se0/1 136 00:40:21 36 216
0
> 10
> R3#uu
> BL-Rack3>1
>
>
> Notice the uptime for R1 (1831.1.123.1) is very small relative to R2.
>
> Moments later.
>
> R3#sh ip ei n
> IP-EIGRP neighbors for process 100
> H Address Interface Hold Uptime SRTT RTO
Q
> Seq
> Typ
> e
> (sec) (ms)
Cnt
> Num
> 1 183.1.123.2 Se0/1 165 00:45:33 36 216
0
> 10
>
> And, I get these messages on R3:
>
> R3#
> *Mar 1 04:04:45.633: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
> 183.1.123.1 (
> Serial0/1) is up: new adjacency
>
> R3#
> *Mar 1 04:07:50.156: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
> 183.1.123.1 (
> Serial0/1) is down: retry limit exceeded R3# *Mar 1 04:07:50.156:
> destroy peer: 183.1.123.1
>
>
> R1(config-router)#do sh ip ei n
> IP-EIGRP neighbors for process 100
> H Address Interface Hold Uptime SRTT RTO
Q
> Seq
> Typ
> e
> (sec) (ms)
Cnt
> Num
> 1 183.1.123.2 Se0/0 177 00:40:37 68 408
0
> 10
> 0 183.1.17.7 Et0/0 14 00:49:41 145 870
0
> 19
> R1(config-router)#
>
>
> Anyone know what's going on? And, know what should be done about
this?
>
> TIA, Tim
>
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3