GLBP doesn't use gratuituous ARP. When someone asks which MAC does the virtual IP have, the AVG will reply saying "This IP is at this MAC", using the field "Sender MAC Address", which is invisible to the switch's CAM table. The source address is still the AVG MAC.
EDIT: I said it wrong. The IP address requested is actually the Sender, the Target address is the address of the host that sent the arp request in the first place. I'll just upload here an example of ARP Request and Reply and when I get home I'll simulate on GNS so you can see how it really works and not just an example capture.
![enter image description here](https://i.stack.imgur.com/TastL.png)
Cadant device asks which is the MAC for x.x.128.77 and if anyone has the answer, please direct it to x.x.128.164.
Oracle device then replies with a broadcast saying that x.x.128.77 is himself, at the MAC 00:14:4f:fb:c3:16, at the sender MAC address. The target is x.x.128.164, who was the one requesting.
If this was the case of a GLBP host, it would state the virtual MAC in the sender MAC address field. It's called Proxy ARP. Just hold tight, I'll upload the actual GLBP capture in about 10 hours.
GLBP Capture:
R2 is the AVG, R1 the AVF:
![enter image description here](https://i.stack.imgur.com/5SJZs.png)
HOST 192.168.0.200 asked for the MAC of 192.168.0.1, the GLBP VIP. He received an answer from C001.3270.0000, which is the real MAC of the interface fa0/0 from R2, stating that 192.168.0.1 was located at 0007.B400.0101, one of the virtual MAC .
Later on, HOST 192.168.0.201 asked for the MAC of 192.168.0.1 and received an answer from the same C001.3270.0000 saying that this IP was with the MAC 0007.B400.0102, the other virtual MAC. Wireshark even throws a yellow line saying that "Hey, lookout, this IP is in use by another host".
When issuing "show glbp" from both routers, the AVG output have a little more detailing, including how many times it answered and ARP request with this or that virtual MAC address. You can see the MAC and IP addresses of the interfaces in "Group Members", present in both outputs.
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.
![HP Port-security Static](https://i.stack.imgur.com/ZQsVF.png)
Best Answer
Switches don't use ARP to learn MAC addresses. Switches lean which MAC address is on which port simply by inspecting the source addresses on frames which come into the switch ports.
Switches don't understand layer-3 (except for layer-3 switches). To the switch, a router is just another host on the LAN.
All the above is from the perspective of layer-2 switch operation. A switch may have a management address, but, again, this is just another host on the LAN, and the management will use ARP and have a configured gateway and learn its MAC address with ARP, but it really has nothing to do with how the switching operates.
A host wishing to send an IP packet to another host will look in its ARP cache for the MAC address. If there isn't an entry in its ARP cache, it will send an ARP request to resolve the layer-3 IP address to the layer-2 MAC address. It will then build a layer-2 frame with this information and send it to the switch. If the destination IP address is on a different network, the host will look for the MAC address of its configured gateway in its ARP cache, and send an ARP request if it isn't in there, build a frame and send it out, just as it would for any other host.
As the frames come into the switch, the switch will look at the source MAC addresses, and use that to build its MAC address table, not the same as an ARP cache. When a switch receives a frame with a destination MAC address which isn't in its MAC address table, it will flood the frame out every port; it does not use ARP requests to discover this. It doesn't take a switch very long to build its MAC table since it take only one frame from each host to populate the MAC address table.