local routing

Hello ereryone.
Is it possible to prevent local routing in Linux?

eth0 -------
|
switch
|
eth1 -------

eth0 and eth1 are in same network.
I want that packages are going across a switch
from eth0 to eth1 but not through the local lo interface.
Is there some way to do it?

--
Regards
Igor A. Nemilentsev

On 10.9.10 12:29 , Igor Nemilentsev wrote:
> Hello ereryone.
> Is it possible to prevent local routing in Linux?
>
> eth0 -------
> |
> switch
> |
> eth1 -------
>
> eth0 and eth1 are in same network.
> I want that packages are going across a switch
> from eth0 to eth1 but not through the local lo interface.
> Is there some way to do it?


Would you please tell why? What is the problem you're
attempting to solve?

It is already a bad practice to have two different interfaces
in the same subnet on the same host.

If you succeeded to break the routing in the requested
way, you still have a need for ARP to behave in a
scitsophrenic way, to respond correctly to a request
from an own interface.

If you want to test the interface cards, you do need
two different computers, period.

For just testing networked programs wthout the need for
physical interfaces, a virtual computer in the host system
can operate like the other computer. The virtual machine
monitors (e.g. VmWare) usually build virtual network
interfaces between the computers, and they can be
programmed like two separate computers.

--

Tauno Voipio
tauno voipio (at) iki fi

jack <(E-Mail Removed)> wrote:
> Tauno Voipio wrote:
> > If you succeeded to break the routing in the requested
> > way, you still have a need for ARP to behave in a
> > scitsophrenic way, to respond correctly to a request
> > from an own interface.
> >
> ARP behaves schizophrenic enough as it is - I spent an hour today
> figuring out what generated a bunch of 'arp info overwritten' messages
> on the firewall. Turns out that my second network card (used to catch
> traffic on a mirrored switch port) was plugged into a normal switch
> port, and was responding to ARP requests for the primary card's IP
> address. And that with one interface on 192.168.0.x and the other on
> 172.16.0.x, and all net.*.forward sysctls set to 0.

"Linux" believes very strongly in the "weak end system" model, where
IP addresses are properties of the *system* not the "physical"
interface. That is why, by default, ARP will respond for any
system-local IP on any interface.

Causes me no end of grief in netperf testing when I want to "know"
that the traffic flowed over a specific NIC. To work around the
issue, I set the "arp_ignore" sysctl for each interface (or set the
default and then re-ifconfig or reboot).

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones a écrit :
> Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
>> Hello,
>> Igor Nemilentsev a ?crit :
>>> Is it possible to prevent local routing in Linux?
>
>> Not without patching the kernel, or using NAT tricks.
>
> I presume you mean Ben Greer's (Grear) patches?

I meant the send-to-self patch [1] by Julian Anastasov who writes about it :
"This patch is basically the Ben Greear's send-to-self work but
reimplemented entirely on routing level."

[1] http://www.ssi.bg/~ja/#loop

> Not that I'd ever want to do it, but out of curiousity, what sort of
> NAT tricks?

1) Send a packet to some remote address which is directly reachable
through interface #1.
2) SNAT it to some remote address which is directly reachable through
interface #2.
3) When the packet arrives on interface #2, DNAT it to some local
address so that it is locally delivered.

2) is needed because the IP stack would discard a packet with a local
source address received on a non-loopback interface. Besides, it allows
the return traffic to be routed externally too.

I guess you also need to define static ARP entries for the selected
remote addresses.

Rick Jones a écrit :
>
> "Linux" believes very strongly in the "weak end system" model, where
> IP addresses are properties of the *system* not the "physical"
> interface. That is why, by default, ARP will respond for any
> system-local IP on any interface.

Yup. But its weak end model has limits for IPv6. Multicast addresses
required for the neighbour discovery protocol (which does the job of ARP
for IPv6) are only added on the interface the corresponding unicast IPv6
address is added to.

Rick Jones wrote:

> jack <(E-Mail Removed)> wrote:
>> Tauno Voipio wrote:
>> > If you succeeded to break the routing in the requested
>> > way, you still have a need for ARP to behave in a
>> > scitsophrenic way, to respond correctly to a request
>> > from an own interface.
>> >
>> ARP behaves schizophrenic enough as it is - I spent an hour today
>> figuring out what generated a bunch of 'arp info overwritten' messages
>> on the firewall. Turns out that my second network card (used to catch
>> traffic on a mirrored switch port) was plugged into a normal switch
>> port, and was responding to ARP requests for the primary card's IP
>> address. And that with one interface on 192.168.0.x and the other on
>> 172.16.0.x, and all net.*.forward sysctls set to 0.
>
> "Linux" believes very strongly in the "weak end system" model, where
> IP addresses are properties of the *system* not the "physical"
> interface. That is why, by default, ARP will respond for any
> system-local IP on any interface.
>
> Causes me no end of grief in netperf testing when I want to "know"
> that the traffic flowed over a specific NIC. To work around the
> issue, I set the "arp_ignore" sysctl for each interface (or set the
> default and then re-ifconfig or reboot).

You can also use:
echo 1 >/proc/sys/net/ipv4/conf/all/arp_filter

Google for "arp flux" documentation - I had to do this to stop my host
responding to arp requests from a virtual host on a bridge interface with no
IP on it. (Played havoc with the packet filter rules)