[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-net
Subject:    Re: Pinging interfaces on same machine and subnet
From:       "kzsolt" <kzsolt () datanet ! hu>
Date:       2010-08-31 10:00:58
Message-ID: 1E396166D42F482EA0F996BC3BCB2FDF () ZSOLTIPC
[Download RAW message or body]

Hi Joel!

I try to solve the same problem at "Routing internal traffic externally" at
theme more nic same subnet with no success.

First I set a arp_filter=1 és arp_ignore=1 és arp_announce=1 on all
interface (see ip-sysctl.txt).
Then I add source route for own address for both nic.
Finally add arp entry with address of parner nic to both nic.
The result is every route is working fine except the icmp between the two
interface in same kerenel instance. The echo request are sended out trough
both inteface but no response for.
Looks like the UDP and TCP working fine with two nic in same subnet but the
ICMP not. I think the root cause of the problem the ICMP routed trough
different way than the UDP or TCP.

My final solutiuon is a virtual machine trough virtual nic. In that case the
requester and the responder are in different kernel instance but can be on a
same machine.

kzsolt

----- Original Message ----- 
From: "Roel van Meer" <rolek@bokxing.nl>
To: "Joel Fernandes" <agnel.joel@gmail.com>
Cc: <linux-net@vger.kernel.org>
Sent: Tuesday, August 31, 2010 9:15 AM
Subject: Re: Pinging interfaces on same machine and subnet


> Joel Fernandes writes:
>
>>>> I have a question about sending ping requests from one interface to
>>>> another on the same linux machine .
>>>
>>> if I'm not mistaken you need a kernel patch for that to work. They can
>>> be
>>> found here: http://www.ssi.bg/~ja/#loop (the Send-To-Self section).
>>>
>>
>> The Ping request is being received at the other interface but it is
>> not generating a response.
>> Use case: An interface "mesh1" (source) with IP 192.168.3.2 is trying
>> to ping "mesh0" (destination) with IP 192.168.3.1
>>
>> The ARP response itself is not being sent from the destination node
>> (mesh0) to source.
>>
>> root@joel-laptop:/proc# tcpdump -ennqti mesh0 \( arp or icmp \) -v
>> tcpdump: listening on mesh0, link-type EN10MB (Ethernet), capture size 96
>> bytes
>> 02:00:00:00:01:00 > ff:ff:ff:ff:ff:ff, ARP, length 42: Ethernet (len
>> 6), IPv4 (len 4), Request who-has 192.168.3.1 tell 192.168.3.2, length
>> 28
>>
>> Only ARP requests seen at destination, No ARP response generated!!
>>
>> but I manage to get past this problem by manually adding entries to
>> the ARP table of the source interface (mesh1):
>>
>> root@joel-laptop:/proc# arp -i mesh1 -s 192.168.3.1 02:00:00:00:00:00
>>
>> Once I add  the ARP entries, the ping command is able send packets
>> from one interface to the other but for some reason, a ping response
>> is not generated, this seems very strange:
>>
>> root@joel-laptop:/usr/src/# ping -I mesh1 192.168.3.1
>> [ping doesn't return anything]
>
> I think the kernel is not routing packets to 192.168.3.2 or 192.168.3.1
> out through the external interface. For sending the packet you overcome
> this by explicitly setting the outgoing interface (thus overriding
> routing), but the response packet is routed according to the kernel's idea
> of its destination. You can check this by looking it the output of these
> two commands:
>
> ip route get 192.168.3.1
> ip route get 192.168.3.2
>
> I think what you'll see is that packets to 192.168.3.2 (the source) are
> getting routed via loopback, so you won't see a response.
>
> Perhaps it's kind of simplistic, but I don't see why Julian would keep
> updating the send-to-self patches for recent kernels if this would just
> work with stock kernels. Then again, he might have his reasons, I don't
> know.
>
> Regards,
>
> roel
>
>> Monitoring the destination interface of the ping (mesh0):
>>
>> root@joel-laptop:/proc# tcpdump -ennqti mesh0 \( arp or icmp \) -v
>>     192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 1, length
>> 64
>> 02:00:00:00:01:00 > 02:00:00:00:00:00, IPv4, length 98: (tos 0x0, ttl
>> 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
>>     192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 2, length
>> 64
>> 02:00:00:00:01:00 > 02:00:00:00:00:00, IPv4, length 98: (tos 0x0, ttl
>> 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
>>     192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 3, length
>> 64
>> 02:00:00:00:01:00 > 02:00:00:00:00:00, IPv4, length 98: (tos 0x0, ttl
>> 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
>>     192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 4, length
>> 64
>>
>> So the ping packets are being received at destination but the
>> destination is not sending a response for some reason.. Both ARP and
>> ICMP responses are not being generated by the destination node thought
>> it _is_ receiving the requests as verified above.
>>
>> This seems to be a problem with the network layer of the network
>> interfaces. I tried looking at the proc entries and seeing if ICMP or
>> ARP was disabled but everything looks ok.
>>
>> Any suggestions for solving or understanding this problem is much
>> appreciated,
>>
>> thanks,
>> Joel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]