Oh, if requested chassis matches the chasis of the SRIOV instance, then we don't need HA. Ignore my comments regarding multiple chassis.
And yes it's my understanding that the traffic will bounce to the host interface probably through the internal switch embedded in the SRIOV card, or, if the host uses a separate interface then via de Tor switch. On Wed, Dec 19, 2018, 1:54 AM Han Zhou <zhou...@gmail.com wrote: > Hi Numan, I haven't finished reviewing the whole patch yet, but I have some > questions inlined. > > > > + > > + <ul> > > + <li> > > + <p> > > + For each router port IP address <code>A</code> which belongs > to the > > + logical switch, A priority-100 flow is added which matches > > + <code>REGBIT_EXT_PORT_NOT_RESIDENT && arp.tpa == > <var>A</var> > > + && arp.op == 1</code> (ARP request to the router > > + IP) with the action to <code>drop</code> the packet. > > + </p> > > + > > + <p> > > + These flows guarantees that the ARP/NS request to the router > IP > > + address from the external ports is responded by only the > chassis > > + which has claimed these external ports. All the other chassis, > > + drops these packets. > > + </p> > > Could you explain more about how this solves > https://bugzilla.redhat.com/show_bug.cgi?id=1613384 > For my understanding, the logical router port MAC would still flap on the > physical switch ports, if there are multiple external ports and their > "requested-chassis" are set to different chassis. Or does this suggest > specifying a single chassis as "requested-chassis" for all external-ports? > > > > diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml > > index 3936e6016..37b97a0d9 100644 > > --- a/ovn/ovn-architecture.7.xml > > +++ b/ovn/ovn-architecture.7.xml > > @@ -1678,6 +1678,72 @@ > > </li> > > </ol> > > > > + <h2>Native OVN services for external logical ports</h2> > > + > > + <p> > > + To support OVN native services (like DHCP/IPv6 RA/DNS lookup) to the > > + cloud resources which are external, OVN supports > <code>external</code> > > + logical ports. > > + </p> > > + > > + <p> > > + Below are some of the use cases where <code>external</code> ports > can be > > + used. > > + </p> > > + > > + <ul> > > + <li> > > + VMs connected to SR-IOV nics - Traffic from these VMs by passes > the > > + kernel stack and local <code>ovn-controller</code> do not bind > these > > + ports and cannot serve the native services. > > + </li> > > Would the broadcast traffic (e.g. DHCP discover) sent out from SR-IOV come > back to the local host? Is it free to select either the local host or any > other hosts as the "requested-chassis"? Or does this suggest that we have > to use a different chassis other than the local host as the > "requested-chassis"? > > I will review in more detail later. > > Thanks, > Han > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
