From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Jun 15 2005 - 14:45:34 GMT-3
Chris,
Thank you, thank you.
Your suggestion about checking the frame pvc's was the ticket !!!
So, I guess the moral of this story is ...
1. Don't trust the output of the show fram map command. It doesn't
verify that there aren't other pvc's doing nasty stuff to your IGP's.
2. Don't trust the effect of clear fram inarp. It doesn't clear out
all the unused pvc's.
3. If your IGP is acting funky, just reboot the damn routers and be
done with it.
Thanks again.
Tim
-----Original Message-----
From: Chris Lewis (chrlewis) [mailto:chrlewis@cisco.com]
Sent: Wednesday, June 15, 2005 12:57 PM
To: ccie2be; Group Study
Subject: RE: f/r & ei
There are a couple of things that could be happening.
Just dealing with the eror message first. The first guess is that as R1
has a map statement to R3 with the broadcast keyword, multicast hellos
are getting from R1 to R3, so that is why the neighbor is being formed.
The neighbor dies as R1 probably does not have broadcast capability to
R3.
Not being able to see the routers myself, I would troubleshoot this
issue as follows:
Check with the show frame-relay pvc command to see if there are any PVCs
that you don't know about connecting R1 and R3, then do a show frame
map. Even though you map have no frame inverse on, you can still have
mappings to 0.0.0.0 for these extra DLCIs that could be causing trouble.
The simplest way to get rid of the maps to 0.0.0.0 is to reload the
router.
Other comments in-line
-----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.
CL: this can only be because there is some path for multicast hellos to
pass between these two routers.
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.
CL: they must be, probably rogue mappings you don't realize are there.
And, more fundamentally, are the eigrp spokes suppose to become eigrp
neighbors?
CL: depends :)
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