From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Jun 15 2005 - 17:29:43 GMT-3
Simon,
What you say is 100% true but there's an even easier way to tell which pvc's
are active - just look at the summary table for the interface in question:
R3#sh fram pvc
PVC Statistics for interface Serial0/1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 3 0 0 0
In the first column, Active, it's clear that only one pvc is passing
traffic. The other pvc's are "unused".
So, if the task requires that only the pvc's shown in the diagram be used
and R3 is a spoke, this table proves that the tasks requirements are
fulfilled. Of course, you also need to meet any other reachability
requirements that may exist which can tested with pings.
Now, regarding cdp traffic, I think if you've met the requirement on which
pvc's are active and unused, then you don't need to worry about cdp traffic.
Do you agree?
Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
simon hart
Sent: Wednesday, June 15, 2005 3:52 PM
To: ccie2be; 'Chris Lewis (chrlewis)'; 'Group Study'
Subject: RE: f/r & ei
Tim,
The thing to note here is that if you have a question along the lines of '
only use the pvc's defined, no traffic should travel over any other pvc's'
you want to make damn sure CDP is turned off all the frame interfaces,
otherwise you will have CDP traffic going over all directly connected
PVC's - even without a map statement.
It is easy to determine whether traffic is travelling over these PVC's, do
show frame pvc a couple of times and see if the counters are increasing.
Simon
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: 15 June 2005 20:46
To: 'simon hart'; 'Chris Lewis (chrlewis)'; 'Group Study'
Subject: RE: f/r & ei
Hey Simon,
I wasn't aware of that but I'm glad to know about that now.
Overall, I still think Chris's idea of using the show fram pvc is a little
more efficient.
From my limited playing around with cdp, it seems that sometimes it's
enabled by default on serial interfaces but sometimes not.
Also, off-hand, I don't remember if cdp works over sub-int's - it's one of
those things I used to know but have since forgotten.
Thanks for pointing that out. It's good to have these extra little tools
handy.
Tim
-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Wednesday, June 15, 2005 3:33 PM
To: ccie2be; 'Chris Lewis (chrlewis)'; 'Group Study'
Subject: RE: f/r & ei
Tim,
There is something else you should be aware of in this situation.
If you have CDP enabled it can still be exchanged between the PVC's directly
connected between R1 and R3, even though you have no map statements.
I bet if you did a show cdp neighbor you would have seen R3 from R1 via the
directly connected PVC
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
ccie2be
Sent: 15 June 2005 18:46
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