From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Jun 15 2005 - 14:21:32 GMT-3
Chris,
Thanks, you're fantastic. I think you solved the problem with your comments
about f/r.
I had done the sh fram map many times - all looked fine. But, I never did
the show fram pvc command.
Here's the output from both:
R3#sh fram map
Serial0/1 (up): ip 183.1.123.1 dlci 302(0x12E,0x48E0), static,
broadcast,
CISCO, status defined, active
Serial0/1 (up): ip 183.1.123.2 dlci 302(0x12E,0x48E0), static,
broadcast,
CISCO, status defined, active
R3#sh fram pvc
PVC Statistics for interface Serial0/1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 3 0 0 0
Switched 0 0 0 0
Unused 1 0 0 0
DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1
input pkts 77 output pkts 7 in bytes 4838
out bytes 588 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 2 out bcast bytes 68
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 03:59:46, last time pvc status changed 03:59:26
DLCI = 302, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1
input pkts 510 output pkts 1095 in bytes 39428
out bytes 61264 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 273 out bcast bytes 17352
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 03:59:51, last time pvc status changed 03:57:21
And, the config on int s0/1
interface Serial0/1
ip address 183.1.123.3 255.255.255.0
encapsulation frame-relay
clockrate 800000
frame-relay map ip 183.1.123.1 302 broadcast
frame-relay map ip 183.1.123.2 302 broadcast
no frame-relay inverse-arp
**************
It turns out there was something similar on R1:
R1#sh fram map
Serial0/0 (up): ip 183.1.123.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
Serial0/0 (up): ip 183.1.123.3 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
R1#sh fram pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 4 0 0 0
Switched 0 0 0 0
Unused 1 0 0 0
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 1018 output pkts 454 in bytes 58006
out bytes 34854 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 302 out bcast bytes 19238
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 04:03:08, last time pvc status changed 04:00:38
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 9 output pkts 76 in bytes 656
out bytes 4804 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 76 out bcast bytes 4804
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 04:03:19, last time pvc status changed 04:02:49
***********
As you can see, there is a direct pvc going from R1 to R3. So, somehow some
of those little buggers (eigrp hello's) were by passing R2 - at least in one
direction but not the other.
But, leads to a Frame Relay question. As you can see from the show fram map
output, only pvc 102 is listed.
So, how is it possible for pvc 103 to be active and NOT show up in the show
fram map output?
That's pretty screwy, isn't it?
Shouldn't it show up as a dynamically map pvc?
TIA, 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