From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Wed Aug 04 2004 - 17:00:10 GMT-3
Tim,
I've really been bothered by this and I have given it a lot of
thought... I'm hoping someone will help me understand it a little
better.
I think if you prune vlan 16 off the trunk between SW1 and SW2 then the
pings will fail.
Effectively, the ARP resolution process is successful with or without
V16 being forwarded (pruned) on the trunk between SW1 and SW2. But,
PING would not be successful because R1 addresses R3 directly at Layer2,
so V16 pruned on the trunk will make PING fail.
Here are my thoughts:
Assumption: Same physical topology, Vlan 16 and 36 are forwarding on
trunk between SW1 and SW2. Arp resolution was successful.
When R1 sends first ping echo request to R3, you get SourceMacR1 to
DestMacR3. SW1 gets frame destined to MacR3 and knows to forward it out
the trunk to SW2. It is encapsulated in dot1q frame as V16 by SW1. SW2
receives dot1q frame, deencapsulates frame, see's the destination is
MacR3 and forwards out appropriate port to R3.
When R3 responds with ping Echo reply, its SourceMacR3 to DestMacR1.
SW2 knows that to get to DestMacR1 it must use the trunk to SW1. SW2
encapsulates the frame as V36 across trunk to SW1. SW1 deencapsulates
the frame and see the destination is MacR1 and forwards out appropriate
port towards R1.
So, if V16 is not forwarding on the trunk between SW1 and SW2, then the
echo request never makes it to R3.
I guess this could be tested if you prune V16 between SW1 and SW2, debug
ip packet on R3, and then ping R3 from R1. Expect to not see the echo
request on R3.
....
And if I'm wrong someone please help me understand... That's what I love
about this list. 8)
andy
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Wednesday, August 04, 2004 11:38 AM
To: Group Study; Tom Martin
Subject: Re: IRB question from IE lab 3 task 1.9
Hey Tom,
I just noticed something that was different from yesterday.
Yesterday, my switch config's included vtp pruning from an earlier task.
Today, when I first tried this config, vtp pruning wasn't enabled.
I then enabled vtp pruning and tried again. And, again R1 could ping R3
and vice versa. Is there the slightest chance, in your opinion, that
vtp pruning could have had any hand in causing this problem?
Is it possible sw1 or sw2 pruned one of the vlans (vlan 16 or vlan 36)
prior to my testing with the pings?
Here's the physical topology:
R1 --- vlan 16 --- sw1 --- trunk --- to R6 (for vlans 16 & 36)
--- trunk --- to sw2 --- vlan 36
---
R3
Now, with pruing in effect, vlans which don't have ports assigned to on
both sides of a trunk are supposed to be pruned from trunks, right?
So, because vlan 16 and vlan 36 only have access ports assigned on one
side of the trunk between sw1 and sw2, do ya think it's possible one or
both of these vlans was pruned from the trunk running between sw1 and
sw2?
Common sense dictates that IE wouldn't create a lab with instructions
that won't work, so maybe this is far fetched, but, on the other hand,
pruning was the only thing different today from yesterday?
Strange, wouldn't you say?
Thanks again, 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