doc: remove trailing whitespace
Run whitespace scrubbing script to remove unnecessary trailing blanks at end of line and end of file. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David Ahern <dsahern@gmail.com>
This commit is contained in:
Stephen Hemminger
committed by
David Ahern
David Ahern
parent
6065ddfaa7
commit
e5cd5a51f9
@@ -42,7 +42,7 @@ in rsvp/cbqinit.eth1.
|
||||
|
||||
|
||||
Terminology and advices about setting CBQ parameters may be found in Sally Floyd
|
||||
papers.
|
||||
papers.
|
||||
|
||||
|
||||
Pairs X:Y are class handles, X:0 are qdisc handles.
|
||||
|
||||
@@ -7,8 +7,8 @@ This tool is a generalized and more feature-complete replacement for the old
|
||||
|
||||
In addition to routing cache statistics, it supports any kind of statistics
|
||||
the linux kernel exports via a file in /proc/net/stat. In a stock 2.6.9
|
||||
kernel, this is
|
||||
per-protocol neighbour cache statistics
|
||||
kernel, this is
|
||||
per-protocol neighbour cache statistics
|
||||
(ipv4, ipv6, atm)
|
||||
routing cache statistics
|
||||
(ipv4)
|
||||
@@ -29,7 +29,7 @@ In order to get a list of supported statistics files, you can run
|
||||
lnstat -d
|
||||
|
||||
It will display something like
|
||||
|
||||
|
||||
/proc/net/stat/arp_cache:
|
||||
1: entries
|
||||
2: allocs
|
||||
@@ -52,19 +52,19 @@ arp_cach|rt_cache|arp_cach|
|
||||
|
||||
|
||||
You can specify the interval (e.g. 10 seconds) by:
|
||||
|
||||
|
||||
lnstat -i 10
|
||||
|
||||
You can specify to only use one particular statistics file:
|
||||
|
||||
lnstat -f ip_conntrack
|
||||
|
||||
You can specify individual field widths
|
||||
You can specify individual field widths
|
||||
|
||||
lnstat -k arp_cache:entries,rt_cache:entries -w 20,8
|
||||
|
||||
You can specify not to print a header at all
|
||||
|
||||
|
||||
lnstat -s 0
|
||||
|
||||
You can specify to print a header only at start of the program
|
||||
@@ -76,6 +76,5 @@ You can specify to print a header at start and every 20 lines:
|
||||
lnstat -s 20
|
||||
|
||||
You can specify the number of samples you want to take (e.g. 5):
|
||||
|
||||
lnstat -c 5
|
||||
|
||||
lnstat -c 5
|
||||
|
||||
@@ -6,8 +6,8 @@ What is it?
|
||||
-----------
|
||||
|
||||
An extension to the filtering/classification architecture of Linux Traffic
|
||||
Control.
|
||||
Up to 2.6.8 the only action that could be "attached" to a filter was policing.
|
||||
Control.
|
||||
Up to 2.6.8 the only action that could be "attached" to a filter was policing.
|
||||
i.e you could say something like:
|
||||
|
||||
-----
|
||||
@@ -17,7 +17,7 @@ tc filter add dev lo parent ffff: protocol ip prio 10 u32 match ip src \
|
||||
|
||||
which implies "if a packet is seen on the ingress of the lo device with
|
||||
a source IP address of 127.0.0.1/32 we give it a classification id of 1:1 and
|
||||
we execute a policing action which rate limits its bandwidth utilization
|
||||
we execute a policing action which rate limits its bandwidth utilization
|
||||
to 1.5Mbps".
|
||||
|
||||
The new extensions allow for more than just policing actions to be added.
|
||||
@@ -29,9 +29,9 @@ syntax which will work fine. Of course to get the required effect you need
|
||||
both newer tc and kernel. If you are reading this you have the
|
||||
right tc ;->
|
||||
|
||||
A side effect is that we can now get stateless firewalling to work with tc.
|
||||
A side effect is that we can now get stateless firewalling to work with tc.
|
||||
Essentially this is now an alternative to iptables.
|
||||
I won't go into details of my dislike for iptables at times, but
|
||||
I won't go into details of my dislike for iptables at times, but
|
||||
scalability is one of the main issues; however, if you need stateful
|
||||
classification - use netfilter (for now).
|
||||
|
||||
@@ -61,7 +61,7 @@ tc filter add dev lo parent 1:0 protocol ip prio 10 u32 \
|
||||
match ip src 127.0.0.1/32 flowid 1:1 \
|
||||
action police mtu 4000 rate 1500kbit burst 90k
|
||||
|
||||
" generic Actions" (gact) at the moment are:
|
||||
" generic Actions" (gact) at the moment are:
|
||||
{ drop, pass, reclassify, continue}
|
||||
(If you have others, no listed here give me a reason and we will add them)
|
||||
+drop says to drop the packet
|
||||
@@ -93,43 +93,43 @@ decimal 12, then use flowid 1:c.
|
||||
|
||||
3) A feature i call pipe
|
||||
The motivation is derived from Unix pipe mechanism but applied to packets.
|
||||
Essentially take a matching packet and pass it through
|
||||
Essentially take a matching packet and pass it through
|
||||
action1 | action2 | action3 etc.
|
||||
You could do something similar to this with the tc policer and the "continue"
|
||||
operator but this rather restricts it to just the policer and requires
|
||||
multiple rules (and lookups, hence quiet inefficient);
|
||||
operator but this rather restricts it to just the policer and requires
|
||||
multiple rules (and lookups, hence quiet inefficient);
|
||||
|
||||
as an example -- and please note that this is just an example _not_ The
|
||||
as an example -- and please note that this is just an example _not_ The
|
||||
Word Youve Been Waiting For (yes i have had problems giving examples
|
||||
which ended becoming dogma in documents and people modifying them a little
|
||||
to look clever);
|
||||
to look clever);
|
||||
|
||||
i selected the metering rates to be small so that i can show better how
|
||||
i selected the metering rates to be small so that i can show better how
|
||||
things work.
|
||||
|
||||
The script below does the following:
|
||||
- an incoming packet from 10.0.0.21 is first given a firewall mark of 1.
|
||||
|
||||
- It is then metered to make sure it does not exceed its allocated rate of
|
||||
The script below does the following:
|
||||
- an incoming packet from 10.0.0.21 is first given a firewall mark of 1.
|
||||
|
||||
- It is then metered to make sure it does not exceed its allocated rate of
|
||||
1Kbps. If it doesn't exceed rate, this is where we terminate action execution.
|
||||
|
||||
- If it does exceed its rate, its "color" changes to a mark of 2 and it is
|
||||
- If it does exceed its rate, its "color" changes to a mark of 2 and it is
|
||||
then passed through a second meter.
|
||||
|
||||
-The second meter is shared across all flows on that device [i am surpised
|
||||
that this seems to be not a well know feature of the policer; Bert was telling
|
||||
-The second meter is shared across all flows on that device [i am surpised
|
||||
that this seems to be not a well know feature of the policer; Bert was telling
|
||||
me that someone was writing a qdisc just to do sharing across multiple devices;
|
||||
it must be the summer heat again; weve had someone doing that every year around
|
||||
summer -- the key to sharing is to use a operator "index" in your policer
|
||||
rules (example "index 20"). All your rules have to use the same index to
|
||||
summer -- the key to sharing is to use a operator "index" in your policer
|
||||
rules (example "index 20"). All your rules have to use the same index to
|
||||
share.]
|
||||
|
||||
|
||||
-If the second meter is exceeded the color of the flow changes further to 3.
|
||||
|
||||
-We then pass the packet to another meter which is shared across all devices
|
||||
in the system. If this meter is exceeded we drop the packet.
|
||||
|
||||
Note the mark can be used further up the system to do things like policy
|
||||
Note the mark can be used further up the system to do things like policy
|
||||
or more interesting things on the egress.
|
||||
|
||||
------------------ cut here -------------------------------
|
||||
@@ -161,31 +161,31 @@ action ipt -j mark --set-mark 3 \
|
||||
# and then attempt to borrow from a meter used by all devices in the
|
||||
# system. Should this be exceeded, drop the packet on the floor.
|
||||
action police index 20 mtu 5000 rate 1kbit burst 90k drop
|
||||
---------------------------------
|
||||
---------------------------------
|
||||
|
||||
Now lets see the actions installed with
|
||||
Now lets see the actions installed with
|
||||
"tc filter show parent ffff: dev eth0"
|
||||
|
||||
-------- output -----------
|
||||
jroot# tc filter show parent ffff: dev eth0
|
||||
filter protocol ip pref 1 u32
|
||||
filter protocol ip pref 1 u32 fh 800: ht divisor 1
|
||||
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:15
|
||||
filter protocol ip pref 1 u32
|
||||
filter protocol ip pref 1 u32 fh 800: ht divisor 1
|
||||
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:15
|
||||
|
||||
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x1 index 2
|
||||
|
||||
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
|
||||
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
|
||||
|
||||
action order 3: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
action order 3: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x2 index 1
|
||||
|
||||
action order 4: police 30 action pipe rate 1Kbit burst 10Kb mtu 5000b
|
||||
action order 4: police 30 action pipe rate 1Kbit burst 10Kb mtu 5000b
|
||||
|
||||
action order 5: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
action order 5: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x3 index 3
|
||||
|
||||
action order 6: police 20 action drop rate 1Kbit burst 90Kb mtu 5000b
|
||||
action order 6: police 20 action drop rate 1Kbit burst 90Kb mtu 5000b
|
||||
|
||||
match 0a000015/ffffffff at 12
|
||||
-------------------------------
|
||||
@@ -209,31 +209,31 @@ Now lets take a look at the stats with "tc -s filter show parent ffff: dev eth0"
|
||||
|
||||
--------------
|
||||
jroot# tc -s filter show parent ffff: dev eth0
|
||||
filter protocol ip pref 1 u32
|
||||
filter protocol ip pref 1 u32 fh 800: ht divisor 1
|
||||
filter protocol ip pref 1 u32
|
||||
filter protocol ip pref 1 u32 fh 800: ht divisor 1
|
||||
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
|
||||
5
|
||||
5
|
||||
|
||||
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x1 index 2
|
||||
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 0)
|
||||
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 0)
|
||||
|
||||
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
|
||||
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 2122)
|
||||
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
|
||||
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 2122)
|
||||
|
||||
action order 3: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
action order 3: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x2 index 1
|
||||
Sent 178248 bytes 2122 pkts (dropped 0, overlimits 0)
|
||||
Sent 178248 bytes 2122 pkts (dropped 0, overlimits 0)
|
||||
|
||||
action order 4: police 30 action pipe rate 1Kbit burst 10Kb mtu 5000b
|
||||
Sent 178248 bytes 2122 pkts (dropped 0, overlimits 1945)
|
||||
action order 4: police 30 action pipe rate 1Kbit burst 10Kb mtu 5000b
|
||||
Sent 178248 bytes 2122 pkts (dropped 0, overlimits 1945)
|
||||
|
||||
action order 5: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
action order 5: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x3 index 3
|
||||
Sent 163380 bytes 1945 pkts (dropped 0, overlimits 0)
|
||||
Sent 163380 bytes 1945 pkts (dropped 0, overlimits 0)
|
||||
|
||||
action order 6: police 20 action drop rate 1Kbit burst 90Kb mtu 5000b
|
||||
Sent 163380 bytes 1945 pkts (dropped 0, overlimits 437)
|
||||
action order 6: police 20 action drop rate 1Kbit burst 90Kb mtu 5000b
|
||||
Sent 163380 bytes 1945 pkts (dropped 0, overlimits 437)
|
||||
|
||||
match 0a000015/ffffffff at 12
|
||||
-------------------------------
|
||||
@@ -254,4 +254,3 @@ At the moment the focus has been on getting the architecture in place.
|
||||
Expect new things in the spurious time i have to work on this
|
||||
(particularly around end of year when i have typically get time off
|
||||
from work).
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
|
||||
gact <ACTION> [RAND] [INDEX]
|
||||
|
||||
Where:
|
||||
ACTION := reclassify | drop | continue | pass | ok
|
||||
Where:
|
||||
ACTION := reclassify | drop | continue | pass | ok
|
||||
RAND := random <RANDTYPE> <ACTION> <VAL>
|
||||
RANDTYPE := netrand | determ
|
||||
VAL : = value not exceeding 10000
|
||||
INDEX := index value used
|
||||
|
||||
|
||||
ACTION semantics
|
||||
- pass and ok are equivalent to accept
|
||||
- continue allows to restart classification lookup
|
||||
@@ -42,14 +42,14 @@ filter u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 32 suc
|
||||
random type none pass val 0
|
||||
index 1 ref 1 bind 1 installed 59 sec used 35 sec
|
||||
Sent 1680 bytes 20 pkts (dropped 20, overlimits 0 )
|
||||
|
||||
|
||||
----
|
||||
|
||||
# example 2
|
||||
#allow 1 out 10 randomly using the netrand generator
|
||||
tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 match ip src \
|
||||
10.0.0.9/32 flowid 1:16 action drop random netrand ok 10
|
||||
|
||||
|
||||
ping -c 20 10.0.0.9
|
||||
|
||||
----
|
||||
@@ -59,14 +59,14 @@ filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1
|
||||
random type netrand pass val 10
|
||||
index 5 ref 1 bind 1 installed 49 sec used 25 sec
|
||||
Sent 1680 bytes 20 pkts (dropped 16, overlimits 0 )
|
||||
|
||||
|
||||
--------
|
||||
#alternative: deterministically accept every second packet
|
||||
tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 match ip src \
|
||||
10.0.0.9/32 flowid 1:16 action drop random determ ok 2
|
||||
|
||||
|
||||
ping -c 20 10.0.0.9
|
||||
|
||||
|
||||
tc -s filter show parent ffff: dev eth0
|
||||
-----
|
||||
filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 20 success 20)
|
||||
@@ -76,4 +76,3 @@ filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1
|
||||
index 4 ref 1 bind 1 installed 118 sec used 82 sec
|
||||
Sent 1680 bytes 20 pkts (dropped 10, overlimits 0 )
|
||||
-----
|
||||
|
||||
|
||||
@@ -6,18 +6,18 @@ with a _lot_ less code.
|
||||
Known IMQ/IFB USES
|
||||
------------------
|
||||
|
||||
As far as i know the reasons listed below is why people use IMQ.
|
||||
As far as i know the reasons listed below is why people use IMQ.
|
||||
It would be nice to know of anything else that i missed.
|
||||
|
||||
1) qdiscs/policies that are per device as opposed to system wide.
|
||||
IFB allows for sharing.
|
||||
|
||||
2) Allows for queueing incoming traffic for shaping instead of
|
||||
dropping. I am not aware of any study that shows policing is
|
||||
dropping. I am not aware of any study that shows policing is
|
||||
worse than shaping in achieving the end goal of rate control.
|
||||
I would be interested if anyone is experimenting.
|
||||
|
||||
3) Very interesting use: if you are serving p2p you may want to give
|
||||
3) Very interesting use: if you are serving p2p you may want to give
|
||||
preference to your own locally originated traffic (when responses come back)
|
||||
vs someone using your system to do bittorent. So QoSing based on state
|
||||
comes in as the solution. What people did to achieve this was stick
|
||||
@@ -25,17 +25,17 @@ the IMQ somewhere prelocal hook.
|
||||
I think this is a pretty neat feature to have in Linux in general.
|
||||
(i.e not just for IMQ).
|
||||
But i won't go back to putting netfilter hooks in the device to satisfy
|
||||
this. I also don't think its worth it hacking ifb some more to be
|
||||
this. I also don't think its worth it hacking ifb some more to be
|
||||
aware of say L3 info and play ip rule tricks to achieve this.
|
||||
--> Instead the plan is to have a conntrack related action. This action will
|
||||
selectively either query/create conntrack state on incoming packets.
|
||||
Packets could then be redirected to ifb based on what happens -> eg
|
||||
on incoming packets; if we find they are of known state we could send to
|
||||
selectively either query/create conntrack state on incoming packets.
|
||||
Packets could then be redirected to ifb based on what happens -> eg
|
||||
on incoming packets; if we find they are of known state we could send to
|
||||
a different queue than one which didn't have existing state. This
|
||||
all however is dependent on whatever rules the admin enters.
|
||||
|
||||
At the moment this 3rd function does not exist yet. I have decided that
|
||||
instead of sitting on the patch for another year, to release it and then
|
||||
instead of sitting on the patch for another year, to release it and then
|
||||
if there is pressure i will add this feature.
|
||||
|
||||
An example, to provide functionality that most people use IMQ for below:
|
||||
@@ -43,10 +43,10 @@ An example, to provide functionality that most people use IMQ for below:
|
||||
--------
|
||||
export TC="/sbin/tc"
|
||||
|
||||
$TC qdisc add dev ifb0 root handle 1: prio
|
||||
$TC qdisc add dev ifb0 root handle 1: prio
|
||||
$TC qdisc add dev ifb0 parent 1:1 handle 10: sfq
|
||||
$TC qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
|
||||
$TC qdisc add dev ifb0 parent 1:3 handle 30: sfq
|
||||
$TC qdisc add dev ifb0 parent 1:3 handle 30: sfq
|
||||
$TC filter add dev ifb0 protocol ip pref 1 parent 1: handle 1 fw classid 1:1
|
||||
$TC filter add dev ifb0 protocol ip pref 2 parent 1: handle 2 fw classid 1:2
|
||||
|
||||
@@ -54,7 +54,7 @@ ifconfig ifb0 up
|
||||
|
||||
$TC qdisc add dev eth0 ingress
|
||||
|
||||
# redirect all IP packets arriving in eth0 to ifb0
|
||||
# redirect all IP packets arriving in eth0 to ifb0
|
||||
# use mark 1 --> puts them onto class 1:1
|
||||
$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
|
||||
match u32 0 0 flowid 1:1 \
|
||||
@@ -77,44 +77,44 @@ PING 10.22 (10.0.0.22): 56 data bytes
|
||||
--- 10.22 ping statistics ---
|
||||
3 packets transmitted, 3 packets received, 0% packet loss
|
||||
round-trip min/avg/max = 0.6/1.3/2.8 ms
|
||||
[root@jzny action-tests]#
|
||||
[root@jzny action-tests]#
|
||||
-----
|
||||
Now look at some stats:
|
||||
|
||||
---
|
||||
[root@jmandrake]:~# $TC -s filter show parent ffff: dev eth0
|
||||
filter protocol ip pref 10 u32
|
||||
filter protocol ip pref 10 u32 fh 800: ht divisor 1
|
||||
filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
|
||||
filter protocol ip pref 10 u32
|
||||
filter protocol ip pref 10 u32 fh 800: ht divisor 1
|
||||
filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
|
||||
match 00000000/00000000 at 0
|
||||
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x1
|
||||
index 1 ref 1 bind 1 installed 4195sec used 27sec
|
||||
Sent 252 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
|
||||
target MARK set 0x1
|
||||
index 1 ref 1 bind 1 installed 4195sec used 27sec
|
||||
Sent 252 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
|
||||
action order 2: mirred (Egress Redirect to device ifb0) stolen
|
||||
index 1 ref 1 bind 1 installed 165 sec used 27 sec
|
||||
Sent 252 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
Sent 252 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
|
||||
[root@jmandrake]:~# $TC -s qdisc
|
||||
qdisc sfq 30: dev ifb0 limit 128p quantum 1514b
|
||||
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
|
||||
qdisc tbf 20: dev ifb0 rate 20Kbit burst 1575b lat 2147.5s
|
||||
Sent 210 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
qdisc sfq 10: dev ifb0 limit 128p quantum 1514b
|
||||
Sent 294 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
qdisc sfq 30: dev ifb0 limit 128p quantum 1514b
|
||||
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
|
||||
qdisc tbf 20: dev ifb0 rate 20Kbit burst 1575b lat 2147.5s
|
||||
Sent 210 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
qdisc sfq 10: dev ifb0 limit 128p quantum 1514b
|
||||
Sent 294 bytes 3 pkts (dropped 0, overlimits 0)
|
||||
qdisc prio 1: dev ifb0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
|
||||
Sent 504 bytes 6 pkts (dropped 0, overlimits 0)
|
||||
qdisc ingress ffff: dev eth0 ----------------
|
||||
Sent 308 bytes 5 pkts (dropped 0, overlimits 0)
|
||||
Sent 504 bytes 6 pkts (dropped 0, overlimits 0)
|
||||
qdisc ingress ffff: dev eth0 ----------------
|
||||
Sent 308 bytes 5 pkts (dropped 0, overlimits 0)
|
||||
|
||||
[root@jmandrake]:~# ifconfig ifb0
|
||||
ifb0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
|
||||
ifb0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
|
||||
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
|
||||
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
|
||||
RX packets:6 errors:0 dropped:3 overruns:0 frame:0
|
||||
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
|
||||
collisions:0 txqueuelen:32
|
||||
collisions:0 txqueuelen:32
|
||||
RX bytes:504 (504.0 b) TX bytes:252 (252.0 b)
|
||||
-----
|
||||
|
||||
|
||||
@@ -7,10 +7,10 @@ flow to be mirrored. High end switches typically can select based
|
||||
on more than just a port (eg a 5 tuple classifier). They may also be
|
||||
capable of redirecting.
|
||||
|
||||
Usage:
|
||||
Usage:
|
||||
|
||||
mirred <DIRECTION> <ACTION> [index INDEX] <dev DEVICENAME>
|
||||
where:
|
||||
mirred <DIRECTION> <ACTION> [index INDEX] <dev DEVICENAME>
|
||||
where:
|
||||
DIRECTION := <ingress | egress>
|
||||
ACTION := <mirror | redirect>
|
||||
INDEX is the specific policy instance id
|
||||
@@ -18,7 +18,7 @@ DEVICENAME is the devicename
|
||||
|
||||
Direction:
|
||||
- Ingress is not supported at the moment. It will be in the
|
||||
future as well as mirror/redirecting to a socket.
|
||||
future as well as mirror/redirecting to a socket.
|
||||
|
||||
Action:
|
||||
- Mirror takes a copy of the packet and sends it to specified
|
||||
@@ -29,14 +29,14 @@ steals the packet and redirects to specified destination dev.
|
||||
What NOT to do if you don't want your machine to crash:
|
||||
------------------------------------------------------
|
||||
|
||||
Do not create loops!
|
||||
Do not create loops!
|
||||
Loops are not hard to create in the egress qdiscs.
|
||||
|
||||
Here are simple rules to follow if you don't want to get
|
||||
hurt:
|
||||
A) Do not have the same packet go to same netdevice twice
|
||||
in a single graph of policies. Your machine will just hang!
|
||||
This is design intent _not a bug_ to teach you some lessons.
|
||||
This is design intent _not a bug_ to teach you some lessons.
|
||||
|
||||
In the future if there are easy ways to do this in the kernel
|
||||
without affecting other packets not interested in this feature
|
||||
@@ -51,7 +51,7 @@ B) Do not redirect from one IFB device to another.
|
||||
Remember that IFB is a very specialized case of packet redirecting
|
||||
device. Instead of redirecting it puts packets at the exact spot
|
||||
on the stack it found them from.
|
||||
Redirecting from ifbX->ifbY will actually not crash your machine but your
|
||||
Redirecting from ifbX->ifbY will actually not crash your machine but your
|
||||
packets will all be dropped (this is much simpler to detect
|
||||
and resolve and is only affecting users of ifb as opposed to the
|
||||
whole stack).
|
||||
@@ -64,7 +64,7 @@ Some examples:
|
||||
|
||||
1) Mirror all packets arriving on eth0 to be sent out on eth1.
|
||||
You may have a sniffer or some accounting box hooked up on eth1.
|
||||
|
||||
|
||||
---
|
||||
tc qdisc add dev eth0 ingress
|
||||
tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
|
||||
@@ -100,7 +100,7 @@ stack (i.e ping would work).
|
||||
3) Even more funky example:
|
||||
|
||||
#
|
||||
#allow 1 out 10 packets on ingress of lo to randomly make it to the
|
||||
#allow 1 out 10 packets on ingress of lo to randomly make it to the
|
||||
# host A (Randomness uses the netrand generator)
|
||||
#
|
||||
---
|
||||
@@ -111,9 +111,9 @@ action mirred egress mirror dev eth0
|
||||
---
|
||||
|
||||
4)
|
||||
# for packets from 10.0.0.9 going out on eth0 (could be local
|
||||
# IP or something # we are forwarding) -
|
||||
# if exceeding a 100Kbps rate, then redirect to eth1
|
||||
# for packets from 10.0.0.9 going out on eth0 (could be local
|
||||
# IP or something # we are forwarding) -
|
||||
# if exceeding a 100Kbps rate, then redirect to eth1
|
||||
#
|
||||
|
||||
---
|
||||
@@ -158,7 +158,7 @@ Essentially a good debugging/logging interface (sort of like
|
||||
BSDs speacialized log device does without needing one).
|
||||
|
||||
If you replace mirror with redirect, those packets will be
|
||||
blackholed and will never make it out.
|
||||
blackholed and will never make it out.
|
||||
|
||||
cheers,
|
||||
jamal
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Notes about distribution tables from Nistnet
|
||||
Notes about distribution tables from Nistnet
|
||||
-------------------------------------------------------------------------------
|
||||
I. About the distribution tables
|
||||
|
||||
|
||||
Reference in New Issue
Block a user