Znyx Networks bh5700 Manuale Utente
The U32 Filter
The U32 filter provides the capability to match on fields in the L2, L3 or L4 header of a packet.
Each match rule gives the location of the field to be tested, which is always a 32 bit word, a mask
selecting the bits to be tested, and a value which is to be matched by the packet field. Many
matches can be specified in one tc filter command. Only if all matches succeed does the filter
match. In that case, the flowid field identifies the classid of the class this packet belongs in.
Each match rule gives the location of the field to be tested, which is always a 32 bit word, a mask
selecting the bits to be tested, and a value which is to be matched by the packet field. Many
matches can be specified in one tc filter command. Only if all matches succeed does the filter
match. In that case, the flowid field identifies the classid of the class this packet belongs in.
The following tc commands put all icmp packets in class 100:10, packets from IP address
1.2.3.4 in class 100:20. Packets for IP address 1.2.3.4 in class 100:20, and arp reply packets in
class 100:30. The last filter illustrates using an offset from the beginning of the protocol header,
along with a mask, to locate the field to be matched
1.2.3.4 in class 100:20. Packets for IP address 1.2.3.4 in class 100:20, and arp reply packets in
class 100:30. The last filter illustrates using an offset from the beginning of the protocol header,
along with a mask, to locate the field to be matched
tc filter add dev zhp0 protocol ip parent 100:0 u32 match ip
protocol 1 0xff flowid 100:10
protocol 1 0xff flowid 100:10
tc filter add dev zhp0 protocol ip parent 100:0 u32 match ip
src 1.2.3.4/32 flowid 100:20
tc filter add dev zhp0 protocol ip parent 100:0 u32 match ip
dst 1.2.3.4/32 flowid 100:20
dst 1.2.3.4/32 flowid 100:20
tc filter add dev zhp0 protocol arp parent 100:0 u32 match u32
2 0xffff at +4 flowid 100:30
Combining Queuing Disciplines
Any of the queue length limiting disciplines can be used with the bandwidth management queue
disciplines, by defining them with the handle of one of the classes as their parent. For the htb
queueing discipline, each class has an explicit handle specified when it is defined. For the prio
queueing discipline, including wrr, each band is a class; their handles are formed from the
handle of the prio qdisc by appending a minor number of 1 to n for the n bands. For
example, the following commands define two strict priority queues for port zre5, with the lower
priority queue limited to 32 kb and the higher priority queue limited to 32 kb:
disciplines, by defining them with the handle of one of the classes as their parent. For the htb
queueing discipline, each class has an explicit handle specified when it is defined. For the prio
queueing discipline, including wrr, each band is a class; their handles are formed from the
handle of the prio qdisc by appending a minor number of 1 to n for the n bands. For
example, the following commands define two strict priority queues for port zre5, with the lower
priority queue limited to 32 kb and the higher priority queue limited to 32 kb:
tc qdisc add dev zre5 root handle 100:0 prio bands 2 priomap 0
0 0 0 1 1 1 1
0 0 0 1 1 1 1
tc qdisc add dev zre5 parent 100:1 handle 110:0 bfifo limit
32kb
tc qdisc add dev zre5 parent 100:2 handle 120:0 bfifo limit
32kb
32kb
These translation rules handle conversions of individual rules from tc entries into hardware
entries. They do not explain the results of creating rules that are individually supported; but
which do not make sense in conjunction.
entries. They do not explain the results of creating rules that are individually supported; but
which do not make sense in conjunction.
Ethernet Switch Blade User's Guide
release 3.2.2j
page 69