From patchwork Thu Aug 10 17:29:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Phil Sutter X-Patchwork-Id: 800285 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xSwBP3b5Tz9s82 for ; Fri, 11 Aug 2017 03:30:05 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753146AbdHJRaE (ORCPT ); Thu, 10 Aug 2017 13:30:04 -0400 Received: from orbyte.nwl.cc ([151.80.46.58]:35289 "EHLO mail.nwl.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753145AbdHJRaE (ORCPT ); Thu, 10 Aug 2017 13:30:04 -0400 Received: from mail.nwl.cc (orbyte.nwl.cc [127.0.0.1]) by mail.nwl.cc (Postfix) with ESMTP id 22AE3681D7; Thu, 10 Aug 2017 19:30:03 +0200 (CEST) Received: from xsao (localhost [IPv6:::1]) by mail.nwl.cc (Postfix) with ESMTP id 05EDF681C4; Thu, 10 Aug 2017 19:30:03 +0200 (CEST) From: Phil Sutter To: Pablo Neira Ayuso Cc: netfilter-devel@vger.kernel.org Subject: [nft PATCH 5/6] nft.8: Describe base chain details Date: Thu, 10 Aug 2017 19:29:19 +0200 Message-Id: <20170810172920.14893-6-phil@nwl.cc> X-Mailer: git-send-email 2.13.1 In-Reply-To: <20170810172920.14893-1-phil@nwl.cc> References: <20170810172920.14893-1-phil@nwl.cc> X-Virus-Scanned: ClamAV using ClamSMTP Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org This mostly covers base chain types, but also tries to clarify meaning of priority values, chain policy and the ominous device parameter. Command synopsis is adjusted as well to point out which parts of a base chain definition are optional and which are not. Signed-off-by: Phil Sutter --- doc/nft.xml | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 85 insertions(+), 9 deletions(-) diff --git a/doc/nft.xml b/doc/nft.xml index 00095ddafcdad..73ef4d18f462f 100644 --- a/doc/nft.xml +++ b/doc/nft.xml @@ -616,20 +616,26 @@ filter input iif $int_ifs accept Chains - add + + add + create + chain family - table - chain - hook - priority - policy - device + table + chain + + + type + hook + device + priority + + policy + - add - create delete list flush @@ -710,6 +716,76 @@ filter input iif $int_ifs accept + + + For base chains, type, hook and priority parameters are mandatory. + + + + Supported chain types + + + + + + + + Type + Families + Hooks + Description + + + + + filter + all + all + Standard chain type to use in doubt. + + + nat + ip, ip6 + prerouting, input, output, postrouting + Chains of this type perform Native Address Translation based on conntrack entries. Only the first packet of a connection actually traverses this chain - its rules usually define details of the created conntrack entry (NAT statements for instance). + + + route + ip, ip6 + output + If a packet has traversed a chain of this + type and is about to be accepted, a new route + lookup is performed if relevant parts of the IP + header have changed. This allows to e.g. + implement policy routing selectors in + nftables. + + + +
+ + + Apart from the special cases illustrated above (e.g. nat type not supporting forward hook or route type only supporting output hook), there are two further quirks worth noticing: + + + netdev family supports merely a single + combination, namely filter type and + ingress hook. Base chains in this family also require the device parameter to be present since they exist per incoming interface only. + + + arp family supports only + input and output + hooks, both in chains of type + filter. + + + + + The priority parameter accepts a signed integer value which specifies the order in which chains with same hook value are traversed. The ordering is ascending, i.e. lower priority values have precedence over higher ones. + + + Base chains also allow to set the chain's policy, i.e. what happens to packets not explicitly accepted or refused in contained rules. Supported policy values are accept (which is the default) or drop. +