From: Swaroop Potdar (swarooppotdar@hotmail.com)
Date: Tue Aug 10 2004 - 17:03:40 GMT-3
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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:45 GMT-3