as packet count suggests these are not matching against any packet. when I do arping from other machine to the 10.19.1.102 (assigned to the eth1 interface) arp requests are responded from eth0 (ip-10.19.0.102). why the rules are not having any effect.

-j DROP ! -i eth1 .... > as packet count suggests these are not matching against any packet. > when I do arping from other machine to the 10.19.1.102 (assigned to > the eth1 interface) > arp requests are responded from eth0 (ip-10.19.0.102). > why the rules are not having any effect Swifty

On 08/14/07 01:45, pankaj jain wrote: > I was trying to drop arp packets such that only specific interface > should answer the arp requests.

I don't know if it applies to your situation or not, but have you tried the configurations used in the Linux Virtual Server (a.k.a. LVS) to prevent an interface from responding to ARP requests, i.e. via /proc settings?

On 08/14/07 01:45, pankaj jain wrote: > I was trying to drop arp packets such that only specific interface > should answer the arp requests.

Will you please elaborate a bit more on why you are trying to accomplish this and what your situation is? I feel like there is more to this puzzle that will help us help you. For example, do you have multiple (VLAN) physical interfaces on the same subnet or do you have an overly large netmask that encompasses both IPs in your post?

On 8/14/07, Grant Taylor <gtaylor [at] riverviewtech> wrote: > On 08/14/07 01:45, pankaj jain wrote: > > I was trying to drop arp packets such that only specific interface > > should answer the arp requests. > > Will you please elaborate a bit more on why you are trying to accomplish > this and what your situation is? I feel like there is more to this > puzzle that will help us help you. For example, do you have multiple > (VLAN) physical interfaces on the same subnet or do you have an overly > large netmask that encompasses both IPs in your post? > > > > Grant. . . . > >

Hum. I would not think that you even needed the ARPTables rules to prevent the wrong interface from responding to an ARP request for another IP. Are you seeing this happen? Or is the purely preventative?

Grant Taylor a écrit : > On 08/16/07 00:56, pankaj jain wrote: > >>I have a machine with 3 interfaces >>eth0: 10.19.0.102 mask (255.255.255.0) >>eth1: 10.19.1.102 mask (255.255.255.0) >>eth2: 10.29.51.102 mask (255.255.255.0) > > >>all three are connected in a same switch (no vlans configured). I >>want arp requests to be responded by the associated interface only, >>and not by other interfaces. [...] > Hum. I would not think that you even needed the ARPTables rules to > prevent the wrong interface from responding to an ARP request for > another IP.

The default behaviour is to reply on any interface for any local address. It can be changed on a per-interface basis with the kernel parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions and values are in Documentation/networking/ip-sysctl.txt :

arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved 8 - do not reply for all local addresses

The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface}

On 08/16/07 10:07, Pascal Hambourg wrote: > The default behaviour is to reply on any interface for any local > address. It can be changed on a per-interface basis with the kernel > parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions > and values are in Documentation/networking/ip-sysctl.txt :

Ok, so this can be set up, it is just something that has to be turned on via /proc.

> arp_ignore - INTEGER > Define different modes for sending replies in response to > received ARP requests that resolve local target IP addresses: > 0 - (default): reply for any local target IP address, configured > on any interface > 1 - reply only if the target IP address is local address > configured on the incoming interface > 2 - reply only if the target IP address is local address > configured on the incoming interface and both with the > sender's IP address are part from same subnet on this interface > 3 - do not reply for local addresses configured with scope host, > only resolutions for global and link addresses are replied > 4-7 - reserved > 8 - do not reply for all local addresses > > The max value from conf/{all,interface}/arp_ignore is used > when ARP request is received on the {interface}

If I understand the OP and what you have provided here correctly I believe the OP would simply want to issue the following commands:

On Thu, Aug 16, 2007 at 10:27:32AM -0500, Grant Taylor wrote: > On 08/16/07 10:07, Pascal Hambourg wrote: > > The default behaviour is to reply on any interface for any local > > address. It can be changed on a per-interface basis with the kernel > > parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions > > and values are in Documentation/networking/ip-sysctl.txt : [...] > So I can correctly update my references, where did you copy and past > that documentation from?

On 8/16/07, Grant Taylor <gtaylor [at] riverviewtech> wrote: > On 08/16/07 10:07, Pascal Hambourg wrote: > > The default behaviour is to reply on any interface for any local > > address. It can be changed on a per-interface basis with the kernel > > parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions > > and values are in Documentation/networking/ip-sysctl.txt : > > Ok, so this can be set up, it is just something that has to be turned on > via /proc. > > > arp_ignore - INTEGER > > Define different modes for sending replies in response to > > received ARP requests that resolve local target IP addresses: > > 0 - (default): reply for any local target IP address, configured > > on any interface > > 1 - reply only if the target IP address is local address > > configured on the incoming interface > > 2 - reply only if the target IP address is local address > > configured on the incoming interface and both with the > > sender's IP address are part from same subnet on this interface > > 3 - do not reply for local addresses configured with scope host, > > only resolutions for global and link addresses are replied > > 4-7 - reserved > > 8 - do not reply for all local addresses > > > > The max value from conf/{all,interface}/arp_ignore is used > > when ARP request is received on the {interface} > > If I understand the OP and what you have provided here correctly I > believe the OP would simply want to issue the following commands: > > echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore > echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore > echo 1 > /proc/sys/net/ipv4/conf/eth2/arp_ignore > > This should configure the interfaces to only respond to ARP requests for > their own IP address(s) (not other interfaces IP address(s)) correct? > > Thus the kernel would take care of what the OP is wanting to do and the > there would be no need for ARP / IPTables, correct? > > So I can correctly update my references, where did you copy and past > that documentation from? > > > > Grant. . . . > > do these rules apply for logical interfaces also? because in my actual case I would be having 127.x.x.x ips on my physical interfaces and actual ips on logical interfaces. for example: eth0 - 127.2.3.4 eth0:0 - 10.19.0.102 is there any command which can turn on these flags permanently such that I dont have to do it on every reboot of the machine?

Logical as in aliased interfaces or logical as in VLAN interfaces? I don't _think_ they apply to aliased interfaces other than the fact that the IP(s) will be different. VLANs will need their own rules though as they are a pseudo physical interface.

Um, be careful using 127.x.y.z/8 on any thing other than the loop back as I think there are hard coded filters in the kernel to protect the loop back. I don't know if it is to protect the IP range or the subnet that is assigned to the loop back interface. Just be aware....

> is there any command which can turn on these flags permanently such > that I dont have to do it on every reboot of the machine?

Um, there are some config files on some distros that have this option per say. Rather that is to say that they read the file and set the parameters on boot on your behalf. As far as how to set them and not have them be set on boot, I'm sure you could modify the kernel source.