| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20181218155721.1352-1-sthemmin@microsoft.com>
Date: Tue, 18 Dec 2018 07:57:20 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: netdev@...r.kernel.org
Cc: Stephen Hemminger <sthemmin@...rosoft.com>,
Stephen Hemminger <stephen@...workplumber.org>
Subject: [PATCH iproute2-next 1/2] 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@...workplumber.org>
---
README.iproute2+tc | 2 +-
README.lnstat | 15 +++---
doc/actions/actions-general | 99 ++++++++++++++++++-------------------
doc/actions/gact-usage | 17 +++----
doc/actions/ifb-README | 62 +++++++++++------------
doc/actions/mirred-usage | 26 +++++-----
netem/README.distribution | 2 +-
7 files changed, 110 insertions(+), 113 deletions(-)
diff --git a/README.iproute2+tc b/README.iproute2+tc
index 5979098e6177..e7bb48ce2a68 100644
--- a/README.iproute2+tc
+++ b/README.iproute2+tc
@@ -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.
diff --git a/README.lnstat b/README.lnstat
index 59134a158c3b..eab4088fbfbf 100644
--- a/README.lnstat
+++ b/README.lnstat
@@ -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
diff --git a/doc/actions/actions-general b/doc/actions/actions-general
index 08cc785c4575..407a514ca343 100644
--- a/doc/actions/actions-general
+++ b/doc/actions/actions-general
@@ -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).
-
diff --git a/doc/actions/gact-usage b/doc/actions/gact-usage
index de1308ddfb55..5fc3e6287b3b 100644
--- a/doc/actions/gact-usage
+++ b/doc/actions/gact-usage
@@ -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 )
-----
-
diff --git a/doc/actions/ifb-README b/doc/actions/ifb-README
index 63247f3cdc3e..5fe91714671b 100644
--- a/doc/actions/ifb-README
+++ b/doc/actions/ifb-README
@@ -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@...y action-tests]#
+[root@...y action-tests]#
-----
Now look at some stats:
---
[root@...ndrake]:~# $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@...ndrake]:~# $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@...ndrake]:~# 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)
-----
diff --git a/doc/actions/mirred-usage b/doc/actions/mirred-usage
index e749eedc68a6..482ff66d6aaf 100644
--- a/doc/actions/mirred-usage
+++ b/doc/actions/mirred-usage
@@ -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
diff --git a/netem/README.distribution b/netem/README.distribution
index 23f7ecb73ddd..6d52785407fd 100644
--- a/netem/README.distribution
+++ b/netem/README.distribution
@@ -1,4 +1,4 @@
-Notes about distribution tables from Nistnet
+Notes about distribution tables from Nistnet
-------------------------------------------------------------------------------
I. About the distribution tables
--
2.19.2
Powered by blists - more mailing lists