On Fri, Jan 11, 2019 at 12:07 AM Han Zhou <zhou...@gmail.com> wrote: > > > > On Thu, Dec 20, 2018 at 5:34 AM Numan Siddique <nusid...@redhat.com> > wrote: > > > > > > > > On Wed, Dec 19, 2018 at 4:23 PM Miguel Angel Ajo Pelayo < > majop...@redhat.com> wrote: > >> > >> 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? > >>> > > > > You are right. If there are multiple external ports and their > "requested-chassis" are set to > > different chassis you would still see MAC flap issue. I would say CMS > should handle > > this situation and set the same "requested-chassis" for all external > ports. > > > > OK. So would it be better to document this consideration? >
Yeah. Sounds good to me. I will update the patch with the documentation. Thanks Numan > > > > >>> > >>> > 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"? > >>> > > > > As Miguel mentioned the traffic may be received by the compute host > where the SR-IOV VM > > is present if the host NIC is connected to the same switch. > > > > It is free to select any chassis as long as that chassis can receive the > broadcast packet. > > > > > > > >>> > >>> I will review in more detail later. > > > > > > Thanks > > Numan > > > >>> > >>> > >>> 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
