Linux – routing table “220” in Linux kernel 3.2.0-23-generic

linux-kernelnetworkingrouting

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 show
0:      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 220
T42:~#

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?

Best Answer

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 Howto

priority 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.

Related Solutions

Linux routing for receiving packet

There are several settings which control this behavior.
In short the solution is:

sysctl -w net.ipv4.conf.eth0.arp_announce=2
sysctl -w net.ipv4.conf.eth1.arp_announce=2
sysctl -w net.ipv4.conf.eth0.arp_filter=1
sysctl -w net.ipv4.conf.eth1.arp_filter=1
sysctl -w net.ipv4.conf.eth0.arp_ignore=1
sysctl -w net.ipv4.conf.eth1.arp_ignore=1

The kernel documentation covers what these parameters do:

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

arp_announce - INTEGER
    Define different restriction levels for announcing the local
    source IP address from IP packets in ARP requests sent on
    interface:
    0 - (default) Use any local address, configured on any interface
    1 - Try to avoid local addresses that are not in the target's
    subnet for this interface. This mode is useful when target
    hosts reachable via this interface require the source IP
    address in ARP requests to be part of their logical network
    configured on the receiving interface. When we generate the
    request we will check all our subnets that include the
    target IP and will preserve the source address if it is from
    such subnet. If there is no such subnet we select source
    address according to the rules for level 2.
    2 - Always use the best local address for this target.
    In this mode we ignore the source address in the IP packet
    and try to select local address that we prefer for talks with
    the target host. Such local address is selected by looking
    for primary IP addresses on all our subnets on the outgoing
    interface that include the target IP address. If no suitable
    local address is found we select the first local address
    we have on the outgoing interface or on all other interfaces,
    with the hope we will receive reply for our request and
    even sometimes no matter the source IP address we announce.

    The max value from conf/{all,interface}/arp_announce is used.

    Increasing the restriction level gives more chance for
    receiving answer from the resolved target while decreasing
    the level announces more valid sender's information.

arp_ignore - INTEGER
    Define different modes for sending replies in response to
    received ARP requests that resolve local target IP addresses:
    0 - (default): reply for any local target IP address, configured
    on any interface
    1 - reply only if the target IP address is local address
    configured on the incoming interface
    2 - reply only if the target IP address is local address
    configured on the incoming interface and both with the
    sender's IP address are part from same subnet on this interface
    3 - do not reply for local addresses configured with scope host,
    only resolutions for global and link addresses are replied
    4-7 - reserved
    8 - do not reply for all local addresses

    The max value from conf/{all,interface}/arp_ignore is used
    when ARP request is received on the {interface}

Best Answer

Related Solutions

Linux routing for receiving packet

Related Question