Windows Server 2012 R2添加Null Route无效求助：模拟资源故障失败

Hey there! Let’s sort out why your null route isn’t blocking traffic to 172.24.48.10 and get that failure simulation working as intended.

First off, let’s make sure your null route was actually added correctly and is showing up in your system’s routing table.

For Linux systems:

• Run ip route show or route -n and look for an entry for 172.24.48.10/32. If you don’t see it, your initial route command was invalid.
• If you do see it, check if it’s marked as blackhole—pointing traffic to a random non-existent IP isn’t the same as a true null route, which is likely why your setup isn’t working.

For Windows systems:

• Open an admin command prompt and run route print, then search for 172.24.48.10. If it’s missing, your route add command didn’t execute correctly.

Here are the most common culprits:

• Stale ARP Cache: If you’ve successfully pinged 172.24.48.10 before, your system has its MAC address stored in the ARP cache. It’ll skip the routing table entirely and send traffic directly to that cached MAC.
• Incorrect Route Syntax: Pointing traffic to a non-existent IP doesn’t tell your system to drop the traffic—it might still try to forward it, or fall back to a more specific (or default) route that allows connectivity to the original target.
• Local Interface Has the Target IP: If one of your network interfaces is assigned 172.24.48.10, your system will handle traffic locally instead of using the routing table.
• Firewall/Policy Routing Overrides: Rules in iptables/nftables (Linux) or Windows Firewall might be allowing traffic to bypass the null route, or a policy-based routing rule could be prioritizing a different path.

Let’s fix this properly:

1. Remove the old (non-working) route:
   • Linux: sudo ip route del 172.24.48.10/32
   • Windows (admin cmd): route delete 172.24.48.10
2. Add a proper blackhole route:
   • Linux: sudo ip route add blackhole 172.24.48.10/32 (this tells the kernel to drop all traffic to that IP immediately)
   • Windows (admin cmd): route add 172.24.48.10 mask 255.255.255.255 0.0.0.0 metric 1 -p (the -p makes it persistent across reboots; this routes traffic to a "blackhole" destination)
3. Flush the ARP cache to clear old MAC entries:
   • Linux: sudo arp -d 172.24.48.10
   • Windows (admin cmd): arp -d 172.24.48.10
4. Test it out: Ping 172.24.48.10 again. You should get request timeouts or "destination unreachable" messages instead of successful replies.

To confirm everything’s set up right:

• Linux: Run ip route show | grep 172.24.48.10—you should see blackhole 172.24.48.10/32 in the output.
• Windows: Run route print | findstr 172.24.48.10—look for an entry with mask 255.255.255.255 and next hop 0.0.0.0.

If you still have issues, check if the target IP is assigned to any local interface (use ip addr show on Linux or ipconfig on Windows) or if there are firewall rules that might be interfering.

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