Ethernet – Wireshark Etherent II Trailer field

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.

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:

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 have seen this a few times, where manufacturers are lazy and store MAC addresses in CMOS or similar, and fall back to a common default. It would also be easy to arrange if using locally assigned addresses (e.g. when provisioning VMs)

1. I've not tested what individual OSs do. If your only problem is ARP, then static ARP entries might work for you.

   2. Some old DEC systems used to send loopback packets to their own address, as a duplicate address check. I believe some Cisco switches do the same for loop detection. Either way, it's a special case of destination MAC filtering. If the address wasn't in the cache, I wouldn't be sure that first packet would be dropped immediately: it might be added to the forwarding tables and forwarded. Otherwise, silently drop.

   3. The MAC address would flap; if you are running a stateless protocol at the higher levels, you may end up with something like a crude unicast load balancer. For something like TCP, you'll get a lot of RST's as well as packet loss. And as others have said, to an 'enterprise' switch it looks like MAC spoofing and some may log/trap on this event.