I have an application in mind that will stretch the current ARP code farther
than it will go (I think.)
Basically, I want to have many (100+) interfaces, each with 1-4 IP addresses
hanging
off of them. I don't want the box to use an IP address out of the 'real'
address space
for each interface, and I don't want to use subnets.
Currently, I have a prototype with only 3-4 interfaces doing this with ARP-proxy
and host routes.
The problem is that, as far as I can tell, for every new interface I add (and
it's associated IP(s)),
I will have to add proxy-arp statements to every other interface for these
IP(s).
This obviously doesn't scale well to 100+ interfaces.
So, I was thinking of implementing some sort of arp-proxy scheme where you could
have two chains of rules, accept and deny. Each entry would have an IP/MASK
associated
with it.
Basically, if you passed the accept, and you did not fail the deny rules, then
the box will proxy for that IP. The rules should be ordered so that the more
specific rules out-weigh the more generic (ie less significant MASK bits) rules.
That should allow me to do something like:
for each interface
accept all ARP proxy
deny ARP proxy for all IPs assigned to that interface
add host route for each IP assigned to that interface
done
So, can this be done with current code? If not, can anyone suggest a good place
to hack this into the kernel (user space daemon?) I looked at ipv4/arp.c and
core/neighbour.c, but I haven't found where the decision is made whether or not
to proxy for an IP.
Thanks,
Ben
--
Ben Greear greearb@xxxxxxxx Pager: 202-2717
(623) 581 4980 "More weight!" -- _The Crucible._
http://hydrogen:8080/home/greearb/public_html/index.html
|