Complex Cloud Networks and Reverse Path Filtering (rp_filter)

Definition of RPF

When constructing complex network in the cloud, you run in to situations where packets seem to be silently dropped. One reason could because  of Reverse Path Forwarding/Filter (RPF) check at the routing decision step. In RPF check, when the kernel is making the routing decision for a given packet, the kernel (1) notes the interface this packet arrived on, (2) verifies the source address is valid by finding which interface to use from its routing table, (3) and the interface that will be used for reaching back to the source address is the same as the interface this packet arrived.

If the above check passes, the packet is allowed to go forward.

Why?

To reduce spoofed addresses. Reverse Path Forwarding is actually defined in an IETF RFC document 3704 as a best practice. This is more applicable in edge routers and internet facing systems.

However, the default value in CentOS is set to strict. This causes packet drops.

In most cases, if you are not connected to the internet or untrusted networks, it should be fine to disable it or make it ‘loose’ source  validation – which means if the packet has a valid route via any interface not just via the arrival interface, it is accepted.

Turn it off?

If your node is not internet facing, generally prefer to turn it off. If its on the internet edge, you may want to think twice as turning it off at that node indicates some network config isn’t natural.

Here’s how to check current values:

sysctl -a | grep \\.rp_filter

How to temporarily turn it off:

[root] # for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
> echo 2 > $i
> done

In the above, we are setting a value of 2 which is ‘loose source check’.

Or to permanently set it

sysctl -w "net.ipv4.conf.all.rp_filter=2"

Note: Setting  of all, may not be enough. You may have to set individual interfaces.

How to detect RPF is dropping packets

Enable log_martians to see log entries in /var/log/messages that the packets are being dropped :

echo 1 >/proc/sys/net/ipv4/conf/<iface_name>/log_martians

Detecting in IPTABLES

Its hard to detect in Iptables. But it would be in the class of ‘missing log’ entries. Usually it would show as packet that exited the last rule in PREROUTING, but does not appear on the first rule of POSTROUTING . You can add Iptables log chain rules to trace this. But usually if you suspect drop in routing, enable the log_martians value is a much easier way.