Persistent ip rule Configuration in RHEL: Best Methods for Routing Table Rules Survival Across Reboots


2 views

When working with advanced networking on RHEL systems, many admins discover that their carefully crafted ip rule configurations vanish after reboot. Unlike iptables rules which have iptables-save/restore, the ip utility from iproute2 lacks a native persistence mechanism.

The specific rule we're examining:

# ip rule add fwmark 1 lookup 100
# ip rule
...
32765: from all fwmark 0x1 lookup 100
...

This creates a policy-based routing rule that directs packets with firewall mark 1 to routing table 100. Such configurations are common in:

  • Multi-homed servers
  • VPN routing configurations
  • QoS implementations
  • Complex network topologies

Method 1: NetworkManager Dispatcher Script

For modern RHEL 7+ systems with NetworkManager:

# /etc/NetworkManager/dispatcher.d/99-persistent-ip-rule
#!/bin/bash

if [ "$1" = "up" ]; then
    /sbin/ip rule add fwmark 1 lookup 100
fi

Make it executable:

chmod +x /etc/NetworkManager/dispatcher.d/99-persistent-ip-rule

Method 2: systemd Service Unit

Create a service that runs after network is up:

# /etc/systemd/system/persistent-iprule.service
[Unit]
Description=Persistent ip rule configuration
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ip rule add fwmark 1 lookup 100

[Install]
WantedBy=multi-user.target

Then enable it:

systemctl enable persistent-iprule.service

Method 3: ifcfg-post Script

For traditional network-scripts:

# /etc/sysconfig/network-scripts/ifcfg-post-eth0
#!/bin/bash
/sbin/ip rule add fwmark 1 lookup 100

After implementing any method:

# Verify rule exists
ip rule show

# Test packet marking
ping -c 1 -Q 1 8.8.8.8

# Check routing table
ip route show table 100
  • Execution order matters - rules must be added after network interfaces are up
  • Prefer method 1 (NetworkManager) for RHEL 7/8/9
  • Method 2 works well in cloud environments
  • Method 3 is most compatible with legacy systems

If rules don't persist:

  1. Check system logs: journalctl -xe
  2. Verify script permissions
  3. Test script execution manually
  4. Confirm network interface naming matches your configuration

When working with advanced networking on Linux systems, particularly RedHat-based distributions, you might need to create custom routing rules using the ip rule command. Unlike iptables rules which have dedicated persistence mechanisms, ip rule entries don't survive reboots by default.

The main issue is that the ip utility from iproute2 package doesn't have a built-in configuration file for rules persistence. This differs from other networking components that typically have configuration files in /etc/sysconfig/ or /etc/network/.

Here are the most reliable approaches to make your ip rule configurations persistent:

Method 1: NetworkManager Dispatcher Script

#!/bin/bash
# /etc/NetworkManager/dispatcher.d/99-persistent-ip-rule

if [ "$1" = "up" ]; then
    /sbin/ip rule add fwmark 1 lookup 100
fi

Make sure to make it executable:

chmod +x /etc/NetworkManager/dispatcher.d/99-persistent-ip-rule

Method 2: systemd Service Unit

Create a service file at /etc/systemd/system/persistent-iprule.service:

[Unit]
Description=Persistent ip rule configuration
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ip rule add fwmark 1 lookup 100
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Then enable it:

systemctl enable persistent-iprule.service

Method 3: ifup-post Script (Traditional Approach)

For systems using legacy networking:

#!/bin/bash
# /etc/sysconfig/network-scripts/ifup-post

/sbin/ip rule add fwmark 1 lookup 100

After implementing any of these methods, verify that your rule persists after reboot:

ip rule show | grep "fwmark 1"
# Should show: 32765: from all fwmark 0x1 lookup 100

For systems using NetworkManager, you can add scripts to connection-specific hooks:

# /etc/NetworkManager/dispatcher.d/connection-up.d/99-iprule
#!/bin/bash

if [ "$CONNECTION_ID" = "your-connection-name" ]; then
    /sbin/ip rule add fwmark 1 lookup 100
fi
  • Rule priority numbers (like 32765) are automatically assigned if not specified
  • Multiple rules can be added in sequence in your script
  • Test your solution in a non-production environment first
  • Document your changes in the system documentation

If your rules aren't persisting:

  1. Check script permissions (must be executable)
  2. Verify script execution order (use numbering prefixes)
  3. Check system logs for errors (journalctl -xe)
  4. Test script execution manually before relying on automatic execution