Lines Matching +full:x +full:- +full:real +full:- +full:ip

4 u32 \- universal 32bit traffic control filter
40 \fIu12_hex_htid\fB:\fR[\fIu8_hex_hash\fB:\fR[\fIu12_hex_nodeid\fR] | \fB0x\fIu32_hex_value\fR }
85 .B ip
86 .IR IP " | "
99 .IR IP " := { { "
170 filters into a tree-like hierarchy.
213 is often non-intuitive. Therefore the terminals in
220 indicates a two byte-sized value in range between 0 and 65535 (0xFFFF)
227 .I 0x
233 are in dotted-quad formatting as usual for IPv4 addresses. An
235 is specified in common, colon-separated hexadecimal format. Finally,
348 Basically the only real selector is
371 .BI ip " IP"
379 .IR IP / IP6
390 effectively match any address. Otherwise an IP address of the particular
410 Assume a next-header protocol of icmp or ipv6-icmp and match Type or Code
498 tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \\
499         match ip src 192.168.8.0/24 classid 1:1
515 if the IP header's source address is within the
523 filter parent 1: protocol ip pref 99 u32
524 filter parent 1: protocol ip pref 99 u32 \\
526 filter parent 1: protocol ip pref 99 u32 \\
586         match ip src 192.168.0.0/16
596 an IP packet's third byte of the source address field. Along with the
607         match ip src 192.168.8.0/24 classid 1:1
618 one would have to know the kernel-internal algorithm to deduce the destination
639 tc filter add dev eth0 parent 1:0 protocol ip handle 1: \\
641 tc filter add dev eth0 parent 1:0 protocol ip \\
645 tc filter add dev eth0 parent 1:0 protocol ip \\
647         match ip protocol 6 FF \\
648         match ip firstfrag \\
666 sets the offset based on the IP header's IHL field (right-shifting by 6