This is part 4 of an 4-part series (so far 4 parts) on the ToS field (i.e. Differentiated Services Field) of IP frames. I finally get into how all this relates to NetFlow in 2009. Make sure you have already read Part 1, Part 2 and Part 3 of this blog.
ToS and DSCP part 4
At the end of Part 3 of this blog series I digressed very briefly on how CBQoS can be used to modify DSCP values on packets which come into the router. In other words, VoIP traffic that comes in on ports 4569 and 5060 could enter a router with one DSCP value 0x00 and leave with a completely different one e.g. 0xEF (i.e. 11101111).
The BIG Question:
How can you confirm that the DSCP value was actually changed? This is important because we might want to make sure using DiffServ that VoIP gets top priority on the network. Fortunately, Scrutinizer provides a way to confirm these changes.
Because we are collecting NetFlow v9 with ingress and egress turned on, we can filter (in Scrutinizer v7) for the destination address (188.8.131.52) after adding both the in (Fa0/0) and out (Fa0/1) interfaces to the report:
Above, 184.108.40.206 is the destination (dst) when it comes in on one interface and when it goes out the other interface. It is important that this be recognize. This is why both ingress and egress flows be exported.
Here are the results; notice the flow looks exactly the same except for the ToS field when it comes in Interface 1 and goes out Interface 2:
There you have it. 🙂 The flow came in with a DSCP value of 0 and went out with a DSCP value of 46. DiffServ is cool. Your NetFlow Analyzer must be able to report on DSCP values using ingress and egress flows in the same report.
ECN bits are being set in the ToS!
Remember, I joked about the Currently Unused (usually) bits in part 3. Let’s make this a 5th blog in this 4 part series…..