Notes to myself on the priorities of Linux routing policy rules

April 24, 2011

Linux's policy based routing is done by writing a set of rules about what routing to do under various circumstances; this is implemented by 'ip rule' (and kernel code, of course). All policy rules have a priority, and rules are examined in priority order (low to high). Historically, I've given each rule a different priority (related rules get priorities that are close to each other). However, this is not required and I've come to think that it's sort of a mistake.

It's fine to have multiple rules at the same priority if they are what I'll call 'non-conflicting', ie if only one rule can possibly match a given packet. Often this is easy to arrange, for example if you have a series of rules like:

ip rule add from IP1 iif lo table 10
ip rule add from IP2 iif lo table 11
ip rule add from IP3 iif lo table 12
ip rule add from IP4 iif lo table 13

Since a packet can only have one source IP address, at most one of these rules can match a given packet. Similarly, if you have a set of rules that match incoming interfaces to dispatch to a routing table, they can all have the same priority since a packet can only have a single incoming interface.

(I'm confidant that all of this is in the documentation, along with a warning that conflicting rules at the same priority have undocumented behavior. This is a note to myself.)

You can still give all of these rules different priorities, but I've come to believe that this is a mistake for two reasons. First, it makes you work harder than you need to when you're adding rules, especially if you're doing it in scripts. Second, it somewhat obscures your intentions. Someone looking at your policy rules later (including yourself) is going to have to work out if the different priorities are important or just something you did just because. Meanwhile, grouping all of the variants of the same rule together at the same priority makes it clearer how things are organized (at least as I think of it); you can immediately see what your functional groups of different rules are. And of course you get simpler scripts for automating things like adding an isolated interface, since you know ahead of time what priorities the various rules are going to have.

(Having said that, I'm probably not going to revise my existing policy based routing rulesets to shuffle the priorities around to go with my new insight because my current setup works okay. But if I find myself adding and removing rules a bunch, it will get tempting.)

Written on 24 April 2011.
« The Upstart dependency problem
An important note about multi-line log message formats »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Apr 24 02:17:11 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.