Re: Sending ICMP echo request out

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Audio]     [Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux