-- the type of this rule. The list of valid types was given in the previous subsection.
-- select the source prefix to match.
-- select the destination prefix to match.
-- select the incoming device to match. If the interface is loopback, the rule only matches packets originating from this host. This means that you may create separate routing tables for forwarded and local packets and, hence, completely segregate them.
-- select the TOS value to match.
-- select the
fwmark value to match.
-- the priority of this rule. Each rule should have an explicitly
set unique priority value.
Really, for historical reasons
ip rule add does not require a
priority value and allows them to be non-unique.
If the user does not supplied a priority, it is selected by the kernel.
If the user creates a rule with a priority value that
already exists, the kernel does not reject the request. It adds
the new rule before all old rules of the same priority.
It is mistake in design, no more. And it will be fixed one day, so do not rely on this feature. Use explicit priorities.
-- the routing table identifier to lookup if the rule selector matches.
-- Realms to select if the rule matched and the routing table lookup
TO is only used if the route did not select
-- The base of the IP address block to translate (for source addresses).
ADDRESS may be either the start of the block of NAT addresses
(selected by NAT routes) or in linux-2.2 a local host address (or even zero).
In the last case the router does not translate the packets,
but masquerades them to this address; this feature disappered in 2.4.
More about NAT is in Appendix C,