Do you also have a native/default/untagged vlan for eth0? Cheers, Brian
On 05/02/2012 12:26 PM, Will Dennis wrote: > 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/ _______________________________________________ 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/
