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@xxxxxxxxxx>
To: "Joel Fernandes" <agnel.joel@xxxxxxxxx>
Cc: <linux-net@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
