[c-nsp] Cisco ToS/CoS/DiffServe

[Saku Ytti]

On (2006-04-05 08:18 +0300), Arie Vayner wrote:
> Lawrence,
> 
> I would suggest you take a look at "IP SLA":
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hsla_c/index.htm

I'm not sure how IP SLA will help Lawrence to protect his VoIP/ERP traffic
against bursty best effort. I'd rather point him to 3560 configuration
guide[0] regarding QoS.

[0] http://www.cisco.com/en/US/products/hw/switches/ps5528/products_configuration_guide_chapter09186a00805b57c4.html


> 
> Arie
> 
> On 4/5/06, Lawrence Wong <lawrencewong72 at yahoo.com> wrote:
> > Thanks Ytti.
> >
> > I'm a "service provider" serving the users in my
> > office network. ^^
> >
> > I'm looking along the line of ensuring certain
> > "service level" for VoIP and ERP applications running
> > through the internal LAN in the face of sparodic burst
> > of traffic when other users copy files from the other
> > servers on the same network.
> >
> > Would ToS/DiffServe be an overkill for this?
> >
> > --- Saku Ytti <saku+cisco-nsp at ytti.fi> wrote:
> >
> > > On (2006-03-31 23:38 -0800), Lawrence Wong wrote:
> > >
> > > Hello,
> > >
> > > > I read from the documentation that switches like
> > > the
> > > > 2960 and 3560 support QoS based on
> > > ToS/CoS/DiffServe,
> > > > etc.
> > >
> > > prec5 (101) == dscp40 (101000) == tos160 (10100000)
> > >
> > >  CoS is 3 bits also. prec,dscp,tos are all from IPv4
> > > 'tos byte' just giving remaining extra bits
> > > different
> > > meanings, so changing prec changes dscp and tos too.
> > >  CoS of course is in 802.1q headers only and can
> > > have
> > > different value to that off 'tos byte' content.
> > >
> > > > Does anyone have any idea how the QoS settings can
> > > be
> > > > verified? Or how will I know whether the actual
> > > > traffic has indeed been given the CoS which I
> > > wanted
> > > > to set?
> > >
> > > lab, lab, lab and lab testing if you're service
> > > provider.
> > > catalysts aren't the most trivial platform to get
> > > QoS
> > > right :/, using extensive lab testing will probably
> > > be
> > > only way to get it right.
> > > If you're 'user' of the QoS, then apparently you
> > > don't
> > > need the QoS if you can't know if it works or if it
> > > does not work (if you can't observe quality issues,
> > > why bother fiddling with QoS).
> > >
> > > example from my own connection, typical DSL
> > > connection
> > > with large downstream, low upstrea. If my QoS were
> > > suddenly to break down. I could immediately observe
> > > it when I next time upload something, by my mp3
> > > playing (over samba), tv-series (over http),
> > > interactive
> > > ssh sessions (upstream latency) and download
> > > (upstream
> > > tcp acks) having severe quality issues. In my case
> > > QoS
> > > is simply prioritizing small packets (<200 bytes)
> > > upstream, which will take care of all of the
> > > problems
> > > that I can observe as a user.
> > >
> > > --
> > >   ++ytti
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at
> > > http://puck.nether.net/pipermail/cisco-nsp/
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
  ++ytti