On Thu, Mar 31, 2016 at 11:26 AM, Ramu Ramamurthy <ramu.ramamur...@gmail.com > wrote:
> > Problem: > When a VM comes up with interface on localnet, external > switches on the broadcast segment have to update their > port->mac mappings and routers have to update their arp caches. > This normally happens when the VM initiates traffic. > on the localnet interface. But in some scenarios, when the > VM remains silent, the VM is unreachable externally. This can > happen when the VM is migrated or when the VM is reusing an earlier used > IP but with a different mac. The fix is to for OVN to initiate gratuitous > ARP > which updates external routers/switches on localnet. > > This problem has been reported at: > https://bugs.launchpad.net/networking-ovn/+bug/1545897 > > What to generate: > When ipv4 and mac are defined on the port, we can generate a gratuitous ARP > request or a reply. ARP requests seem to be preferred over ARP replies > as suggested here: > https://tools.ietf.org/html/rfc5227#section-3 > In this change, a broadcast garp reply is generated. > Why did you choose to use reply packets ? request packets are less likely to be rejected by external networks and I think thats discussed in the RFC > > How many to generate: > 3 to 5 arps spaced over 1-2 minutes seems to be reasonable to allow > for losses. For comparison qemu generates 5 rarps when a VM port comes up. > > In this change, the garp packet is input to the port, and goes through > the pipelines. An alternative is to output directly > onto the localnet patch port. > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
