Missing kernel configuration: CONFIG_IP_MULTIPLE_TABLES (ip source routing) (original) (raw)

Hello everyone!

I am using the standard, “default build” from NVIDIA, which I load via the SDK Manager. However, I have identified that a specific Linux kernel option required for IP source routing is not enabled in this configuration:

CONFIG_IP_MULTIPLE_TABLES

first device:

$ head /etc/nv_tegra_release -n1
# R36 (release), REVISION: 4.3, GCID: 38968081, BOARD: generic, EABI: aarch64, DATE: Wed Jan  8 01:49:37 UTC 2025

$ zcat /proc/config.gz | grep CONFIG_IP_MULTIPLE_TABLES
# nothing

second device:

$ head /etc/nv_tegra_release -n1
# R36 (release), REVISION: 4.7, GCID: 42132812, BOARD: generic, EABI: aarch64, DATE: Thu Sep 18 22:54:44 UTC 2025

$ zcat /proc/config.gz | grep CONFIG_IP_MULTIPLE_TABLES
# nothing

old device (this works as it should):

$ head /etc/nv_tegra_release -n1
# R32 (release), REVISION: 4.4, GCID: 23942405, BOARD: t186ref, EABI: aarch64, DATE: Fri Oct 16 19:37:08 UTC 2020

$ zcat /proc/config.gz | grep CONFIG_IP_MULTIPLE_TABLES
CONFIG_IP_MULTIPLE_TABLES=y

any random Debian x86-64 setup (default settings):

$ cat /boot/config-5.10.0-31-amd64 | grep CONFIG_IP_MULTIPLE_TABLES
CONFIG_IP_MULTIPLE_TABLES=y

My Questions:

A) Why was this kernel option excluded from the default build?

I realize that this feature cannot be compiled as a loadable kernel module – it must be either enabled or disabled at build time.

B) Could you recommend any modern alternatives? It is possible that the ip rule approach is outdated and there are newer, more efficient methods I am unaware of.

Brief description of my task: I have multiple network interfaces in my system. I need to route all traffic from a specific ip-address (10.0.5.87/32) through a dedicated tunnel interface (tun0), bypassing the main default route.

My Network Configuration (Previously Working):

My system has a standard Ethernet connection with a default gateway:

default via 192.168.88.1 dev eth0

Additionally, I have a tun0 interface with the address 10.0.5.87/32. Previously, I used ip rule for policy-based routing:

$ ip rule
32765: from 10.0.5.87 lookup 120

And I had a corresponding route in table 120:

$ ip route show table 120
default dev tun0 scope link

This configuration successfully put all packets originating from 10.0.5.87/32 through the tun0 interface instead of the default gateway. Thus, regardless of whether a request is received via eth0 or tun0, the response will be sent back via the same path.

Thank you for your help.