From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Jun 15 2005 - 16:29:58 GMT-3
Yep, I think you're right.
Thanks for posting that config.
Tim
-----Original Message-----
From: Wang Dehong-DWANG1 [mailto:Dehong.Wang@motorola.com]
Sent: Wednesday, June 15, 2005 3:27 PM
To: 'ccie2be'; 'Chris Lewis \(chrlewis\)'; 'Group Study'
Subject: RE: f/r & ei
With neighbour statement under eigrp, eigrp adjacency can be established
between spokes. With multicast packet, TTL is set to 1, but with unicast,
TTL is set to 2, I believe.
- Dehong
Rack1R1 ==== HUB
=======
router eigrp 100
network 130.1.124.0 0.0.0.255
network 150.1.0.0
neighbor 130.1.124.2 Serial0/0
neighbor 130.1.124.4 Serial0/0
distribute-list 100 in Serial0/0
no auto-summary
Rack1R1(config-router)#do sh run int s0/0
Building configuration...
Current configuration : 243 bytes
!
interface Serial0/0
ip address 130.1.124.1 255.255.255.0
encapsulation frame-relay
no ip split-horizon eigrp 100
frame-relay map ip 130.1.124.2 102 broadcast
frame-relay map ip 130.1.124.4 104 broadcast
no frame-relay inverse-arp
end
Rack1R1(config-router)#do sh fram map
Serial0/0 (up): ip 130.1.124.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
Serial0/0 (up): ip 130.1.124.4 dlci 104(0x68,0x1880), static,
broadcast,
CISCO, status defined, active
Rack1R1(config-router)#do sh ip ei nei
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
Type
(sec) (ms) Cnt Num
1 130.1.124.2 Se0/0 14 00:05:38 40 240 0 42
S
0 130.1.124.4 Se0/0 10 00:05:41 401 2406 0 41
S
Rack1R2
====== spoke =====
router eigrp 100
network 130.1.124.0 0.0.0.255
network 150.1.0.0
neighbor 130.1.124.4 Serial0/0.124
neighbor 130.1.124.1 Serial0/0.124
no auto-summary
Rack1R2#sh run int s0/0.124
Building configuration...
Current configuration : 119 bytes
!
interface Serial0/0.124 point-to-point
ip address 130.1.124.2 255.255.255.0
frame-relay interface-dlci 201
end
Rack1R2#sh fram map
Serial0/0.234 (up): ip 130.1.234.3 dlci 203(0xCB,0x30B0), dynamic,
broadcast,, status defined, active
Serial0/0.124 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
status defined, active
Rack1R2#sh ip ei nei
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
Type
(sec) (ms) Cnt Num
1 130.1.124.1 Se0/0.124 153 00:06:52 40 240 0 32
S
0 130.1.124.4 Se0/0.124 11 00:08:25 52 312 0 41
S
Rack1R4
======= Spoke ==========
router eigrp 100
network 130.1.124.0 0.0.0.255
neighbor 130.1.124.2 Serial0/0.124
neighbor 130.1.124.1 Serial0/0.124
no auto-summary
Rack1R4(config-router)#do sh run int s0/0.124
Building configuration...
Current configuration : 119 bytes
!
interface Serial0/0.124 point-to-point
ip address 130.1.124.4 255.255.255.0
frame-relay interface-dlci 401
end
Rack1R4(config-router)#do sh fram map
Serial0/0.234 (up): ip 130.1.234.3 dlci 403(0x193,0x6430), dynamic,
broadcast,, status defined, active
Serial0/0.124 (up): point-to-point dlci, dlci 401(0x191,0x6410), broadcast
status defined, active
Rack1R4(config-router)#do sh ip ei nei
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
Type
(sec) (ms) Cnt Num
1 130.1.124.1 Se0/0.124 136 00:08:09 581 3486 0 32
S
0 130.1.124.2 Se0/0.124 13 00:09:44 55 330 0 42
S
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Wednesday, June 15, 2005 12:46 PM
To: 'Chris Lewis \(chrlewis\)'; 'Group Study'
Subject: RE: f/r & ei
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