Adding a routing policy rule with ip rule add sends matching traffic to a specific routing table instead of leaving every lookup to the default main table. This is useful on hosts with multiple uplinks, source-based egress policies, firewall-mark steering, or other layouts where the same destination may need different next hops.
A policy rule does not define the path by itself. It matches selectors such as source prefix, destination prefix, firewall mark, or interface, and the matching action tells the kernel which table to consult next. The selected table still needs the correct default route or destination prefix for the traffic that should match.
Rules are processed by increasing priority number, so lower numeric values run first and can override later lookups. New runtime rules affect traffic immediately, and any rule that should survive interface or host restarts must also be defined in the system's persistent network configuration.
Steps to add a routing policy rule with ip rule:
- Show the current policy-routing rules before choosing a priority for the new entry.
$ ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
Lower numeric priorities are evaluated first, so pick a unique value that fits the intended order.
- Confirm that the target routing table already contains the route that matching traffic should use.
$ ip route show table 100 default via 192.0.2.1 dev lab0 onlink
- Add the rule with the required selector, target table, and explicit priority.
$ sudo ip rule add from 192.0.2.10/32 table 100 priority 1000
- Verify that the new rule now appears in the policy list at the intended priority.
$ ip rule show 0: from all lookup local 1000: from 192.0.2.10 lookup 100 32766: from all lookup main 32767: from all lookup default
- Test a route lookup that should match the new selector before applying the same rule persistently.
$ ip route get 203.0.113.8 from 192.0.2.10 203.0.113.8 from 192.0.2.10 via 192.0.2.1 dev lab0 table 100 uid 0 cacheIf the lookup still resolves through the wrong table or interface, remove the rule and correct the selector or target table before continuing.
- Add the same rule to the interface's NetworkManager connection profile if it must survive a restart.
$ sudo nmcli connection modify lab0 +ipv4.routing-rules "priority 1000 from 192.0.2.10/32 table 100"
Runtime ip rule add changes only the active kernel policy database. The profile rule loads the next time the connection activates, and ip rule show then lists it with proto static beside any runtime copy. The profile name is the NAME value that nmcli connection show lists for the interface. If the table 100 route was also added by hand, it belongs in the same profile's ipv4.routes value, such as 0.0.0.0/0 192.0.2.1 table=100. On a host where Netplan manages the interface without NetworkManager, the same rule goes in the interface's routing-policy: list in its YAML file under /etc/netplan and loads with sudo netplan apply.