From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Aug 13 2004 - 13:44:18 GMT-3
There have been a few scenarios that I've come across where although the
config is 100% correct it still doesn't work.
For those scenarios, you will need to reboot the router.
So, I've made a mental note, "If all else fails, reboot."
The problem with this approach is that in the lab, how often are you 100%
sure your config is perfectly correct when things are not working properly?
If your config is wrong and you reboot, you've just wasted a few minutes and
things will still not work.
Kind of a Hobsons choice.
----- Original Message -----
From: "Tiean" <noktes@bellsouth.net>
To: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>; "ccie2be"
<ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Monday, August 09, 2004 1:14 AM
Subject: Re: IRB question from IE lab 3 task 1.9
> 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
>
> _______________________________________________________________________
> 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:43 GMT-3