From: Scott M Vermillion (scott@it-ag.com)
Date: Mon Dec 08 2008 - 16:07:40 ARST
Cisco just called and asked me to update my case with more details so that
they could escalate it. I included a brief mention of your troubles with
Pod1 as well. Seems most of us have had some kind of issue with that
specific rack and none to speak of on any of the others, so maybe Cisco can
get to the bottom of it. One suggestions that I made was simply to assign
someone to try to complete the entire lab scenario on that rack to see what
comes of it. Also asked them to look for any log entries related to
err-disable events on the core switch ports attaching to Pod1...
-----Original Message-----
From: Scott M Vermillion [mailto:scott@it-ag.com]
Sent: Monday, December 08, 2008 10:45 AM
To: 'Carlos G Mendioroz'
Cc: 'Luan Nguyen'; 'CCIE Lab'
Subject: RE: OT: GOLD Labs On PEC?
Well, as I recall, this is some strange development release of code compiled
specifically for the lab scenario, no? I guess we can't assume it's
entirely bug-free. Not entirely clear that we can assume >VSS< is bug-free
for that matter! ;~) But it's still good sport...
-----Original Message-----
From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: Monday, December 08, 2008 10:42 AM
To: Scott M Vermillion
Cc: 'Luan Nguyen'; 'CCIE Lab'
Subject: Re: OT: GOLD Labs On PEC?
This was on pod1 too.
I'll see if I can reproduce it, but the log of the console speaks for
itself. Nothing really strange, just the etherchannels, three vlans, ...
Scott M Vermillion @ 8/12/2008 15:36 -0200 dixit:
> Agreed. I did some extracurricular breaking of things and this was not a
> problem area. I too played around with preemption towards the end and
> verified connectivity from the c4948. My only problems were early on and
> related to a loss of connectivity to the core switch from the VSS. Seemed
> the core switch ports had gone into err-disable or something. Had to
start
> over on a new pod after an hour of frustration. Talked to another CCIE
who
> had the same issue on the same pod (Pod1) with ultimately the same fix
> action. I have a support case open on the matter and Cisco is responding,
> so that should hopefully be resolved soon...
>
>
> -----Original Message-----
> From: Luan Nguyen [mailto:luan@netcraftsmen.net]
> Sent: Monday, December 08, 2008 10:25 AM
> To: 'Carlos G Mendioroz'
> Cc: 'Scott M Vermillion'; 'CCIE Lab'
> Subject: RE: OT: GOLD Labs On PEC?
>
> Re: 2) I never had any problem with one port left the Po, and you
shouldn't
> either :)
> I would suggest to try again, ping from client 3 instead and do some debug
> on the 4948.
>
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> www.NetCraftsmen.net
>
>
>
> -----Original Message-----
> From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
> Sent: Monday, December 08, 2008 11:54 AM
> To: Luan Nguyen
> Cc: 'Scott M Vermillion'; 'CCIE Lab'
> Subject: Re: OT: GOLD Labs On PEC?
>
> Luan Nguyen @ 8/12/2008 14:42 -0200 dixit:
>> 1) Those are the 6 etherchannels between the FWSM and the switch.
>> When you reload switch 1, you only see 6 for switch 2. Once everything
is
>> back, you will see 2 Pos for switch 1 and switch 2 each with 6 ports.
>
> Stupid me :) Yup, I did power down one of the FWSMs to make the
> switchover faster, that explains the asymmetry.
> I did not engage into associating the second number to the slot
> in the chasis.
>
>> 2) Not sure what you did, but if one port left the channel, that status
>> should be Te1/50(D) - D for down, and the port-channel should still
>> function.
>
> I did an etherchannel between the 4948 and one port of each 6500,
> trunking, and a ping between an SVI at the 4948 and one at the 6500.
>
> -Carlos
>
>> Regards,
>>
>> Luan Nguyen
>> Chesapeake NetCraftsmen, LLC.
>> www.NetCraftsmen.net
>>
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>> Carlos G Mendioroz
>> Sent: Monday, December 08, 2008 6:51 AM
>> To: Scott M Vermillion
>> Cc: 'CCIE Lab'
>> Subject: Re: OT: GOLD Labs On PEC?
>>
>> I've just done it (the lab).
>> There were a couple of things that I would like to understand,
>> if someone has a clue.
>>
>>
>> 1) show etherchannel summary showed some bundles that the config
>> had no hint about:
>>
>> Group Port-channel Protocol Ports
>>
>
------+-------------+-----------+-------------------------------------------
>> ----
>> 1 Po1(RU) - Te1/1/4(P) Te1/1/5(P)
>> 2 Po2(RU) - Te2/1/4(P) Te2/1/5(P)
>> 3 Po3(SU) PAgP Te1/2/2(P)
>> 4 Po4(SU) LACP Gi1/3/1(P)
>> 10 Po10(RD) PAgP Te1/2/1(D)
>> 580 Po580(SD) -
>> 596 Po596(SD) -
>>
>> This is some time after a switchover.
>>
>> While stable, they showed:
>> 580 Po580(SD) -
>> 596 Po596(SU) - Gi2/4/1(P) Gi2/4/2(P) Gi2/4/3(P)
>> Gi2/4/4(P) Gi2/4/5(P) Gi2/4/6(P)
>>
>> but all Gi ports where config default.
>>
>>
>> 2) That switchover was produced by preemtion, and one of the
>> etherchannels stayed down from the 4948 perspective:
>>
>> pod1-4948-10G#ping
>> Protocol [ip]:
>> Target IP address: 10.252.11.1
>> Repeat count [5]: 1000000
>> Datagram size [100]: 4000
>> Timeout in seconds [2]:
>> Extended commands [n]:
>> Sweep range of sizes [n]:
>> Type escape sequence to abort.
>> Sending 1000000, 4000-byte ICMP Echos to 10.252.11.1, timeout is 2
> seconds:
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!
>> 2d16h: %EC-5-UNBUNDLE: Interface TenGigabitEthernet1/50 left the
>> port-channel Po
>> rt-channel3............................................
>> ......................................................................
>> ......................................................................
>> ........
>> pod1-4948-10G#sh etherc sum
>> Flags: D - down P - in port-channel
>> I - stand-alone s - suspended
>> R - Layer3 S - Layer2
>> U - in use f - failed to allocate aggregator
>> u - unsuitable for bundling
>> w - waiting to be aggregated
>> d - default port
>>
>>
>> Number of channel-groups in use: 1
>> Number of aggregators: 1
>>
>> Group Port-channel Protocol Ports
>>
>
------+-------------+-----------+-------------------------------------------
>> ----
>> 3 Po3(SU) PAgP Te1/49(P) Te1/50(P)
>>
>> pod1-4948-10G#ping 10.252.11.1
>>
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 10.252.11.1, timeout is 2 seconds:
>> .....
>> Success rate is 0 percent (0/5)
>>
>> Any ideas ?
>> -Carlos
>>
>>
>>
>> Scott M Vermillion @ 4/12/2008 21:55 -0200 dixit:
>>> Incidentally all, the VSS lab pods are back online and available for
>> either
>>> immediate booking or scheduled booking. I think it's great that Cisco
> has
>>> something like this and I'd sure love to see more of it (how many of us
>> have
>>> two 6500s w/ Sup 720 10GE VSS in our home labs?!). I would think one
way
>> to
>>> encourage Cisco to continue with this type of investment is to make use
> of
>>> it. Please, if you have any interest in playing around with (admittedly
>>> fairly basic) VSS and have access to PEC, take the time to do this lab.
>>> It's scheduled for four hours but can be completed in half (or less)
that
>>> time by a CCIE or CCIE lab candidate with basic proficiency of L2 and L3
>>> EtherChannels, etc. This lab even includes a shared server and a
>>> pod-specific server with VMWare hosts for connectivity testing, etc.
> It's
>>> way cool - especially given the price!
>>>
>>>
>>>
>>>
>>>
>>> From: Scott M Vermillion [mailto:scott@it-ag.com]
>>> Sent: Saturday, November 29, 2008 2:34 PM
>>> To: 'CCIE Lab'
>>> Subject: OT: GOLD Labs On PEC?
>>>
>>>
>>>
>>> Howdy all,
>>>
>>>
>>>
>>> Anybody know anything about the Global Online Lab Delivery (GOLD) labs
on
>>> Partner Education Connection (PEC)? I used to use PEC fairly often
years
>>> back but have only recently begun poking around there again. There was
a
>>> very interesting online lab listed and it was only introduced just this
>>> year. Yet every time I try to pick a date to schedule the rack I get
the
>>> following error:
>>>
>>>
>>>
>>> "No valid equipments found for the exercise, please contact LabOps
>>> administrator."
>>>
>>>
>>>
>>> I have no idea as to how one might go about contacting the "LabOps
>>> administrator." I seem to recall that at one time they had some really
>> cool
>>> racks available and I never had any trouble scheduling one. Just
curious
>> if
>>> anybody else has recent experience with these?
>>>
>>>
>>>
>>> Just for whatever it's worth, here is the description of the lab I was
>>> interested in:
>>>
>>>
>>>
>>> "The purpose of this lab is to introduce the student to the concept of
>> VSS,
>>> understand the conversion process, and to allow them to gain an
>> appreciation
>>> of the benefits that VSS will bring to the rest of the network.
>> Additional
>>> labs are also available to help understand advanced VSS concepts such as
>> VSS
>>> ISSU, VSS troubleshooting commands & Service module integration."
>>>
>>>
>>>
>>> Looking at the topology and the steps involved, it looks like you would
>> gain
>>> a fairly good grasp of actually deploying a VSS. It was estimated to be
>> 240
>>> minutes in duration. All very interesting if actually available.
>>>
>>>
>>>
>>> Cheers all,
>>>
>>> Scott
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI ArgentinaBlogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:08 ARST