[Flow-tools] interpreting ToS field? (fwd)
Michael W. Lucas
mwlucas at blackhelicopters.org
Sat Dec 5 14:38:27 EST 2009
Thanks, definitely useful to have all of this in one spot.
On Sat, Dec 05, 2009 at 10:06:13AM -0600, Craig Weinhold wrote:
> I've attached a cheat-sheet (view/print with monospace font).
>
> There is a little bit of historical context that's useful to understand
> ToS, though. For example, Michael shows that some flows have ToS 2. That
> could either be an antique "min-montetary-cost" host or, more likely,
> a modern ECN-compliant host.
>
> ECN (RFC 3168) is an emerging issue for traditional netflow collection
> and processing. The jist of ECN is that an intermediary router can,
> after sensing congestion, change the lower two bits of ToS to indicate
> congestion so that the hosts can slow themselves down. It's a L3
> implementation of frame-relay FECN, essentially. Unfortunately, since
> the ToS field changes packet-to-packet and hop-to-hop, it also disrupts
> the traditional netflow 7-tuplet key (protocol, src/dst IP, src/dst port,
> ToS, input interface).
>
> If you can, exclude ToS as a flow key on your netflow sources. Recent
> cisco IOS versions let you do this with flexible netflow while still
> exporting netflow v5.
>
> -Craig
>
>
> On Sat, 5 Dec 2009, sthaug at nethelp.no wrote:
>
> > > Various flow-stat and flow-report output include Type of Service
> > > reports. I'm finally on a network where we use ToS, and I need to
> > > make sense of the results.
> > >
> > > Can anyone point me to any documentation on the ToS values flow-tools
> > > reports? How can I map these results to, say, DSCP? Here's a snippet
> > > of flow-stat output for reference:
> >
> > There's no magic here. ToS is the whole 8 bit ToS field. Divide by 4
> > (or right shift 2) to get DSCP, since DSCP is the 6 most significant
> > bits of the ToS field.
> >
> > Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> > _______________________________________________
> > Flow-tools mailing list
> > flow-tools at splintered.net
> > http://mailman.splintered.net/mailman/listinfo/flow-tools
> >
> **** Pre-1998
>
> The IPv4 ToS byte was part of the original 1981 definition of Internet Protocol in RFC 791, which specified a 3-bit precedence value and 3-bits of ToS attributes. In the tables below, "tos" values refer to the entire byte. In 1992, RFC 1349 added a fourth ToS attribute.
>
> 0x80 0x40 0x20 0x10 0x08 0x04 0x02 0x01
> +-----+-----+-----+-----+-----+-----+-----+-----+
> | PRECEDENCE | TOS attributes | - |
> +-----+-----+-----+-----+-----+-----+-----+-----+
>
> PRECEDENCE TOS attributes
>
> name dec tos bin name dec tos bin
> network 7 224 111 min-delay 8 16 1000
> internet 6 192 110 max-throughput 4 8 0100
> critical 5 160 101 max-reliability 2 4 0010
> flash-override 4 128 100 min-monetary-cost 1 2 0001
> flash 3 96 011 normal 0 0 0000
> immediate 2 64 010
> priority 1 32 001
> routine 0 0 000
>
>
> **** Post-1998
>
> RFC 2474 reworked the ToS as a 6-bit Differentiated Services Code Point (DSCP) and, soon after, RFC 3168 allocated the lowest two bits for Error Congestion Notification (ECN, an IP analogy of frame-relay FECN and ATM EFCI).
>
> 0x80 0x40 0x20 0x10 0x08 0x04 0x02 0x01
> +-----+-----+-----+-----+-----+-----+-----+-----+
> | DSCP | ECN |
> +-----+-----+-----+-----+-----+-----+-----+-----+
>
> DSCP
>
> name dec tos binary name dec tos binary
> AF11 10 40 001010 CS1 8 32 001000
> AF12 12 48 001100 CS2 16 64 010000
> AF13 14 56 001110 CS3 24 96 011000
> AF21 18 72 010010 CS4 32 128 100000
> AF22 20 80 010100 CS5 40 160 101000
> AF23 22 88 010110 CS6 48 192 110000
> AF31 26 104 011010 CS7 56 224 111000
> AF32 28 112 011100 EF 46 184 101110
> AF33 30 120 011110 default 0 0 000000
> AF41 34 136 100010
> AF42 36 144 100100 AF = assured forwarding
> AF43 38 152 100110 EF = expedited forwarding
> CS = class selector
>
> ECN (unrelated to QoS)
> 00 Not-ECT Not ECN-Capable Transport
> 01 ECT(0) ECN-Capable Transport
> 10 ECT(1) ECN-Capable Transport
> 11 CE Congestion Experienced
>
> **** Notes on interpreting the ToS byte
>
> The two definitions are complimentary for the upper 3-bits. This is good, since those three bits are often copied to/from the 3-bit class-of-service (CoS) field of layer-2 802.1p frames and the 3-bit experimental (EXP) field of MPLS frames. Bits 3-5, however, are fairly incompatible..
>
> Thus, it's important not to oversimplify precedence/DSCP as a simple pecking order. In reality, each unique precedence/DSCP value conveys a packet's requirements for throughput, latency, and packet loss, three traits that are somewhat at odds with each other. And, any value can be assigned to any organizationally-unique purposes. For example,
>
> * Packets with precedence 5 and/or DSCP EF are often serviced by priority queues, so they may delay packets with higher precedence/DSCP values.
> * Within each AF level (e.g., AF2x includes AF21, AF22, and AF23), the higher values indicate a higher tolerance to packet loss. I.e., a congested interface should drop AF22 packets earlier than AF21 packets. In Cisco IOS, this behavior is implemented with DiffServ-complaint WRED ('random-detect dscp' on a class-map).
> * Any DSCP value under CS6 can be assigned for any organizationally-unique use. For example, Precedence 1/DSCP CS1 is often assigned for use as a less-than-best-effort class called scavenger. To successfully implement the scavenger class, all network devices must agree to treat CS1 traffic worse than Precedence 0/DSCP default.
>
--
Michael W. Lucas mwlucas at BlackHelicopters.org
http://www.MichaelWLucas.com/
Latest book: Cisco Routers for the Desperate, 2nd Edition
http://www.CiscoRoutersForTheDesperate.com/
More information about the Flow-tools
mailing list