arpmac address
I have a peripheral device, connected via Ethernet to my Ubuntu. I would like to find out its IP, and untofetunately no it is not cached in my ARP table.
ARP broadcasts the messages to every reachable MAC-Address, right? So without a brute-force style scanning, I expect ARP protocol to be able to broadcast a request from my laptop, and I expect the peripheral to answer and show its IP.
Is there such a functionality, and if not, is there a good reason?
Edit 2:
As you mentioned...
ip route 10.1.0.0 255.255.0.0 iface0
Forces the Brocade to proxy-arp for every destination in 10.1.0.0/16 as if it was directly connected to iface0.
I can't respond about Brocade's ARP cache implementation, but I would simply point out the easy solution to your problem... configure your route differently:
ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP
By doing this, you prevent the Brocade from ARP-ing for all of 10.1.0.0/16 (note, you might need to renumber the link between R1 and R2 to be outside 10.1.0.0/16, depending on Brocade's implementation of things).
Original answer:
I expect that in most, or even all, implementations, there is a hard limit on the capacity of the ARP table.
Cisco IOS CPU routers are only limited by the amount of DRAM in the router, but that is typically not going to be a limiting factor. Some switches (like Catalyst 6500) have a hard limitation on the adjacency table (which is correlated to the ARP table); Sup2T has 1 Million adjacencies.
So, what happens when the ARP cache is full and a packet is offered with a destination (or next-hop) that isn't cached?
Cisco IOS CPU routers don't run out of space in the ARP table, because those ARPs are stored in DRAM. Let's assume you're talking about Sup2T. Think of it like this, suppose you had a Cat6500 + Sup2T and you configured all Vlans possible, technically that is
4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans
Assume you make each Vlan a /24 (so that's 252 possible ARPs), and you pack every Vlan full... that is 1 Million ARP entries.
4094 * 252 = 1,030,680 ARP Entries
Every one of those ARPs would consume a certain amount of memory in the ARP table itself, plus the IOS adjacency table. I dont know what it is, but let's say the total ARP overhead is 10 Bytes...
That means you have now consumed 10MB for ARP overhead; it still isn't very much space... if you were that low on memory, you would see something like %SYS-2-MALLOCFAIL.
With that many ARPs and a four hour ARP timeout, you would have to service almost 70 ARPs per second on average; it's more likely that the maintenance on 1 million ARP entries would drain the CPU of the router (potentially CPUHOG messages).
At this point, you could start bouncing routing protocol adjacencies and have IPs that are just unreachable because the router CPU was too busy to ARP for the IP.
I guess what I'm asking for is, does a solution exist where a single host can cause an unknown NIC MAC Address to respond so as to populate the switch MAC Table? Or another solution that could get this data?
Let's step back for a moment and think about how switches work.
If a switch doesn't know the destination mac-address in a frame, the switch floods the frame with the unknown destination mac out all ports in that vlan; thus you do not need the switch to know the mac-address of the hosts while the host is powered down.
However, you do need to know the mac-address of all PCs in question; that mac-address is embedded in the WOL frame. Quite honestly, knowing the list of macs is pretty simple... just poll your edge router for arp entries for the Vlan(s) in question every five minutes, and store the results somewhere.
Now when you're ready to wake computers up, build a unique list of macs from your archived ARP tables and send a WOL frame to each unique mac; and if you send a WOL frame to a printer that's already up, who cares?
FYI, I built a python WOL packet crafter if it's at all helpful... you'll need linux or another *nix to use it though. Run in cygwin or a VM if you like...
If you really hate the idea of scraping and archiving your ARP table, another option is HP Port-Security with Static mac-learning... that makes the switch remember the mac it learned on a port and then it saves the mac in the running / startup configurations.
Best Answer
ARP requests are broadcast, ARP replies are normally unicast.
That's not how ARP works. ARP resolves the MAC address for a given IP address.
For the other way around RARP was defined which resolved a given MAC address to one or more IP addresses. In contrast to ARP, RARP didn't work via broadcast but required a server. Its adoption was low and it was obsoleted when BOOTP and DHCP became popular - you can use a reservation on those to assign the desired IP address to a given MAC address.
There's also Inverse ARP, but I don't think it's ever been used.
In a nutshell: if there's no DHCP server you can ask you have to do a brute-force scan or alternatively use a higher-layer discovery method. For instance, you could craft a UDP packet addressed to 255.255.255.255 (or directed broadcast) in a unicast Ethernet frame.
As Ron Maupin has pointed out in his comment, the best practice and future-proof (IPv6) way to discover another machine is to use IP multicast. With according network configuration multicast may even work across routers.