Re: 3650 COS/DSCP to queue mapping

Based on what I copied here before and on this statement in the
"Classification" section of the 3550 QoS section, I would say if you
trust CoS it will generate an internal DSCP, then use that internal
DSCP to map back to CoS and finally the CoS maps to a queue via the
CoS output queue map

In context, this statement is in a bulleted list explaining what
happens when you trust different values (DSCP, CoS, etc)

"Trust the CoS value in the incoming frame (configure the port to
trust CoS). Then, the switch uses the configurable CoS-to-DSCP map to
generate the internal DSCP value"

To be honest, I think this sort of style is on a lot of the older
platforms. I think the 3560 has the ability to queue based DIRECTLY
on whatever it is you trust and not based on a bunch of convoluted
intermediate mappings.

On Wed, Sep 5, 2012 at 7:48 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
> That's what I would call a gotcha!
> Now I would assume that the dscp-to-cos is only used when you trust dscp on
> ingress ?
>
> To be honest, what Joe was expecting is what I would have expected.
> I'm still inclined to believe that this is what happens on a 6k,
> although I would test it before being assertive about it ;-)
>
> -Carlos
>
> Joe Astorino @ 05/09/2012 04:08 -0300 dixit:
>
>> In an effort to make sure I am not completely losing my mind I set out
>> to figure out where I had gotten this notion. I believe it is
>> something I learned back in the day about the catalyst 3550 and NOT
>> the 3560. Check this out from the 3550 software configuration guide
>> here:
>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1_19_ea1/configuration/guide/swqos.html#wp1023211
>>
>> "Before the traffic reaches the scheduling stage, QoS uses the
>> configurable DSCP-to-CoS map to derive a CoS value from the internal
>> DSCP value. Through the CoS-to-egress-queue map, the CoS values select
>> one of the four egress queues for output processing."
>>
>> In the same section (look for "mapping tables") in the 3560 guide,
>> this has been changed to read:
>>
>> "Before the traffic reaches the scheduling stage, QoS stores the
>> packet in an ingress and an egress queue according to the QoS label.
>> The QoS label is based on the DSCP or the CoS value in the packet and
>> selects the queue through the DSCP input and output queue threshold
>> maps or through the CoS input and output queue threshold maps"
>>
>> NOW...since I just so happen to have some 3550's here in my home lab I
>> re-ran the same test and received the same results we did with the
>> 3560 as far as MARKING is concerned. But I believe what the 3550
>> guide here is saying is that the output queue was based on the
>> internal mapping. So, on the 3550 I believe we had the CoS mapped to
>> internal DSCP then internal DSCP mapped to CoS and CoS mapped to
>> output queue. Seems the output queue was effected by the internal
>> mappings, but not the marking itself
>>
>> So in summary -- It looks like based on testing and documentation that
>> the 3550 did something like I was saying at least for outbound
>> queueing but that the 3560 has a different approach
>>
>>
>> On Wed, Sep 5, 2012 at 1:36 AM, ccie99999 <ccie99999_at_gmail.com> wrote:
>>>
>>> sorry.. Joe.. just reloaded everything and I cannot use those switches
>>> now.
>>>
>>> anyway.. nothing special:
>>>
>>> pc1 side: cos3 + cos override.. as explained in the test
>>> pc2 side: nothing.. no trust, no override.. nothing..
>>>
>>>
>>>
>>> On Wed, Sep 5, 2012 at 5:25 AM, Joe Astorino
>>> <joeastorino1982_at_gmail.com>wrote:
>>>
>>>> 99999,
>>>>
>>>> Can you post your configurations? I would like to see on both
>>>> interfaces what you have configured for trust and other things.
>>>>
>>>> On Tue, Sep 4, 2012 at 1:46 PM, marc edwards <renorider_at_gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>
>>>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_58_se/configuration/guide/swqos.html#wp1023954
>>>>>
>>>>>
>>>>>
>>>>> Chart really says it all. What I find interested and (supporting your
>>>>
>>>> view)
>>>>>
>>>>> is the fact that DSCP-to-CoS is never used....
>>>>>
>>>>> On Tue, Sep 4, 2012 at 9:04 AM, marc edwards <renorider_at_gmail.com>
>>>>
>>>> wrote:
>>>>>
>>>>>
>>>>>> So on those thoughts.... We need to trust dscp. trusting cos
>>>>>> throughout
>>>>>> will bypass switch from looking at dscp markings. trusting dscp will
>>>>
>>>> make
>>>>>>
>>>>>> switch look into packet to see dscp markings and use mappings to
>>>>
>>>> convert a
>>>>>>
>>>>>> cos value. This should hit the dscp-cos map and reference values from
>>>>>> altered config.
>>>>>>
>>>>>> Marc
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 4, 2012 at 8:55 AM, marc edwards <renorider_at_gmail.com>
>>>>
>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> So... looks like you are tagging frames on PC NIC? Where is vlan 1
>>>>
>>>> vlan 2
>>>>>>>
>>>>>>> config or are these PC's in same VLAN/subnet? Where is 'mls qos trust
>>>>
>>>> cos'
>>>>>>>
>>>>>>> on fa 0/2?
>>>>>>>
>>>>>>> Marc
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 4, 2012 at 8:46 AM, ccie99999 <ccie99999_at_gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Command was like: MLS qos map dscp-cos 24 to 5
>>>>>>>>
>>>>>>>> Show mls QoS dscp-cos shows it's mapped correctly
>>>>>>>> Il giorno 04/set/2012 17:35, "marc edwards" <renorider_at_gmail.com> ha
>>>>>>>> scritto:
>>>>>>>>
>>>>>>>>> can you please provide command entered for dscp-cos map config?
>>>>>>>>>
>>>>>>>>> On Tue, Sep 4, 2012 at 8:31 AM, ccie99999 <ccie99999_at_gmail.com>
>>>>
>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I did cos 3 + cos override on pc1 side and trust dscp on pc2 side.
>>>>>>>>>> I can't do a show mls qos maps now but I set up a dscp24 to cos5
>>>>>>>>
>>>>>>>> mapping.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 4, 2012 at 3:30 PM, marc edwards <renorider_at_gmail.com>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Can either of you do a sh mls qos maps? Also, please show access
>>>>>>>>>>> interfaces config. My hunch is that the dscp-cos map hasn't been
>>>>>>>>>>
>>>>>>>>>> changed to
>>>>>>>>>>>
>>>>>>>>>>> refelect dscp 24 as cos 05. I am also curious to see if you have
>>>>>>>>
>>>>>>>> trusted
>>>>>>>>>>>
>>>>>>>>>>> cos or dscp on access. That will change things.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 4, 2012 at 8:23 AM, ccie99999 <ccie99999_at_gmail.com>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I've labbed this (cos3->dscp24->cos5) and I see I receive cos3
>>>>
>>>> on
>>>>>>>>
>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>> second pc as well as dscp24.
>>>>>>>>>>>>
>>>>>>>>>>>> pc1(vlan1) - sw - pc2(vlan2)
>>>>>>>>>>>>
>>>>>>>>>>>> (I do trust cos on pc2 interface side).
>>>>>>>>>>>>
>>>>>>>>>>>> I guess it's fine I see dscp24.. don't understand why I see
>>>>
>>>> cos3.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 4, 2012 at 12:33 PM, gp <gs4me2me_at_gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Joe,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried lab what you wrote, and not have result that I
>>>>
>>>> expected.
>>>>>>>>
>>>>>>>> So I
>>>>>>>>>>>>
>>>>>>>>>>>> have
>>>>>>>>>>>>>
>>>>>>>>>>>>> one question; in your opinion what cos value will have frame
>>>>
>>>> when
>>>>>>>>>>
>>>>>>>>>> leave
>>>>>>>>>>>>>
>>>>>>>>>>>>> switch: cos 3 or cos 5?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had cos 3, that confuse me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On
>>>>>>>>>>
>>>>>>>>>> Behalf Of
>>>>>>>>>>>>>
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>> Astorino
>>>>>>>>>>>>> Sent: Thursday, August 30, 2012 6:34 PM
>>>>>>>>>>>>> To: Anthony Sequeira
>>>>>>>>>>>>> Cc: Matt Eason; Cisco certification
>>>>>>>>>>>>> Subject: Re: 3650 COS/DSCP to queue mapping
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Matt,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anthony answered your question simply and correctly, but I
>>>>
>>>> just
>>>>>>>>>>
>>>>>>>>>> wanted
>>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>> add some things that helped me understand this. Like Anthony
>>>>>>>>
>>>>>>>> said,
>>>>>>>>>>>>>
>>>>>>>>>>>>> whatever
>>>>>>>>>>>>> you trust is basically how the switch determines the queue at
>>>>
>>>> a
>>>>>>>>
>>>>>>>> high
>>>>>>>>>>>>
>>>>>>>>>>>> level,
>>>>>>>>>>>>>
>>>>>>>>>>>>> but at a deeper level there are a few different mappings going
>>>>>>>>
>>>>>>>> on.
>>>>>>>>>>>>
>>>>>>>>>>>> Let's
>>>>>>>>>>>>>
>>>>>>>>>>>>> assume you trust CoS. You would have:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - CoS to DSCP mapping INTERNAL to the switch
>>>>>>>>>>>>> - DSCP to CoS mapping INTERNAL to the switch
>>>>>>>>>>>>> - CoS to output queue mapping
>>>>>>>>>>>>>
>>>>>>>>>>>>> The point I am making is that even though a frame comes in
>>>>
>>>> with a
>>>>>>>>>>>>>
>>>>>>>>>>>>> particular
>>>>>>>>>>>>> CoS value, that value COULD change internally based on the
>>>>>>>>
>>>>>>>> internal
>>>>>>>>>>>>>
>>>>>>>>>>>>> COS-DSCP
>>>>>>>>>>>>> and DSCP-COS, and the frame COULD be queued based on the value
>>>>>>>>>>
>>>>>>>>>> derived
>>>>>>>>>>>>
>>>>>>>>>>>> from
>>>>>>>>>>>>>
>>>>>>>>>>>>> the internal mappings and not on the original value. Let's
>>>>
>>>> look
>>>>>>>>
>>>>>>>> at
>>>>>>>>>>
>>>>>>>>>> some
>>>>>>>>>>>>>
>>>>>>>>>>>>> example output for a second
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here are some mapping tables for cos-dscp, dscp-cos and
>>>>>>>>
>>>>>>>> cos-output-q
>>>>>>>>>>
>>>>>>>>>> on
>>>>>>>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3750 switch. Note these are probably not default values
>>>>
>>>> because
>>>>>>>>
>>>>>>>> this
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>>>>>
>>>>>>>>>>>>> production switch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the COS to DSCP mapping:
>>>>>>>>>>>>>
>>>>>>>>>>>>> switch#sh mls qos maps cos-dscp
>>>>>>>>>>>>> Cos-dscp map:
>>>>>>>>>>>>> cos: 0 1 2 3 4 5 6 7
>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>> dscp: 0 8 16 24 32 40 48 56
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the DSCP to CoS mapping
>>>>>>>>>>>>>
>>>>>>>>>>>>> switch#sh mls qos map dscp-cos
>>>>>>>>>>>>> Dscp-cos map:
>>>>>>>>>>>>> d1 : d2 0 1 2 3 4 5 6 7 8 9
>>>>>>>>>>>>> ---------------------------------------
>>>>>>>>>>>>> 0 : 00 00 00 00 00 00 00 00 01 01
>>>>>>>>>>>>> 1 : 01 01 01 01 01 01 02 02 02 02
>>>>>>>>>>>>> 2 : 02 02 02 02 03 03 03 03 03 03
>>>>>>>>>>>>> 3 : 03 03 04 04 04 04 04 04 04 04
>>>>>>>>>>>>> 4 : 05 05 05 05 05 05 05 05 06 06
>>>>>>>>>>>>> 5 : 06 06 06 06 06 06 07 07 07 07
>>>>>>>>>>>>> 6 : 07 07 07 07
>>>>>>>>>>>>>
>>>>>>>>>>>>> Finally, here is the CoS to output queue mapping
>>>>>>>>>>>>>
>>>>>>>>>>>>> switch#sh mls qos map cos-output-q
>>>>>>>>>>>>> Cos-outputq-threshold map:
>>>>>>>>>>>>> cos: 0 1 2 3 4 5 6 7
>>>>>>>>>>>>> ------------------------------------
>>>>>>>>>>>>> queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let's just look at CoS 3 for example. We see that CoS 3 is
>>>>>>>>
>>>>>>>> mapped to
>>>>>>>>>>>>
>>>>>>>>>>>> DSCP
>>>>>>>>>>>>>
>>>>>>>>>>>>> 24. In turn DSCP 24 is mapped right back to CoS 3 in the DSCP
>>>>>>>>
>>>>>>>> to COS
>>>>>>>>>>>>>
>>>>>>>>>>>>> mapping. In turn, CoS 3 is put into output queue 3,
>>>>
>>>> threshold 1.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fine. So in this case, it comes in as CoS 3 and is queued
>>>>
>>>> based
>>>>>>>>
>>>>>>>> on
>>>>>>>>>>
>>>>>>>>>> CoS
>>>>>>>>>>>>
>>>>>>>>>>>> 3
>>>>>>>>>>>>>
>>>>>>>>>>>>> because we trust CoS and because the DSCP-COS mapping is sort
>>>>
>>>> of
>>>>>>>>>>>>
>>>>>>>>>>>> "synced".
>>>>>>>>>>>>>
>>>>>>>>>>>>> But...what if you went in and mucked with the DSCP-COS mapping
>>>>>>>>>>>>
>>>>>>>>>>>> internally
>>>>>>>>>>>>>
>>>>>>>>>>>>> such that DSCP 24 was no longer mapped back to CoS 3? What if
>>>>>>>>
>>>>>>>> it was
>>>>>>>>>>>>>
>>>>>>>>>>>>> re-mapped to CoS 5 ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you COULD have the frame come in as CoS 3 ...internally we
>>>>
>>>> go
>>>>>>>>
>>>>>>>> CoS
>>>>>>>>>>
>>>>>>>>>> 3
>>>>>>>>>>>>>
>>>>>>>>>>>>> --> DSCP 24, then DSCP 24 to CoS 5 then queued based on CoS 5
>>>>>>>>>>>>>
>>>>>>>>>>>>> These are intricate details, but when you are studying for the
>>>>>>>>
>>>>>>>> lab, I
>>>>>>>>>>>>
>>>>>>>>>>>> think
>>>>>>>>>>>>>
>>>>>>>>>>>>> it is important to get to the dirty details! Best of luck
>>>>
>>>> and I
>>>>>>>>
>>>>>>>> hope
>>>>>>>>>>>>
>>>>>>>>>>>> this
>>>>>>>>>>>>>
>>>>>>>>>>>>> helps you out.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Aug 30, 2012 at 10:45 AM, Anthony Sequeira
>>>>>>>>>>>>> <terry.francona_at_gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Matt!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What an AWESOME question. While the documentation does not
>>>>>>>>
>>>>>>>> make it
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> clear, the value that you trust on ingress, in your example,
>>>>>>>>
>>>>>>>> CoS,
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the marking that is used in the appropriate default queue
>>>>>>>>
>>>>>>>> mapping
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> table on the egress port.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anthony Sequeira, CCIE, CCSI, VCP
>>>>>>>>>>>>>> http://www.stormwind.com
>>>>>>>>>>>>>> Twitter: @compsolv
>>>>>>>>>>>>>> Facebook: http://www.facebook.com/compsolv
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/29/12 9:11 PM, "Matt Eason" <matt.d.eason_at_gmail.com>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Guys,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you help clarify the following. If I have a switchport
>>>>>>>>>>
>>>>>>>>>> configured
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>> 3560 to trust CoS inbound, that cos value is then mapped to
>>>>
>>>> an
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> internal DSCP value via the COS>DSCP map. That s fine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does this switch then determine the output queue from the
>>>>>>>>
>>>>>>>> original
>>>>>>>>>>
>>>>>>>>>> CoS
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> value or the internal DSCP value which was assigned by the
>>>>>>>>
>>>>>>>> switch?
>>>>>>>>>>
>>>>>>>>>> I
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> see both a DSCP>Output queue map and a COS>Output queue map
>>>>>>>>>>
>>>>>>>>>> exists.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> ______________________________________________________________________
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _ Subscription information may be found at:
>>>>>>>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>
>>>> ______________________________________________________________________
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _ Subscription information may be found at:
>>>>>>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Joe Astorino
>>>>>>>>>>>>> CCIE #24347
>>>>>>>>>>>>> http://astorinonetworks.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> "He not busy being born is busy dying" - Dylan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> _______________________________________________________________________
>>>>>>>>>>>>>
>>>>>>>>>>>>> Subscription information may be found at:
>>>>>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> _______________________________________________________________________
>>>>>>>>>>>>>
>>>>>>>>>>>>> Subscription information may be found at:
>>>>>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> _______________________________________________________________________
>>>>>>>>>>>>
>>>>>>>>>>>> Subscription information may be found at:
>>>>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> _______________________________________________________________________
>>>>>>>>>>
>>>>>>>>>> Subscription information may be found at:
>>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>
>>>>>>>>
>>>> _______________________________________________________________________
>>>>>>>>
>>>>>>>> Subscription information may be found at:
>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>> _______________________________________________________________________
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Joe Astorino
>>>> CCIE #24347
>>>> http://astorinonetworks.com
>>>>
>>>> "He not busy being born is busy dying" - Dylan
>>>
>>>
>>>
>>> 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_at_huapi.ba.ar> LW7 EQI Argentina

-- 
Regards,
Joe Astorino
CCIE #24347
http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net