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. >> > 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
