doc/man: spelling fixes
Use ispell and codespell to find/fix spelling errors in documentation and man pages. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This commit is contained in:
parent
0b9b0d08c2
commit
9d715cf65a
|
|
@ -21,7 +21,7 @@ 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.
|
||||
They are also fully backward compatible. If you have a kernel that doesnt
|
||||
They are also fully backward compatible. If you have a kernel that doesn't
|
||||
understand them, then the effect is null i.e if you have a newer tc
|
||||
but older kernel, the actions are not installed. Likewise if you
|
||||
have a newer kernel but older tc, obviously the tc will use current
|
||||
|
|
@ -31,7 +31,7 @@ right 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 wont 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).
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ iptable target. I have only tested with mangler targets up to now.
|
|||
In terms of hooks:
|
||||
*ingress is mapped to pre-routing hook
|
||||
*egress is mapped to post-routing hook
|
||||
I dont see much value in the other hooks, if you see it and email me good
|
||||
I don't see much value in the other hooks, if you see it and email me good
|
||||
reasons, the addition is trivial.
|
||||
|
||||
Example syntax for iptables targets usage becomes:
|
||||
|
|
@ -111,12 +111,12 @@ 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 doesnt exceed rate, this is where we terminate action execution.
|
||||
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
|
||||
then passed through a second meter.
|
||||
|
||||
-The second meter is shared across all flows on that device [i am suprised
|
||||
-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
|
||||
|
|
@ -145,7 +145,7 @@ u32 match ip src 10.0.0.21/32 flowid 1:15 \
|
|||
action ipt -j mark --set-mark 1 index 2 \
|
||||
#
|
||||
# then pass it through a policer which allows 1kbps; if the flow
|
||||
# doesnt exceed that rate, this is where we stop, if it exceeds we
|
||||
# doesn't exceed that rate, this is where we stop, if it exceeds we
|
||||
# pipe the packet to the next action
|
||||
action police rate 1kbit burst 9k pipe \
|
||||
#
|
||||
|
|
@ -241,7 +241,7 @@ filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
|
|||
Neat, eh?
|
||||
|
||||
|
||||
Wanna write an action module?
|
||||
Want to write an action module?
|
||||
------------------------------
|
||||
Its easy. Either look at the code or send me email. I will document at
|
||||
some point; will also accept documentation.
|
||||
|
|
|
|||
|
|
@ -17,26 +17,26 @@ 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 wanna give
|
||||
preference to your own localy originated traffic (when responses come back)
|
||||
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 achive this was stick
|
||||
comes in as the solution. What people did to achieve this was stick
|
||||
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 wont go back to putting netfilter hooks in the device to satisfy
|
||||
this. I also dont think its worth it hacking ifb some more to be
|
||||
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
|
||||
aware of say L3 info and play ip rule tricks to achieve this.
|
||||
--> Instead the plan is to have a contrack related action. This action will
|
||||
selectively either query/create contrack state on incoming packets.
|
||||
--> 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
|
||||
a different queue than one which didnt have existing state. This
|
||||
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
|
||||
if theres pressure i will add this feature.
|
||||
if there is pressure i will add this feature.
|
||||
|
||||
An example, to provide functionality that most people use IMQ for below:
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ dev ("port" in ethernet switch/bridging terminology)
|
|||
- redirect
|
||||
steals the packet and redirects to specified destination dev.
|
||||
|
||||
What NOT to do if you dont want your machine to crash:
|
||||
What NOT to do if you don't want your machine to crash:
|
||||
------------------------------------------------------
|
||||
|
||||
Do not create loops!
|
||||
Loops are not hard to create in the egress qdiscs.
|
||||
|
||||
Here are simple rules to follow if you dont want to get
|
||||
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!
|
||||
|
|
@ -129,7 +129,7 @@ so you could tcpdump them (dummy by defaults drops all packets it sees).
|
|||
This is a very useful debug feature.
|
||||
|
||||
Lets say you are policing packets from alias 192.168.200.200/32
|
||||
you dont want those to exceed 100kbps going out.
|
||||
you don't want those to exceed 100kbps going out.
|
||||
|
||||
---
|
||||
tc qdisc add dev eth0 handle 1:0 root prio
|
||||
|
|
|
|||
|
|
@ -629,7 +629,7 @@ or the internal FDB should be used.
|
|||
Allows to transport group policy context across VXLAN network peers.
|
||||
If enabled, includes the mark of a packet in the VXLAN header for outgoing
|
||||
packets and fills the packet mark based on the information found in the
|
||||
VXLAN header for incomming packets.
|
||||
VXLAN header for incoming packets.
|
||||
|
||||
Format of upper 16 bits of packet mark (flags);
|
||||
|
||||
|
|
@ -880,7 +880,7 @@ discovery.
|
|||
- enables/disables IPv4 DF suppression on this tunnel.
|
||||
Normally datagrams that exceed the MTU will be fragmented; the presence
|
||||
of the DF flag inhibits this, resulting instead in an ICMP Unreachable
|
||||
(Fragmentation Required) message. Enabling this attribute casues the
|
||||
(Fragmentation Required) message. Enabling this attribute causes the
|
||||
DF flag to be ignored.
|
||||
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ discovery.
|
|||
enable IPv4 DF suppression on this tunnel.
|
||||
Normally datagrams that exceed the MTU will be fragmented; the presence
|
||||
of the DF flag inhibits this, resulting instead in an ICMP Unreachable
|
||||
(Fragmentation Required) message. Enabling this attribute casues the
|
||||
(Fragmentation Required) message. Enabling this attribute causes the
|
||||
DF flag to be ignored.
|
||||
|
||||
.TP
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ Outer header TOS
|
|||
Outer header TTL
|
||||
.TP
|
||||
.RB [ no ] csum
|
||||
Controlls outer UDP checksum. When set to
|
||||
Controls outer UDP checksum. When set to
|
||||
.B csum
|
||||
(which is default), the outer UDP checksum is calculated and included in the
|
||||
packets. When set to
|
||||
|
|
|
|||
Loading…
Reference in New Issue