Sorry for the late comment, but this issue is still present in Ocata. Unfortunately I can't confirm/deny its presence for later versions just yet, but if it would have been fixed, I don't see why the patch hadn't been ported to Ocata -> so I'm assuming it's present in later versions, too, unless it has been fixed silently.
Anyway, could you please reopen this Nate?
I think in the meantime, we'll have to resort to an ebtables rule hotfix to just drop ARP packets with the virtual router gateway source MAC address coming from "outside" the host. Turns out that a rogue ARP response may come from the other DVRs even when not using static routes in routers - but that's normal, since every once in a while, a host with its default GW set to the router's interface will ask for its MAC.
Sorry for the late comment, but this issue is still present in Ocata. Unfortunately I can't confirm/deny its presence for later versions just yet, but if it would have been fixed, I don't see why the patch hadn't been ported to Ocata -> so I'm assuming it's present in later versions, too, unless it has been fixed silently.
Anyway, could you please reopen this Nate?
I think in the meantime, we'll have to resort to an ebtables rule hotfix to just drop ARP packets with the virtual router gateway source MAC address coming from "outside" the host. Turns out that a rogue ARP response may come from the other DVRs even when not using static routes in routers - but that's normal, since every once in a while, a host with its default GW set to the router's interface will ask for its MAC.