Re: [ovs-discuss] Connecting two servers over layer 2 openvswitch without encapsulation
Ben, when I build a cluster database on a layer 3 network, I can push packets between cluster database nodes at MTU 1500 or use jumbo frames if I set that up and use MTU 9000. But when I cluster databases over layer 2, I have to use something like MTU 1420 or MTU 8920 which databases typically do not like and do not play well with at least in my experience. So that's what I'm asking really. But afaik encapsulating packets and using MTU 1420 or MTU 8920 is kind of a fundamental principle on layer 2 over layer 3, kind of like e=mc2 inescapable a fundamental principle that cannot be avoided. From: Ben Pfaff Sent: Thursday, November 12, 2020 11:44 PM To: Gilbert Standen Cc: ovs-discuss@openvswitch.org Subject: Re: [ovs-discuss] Connecting two servers over layer 2 openvswitch without encapsulation On Fri, Nov 13, 2020 at 05:29:10AM +, Gilbert Standen wrote: > So this may be a very dumb question, but is there any way to connect > two separate physical servers with layer 2 openvswitches on each > separate server over a physical layer 3 network without using an > encapsulation scheme (e.g. GRE, VXLAN, etc) ? There are many > workloads that are somewhat hobbled by having to use MTU other than > 1500 or 9000, such as database workloads, and so I'm asking this > probably dumb question, because just me, I cannot see how it is > possible to avoid encapsulation when pushing data between servers over > a layer 2 network running on a physical layer 3 network, but I thought > I would ask anyway. Thanks, Gilbert It appears that you have described what networks do anyway. No special configuration is needed. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Connecting two servers over layer 2 openvswitch without encapsulation
On Fri, Nov 13, 2020 at 05:29:10AM +, Gilbert Standen wrote: > So this may be a very dumb question, but is there any way to connect > two separate physical servers with layer 2 openvswitches on each > separate server over a physical layer 3 network without using an > encapsulation scheme (e.g. GRE, VXLAN, etc) ? There are many > workloads that are somewhat hobbled by having to use MTU other than > 1500 or 9000, such as database workloads, and so I'm asking this > probably dumb question, because just me, I cannot see how it is > possible to avoid encapsulation when pushing data between servers over > a layer 2 network running on a physical layer 3 network, but I thought > I would ask anyway. Thanks, Gilbert It appears that you have described what networks do anyway. No special configuration is needed. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Connecting two servers over layer 2 openvswitch without encapsulation
So this may be a very dumb question, but is there any way to connect two separate physical servers with layer 2 openvswitches on each separate server over a physical layer 3 network without using an encapsulation scheme (e.g. GRE, VXLAN, etc) ? There are many workloads that are somewhat hobbled by having to use MTU other than 1500 or 9000, such as database workloads, and so I'm asking this probably dumb question, because just me, I cannot see how it is possible to avoid encapsulation when pushing data between servers over a layer 2 network running on a physical layer 3 network, but I thought I would ask anyway. Thanks, Gilbert ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVS 2.11.1 RPM build from source fails on Oracle Linux 7.8 and 7.9
Hi, OVS 2.11.1 RPM builds and install fine on Oracle Linux 7.6, but on Oracle Linux 7.8 and 7.9 the RPM build fails with the following errors: In file included from lib/netlink-conntrack.c:27:0: /usr/include/linux/netfilter/nf_conntrack_sctp.h:25:2: error: unknown type name 'u8' u8 last_dir; ^ /usr/include/linux/netfilter/nf_conntrack_sctp.h:26:2: error: unknown type name 'u8' u8 flags; ^ make[2]: *** [lib/netlink-conntrack.lo] Error 1 make[2]: Leaving directory `/opt/olxc/home/ubuntu/Downloads/orabuntu-lxc-master/uekulele/openvswitch/rpmbuild/BUILD/openvswitch-2.11.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/olxc/home/ubuntu/Downloads/orabuntu-lxc-master/uekulele/openvswitch/rpmbuild/BUILD/openvswitch-2.11.1' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.s2PkRp (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.s2PkRp (%build) I've looked at these URLs below, but do not know how to make use of them to get the RPM build working on Oracle Linux 7.8 and 7.9 (I have not tested Oracle Linux 7.7 yet). https://bugzilla.redhat.com/show_bug.cgi?id=1890095 and https://github.com/openvswitch/ovs/commit/8c7130da98c55bdf13eae62b5250434f8dfd366b Is there a way I can get OVS 2.11.1 RPM to build successfully on Oracle LInux 7.8 and 7.9 and what is causing the problem? Thanks, Gilbert Standen Contributor Orabuntu-LXC ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVS 2.11.1 RPM build from source fails on Oracle Linux 7.8 and 7.9
Hi, OVS 2.11.1 RPM builds and install fine on Oracle Linux 7.6, but on Oracle Linux 7.8 and 7.9 the RPM build fails with the following errors: In file included from lib/netlink-conntrack.c:27:0: /usr/include/linux/netfilter/nf_conntrack_sctp.h:25:2: error: unknown type name 'u8' u8 last_dir; ^ /usr/include/linux/netfilter/nf_conntrack_sctp.h:26:2: error: unknown type name 'u8' u8 flags; ^ make[2]: *** [lib/netlink-conntrack.lo] Error 1 make[2]: Leaving directory `/opt/olxc/home/ubuntu/Downloads/orabuntu-lxc-master/uekulele/openvswitch/rpmbuild/BUILD/openvswitch-2.11.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/olxc/home/ubuntu/Downloads/orabuntu-lxc-master/uekulele/openvswitch/rpmbuild/BUILD/openvswitch-2.11.1' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.s2PkRp (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.s2PkRp (%build) I've looked at these URLs below, but do not know how to make use of them to get the RPM build working on Oracle Linux 7.8 and 7.9 (I have not tested Oracle Linux 7.7 yet). https://bugzilla.redhat.com/show_bug.cgi?id=1890095 and https://github.com/openvswitch/ovs/commit/8c7130da98c55bdf13eae62b5250434f8dfd366b Is there a way I can get OVS 2.11.1 RPM to build successfully on Oracle LInux 7.8 and 7.9 and what is causing the problem? Thanks, Gilbert Standen Contributor Orabuntu-LXC ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovn] non-maskable OVS meta-flow fields not correctly handled
Hi Ben, Thanks for your answer. Ben Pfaff: > On Thu, Nov 05, 2020 at 12:39:38PM +, ythomas1@orange.com wrote: > > I’m currently working on OVN to add MPLS logical fields (such as > > 'mpls_label', 'mpls_bos') to support BGP/MPLS technology. > > > > As indicated in 'mf_field' struct in meta-flow.h, most OVS meta-flow > > fields have n_bytes * 8 == n_bits size but there are few exceptions > > such as 'mpls_label', 'mpls_bos', etc… > > > > In OVN case, when calling 'mf_mask_subfield' method from meta-flow.c, > > for example for 'mpls_label' OVS meta-flow field which has 20 useful > > bits over 32 bits, the 'mask' value parsed in OVN is set to 0x00ff > > (which seems correct). > > OVN doesn't use that function much. I see one use in constrain_match(). I agree with the fact that there is only one use in constrain_match(), but this call to mf_mask_subfield() is used to set Openflow matches, converted from the OVN matches expression. > > I don't understand where 0x00ff comes from. The mask should not be > discontiguous like that. Sorry for the confusion, the actual value once in network byte order, has indeed only consecutive 1s (0x000f). > > > The problem is that in 'mf_set' method, 'mpls_label' OVS meta-flow > > field is supposed to only have a NULL, all-1-bits or all-0-bits 'mask' > > value to be set, as shown below: > > [...] > > > However, as mentioned in 'mf_set' method comment, “The caller is > > responsible for ensuring that 'match' meets 'mf''s prerequisites”. > > > > So, since the 'mpls_label' OVS meta-flow field is indicated as not > > maskable in meta-flow.h, shouldn't OVN ensure that 'mask' is set to > > NULL when calling 'mf_mask_subfield' ? > > The mask isn't a prerequisite. The prerequisite for mpls_label is that > the flow is an MPLS flow, that is, it has an MPLS ethertype. See > mf_are_prereqs_ok(). Ok. The issue does not indeed seem to be related to these prereqs. As shown in the following traces, we can see that mpls_label and mpls_bos fields are ignored in mf_set(). Their mask not being NULL or all-1-bits or all-0-bits, we are falling in the switch case where they are not handled (https://github.com/openvswitch/ovs/blob/master/lib/meta-flow.c#L2328). 2020-11-10T16:05:50.821Z|00192|lflow|INFO|CONSIDER_LOGICAL_FLOW -> OVN match to translate: mpls && mpls.bos == 1 && mpls.label == 18 2020-11-10T16:05:50.821Z|00193|meta_flow|INFO|MF_MASK_SUBFIELD -> Value [0x8847] and mask [0x] to copy to match 2020-11-10T16:05:50.821Z|00194|meta_flow|INFO|MF_MASK_SUBFIELD -> Updated match: mpls 2020-11-10T16:05:50.821Z|00195|meta_flow|INFO|MF_MASK_SUBFIELD -> Value [0x0001] and mask [0x0001] to copy to match 2020-11-10T16:05:50.821Z|00196|meta_flow|INFO|MF_SET -> mf_field [mpls_bos] value and mask not set, returning OFPUTIL_P_NONE 2020-11-10T16:05:50.821Z|00197|meta_flow|INFO|MF_MASK_SUBFIELD -> Updated match: mpls 2020-11-10T16:05:50.821Z|00198|meta_flow|INFO|MF_MASK_SUBFIELD -> Value [0x0012] and mask [0x000f] to copy to match 2020-11-10T16:05:50.821Z|00199|meta_flow|INFO|MF_SET -> mf_field [mpls_label] value and mask not set, returning OFPUTIL_P_NONE 2020-11-10T16:05:50.821Z|00200|meta_flow|INFO|MF_MASK_SUBFIELD -> Updated match: mpls So what should be the fix ? Should OVN ensure that the mask be set to all zeroes or all ones when calling mf_mask_subfield, or should mf_set be adjusted (e.g. treat mpls fields as 'a nontrivial mask' (to quote https://github.com/openvswitch/ovs/blob/master/lib/meta-flow.c#L2324 ) after introducing suitable match_set_mpls_label_masked/match_set_mpls_bos_masked/match_set_mpls_tc_masked/match_set_mpls_ttl_masked functions) ? Best regards, Yannick _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
