On Fri, Jan 11, 2019 at 12:09 AM Numan Siddique <[email protected]> wrote:
> > > On Fri, Jan 11, 2019 at 12:07 AM Han Zhou <[email protected]> wrote: > >> >> >> >> On Thu, Dec 20, 2018 at 5:34 AM Numan Siddique <[email protected]> >> wrote: >> > >> > >> > >> > On Wed, Dec 19, 2018 at 4:23 PM Miguel Angel Ajo Pelayo < >> [email protected]> 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 <[email protected] 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. > > Please note that, CMS configures the source MAC to use when ovn-controller sends the DHCP response (with the put_dhcp_opts action). So we will see MAC flap issue for this MAC configured and not for the logical router port MAC. Thanks Numan > 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 >> >>> [email protected] >> >>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
