[ovs-dev] [PATCH v2 ovn] northd: allow explicit nat-addresses for distributed gw ports
Allow the CMS to explicitly configure nat addresses to use in
GARP advertising even if the logical switch port is connected
to a distributed gateway router port.
Signed-off-by: Lorenzo Bianconi
---
Changes since v1:
- rebase on top of ovn master
- add unit test
---
northd/northd.c | 15 +++
tests/ovn.at| 32
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index b264fb850..f94239b45 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -3385,6 +3385,8 @@ ovn_port_update_sbrec(struct northd_input *input_data,
"nat-addresses");
size_t n_nats = 0;
char **nats = NULL;
+bool l3dgw_ports = op->peer && op->peer->od &&
+ op->peer->od->n_l3dgw_ports;
if (nat_addresses && !strcmp(nat_addresses, "router")) {
if (op->peer && op->peer->od
&& (chassis || op->peer->od->n_l3dgw_ports)) {
@@ -3393,9 +3395,7 @@ ovn_port_update_sbrec(struct northd_input *input_data,
nats = get_nat_addresses(op->peer, _nats, false,
!exclude_lb_vips);
}
-/* Only accept manual specification of ethernet address
- * followed by IPv4 addresses on type "l3gateway" ports. */
-} else if (nat_addresses && chassis) {
+} else if (nat_addresses && (chassis || l3dgw_ports)) {
struct lport_addresses laddrs;
if (!extract_lsp_addresses(nat_addresses, )) {
static struct vlog_rate_limit rl =
@@ -3405,7 +3405,14 @@ ovn_port_update_sbrec(struct northd_input *input_data,
destroy_lport_addresses();
n_nats = 1;
nats = xcalloc(1, sizeof *nats);
-nats[0] = xstrdup(nat_addresses);
+struct ds nat_addr = DS_EMPTY_INITIALIZER;
+ds_put_format(_addr, "%s", nat_addresses);
+if (l3dgw_ports) {
+ds_put_format(_addr, " is_chassis_resident(%s)",
+op->peer->od->l3dgw_ports[0]->cr_port->json_key);
+}
+nats[0] = xstrdup(ds_cstr(_addr));
+ds_destroy(_addr);
}
}
diff --git a/tests/ovn.at b/tests/ovn.at
index 9b13a980d..32c812caa 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -8642,6 +8642,38 @@
f00108060001080006040001f001c0a80001c0a8
f00108060001080006040001f001c0a80002c0a80002
])
+# Temporarily remove nat-addresses option to avoid race conditions
+# due to GARP backoff
+ovn-nbctl lsp-set-options lrp0-rp router-port=lrp0 nat-addresses=""
+# Let's use gw router port now
+hv1_uuid=$(ovn-sbctl --bare --columns _uuid list chassis hv1)
+ovn-nbctl remove logical_router lr0 options chassis
+ovn-nbctl lrp-set-gateway-chassis lrp0 hv1 20
+OVS_WAIT_UNTIL([
+cr_lrp0_ch=$(ovn-sbctl --bare --columns chassis list port_binding cr-lrp0)
+test "$cr_lrp0_ch" = $hv1_uuid
+])
+ovn-nbctl lsp-set-options lrp0-rp router-port=lrp0
nat-addresses="f0:00:00:00:00:03 192.168.0.3"
+
+reset_pcap_file() {
+local iface=$1
+local pcap_file=$2
+ovs-vsctl -- set Interface $iface options:tx_pcap=dummy-tx.pcap \
+options:rxq_pcap=dummy-rx.pcap
+rm -f ${pcap_file}*.pcap
+ovs-vsctl -- set Interface $iface options:tx_pcap=${pcap_file}-tx.pcap \
+options:rxq_pcap=${pcap_file}-rx.pcap
+}
+
+reset_pcap_file snoopvif hv1/snoopvif
+OVS_WAIT_UNTIL([test `wc -c < "hv1/snoopvif-tx.pcap"` -ge 140])
+
+$PYTHON "$ovs_srcdir/utilities/ovs-pcap.in" hv1/snoopvif-tx.pcap | trim_zeros
> packets
+AT_CHECK([sort packets], [0], [dnl
+f00108060001080006040001f001c0a80001c0a80001
+f00308060001080006040001f003c0a80003c0a80003
+])
+
OVN_CLEANUP([hv1])
AT_CLEANUP
--
2.35.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS DPDK DMA-Dev library/Design Discussion
Hi All, The goal of this meeting is to ensure that all of DPDK DMA-dev library, DPDK Vhost library (consuming DMA-dev for acceleration) and OVS (as an end user of the DPDK DMA & VHost libraries) are working well together; and that the maintainers & contributors to those libraries are aware of the design & architecture in OVS consumption. https://meet.google.com/hme-pygf-bfb Thanks Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] flow: Consistent VXLAN UDP src ports for fragmented packets
Issue:
The src-port for UDP is based on RSS hash in the packet metadata.
In case of packets coming from VM it will be 5-tuple, if available,
otherwise just IP addresses.If the VM fragments a large IP packet
and sends the fragments to ovs, only the first fragment will contain
the L4 header. Therefore, the first fragment and subsequent fragments
get different UDP src ports in the outgoing VXLAN header.This can
lead to fragment re-ordering in the fabric as packet will take
different paths.
Fix:
Intention of this is to avoid fragment packets taking different paths.
For example, due to presence of firewalls, fragment packets will take
different paths and will get dropped.To avoid this we ignore the L4
header during hash calculation only in the case of fragmented packets.
P.S: There is already a review request raised for the same.
https://mail.openvswitch.org/pipermail/ovs-dev/2021-January/379395.html.
Re-iterating the same patch request on the latest master code.
Signed-off-by: Hemanth Aramadaka
---
lib/flow.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/flow.c b/lib/flow.c
index dd523c889..17bd47724 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -2238,7 +2238,7 @@ miniflow_hash_5tuple(const struct miniflow *flow,
uint32_t basis)
if (flow) {
ovs_be16 dl_type = MINIFLOW_GET_BE16(flow, dl_type);
-uint8_t nw_proto;
+uint8_t nw_proto,nw_frag;
if (dl_type == htons(ETH_TYPE_IPV6)) {
struct flowmap map = FLOWMAP_EMPTY_INITIALIZER;
@@ -2260,6 +2260,14 @@ miniflow_hash_5tuple(const struct miniflow *flow,
uint32_t basis)
nw_proto = MINIFLOW_GET_U8(flow, nw_proto);
hash = hash_add(hash, nw_proto);
+/* Skip l4 header fields if IP packet is fragmented since
+ * only first fragment will carry l4 header.
+ */
+nw_frag = MINIFLOW_GET_U8(flow, nw_frag);
+if ((nw_frag)) {
+goto out;
+}
+
if (nw_proto != IPPROTO_TCP && nw_proto != IPPROTO_UDP
&& nw_proto != IPPROTO_SCTP && nw_proto != IPPROTO_ICMP
&& nw_proto != IPPROTO_ICMPV6) {
--
2.25.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3] northd: Add support for NAT with multiple DGP
Hey Mark, Thanks for reviewing the patch. Regarding `ovn-nbctl lr-nat-del`, I have updated the command to have the following structure: `lr-nat-del ROUTER [TYPE [IP [GATEWAY_PORT]]]`. Most of the earlier checks are not enforced unless `GATEWAY_PORT` is also passed. With the new patch, a NAT rule is no longer uniquely identified by `TYPE` and `IP`. The user also needs to pass `GATEWAY_PORT` to uniquely identify a NAT rule. So, I have updated the behavior of `lr-nat-del` to not raise an error when `IP` is passed but no NAT rules match, similar to its behavior when `TYPE` is passed and no NAT rules match. Also, with the new patch, if `IP` is passed without passing `GATEWAY_PORT`, all NAT rules (possibly None) with the `TYPE` and `IP` values are deleted irrespective of their `GATEWAY_PORT` value. Should we retain the previous behavior of `lr-nat-del` when LR has a single DGP - raise an error if no NAT rules match when `IP` is passed? On 14 Mar 2022, at 20:55, Mark Michelson mailto:mmich...@redhat.com>> wrote: Hi Abhiram, I had a look through the code and I'm happy with how it looks. I also did a quick check through the testsuite and it all seems good. All that being said, I nearly acked this, but I have one question down below in the test code. It may indicate some issue in `ovn-nbctl lr-nat-del` so I'd like to get that cleared up first. -AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat_and_snat 30.0.0.3], [1], [], -[ovn-nbctl: no matching NAT with the type (dnat_and_snat) and external_ip (30.0.0.3) -]) -AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat 30.0.0.2], [1], [], -[ovn-nbctl: no matching NAT with the type (dnat) and external_ip (30.0.0.2) -]) -AT_CHECK([ovn-nbctl lr-nat-del lr0 snat 192.168.10.0/24], [1], [], -[ovn-nbctl: no matching NAT with the type (snat) and logical_ip (192.168.10.0/24) -]) -AT_CHECK([ovn-nbctl --if-exists lr-nat-del lr0 snat 192.168.10.0/24]) +AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat_and_snat 30.0.0.3]) I don't understand the above change. First, I don't understand why many of the lr-nat-del checks were removed. Second, I don't understand why the lr-nat-del of 30.0.0.3 doesn't return an error. There is no NAT with that address, so shouldn't that return an error? AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat_and_snat 30.0.0.1]) AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat_and_snat fd01::1]) ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK DSA Architecture/Design Discussion
> 15/03/2022 12:14, Stokes, Ian: > > > 15/03/2022 11:27, Stokes, Ian: > > > > Hi All, > > > > > > > > We'd like to put a public meeting in place for the stakeholders > > > > of DPDK and OVS to discuss the next steps and design of > > > > the DSA library along with its integration in OVS. > > > > > > There is no DSA library. > > > Do you mean the IOAT driver in DPDK for the DMA library? > > > > Apologies Thomas, > > > > DMA-Dev library is actually what's intended to be discussed to clarify. > > Will re-send the invite with the correct title. > > If you want to have a good number of attendees, > you should postpone to a later date, so we can plan in advance. > You also need to describe the problem to discuss. > That's really better to start with emails, and to have a summary > after the meeting. Agreed, we have a few people who can't make it today so will push to the same time next week. I'll also update the summary of what's to be discussed. So it's clearer. > > > > If it is just for discussing the Intel driver, no way I attend. > > > And even if it is for discussing the DMA library integration, > > > I don't understand why the DPDK community is required. > > > > > > If there is an issue with the library API, please tell it. > > > We need email discussions, not meeting request sent few hours in advance. > > > Ian, I know you are not a beginner in the community, what happens? > > So if I understand well, there is no urgent problem to discuss? No Immediate issues, but from what I understand a number of designs have been prototyped so their results and next steps should be discussed for an agreed approach from both communities to allow future use and integration. Thanks Ian > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS DPDK DMA-Dev library/Design Discussion
Hi All, We'd like to put a public meeting in place for the stakeholders of DPDK and OVS to discuss the next steps and design of the DMA-DEV library along with its integration in OVS. There are a few different time zones involved so trying to find a best fit. Currently the suggestion is 2PM Tuesday the 22nd. https://meet.google.com/hme-pygf-bfb The plan is for this to be a public meeting that can be shared with both DPDK and OVS communities but for the moment I've invited the direct stakeholders from both communities as a starting point as we'd like a time that suits these folks primarily, all are welcome to join the discussion. Thanks Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK DSA Architecture/Design Discussion
15/03/2022 12:14, Stokes, Ian: > > 15/03/2022 11:27, Stokes, Ian: > > > Hi All, > > > > > > We'd like to put a public meeting in place for the stakeholders > > > of DPDK and OVS to discuss the next steps and design of > > > the DSA library along with its integration in OVS. > > > > There is no DSA library. > > Do you mean the IOAT driver in DPDK for the DMA library? > > Apologies Thomas, > > DMA-Dev library is actually what's intended to be discussed to clarify. > Will re-send the invite with the correct title. If you want to have a good number of attendees, you should postpone to a later date, so we can plan in advance. You also need to describe the problem to discuss. That's really better to start with emails, and to have a summary after the meeting. > > If it is just for discussing the Intel driver, no way I attend. > > And even if it is for discussing the DMA library integration, > > I don't understand why the DPDK community is required. > > > > If there is an issue with the library API, please tell it. > > We need email discussions, not meeting request sent few hours in advance. > > Ian, I know you are not a beginner in the community, what happens? So if I understand well, there is no urgent problem to discuss? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS DPDK DMA-Dev library/Design Discussion
Hi All, We'd like to put a public meeting in place for the stakeholders of DPDK and OVS to discuss the next steps and design of the DSA library along with its integration in OVS. There are a few different time zones involved so trying to find a best fit. Currently the suggestion is 2PM Tuesday the 15th. https://meet.google.com/hme-pygf-bfb The plan is for this to be a public meeting that can be shared with both DPDK and OVS communities but for the moment I've invited the direct stakeholders from both communities as a starting point as we'd like a time that suits these folks primarily, all are welcome to join the discussion. Thanks Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK DSA Architecture/Design Discussion
> 15/03/2022 11:27, Stokes, Ian: > > Hi All, > > > > We'd like to put a public meeting in place for the stakeholders > > of DPDK and OVS to discuss the next steps and design of > > the DSA library along with its integration in OVS. > > There is no DSA library. > Do you mean the IOAT driver in DPDK for the DMA library? Apologies Thomas, DMA-Dev library is actually what's intended to be discussed to clarify. Will re-send the invite with the correct title. Thanks Ian > > If it is just for discussing the Intel driver, no way I attend. > And even if it is for discussing the DMA library integration, > I don't understand why the DPDK community is required. > > If there is an issue with the library API, please tell it. > We need email discussions, not meeting request sent few hours in advance. > Ian, I know you are not a beginner in the community, what happens? > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS DPDK DSA Architecture/Design Discussion
15/03/2022 11:27, Stokes, Ian: > Hi All, > > We'd like to put a public meeting in place for the stakeholders > of DPDK and OVS to discuss the next steps and design of > the DSA library along with its integration in OVS. There is no DSA library. Do you mean the IOAT driver in DPDK for the DMA library? If it is just for discussing the Intel driver, no way I attend. And even if it is for discussing the DMA library integration, I don't understand why the DPDK community is required. If there is an issue with the library API, please tell it. We need email discussions, not meeting request sent few hours in advance. Ian, I know you are not a beginner in the community, what happens? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVS DPDK DSA Architecture/Design Discussion
Hi All, We'd like to put a public meeting in place for the stakeholders of DPDK and OVS to discuss the next steps and design of the DSA library along with its integration in OVS. There are a few different time zones involved so trying to find a best fit. Currently the suggestion is 2PM Tuesday the 15th. https://meet.google.com/hme-pygf-bfb The plan is for this to be a public meeting that can be shared with both DPDK and OVS communities but for the moment I've invited the direct stakeholders from both communities as a starting point as we'd like a time that suits these folks primarily, all are welcome to join the discussion. Thanks Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
