(Sorry, top posting it) Hi Ihar,
I tested out your patch. All the tests pass. I then tested out using the ovn-fake-multinode [1]. After the deployment, I changed the encap to vxlan. East/West traffic worked fine without any issues.. But I was not able to ping to the gateway router port IP from outside (172.16.0.100). The moment I changed the encap back to geneve, the ping works. I didn't look into the issue. So not sure what's the reason. You may want to try out once with ovn-fake-multinode Thanks Numan [1] - https://github.com/ovn-org/ovn-fake-multinode/ On Tue, Mar 24, 2020 at 1:37 PM Numan Siddique <num...@ovn.org> wrote: > > On Tue, Mar 24, 2020 at 5:17 AM Ben Pfaff <b...@ovn.org> wrote: > > > > On Mon, Mar 23, 2020 at 06:39:14PM -0400, Ihar Hrachyshka wrote: > > > First, some questions as to implementation (or feasibility) of several > > > todo items in my list for the patch. > > > > > > 1) I initially thought that, because VXLAN would have limited space > > > for both networks and ports in its VNI, the encap type would not be > > > able to support as many of both as Geneve / STT, and so we would need > > > to enforce the limit programmatically somehow. But in OVN context, is > > > it even doable? North DB resources may be created before any chassis > > > are registered; once a chassis that is VXLAN only joins, it's too late > > > to forbid the spilling resources from existence (though it may be a > > > good time to detect this condition and perhaps fail to register the > > > chassis / configure flow tables). How do we want to handle this case? > > > Do we fail to start VXLAN configured ovn-controller when too many > > > networks / ports per network created? Do we forbid creating too many > > > resources when a chassis is registered that is VXLAN only? Both? Or do > > > we leave it up to the deployment / CMS to control the chassis / north > > > DB configuration? > > > > > > 2) Similar to the issue above, I originally planned to forbid using > > > ACLs relying on ingress port when a VXLAN chassis is involved (because > > > the VNI won't carry the information). I believe the approach should be > > > similar to how we choose to handle the issue with the maximum number > > > of resources, described above. > > > > > > I am new to OVN so maybe there are existing examples for such > > > situations already that I could get inspiration from. Let me know what > > > you think. > > > > I don't have good solutions for the above resource limit problems. We > > designed OVN so that this kind of resource limit wouldn't be a problem > > in practice, so we didn't think through what would happen if the limits > > suddenly became more stringent. > > > > I think that it falls upon the CMS by default. > > I agree. I think It should be handled by CMS. > > Thanks > Numan > > > > > > > > Assuming we pick a term to use to describe these out-of-cluster > > > > > switches, we should consider the impact of the rename. Renaming > > > > > internal symbols / functions is trivial. But "vtep" is used in OVN > > > > > schema (for example, for port binding 'type' attribute). Do we want to > > > > > rename those too? If so, what considerations should we apply when > > > > > doing it? Any guidance as to maintaining backwards compatibility? > > > > > > > > > > Also, is such a rename something that should happen at the same moment > > > > > when we add support for VXLAN for in-cluster communication? Or should > > > > > it be a separate work item? (If so, do we expect it to land before or > > > > > after the core VXLAN implementation lands?) > > > > > > > > We can't (or at any rate should not) change the terms in the schema, but > > > > we can change other places and point out to people in a few places that > > > > a "ramp switch" is sometimes, confusingly, called a "vtep". > > > > > > Gotcha. Any preferences as to whether to consider it a preparatory > > > work item; a follow-up; or a part of the VXLAN implementation? (I lean > > > towards handling the ramp term introduction as an independent > > > preparatory step.) > > > > I sent out a patch for people to look at. > > _______________________________________________ > > 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