Edge31-ca-u32

Previous

3.3. Edge31-ca-u32

The example's script is as follows:

#!/bin/bash

####################### Ingress side ########################

tc qdisc add dev eth0 handle ffff: ingress

tc filter add dev eth0 parent ffff: protocol ip prio 4 handle 1: u32 \
divisor 1

tc filter add dev eth0 parent ffff: protocol ip prio 4 u32 \
match ip tos 0x88 0xfc \
police index 1 rate 1500kbit burst 90k \
continue flowid :1

tc filter add dev eth0 parent ffff: protocol ip prio 5 u32 \
match ip tos 0x88 0xfc \
police index 2 rate 1000kbit burst 90k \
continue flowid :2

tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \
match ip tos 0x88 0xfc \
police index 3 rate 1000kbit burst 60k \
drop flowid :3

tc filter add dev eth0 parent ffff: protocol ip prio 5 u32 \
match ip tos 0x90 0xfc \
police index 2 rate 1000kbit burst 90k \
continue flowid :2

tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \
match ip tos 0x90 0xfc \
police index 3 rate 1000kbit burst 60k \
drop flowid :3

tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \
match ip tos 0x98 0xfc \
police index 3 rate 1000kbit burst 60k \
drop flowid :3

tc filter add dev eth0 parent ffff: protocol ip prio 7 u32 \
match ip src 0/0 \
police index 4 rate 1500kbit burst 60k \
drop flowid :4

######################## Egress side ######################## tc qdisc add dev eth1 handle 1:0 root dsmark indices 64 tc class change dev eth1 classid 1:1 dsmark mask 0x3 value 0x88 tc class change dev eth1 classid 1:2 dsmark mask 0x3 value 0x90 tc class change dev eth1 classid 1:3 dsmark mask 0x3 value 0x98 tc class change dev eth1 classid 1:4 dsmark mask 0x3 value 0x0 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 1 tcindex classid 1:1 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 2 tcindex classid 1:2 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 3 tcindex classid 1:3 tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ handle 4 tcindex classid 1:4

We have some new keywords in this example. It handles four classes identified by tcindex values 1, 2, 3 and 4. The idea is to mark packets in this way:

This is done using the commands on the egress side. More explanations are not required for the egress eth1 interface configuration. Let's concentrate now in the ingress eth2 interface configuration.

Here they use what is known as shared meters. Each meter is identified by the keywords police index n, where n is the meter number. Four meters are used here. Meter 1 is attached to filter element 4 (prio 4), meters 2, 3 and 4 are attached to filter elements 5, 6, and 7, respectively.

This example assume that traffic arrives to the ingress router previously marked, probably by another DS capable domain. There are three rules to be applied to traffic that enter the ingress router marked as DS field 0x88 (DS class AF41).

DS AF41 traffic above 3500kbps is dropped. As you can see this edge router is really remarking entering flows. The service level agreement calls to keep on the DS AF41 traffic with its original classification up to 1500kbps, 90KB burst. This traffic is accepted and forwarded as it is. Above this CIR (commited information rate), for the next 1000kbps, 90KB burst, DS AF41 traffic is accepted but remarked (demoted) as DS AF42. Above this, next 1000kbps, 60KB burst, again from the DS AF41 traffic, is accepted but remarked (demoted) as DS AF43. Rest of the DS AF41 traffic is dropped.

The job that our very nice edge (ingress) router is doing is conditioning the entering traffic.

Is left to the gentle reader to draw its own tables for entering traffic marked as DS AF42 and DS AF43. It is a good exercise, then go ahead. By the way, what about with entering traffic not marked as DS AF41, AF42 or AF43? How does the router deal with them?

Okay, it's time to continue with Edge32-ca-u32.

Previous

Content

Next