Thanks David for the explanation. So here's the setups between the two systems:
System that works: ================== root@rhel4-sys ~> for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo $i; cat $i; done /proc/sys/net/ipv4/conf/all/rp_filter 0 /proc/sys/net/ipv4/conf/default/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.100/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.101/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.102/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.103/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.104/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.105/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.106/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.107/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.108/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.109/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.120/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.150/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.155/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.159/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.161/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.162/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.164/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.166/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.167/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.168/rp_filter 1 /proc/sys/net/ipv4/conf/eth0.169/rp_filter 1 /proc/sys/net/ipv4/conf/eth0/rp_filter 1 /proc/sys/net/ipv4/conf/lo/rp_filter 0 root@rhel4-sys ~> System that does not work: ========================= root@rhel6-sys ~> for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo $i; cat $i; done /proc/sys/net/ipv4/conf/all/rp_filter 1 /proc/sys/net/ipv4/conf/default/rp_filter 0 /proc/sys/net/ipv4/conf/eth0.168/rp_filter 0 /proc/sys/net/ipv4/conf/eth0/rp_filter 1 /proc/sys/net/ipv4/conf/eth1/rp_filter 0 /proc/sys/net/ipv4/conf/lo/rp_filter 0 root@rhel6-sys ~> I tried the command 'sysctl -w net.ipv4.conf.eth0.rp_filter=0' and it does not solve the problem; however (as in the above working system) if I set 'sysctl -w net.ipv4.conf.all.rp_filter=0' it doesn't matter what the other settings are set to, it seems to turn off reverse path checking globally. It's good to know how things work :) Now, can one consider this a bug as relates to systems with 802.1q trunking on a NIC? (Shouldn't the reverse path checking be VLAN tag aware?) Caveat: I'm not really a Linux guy, and certainly not a kernel hacker, so I don't know how much work it would be to implement this type of checking... Thanks again, Will -----Original Message----- From: David Coulson [mailto:[email protected]] Sent: Thursday, May 03, 2012 11:56 AM To: Will Dennis Cc: [email protected] Subject: Re: [lopsa-tech] Weird problem with trunking on RedHat EL 6.x Reverse path filtering only cares about the source IP address of the packet coming in - It is not connection-based. In your example, it's seeing a packet from 172.16.42.1 coming in eth0.168, however the path back to 172.16.42.1 is via eth0 (using the default route). With rp_filter set to 1, this will cause the packet to be dropped. RHEL4 pretty much worked the same - I'm not sure why you're seeing a difference between the two. Perhaps there is a routing table difference, or a variation on how the packets are routed back from somewhere else on the network? _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
