From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Thu Jun 16 2005 - 04:40:42 GMT-3
Hi Tim,
I think the last question you raised that has not got an answer is the
one regarding the spokes becoming neighbors. There are two alternatives
I can think of depending on how a question is worded.
If the spokes are not neighbors and you have disabled split horizon on
the hub, routes learned from spoke to spoke will show the route as
learned from the address of the hub. The following is an example of that
R1=10.1.1.1 R2=10.1.1.2 and R3 =10.1.1.3 for the frame interfaces, R2 is
the hub. If you create a loopback 10.1.11.1/24 on R1, R3 will show a
routing table entry like this
D 10.1.11.0 [90/2809856] via 10.1.1.2, 00:00:03, Serial2/0
A question could be worded whereby a route from a spoke has to show up
in the routing table as learned via that spoke. In that case you'd want
to configure neighbor statements between the spokes (and from the hub to
each spoke) to enable the spokes to become neighbors and routes learned
frrom spoke to spoke will show as learned via the spoke address, not the
hub address, as follows:
D 10.1.11.0 [90/2809856] via 10.1.1.1, 00:00:03, Serial2/0
In real world applications, I think p2p interfaces generally get
deployed and none of this matters, so it is really just for the CCIE lab
and how the question is worded.
Chris
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
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