When working with Linux networking, I recently encountered a puzzling behavior where:

# Fails
ip route add 192.168.0.0/16 via 192.168.255.254 src 192.168.1.101
RTNETLINK answers: No such process

# Works in two steps
ip route add 192.168.0.0/16 dev eth0
ip route change 192.168.0.0/16 via 192.168.255.254 src 192.168.1.101

This occurs because the Linux kernel performs route validation before accepting new routes. When you specify both via and src parameters together in the initial ip route add command, the kernel needs to verify:

• The gateway (192.168.255.254) is reachable
• The source address (192.168.1.101) is valid for the outgoing interface
• Reverse path filtering (rp_filter) considerations

Breaking it into two commands succeeds because:

1. The first command establishes a basic route entry with just the interface
2. The second command modifies the existing route, bypassing some of the initial validation checks

Here's the complete working configuration I ended up with:

auto lo
iface lo inet loopback

# Primary interface
auto eth0
iface eth0 inet static
    address 178.xxx.xxx.131
    netmask 255.255.255.192
    gateway 178.xxx.xxx.190
    up ip route add default via 178.xxx.xxx.190 dev eth0 table 125
    up ip rule add from 178.xxx.xxx.128/26 table 125
    post-down ip route del default via 178.xxx.xxx.190 dev eth0 table 125
    post-down ip rule del from 178.xxx.xxx.128/26 table 125

# Secondary IP with different routing
auto eth0:0
iface eth0:0 inet static
    address 192.168.1.101
    netmask 255.255.0.0
    gateway 192.168.255.254

Several important adjustments made this work:

# Disable reverse path filtering
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

# Verify route table
ip route show table 125

Other potential solutions include:

# Option 1: Add a dummy route first
ip route add 192.168.255.254 dev eth0
ip route add 192.168.0.0/16 via 192.168.255.254 src 192.168.1.101

# Option 2: Use 'proto kernel' to bypass some checks
ip route add 192.168.0.0/16 via 192.168.255.254 src 192.168.1.101 proto static

When facing similar issues, check:

# View kernel route validation errors
dmesg | grep "RTNETLINK"

# Verify interface configurations
ip addr show
ip link show

# Check routing tables
ip route get 192.168.1.101

When working with Linux network configuration, I encountered a puzzling scenario where direct route addition failed but a two-step process succeeded:

# Fails with "No such process"
ip route add 192.168.0.0/16 via 192.168.255.254 src 192.168.1.101

# Works in two steps
ip route add 192.168.0.0/16 dev eth0
ip route change 192.168.0.0/16 via 192.168.255.254 src 192.168.1.101

Here's the relevant interface configuration from /etc/network/interfaces:

auto eth0
iface eth0 inet static
    address 178.xxx.xxx.xxx
    netmask 255.255.255.192
    gateway 178.xxx.xxx.xxx

auto eth0:1
iface eth0:1 inet static
    address 192.168.1.101
    netmask 255.255.0.0

The failure occurs because the Linux kernel performs several validation checks when adding routes:

• Source address validation (RPF check)
• Gateway reachability verification
• Interface binding constraints

When you attempt the direct route addition, the kernel needs to verify that:

1. The specified gateway (192.168.255.254) is reachable through the outgoing interface
2. The source IP (192.168.1.101) belongs to the outgoing interface
3. The reverse path filtering (rp_filter) allows this asymmetric routing

Here's the working configuration I implemented:

auto eth0
iface eth0 inet static
    address 178.xxx.xxx.131
    netmask 255.255.255.192
    gateway 178.xxx.xxx.190
    up ip route add default via 178.xxx.xxx.190 dev eth0 table 125
    up ip rule add from 178.xxx.xxx.128/26 table 125

auto eth0:0
iface eth0:0 inet static
    address 192.168.1.101
    netmask 255.255.0.0
    gateway 192.168.255.254

# Disable strict RPF checking
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

For complex routing scenarios, consider these additional techniques:

# Create a separate routing table
echo "200 custom" >> /etc/iproute2/rt_tables

# Add specific rules
ip rule add from 192.168.1.101 lookup custom
ip route add default via 192.168.255.254 dev eth0 table custom

# Verify routing decisions
ip route get 192.168.10.1 from 192.168.1.101

Use these commands to diagnose routing issues:

# Show all routes
ip route show table all

# Check route cache
ip route get 192.168.1.1

# Verify interface addresses
ip addr show eth0

# Check kernel routing decisions
ip route get 192.168.1.1 from 192.168.1.101