From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Aug 18 2004 - 08:05:07 GMT-3
There are some tasks for which one might not know what debugs to run or
exactly how to interpret the output of such debugs. And, in some cases, it
might take longer to correct the problem by going the debug path.
On occasion, even when everything is configured correctly, but in the wrong
order, things don't work as expected. So, in these situations, the fastest
way just might be to reload the router.
----- Original Message -----
From: "Swaroop Potdar" <swarooppotdar@hotmail.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Tiean" <noktes@bellsouth.net>;
"Edwards, Andrew M" <andrew.m.edwards@boeing.com>; <ccielab@groupstudy.com>
Sent: Tuesday, August 10, 2004 4:03 PM
Subject: Re: IRB question from IE lab 3 task 1.9
> Hi,
>
> could we run the specific debugs...to check before reloading....
>
> as if the commands are right...there could be a possibility that the
> specific code is not being executed as wanted into the memory ...so in
that
> case the debug messages would reflect that...
>
> So debugging the code itself would help us to understand to reload the
> router or not...
>
> what say...
>
> Thanks,
> Swaroop.
>
>
>
> ----- Original Message -----
> From: ccie2be <ccie2be@nyc.rr.com>
> To: Tiean <noktes@bellsouth.net>; Edwards, Andrew M
> <andrew.m.edwards@boeing.com>; <ccielab@groupstudy.com>
> Sent: Friday, August 13, 2004 9:44 AM
> Subject: Re: IRB question from IE lab 3 task 1.9
>
>
> > 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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:45 GMT-3