My test switch is an EX4300 running 17.3R3-S4.2. I have not put a license on it yet. For all intents and purposes, this is an out-of-the-box switch with the bare minimum configuration.
My team and I are currently migrating from a non-Juniper switch platform to the EX4300s. We use a layer 3 access design with dual L3 uplinks. Overall process for migration is to put in a layer 2 interregion between the two switches to share the production VLANs, establish an OSPF adjacency for a layer 3 interregion, then migrate one of the layer 3 uplinks to the EX4300. For the production VLANs, we would use an FHRP between them, but we don't have a compatible protocol (old switch does not support VRRP). So migration has been by disabling the VLAN interface on the old switch, then turning up the irb interface on the EX4300. This causes a brief outage during the commit, but it's outside business hours. At this point, all devices are still connected to their VLANs on the old switch.
Many devices come back automatically, albeit with a short delay. However, the VoIP telephones take upwards of 20 minutes -- which looks suspiciously like an ARP issue, not getting the new gateway MAC address.
On my test switch, when I bring up the irb interface, I get a GARP request, which is for duplicate address detection. However, I cannot get Junos to send a GARP reply. The old switch sends a GARP reply to cause connected devices to update their ARP tables and it works beautifully.
I've learned the gratuitous-arp-reply option is for the EX to update its own ARP table when it hears a GARP reply.
I've learned the no-gratuitous-arp-request option is so the EX does not reply to GARP requests it hears.
But I can't find anything to make the EX send a GARP reply, like the old switch does, to update the ARP tables on the telephones.
Any thoughts on this? Is there a configuration option I'm missing or is it a Junos design thing and I'm Sorta Outta Luck? Should the telephones be taken the GARP request and handling it the same as a GARP reply (updating their ARP tables)? Also, is the fact that I don't have a license on this test switch a factor? The production EX switches are properly licensed. I've done a capture off of my test switch, but not off the production EX.
Thank you for your reply!
I will readily admit that, being substantially single-vendor in the past, I've only seen things done one way. In my previous readings on GARP, I'd come away with a sense that, while the standard said either request or reply was acceptable, the industry had informally standardized on a reply. And I came to understand the request was used in duplicate address detection. Seems I need to revisit those "senses."
My first thought would be a ping to the broadcast address from the switch. Even if the telephones don't reply to the broadcast ping itself, they'll still see the source IP and the source MAC. But again, I need to test this.
Fortunately, this is a limited-scope problem. Migrating the telephones to the new switch solves the problem. Or, theoretically, just bouncing the port. But knowing the "why" is helpful in the future. So, again, thank you for your replies!