On Thu, Mar 31, 2016 at 6:32 PM, Ramu Ramamurthy <ramu.ramamur...@gmail.com> wrote:
> > > > On a separate but related topic, northd programs localnet to not respond > to > > regular > > arp requests coming from the network via a localnet port. > > > > How can IP traffic be initiated from a VM outside OVN control or from the > > physical network to a VM inside OVN controlled HV, connected via a > localnet > > port ? > > > > Traffic initiated from VM1 outside OVN to VM2 inside OVN would flow as > follows: > > VM1 would first arp for VM2's IP. This arp is a broadcast, and would > enter br-int via the > localnet patch on ALL hypervisors connected to that localnet. br-int > "floods" that arp > to all locally attached VIFs on that localnet datapath. This is the part I was really interested to make explicit For localnet: all incoming arp requests, reach all VMs on all HVs attached to a given localnet > VM2 happens to > be one of those VIFs. > VM2 receives that arp, and replies back. > > As a result of the above interaction, external switches would learn > (port->source mac) bindings > and the external router would learn the arp mappings (IP->mac) > The problem is that port->source mac binding is cached for 5 minutes > at switches, and the arp > binding is cached for 4 hours by some routers !! > You can't depend on any particular timeout for either; both are configurable The below scenarios are normal gARP use cases > > During that period, consider the following 2 scenarios: > > 1) VM2 moved between hypervisors due to migration and stayed silent. > VM2 cannot be > accessed externally due to stale port->mac mappings for several > minutes. Eventually, > the mac-learning entry ages out and the switch treats VM2's mac as unknown > and > floods it as unknown unicast. > > OR > > 2) VM2 got deleted, and VM3 is booted within OVN, and VM3 has the same IP > as VM2 > BUT a different mac, AND VM3 stayed silent. > VM3 cannot be accessed externally due to stale arp mapping at a router > for several hours !. > Eventually, the router would ageout its arp entry, and then, the > router would ARP for VM3's IP, > and traffic to VM3 is successfully established. > > So, the problem addressed by this code change ONLY handles the corner > cases of stale mac-learning > entries at switches or stale arp entries at routers. > > > > Are you depending on flooding the network with gARPs periodically (to > handle > > new external hosts) for all VMs on all HVs inside OVN, attached to > localnet > > ? > > No, the gARP is sent only a few times when a logical port on localnet > comes up > to handle the special corner case (of stale mac-learning or arp > caches) described above. > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
