[ovs-dev] [PATCH v3] ovn: Support a new Logical_Switch_Port.type - 'external'
From: Numan Siddique
In the case of OpenStack + OVN, when the VMs are booted on
hypervisors supporting SR-IOV nics, there are no OVS ports
for these VMs. When these VMs sends DHCPv4, DHPCv6 or IPv6
Router Solicitation requests, the local ovn-controller
cannot reply to these packets. OpenStack Neutron dhcp agent
service needs to be run to serve these requests.
With the new logical port type - 'external', OVN itself can
handle these requests avoiding the need to deploy any
external services like neutron dhcp agent.
To make use of this feature, CMS has to
- create a logical port for such VMs
- set the type to 'external'
- set requested-chassis="" in the options
column.
- create a localnet port for the logical switch
- configure the ovn-bridge-mappings option in the OVS db.
When the ovn-controller running in that 'chassis', detects
the Port_Binding row, it adds the necessary DHCPv4/v6 OF
flows. Since the packet enters the logical switch pipeline
via the localnet port, the inport register (reg14) is set
to the tunnel key of localnet port in the match conditions.
In case the chassis goes down for some reason, it is the
responsibility of CMS to change the 'requested-chassis'
option to some other active chassis, so that it can serve
these requests.
When the VM with the external port, sends an ARP request for
the router ips, only the chassis which has claimed the port,
will reply to the ARP requests. Rest of the chassis on
receiving these packets drop them in the ingress switch
datapath stage - S_SWITCH_IN_EXTERNAL_PORT which is just
before S_SWITCH_IN_L2_LKUP.
This would guarantee that only the chassis which has claimed
the external ports will run the router datapath pipeline.
Signed-off-by: Numan Siddique
---
v2 -> v3
---
* Rebased
ovn/controller/binding.c| 15 +-
ovn/controller/lflow.c | 41 ++-
ovn/controller/lflow.h | 2 +
ovn/controller/lport.c | 26 ++
ovn/controller/lport.h | 5 +
ovn/controller/ovn-controller.c | 6 +
ovn/lib/ovn-util.c | 1 +
ovn/northd/ovn-northd.8.xml | 52 +++-
ovn/northd/ovn-northd.c | 123 ++--
ovn/ovn-architecture.7.xml | 66
ovn/ovn-nb.xml | 33 ++
tests/ovn.at| 530 +++-
12 files changed, 868 insertions(+), 32 deletions(-)
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 021ecddcf..ee396c93d 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -471,13 +471,26 @@ consider_local_datapath(struct ovsdb_idl_txn
*ovnsb_idl_txn,
* for them. */
sset_add(local_lports, binding_rec->logical_port);
our_chassis = false;
+} else if (!strcmp(binding_rec->type, "external")) {
+const char *chassis_id = smap_get(_rec->options,
+ "requested-chassis");
+our_chassis = chassis_id && (
+!strcmp(chassis_id, chassis_rec->name) ||
+!strcmp(chassis_id, chassis_rec->hostname));
+if (our_chassis) {
+add_local_datapath(sbrec_datapath_binding_by_key,
+ sbrec_port_binding_by_datapath,
+ sbrec_port_binding_by_name,
+ binding_rec->datapath, true, local_datapaths);
+}
}
if (our_chassis
|| !strcmp(binding_rec->type, "patch")
|| !strcmp(binding_rec->type, "localport")
|| !strcmp(binding_rec->type, "vtep")
-|| !strcmp(binding_rec->type, "localnet")) {
+|| !strcmp(binding_rec->type, "localnet")
+|| !strcmp(binding_rec->type, "external")) {
update_local_lport_ids(local_lport_ids, binding_rec);
}
diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index 8db81927e..98e8ed3b9 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -52,7 +52,10 @@ lflow_init(void)
struct lookup_port_aux {
struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath;
struct ovsdb_idl_index *sbrec_port_binding_by_name;
+struct ovsdb_idl_index *sbrec_port_binding_by_type;
+struct ovsdb_idl_index *sbrec_datapath_binding_by_key;
const struct sbrec_datapath_binding *dp;
+const struct sbrec_chassis *chassis;
};
struct condition_aux {
@@ -66,6 +69,8 @@ static void consider_logical_flow(
struct ovsdb_idl_index *sbrec_chassis_by_name,
struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath,
struct ovsdb_idl_index *sbrec_port_binding_by_name,
+struct ovsdb_idl_index *sbrec_port_binding_by_type,
+struct ovsdb_idl_index *sbrec_datapath_binding_by_key,
const struct sbrec_logical_flow *,
const struct hmap *local_datapaths,
const struct sbrec_chassis *,
@@ -89,8 +94,24 @@ lookup_port_cb(const void *aux_, const char *port_name,
unsigned int *portp)
const struct sbrec_port_binding *pb
=
Re: [ovs-dev] [PATCH v2] ovn: Avoid tunneling for VLAN packets redirected to a gateway chassis
On Tue, Nov 27, 2018 at 12:48 AM Guru Shetty wrote:
>
>
> On Mon, 19 Nov 2018 at 08:18, wrote:
>
>> From: Numan Siddique
>>
>> An OVN deployment can have multiple logical switches each with a
>> localnet port connected to a distributed logical router in which one
>> logical switch may provide external connectivity and the rest of
>> the localnet logical switches use VLAN tagging in the physical
>> network.
>>
>> As reported in [1], external traffic from these localnet VLAN tagged
>> logical switches are tunnelled to the gateway chassis (chassis hosting
>> a distributed gateway port which applies NAT rules). As part of the
>> discussion in [1], there are few possible solutions proposed by
>> Russell [2]. This patch implements the first option in [2].
>>
>> With this patch, a new option 'reside-on-redirect-chassis' in 'options'
>> column of Logical_Router_Port table is added. If the value of this
>> option is set to 'true' and if the logical router also have a
>> distributed gateway port, then routing for this logical router port
>> is centralized in the chassis hosting the distributed gateway port.
>>
>> If a logical switch 'sw0' is connected to a router 'lr0' with the
>> router port - 'lr0-sw0' with the address - "00:00:00:00:af:12 192.168.1.1"
>> , and it has a distributed logical port - 'lr0-public', then the
>> below logical flow is added in the logical switch pipeline
>> of 'sw0' if the 'reside-on-redirect-chassis' option is set on 'lr-sw0' -
>>
>> table=16(ls_in_l2_lkup), priority=50,
>> match=(eth.dst == 00:00:00:00:af:12 &&
>> is_chassis_resident("cr-lr0-public")),
>> action=(outport = "sw0-lr0"; output;)
>>
>> "cr-lr0-public" is an internal port binding created by ovn-northd of type
>> 'chassisredirect' for lr0-public in SB DB. Please see "man ovn-sb" for
>> more details.
>>
>> With the above flow, the packet doesn't enter the router pipeline in
>> the source chassis. Instead the packet is sent out via the localnet
>> port of 'sw0'. The gateway chassis upon receiving this packet, runs
>> the logical router pipeline applying NAT rules and sends the traffic
>> out via the localnet port of the logical switch providing external
>> connectivity.
>> The gateway chassis will also reply to the ARP requests for the router
>> port IPs.
>>
>> With this approach, we avoid redirecting the external traffic to the
>> gateway chassis via the tunnel port. There are a couple of drawbacks
>> with this approach:
>>
>> - East - West routing is no more distributed for the VLAN tagged
>> localnet logical switches if 'reside-on-redirect-chassis' option is
>> defined
>>
>> - 'dnat_and_snat' NAT rules with 'logical_mac' and 'logical_port'
>> columns defined will not work for these logical switches.
>>
>> This approach is taken for now as it is simple. If there is a requirement
>> to support distributed routing for these VLAN tenant networks, we
>> can explore other possible solutions.
>>
>> [1] -
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
>> [2] -
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
>>
>> Reported-at:
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
>> Reported-by: venkata anil
>> Acked-by: Gurucharan Shetty
>> Co-authored-by: venkata anil
>> Signed-off-by: Numan Siddique
>> Signed-off-by: venkata anil
>>
>
> Since no one else looks to have any further comments, I applied this to
> master.
>
>
Thanks Guru for the review and applying the patch.
Numan
> ---
>>
>> v1 -> v2
>>
>> * Addressed the review comments from Guru.
>> * Removed the patch 2 'ovn: Support a new Logical_Switch_Port.type -
>>'external' from this series as it is an independent patch.
>>
>> ovn/northd/ovn-northd.8.xml | 30
>> ovn/northd/ovn-northd.c | 71 +++---
>> ovn/ovn-architecture.7.xml | 211
>> ovn/ovn-nb.xml | 43 ++
>> tests/ovn.at| 273
>> 5 files changed, 612 insertions(+), 16 deletions(-)
>>
>> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>> index 7352c6764..f52699bd3 100644
>> --- a/ovn/northd/ovn-northd.8.xml
>> +++ b/ovn/northd/ovn-northd.8.xml
>> @@ -874,6 +874,25 @@ output;
>> resident.
>>
>>
>> +
>> +
>> + For the Ethernet address on a logical switch port of type
>> + router, when that logical switch port's
>> + > + db="OVN_Northbound"/> column is set to router and
>> + the connected logical router port specifies a
>> + reside-on-redirect-chassis and the logical router
>> + to which the connected logical router port belongs to has a
>> + redirect-chassis distributed gateway logical
>> router
>> + port:
>> +
>> +
>> +
>> +
>> +The flow for the connected logical router port's Ethernet
>> +
[ovs-dev] (no subject)
-- -- Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von 2% .reply, wenn nötig. Good Day, We are a registered private money lender. We give out loans to firms, Individual who need to update their financial status all over the world, with Minimal annual Interest Rates of 2%reply if needed. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] HOW ARE YOU
How are you doingI'm miss Aina ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] pinctrl: Check requested IP in DHCPREQUEST messages
Bleep bloop. Greetings Gregory Smith, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. checkpatch: WARNING: Line is 80 characters long (recommended limit is 79) #157 FILE: ovn/controller/pinctrl.c:712: "match offer "IP_FMT, IP_ARGS(*in_dhcp_request_ip), Lines checked: 561, Warnings: 1, Errors: 0 Please check this out. If you feel there has been an error, please email acon...@bytheb.org Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] pinctrl: Check requested IP in DHCPREQUEST messages
See RFC 2131, section 4.3.2. When handling a DHCPREQUEST message, the
server should validate that the client's requested IP matches the
offered IP. If not, the server should reply with a DHCPNAK. The client's
requested IP is either specified as the Requested IP Address (option
50), or as the ciaddr, depending on the client's state.
Signed-off-by: Gregory Smith
---
v1 -> v2
* Refactored DHCP option parsing and packet boundary checks.
lib/dhcp.h | 3 +
ovn/controller/pinctrl.c | 124 ---
ovn/lib/ovn-l7.h | 9 +++
tests/ovn.at | 188 +--
4 files changed, 259 insertions(+), 65 deletions(-)
diff --git a/lib/dhcp.h b/lib/dhcp.h
index 271e0a5..73f593a 100644
--- a/lib/dhcp.h
+++ b/lib/dhcp.h
@@ -54,7 +54,10 @@ BUILD_ASSERT_DECL(DHCP_HEADER_LEN == sizeof(struct
dhcp_header));
#define DHCP_MSG_OFFER 2
#define DHCP_MSG_REQUEST 3
#define DHCP_MSG_ACK 5
+#define DHCP_MSG_NAK 6
+#define DHCP_OPT_PAD 0
+#define DHCP_OPT_REQ_IP50
#define DHCP_OPT_MSG_TYPE 53
#define DHCP_OPT_END 255
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 56539a8..20e4d19 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -608,14 +608,23 @@ pinctrl_handle_put_dhcp_opts(
*| UDP HEADER | DHCP HEADER | 4 Byte DHCP Cookie | DHCP OPTIONS(var
len)|
*
*/
-if (dp_packet_l4_size(pkt_in) < (UDP_HEADER_LEN +
-sizeof (struct dhcp_header) + sizeof(uint32_t) + 3)) {
+
+const char *end = (char *)dp_packet_l4(pkt_in) + dp_packet_l4_size(pkt_in);
+const char *in_dhcp_ptr = dp_packet_get_udp_payload(pkt_in);
+if (!in_dhcp_ptr) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
VLOG_WARN_RL(, "Invalid or incomplete DHCP packet received");
goto exit;
}
-struct dhcp_header const *in_dhcp_data = dp_packet_get_udp_payload(pkt_in);
+const struct dhcp_header *in_dhcp_data =
+ (const struct dhcp_header *)in_dhcp_ptr;
+in_dhcp_ptr += sizeof *in_dhcp_data;
+if (in_dhcp_ptr > end) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+VLOG_WARN_RL(, "Invalid or incomplete DHCP packet received");
+goto exit;
+}
if (in_dhcp_data->op != DHCP_OP_REQUEST) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
VLOG_WARN_RL(, "Invalid opcode in the DHCP packet : %d",
@@ -626,41 +635,96 @@ pinctrl_handle_put_dhcp_opts(
/* DHCP options follow the DHCP header. The first 4 bytes of the DHCP
* options is the DHCP magic cookie followed by the actual DHCP options.
*/
-const uint8_t *in_dhcp_opt =
-(const uint8_t *)dp_packet_get_udp_payload(pkt_in) +
-sizeof (struct dhcp_header);
-
ovs_be32 magic_cookie = htonl(DHCP_MAGIC_COOKIE);
-if (memcmp(in_dhcp_opt, _cookie, sizeof(ovs_be32))) {
+const ovs_be32 *in_dhcp_cookie = (const ovs_be32 *)in_dhcp_ptr;
+in_dhcp_ptr += sizeof *in_dhcp_cookie;
+if (in_dhcp_ptr > end || *in_dhcp_cookie != magic_cookie) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
VLOG_WARN_RL(, "DHCP magic cookie not present in the DHCP packet");
goto exit;
}
-in_dhcp_opt += 4;
+const uint8_t *in_dhcp_msg_type = NULL;
+const ovs_be32 *in_dhcp_request_ip = NULL;
+while (true) {
+const struct dhcp_opt_header *in_dhcp_opt =
+(const struct dhcp_opt_header *)in_dhcp_ptr;
+in_dhcp_ptr += 1;
+if (in_dhcp_ptr > end || in_dhcp_opt->code == DHCP_OPT_END) {
+break;
+} else if (in_dhcp_opt->code == DHCP_OPT_PAD) {
+continue;
+}
+in_dhcp_ptr += 1;
+if (in_dhcp_ptr > end) {
+break;
+}
+in_dhcp_ptr += in_dhcp_opt->len;
+if (in_dhcp_ptr > end) {
+break;
+}
+switch (in_dhcp_opt->code) {
+case DHCP_OPT_MSG_TYPE:
+if (in_dhcp_opt->len == 1) {
+in_dhcp_msg_type = (const uint8_t *)_dhcp_opt[1];
+}
+break;
+case DHCP_OPT_REQ_IP:
+if (in_dhcp_opt->len == 4) {
+in_dhcp_request_ip = (const ovs_be32 *)_dhcp_opt[1];
+}
+break;
+default:
+break;
+}
+}
+
/* Check that the DHCP Message Type (opt 53) is present or not with
- * valid values - DHCP_MSG_DISCOVER or DHCP_MSG_REQUEST as the first
- * DHCP option.
+ * valid values - DHCP_MSG_DISCOVER or DHCP_MSG_REQUEST.
*/
-if (!(in_dhcp_opt[0] == DHCP_OPT_MSG_TYPE && in_dhcp_opt[1] == 1 && (
-in_dhcp_opt[2] == DHCP_MSG_DISCOVER ||
-in_dhcp_opt[2] == DHCP_MSG_REQUEST))) {
+if (!in_dhcp_msg_type) {
static
Re: [ovs-dev] [PATCH v2] ovn: Avoid tunneling for VLAN packets redirected to a gateway chassis
On Mon, 19 Nov 2018 at 08:18, wrote:
> From: Numan Siddique
>
> An OVN deployment can have multiple logical switches each with a
> localnet port connected to a distributed logical router in which one
> logical switch may provide external connectivity and the rest of
> the localnet logical switches use VLAN tagging in the physical
> network.
>
> As reported in [1], external traffic from these localnet VLAN tagged
> logical switches are tunnelled to the gateway chassis (chassis hosting
> a distributed gateway port which applies NAT rules). As part of the
> discussion in [1], there are few possible solutions proposed by
> Russell [2]. This patch implements the first option in [2].
>
> With this patch, a new option 'reside-on-redirect-chassis' in 'options'
> column of Logical_Router_Port table is added. If the value of this
> option is set to 'true' and if the logical router also have a
> distributed gateway port, then routing for this logical router port
> is centralized in the chassis hosting the distributed gateway port.
>
> If a logical switch 'sw0' is connected to a router 'lr0' with the
> router port - 'lr0-sw0' with the address - "00:00:00:00:af:12 192.168.1.1"
> , and it has a distributed logical port - 'lr0-public', then the
> below logical flow is added in the logical switch pipeline
> of 'sw0' if the 'reside-on-redirect-chassis' option is set on 'lr-sw0' -
>
> table=16(ls_in_l2_lkup), priority=50,
> match=(eth.dst == 00:00:00:00:af:12 &&
> is_chassis_resident("cr-lr0-public")),
> action=(outport = "sw0-lr0"; output;)
>
> "cr-lr0-public" is an internal port binding created by ovn-northd of type
> 'chassisredirect' for lr0-public in SB DB. Please see "man ovn-sb" for
> more details.
>
> With the above flow, the packet doesn't enter the router pipeline in
> the source chassis. Instead the packet is sent out via the localnet
> port of 'sw0'. The gateway chassis upon receiving this packet, runs
> the logical router pipeline applying NAT rules and sends the traffic
> out via the localnet port of the logical switch providing external
> connectivity.
> The gateway chassis will also reply to the ARP requests for the router
> port IPs.
>
> With this approach, we avoid redirecting the external traffic to the
> gateway chassis via the tunnel port. There are a couple of drawbacks
> with this approach:
>
> - East - West routing is no more distributed for the VLAN tagged
> localnet logical switches if 'reside-on-redirect-chassis' option is
> defined
>
> - 'dnat_and_snat' NAT rules with 'logical_mac' and 'logical_port'
> columns defined will not work for these logical switches.
>
> This approach is taken for now as it is simple. If there is a requirement
> to support distributed routing for these VLAN tenant networks, we
> can explore other possible solutions.
>
> [1] -
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
> [2] -
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
> Reported-by: venkata anil
> Acked-by: Gurucharan Shetty
> Co-authored-by: venkata anil
> Signed-off-by: Numan Siddique
> Signed-off-by: venkata anil
>
Since no one else looks to have any further comments, I applied this to
master.
> ---
>
> v1 -> v2
>
> * Addressed the review comments from Guru.
> * Removed the patch 2 'ovn: Support a new Logical_Switch_Port.type -
>'external' from this series as it is an independent patch.
>
> ovn/northd/ovn-northd.8.xml | 30
> ovn/northd/ovn-northd.c | 71 +++---
> ovn/ovn-architecture.7.xml | 211
> ovn/ovn-nb.xml | 43 ++
> tests/ovn.at| 273
> 5 files changed, 612 insertions(+), 16 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 7352c6764..f52699bd3 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -874,6 +874,25 @@ output;
> resident.
>
>
> +
> +
> + For the Ethernet address on a logical switch port of type
> + router, when that logical switch port's
> + + db="OVN_Northbound"/> column is set to router and
> + the connected logical router port specifies a
> + reside-on-redirect-chassis and the logical router
> + to which the connected logical router port belongs to has a
> + redirect-chassis distributed gateway logical router
> + port:
> +
> +
> +
> +
> +The flow for the connected logical router port's Ethernet
> +address is only programmed on the
> redirect-chassis.
> +
> +
>
>
>
> @@ -1179,6 +1198,17 @@ output;
>upstream MAC learning to point to the
>redirect-chassis.
>
> +
> +
Re: [ovs-dev] [patch v9 07/11] dpctl: Simplify opt_dpif_open().
On Mon, Nov 19, 2018 at 11:11 AM Darrell Ball wrote:
>
> The commonly used function, opt_dpif_open(), recently became more complex
> to check for a datapath argument. Unnecessary dummy parameters for most users
> were hence added. Revert back and call the intended api, dp_arg_exists(), to
> query for a datapath argument being supplied.
>
> Fixes: 4eeec031d4c4 ("dpctl: Implement dpctl commands for conntrack per zone
> limit")
> CC: Yi-Hung Wei
> Signed-off-by: Darrell Ball
> ---
Thanks for the simplification. Looks good to me.
Acked-by: Yi-Hung Wei
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [patch v3 3/4] conntrack: Enforce conn_type for flush tuple.
The user should only reference a conntrack entry by the forward
direction context, as per 'conntrack_flush()', enforce this by
checking for 'default' conn_type. The likelihood of a user
not using the original tuple is low, but it should be guarded
against, logged and documented.
Signed-off-by: Darrell Ball
---
Backport to 2.9.
v3: Move backport hint out of commit message.
Remove warning log conditional for now.
lib/conntrack.c | 3 ++-
lib/dpctl.man | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/conntrack.c b/lib/conntrack.c
index bb3eeca..f6ff90a 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2572,9 +2572,10 @@ conntrack_flush_tuple(struct conntrack *ct, const struct
ct_dpif_tuple *tuple,
ct_lock_lock(>buckets[bucket].lock);
conn_key_lookup(>buckets[bucket], , time_msec());
-if (ctx.conn) {
+if (ctx.conn && ctx.conn->conn_type == CT_CONN_TYPE_DEFAULT) {
conn_clean(ct, ctx.conn, >buckets[bucket]);
} else {
+VLOG_WARN("Must flush tuple using the original pre-NATed tuple");
error = ENOENT;
}
ct_lock_unlock(>buckets[bucket].lock);
diff --git a/lib/dpctl.man b/lib/dpctl.man
index 9b13e0d..fe0aec9 100644
--- a/lib/dpctl.man
+++ b/lib/dpctl.man
@@ -237,6 +237,8 @@ If \fBzone\fR=\fIzone\fR is specified, only flushes the
connections in
.IP
If \fIct-tuple\fR is provided, flushes the connection entry specified by
\fIct-tuple\fR in \fIzone\fR. The zone defaults to 0 if it is not provided.
+The userspace connection tracker requires flushing with the original pre-NATed
+tuple and a warning log will be otherwise generated.
An example of an IPv4 ICMP \fIct-tuple\fR:
.IP
"ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=1,icmp_type=8,icmp_code=0,icmp_id=10"
--
1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [patch v3 2/4] conntrack: Check all addresses for ephemeral ports.
When fallback to ephemeral ports triggers to find a NAT translation,
it may happen that the full address range is not explored; i.e. if
all ephemeral ports are being used for the address range >= the
first address checked and there are other addresses in the
available range, then they would not be explored for availability.
The likelihood of hitting this condition is rare. The fix is to
reset the first address to the minimum address when starting to
search ephemeral ports. Found by inspection.
Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
Signed-off-by: Darrell Ball
---
Backport to 2.8.
v3: Move backport hint out of commit message.
Fix wording.
lib/conntrack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 31fedc0..bb3eeca 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2225,6 +2225,7 @@ nat_select_range_tuple(struct conntrack *ct, const struct
conn *conn,
} else {
ephemeral_ports_tried = true;
ct_addr = conn->nat_info->min_addr;
+first_addr = ct_addr;
min_port = MIN_NAT_EPHEMERAL_PORT;
max_port = MAX_NAT_EPHEMERAL_PORT;
}
--
1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [patch v3 1/4] conntrack: Skip ephemeral ports fallback for DNAT.
Ephemeral port fallback is being done for DNAT and the code could be hit in
some special cases and testing configurations. Also good packets are
expected to be persistently dropped in this case, which is not a common
user goal. Regardless, this is incorrect, so filter this out. Also, rename
the variable used for checking whether ephemeral ports need to be checked.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-August/351629.html
Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.")
Signed-off-by: Darrell Ball
---
Backport to 2.8.
v3: Move backport hint out of commit message.
lib/conntrack.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 974f985..31fedc0 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2172,7 +2172,9 @@ nat_select_range_tuple(struct conntrack *ct, const struct
conn *conn,
uint16_t port = first_port;
bool all_ports_tried = false;
-bool original_ports_tried = false;
+/* For DNAT, we don't use ephemeral ports. */
+bool ephemeral_ports_tried = conn->nat_info->nat_action & NAT_ACTION_DST
+ ? true : false;
struct ct_addr first_addr = ct_addr;
while (true) {
@@ -2218,13 +2220,13 @@ nat_select_range_tuple(struct conntrack *ct, const
struct conn *conn,
ct_addr = conn->nat_info->min_addr;
}
if (!memcmp(_addr, _addr, sizeof ct_addr)) {
-if (!original_ports_tried) {
-original_ports_tried = true;
+if (ephemeral_ports_tried) {
+break;
+} else {
+ephemeral_ports_tried = true;
ct_addr = conn->nat_info->min_addr;
min_port = MIN_NAT_EPHEMERAL_PORT;
max_port = MAX_NAT_EPHEMERAL_PORT;
-} else {
-break;
}
}
first_port = min_port;
--
1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Great News For You
You were listed as next of kin in an Estate .Please contact me for more information ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] .Are You Interested...
how are you, my name is Elizabeth Brown I need your service for General Errands or Personal Assistant, contact me if you are interested: kohno6...@gmail.com ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Apply e120ff1f8 to stable bracnhes
Ups, You're right Ben, sorry, got passed to me and I didn't crosscheck properly. -Original Message- From: Ben Pfaff To: jcaam...@suse.de Cc: ovs dev Subject: Re: [ovs-dev] Apply e120ff1f8 to stable bracnhes Date: Mon, 26 Nov 2018 06:22:14 -0800 On Mon, Nov 26, 2018 at 11:09:15AM +0100, Jaime Caamaño Ruiz wrote: > Commit e120ff1f8 (python-c-ext: Fix memory leak in Parser_finish) > fixes > a bug that is present since OVS 2.6. Could it be cherry picked to > applicable stable branches? It appears that it was already on all of them. Where is it missing? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Apply e120ff1f8 to stable bracnhes
On Mon, Nov 26, 2018 at 11:09:15AM +0100, Jaime Caamaño Ruiz wrote: > Commit e120ff1f8 (python-c-ext: Fix memory leak in Parser_finish) fixes > a bug that is present since OVS 2.6. Could it be cherry picked to > applicable stable branches? It appears that it was already on all of them. Where is it missing? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] (no subject)
Fordern Sie Ihre Western Union-Kompensationsmittel am Jahresende im Wert von 800.000 USD ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Apply e120ff1f8 to stable bracnhes
Hi Commit e120ff1f8 (python-c-ext: Fix memory leak in Parser_finish) fixes a bug that is present since OVS 2.6. Could it be cherry picked to applicable stable branches? Thanks Jaime. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
