Re: 3650 COS/DSCP to queue mapping

Yes. we should be. How about a short description adding or correcting
what has been said ?

Narbik Kocharians @ 07/09/2012 12:18 -0300 dixit:
> I have bunch of fully tested labs if you guys are interested.
>
> On Wed, Sep 5, 2012 at 6:08 AM, Joe Astorino <joeastorino1982_at_gmail.com
> <mailto:joeastorino1982_at_gmail.com>> wrote:
>
> 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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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> [mailto: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
> <tel:1%20%202%20%203%20%204%20%205%20%206%20%207>
> >>>>>>>>>>>>> --------------------------------
> >>>>>>>>>>>>> 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
> <mailto: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 <mailto: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 <mailto: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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
> --
> *Narbik Kocharians
> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> *www.MicronicsTraining.com* <http://www.micronicstraining.com/>
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> A Cisco Learning Partner
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net