From: Guyler, Rik (rguyler@shp-dayton.org)
Date: Wed Jun 15 2005 - 14:06:32 GMT-3
Tim, think about the physical topology: the purpose of hub and spoke is so
that you don't have to require spokes to become neighbors. If the hub is
lost so is all inter-site data so spoke-to-spoke neighboring is not worth
much here. If you expected all spokes to become neighbors to each other as
well as the hub then you would be creating a mesh, which is ugly with this
physical topology in the "real" world.
Of course, if your lab says to do it then all bets are off! ;-)
Rik
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Wednesday, June 15, 2005 12:40 PM
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