From: Wang Dehong-DWANG1 (Dehong.Wang@motorola.com)
Date: Wed Jun 15 2005 - 16:26:31 GMT-3
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