I have a Linux machine with kernel 3.2.0-23-generic and it has rule with priority 220 in RPDB which points to routing table named 220:T42:~# ip rule show0:      from all lookup local 220:    from all lookup 220 220:    from all lookup 220 32766:  from all lookup main 32767:  from all lookup default T42:~# ip route show table 220T42:~# Is it possible to see Where did this rule come from? What is the point of empty routing table? Last but not least, how can there be multiple rules with same priority?
routing table 220 in Linux kernel 3.2.0-23-generic
networking;linux kernel;routing
Is it possible to see Where did this rule come from?Not in the sense where can I look up the source of this rule.There are several ways to investigate the issue: the most evident is to grep all startup scripts on your system to see which uses ip rule at all, and then start reading them. Or you could start your system in single-user mode, and start services one-by-one, from command-line, using strace. Or you might start your system with bash as init (kernel command line: init=/bin/bash), and then you can exec the real /sbin/init with strace. These are rather advanced ways to trace the startup activities, it may not be trivial to know which scripts to run...There is no way to know where the specific rule came from if it was an administrator or a hacker entering it manually, and not a script present on the system.What is the point of empty routing table?Nothing - until someone starts populating that table. This could be a daemon, initially entering the rule for its own table, and then dynamically changing the contents of its own routing table.how can there be multiple rules with same priority?IPROUTE2 Utility Suite Howtopriority PREFERENCE --- priority of this rule. Each rule should have an explicitly set unique priority value. Priority is an unsigned 32 bit number thus we have 4294967296 possible rules.WARNING!For historical reasons ip rule add does not require any priority value and allows the priority value to be non-unique. If the user had not supplied a priority value then one was assigned by the kernel.If the user requested creating a rule with a priority value which already existed then the kernel did not reject the request and added the new rule before all old rules of the same priority. This is a mistake in the current design, nothing more. It should be fixed by the time you read this so please do not rely on this feature. You should always use explicit priorities when creating rules.