In Parts 1, Part 2 and Part 3 we saw we can use the CEF table to express all sorts of different QoS policies. In Part 4 we describe how to attach a policy to the packet that will follow it around the network.
Like many policies (security, shaping, etc.) it’s best to classify the traffic at the edge as it enters the network. Like qos-group we’ll setup a table to classify certain traffic. Your table may look different, depending on what QoS policy you are trying to achieve.
Routine (0) Internet
Priority (1) Business applications
Immediate (2) Latency-sensitive Business Apps
Critical (5) Voice
Just as before, we can come up with any breakdown that suits are purposes. This will mark the IP Precedence Field (3 bits) within the DSCP byte on the packet so we have Values of 0-7 that we can assign. Using our special CEF magic, all our prefixes in CEF have been pre-marked with one of these Precedence values. We can check this with the show ip cef detail command.
We then apply the following to an interface.
bgp-policy destination ip-prec-map
Bam! As packets arrive at an interface the IP Precedence field in the header is modified based on the destination IP address of the packet header. So, if our network QoS can be based on the destination subnet of our packet, we can feed that information into the routing table (which feeds CEF) and at CEF speeds we can mark packets as they arrive.
We can even mark packets as they arrive based on the source IP address in the packet header…
bgp-policy source ip-prec-map
Now that the IP Precedence field is marked on the packet header we can process the packet locally or process it somewhere else in the network. For instance, a very simply way to manage congestion on a link would be Random Early Detection.
As congestion starts to pile up on Gi0/1 it will start to randomly drop packets in an attempt to cause TCP flows to naturally slow down at their source. The random dropping of packets gets more and more aggressive as you descend from Precedence 7 down to Precedence 0. The hope is TCP traffic at low precedence will “get the message” and naturally slow down, making capacity available for higher priority traffic. It’s not perfect but it’s better than Tail Drop! And in terms of complexity, what would we rather have, a stateless QoS system like RED or a complex statefull setup like ATM or RSVP? Stateless network technologies are easier to scale so RED wins in my book.
As a side note, Cisco IOS marks RIP, OSPF EIGRP and BGP control packets with IP Precedence 6. You generally want your user traffic to be marked at 5 or below.
Of course, if you want a good degree of fine control you could put in some Modular CLI QoS (MQC) and specify specific behavior for each level of IP Precedence. You could go hog wild writing a complex policy. The nice thing is you could write this policy fifteen router-hops away; the IP Precedence was attached to the packet header when it first entered the network so it will arrive at some remote area of the network with the QoS marking intact.
At first I was concerned with changing the header of an IP packet. Would it disrupt applications or invalidate packets encrypted with IPSec? No problems here. IPSec does not consider the IP Precedence field when writing the Message Authentication Code (MD5, SHA, etc.) Applications should not freak out because RFC 2474 states ” it is very rare that the network honors markings at the ingress to the DiffServ domain” which should mean the IP Precedence could be changed at any moment within the network, no problem.
If you have been following along since Part 1 I appreciate your patience. Everyone is now wondering how the traffic-index, qos-group and precedence markings were attached to prefixes in the RIB and CEF. Since all the commands have been prefixed with bgp-policy you may be wondering if it has anything to do with BGP! Part 5 will explain.