Luis,
Here's your configuration:
: $ip rule add from 172.16.0.0/24 lookup 80
: $ip rule add to 172.16.0.0/24 lookup 81
: $ip route add 0.0.0.0/0 via 195.55.97.222 table 80
: $ip route add 172.16.0.0/24 via 172.16.0.254 table 81
:
: $ip rule add from 172.16.0.5 lookup 800
: $ip rule add from 172.16.0.6 lookup 800
: $ip rule add from 172.16.0.7 lookup 800
: $ip rule add to 172.16.0.5 lookup 810
: $ip rule add to 172.16.0.6 lookup 810
: $ip rule add to 172.16.0.7 lookup 810
: $ip route add 0.0.0.0/0 via 195.55.97.222 table 800
: $ip route add 10.10.10.0/24 dev vlan2 table 800
: $ip route add 172.16.0.0/24 via 172.16.0.254 table 810
:
: what table will be used by incoming traffic to 172.16.0.5? 81 or 810?
You should take a look at "ip rule show" and examine the entries in the
RPDB. They'll be organized from 0 (highest priority) to 32767 (lowest
priority). You can specify priority in your "ip rule add" commands like
this, for example:
# ip rule add prio 4000 from 172.16.0.7 lookup 800
By using explicit priorities (which Alexey Kuznetsov recommends in his
iproute2 documentation--see ip-cref.ps), you will have better control over
which rule is used first.
So, which table will be used by incoming traffic to 172.16.0.5? Assuming
the above commands were executed in that order on a fresh RPDB, the
entries in the RPDB will be selected in the following order (the reverse
order in which they were added). I speculate in brackets about the
priority number of each entry.
[32758] --> $ip rule add to 172.16.0.7 lookup 810
[32759] --> $ip rule add to 172.16.0.6 lookup 810
[32760] --> $ip rule add to 172.16.0.5 lookup 810
[32761] --> $ip rule add from 172.16.0.7 lookup 800
[32762] --> $ip rule add from 172.16.0.6 lookup 800
[32763] --> $ip rule add from 172.16.0.5 lookup 800
[32764] --> $ip rule add to 172.16.0.0/24 lookup 81
[32765] --> $ip rule add from 172.16.0.0/24 lookup 80
Following this logic, traffic to 172.16.0.5 will hit rule 32760 first,
which will cause a lookup in table 810. If this lookup fails to produce a
route, the traversal of the RPDB will continue.
Here are the conditions which would cause a route lookup to fail:
( There is no matching network prefix (and ToS (and fwmark)) for the
destination in the specified table.
AND
There is no default route. )
OR
( There is a matching network prefix (and ToS (and fwmark)) for the
destination in the specified table.
AND
The route type is a "throw" route. )
Continuing, your rule lookup has specified table 810. Your route lookup
in table 810 should return this route:
172.16.0.0/24 via 172.16.0.254
: what table will be used for the outcoming traffic from 172.16.0.5?
Rule lookup will match rule 32763 first, causing a route lookup in table
800. The matching route would be "0.0.0.0/0 via 195.55.97.222".
: Do I really need both type of rules? from and to?
Using the RPDB for "to" rules is not as intuitive as using a routing
table. The routing table is already (natively) keyed to destination
addressing (longest prefix match), so the most efficient use of the RPDB
is to use the RPDB to select based on source address or other criteria.
Although this may be the simplest use of the RPDB, there is no reason you
could not use "to" as a simple selector in the RPDB. Generally I'd
recommend restricting your use of the "to" selector in the RPDB as an
additional selector, a secondary adjective, if you will. Using "from" and
"to" together in a rule, using "to" with other selectors, or using "to" as
a solitary selector are all perfectly legitimate uses of the RPDB, despite
my recommendations. Some examples?
# ip rule add to 10.20.30.40 from 192.168.100.0/24 table 3
# ip rule add to $PARTNERNET tos $INTERACTIVE table $FASTLINK
# ip rule add to $MAILSERVER fwmark $SPAM table $BLACKHOLE
# ip rule add to $INTERNET iif $DMZIF table $RESTRICTED
: $ip rule add from 10.10.10.0/24 lookup 90
: $ip route add 172.16.0.5 via 172.16.0.254 table 90
: $ip route add 172.16.0.6 via 172.16.0.254 table 90
: $ip route add 172.16.0.7 via 172.16.0.254 table 90
:
: Should I add this routes for the traffic from 10.10.10.0/24?
: (as you can note I didn't define the 'ip rule add to' line but I am not
: sure if it is correct)
I'm really not sure what it is you are trying to accomplish, so I'm not
sure whether you should add that rule or not.
As I read through the routes and rules you added above, I am struck that
the only hosts which can reach the 10.10.10.0/24 network are the hosts
172.16.0.{5,6,7}. Is that what you intended?
If that is not what you intended, then you might send in a diagram of your
network with a description of what you wish to accomplish with your
routing policy.
Good luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
