From patchwork Thu Jan 11 18:44:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 13517713 X-Patchwork-Delegate: stephen@networkplumber.org Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C85053E19 for ; Thu, 11 Jan 2024 18:45:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20230601.gappssmtp.com header.i=@networkplumber-org.20230601.gappssmtp.com header.b="JzV6ieP2" Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-5ca29c131ebso4337916a12.0 for ; Thu, 11 Jan 2024 10:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1704998704; x=1705603504; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=T8BdktxS3T9FnT+KN6r57I70iQkEv8DZXhJrz4qu/0s=; b=JzV6ieP2otY+J8o9qYfKaOiZ37ZioBa7R45rXrGXV1BsnlA4PW1w09ckUG4lfNmS/p wDFLcDUKIXSk3976aJat4AVeCkE95AgixBWiRPpbViW/UHYUa9BXqpx8sOhoJCisQ2Oh gjbYvs98OGzKcnbg23kb9BsXJE+ZvK5Sxvq8709oqQsxnWY2C+1RfpLkKZDNfMAlHVB2 CVtN6f9N6yj8AWn/+mSDEFFU2JR9TUdk7he9f3CFlckf815l2i/NipmcWJQVDt1yKSEW tcA7gYAtf1RNu+0OTjpNNnScNqor+YsR2kkl8mCsofd3MpSfE0Nl8nov01yjFiFJglL/ 3TFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704998704; x=1705603504; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=T8BdktxS3T9FnT+KN6r57I70iQkEv8DZXhJrz4qu/0s=; b=ZcvuKiHnsFccHuRwhKRJXFpWine+AUTmdaheAAh1UYI4O+SN/2VemrVNu8zGJ36fSL Xk3DPq5SiWti3nijZPzerlfSE69fMlO/sv0Q6xz92UF8aIkVqQmHcPNjLQziYEvfw63r 4aXYiqNuS7FjjygFEWmvfRgX36LzE0vq+8VpVY9gFZgZft3Cl5pMyFfFlgvaUAWjm+0f zmkymSTw2LSjBtGxdx/yxouJCcBQvDzfUt1KLgZdlnmefEU2+bfPLkMEcMKKdmunZ18s 22XISbKD9PSqCBn7ZnDpz7n+u+R1etTkaFfGFl0Yw0PgZCVdus6Iuil3gMTaGC62T0io AEHw== X-Gm-Message-State: AOJu0YxWFf3HKE/FRhuim3ouW+EYlXd4VLLqFXmPcx/TWCNXGGdMR9x2 cS4M6N9o3D1N2DOl/PU1vLejrNgYsPdhLJajhTppC47DLCKAmg== X-Google-Smtp-Source: AGHT+IGVNZ/KyFooojyH+QMGKx61wTo+C4dF8eeFYzH0BIb1MICs3+/dj2kp70Ut73/rUN9L3TRyvA== X-Received: by 2002:a05:6a20:7503:b0:199:dab1:8b6e with SMTP id r3-20020a056a20750300b00199dab18b6emr236816pzd.39.1704998703598; Thu, 11 Jan 2024 10:45:03 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id v3-20020aa78083000000b006d9b4303f9csm1513460pff.71.2024.01.11.10.45.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 10:45:02 -0800 (PST) From: Stephen Hemminger To: netdev@vger.kernel.org Cc: Stephen Hemminger Subject: [PATCH iproute2-next 1/4] man: get rid of doc/actions/mirred-usage Date: Thu, 11 Jan 2024 10:44:08 -0800 Message-ID: <20240111184451.48227-2-stephen@networkplumber.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240111184451.48227-1-stephen@networkplumber.org> References: <20240111184451.48227-1-stephen@networkplumber.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: dsahern@gmail.com The only bit of information not already on the man page is some of the limitations. Signed-off-by: Stephen Hemminger --- doc/actions/mirred-usage | 164 --------------------------------------- man/man8/tc-mirred.8 | 8 ++ 2 files changed, 8 insertions(+), 164 deletions(-) delete mode 100644 doc/actions/mirred-usage diff --git a/doc/actions/mirred-usage b/doc/actions/mirred-usage deleted file mode 100644 index 482ff66d6aaf..000000000000 --- a/doc/actions/mirred-usage +++ /dev/null @@ -1,164 +0,0 @@ - -Very funky action. I do plan to add to a few more things to it -This is the basic stuff. Idea borrowed from the way ethernet switches -mirror and redirect packets. The main difference with say a vannila -ethernet switch is that you can use u32 classifier to select a -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: - -mirred [index INDEX] -where: -DIRECTION := -ACTION := -INDEX is the specific policy instance id -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. - -Action: -- Mirror takes a copy of the packet and sends it to specified -dev ("port" in ethernet switch/bridging terminology) -- redirect -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! -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. - -In the future if there are easy ways to do this in the kernel -without affecting other packets not interested in this feature -I will add them. At the moment that is not clear. - -Some examples of bad things NOT to do: -1) redirecting eth0 to eth0 -2) eth0->eth1-> eth0 -3) eth0->lo-> eth1-> eth0 - -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 -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). - -In the case of A) the problem has to do with a recursive contention -for the devices queue lock and in the second case for the transmit lock. - -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 \ -match u32 0 0 flowid 1:2 action mirred egress mirror dev eth1 ---- - -If you replace "mirror" with "redirect" then not a copy but rather -the original packet is sent to eth1. - -2) Host A is hooked up to us on eth0 - -# redirect all packets arriving on ingress of lo to eth0 ---- -tc qdisc add dev lo ingress -tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ -match u32 0 0 flowid 1:2 action mirred egress redirect dev eth0 ---- - -On host A start a tcpdump on interface connecting to us. - -on our host ping -c 2 127.0.0.1 - -Ping would fail since all packets are heading out eth0 -tcpudmp on host A would show them - -if you substitute the redirect with mirror above as in: -tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ -match u32 0 0 flowid 1:2 action mirred egress mirror dev eth0 - -Then you should see the packets on both host A and the local -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 -# host A (Randomness uses the netrand generator) -# ---- -tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ -match u32 0 0 flowid 1:2 \ -action drop random determ ok 10\ -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 -# - ---- -tc qdisc add dev eth0 handle 1:0 root prio -tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \ -match ip src 10.0.0.9/32 flowid 1:16 \ -action police rate 100kbit burst 90k ok \ -action mirred egress mirror dev eth1 ---- - -A more interesting example is when you mirror flows to a dummy device -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 don't want those to exceed 100kbps going out. - ---- -tc qdisc add dev eth0 handle 1:0 root prio -tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \ -match ip src 192.168.200.200/32 flowid 1:2 \ -action police rate 100kbit burst 90k drop ---- - -If you run tcpdump on eth0 you will see all packets going out -with src 192.168.200.200/32 dropped or not (since tcpdump shows -all packets being egressed). -Extend the rule a little to see only the packets making it out. - ---- -tc qdisc add dev eth0 handle 1:0 root prio -tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \ -match ip src 192.168.200.200/32 flowid 1:2 \ -action police rate 10kbit burst 90k drop \ -action mirred egress mirror dev dummy0 ---- - -Now fire tcpdump on dummy0 to see only those packets .. -tcpdump -n -i dummy0 -x -e -t - -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. - -cheers, -jamal diff --git a/man/man8/tc-mirred.8 b/man/man8/tc-mirred.8 index 38833b452d92..71f3c93df472 100644 --- a/man/man8/tc-mirred.8 +++ b/man/man8/tc-mirred.8 @@ -94,6 +94,14 @@ interface, it is possible to send ingress traffic through an instance of .EE .RE +.SH LIMITIATIONS +It is possible to create loops which will cause the kernel to hang. +Do not have the same packet go the same netdevice twice in a single graph of policies. +.PP +Do not redirect for one IFB device to another. +IFB is a very specialized case of packet redirecting device. +Redirecting from ifbX->ifbY will cause all packets to be dropped. + .SH SEE ALSO .BR tc (8), .BR tc-u32 (8) From patchwork Thu Jan 11 18:44:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 13517714 X-Patchwork-Delegate: stephen@networkplumber.org Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 575E553E23 for ; Thu, 11 Jan 2024 18:45:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20230601.gappssmtp.com header.i=@networkplumber-org.20230601.gappssmtp.com header.b="BsEoAtMK" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6d9344f30caso3886313b3a.1 for ; Thu, 11 Jan 2024 10:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1704998704; x=1705603504; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bXiwtsBj02EdK8fJqvGHYuYq6nsBbsRGVOYyO29NQoc=; b=BsEoAtMKWxOL1ZAYv8zk34U9No6axjWxE9h4+rPXueTig2obRecU/Ow27KQ22uvhGG 6QgEtWzwSKCg+rT4CrPjHZllmCoAY6x+baX+4l5mE9M+NaZgKXxexWzVa2ZztYs6b1zc Kr6wPQDYUb+BURSd+1HdXp7JL5SEG3G+XQVZMcFRAS7B+0cT32FOrCo4wdjiqMNWJs5n XUXPTrlGW+o1b7Ew5Nyu837GVO6HQzLazjR0RtPH2NOMvzSkwSGTyEnWxXtvNuB50W0O bI1YZGFQtY8yj5chNoSSeqxzZ1Z/XnFsFOOji+l1tfq3VOwVXL5wWvNwy06PnE1kO36c UYmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704998704; x=1705603504; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bXiwtsBj02EdK8fJqvGHYuYq6nsBbsRGVOYyO29NQoc=; b=CdwjFis58w70hNrBOSA2AgO94O6mbpVb6hTrr67N9yRcBEpEwsyIWVMv2Qnz7Z10Y2 hY8KDbsr9BE1VjsQdoCJ1ENImNyf6oFLzYdXFD8yHaswNc2YUhrQSiHI/qVHFmnoi4BQ bxrl98KovIqVTdcBso1iX6OcMi55V32vgyrVgBF1Ou4imXZ6A/fqNIzEoznzR52+D7i6 foSd3UQhGE/J7KW1UuPh23ITjJkqCIcq2XNJYhjHtCLZAYOrpiHWqyfSF36kxMCls47Q T72q9SvOx8sWYFjZFo9EFOPvTNng/BclOc//KcDKy9xSHN2v9W5aR5JB4QxsoKz1zXIn 75LA== X-Gm-Message-State: AOJu0YwaXdOevisQ3va1tb8hqqSiOhlhBjYHFv0rrXyIO0gnPQDNo/1N wRLVDc2emLQ5lKkMq0jnViaW2kZCKhgMVlR5uyPBzULbUJJgNA== X-Google-Smtp-Source: AGHT+IHVbAQ4PJ7gAD0FSluYsddCIj+BPGRN63XHopXC6g5MV+KJ+ohX+k5g6xAHBL3l78pEh/99rQ== X-Received: by 2002:a05:6a00:92a0:b0:6d9:c201:f887 with SMTP id jw32-20020a056a0092a000b006d9c201f887mr395292pfb.1.1704998704530; Thu, 11 Jan 2024 10:45:04 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id v3-20020aa78083000000b006d9b4303f9csm1513460pff.71.2024.01.11.10.45.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 10:45:03 -0800 (PST) From: Stephen Hemminger To: netdev@vger.kernel.org Cc: Stephen Hemminger Subject: [PATCH iproute2-next 2/4] man/tc-gact: move generic action documentation to man page Date: Thu, 11 Jan 2024 10:44:09 -0800 Message-ID: <20240111184451.48227-3-stephen@networkplumber.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240111184451.48227-1-stephen@networkplumber.org> References: <20240111184451.48227-1-stephen@networkplumber.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: dsahern@gmail.com Convert from free form doc to man page. Signed-off-by: Stephen Hemminger --- doc/actions/gact-usage | 78 -------------------------------------- man/man8/tc-gact.8 | 85 ++++++++++++++++++++++++++++++++++++++++++ man/man8/tc.8 | 1 + 3 files changed, 86 insertions(+), 78 deletions(-) delete mode 100644 doc/actions/gact-usage create mode 100644 man/man8/tc-gact.8 diff --git a/doc/actions/gact-usage b/doc/actions/gact-usage deleted file mode 100644 index 7cf48abbd90a..000000000000 --- a/doc/actions/gact-usage +++ /dev/null @@ -1,78 +0,0 @@ - -gact [RAND] [INDEX] - -Where: - ACTION := reclassify | drop | continue | pass | ok - RAND := random - RANDTYPE := netrand | determ - VAL : = value not exceeding 10000 - INDEX := index value used - -ACTION semantics -- pass and ok are equivalent to accept -- continue allows one to restart classification lookup -- drop drops packets -- reclassify implies continue classification where we left off - -randomization --------------- - -At the moment there are only two algorithms. One is deterministic -and the other uses internal kernel netrand. - -Examples: - -Rules can be installed on both ingress and egress - this shows ingress -only - -tc qdisc add dev eth0 ingress - -# example 1 -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 - -ping -c 20 10.0.0.9 - --- -filter u32 -filter u32 fh 800: ht divisor 1 -filter u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 32 success 20) - match 0a000009/ffffffff at 12 (success 20 ) - action order 1: gact action drop - 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 - ----- -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) - match 0a000009/ffffffff at 12 (success 20 ) - action order 1: gact action drop - 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) - match 0a000009/ffffffff at 12 (success 20 ) - action order 1: gact action drop - random type determ pass val 2 - index 4 ref 1 bind 1 installed 118 sec used 82 sec - Sent 1680 bytes 20 pkts (dropped 10, overlimits 0 ) ------ diff --git a/man/man8/tc-gact.8 b/man/man8/tc-gact.8 new file mode 100644 index 000000000000..81aa30eba5a0 --- /dev/null +++ b/man/man8/tc-gact.8 @@ -0,0 +1,85 @@ +.TH "Generic actions in tc" 8 "11 Jan 2023" "iproute2" "Linux" + +.SH NAME +gact - generic action +.SH SYNOPSIS +.in +8 +.ti -8 +.BR tc " ... " "action gact" +.IR CONTROL " [ " RAND " ] [ " INDEX " ]" +.ti -8 +.IR CONTROL " := { " +.BR reclassify " | " drop " | " continue " | " pass " | " pipe " | " +.br +.BI "goto chain " "CHAIN_INDEX" +| +.br +.BI "jump " "JUMP_COUNT" +} + +.ti -8 +.IR RAND " := " +.BI random " RANDTYPE CONTROL VAL" +.ti -8 +.IR RANDTYPE " := { " +.BR netrand " | " determ " }" +.ti -8 +.IR VAL " := number not exceeding 10000" +.ti -8 +.IR JUMP_COUNT " := absolute jump from start of action list" +.ti -8 +.IR INDEX " := index value used" + +.SH DESCRIPTION +The +.B gact +action allows reclassify, dropping, passing, or accepting packets. +At the moment there are only two algorithms. One is deterministic +and the other uses internal kernel netrand. + +.SH OPTIONS +.TP +.BI random " RANDTYPE CONTROL VAL" +The probability of taking the action expressed in terms of 1 out of +.I VAL +packets. + +.TP +.I CONTROL +Indicate how +.B tc +should proceed if the packet matches. +For a description of the possible +.I CONTROL +values, see +.BR tc-actions (8). + +.SH EXAMPLES +Apply a rule on ingress to drop packets from a given source address. +.RS +.EX +# 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 +.EE +.RE + +Allow 1 out 10 packets from source randomly using the netrand generator +.RS +.EX +# 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 +.EE +.RE + +Deterministically accept every second packet +.RS +.EX +# 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 +.EE +.RE + +.SH SEE ALSO +.BR tc (8), +.BR tc-actions (8), +.BR tc-u32 (8) diff --git a/man/man8/tc.8 b/man/man8/tc.8 index e5bef911f21b..3175454b9d60 100644 --- a/man/man8/tc.8 +++ b/man/man8/tc.8 @@ -871,6 +871,7 @@ was written by Alexey N. Kuznetsov and added in Linux 2.2. .BR tc-fq_codel (8), .BR tc-fq_pie (8), .BR tc-fw (8), +.BR tc-gact (8), .BR tc-hfsc (7), .BR tc-hfsc (8), .BR tc-htb (8), From patchwork Thu Jan 11 18:44:10 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 13517715 X-Patchwork-Delegate: stephen@networkplumber.org Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AF0154673 for ; Thu, 11 Jan 2024 18:45:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20230601.gappssmtp.com header.i=@networkplumber-org.20230601.gappssmtp.com header.b="hpglDGNv" Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-6d9bec20980so3316508b3a.2 for ; Thu, 11 Jan 2024 10:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1704998705; x=1705603505; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pf9YiHke98q12fhK0GUJBdIjwA4/pEcCFP6a3ZKpj3U=; b=hpglDGNvuxhfNDgFh8jPaI7S7OS2OAiAWTgzWANCDTr6fpB4LjWbdbrNMSJDe+E/Ht QI5cKm6pdCuZ7FObeKRrHQ27KqtGU9jqU/hkFPE49xUY1zKNpSAXb1f1kHsHug1f5J0F fROLV719nIqfU0kJTbGFiNU0wJNCneuyw/uGQwgH0Wl4mVB7Z3jaftg5OAlWuG4npTh0 MWwEWNqrDT2llfm/deZ4U4ObSHJoBikfLh/5X5bf4pj3LgqXlkSPz9SHJ9It+vWznsgI zELji9hxFb42tf9LQ/l0MY5kyWWVe5EsspS/bf+AF3+vesg+yvCWl4kFpotL4Zz2J8Qd Dfiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704998705; x=1705603505; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pf9YiHke98q12fhK0GUJBdIjwA4/pEcCFP6a3ZKpj3U=; b=waQb8XixD3eXT25NfMBo8gb+w2YgirA8kAlC1ZhapuhTtmJQEi7/1lKEgVeQV18lb0 RKRKImDRSN1ZSpYrePYKmpkffPKD3GDfR3ogIjCUOXLUtDzpfCGqA6bQZYK4uoLqqQyD kPrdFUd3SHknzuhLJIaLzehQOy9jqRlQxKSPd2WGnjb0a5385LY5T9MKvcdyrlfUuKdg uKRvv2nLMlbthyqoZGzNDpWVmBpHLEto71xtqeeXPomfpy4cmfZZevXHW1YL+BGzL4D1 SJEQLXmTef5clC5HAL6tqUV2C0hNXgdMP2hdOHMFxafm/oFk9U85aS+omCFR/vluZ8qg 6kxg== X-Gm-Message-State: AOJu0YxaT/7PdkHxZqjvUS5TzcQJi5znvQpQ9UpuL9auUmcpZdwo86Rf mLiJBJlLE3G+7f3r2+JkATGQBfngNUW90k9FQnhGMFUSKR1Rcg== X-Google-Smtp-Source: AGHT+IH2OE+oIfz2q/uUuWjT2hEiSqctpJnE2fm22qdFOYtuunLH1gsX2s8dMqof6pMsh+fK/b4WgQ== X-Received: by 2002:a05:6a00:4b10:b0:6d9:bdde:bb1d with SMTP id kq16-20020a056a004b1000b006d9bddebb1dmr166116pfb.69.1704998705322; Thu, 11 Jan 2024 10:45:05 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id v3-20020aa78083000000b006d9b4303f9csm1513460pff.71.2024.01.11.10.45.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 10:45:04 -0800 (PST) From: Stephen Hemminger To: netdev@vger.kernel.org Cc: Stephen Hemminger Subject: [PATCH iproute2-next 3/4] doc: remove ifb README Date: Thu, 11 Jan 2024 10:44:10 -0800 Message-ID: <20240111184451.48227-4-stephen@networkplumber.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240111184451.48227-1-stephen@networkplumber.org> References: <20240111184451.48227-1-stephen@networkplumber.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: dsahern@gmail.com Most of this document goes back to when IFB was first integrated and covers the motivation. Only of historical interest. Signed-off-by: Stephen Hemminger --- doc/actions/ifb-README | 125 ----------------------------------------- 1 file changed, 125 deletions(-) delete mode 100644 doc/actions/ifb-README diff --git a/doc/actions/ifb-README b/doc/actions/ifb-README deleted file mode 100644 index 5fe91714671b..000000000000 --- a/doc/actions/ifb-README +++ /dev/null @@ -1,125 +0,0 @@ - -IFB is intended to replace IMQ. -Advantage over current IMQ; cleaner in particular in in SMP; -with a _lot_ less code. - -Known IMQ/IFB USES ------------------- - -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 -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 -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 -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 -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 -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 there is pressure i will add this feature. - -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 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 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 - -ifconfig ifb0 up - -$TC qdisc add dev eth0 ingress - -# 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 \ -action ipt -j MARK --set-mark 1 \ -action mirred egress redirect dev ifb0 - --------- - - -Run A Little test: - -from another machine ping so that you have packets going into the box: ------ -[root@jzny action-tests]# ping 10.22 -PING 10.22 (10.0.0.22): 56 data bytes -64 bytes from 10.0.0.22: icmp_seq=0 ttl=64 time=2.8 ms -64 bytes from 10.0.0.22: icmp_seq=1 ttl=64 time=0.6 ms -64 bytes from 10.0.0.22: icmp_seq=2 ttl=64 time=0.6 ms - ---- 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]# ------ -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 - 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 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) - -[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 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) - -[root@jmandrake]:~# ifconfig ifb0 -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 - RX bytes:504 (504.0 b) TX bytes:252 (252.0 b) ------ - -You send it any packet not originating from the actions it will drop them. -[In this case the three dropped packets were ipv6 ndisc]. - -cheers, -jamal From patchwork Thu Jan 11 18:44:11 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 13517716 X-Patchwork-Delegate: stephen@networkplumber.org Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0552654F9A for ; Thu, 11 Jan 2024 18:45:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=networkplumber.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20230601.gappssmtp.com header.i=@networkplumber-org.20230601.gappssmtp.com header.b="HNsjMHAT" Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-6d9a795cffbso4219377b3a.0 for ; Thu, 11 Jan 2024 10:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1704998706; x=1705603506; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=gtyMfHbhaGgr3o4nLTjlZj3oa1+iqbMH9OcTY5kK/MQ=; b=HNsjMHATaSVtStYQ0AEvgDlrX2tpCazU59N+iK/8W3wCJ0FLxmT+oQsu5i9oQ6o8Jb k5grMQPI71uyS49d7y4aKTBQdBh+IiNbM+MGkIXVsq5KvooAxqCsL0ioItSUukKwZza0 bf6oIii8skpt6YbJ/GG/4uXvGYrzL3LOmLyeSF4R4YVM1ZJlAwNWdfW63aCcGtZmB3as gL4sIKuEPyWY7UBir4qPF3vvoydfyc01MUpzGsC0pMvPuIJBcqwJe0rXYURi5GfKXYom z5LQXNyQbxOiQhnjpeB2QCV5fS+UNT7nCc3lYBr4iRx+A5sbItonnbiQLYXJ6q4W7Aw4 oDdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704998706; x=1705603506; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gtyMfHbhaGgr3o4nLTjlZj3oa1+iqbMH9OcTY5kK/MQ=; b=atq426nXfe37Xz3tivsdzPdOnPoz8fSQjjhLdI19x6yV1L1rLeRJyM/8LRogifS3Lf nmqljt1MzSvc8SMGXjKXEppE4zlkHhq0Wt8B3NrNdpuh/0arWz9Rh0rq2Q0FJJNKFEGN hiZ074lZA5GFSnRdu0KYXd2rLS1/DqI3DkE+QE5ahtkpdqwmqGPKI9qy56TspZO0frCI cTJedy9Bt1JwMvzzcGddfQr26GA4Gu6xS1+yWR68sfWywrsJvQWbrF2frZMiLizBLQSn 70fcqLE5/kAqc6WxBXsIk9srxoQ91XTbCgnVAeCqquro9y64vU8WT28j37StTXlyN7z3 Y8mg== X-Gm-Message-State: AOJu0YwMDmRa+S9SpD28nmd6mi8zH8II9PnJbmxfuyXOOhEUSy547507 UQXpGl8BkdPtRP/Zfr2MRb41lzc2KO6NPYG/36FWdoiAX1Jc6g== X-Google-Smtp-Source: AGHT+IGcMmaDycSWbJknsOLNwvwHqLZrAYcaAEkyoFOotCmfpJS8+JUXpfu7IkNqOhRoRzcX+EPIRg== X-Received: by 2002:a62:5486:0:b0:6da:ed17:bfa7 with SMTP id i128-20020a625486000000b006daed17bfa7mr379316pfb.6.1704998706190; Thu, 11 Jan 2024 10:45:06 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id v3-20020aa78083000000b006d9b4303f9csm1513460pff.71.2024.01.11.10.45.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 10:45:05 -0800 (PST) From: Stephen Hemminger To: netdev@vger.kernel.org Cc: Stephen Hemminger Subject: [PATCH iproute2-next 4/4] doc: remove out dated actions-general Date: Thu, 11 Jan 2024 10:44:11 -0800 Message-ID: <20240111184451.48227-5-stephen@networkplumber.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240111184451.48227-1-stephen@networkplumber.org> References: <20240111184451.48227-1-stephen@networkplumber.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: dsahern@gmail.com This file is rather free form, out dated, and redundant. Everything here should be covered on man pages. Signed-off-by: Stephen Hemminger --- doc/actions/actions-general | 256 ------------------------------------ 1 file changed, 256 deletions(-) delete mode 100644 doc/actions/actions-general diff --git a/doc/actions/actions-general b/doc/actions/actions-general deleted file mode 100644 index a0074a58c653..000000000000 --- a/doc/actions/actions-general +++ /dev/null @@ -1,256 +0,0 @@ - -This documented is slightly dated but should give you idea of how things -work. - -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. -i.e you could say something like: - ------ -tc filter add dev lo parent ffff: protocol ip prio 10 u32 match ip src \ -127.0.0.1/32 flowid 1:1 police mtu 4000 rate 1500kbit burst 90k ------ - -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 -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 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 -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. -Essentially this is now an alternative to iptables. -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). - -This stuff works on both ingress and egress qdiscs. - -Features --------- - -1) new additional syntax and actions enabled. Note old syntax is still valid. - -Essentially this is still the same syntax as tc with a new construct -"action". The syntax is of the form: -tc filter add parent 1:0 protocol ip prio 10 -flowid 1:1 action * - -You can have as many actions as you want (within sensible reasoning). - -In the past the only real action was the policer; i.e you could do something -along the lines of: -tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ -match ip src 127.0.0.1/32 flowid 1:1 \ -police mtu 4000 rate 1500kbit burst 90k - -Although you can still use the same syntax, now you can say: - -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: -{ 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 -+pass and ok (are equivalent) says to accept it -+reclassify requests for reclassification of the packet -+continue requests for next lookup to match - -2)In order to take advantage of some of the targets written by the -iptables people, a classifier can have a packet being massaged by an -iptable target. I have only tested with mangler targets up to now. -(in fact anything that is not in the mangling table is disabled right now) - -In terms of hooks: -*ingress is mapped to pre-routing hook -*egress is mapped to post-routing hook -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: -tc filter add ..... u32 action ipt -j - -example: -tc filter add dev lo parent ffff: protocol ip prio 8 u32 \ -match ip dst 127.0.0.8/32 flowid 1:12 \ -action ipt -j mark --set-mark 2 - -NOTE: flowid 1:12 is parsed flowid 0x1:0x12. Make sure if you want flowid -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 -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); - -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); - -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 -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 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 -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 -or more interesting things on the egress. - ------------------- cut here ------------------------------- -# -# Add an ingress qdisc on eth0 -tc qdisc add dev eth0 ingress -# -#if you see an incoming packet from 10.0.0.21 -tc filter add dev eth0 parent ffff: protocol ip prio 1 \ -u32 match ip src 10.0.0.21/32 flowid 1:15 \ -# -# first give it a mark of 1 -action ipt -j mark --set-mark 1 index 2 \ -# -# then pass it through a policer which allows 1kbps; if the flow -# 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 \ -# -# which marks the packet fwmark as 2 and pipes -action ipt -j mark --set-mark 2 \ -# -# next attempt to borrow b/width from a meter -# used across all flows incoming on eth0("index 30") -# and if that is exceeded we pipe to the next action -action police index 30 mtu 5000 rate 1kbit burst 10k pipe \ -# mark it as fwmark 3 if exceeded -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 -"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 - - 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 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 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 - - match 0a000015/ffffffff at 12 -------------------------------- - -Note the ordering of the actions is based on the order in which we entered -them. In the future i will add explicit priorities. - -Now lets run a ping -f from 10.0.0.21 to this host; stop the ping after -you see a few lines of dots - ----- -[root@jzny hadi]# ping -f 10.0.0.22 -PING 10.0.0.22 (10.0.0.22): 56 data bytes -.................................................................................................................................................................................................................................................................................................................................................................................................................................................... ---- 10.0.0.22 ping statistics --- -2248 packets transmitted, 1811 packets received, 19% packet loss -round-trip min/avg/max = 0.7/9.3/20.1 ms ------------------------------ - -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 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 -5 - - 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) - - 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 - target MARK set 0x2 index 1 - 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 5: tablename: mangle hook: NF_IP_PRE_ROUTING - target MARK set 0x3 index 3 - 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) - - match 0a000015/ffffffff at 12 -------------------------------- - -Neat, eh? - - -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. - -TODO ----- - -Lotsa goodies/features coming. Requests also being accepted. -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).