Here are my findings: --------------------------------------------------------------------- Reverse Path Filtering which is enable by default on linux. Basically, if the reply to the packet doesn't go out using the interface through which packet came in then linux box ,with Reverse Path Filtering enable, consider the packet as bogus packet and ignores it. FYI, http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html To see if any packets are being dropped then set flag in the log_martians file (/proc/sys/net/ipv4/conf/<interfacename>/log_martians) to tell kernel to log ignored packets in syslog. echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians After settting log_martians for inrterface eth1 192.168.12.6, I could see that packets are being dropped by system-2: $echo 1 > /proc/sys/net/ipv4/conf/eth1/log_martians $dmesg martian source 192.168.12.6 from 192.168.11.5, on dev eth1 ll header: 00:80:48:1e:47:68:00:80:48:3d:56:98:08:00 martian source 192.168.12.6 from 192.168.11.5, on dev eth1 ll header: 00:80:48:1e:47:68:00:80:48:3d:56:98:08:00 martian source 192.168.12.6 from 192.168.11.5, on dev eth1 ll header: 00:80:48:1e:47:68:00:80:48:3d:56:98:08:00 martian source 192.168.12.6 from 192.168.11.5, on dev eth1 ll header: 00:80:48:1e:47:68:00:80:48:3d:56:98:08:00 martian source 192.168.12.6 from 192.168.11.5, on dev eth1 ll header: 00:80:48:1e:47:68:00:80:48:3d:56:98:08:00 martian source 192.168.12.6 from 192.168.11.5, on dev eth1 ll header: 00:80:48:1e:47:68:00:80:48:3d:56:98:08:00 After turning off Reverse Path Filtering as shown below and then I did ping 192.168.12.6 from 192.168.11.5 . I could see as shown below via tcpdump taken on System-2, ICMP echo packet coming on eth1 (192.168.12.6) and ICMP Reply packet going out using different interface eth0 192.168.11.6 as it was expected. To disable Reverse Path Filtering $echo 2 > /proc/sys/net/ipv4/conf/<interfacename>/rp_filter $tcpdump -i eth1 proto ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 12:16:12.204647 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 353, length 64 12:16:13.204810 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 354, length 64 12:16:14.204820 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 355, length 64 12:16:15.204988 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 356, length 64 12:16:16.205003 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 357, length 64 12:16:17.205163 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 358, length 64 12:16:18.205185 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 359, length 64 12:16:19.205336 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 360, length 64 12:16:20.205358 IP 192.168.11.5 > 192.168.12.6: ICMP echo request, id 17169, seq 361, length 64 $tcpdump -i eth0 proto ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 12:16:12.204677 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 353, length 64 12:16:13.204840 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 354, length 64 12:16:14.204851 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 355, length 64 12:16:15.205019 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 356, length 64 12:16:16.205033 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 357, length 64 12:16:17.205195 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 358, length 64 12:16:18.205215 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 359, length 64 12:16:19.205362 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 360, length 64 12:16:20.205388 IP 192.168.12.6 > 192.168.11.5: ICMP echo reply, id 17169, seq 361, length 64 Thanks, Anil 2011/12/13 anil dahiya <anildahiya80@xxxxxxxxx>: > Thanks, It was issue of reverse path filtering. > > Regards, > Anil > > On Fri, Dec 9, 2011 at 1:29 AM, Nikolay S. <nowhere@xxxxxxxxxxxxxxxx> wrote: >> В Пт., 09/12/2011 в 00:00 +0530, anil dahiya пишет: >>> Hi , >>> >>> I have following setup with routing table as shown below: >>> >>> +-----------------------+ >>> | System-1 | >>> | "client" | >>> |------------------------| >>> | 192.168.11.5 | >>> +----------------------+ >>> | >>> | >>> +------+-----+ >>> | Switch +----------------------+ >>> +------+-----+ | >>> | | >>> | +-------------------------+ >>> | | 192.168.11.1 | >>> | |---------------------------| >>> | | Router | >>> | |-------------------------- | >>> | | 192.168.12.1 | >>> | +--------------------------+ >>> | | >>> | | >>> +------------------------+ | >>> | 192.168.11.6 | | >>> |--------------------------| | >>> | System-2 | | >>> |--------------------------| | >>> | 192.168.12.6 | | >>> | |----------------+ >>> +------------------------+ >>> >>> Routing table details of setup >>> ------------------------------------------ >>> System-1 >>> ----- >>> $route -n >>> Kernel IP routing table >>> Destination Gateway Genmask Flags Metric Ref Use Iface >>> 192.168.11.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1 >>> 0.0.0.0 192.168.11.1 0.0.0.0 UG 0 0 0 eth1 >>> >>> >>> Router >>> ----------- >>> $route -n >>> Kernel IP routing table >>> Destination Gateway Genmask Flags Metric Ref Use Iface >>> 192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 >>> 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> >>> >>> System-2 >>> ------ >>> $route -n >>> Kernel IP routing table >>> Destination Gateway Genmask Flags Metric Ref Use Iface >>> 192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 >>> 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> 0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 eth1 >>> >>> >>> When I do ping from system-1 192.168.11.5 to system-2 192.168.12.6 , >>> ping echo packet is reaching on system-2 through NIC 192.168.12.6 but >>> system is not sending any response to 192.168.11.5 using either of NIC >>> i.e 192.168.11.6 or 192.168.12.6 ? Why this is happening ? Can you >>> help me ? >>> >>> I have observed same type of symtoms when I do SSH from 192.168.11.5 >>> to 192.168.12.6 >>> >>> FYI, >>> ip_forwarding is enable on router and iptables are no configured on >>> any of system . >> >> I think, reverse path filtering is the problem here. >> >>> >>> Thanks, >>> Anil >>> -- >>> To unsubscribe from this list: send the line "unsubscribe netfilter" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs
