[ovs-dev] [PATCH RFC 0/3] - send garp on localnet

Darrell Ball dlu998 at gmail.com
Fri Apr 1 05:08:32 UTC 2016


On Thu, Mar 31, 2016 at 6:32 PM, Ramu Ramamurthy <ramu.ramamurthy at 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.
>


More information about the dev mailing list