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:
- Check system logs:
journalctl -xe
- Verify script permissions
- Test script execution manually
- 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:
- Check script permissions (must be executable)
- Verify script execution order (use numbering prefixes)
- Check system logs for errors (
journalctl -xe
) - Test script execution manually before relying on automatic execution