The documentation is wrong here: it is indeed possible to remove policy
rule 0 and recreate it afterwards. Therefore remove these statements.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Clarify that 'ip rule' defaults to action 'list', that 'flush' and
'save' actions don't accept additional parameters, add missing 'not' and
'goto' keywords and finally fix fonts used in 'fwmark' and 'realms'
parameters.
Signed-off-by: Phil Sutter <phil@nwl.cc>
This patch adds save and restore commands to "ip rule"
similar the same is made in commit f4ff11e3e2 for "ip route".
The feature is useful in checkpoint/restore for container
migration, also it may be helpful in some normal situations.
Signed-off-by: Kirill Tkhai <ktkhai@odin.com>
This has been inconsistent since the beginning of Git and seems to be
merely a documentation leftover, therefore just remove it from help
output and man page.
Signed-off-by: Phil Sutter <phil@nwl.cc>
When configuring a system with multiple network uplinks and default routes, it
is often convenient to reference a routing table multiple times - but reject
its routing decision if certain constraints are not met by it.
Consider this setup:
$ ip route add table secuplink default via 10.42.23.1
$ ip rule add pref 100 table main suppress_prefixlength 0
$ ip rule add pref 150 fwmark 0xA table secuplink
With this setup, packets marked 0xA will be processed by the additional routing
table "secuplink", but only if no suitable route in the main routing table can
be found. By suppressing entries with a prefixlength of 0 (or less), the
default route (/0) of the table "main" is hidden to packets processed by rule
100; packets traveling to destinations via more specific routes are processed
as usual.
It is also possible to suppress a routing entry if a device belonging to
a specific interface group is to be used:
$ ip rule add pref 150 table main suppress_group 1
Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
Rephrasing for clarity.
Note that in ip-rule.8 I rephrased a sentence to "The RPDB is scanned
in order of decreasing priority." The original version talked about
*in*creasing priority, but from the context that didn't make sense.
Signed-off-by: Kees van Reeuwijk <reeuwijk@few.vu.nl>