Differentiated Service on Cisco

Previous

2.3.3- Edge31-ca-u32

Third example implemented by DS Linux Implementation is called Edge31-ca-u32. In this example the goal is to implement an edge router as a re-marker device; i.e., packets are expected to come previously marked, probably by another DS capable domain. At the same time some policing on entering packets is required. The scheme is as follows:

Reading on the table above observe, for example, that incoming packets marked as DS class AF41 are transmitted as they are (untouched) up to 1500 Kbps; next 1000 Kbps should be transmitted too but they must be remarked (demoted) as DS class AF42; next 1000 Kbps should be transmitted too but they must be remarked (demoted) as DS class AF43; any traffic marked as DS class AF41 above 3500 Kbps must be dropped. DS class AF42 and AF43 packets have similar rules to be treated.

Well... Cisco solution for this case is not as easy as before. This environment requires something that Linux has and Cisco hasn't, at least using traffic policies. We need some mechanism to evaluate traffic conditions in cascade having a "continue" action to evaluate next condition. Linux has this implemented in its police command. Cisco has not this in its policy-map command but they have something similar using CAR. I wrote some words about CAR just in CAR queuing discipline in this site. Perhaps because its implementation was weak, Cisco extended it implementing something called Policer Enhancement: Multiple Actions, but even with this they forgot to include a "continue" action to tell the software to evaluate next condition. Then you can include many actions but just one policy; would be very nice to have this simplyfing our life.

Let's have a brief look to the Policer Enhancement from Cisco to understand what I'm talking about:

This example was taken from the Cisco document about the Policer Enhancement above. Observe, they police using a cir (committed information rate) of 1000 Kbps and a pir (peak information rate) of 2000 Kbps. Then the conditions to be evaluated: conform, exceed, violate; and the actions: transmit, set-prec-, set-frde-, drop, etc. As you see you have one police and as many conditions and action you want, but nothing as a "continue" action and go to the next police; something like this:

This is an hypothetical example; very important: hypothetical. Cisco doesn't implement this configuration. In this example we have two polices; the router evaluates first of them and if it is violated the "continue" action means: okay fellows, we failed here, let's evaluate the next police. And the next police is evaluated using a higher cir and pir.

Okay, that's what we would like; but, what about what we have? Well, to use polices in cascade using Cisco we don't have any alternative than using CAR. But what actions can we implement using Cisco CAR? Having a look to the CAR documentation from Cisco just here, we could take advantage of the Set QoS group and transmit and the Set QoS group and continue actions to do what we want. The QoS Group is a number in the range 0-99 which identifies a packet just within the router only (thinking it's like Linux where they mark the packet's buffer and not the packet itself), being very nice because we don't need to mark packets using anything different to the DSCP field.

Let's try to build some commands using Cisco CAR to mark our packets with different QoS Groups depending on the nature of the traffic; but first let's have a feeling about Cisco CAR:

This figure is taken from the document referenced above about Cisco CAR; as they wisely explain CAR is a long command repeated over and over with various rule specifications; what is good for us is that any of those rules can use the continue keyword which means: break here and evaluate the next condition. Have a look to our rule's table above and let's try to implement rules 1 to 4 using CAR; then we could write something like this:

Here we are policing traffic in the ingress queue; that's the reason of the input keyword. Using access-list we assign all traffic entering our domain marked as DS class AF41 to the access-group 101. Then we match access-group 101's packets against three police rules. First of them implement our rule #1, i.e., AF41 packets will be transmitted up to 1500 Kbps and 90 KB; traffic above this is committed to test the second rule using the continue keyword. This rule implements our rule #2, i.e., AF41 packets will be transmitted up to 2500 Kbps and 90 KB, that's next 1000 Kbps because first 1500 Kbps were matched before by the first rule. Because we can't use CAR to set the packets' DSCP field, at least we mark them as QoS Group #1 having the expectation of catching them later, when leaving the router; traffic above 2500 Kbps is committed to test the third rule. The last rule implements our rules #3 and #4, transmiting packets up to 3500 Kbps (next 1000 Kbps) and marking them as QoS Group #2, dropping all above this limit.

Well, having our packets properly policed and marked we can use these marks (remember these are packet's buffer marks, not in the packets themself) to remark them (using DSCP field) when leaving the router for another interface. Let's see an example of this:

Here, using match qos-group we identify packets and remark them as required by our rule's table above. After the service-policy is ready to begin working we apply it to the output of any X interface.

Well, after this long explanation we are ready to configure our Cisco router to do what Linux did sometime ago. But, again, I really love Cisco more terse approach to implement what we want. Here we have the commands using a symbolic input interface X and a symbolic output interface Y. Replace these names for truly interface names you want.

Okay, dear fellows, next example is Edge32-ca-u32; let's start to work.

Previous

Content

Next