Switching

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.

 

Hi farrenkm, Gratuitous ARPs can be either implemented as requests or replies, and Junos uses requests. Whether it's with VRRP mastership change or ethernet/irb interface IP change. You are correct there are knobs to ensure that GARP requests are sent out on ethernet interfaces and to update ARP cache of the Juniper switch when receiving GARP replies. The following references discuss the use-cases of GARP and the the two knobs. https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ip-gratuitous-arps-transmission-overview.html https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-gratuitous-arp.html Another useful knob for VRRP failover case is "set system arp passive-learning": https://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/vrrp-passive-arp-learning-for-backup-routers-configuring.html or https://kb.juniper.net/InfoCenter/index?page=content&id=KB31350&cat=EX3300&actp=LIST In your case, if the phones are implemented to only update their cache with GARP replies, my guess is they may not be configurable otherwise. However please feel free to check. Since this is a one-time thing needed for smooth migration, a dirty idea would be to have these IPs pinged for faster ARP updates. Or leave a RPM probe with ICMP test running for these phone IPs :P. Just throwing it out as a workaround if you didn't find anything else more feasible. Remove it later as it's just meant for monitoring an IP/performance, but may serve the purpose in our case.: https://www.juniper.net/documentation/en_US/junos/topics/example/security-basic-rpm-probe-configuring.html Hope this helps. Regards, -r. -------------------------------------------------- If this solves your problem, please mark this post as "Accepted Solution." Kudos are always appreciated :).

Hi farrenkm, Also, there's a knob to enable "set system arp gratuitous-arp-on-ifup" if the EX isn't sending GARP request by default when interface comes up. Then check if the phones react to it or not. Another possibility is to temporarily shorten the ARP aging timer (default 20mins) i.e. "set system arp aging-timer <>" but that's not ideal as it adds to the traffic on the network, should be reverted after the migration goes smooth if at all used. Hope some or one of this suggestion helps. Regards, -r. -------------------------------------------------- If this solves your problem, please mark this post as "Accepted Solution." Kudos are always appreciated :).

Hi mriyaz,

 

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!