Re: ipv4 regression in 2.6.31 ?

Eric Dumazet
2009-09-14T13:57:08Z

Stephan von Krawczynski a écrit :
> Hello all,
>
> today we experienced some sort of regression in 2.6.31 ipv4 implementation, or
> at least some incompatibility with former 2.6.30.X kernels.
>
> We have the following situation:
>
> ---------- vlan1@eth0 192.168.2.1/24
> /
> host A 192.168.1.1/24 eth0 -------<router> host B
> \
> ---------- eth1 192.168.3.1/24
>
>
> Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B and let
> host A ping 192.168.2.1 everything works. But if you route 192.168.1.0/24 via
> interface eth1 on host B and let host A ping 192.168.2.1 you get no reply.
> With tcpdump we see the icmp packets arrive at vlan1@eth0, but no icmp echo
> reply being generated neither on vlan1 nor eth1.
> Kernels 2.6.30.X and below do not show this behaviour.
> Is this intended? Do we need to reconfigure something to restore the old
> behaviour?
>

Asymetric routing ?

Check your rp_filter settings

grep . `find /proc/sys/net -name rp_filter`

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.

Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.

conf/all/rp_filter must also be set to non-zero to do source validation
on the interface

Default value is 0. Note that some distributions enable it
in startup scripts.