From: Tiean (noktes@bellsouth.net)
Date: Mon Aug 09 2004 - 02:14:01 GMT-3
Hi ,
I got the same thing when I did this task. After I configured all the
command in R6,R3,R1.( Also enabled pruning on sw1 ). R1 couldn't ping to R3
and vice versa.
So I rebooted R1,R3,R6. When it came up then R1 could ping R3 and vice
versa.
Hmm!
Montiean
----- Original Message -----
From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Wednesday, August 04, 2004 4:00 PM
Subject: RE: IRB question from IE lab 3 task 1.9
> 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
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:35 GMT-3