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, [email protected] 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, [email protected] > > _______________________________________________ > > Flow-tools mailing list > > [email protected] > > 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 [email protected] http://www.MichaelWLucas.com/ Latest book: Cisco Routers for the Desperate, 2nd Edition http://www.CiscoRoutersForTheDesperate.com/ _______________________________________________ Flow-tools mailing list [email protected] http://mailman.splintered.net/mailman/listinfo/flow-tools
