On 5/2/12 12:26 PM, Will Dennis wrote:
My question is, if the ping command used was 'ping -I eth0.168
172.16.42.1' to force the ping out the eth0.168 int, with the dest being
on another VLAN, and where the outgoing ICMP packet has the VLAN tag set
to '168', and the return ICMP packet is also tagged with VLAN '168', why
would the RHEL system think the response packet was coming in a
different interface from the one that had the source address? Wouldn't a
packet going out eth0.168 come back into eth0.168, because that's the
interface that is mapped to the source IP address?? Here is the routing
table for this example:
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
172.16.180.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
172.16.168.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0.168
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
eth0.168
0.0.0.0 172.16.180.254 0.0.0.0 UG 0 0 0
eth0
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/
