I'm hoping someone will have an idea or a solution to this... It's not exclusively a linux issue, but I am using arpwatch on linux so....

Here's the deal:

At work, I've been testing out an arpwatch server. At the moment it is on our dev environment which is all on one VLAN/subnet. Arpwatch has been running great and I've been notified when new machines get added to our dev environment. But one VLAN and (and only dev at that) is not using the application to any true potential. Ideally, I'd *like* to use arpwatch as a backup method for making sure added servers are inventoried properly...as standards are not always practices.

So the goal is: have 1 server running arpwatch on a VLAN (ie VLAN36) be able to recieve arp broadcasts from servers on OTHER VLAN/Subnets (ie VLAN20, VLAN28, etc)

By default of course a VLAN acts as a broadcast domain, so how could the network be used to make sure the arpwatch server gets other VLAN's arp broadcasts?

The three ideas I came up with (with some added help from on of our network guys) was to either use IPHelper (Cisco IOS function) and add the IP of the arpwatch server to the IPHelper address list, efectively forwarding broadcasts to the arpwatch server. Usually IPHelper is used for DHCP/BOOTP, WINS, etc, but I was told that arp broadcasts *should* be able to be forwarded as well. However, this solution adds a bit of overhead in adding the server's IP address to each necessary VLAN's IP Helper.

Another idea I still have yet to get a straight answer on is whether a Cisco switchport (port the arpwatch server is in) could be added to multiple VLANs, efectively recieving broadcasts from all VLAN's the port belongs to.

The last far-stretch idea I had was to compile kernel with 802.1q support, set the port to the arpwatch server as a trunk, and then add virtual ethernet interfaces for each VLAN...but that is a bit cumbersome as well. And I'm not sure of the network ramifications if something was incorrectly configured on the server end. I've seen an incorrectly configured switch with spanning tree, bring down the whole network, so..... plus, I'm not sure arpwatch could listen on all virtual interfaces...something I'd have to check on as well.

I realize that having a port in multiple VLANs defeats the purpose of a VLAN, and it would probably create some network loop issue (spanning tree should take care of?)

So in the end, I suppose it mainly comes down to: "can the network do what I want it to, and has anyone heard of a similar implementation of arpwatch?"


FYI: running arpwatch 2.1a13 on a RedHat 9 server.