From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Aug 04 2004 - 11:30:14 GMT-3
Tom,
You're comprehensive response is fantastic. With your help, I'm sure I'll
get to the bottom of this problem. I'm just hoping this doesn't turn out to
be some very stupid mistake or oversight on my part that will embarass me
for life.
On the bright side, I'm certainly getting practice and insight into an area
of networking and troubleshooting I've haven't wondered into previously.
So, for that alone I greatly appreciate all your assistence. And, I suspect
many others on GS, if they're following this thread, are also learning a
great deal as well.
As I said, I'll get access to the rack today at noon. I'll look at these
things and report back to you my findings.
Thanks so much, Tim
----- Original Message -----
From: "Tom Martin" <tig@wiltecinc.com>
To: "ccie2be" <ccie2be@nyc.rr.com>
Sent: Wednesday, August 04, 2004 10:18 AM
Subject: RE: IRB question from IE lab 3 task 1.9
Tim,
1. I've configured this a number of times, and short of a very strange
hardware problem that hasn't generated any console messages I think it's
probably a configuration error.
2. I have not seen any problems with the config that I've seen so far.
3. When you ping R3 from R1, you can expect to see a translation in the ARP
table. If the R3 router isn't getting R1s ARP requests (or R1 isn't gettings
its replies) you will end up with an 'Incomplete' for the MAC address. The
output from 'debug arp' on both routers would be helpful.
If for some reason ARPs are not making it through the bridge, next would be
to configure a static ARP entry for the remote router so that all traffic is
unicast. Unicast traffic is easier to troubleshoot as you can examine the
CAM and determine which ports (if any) will be used to reach the
destination.
4. You're dealing with a layer-2 issue, troubleshooting there makes sense.
Pings from R1 to R3 should result with the following packet exchange:
R1: ARP request for R3s IP (from R1 MAC, to broadcast)
R3: ARP reply (from R3 MAC to R1 MAC)
R1: ICMP echo request (from R1 IP/MAC to R3 IP/MAC)
R3: ICMP echo reply (from R3 IP/MAC to R1 IP/MAC)
If you're not getting a ping reply, at least one of the above isn't
happening. For example:
1st packet: If R1 doesn't believe R3 is on the same subnet as itself it
won't ARP for R3, it will ARP for the default gateway (if configured) or
won't ARP at all (if no default gateway is configured) -- subnet mask
problem.
2nd packet: If R3 doesn't believe R1 is on the same subnet as itself, it
won't reply to the ARP. Again, possibly a subnet mask problem. The ARP
request will also get ignored if R3 doesn't like the interface it is
received on (a better interface is used to get to R1, a host route?)
3rd packet: If R1 doesn't send the ping packet, it might be (mis)configured
for policy-based routing, the ping is set do not fragment and the link
doesn't support the MTU size required to send the packet, etc.
The above doesn't take into consideration access-lists, broadcast
suppression, port security, pruning problems, vlan filtering, etc. The key
is to focus on the 4-packet exchange and figure out which step isn't
completing. Once the "missing packet" is identified it's simply a matter of
checking the handful of possible causes that would affect that step. A
packet capture works best for this, but in a remote lab you should be able
to debug your way through (debug arp and debug ip icmp on both routers).
-- Tom
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Wednesday, August 04, 2004 9:38 AM
To: Tom Martin; Group Study
Subject: Re: IRB question from IE lab 3 task 1.9
Hey Tom,
Thanks again for staying with me on this.
OK, I'll check later today when I'm back on the rack around noon.
But, until I'm able to get back on the routers and switches, I'm wondering
about a couple things:
Note the following:
a) There are no acl's on any interfaces on any of these routers or switches.
b) There's a 802/1q trunk configured between the 2 Cat's with vlan 36 the
native vlan. All vlans are permitted across the trunk and pruing is enabled.
c) I haven't changed any default settings such as proxy-arp on any of the
routers or switches.
1) Could everything be configured correctly and this problem still exist?
Or, must there be some sort of configuration error?
2) Based on the config's you saw, there weren't any obvious configuration
errors, true?
3) What should I be looking to see in the output of the show ip arp? And,
how should I be using that output to troubleshoot this problem?
4) Assuming there aren't any configuration errors, what do I do then?
Thanks, Tim
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:32 GMT-3