We ran into a problem with trunking (multi-VLAN over one NIC) with
RedHat EL 6 that we haven't seen before. We do have RedHat EL 4 machines
that are running multi-VLAN over one int (with the requisite virtual
int's) that can ping any other network address (whether or not there is
an associated VLAN int mapped) with no problem - here's an example of
the int's off one such EL4 machine:
eth0 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.100 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.101 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.102 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.103 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.104 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.105 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.106 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.107 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.108 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.109 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.120 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.150 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.155 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.159 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.161 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.162 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.164 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.166 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.167 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.168 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
eth0.169 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC
(actual MAC addr changed to protect the innocent ;)
When we tried to do the same thing with a newly-installed RHEL 6
machine, we saw an odd problem... Pings from a virt (VLAN) interface,
say eth0.168, would work only if the corresponding IP address was on the
same VLAN (168 in this case.) Ping replies to IPs on other VLANs were
not received (no output whatever with the ping command.) We sniffed the
wire, and also used tcpdump on the interface, and did see ICMP ping
response packets coming back with the appropriate VLAN tag. So at that
point we knew it was a problem on the Linux box, not an network problem.
At that point our lead Linux admin opened a support ticket with RedHat
Support.
RedHat responded with the following:
=====
Issue
Why can't a server be pinged if net.ipv4.conf.all.rp_filter is set on
the server?
Environment
Red Hat Enterprise Linux 5
Resolution
Setting net.ipv4.conf.all.rp_filter = 1, enables reverse path filtering,
which automatically rejects incoming packets if the routing table entry
for their source address doesn't match the network interface they're
arriving on.
This has security advantages because it prevents the so-called IP
spoofing, however it can pose problems if the server does asymmetric
routing (packets from the server to a host take a different path than
packets from that host to the server) or if the server is a non-routing
host which has several IP addresses on different interfaces.
To see if any packets are being dropped, the log_martians parameter can
be turned on to tell the kernel to log them to through syslog.
# echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians
For more information about the parameter log_martians, please refer to
What is the kernel parameter ipv4.conf.all.log_martians for?.
You need to disable reverse path filtering to solve the problem. To
disable reverse path filtering for a specific interface, for example,
eth0, run the following command:
# sysctl -w net.ipv4.conf.eth0.rp_filter=0
Or add the following line in /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
And run the following command:
sysctl -p
To disable reverse path filtering for all interfaces, run the following
command:
# sysctl -w net.ipv4.conf.all.rp_filter=0
Or add the following line in /etc/sysctl.conf:
net.ipv4.conf.all.rp_filter=0
And run the following command:
sysctl -p
=====
So, they are saying to disable the 'reverse path filtering' feature, and
by extension, I guess that means the return packets are using an
asymmetric route?
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
Seems like a bug to me, but I am certainly not a Linux guru, so help me
understand if I'm off track somewhere here...
Thanks,
Willard Dennis
Systems/Network Administrator, Information Systems Technology
Group
NEC Laboratories America, Inc.
_______________________________________________
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/
