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:
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 18.104.22.168 || IP 22.214.171.124
if eth0 receives an ARP request for 126.96.36.199, 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 188.8.131.52 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 184.108.40.206, 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 220.127.116.11 || IP 18.104.22.168 <==eth0.201 || eth1.201==> IP 22.214.171.124 || IP 126.96.36.199 <==eth0.202 || eth1.202==> IP 188.8.131.52 || IP 184.108.40.206 <==eth0.203 || eth1.203==> IP 220.127.116.11 || IP 18.104.22.168 <==eth0.204 || eth1.204==> IP 22.214.171.124 || IP 126.96.36.199
so on until eth0.213. The problem is, that as you can see, the 188.8.131.52 network is on eth1 while 184.108.40.206 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 220.127.116.11 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.