修改主表默认IP规则优先级，求教在主规则后添加上游表IP规则方法

Hey there, let's work through this IP rule ordering challenge you're dealing with. I’ve run into similar situations when setting up custom routing tables, so here’s a breakdown of practical solutions to get your upstream01 and upstream02 rules placed right after the main table, even with the tight default priority gap.

First, let’s recap the default IP rule priority setup—this is why you’re running into the gap issue:

$ ip rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

The main table sits at priority 32766, with default right behind at 32767—no room to squeeze in new rules between them. Here’s how to fix that:

Solution 1: Adjust the main table’s priority to create space #

This is the approach you already considered, and it’s the most reliable way to enforce strict rule ordering. Here’s how to implement it:

1. Remove the default main rule (we’ll re-add it with a new priority):

   ip rule del priority 32766
   

2. Re-add the main rule with a lower priority number (remember: lower priority numbers mean the rule executes earlier). Let’s pick 32700—this leaves plenty of space between it and the default rule’s 32767:

   ip rule add priority 32700 from all lookup main
   

3. Slot in your upstream rules with priorities between 32700 and 32767. For example:

   ip rule add priority 32701 from 192.168.1.0/24 lookup upstream01
   ip rule add priority 32702 from 192.168.2.0/24 lookup upstream02
   

   Swap out the source CIDRs for whatever matches your traffic needs—you could also use to <dest-cidr> if routing based on destination instead.
4. Make rules persist across reboots with a systemd service:
   • Create a service file at /etc/systemd/system/ip-rules-setup.service:

     [Unit]
     Description=Custom IP Rules Setup
     After=network.target
     
     [Service]
     Type=oneshot
     ExecStart=/usr/local/bin/setup-ip-rules.sh
     RemainAfterExit=yes
     
     [Install]
     WantedBy=multi-user.target
     

   • Create the script /usr/local/bin/setup-ip-rules.sh (add 2>/dev/null to avoid errors if the rule doesn’t exist):

     #!/bin/bash
     # Remove default main rule (ignore error if already deleted)
     ip rule del priority 32766 2>/dev/null
     # Add main rule with adjusted priority
     ip rule add priority 32700 from all lookup main
     # Add upstream routing rules
     ip rule add priority 32701 from 192.168.1.0/24 lookup upstream01
     ip rule add priority 32702 from 192.168.2.0/24 lookup upstream02
     

   • Give the script execute permissions: chmod +x /usr/local/bin/setup-ip-rules.sh
   • Enable and start the service: systemctl enable --now ip-rules-setup.service

Solution 2: Leverage specific match conditions (no priority changes) #

If you’d rather not tweak the main table’s priority, this workaround might work—though it depends on your traffic logic. The default main rule is from all lookup main, so any rule with a more specific match (like a source/destination CIDR) will take precedence even at the same priority.

But a heads-up: when you add a rule with the same priority as an existing one, it gets inserted before the existing rule. So your upstream rules at priority 32766 will run before the main rule. This works if you only want specific traffic to hit the upstream tables, with everything else falling through to main. But if you strictly need upstream rules to run after main (for unhandled traffic), stick with Solution 1.

Quick Tips to Avoid Headaches #

• Always verify the rule order after changes with ip rule show—you want to see local → main → upstream01 → upstream02 → default.
• If you use NetworkManager, it might reset rules on network connect. Fix this by dropping the script content into /etc/NetworkManager/dispatcher.d/99-ip-rules (set execute permissions) so NetworkManager runs it post-connection.
• Double-check any existing scripts/tools that rely on the main table’s original priority—most systems only care about the rule execution order, not the exact priority number.

内容的提问来源于stack exchange，提问作者Dmitriy Sosunov