ifcfg-eth0.200 is not responding to arp broadcasts

Question

I have a Centos router doing a stupendous job in a setup similar to this:

eth0 --> no IP
eth0.200 --> 192.168.200.1
eth0.201 --> 192.168.201.1
... so on up to
eth0.213 --> 192.168.213.1

I have ipv4 forwarding enable to allow intervlan routing, and then:

eth1 --> no IP
eth1.201 --> 10.1.29.40
eth0.202 --> 10.1.29.48
... so on up to
eth0.213 --> 10.1.29.136

iptables does SNAT when any of the eth0 networks seeks something out from the Internet, using the range of IPs from 10.198.29.138 to 10.198.29.142 as public IPs. Everything works great. The problem is that I need VLAN interface 192.168.200.1 to reside in eth1. When I move it to ifcfg-eth1.200, I can see in a packet capture that many clients try to fill their ARP tables by asking which MAC address belongs to 192.168.200.1, but eth1.200 never replies! I see other eth0.XXX responding to ARP broadcasts, but not 200. Could it be an iptables thing, or something else?

My iptables looks like this: enter image description here

EDIT/RESOLUTION SUMMARY BIG THANKS TO DAVID HOUDE FOR HIS COMMENT

I was able to experiment myself while troubleshooting a different issue, what the sysctl -w net.ipv4.conf.eth0/202.rp_filter=0 command does:

          SERVER
     <==eth0||eth1==>
  MAC FF:11 || MAC FF:22
 IP 1.1.1.1 || IP 3.3.3.1

if eth0 receives an ARP request for 3.3.3.1, SERVER is not going to reply to it by default. After disabling the reverse path filter, SERVER replies to ARP requests ON eth0 saying "hey, IP 3.3.3.1 is on MAC FF:11", while in reality, its on eth1.

Then the next packet arrives on eth0 destined to MAC FF:11 and IP 3.3.3.1, and because of the routing table, everything going back to a 3.3.3.x IP would go out eth1, so my packets were getting lost in a black hole, but thats another story.

In my case, I have something more like this:

          SERVER
     <==eth0||eth1==>
  MAC FF:11 || MAC FF:22

<==eth0.200 || eth1.200==>
 IP 3.3.3.1 || IP 1.1.0.1

<==eth0.201 || eth1.201==>
 IP 1.1.1.1 || IP 3.3.3.9

<==eth0.202 || eth1.202==>
 IP 1.1.2.1 || IP 3.3.3.17

<==eth0.203 || eth1.203==>
 IP 1.1.3.1 || IP 3.3.3.25

<==eth0.204 || eth1.204==>
 IP 1.1.4.1 || IP 3.3.3.33

so on until eth0.213. The problem is, that as you can see, the 1.1.0.0 network is on eth1 while 3.3.3.0 is on eth0, and the rest of the networKs are inverted.

I hope from what I found later with the suggested sysctl command, that if RPF is disabled, SERVER would at last reply those ARP packets requesting 1.1.0.1 MAC on eth1.200, but unfortunately I won't be able to confirm.

I can actually confirm that this command can be run on the affected subinterfaces only and they will apply the changes immediately.

David Houde · Accepted Answer · 2014-11-20T13:08:27.897

Linux is designed to respond to ARP requests on any interface. It is assumed that the host owns the IP address and not the particular interface. What you are seeing is called ARP Flux.

If your interfaces exist on the same Layer 2 Broadcast Domain, you will see this. You mention that you are using VLAN's which should make this not true, but that depends on where the VLAN is being tagged (by the OS or switch, etc).

You can change this behavior in Linux using sysctl

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

Edit: After re-reading your question, it sounds like you may need to disable reverse path filter on each NIC.

sysctl -w net.ipv4.conf.eth0/102.rp_filter=0
sysctl -w net.ipv4.conf.eth0/103.rp_filter=0

ifcfg-eth0.200 is not responding to arp broadcasts

1 Answers1