Re: [ovs-dev] [PATCH] ovn-northd: Add support for static_routes.
Mickey, Can you give a first shot at the review. You had some issues with
the my code structure and looks like Steve decided to use something
similar.
On 19 April 2016 at 02:36, steve.ruan wrote:
> From: Guru Shetty
>
Steve,
You should be the author (when you respin after Mickey's review). You can
just add me as "Co-authored-by" along with my signed-off-by. You can
search in "git log" for other examples.
>
> static routes are useful when connecting multiple
> routers with each other.
>
> Signed-off-by: Gurucharan Shetty
> Signed-off-by: steve.ruan
> ---
> ovn/northd/ovn-northd.8.xml | 5 +-
> ovn/northd/ovn-northd.c | 101 +
> ovn/ovn-nb.ovsschema | 15 +++-
> ovn/ovn-nb.xml| 31 +++
> ovn/utilities/ovn-nbctl.8.xml | 5 ++
> ovn/utilities/ovn-nbctl.c | 5 ++
> tests/ovn.at | 204
> ++
> 7 files changed, 362 insertions(+), 4 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index da776e1..978853c 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -682,8 +682,9 @@ next;
>
>
>
> - If the route has a gateway, G is the gateway IP
> address,
> - otherwise it is ip4.dst.
> + If the route has a gateway, G is the gateway IP
> address.
> + Instead, if the route is from a configured static route,
> G
> + is the next hop IP address. Else it is ip4.dst.
>
>
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 260c02f..71c9b29 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -234,6 +234,18 @@ allocate_tnlid(struct hmap *set, const char *name,
> uint32_t max,
> return 0;
> }
>
> +/* Holds the next hop ip address and the logical router port via which
> + * a static route is reachable. */
> +struct route_to_port {
> +ovs_be32 ip;/* network address of the route. */
> +ovs_be32 mask; /* network mask of the route. */
> +ovs_be32 next_hop; /* next_hop ip address for the above
> route. */
> +struct uuid rport; /* output port specified by CMS, or null
> if not specified */
> +struct ovn_port *ovn_port; /* The logical router port via which the
> packet
> + * needs to exit to reach the next hop. */
> +};
> +
> +
> /* The 'key' comes from nbs->header_.uuid or nbr->header_.uuid or
> * sb->external_ids:logical-switch. */
> struct ovn_datapath {
> @@ -249,6 +261,9 @@ struct ovn_datapath {
> /* Logical router data (digested from nbr). */
> const struct ovn_port *gateway_port;
> ovs_be32 gateway;
> +/* Maps a static route to a ovn logical router port via which packet
> + * needs to exit. */
> +struct shash routes_map;
>
> /* Logical switch data. */
> struct ovn_port **router_ports;
> @@ -272,6 +287,7 @@ ovn_datapath_create(struct hmap *datapaths, const
> struct uuid *key,
> od->nbs = nbs;
> od->nbr = nbr;
> hmap_init(&od->port_tnlids);
> +shash_init(&od->routes_map);
> od->port_key_hint = 0;
> hmap_insert(datapaths, &od->key_node, uuid_hash(&od->key));
> return od;
> @@ -286,6 +302,7 @@ ovn_datapath_destroy(struct hmap *datapaths, struct
> ovn_datapath *od)
> * use it. */
> hmap_remove(datapaths, &od->key_node);
> destroy_tnlids(&od->port_tnlids);
> +shash_destroy_free_data(&od->routes_map);
> free(od->router_ports);
> free(od);
> }
> @@ -318,6 +335,50 @@ ovn_datapath_from_sbrec(struct hmap *datapaths,
> }
>
> static void
> +build_static_route(struct ovn_datapath *od,
> + const struct nbrec_logical_router_static_route *route)
> +{
> +ovs_be32 prefix, next_hop, mask;
> +
> +/* verify nexthop */
> +char *error = ip_parse_masked(route->nexthop, &next_hop, &mask);
> +if (error || mask != OVS_BE32_MAX) {
> +static struct vlog_rate_limit rl
> += VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_WARN_RL(&rl, "bad next hop ip address %s",
> +route->nexthop);
> +free(error);
> +return;
> +}
> +
> +/* verify prefix */
> +error = ip_parse_masked(route->prefix, &prefix, &mask);
> +if (error || !ip_is_cidr(mask)) {
> +static struct vlog_rate_limit rl
> +
Re: [ovs-dev] [PATCH] ovn-northd: Add support for static_routes.
On 20 April 2016 at 18:38, steve.ruan wrote:
> From: Guru Shetty
>
Run the following command (with your name added) for your next respin:
git commit --amend --author="Author Name "
>
> static routes are useful when connecting multiple
> routers with each other.
>
> Signed-off-by: steve.ruan
> Signed-off-by: Gurucharan Shetty
> Co-authored-by: Gurucharan Shetty
>
> Reported-by: Na Zhu
> Reported-by: Dustin Lundquist
>
> Reported-at:
> https://bugs.launchpad.net/networking-ovn/+bug/1545140
> https://bugs.launchpad.net/networking-ovn/+bug/1539347
> ---
> ovn/northd/ovn-northd.8.xml | 5 +-
> ovn/northd/ovn-northd.c | 101 +
> ovn/ovn-nb.ovsschema | 15 +++-
> ovn/ovn-nb.xml| 31 +++
> ovn/utilities/ovn-nbctl.8.xml | 5 ++
> ovn/utilities/ovn-nbctl.c | 5 ++
> tests/ovn.at | 204
> ++
> 7 files changed, 362 insertions(+), 4 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index da776e1..978853c 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -682,8 +682,9 @@ next;
>
>
>
> - If the route has a gateway, G is the gateway IP
> address,
> - otherwise it is ip4.dst.
> + If the route has a gateway, G is the gateway IP
> address.
> + Instead, if the route is from a configured static route,
> G
> + is the next hop IP address. Else it is ip4.dst.
>
>
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 260c02f..5d86219 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -234,6 +234,18 @@ allocate_tnlid(struct hmap *set, const char *name,
> uint32_t max,
> return 0;
> }
>
> +/* Holds the next hop ip address and the logical router port via which
> + * a static route is reachable. */
> +struct route_to_port {
> +ovs_be32 ip;/* network address of the route. */
> +ovs_be32 mask; /* network mask of the route. */
> +ovs_be32 next_hop; /* next_hop ip address for the above
> route. */
> +struct uuid rport; /* output port specified by CMS, or null
> if not specified */
> +struct ovn_port *ovn_port; /* The logical router port via which the
> packet
> + * needs to exit to reach the next hop. */
> +};
> +
> +
> /* The 'key' comes from nbs->header_.uuid or nbr->header_.uuid or
> * sb->external_ids:logical-switch. */
> struct ovn_datapath {
> @@ -249,6 +261,9 @@ struct ovn_datapath {
> /* Logical router data (digested from nbr). */
> const struct ovn_port *gateway_port;
> ovs_be32 gateway;
> +/* Maps a static route to a ovn logical router port via which packet
> + * needs to exit. */
> +struct shash routes_map;
>
> /* Logical switch data. */
> struct ovn_port **router_ports;
> @@ -272,6 +287,7 @@ ovn_datapath_create(struct hmap *datapaths, const
> struct uuid *key,
> od->nbs = nbs;
> od->nbr = nbr;
> hmap_init(&od->port_tnlids);
> +shash_init(&od->routes_map);
> od->port_key_hint = 0;
> hmap_insert(datapaths, &od->key_node, uuid_hash(&od->key));
> return od;
> @@ -286,6 +302,7 @@ ovn_datapath_destroy(struct hmap *datapaths, struct
> ovn_datapath *od)
> * use it. */
> hmap_remove(datapaths, &od->key_node);
> destroy_tnlids(&od->port_tnlids);
> +shash_destroy_free_data(&od->routes_map);
> free(od->router_ports);
> free(od);
> }
> @@ -318,6 +335,50 @@ ovn_datapath_from_sbrec(struct hmap *datapaths,
> }
>
> static void
> +build_static_route(struct ovn_datapath *od,
> + const struct nbrec_logical_router_static_route *route)
> +{
> +ovs_be32 prefix, next_hop, mask;
> +
> +/* verify nexthop */
> +char *error = ip_parse_masked(route->nexthop, &next_hop, &mask);
> +if (error || mask != OVS_BE32_MAX) {
> +static struct vlog_rate_limit rl
> += VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_WARN_RL(&rl, "bad next hop ip address %s",
> +route->nexthop);
> +free(error);
> +return;
> +}
> +
> +/* verify prefix */
> +error = ip_parse_masked(route->prefix, &prefix, &mask);
> +if (error || !ip_is_cidr(mask)) {
> +static struct vlog_rate_limit rl
> +
Re: [ovs-dev] [PATCH V5 1/1] ovn-northd: Add support for static_routes.
On 24 April 2016 at 02:49, steve.ruan wrote:
Thank you for working through this. I have a few comments.
With this patch, your author name becomes "steve.ruan". Did you intend it
to be Steve Ruan instead? Your email address in the author name (gmail) is
different than the email address in your signed-off-by (IBM). They need to
be the same.
static routes are useful when connecting multiple
> routers with each other.
>
> Signed-off-by: steve.ruan
> Co-authored-by: Gurucharan Shetty
>
> Reported-by: Na Zhu
> Reported-by: Dustin Lundquist
>
> Reported-at:
> https://bugs.launchpad.net/networking-ovn/+bug/1545140
> https://bugs.launchpad.net/networking-ovn/+bug/1539347
> ---
> ovn/northd/ovn-northd.8.xml | 5 +-
> ovn/northd/ovn-northd.c | 81 +
> ovn/ovn-nb.ovsschema | 15 +++-
> ovn/ovn-nb.xml| 31 +++
> ovn/utilities/ovn-nbctl.8.xml | 5 ++
> ovn/utilities/ovn-nbctl.c | 5 ++
> tests/ovn.at | 203
> ++
> 7 files changed, 341 insertions(+), 4 deletions(-)
>
You will also need to add yourself to AUTHORS file.
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 1cd8072..970c352 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -689,8 +689,9 @@ next;
>
>
>
> - If the route has a gateway, G is the gateway IP
> address,
> - otherwise it is ip4.dst.
> + If the route has a gateway, G is the gateway IP
> address.
> + Instead, if the route is from a configured static route,
> G
> + is the next hop IP address. Else it is ip4.dst.
>
>
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index e3436da..e2c5a78 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -1828,6 +1828,79 @@ add_route(struct hmap *lflows, const struct
> ovn_port *op,
> }
>
> static void
> +build_static_route_flow(struct hmap *lflows, struct ovn_datapath *od,
> + struct hmap *ports,
> + const struct nbrec_logical_router_static_route *route)
> +{
> +struct ovn_port *out_port, *op;
> +ovs_be32 prefix, next_hop, mask;
> +int len;
> +
> +/* verify nexthop */
>
From CodingStyle:
Comments should be written as full sentences that start with a
capital letter and end with a period. Put two spaces between
sentences. I have the same comment for everywhere else.
> +char *error = ip_parse_masked(route->nexthop, &next_hop, &mask);
> +if (error || mask != OVS_BE32_MAX) {
> +static struct vlog_rate_limit rl
> += VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_WARN_RL(&rl, "bad next hop ip address %s",
> +route->nexthop);
> +free(error);
> +return;
> +}
> +
> +/* verify prefix */
> +error = ip_parse_masked(route->prefix, &prefix, &mask);
> +if (error || !ip_is_cidr(mask)) {
> +static struct vlog_rate_limit rl
> += VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_WARN_RL(&rl, "bad 'network' in static routes %s",
> + route->prefix);
> +free(error);
> +return;
> +}
> +
> +/* find the outgoing port */
> +out_port = NULL;
> +len = 0;
> +if (route->output_port){
>
You need a space before "{" (similar violations at other places)
> +out_port = ovn_port_find(ports, route->output_port);
> +if (!out_port){
> +static struct vlog_rate_limit rl
> += VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_WARN_RL(&rl, "bad 'out port' in static routes %s",
> +route->output_port);
> +return;
> +}
> +}
>
else below should be in the previous line. Have a look at CodingStyle
document.
> +else{ /* output_port is not specified, then find the
>
...
...
> +* router port with longest net mask match */diff --git
> a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
> index e3e41e3..e67f903 100644
> --- a/ovn/ovn-nb.ovsschema
> +++ b/ovn/ovn-nb.ovsschema
> @@ -1,7 +1,7 @@
> {
> "name": "OVN_Northbound",
> -"version": "2.1.0",
> -"cksum": "2201582413 4513",
> +"version": "2.1.1",
> +"cksum": "1773273858 5105",
> "tables": {
> "Logical_Switch": {
> "columns": {
> @@ -71,6 +71,11 @@
> "refType": "strong"},
> "min": 0,
> "max": "unlimited"}},
> +"static_routes": {"type": {"key": {"type": "uuid",
> +"refTable":
> "Logical_Router_Static_Route",
> +"refType": "strong"},
> + "min": 0,
> + "max": "unlimited"}},
> "default_gw": {"type": {"k
Re: [ovs-dev] [PATCH V6 1/1] ovn-northd: Add support for static_routes.
> > > + > + > + > +Nexthop of this route, nexthop can be a IP address of logical > router > +port, or IP address which has been learnt by dynamic ARP. > Can you explain how a nexthop IP address specified is anything other than the IP address of a logical router (based on current code)? I do not quite understand what IP address is being learnt via dynamic ARP? > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V6 1/1] ovn-northd: Add support forstatic_routes.
>
> [Resending as the previous reply got rejected by the mailing list].
>
Thanks for the explanation. I intend to add the following stylistic and
needed changes and apply this to master after some time.
diff --git a/AUTHORS b/AUTHORS
index 3f05a02..5290ef5 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -211,6 +211,7 @@ Steffen Gebert
steffen.geb...@informatik.uni-wuerzburg.de
Sten Spans s...@blinkenlights.nl
Stephane A. Sezer s...@cd80.net
Stephen Finucanestephen.finuc...@intel.com
+Steve Ruan rua...@cn.ibm.com
SUGYO Kazushi sugyo@gmail.com
Tadaaki Nagao na...@stratosphere.co.jp
Terry Wilsontwil...@redhat.com
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index ad9684b..673f52d 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1828,74 +1828,65 @@ add_route(struct hmap *lflows, const struct
ovn_port *op,
static void
build_static_route_flow(struct hmap *lflows, struct ovn_datapath *od,
- struct hmap *ports,
- const struct nbrec_logical_router_static_route *route)
+struct hmap *ports,
+const struct nbrec_logical_router_static_route
*route)
{
ovs_be32 prefix, next_hop, mask;
-/* Verify that next hop is an IP address with 32 bits mask */
+/* Verify that next hop is an IP address with 32 bits mask. */
char *error = ip_parse_masked(route->nexthop, &next_hop, &mask);
if (error || mask != OVS_BE32_MAX) {
-static struct vlog_rate_limit rl
-= VLOG_RATE_LIMIT_INIT(5, 1);
-VLOG_WARN_RL(&rl, "bad next hop ip address %s",
-route->nexthop);
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(&rl, "bad next hop ip address %s", route->nexthop);
free(error);
return;
}
-/* Verify that ip prefix is a valid CIDR address */
+/* Verify that ip prefix is a valid CIDR address. */
error = ip_parse_masked(route->ip_prefix, &prefix, &mask);
if (error || !ip_is_cidr(mask)) {
-static struct vlog_rate_limit rl
-= VLOG_RATE_LIMIT_INIT(5, 1);
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
VLOG_WARN_RL(&rl, "bad 'network' in static routes %s",
- route->ip_prefix);
+ route->ip_prefix);
free(error);
return;
}
-/* Find the outgoing port */
+/* Find the outgoing port. */
struct ovn_port *out_port = NULL;
if (route->output_port) {
out_port = ovn_port_find(ports, route->output_port);
if (!out_port) {
-static struct vlog_rate_limit rl
-= VLOG_RATE_LIMIT_INIT(5, 1);
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
VLOG_WARN_RL(&rl, "Bad out port %s for static route %s",
-route->output_port, route->ip_prefix);
+ route->output_port, route->ip_prefix);
return;
}
} else {
-
-/* output_port is not specified, then find the
- * router port match next hop */
-
+/* output_port is not specified, find the
+ * router port matching the next hop. */
int i;
for (i = 0; i < od->nbr->n_ports; i++) {
-
struct nbrec_logical_router_port *lrp = od->nbr->ports[i];
out_port = ovn_port_find(ports, lrp->name);
if (!out_port) {
-/* This should not happen */
+/* This should not happen. */
continue;
}
if (out_port->network
&& !((out_port->network ^ next_hop) & out_port->mask)) {
-/* There should have ONLY 1 interface match the next hop,
- * or it's a configuration error, because subnets of
router's
- * interfaces should NOT be overlapped */
+/* There should be only 1 interface that matches the next
hop.
+ * Otherwise, it's a configuration error, because subnets
of
+ * router's interfaces should NOT overlap. */
break;
break;
}
}
if (i == od->nbr->n_ports) {
-
-/* There is no matched out port */
-static struct vlog_rate_limit rl
-= VLOG_RATE_LIMIT_INIT(5, 1);
+/* There is no matched out port. */
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
VLOG_WARN_RL(&rl, "No path for static route %s; next hop %s",
-route->ip_prefix, route->nexthop);
+ route->ip_prefix, route->nexthop);
return;
}
}
@@ -2072,7 +2063,7 @@ build_lrouter_flows(struct hmap *datapaths, struct
hmap *ports,
continue;
}
-/* convert the routing table t
Re: [ovs-dev] [PATCH v2 2/2] ofproto-dpif: Do not count resubmit to later tables against limit.
> > > > Thanks for the ack. > > Guru, I mostly wrote this up for you, does this solve the problem you > saw? > Sorry, I completely missed this. Yes, it does solve the problem for me. > > Thanks, > > Ben. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
On 9 May 2016 at 14:51, Darrell Ball wrote:
> I have some initial clarifications first before review
>
> On Fri, May 6, 2016 at 9:21 AM, Gurucharan Shetty wrote:
>
>> Currently we can connect routers via "peer"ing. This limits
>> the number of routers that can be connected with each other
>> directly to 2.
>>
>
>
> This sounds like you are saying that cannot have a topology like
>
> R1---R2
> \ /
> \/
>\ /
> \ /
> R3
>
> which is common.
> Did I read the above comment correctly ?
>
The above drawn topology will start getting complex with more gateways. (In
case of k8s each machine is a l3 gateway.). I agree that my usage of word
"directly" may be confusing. I meant routers connected to each other in the
same subnet.
>
>
>
>>
>> One of the design goals for L3 Gateway is to be able to
>> have multiple gateways (each with their own router)
>> connected to a distributed router via a switch.
>>
>
> Its not ideal to have a switch required to connect routers - it somewhat
> defeats the advantages
> of having routers in the first place.
>
I do not have much experience with real world networking setups. There are
probably reasons why your statement is true. From my perspective , all I
see is that a switch is used to connect multiple endpoints in the same
subnet and If I want multiple routers connected to each other in the same
subnet, I need to use a switch. VMware NSX uses something similar in
customer deployments, so I believe it is not out of ordinary to do
something like this.
> This is usually only done if there is existing switching equipment than
> must be traversed
> But in the case, we are just dealing with software where we have total
> flexibility.
>
From OpenStack perspective, each tenant gets a router and multiple switches
with different subnets. The idea is that the OpenStack network plugin, can
at best split this single tenant router into 2 with a switch in between on
a subnet that neutron does not use. Taking the same logic forward for k8s,
I can support multiple gateways.
Connecting multiple routers to each other without a switch makes it a pain
to remember the interconnections and create multiple subnets (which may
simply not be available for a networking backend for internal use).
>
>
>>
>> With the above goal in mind, this commit gives the general
>> ability to connect multiple routers via a switch.
>>
>> Signed-off-by: Gurucharan Shetty
>> ---
>> This needs the following 2 commits under review to
>> first go in.
>> 1. ofproto-dpif: Rename "recurse" to "indentation".
>> 2. ofproto-dpif: Do not count resubmit to later tables against limit.
>> ---
>> ovn/controller/lflow.c | 19 ++--
>> ovn/northd/ovn-northd.c | 56 ++-
>> ovn/ovn-nb.xml |7 --
>> tests/ovn.at| 236
>> +++
>> 4 files changed, 299 insertions(+), 19 deletions(-)
>>
>> diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
>> index 96b7c66..efc427d 100644
>> --- a/ovn/controller/lflow.c
>> +++ b/ovn/controller/lflow.c
>> @@ -215,15 +215,15 @@ add_logical_flows(struct controller_ctx *ctx, const
>> struct lport_index *lports,
>> if (is_switch(ldp)) {
>> /* For a logical switch datapath, local_datapaths tells us
>> if there
>> * are any local ports for this datapath. If not, we can
>> skip
>> - * processing logical flows if the flow belongs to egress
>> pipeline
>> - * or if that logical switch datapath is not patched to any
>> logical
>> - * router.
>> + * processing logical flows if that logical switch datapath
>> is not
>> + * patched to any logical router.
>> *
>> - * Otherwise, we still need the ingress pipeline because
>> even if
>> - * there are no local ports, we still may need to execute
>> the ingress
>> - * pipeline after a packet leaves a logical router. Further
>> - * optimization is possible, but not based on what we know
>> with
>> - * local_datapaths right now.
>> + * Otherwise, we still need both ingress and egress pipeline
>> + * because even if there are no local ports, we still may
>> need to
>> + * execute the ingress pipeline after a packet leaves a
>> logical
>> + * router and we need to do egress pipeline for a switch that
>> + * is connected to only routers. Further optimization is
>> possible,
>> + * but not based on what we know with local_datapaths right
>> now.
>> *
>> * A better approach would be a kind of "flood fill"
>> algorithm:
>> *
>> @@ -242,9 +242,6 @@ add_logical_flows(struct controller_ctx *ctx, const
>> struct lport_index *lports,
>> */
>>
>> if (!get_local_datapath(local_datapaths, ldp->tunnel_key)) {
>> -if (!ingress) {
>>
Re: [ovs-dev] [patch_v1] ovn: add local router support (RFC)
On 9 May 2016 at 23:57, Mickey Spiegel wrote: > The big issue for me is your last comment: > > If you add bob2 on hv1, would bob2 be able to reach alice1? > > No; take foo1 which is already on hv1 for this example; > if I try to send b/w foo1 and alice1, I have “no route to alice1, the > destination” because all I can use on hv1 is R1 routes. If I change the > test with new permissive catchall routes everywhere, I could do it, of > course, but that is something else and contrary to what you would want to > do. > > > There is a reason that I mentioned bob rather than foo. > > The logical connectivity is > bob -- R1 -- foo > and > bob -- R2 -- alice > > Since there are no static routes configured between R1 and R2, foo has no > logical connectivity to alice. > > There *is* logical connectivity between bob and alice through R2. > > With your code, you get different behavior depending on whether the > endpoint in bob is on hv1 or hv2. > Since bob1 and alice1 are both on hv2 along with R2, bob1 can reach alice1. > If you add bob2 on hv1, bob2 cannot reach alice1. > > Why should you get different connectivity depending on placement of > endpoints within logical switch bob? > If bob is connected to R2, any endpoint anywhere in bob should be able to > reach R2, and continue on to any endpoints in other logical switches (i.e. > alice) connected to R2. > > Cutting the patch port as you did in v3 is not enough. Unless you restrict > bob to the same subset of chassis as R2, I would think what you really want > is to associate the patch port's port binding with hv2. If you do that, > then on hv1, physical.c would add an entry in table 32 for datapath bob > that would direct traffic to the patch port down a tunnel to hv2. > > This seems like it would be a lot simpler if each "local router" is > limited to only one chassis. If a "local router" can be on multiple > chassis, I start thinking about multiple possible chassis and ECMP which > would add significant complexity. > Before this discussion goes too far, I would like to point out that I have done something similar to what Mickey is suggesting here for the l3 gateway work. I sent a patch here: http://openvswitch.org/pipermail/dev/2016-May/070790.html I will send the DNAT and SNAT implementations on top of the above patch either today evening or tomorrow (unless I hit some new bugs). But specifically for DNAT and SNAT, we want the router pipeline's ingress and egress to happen on the same host. > > Mickey > > > -Darrell Ball wrote: - > To: Mickey Spiegel/San Jose/IBM@IBMUS > From: Darrell Ball > Date: 05/09/2016 09:11PM > Cc: d...@openvswitch.com > Subject: Re: [ovs-dev] [patch_v1] ovn: add local router support (RFC) > > > > On Mon, May 9, 2016 at 4:40 PM, Mickey Spiegel > wrote: > I am missing something basic here. > > In your tests, you have logical switch bob that seems like it could be > present on both hv1 and hv2, and a logical router R2 that is local to hv2 > but not present on hv1. > > Exactly > > Wouldn't the logical switch bob flows on hv1 still send packets locally > to the patch port rp-bob? > But when the packets come back around to logical router R2 flows, they are > not present on hv1? > > Exactly; I don’t want R2 flows processed and downloaded > on HV1. > > > > Don't you need to change the patch ports so that they are not considered > local if the associated logical router is not local to this chassis? > > Its not required. > The router<->switch patch cabling is still there. > I did not “cut the cable” as it were; I enabled selective router flow > processing and download in this patch. The idea is to not process and > download flows that are not needed on a given HV. > > Its probably fine to also “cut the patch cable” for the router to > switch. Its pretty cheap to do that in a minimal way, so I added it for > now. I really want to keep it as simple as possible and not add unnecessary > code, however. > > > > If you add bob2 on hv1, would bob2 be able to reach alice1? > > No; take foo1 which is already on hv1 for this example; > if I try to send b/w foo1 and alice1, I have “no route to alice1, the > destination” because all I can use on hv1 is R1 routes. If I change the > test with new permissive catchall routes everywhere, I could do it, of > course, but that is something else and contrary to what you would want to > do. > > > > Mickey > > > -"dev" wrote: - > To: dlu...@gmail.com, d...@openvswitch.com > From: Darrell Ball > Sent by: "dev" > Date: 05/09/2016 11:58AM > Subject: [ovs-dev] [patch_v1] ovn: add local router support (RFC) > > This patch adds local router support. A logical router can > be declared local at northbound level via external_ids. > This is communicated to the southbound database via northd > which populates the external_id of the datapath_binding table. > ovn-controller will also allow a chassis to be configured
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
>
>
>
> Some reasons why having a “transit LS” is “undesirable” is:
>
> 1)1) It creates additional requirements at the CMS layer for setting
> up networks; i.e. additional programming is required at the OVN northbound
> interface for the special transit LSs, interactions with the logical router
> peers.
>
Agreed that there is additional work needed for the CMS plugin. That work
is needed even if it is just peering as they need to convert one router in
to two in OVN (unless OVN automatically makes this split)
>
> In cases where some NSX products do this, it is hidden from the user, as
> one would minimally expect.
>
> 2) 2) From OVN POV, it adds an additional OVN datapath to all
> processing to the packet path and programming/processing for that datapath.
>
> because you have
>
> R1<->Transit LS<->R2
>
> vs
>
> R1<->R2
>
Agreed that there is an additional datapath.
>
> 3) 3) You have to coordinate the transit LS subnet to handle all
> addresses in this same subnet for all the logical routers and all their
> transit LS peers.
>
I don't understand what you mean. If a user uses one gateway, a transit LS
only gets connected by 2 routers.
Other routers get their own transit LS.
>
> 4)4) Seems like L3 load balancing, ECMP, would be more complicated at
> best.
>
> 5)5) 1000s of additional arp resolve flows rules are needed in normal
> cases in addition to added burden of the special transit LS others flows.
>
I don't understand why that would be the case.
>
>
>
>
> >
> >
> >> This is usually only done if there is existing switching equipment than
> >> must be traversed
> >> But in the case, we are just dealing with software where we have total
> >> flexibility.
> >>
> >
> > From OpenStack perspective, each tenant gets a router and multiple
> > switches with different subnets. The idea is that the OpenStack network
> > plugin, can at best split this single tenant router into 2 with a switch
> in
> > between on a subnet that neutron does not use. Taking the same logic
> > forward for k8s, I can support multiple gateways.
> >
>
> As far as I have heard from Openstack folks, each tenant can create
> multiple logical routers; they can even overlap subnets if they wanted. So,
> I am not sure the above assumption holds true.
>
A tenant can create multiple logical routers. But a connected logical
topology can have one router connected to the gateway, atleast that is the
common use case.
>
>
>
> >
> > Connecting multiple routers to each other without a switch makes it a
> pain
> > to remember the interconnections and create multiple subnets (which may
> > simply not be available for a networking backend for internal use).
> >
>
> Well, just looking at the 10.x.x.x private IP range, there are more than 16
> million IP addresses
>
> Point to point direct router links, Rx<->Ry subnets, can be /31. In the
> most extreme case, maybe 20,000 addresses would be used. I don’t think
> there should be a subnet depletion problem here, unless it’s a contrived
> misconfiguration.
>
Who is going to manage all the interconnections? As far as I see a transit
LS is much more simpler.
>
>
>
>
> >
> >
> >>
> >>
> >>>
> >>> With the above goal in mind, this commit gives the general
> >>> ability to connect multiple routers via a switch.
> >>>
> >>> Signed-off-by: Gurucharan Shetty
> >>> ---
> >>> This needs the following 2 commits under review to
> >>> first go in.
> >>> 1. ofproto-dpif: Rename "recurse" to "indentation".
> >>> 2. ofproto-dpif: Do not count resubmit to later tables against limit.
> >>> ---
> >>> ovn/controller/lflow.c | 19 ++--
> >>> ovn/northd/ovn-northd.c | 56 ++-
> >>> ovn/ovn-nb.xml |7 --
> >>> tests/ovn.at| 236
> >>> +++
> >>> 4 files changed, 299 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
> >>> index 96b7c66..efc427d 100644
> >>> --- a/ovn/controller/lflow.c
> >>> +++ b/ovn/controller/lflow.c
> >>> @@ -215,15 +215,15 @@ add_logical_flows(struct controller_ctx *ctx,
> >>> const struct lport_index *lports,
> >>> if (is_switch(ldp)) {
> >>> /* For a logical switch datapath, local_datapaths tells us
> >>> if there
> >>> * are any local ports for this datapath. If not, we can
> >>> skip
> >>> - * processing logical flows if the flow belongs to egress
> >>> pipeline
> >>> - * or if that logical switch datapath is not patched to
> any
> >>> logical
> >>> - * router.
> >>> + * processing logical flows if that logical switch
> datapath
> >>> is not
> >>> + * patched to any logical router.
> >>> *
> >>> - * Otherwise, we still need the ingress pipeline because
> >>> even if
> >>> - * there are no local ports, we still may need to execute
> >>> the ingress
> >>> - * pipeline after a packet leaves a lo
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
> On May 11, 2016, at 10:45 PM, Darrell Ball wrote: > > > >> On Wed, May 11, 2016 at 8:51 PM, Guru Shetty wrote: >> >> >> >> >> > On May 11, 2016, at 8:45 PM, Darrell Ball wrote: >> > >> >> On Wed, May 11, 2016 at 4:42 PM, Guru Shetty wrote: >> >> >> >> >> >>> >> >>> Some reasons why having a “transit LS” is “undesirable” is: >> >>> >> >>> 1)1) It creates additional requirements at the CMS layer for setting >> >>> up networks; i.e. additional programming is required at the OVN >> >>> northbound >> >>> interface for the special transit LSs, interactions with the logical >> >>> router >> >>> peers. >> >> >> >> Agreed that there is additional work needed for the CMS plugin. That work >> >> is needed even if it is just peering as they need to convert one router in >> >> to two in OVN (unless OVN automatically makes this split) >> > >> > The work to coordinate 2 logical routers and one special LS is more and >> > also more complicated than >> > to coordinate 2 logical routers. >> > >> > >> >> >> >> >> >>> >> >>> In cases where some NSX products do this, it is hidden from the user, as >> >>> one would minimally expect. >> >>> >> >>> 2) 2) From OVN POV, it adds an additional OVN datapath to all >> >>> processing to the packet path and programming/processing for that >> >>> datapath. >> >>> >> >>> because you have >> >>> >> >>> R1<->Transit LS<->R2 >> >>> >> >>> vs >> >>> >> >>> R1<->R2 >> >> >> >> Agreed that there is an additional datapath. >> >> >> >> >> >>> >> >>> 3) 3) You have to coordinate the transit LS subnet to handle all >> >>> addresses in this same subnet for all the logical routers and all their >> >>> transit LS peers. >> >> >> >> I don't understand what you mean. If a user uses one gateway, a transit LS >> >> only gets connected by 2 routers. >> >> Other routers get their own transit LS. >> > >> > >> > Each group of logical routers communicating has it own Transit LS. >> > >> > Take an example with one gateway router and 1000 distributed logical >> > routers for 1000 tenants/hv, >> > connecting 1000 HVs for now. >> > Lets assume each distributed logical router only talks to the gateway >> > router. >> >> That is a wrong assumption. Each tenant has his own gateway router (or more) > > Its less of an assumption but more of an example for illustrative purposes; > but its good that you > mention it. I think one of the main discussion points was needing thousands of arp flows and thousands of subnets, and it was on an incorrect logical topology, I am glad that it is not an issue any more. > > The DR<->GR direct connection approach as well as the transit LS approach can > re-use private > IP pools across internal distributed logical routers, which amount to VRF > contexts for tenants networks. > > The Transit LS approach does not scale due to the large number of distributed > datapaths required and > other high special flow requirements. It has more complex and higher > subnetting requirements. In addition, there is greater complexity for > northbound management. Okay, now to summarize from my understanding: * A transit LS uses one internal subnet to connect multiple GR with one DR whereas direct multiple GR to one DR via peering uses multiple internal subnets. * A transit LS uses an additional logical datapath (split between 2 machines via tunnel) per logical topology which is a disadvantage as it involves going through an additional egress or ingress openflow pipeline in one host. * A transit LS lets you split a DR and GR in such a way that the packet entering physical gateway gets into egress pipeline of a switch and can be made to renter the ingress pipeline of a router making it easier to apply stateful policies as packets always enter ingress pipeline of a router in all directions (NS, SN and east west) * The general ability to connect multiple router to a switch (which this patch is about) also lets you connect your physical interface of your physical gateway connected to a physical topology to a LS in ovn which inturn is connected to multiple GRs
Re: [ovs-dev] [PATCH] tests: Add valgrind targets for ovn utilities and dameons.
Thank you William and Ryan. I pushed this to master. On 12 May 2016 at 09:32, William Tu wrote: > Thanks for adding this, I will re-run the OVN-related valgrind tests. > > On Thu, May 12, 2016 at 9:14 AM, Ryan Moats wrote: > > > > > > > "dev" wrote on 05/12/2016 10:23:39 AM: > > > > > From: Gurucharan Shetty > > > To: dev@openvswitch.org > > > Cc: Gurucharan Shetty > > > Date: 05/12/2016 10:42 AM > > > Subject: [ovs-dev] [PATCH] tests: Add valgrind targets for ovn > > > utilities and dameons. > > > Sent by: "dev" > > > > > > Signed-off-by: Gurucharan Shetty > > > --- > > > tests/automake.mk |4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/tests/automake.mk b/tests/automake.mk > > > index a5c6074..211a80d 100644 > > > --- a/tests/automake.mk > > > +++ b/tests/automake.mk > > > @@ -152,6 +152,10 @@ check-lcov: all tests/atconfig tests/atlocal $ > > > (TESTSUITE) $(check_DATA) clean-lc > > > # valgrind support > > > > > > valgrind_wrappers = \ > > > + tests/valgrind/ovn-controller \ > > > + tests/valgrind/ovn-nbctl \ > > > + tests/valgrind/ovn-northd \ > > > + tests/valgrind/ovn-sbctl \ > > > tests/valgrind/ovs-appctl \ > > > tests/valgrind/ovs-ofctl \ > > > tests/valgrind/ovstest \ > > > -- > > > > This makes a lot of sense to me, we should especially be checking the > > daemons... > > > > Acked-by: Ryan Moats > > ___ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
> > >> >> I think one of the main discussion points was needing thousands of arp >> flows and thousands of subnets, and it was on an incorrect logical >> topology, I am glad that it is not an issue any more. >> > > I think you misunderstood - having one or more gateway per tenant does not > make Transit LS better in flow scale. > The size of a Transit LS subnet and management across Transit LSs is one > the 5 issues I mentioned and it remains the same > as do the other issues. > > Based on the example with 1000 HVs, 1000 tenants, 1000 HV/tenant, one > distributed logical router per tenant > spanning 1000 HVs, one gateway per tenant, we have a Transit LS with 1001 > router type logical ports (1000 HVs + one gateway). > A transit LS does not have 1001 router type ports. It has just two. One of them only resides in the gateway. The other one resides in every hypervisor. This is the same as a router peer port. Transit LS adds one extra per hypervisor, which I have agreed as a disadvantage. If that is what you mean, then it is right. > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
> > > I think you misunderstood - having one or more gateway per tenant does not > make Transit LS better in flow scale. > The size of a Transit LS subnet and management across Transit LSs is one > the 5 issues I mentioned and it remains the same > as do the other issues. > > Based on the example with 1000 HVs, 1000 tenants, 1000 HV/tenant, one > distributed logical router per tenant > spanning 1000 HVs, one gateway per tenant, we have a Transit LS with 1001 > router type logical ports (1000 HVs + one gateway). > > Now, based on your previous assertion earlier: > "If a user uses one gateway, a transit LS only gets connected by 2 > routers. > Other routers get their own transit LS." > > This translates: > one Transit LS per tenant => 1000 Transit LS datapaths in total > 1001 Transit LS logical ports per Transit LS => 1,001,000 Transit LS > logical ports in total > 1001 arp resolve flows per Transit LS => 1,001,000 flows just for arp > resolve. > Each Transit LS comes with many other flows: so we multiply that number of > flows * 1000 Transit LSs = ? flows > 1001 addresses per subnet per Transit LS; I suggested addresses should be > reused across subnets, but when each subnet is large > Re-reading. The above is a wrong conclusion making me believe that there is a big disconnect. A subnet in transit LS has only 2 IP addresses (if it is only one physical gateway). Every additional physical gateway can add one additional IP address to the subnet (depending on whether the new physical gateway has a gateway router added for that logical topology.). ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/5] ovn: Introduce l3 gateway router.
> > > > Completely agree that you need to go through a common point in both > directions > in the same chassis. > > Why does this require a separate gateway router? > The primary reason to choose a separate gateway router was to support multiple physical gateways for k8s to which you can loadbalance your traffic from external world. i.e you will have a router in each physical gateway with its own floating IP per service. From external world, you can loadbalance traffic to your gateways. The floating IP is further loadbalanced to an internal workload. > Why can't it just be a centralized gateway router port on an otherwise > distributed > router? > It is indeed one of the solutions for my problem statement (provided you can support multiple physical gateway chassis.). I haven't spent too much time thinking on how to do this for multiple physical gateways. > > Looking at the logic for ports on remote chassis in physical.c, I see no > reason why > that logic cannot work for logical router datapaths just like it works for > logical > switch datapaths. On logical switches, some ports are distributed and run > everywhere, e.g. localnet, and other ports run on a specific chassis, e.g. > vif and > your proposed "gateway" port. > Am I missing something that prevents a mix of centralized and distributed > ports > on a logical router datapath? > You will have to give me some more details (I am currently unable to visualize your solution). May be start with a simple topology of one DR connected to two LS. Simple packet walkthrough (in english) for north-south (external to internal via floating IPs) and its return traffic (going through conntrack), south-north traffic (and its return traffic) and east-west (via central gateway). My thinking is this: If we want to do NAT in a router, then we need to have a ingress pipeline as well as an egress pipeline. A router has multiple ports. When a packet comes in any router port, I want to be able to do DNAT (and reverse its effect) and when packet exits any port, I want to be able to do SNAT. I also should be able to do both DNAT and SNAT on a single packet (to handle north-south loadbalancing). So the entire router should be there at a single location. > > We have not tried it yet, but it seems like this would simplify things a > lot: > 1. Only one router needs to be provisioned rather than a distributed > router and a > centralized gateway router > 2. No need for static routes between the distributed and centralized > gateway routers > 3. No need for transit logical switches, transit subnets, or transit flows > 4. Less passes through datapaths, improving performance > The above is ideal. > > You can then pin DNAT and SNAT logic to the centralized gateway port, for > traffic to > physical networks. East/west traffic to floating IPs still requires > additional logic on > other ports, as proposed in Chandra's floating IP patch. > > We want to get to a point where SNAT traffic goes through a centralized > gateway > port, but DNAT traffic goes through a distributed patch port. Please tell me what does DNAT mean and what does SNAT mean for you. I may be talking the opposite thing than you. dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
On 12 May 2016 at 16:34, Darrell Ball wrote: > On Thu, May 12, 2016 at 10:54 AM, Guru Shetty wrote: > > > > >> I think you misunderstood - having one or more gateway per tenant does > >> not make Transit LS better in flow scale. > >> The size of a Transit LS subnet and management across Transit LSs is one > >> the 5 issues I mentioned and it remains the same > >> as do the other issues. > >> > >> Based on the example with 1000 HVs, 1000 tenants, 1000 HV/tenant, one > >> distributed logical router per tenant > >> spanning 1000 HVs, one gateway per tenant, we have a Transit LS with > 1001 > >> router type logical ports (1000 HVs + one gateway). > >> > >> Now, based on your previous assertion earlier: > >> "If a user uses one gateway, a transit LS only gets connected by 2 > >> routers. > >> Other routers get their own transit LS." > >> > >> This translates: > >> one Transit LS per tenant => 1000 Transit LS datapaths in total > >> 1001 Transit LS logical ports per Transit LS => 1,001,000 Transit LS > >> logical ports in total > >> 1001 arp resolve flows per Transit LS => 1,001,000 flows just for arp > >> resolve. > >> Each Transit LS comes with many other flows: so we multiply that number > >> of flows * 1000 Transit LSs = ? flows > >> 1001 addresses per subnet per Transit LS; I suggested addresses should > be > >> reused across subnets, but when each subnet is large > >> > > > > Re-reading. The above is a wrong conclusion making me believe that there > > is a big disconnect. A subnet in transit LS has only 2 IP addresses (if > it > > is only one physical gateway). Every additional physical gateway can add > > one additional IP address to the subnet (depending on whether the new > > physical gateway has a gateway router added for that logical topology.). > > > > > With respect to the IP address usage. I think a diagram would help > especially the K8 case, > Drawing a diagram here is not feasible. Happy to do it on a whiteboard though. > which I had heard in other conversations may have a separate gateway on > every HV ?. Hence, I would like to know what that means - i.e. were you > thinking to run separate gateways routers on every HV for K8 ? > Yes, thats the plan (as many as possible). 100 routers is a target. Not HV, but a VM. > > With respect to the other questions, I think its best approach would be to > ask direct questions so those > direct questions get answered. > > 1) With 1000 HVs, 1000 HVs/tenant, 1 distributed router per tenant, you > choose the number of gateways/tenant: > > a) How many Transit LS distributed datapaths are expected in total ? > One (i.e the same as the distributed router). > > b) How many Transit LS logical ports are needed at the HV level ? > > what I mean by that is lets say we have one additional logical port at > northd level and 1000 HVs then if we need to download that port to 1000 > HVs, I consider that to be 1000 logical ports at the HV level because > downloading and maintaining state across HVs at scale is more expensive > than for a single hypervisor. > 1000 additional ones. It is the same as your distributed logical switch or logical router (this is the case even with the peer routers) > > c) How many Transit LS arp resolve entries at the HV level ? > > what I mean by that is lets say we have one additional arp resolve flow at > northd level and 1000 HVs then if we need to download that arp resolve flow > to 1000 HVs, I consider that to be 1000 flows at the HV level because > downloading and maintaining state across multiple HVs is more expensive > that a single hypervisor. > 2 ARP flows per transit LS * 1000 HVs. Do realize that a single bridge on a single hypervisor typically has flows in the 100,000 range. Even a million is feasbile. Microsegmentation use cases has 1 ACLs per logical switch. So that is 1 * 1000 for your case form single LS. So do you have some comparative perspectives. dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.
> > > >> > >> With respect to the other questions, I think its best approach would be > to > >> ask direct questions so those > >> direct questions get answered. > >> > >> 1) With 1000 HVs, 1000 HVs/tenant, 1 distributed router per tenant, you > >> choose the number of gateways/tenant: > >> > >> a) How many Transit LS distributed datapaths are expected in total ? > >> > > > > One (i.e the same as the distributed router). > > > > > i.e. > 1000 distributed routers => 1000 Transit LSs > Yes. > > > > > > > > >> > >> b) How many Transit LS logical ports are needed at the HV level ? > >> > >> what I mean by that is lets say we have one additional logical port at > >> northd level and 1000 HVs then if we need to download that port to 1000 > >> HVs, I consider that to be 1000 logical ports at the HV level because > >> downloading and maintaining state across HVs at scale is more expensive > >> than for a single hypervisor. > >> > > > > 1000 additional ones. It is the same as your distributed logical switch > or > > logical router (this is the case even with the peer routers) > > > > Did you mean 2000 including both ends of the Transit LS ? > No. One end is only on the physical gateway to act as a physical endpoint. > > > > > > > > > > >> > >> c) How many Transit LS arp resolve entries at the HV level ? > >> > >> what I mean by that is lets say we have one additional arp resolve flow > at > >> northd level and 1000 HVs then if we need to download that arp resolve > >> flow > >> to 1000 HVs, I consider that to be 1000 flows at the HV level because > >> downloading and maintaining state across multiple HVs is more expensive > >> that a single hypervisor. > >> > > > > 2 ARP flows per transit LS * 1000 HVs. > > > > oops; I underestimated by half > > > > > Do realize that a single bridge on a single hypervisor typically has > flows > > in the 100,000 range. Even a million is feasbile. > > > > I know. > I am thinking about the coordination across many HVs. > There is no co-ordination. HV just downloads from ovn-sb. This is absolutely not different than any of the other distributed datapaths that we have. If introduction of one additional datapath is a problem, then OVN has a problem in general because it then simply means that it can only do one DR per logical topology. A transit LS is much less resource intensive (as it consumes just one additional port) than a DR connected to another DR (not GR) as peers (in this case have 2 additional ports per DR and then whatever additional switch ports that are connected to it). If the larger concern is about having 1000 tenants, then we need to pass more hints to ovn-controller about interconnections so that it only programs things relevant to local VMs and containers which are limited by the number of CPUs and Memory and is usually in the order of 10s. > > > > > Microsegmentation use cases has 1 ACLs per logical switch. So that is > > 1 * 1000 for your case form single LS. So do you have some > comparative > > perspectives. > > > > > > > > dev mailing list > >> dev@openvswitch.org > >> http://openvswitch.org/mailman/listinfo/dev > >> > > > > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Seek information about OVN L3 gateway and NAT
> > > > There was an in-person meeting yesterday at VMware with Mickey (from > that thread) and some other IBMers. I couldn't attend the whole meeting > but I assume that some conclusions were reached. I guess that we'll > know more soon. > The conclusion of the meeting was that we will go ahead with the "gateway router" approach for conntrack based NAT and will be used by anyone that need L3 and L4 based NAT. For the OpenStack case of floating ips (which does not need L4 ports to be NATed), the idea is to not use conntrack as much as possible and also to not use the additional gateway router. We think, there is a workable solution for north-south and south-north cases. The guys at IBM will work on the east-west case to see how they could potentially leverage conntrack for that particular use case. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [OVN] CNI plugin and Kubernetes integration
On 19 May 2016 at 03:57, Salvatore Orlando wrote: > [Accidentally sent message before completing, resuming here] > > Hello, > > I have been working for a while on integration with kubernetes with a CNI > plugin for OVN. > The work in [1] is forked by Guru's repository by the same name [2]. > > Most consumers of the CNI interface have an expectation that when returning > from the plugin the container interface is fully configured and ready to > send/receive data. > For the OVN case this means that when returning from the CNI both VIF > plugging and logical configuration (lport and ACLs) must be completed. > > However, in the current implementation logical port management was moved > out of the plugin [3] in order to avoid calling into the OVN NB Database. > This means that in order to fulfil the "network ready" expectation there's > a need for adding a synchronisation point in the CNI plugin (ie: a blocking > call waiting for a "ready" event). > > At this stage I am wondering whether it might be actually better to revert > to the previous state - where logical port creation was performed in the > plugin [4]. > The disadvantage of moving it back would be that we now need to provide a way for the plugins to securely talk to OVN NB. This in itself is not a big deal for the "overlay" mode for a single tenant as we have ssl support. But this will become a problem for multi-tenancy as now a container breakout would essentially have full control over your network. So, ideally your current model is better. The plugins have access to k8s API server itself. So one way to synchronize is to pass the ready event via a pod annotation? You probably have better ideas. > I am wondering whether it might be fair to expect ovn-northd to be > accessible from the control plane. What is your opinion? > > Should that be the way to go, the CNI plugin should also take care of > implementing ACLs before returning (not just applying a drop-all rule as it > does now [5]) - because otherwise networking configuration would not be > complete (especially with a drop-all rule!). > > Salvatore > > [1] https://github.com/salv-orlando/ovn-kubernetes > [2] https://github.com/shettyg/ovn-kubernetes > [3] > > https://github.com/salv-orlando/ovn-kubernetes/commit/b951079fe3100160478f0cbc0eaf6729c088a4af > [4] > > https://github.com/salv-orlando/ovn-kubernetes/blob/78c7b39715894cfa64066b294a80f55d2c01e356/bin/ovn_cni.py#L191 > [5] > > https://github.com/salv-orlando/ovn-kubernetes/blob/master/ovn_k8s/conn_processor.py#L59 > > > > > > > On 19 May 2016 at 12:38, Salvatore Orlando wrote: > > > Hello, > > > > I have been working for a while on integration with kubernetes with a CNI > > plugin for OVN. > > The work in [1] is forked by Guru's repository by the same name [2]. > > > > Most consumers of the CNI interface have an expectation that when > > returning from the plugin the container interface is fully configured and > > ready to send/receive data. > > For the OVN > > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] need info on ssl in manager table
On 20 May 2016 at 09:07, D M, Vikas wrote: > Hi , > > We are using ovsdb hardware vtep schema in openstack l2gateway project [1] > > ovsdb server initiates the connection to l2gateway agent with the entries > in manager table in ovsdb hardware vtep schema[3]. > Already tcp connection for manager table is implemented in our code [2]. > > I am trying to use ovsdb manager table (hardware vtep schema) by setting > ssl:IP:PORT. (ssl:IP:6632) > > But while implementing ssl communication in our code is throwing error, > saying unknown protocol, while wrapping the socket (sslv23) . > (I have tried with different versions of SSL protocol, but some are not > supported) > > I am using working certificates. Since the same certificates are used for > initiating ssl connection from the other way and it works fine. > (l2gateway agent to ovsdb server via ssl connection). > > While stating ovsdb-server with ssl we are specifying the certs path. > But for manager table, ovsdb-server has to pick the certs from some > location while initiating the connection. > So what is the default location? > You will have to provide the location. Like here: https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-vtep.init#L43 > > Is manager table works with SSl ? > Am I missing something? > > Please guide me on this. > > Note: my setup details > Both nodes are with below config and date. > Ubuntu 14.04 > Python 2.7.6 > OpenSSL 1.0.1f > > > Thanks, > Vikas > > [1] > https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api-implementation.rst > [2] https://review.openstack.org/#/c/208524/ > [3] https://bugs.launchpad.net/networking-l2gw/+bug/1466302 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] need info on ssl in manager table
You will have to create the vtep database. The file that I referred is a startup script of a vtep debian package and if you look at it, it does create one. You will have to do something similar. > On May 20, 2016, at 9:22 PM, "D M, Vikas" wrote: > > Hi guru, > > Thanks for the guidance. > > My ovsdb server was enabled with SSL via below command. > (ovsdb-server -C /home/sdn/certificates/switch/cacert.pem -p > /home/sdn/certificates/switch/sc-privkey.pem -c > /home/sdn/certificates/switch/sc-cert.pem /usr/local/etc/openvswitch/conf.db > --remote=pssl:6632 --remote=db:hardware_vtep,Global,managers --pidfile > --overwrite-pidfile --detach --no-chdir --verbose > --log-file=/usr/local/var/log/openvswitch/ovsdb-server.log) > > Only missing thing in my command is /etc/openvswitch/vtep.db . > So added the same. > (ovsdb-server -C /home/sdn/certificates/switch/cacert.pem -p > /home/sdn/certificates/switch/sc-privkey.pem -c > /home/sdn/certificates/switch/sc-cert.pem /usr/local/etc/openvswitch/conf.db > /usr/local/etc/openvswitch/vtep.db --remote=pssl:6632 > --remote=db:hardware_vtep,Global,managers --pidfile --overwrite-pidfile > --detach --no-chdir --verbose > --log-file=/usr/local/var/log/openvswitch/ovsdb-server.log) > > But there is no vtep.db file, only conf.db file exists in > /usr/local/etc/openvswitch/ folder. > So ovsdb-server fails to start with IO Error (ovsdb-server: I/O error: open: > /usr/local/etc/openvswitch/vtep.db failed (No such file or directory)) > > So searched the entire / dir to locate vtep.db file. But vtep.db doesn’t > exist. > > Thanks, > Vikas > > > > > > > > > > From: Guru Shetty [mailto:g...@ovn.org] > Sent: Friday, May 20, 2016 10:02 PM > To: D M, Vikas > Cc: dev@openvswitch.org; Kamat, Maruti Haridas > Subject: Re: [ovs-dev] need info on ssl in manager table > > > > On 20 May 2016 at 09:07, D M, Vikas > mailto:vikas@hpe.com>> wrote: > Hi , > > We are using ovsdb hardware vtep schema in openstack l2gateway project [1] > > ovsdb server initiates the connection to l2gateway agent with the entries in > manager table in ovsdb hardware vtep schema[3]. > Already tcp connection for manager table is implemented in our code [2]. > > I am trying to use ovsdb manager table (hardware vtep schema) by setting > ssl:IP:PORT. (ssl:IP:6632) > > But while implementing ssl communication in our code is throwing error, > saying unknown protocol, while wrapping the socket (sslv23) . > (I have tried with different versions of SSL protocol, but some are not > supported) > > I am using working certificates. Since the same certificates are used for > initiating ssl connection from the other way and it works fine. > (l2gateway agent to ovsdb server via ssl connection). > > While stating ovsdb-server with ssl we are specifying the certs path. > But for manager table, ovsdb-server has to pick the certs from some location > while initiating the connection. > So what is the default location? > You will have to provide the location. Like here: > https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-vtep.init#L43 > > > > Is manager table works with SSl ? > Am I missing something? > > Please guide me on this. > > Note: my setup details > Both nodes are with below config and date. > Ubuntu 14.04 > Python 2.7.6 > OpenSSL 1.0.1f > > > Thanks, > Vikas > > [1] > https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api-implementation.rst > [2] https://review.openstack.org/#/c/208524/ > [3] https://bugs.launchpad.net/networking-l2gw/+bug/1466302 > ___ > dev mailing list > dev@openvswitch.org<mailto:dev@openvswitch.org> > http://openvswitch.org/mailman/listinfo/dev > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 2/5] ovn: Introduce l3 gateway router.
On 21 May 2016 at 11:48, Darrell Ball wrote:
> I made some modifications to code in Patches 1 and 2 to remove the Transit
> LS
> requirements.
>
These are the reasons for the need of a LS to be able to be connected to
multiple routers.
1. I think it should be left to the upstream user on how they want to
connect their DRs with GRs. On a 1000 node k8s cluster using peering would
mean that I need to add 1000 DR router ports and manage 1000 subnets. If I
use a LS in-between I need to add only one router port for the DR and
manage only one subnet.
2. The ability to connect multiple routers to a switch is needed on the
north side of the GR as we will need to connect multiple GRs to a switch to
be able to access the physical network for ARP resolution. This is for both
north-south as well as east-west.
3. A Transit LS is needed for the final patch in this series to work (i.e
actual DNAT and SNAT). The final patch needs the packet to enter the
ingress pipeline of a router. The current implementation cannot handle
peering as packets enter the egress pipeline of the router. To support
peering, it will need further enhancements.
>
> In summary:
>
> I removed all changes to lflow.c thereby reinstating the previous
> optimization.
>
> I made some modifications to ovn-northd.c changes to remove the Transit LS
> special
> aspects and additional arp flows.
>
> I left the other code changes in Patches 1 and 2 as they were.
>
> The overall resulting diff to support both patches 1 and 2 is reduced in
> ovn-northd.c
> and becomes:
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index b271f7f..2e2236b 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -702,11 +702,25 @@ ovn_port_update_sbrec(const struct ovn_port *op)
> {
> sbrec_port_binding_set_datapath(op->sb, op->od->sb);
> if (op->nbr) {
> -sbrec_port_binding_set_type(op->sb, "patch");
> +/* If the router is for l3 gateway, it resides on a chassis
> + * and its port type is "gateway". */
> +const char *chassis = smap_get(&op->od->nbr->options, "chassis");
> +
> +if (chassis && op->peer && op->peer->od && op->peer->od->nbs){
> +sbrec_port_binding_set_type(op->sb, "gateway");
> +} else {
> +sbrec_port_binding_set_type(op->sb, "patch");
> +}
>
> const char *peer = op->peer ? op->peer->key : "";
> -const struct smap ids = SMAP_CONST1(&ids, "peer", peer);
> -sbrec_port_binding_set_options(op->sb, &ids);
> +struct smap new;
> +smap_init(&new);
> +smap_add(&new, "peer", peer);
> +if (chassis) {
> +smap_add(&new, "gateway-chassis", chassis);
> +}
> +sbrec_port_binding_set_options(op->sb, &new);
> +smap_destroy(&new);
>
> sbrec_port_binding_set_parent_port(op->sb, NULL);
> sbrec_port_binding_set_tag(op->sb, NULL, 0);
> @@ -716,15 +730,31 @@ ovn_port_update_sbrec(const struct ovn_port *op)
> sbrec_port_binding_set_type(op->sb, op->nbs->type);
> sbrec_port_binding_set_options(op->sb, &op->nbs->options);
> } else {
> -sbrec_port_binding_set_type(op->sb, "patch");
> +const char *chassis = NULL;
> +if (op->peer && op->peer->od && op->peer->od->nbr) {
> +chassis = smap_get(&op->peer->od->nbr->options,
> "chassis");
> +}
> +/* A switch port connected to a gateway router is also of
> + * type "gateway". */
> +if (chassis) {
> +sbrec_port_binding_set_type(op->sb, "gateway");
> +} else {
> +sbrec_port_binding_set_type(op->sb, "patch");
> +}
>
> const char *router_port = smap_get(&op->nbs->options,
> "router-port");
> if (!router_port) {
> router_port = "";
> }
> -const struct smap ids = SMAP_CONST1(&ids, "peer",
> router_port);
> -sbrec_port_binding_set_options(op->sb, &ids);
> +struct smap new;
> +smap_init(&new);
> +smap_add(&new, "peer", router_port);
> +if (chassis) {
> +smap_add(&new, "gateway-chassis", chassis);
> +}
> +sbrec_port_binding_set_options(op->sb, &new);
> +smap_destroy(&new);
> }
> sbrec_port_binding_set_parent_port(op->sb, op->nbs->parent_name);
> sbrec_port_binding_set_tag(op->sb, op->nbs->tag, op->nbs->n_tag);
>
>
> I added a new test to demonstrate direct DR<->GR connectivity.
>
>
> AT_SETUP([ovn -- 2 HVs, 3 LRs, 1 DR directly connected to 2 gateway routers
> ])
> AT_KEYWORDS([ovndirectlyconnectedrouters])
> AT_SKIP_IF([test $HAVE_PYTHON = no])
> ovn_start
>
> # Logical network:
> # Three LRs - R1, R2 and R3 that are connected to each other directly
> # in 20.0.0.2/31 and 21.0.0.2/
Re: [ovs-dev] [RFC 1/8] system-traffic: Load balancing.
On 14 March 2016 at 14:36, Ben Pfaff wrote:
> On Mon, Mar 14, 2016 at 01:57:57PM -0700, Jarno Rajahalme wrote:
> >
> > > On Mar 14, 2016, at 10:42 AM, Ben Pfaff wrote:
> > >
> > > On Sun, Feb 28, 2016 at 10:33:17PM -0800, Gurucharan Shetty wrote:
> > >> From: Jarno Rajahalme
> > >>
> > >> Signed-off-by: Jarno Rajahalme
> > >
> > > The core of the change here seems to be:
> > >
> > >> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
> > >> index becf02d..8f6e02e 100644
> > >> --- a/lib/ofp-actions.c
> > >> +++ b/lib/ofp-actions.c
> > >> @@ -5913,7 +5913,8 @@ ofpacts_execute_action_set(struct ofpbuf
> *action_list,
> > >> * not be sent anywhere. */
> > >> if (!ofpacts_copy_last(action_list, action_set, OFPACT_GROUP) &&
> > >> !ofpacts_copy_last(action_list, action_set, OFPACT_OUTPUT) &&
> > >> -!ofpacts_copy_last(action_list, action_set,
> OFPACT_RESUBMIT)) {
> > >> +!ofpacts_copy_last(action_list, action_set, OFPACT_RESUBMIT)
> &&
> > >> +!ofpacts_copy_last(action_list, action_set, OFPACT_CT)) {
> > >> ofpbuf_clear(action_list);
> > >> }
> > >> }
> > >
> > > The change to ofproto-dpif-xlate seems undesirable, because if I read
> it
> > > correctly it means that every packet translation that involves a group
> > > bucket will put that into the log, without even rate-limiting. I think
> > > that this change was probably meant for debugging, without meaning to
> be
> > > applied permanently.
> > >
> >
> > Right, I sent my unpolished patch to Guru, and did not remember about
> > the debugging I added to ofproto-dpif-xlate. So, to be clear, the
> > ofproto-dpif-xlate changes in this patch should not be applied,
> > otherwise this should be good to go.
>
> OK. If the xlate changes are dropped, then:
> Acked-by: Ben Pfaff
>
It took a while to decide whether to merge this patch. Back then, we were
considering dp_hash based approach for group selection and it was not very
clear to me whether this patch would still be relevant. But, based on
Jarno's RFC patch "xlate: Use dp_hash for select groups", this is still
relevant. I intend to drop all the changes in ofproto-dpif-xlate as
requested in the review and apply this with the following commit message
after some time (I have also modified the output formatting of the unit
test to get consistent results).
Author: Jarno Rajahalme
Date: Tue May 24 00:25:36 2016 -0700
ofp-actions: Allow conntrack action in group buckets.
Conntrack action used in group buckets lets
us do simple load-balancing.
Signed-off-by: Jarno Rajahalme
[g...@ovn.org updated the commit message and made
a small change to the test output format]
Signed-off-by: Gurucharan Shetty
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator
On 26 May 2016 at 07:13, Kyle Mestery wrote: > Greetings! > > I was looking for some L3 related items and came across the following > patch on patchworks [1]. This was some work done to add L3 routing to > the vtep emulator. Guru had commented on this indicating the > usefulness for using the vtep-emulator as a L3 edge device, but he had > a bunch of comments around the approach taken by Shuangmin. I never > saw a reply to Guru on list. What is the status of the thinking here? > I also see value in this as an L3 edge device. > We do have a more sophisticated L3 gateway related patches out for review for OVN (This does not integrate with VTEP schema). Was your interest with L3 gateway in general or VTEP schema based L3 gateway in particular? > > Thanks! > Kyle > > [1] https://patchwork.ozlabs.org/patch/553435/ > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator
On 26 MaVTEP schema based L3 gateway in particular? > > > > Thanks Guru. I was looking at the VTEP schema based L3 GW as well, and > wondering if this patch had pretty much been abandoned. I can see some > use for using VTEP as an L3 edge device. > The patch has been abandoned for the time being. I don't know of anyone actively working on it right now. > > >> > >> > >> Thanks! > >> Kyle > >> > >> [1] https://patchwork.ozlabs.org/patch/553435/ > >> ___ > >> dev mailing list > >> dev@openvswitch.org > >> http://openvswitch.org/mailman/listinfo/dev > > > > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Question on L3 Logical Router in vtep-emulator
> > > OK, I'm going to play with this a bit. I was mostly interested in > feedback from others. We're interested in this approach and so if we > take the patch up does it stand a chance of merging? > If I remember correctly, the main problem was around ARP handling when the destination's mac address is not known. Who would do the job that ovn-controller currently does for OVN? If a clean solution is proposed, then I can't think of any reasons why it can't be merged. > > >> > >> > >> >> > >> >> > >> >> Thanks! > >> >> Kyle > >> >> > >> >> [1] https://patchwork.ozlabs.org/patch/553435/ > >> >> ___ > >> >> dev mailing list > >> >> dev@openvswitch.org > >> >> http://openvswitch.org/mailman/listinfo/dev > >> > > >> > > > > > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 1/5] ovn-northd: Support connecting multiple routers to a switch.
On 2 June 2016 at 13:06, Ben Pfaff wrote: > On Thu, May 19, 2016 at 01:02:30PM -0700, Gurucharan Shetty wrote: > > Currently we can connect routers via "peer"ing. This limits > > the number of routers that can be connected with each other > > directly to 2. > > > > One of the design goals for L3 Gateway is to be able to > > have multiple gateways (each with their own router) > > connected to a distributed router via a switch. > > > > With the above goal in mind, this commit gives the general > > ability to connect multiple routers via a switch. > > > > Signed-off-by: Gurucharan Shetty > > Please describe this new priority-101 rule in ovn-northd.8.xml. > I tried to remember the reason for having the flow priority of 101 instead of 100 and couldn't find any. So I changed it to 100. With it now being 100, there is already documentation that matches the flow (which was written for peer routers) and reads: For each logical router port with an IP address A and a mac address of E that is reachable via a different logical router port P, a priority-100 flow with match outport === P && reg0 == A has actions eth.dst = E; next;. Since the above holds true for this change too, I applied this. > > Acked-by: Ben Pfaff > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 2/5] ovn: Introduce l3 gateway router.
On 2 June 2016 at 13:23, Ben Pfaff wrote: > On Thu, May 19, 2016 at 01:02:31PM -0700, Gurucharan Shetty wrote: > > Currently OVN has distributed switches and routers. When a packet > > exits a container or a VM, the entire lifecycle of the packet > > through multiple switches and routers are calculated in source > > chassis itself. When the destination endpoint resides on a different > > chassis, the packet is sent to the other chassis and it only goes > > through the egress pipeline of that chassis once and eventually to > > the real destination. > > > > When the packet returns back, the same thing happens. The return > > packet leaves the VM/container on the chassis where it resides. > > The packet goes through all the switches and routers in the logical > > pipleline on that chassis and then sent to the eventual destination > > over the tunnel. > > > > The above makes the logical pipeline very flexible and easy. But, > > creates a problem for cases where you need to add stateful services > > (via conntrack) on switches and routers. > > > > For l3 gateways, we plan to leverage DNAT and SNAT functionality > > and we want to apply DNAT and SNAT rules on a router. So we ideally need > > the packet to go through that router in both directions in the same > > chassis. To achieve this, this commit introduces a new gateway router > which is > > static and can be connected to your distributed router via a switch. > > > > To make minimal changes in OVN's logical pipeline, this commit > > tries to make the switch port connected to a l3 gateway router look like > > a container/VM endpoint for every other chassis except the chassis > > on which the l3 gateway router resides. On the chassis where the > > gateway router resides, the connection looks just like a patch port. > > > > This is achieved by the doing the following: > > Introduces a new type of port_binding record called 'gateway'. > > On the chassis where the gateway router resides, this port behaves just > > like the port of type 'patch'. The ovn-controller on that chassis > > populates the "chassis" column for this record as an indication for > > other ovn-controllers of its physical location. Other ovn-controllers > > treat this port as they would treat a VM/Container port on a different > > chassis. > > > > Signed-off-by: Gurucharan Shetty > > The commit mesagee description above is really good. Do you think that > it would be appropriate to include it, or some variant, somewhere in the > documentation as introductory or tutorial material? > Thank you! ovn-architecture may be a place to fit it in. I will try to do that as part of a separate patch. > > > diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml > > index efd2f9a..741228c 100644 > > --- a/ovn/ovn-sb.xml > > +++ b/ovn/ovn-sb.xml > > @@ -1220,7 +1220,12 @@ tcp.flags = RST; > >which > ovn-controller/ovn-controller-vtep in > >turn finds out by monitoring the local hypervisor's Open_vSwitch > >database, which identifies logical ports via the conventions > described > > - in IntegrationGuide.md. > > + in IntegrationGuide.md. (The exceptions are for > > Instead of "of type 'gateway' here"; > > + Port_Binding records of type 'gateway', > I would write "with type of gateway", so that > we are consistent about fonts. > > I made the change above and replaced a mention of 'non-distributed router' to a 'a Gateway router (which is centralized)' and applied it. > > + whose locations are identified by ovn-northd via > > + the options:gateway-chassis column in this table. > > + ovn-controller is still responsible to populate the > > + chassis column.) > > > > Acked-by: Ben Pfaff > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 3/5] ovn-controller: Refactor conntrack zone allocation.
On 2 June 2016 at 13:31, Ben Pfaff wrote: > On Thu, May 19, 2016 at 01:02:32PM -0700, Gurucharan Shetty wrote: > > We currently allocate conntrack zones in binding.c. It fits > > in nicely there because we currently only allocate conntrack > > zones to logical ports and binding.c is where we figure out > > the local ones. > > > > An upcoming commit needs conntrack zone allocation for routers > > in a gateway. For that reason, this commit moves conntrack zone > > allocation code to ovn-controller.c where it would be easily > > accessible for router zone allocation too. > > > > Signed-off-by: Gurucharan Shetty > > I didn't read the change in detail because I assume that most of it is > really just moving code around. > Yes. Thank you, I applied this. > > Acked-by: Ben Pfaff > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 4/5] ovn-controller: Assign conntrack zones for gateway router.
On 2 June 2016 at 14:19, Ben Pfaff wrote:
> On Thu, May 19, 2016 at 01:02:33PM -0700, Gurucharan Shetty wrote:
> > OVS NAT currently cannot do snat and dnat in the same zone.
> > So we need two zones per gateway router.
> >
> > Signed-off-by: Gurucharan Shetty
>
> We're running out of registers quickly, but we're also using a full
> 32-bit register when we only need 16 bits, so there's considerable room
> to economize later if necessary.
>
I agree. I will work on atleast combining the 2 registers being used here
into one.
>
> Please update ovn-architecture(7) to mention the new connection tracking
> zones (the existing one is already mentioned).
>
I will add the following incremental.
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index 13acaf5..553c2e5 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -669,12 +669,22 @@
-conntrack zone field
+conntrack zone field for logical ports
- A field that denotes the connection tracking zone. The value only
- has local significance and is not meaningful between chassis.
- This is initialized to 0 at the beginning of the logical ingress
- pipeline. OVN stores this in Nicira extension register number 5.
+ A field that denotes the connection tracking zone for logical ports.
+ The value only has local significance and is not meaningful between
+ chassis. This is initialized to 0 at the beginning of the logical
+ ingress pipeline. OVN stores this in Nicira extension register
number 5.
+
+
+conntrack zone fields for Gateway router
+
+ Fields that denote the connection tracking zones for Gateway routers.
+ These values only have local significance (only on chassis that have
+ Gateway routers instantiated) and is not meaningful between
+ chassis. OVN stores the zone information for DNATting in Nicira
+ extension register number 3 and zone information for SNATing in
Nicira
+ extension register number 4.
>
> There are a couple of instances of
> +char *dnat = xasprintf(UUID_FMT"_%s",
> +
> UUID_ARGS(&binding->datapath->header_.uuid),
> + "dnat");
> +char *snat = xasprintf(UUID_FMT"_%s",
> +
> UUID_ARGS(&binding->datapath->header_.uuid),
> + "snat");
> or similar. Do you think it would be worth having a helper function (or
> two) so that they are harder to get out-of-sync?
>
How about something like the following?
diff --git a/ovn/controller/ovn-controller.c
b/ovn/controller/ovn-controller.c
index 3b55e6c..356a94b 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -40,6 +40,7 @@
#include "openvswitch/vconn.h"
#include "openvswitch/vlog.h"
#include "ovn/lib/ovn-sb-idl.h"
+#include "ovn/lib/ovn-util.h"
#include "patch.h"
#include "physical.h"
#include "pinctrl.h"
@@ -273,12 +274,8 @@ update_ct_zones(struct sset *lports, struct hmap
*patched_datapaths,
continue;
}
-char *dnat = xasprintf(UUID_FMT"_%s",
-
UUID_ARGS(&pd->port_binding->datapath->header_.uuid),
-"dnat");
-char *snat = xasprintf(UUID_FMT"_%s",
-
UUID_ARGS(&pd->port_binding->datapath->header_.uuid),
- "snat");
+char *dnat = alloc_nat_zone_key(pd->port_binding, "dnat");
+char *snat = alloc_nat_zone_key(pd->port_binding, "snat");
sset_add(&all_users, dnat);
sset_add(&all_users, snat);
free(dnat);
diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index b6e752c..85528e0 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -24,6 +24,7 @@
#include "openvswitch/vlog.h"
#include "ovn-controller.h"
#include "ovn/lib/ovn-sb-idl.h"
+#include "ovn/lib/ovn-util.h"
#include "physical.h"
#include "shash.h"
#include "simap.h"
@@ -368,12 +369,8 @@ physical_run(struct controller_ctx *ctx, enum
mf_field_id mff_ovn_ge
}
int zone_id_dnat, zone_id_snat;
-char *dnat = xasprintf(UUID_FMT"_%s",
-
UUID_ARGS(&binding->datapath->header_.uuid),
- "dnat");
-char *snat = xasprintf(UUID_FMT"_%s",
-
UUID_ARGS(&binding->datapath->header_.uuid),
- "snat");
+char *dnat = alloc_nat_zone_key(binding, "dnat");
+char *snat = alloc_nat_zone_key(binding, "snat");
zone_id_dnat = simap_get(ct_zones, dnat);
if (zone_id_dnat) {
put_load(zone_id_dnat, MFF_LOG_DNAT_ZONE, 0, 32, &ofpacts);
diff --git a/ovn/lib/ovn-util.c b/ovn/lib/ovn-util.c
index abdc247..5a1dcb6 100644
--- a/ovn/lib/ovn-util.c
+++ b/ovn/lib/ovn-util.c
@@ -15,6 +15,7 @@
#include
#include "ovn-util.h"
#include "openvswitch/vlog.h"
+#include "ovn/lib/ovn-sb-idl.h"
VLOG_DEFINE_THIS_MODULE(ovn_util);
@@ -102,3 +103,15 @@ extract_lport_
Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
>
>
>
> Looking at the code, it looks like any IP packet matches the priority-50
> flow. Something like:
> For all IP packets, a priority-50 flow with an action
> ct_dnat;.
>
Agreed. Will fix this as part of the next version.
>
>
> >index 7852d83..3ce88a7 100644
> >--- a/ovn/northd/ovn-northd.c
> >+++ b/ovn/northd/ovn-northd.c
> >@@ -105,12 +105,15 @@ enum ovn_stage {
> > /* Logical router ingress stages. */ \
> > PIPELINE_STAGE(ROUTER, IN, ADMISSION, 0, "lr_in_admission") \
> > PIPELINE_STAGE(ROUTER, IN, IP_INPUT,1, "lr_in_ip_input") \
> >-PIPELINE_STAGE(ROUTER, IN, IP_ROUTING, 2, "lr_in_ip_routing") \
> >-PIPELINE_STAGE(ROUTER, IN, ARP_RESOLVE, 3, "lr_in_arp_resolve") \
> >-PIPELINE_STAGE(ROUTER, IN, ARP_REQUEST, 4, "lr_in_arp_request") \
> >+PIPELINE_STAGE(ROUTER, IN, SNAT,2, "lr_in_snat") \
>
> I find calling this table SNAT misleading, since it is actually reverting
> the destination address.
> How about UNDO_SNAT or UNSNAT?
>
I am okay with UNSNAT. What about DNAT as it is currently doing both unDNAT
and DNAT? Leave it at DNAT?
> You are allowing the key to be a prefix, with mask other than OVS_BE32_MAX.
> This implies that a user can specify multiple overlapping prefixes.
> Conflicts should be resolved by going with the longest matching prefix.
>
> We actually need this behavior for OpenStack. If the source IP address is a
> fixed IP that has a corresponding floating IP, then the source IP address
> should be mapped to the floating IP address rather than the router gateway
> address. We need longest match to win to get this behavior.
>
> So, the priority should be (mask+1).
>
Right. I will get this right in the next version.
>
> >--- a/ovn/ovn-nb.ovsschema
> >+++ b/ovn/ovn-nb.ovsschema
> >@@ -1,7 +1,7 @@
> > {
> > "name": "OVN_Northbound",
> >- "version": "2.1.2",
> >- "cksum": "429668869 5325",
> >+ "version": "2.1.3",
> >+ "cksum": "400575131 5731",
> > "tables": {
> > "Logical_Switch": {
> > "columns": {
> >@@ -78,6 +78,14 @@
> >"max": "unlimited"}},
> > "default_gw": {"type": {"key": "string",
> "min": 0, "max": 1}},
> > "enabled": {"type": {"key": "boolean",
> "min": 0, "max": 1}},
> >+ "dnat" : {
> >+ "type": {"key": {"type":
> "string"},
> >+"value": {"type"
> : "string"},
> >+ "min": 0,
> "max": "unlimited"}},
> >+ "snat" : {
> >+ "type": {"key": {"type":
> "string"},
> >+ "value":
> {"type" : "string"},
> >+"min": 0, "max":
> "unlimited"}},
>
> As mentioned above, in OpenStack, if the source IP address is a fixed IP
> that has a corresponding floating IP, then the source IP address should be
> mapped to the floating IP address rather than the router gateway address.
>
> Separate dnat and snat lists as defined here can be made to work to support
> the OpenStack behavior using this patch, by copying floating IPs into both
> the dnat and snat lists. However this is a little unwieldy.
>
I see your point. But the behavior you mention is a very OpenStack thing.
OVN config being independent of OpenStack specific behavior looks better to
me, Unless we can think up with a general purpose schema.
>
> If we ever move to distributed handling of floating IPs, which I am still
> working on, then the duplication will be difficult to handle for east/west
> flows. It would be easier if one definition could apply to both dnat and
> snat.
> An additional value could indicate if the rule applies to only dnat or
> both.
> Or, perhaps there could just be a single list of nat rules with an
> additional
> value indicating if the rule applies to snat or dnat or both.
>
This needs some thought. Do you strongly feel that this needs to be handled
now, or would you mind sending a patch that proposes your schema after this
schema goes in?
>
> Note also that for distributed handling of floating IPs, we will need MAC
> addresses to go along with the floating IPs. This makes me think it might
> be worth having an indirection to a separate nat table.
>
> Mickey
>
>
> > "options": {
> > "type": {"key": "string",
> > "value":
> "string",
> >diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> >index d239499..508a865 100644
> >--- a/ovn/ovn-nb.xml
> >+++ b/ovn/ovn-nb.xml
> >@@ -631,18 +631,41 @@
> > router has all ingress and egress traffic dropped.
> >
> >
> >+
> >+ A map of externally visible IP address t
Re: [ovs-dev] [PATCH v3 4/5] ovn-controller: Assign conntrack zones for gateway router.
On 3 June 2016 at 08:18, Ben Pfaff wrote: > On Thu, Jun 02, 2016 at 10:22:05PM -0700, Guru Shetty wrote: > > On 2 June 2016 at 14:19, Ben Pfaff wrote: > > > > > On Thu, May 19, 2016 at 01:02:33PM -0700, Gurucharan Shetty wrote: > > > > OVS NAT currently cannot do snat and dnat in the same zone. > > > > So we need two zones per gateway router. > > > > > > > > Signed-off-by: Gurucharan Shetty > > > > > > We're running out of registers quickly, but we're also using a full > > > 32-bit register when we only need 16 bits, so there's considerable room > > > to economize later if necessary. > > > > > I agree. I will work on atleast combining the 2 registers being used here > > into one. > > It might require some new infrastructure, since I think there is some > code around oriented around using a whole MFF_* field instead of a > subfield. If so, I don't think it's essential for this patch. > I will leave this out from this patch. > > > > There are a couple of instances of > > > +char *dnat = xasprintf(UUID_FMT"_%s", > > > + > > > UUID_ARGS(&binding->datapath->header_.uuid), > > > + "dnat"); > > > +char *snat = xasprintf(UUID_FMT"_%s", > > > + > > > UUID_ARGS(&binding->datapath->header_.uuid), > > > + "snat"); > > > or similar. Do you think it would be worth having a helper function > (or > > > two) so that they are harder to get out-of-sync? > > > > > > > How about something like the following? > > Looks good to me, thanks! > Thanks, I applied this. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] FAQ: Explain that the order of actions is significant.
On 3 June 2016 at 09:10, Ben Pfaff wrote: > I've seen users make this error several times. This FAQ will provide a > useful answer to pass along. > > Signed-off-by: Ben Pfaff > Acked-by: Gurucharan Shetty ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
>
>
>> As mentioned above, in OpenStack, if the source IP address is a fixed IP
>> that has a corresponding floating IP, then the source IP address should be
>> mapped to the floating IP address rather than the router gateway address.
>>
>> Separate dnat and snat lists as defined here can be made to work to
>> support
>> the OpenStack behavior using this patch, by copying floating IPs into both
>> the dnat and snat lists. However this is a little unwieldy.
>>
>
> I see your point. But the behavior you mention is a very OpenStack thing.
> OVN config being independent of OpenStack specific behavior looks better to
> me, Unless we can think up with a general purpose schema.
>
>>
>> If we ever move to distributed handling of floating IPs, which I am still
>> working on, then the duplication will be difficult to handle for east/west
>> flows. It would be easier if one definition could apply to both dnat and
>> snat.
>> An additional value could indicate if the rule applies to only dnat or
>> both.
>> Or, perhaps there could just be a single list of nat rules with an
>> additional
>> value indicating if the rule applies to snat or dnat or both.
>>
>
> This needs some thought. Do you strongly feel that this needs to be
> handled now, or would you mind sending a patch that proposes your schema
> after this schema goes in?
>
As an addendum, the current schema does dnat:30.0.0.3=192.168.1.2. I would
like to enhance it to also be able to provide ports. Something like
dnat:30.0.0.3:4443=192.168.1.2:80
So we will need to include the above with the new table that you are
thinking too.
>
>
>
>>
>> Note also that for distributed handling of floating IPs, we will need MAC
>> addresses to go along with the floating IPs. This makes me think it might
>> be worth having an indirection to a separate nat table.
>>
>
>
>> Mickey
>>
>>
>> > "options": {
>> > "type": {"key": "string",
>> > "value":
>> "string",
>> >diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
>> >index d239499..508a865 100644
>> >--- a/ovn/ovn-nb.xml
>> >+++ b/ovn/ovn-nb.xml
>> >@@ -631,18 +631,41 @@
>> > router has all ingress and egress traffic dropped.
>> >
>> >
>> >+
>> >+ A map of externally visible IP address to their corresponding IP
>> >+ addresses in the logical space. The externally visible IP address
>> >+ is DNATed to the IP address in the logical space. DNAT only works
>> >+ on routers that are non-distributed.
>> >+
>> >+
>> >+
>> >+ A map of IP network (e.g 192.168.1.0/24) or an IP address to
>> another
>> >+ IP address. All IP packets with their source IP address that
>> either
>> >+ matches the key or is in the provided network is SNATed
>> >+ into the IP address in the value. SNAT only works on routers
>> that are
>> >+ non-distributed.
>> >+
>> >+
>> >
>> >
>> > Additional options for the logical router.
>> >
>> >
>> >
>> >-If set, indicates that the logical router in question is
>> >-non-distributed and resides in the set chassis. The same
>> >-value is also used by ovn-controller to
>> >-uniquely identify the chassis in the OVN deployment and
>> >-comes from external_ids:system-id in the
>> >-Open_vSwitch table of Open_vSwitch database.
>> >+
>> >+ If set, indicates that the logical router in question is
>> >+ non-distributed and resides in the set chassis. The same
>> >+ value is also used by ovn-controller to
>> >+ uniquely identify the chassis in the OVN deployment and
>> >+ comes from external_ids:system-id in the
>> >+ Open_vSwitch table of Open_vSwitch database.
>> >+
>> >+
>> >+
>> >+ The non-distributed router (also known as Gateway router)
>> >+ can only be connected to a distributed router via a switch
>> >+ if SNAT and DNAT is to be configured in the Gateway router.
>> >+
>> >
>> >
>> >
>> >diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
>> >index 741228c..3a0268f 100644
>> >--- a/ovn/ovn-sb.xml
>> >+++ b/ovn/ovn-sb.xml
>> >@@ -951,6 +951,44 @@
>> >
>> >
>> >
>> >+ct_dnat;
>> >+ct_dnat(IP);
>> >+
>> >+
>> >+ct_dnat sends the packet through the DNAT zone
>> to
>> >+unDNAT any packet that was DNATed in a different direction.
>> >+
>> >+
>> >+ct_dnat(IP) sends the packet
>> through the
>> >+DNAT zone to change the destination IP address of the
>> packet to
>> >+the one provided inside the parenthesis and commits the
>> connection.
>> >+
>> >+
>> >+Both ct_dnat and
>> ct_dnat(IP)
>> >+recirculate the packet in the datapath.
>> >+
>> >+
>> >+
>> >+
Re: [ovs-dev] [PATCH 3/4] system-ovn.at: Add a OVN NAT test using OVN gateway.
On 12 July 2016 at 17:56, Joe Stringer wrote: > On 11 July 2016 at 23:35, Gurucharan Shetty wrote: > > This unit test adds a basic OVN NAT test that tests north-south > > DNAT, south-north SNAT and east-west DNAT and SNAT. It uses network > > namespaces connected to br-int using veth pairs to act as logical > > ports. This test does not cover multi-host scenarios, so there is > > a gap. But userspace OVN tests do multi-host scenarios (without NAT > > testing), so it should still be a decent coverage. > > > > Signed-off-by: Gurucharan Shetty > > Awesome, more users of the kernel tests:) A few comments below. > > > --- > > Please note that there are a couple of unit tests around fragmentation > > (unrelated to OVN) that can cause kernel crashes when you run OVN kernel > > tests. So, if you intend to run these, run it via: > > make check-kmod TESTSUITEFLAGS="-k ovn" > > --- > > tests/automake.mk | 3 +- > > tests/system-kmod-testsuite.at | 1 + > > tests/system-ovn.at| 141 > + > > 3 files changed, 144 insertions(+), 1 deletion(-) > > create mode 100644 tests/system-ovn.at > > > > diff --git a/tests/automake.mk b/tests/automake.mk > > index bdf6828..0a4e9e6 100644 > > --- a/tests/automake.mk > > +++ b/tests/automake.mk > > @@ -106,7 +106,8 @@ SYSTEM_USERSPACE_TESTSUITE_AT = \ > > > > SYSTEM_TESTSUITE_AT = \ > > tests/system-common-macros.at \ > > - tests/system-traffic.at > > + tests/system-traffic.at \ > > + tests/system-ovn.at > > > > TESTSUITE = $(srcdir)/tests/testsuite > > TESTSUITE_PATCH = $(srcdir)/tests/testsuite.patch > > diff --git a/tests/system-kmod-testsuite.at b/tests/ > system-kmod-testsuite.at > > index fc71a48..bdf57c8 100644 > > --- a/tests/system-kmod-testsuite.at > > +++ b/tests/system-kmod-testsuite.at > > @@ -23,3 +23,4 @@ m4_include([tests/system-common-macros.at]) > > m4_include([tests/system-kmod-macros.at]) > > > > m4_include([tests/system-traffic.at]) > > +m4_include([tests/system-ovn.at]) > > > > diff --git a/tests/system-ovn.at b/tests/system-ovn.at > > new file mode 100644 > > index 000..b58a5b7 > > --- /dev/null > > +++ b/tests/system-ovn.at > > @@ -0,0 +1,141 @@ > > +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, NAT]) > > In most of the existing tests, we also put CHECK_CONNTRACK() to ensure > that modules are loaded, and to skip the tests where conntrack is > unsupported (eg, check-system-userspace target). Makes sense. > Currently this patch > doesn't add system-ovn.at to the check-system-userspace target, but > perhaps it should (even if all tests would be skipped currently due to > a lack of NAT support). > I will do that. > > > +AT_KEYWORDS([ovnnat]) > > +ovn_start > > + > > +OVS_TRAFFIC_VSWITCHD_START() > > +ADD_BR([br-int]) > > + > > +# Set external-ids in br-int needed for ovn-controller > > +ovs-vsctl \ > > +-- set Open_vSwitch . external-ids:system-id=hv1 \ > > +-- set Open_vSwitch . > external-ids:ovn-remote=unix:$ovs_base/ovn-sb/ovn-sb.sock \ > > +-- set Open_vSwitch . external-ids:ovn-encap-type=geneve \ > > +-- set Open_vSwitch . external-ids:ovn-encap-ip=169.0.0.1 \ > > +-- set bridge br-int fail-mode=secure > other-config:disable-in-band=true > > + > > +# Start ovn-controller > > +start_daemon ovn-controller > > + > > +# Logical network: > > +# Two LRs - R1 and R2 that are connected to each other via LS "join" > > +# in 20.0.0.0/24 network. R1 has switchess foo (192.168.1.0/24) and > > +# bar (192.168.2.0/24) connected to it. R2 has alice (172.16.1.0/24) > connected > > +# to it. R2 is a gateway router on which we add NAT rules. > I will add a small topology diagram. > > + > > +ovn-nbctl create Logical_Router name=R1 > > +ovn-nbctl create Logical_Router name=R2 options:chassis=hv1 > > + > > +ovn-nbctl ls-add foo > > +ovn-nbctl ls-add bar > > +ovn-nbctl ls-add alice > > +ovn-nbctl ls-add join > > + > > +# Connect foo to R1 > > +ovn-nbctl lrp-add R1 foo 00:00:01:01:02:03 192.168.1.1/24 > > +ovn-nbctl lsp-add foo rp-foo -- set Logical_Switch_Port rp-foo \ > > +type=router options:router-port=foo addresses=\"00:00:01:01:02:03\" > > + > > +# Connect bar to R1 > > +ovn-nbctl lrp-add R1 bar 00:00:01:01:02:04 192.168.2.1/24 > > +ovn-nbctl lsp-add bar rp-bar -- set Logical_Switch_Port rp-bar \ > > +type=router options:router-port=bar addresses=\"00:00:01:01:02:04\" > > + > > +# Connect alice to R2 > > +ovn-nbctl lrp-add R2 alice 00:00:02:01:02:03 172.16.1.1/24 > > +ovn-nbctl lsp-add alice rp-alice -- set Logical_Switch_Port rp-alice \ > > +type=router options:router-port=alice > addresses=\"00:00:02:01:02:03\" > > + > > +# Connect R1 to join > > +ovn-nbctl lrp-add R1 R1_join 00:00:04:01:02:03 20.0.0.1/24 > > +ovn-nbctl lsp-add join r1-join -- set Logical_Switch_Port r1-join \ > > +type=router options:router-port=R1_join > addresses='"00:00:04:01:02:03"' > > + > > +# Connect R2 to join >
Re: [ovs-dev] [PATCH 4/4] system-ovn.at: Add a OVN load-balancing unit test.
On 12 July 2016 at 17:57, Joe Stringer wrote: > On 11 July 2016 at 23:35, Gurucharan Shetty wrote: > > Signed-off-by: Gurucharan Shetty > > --- > > Looks good, thanks. Only comment is if you add this file to > check-system-userspace then it should also get a CHECK_CONNTRACK() at > the start. > I will do that. > > Acked-by: Joe Stringer > Thank you. Since I am sending a v2 for NAT test anyway, I would like to take that opportunity to enhance this test as well in v2 with the following incremental: diff --git a/tests/system-ovn.at b/tests/system-ovn.at index 61aaa76..ff4b4b0 100644 --- a/tests/system-ovn.at +++ b/tests/system-ovn.at @@ -235,10 +235,13 @@ ADD_VETH(bar3, bar3, br-int, "172.16.1.4/24", "f0:00:0f:01:02:05", \ ovn-nbctl lsp-add bar bar3 \ -- lsp-set-addresses bar3 "f0:00:0f:01:02:05 172.16.1.4" -# Config OVN load-balancer. +# Config OVN load-balancer with a VIP. uuid=`ovn-nbctl create load_balancer vips:30.0.0.1="172.16.1.2,172.16.1.3,172.16.1.4"` ovn-nbctl set logical_switch foo load_balancer=$uuid +# Config OVN load-balancer with another VIP (this time with ports). +ovn-nbctl set load_balancer $uuid vips:'"30.0.0.2:8000"'='"172.16.1.2:80, 172.16.1.3:80,172.16.1.4:80"' + # Wait for ovn-controller to catch up. sleep 2 @@ -260,6 +263,19 @@ tcp,orig=(src=192.168.1.2,dst=30.0.0.1,sport=,dport=),reply=(s tcp,orig=(src=192.168.1.2,dst=30.0.0.1,sport=,dport=),reply=(src=172.16.1.4,dst=192.168.1.2 ]) +dnl Test load-balancing that includes L4 ports in NAT. +for i in 1 2 3 4 5 6 7 8 9 10 11 12; do +echo Request $i +NS_CHECK_EXEC([foo1], [wget 30.0.0.2:8000 -t 5 -T 1 --retry-connrefused -v -o wget$i.log]) +done + +dnl Each server should have at least one connection. +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(30.0.0.2)], [0], [dnl +tcp,orig=(src=192.168.1.2,dst=30.0.0.2,sport=,dport=),reply=(src=172.16.1.2,dst=192.168.1.2 +tcp,orig=(src=192.168.1.2,dst=30.0.0.2,sport=,dport=),reply=(src=172.16.1.3,dst=192.168.1.2 +tcp,orig=(src=192.168.1.2,dst=30.0.0.2,sport=,dport=),reply=(src=172.16.1.4,dst=192.168.1.2 +]) + ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Use ovs_be32 for an IP address in find_lrp_member_ip().
On 13 July 2016 at 13:02, Ben Pfaff wrote:
> Fixes a number of warnings from "sparse".
>
> Fixes: 4685e523695c ("ovn: Support multiple addresses on a single logical
> router port.")
> Signed-off-by: Ben Pfaff
>
Acked-by: Gurucharan Shetty
> ---
> ovn/northd/ovn-northd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index b262e86..eacae7c 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2037,7 +2037,7 @@ lrport_is_enabled(const struct
> nbrec_logical_router_port *lrport)
> static const char *
> find_lrp_member_ip(const struct ovn_port *op, const char *ip_s)
> {
> -uint32_t ip;
> +ovs_be32 ip;
>
> if (!ip_parse(ip_s, &ip)) {
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
> --
> 2.1.3
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V6 12/17] python tests: Ported Python daemon to Windows
On 13 July 2016 at 07:49, Alin Serdean wrote: > > -Mesaj original- > > De la: Paul Boca > > Trimis: Wednesday, July 13, 2016 11:24 AM > > Către: Alin Serdean ; > > dev@openvswitch.org > > Subiect: RE: [ovs-dev] [PATCH V6 12/17] python tests: Ported Python > > daemon to Windows > > > > Hi Alin, > > > > It was easier for me to call Windows APIs from python, that mimics > > detach_process, and to be in a better control on what's happening, than > > creating a *DLL and loading it in order to call this function. > > *On Windows the LIB file cannot be loaded as-is; a DLL with entry point > > needs to be created, allowing the ntdll loader to resolve the imported > > functions. > [Alin Gabriel Serdean: ] I understand the concern but we can deal with > that pretty easily from the build system. > I understand the reasoning behind it, but in my opinion it seems we are > duplicating the effort and in case of problems it will mean another codebase > to maintain. > Adding Ben and Guru to the thread extra opinions are always welcomed :). > I think so far we have tried to keep Python code independent of OVS C libraries. My opinion is that we keep the problem space limited with this patch series ( and if there is time on anyone's hand, try and work on what Alin is suggesting to see whether it fits well with all the linux packaging and build system variations.) So far, python daemonization code hasn't seen any bugs for a few years on Linux, so I don't think there will be a lot of maintenance burden. The windows ones probably will start with some bugs.. > > > > I don't say it isn't doable, but this seemed to be the right solution > for this. > > Also, creating a DLL loaded by python would add a dependency between > > python and C components. > > > > Regarding the *unix side, maybe a Linux guy can add his opinion about > this. > > > > Thanks, > > Paul > > > > > -Original Message- > > > From: Alin Serdean > > > Sent: Tuesday, July 12, 2016 10:54 PM > > > To: Paul Boca; dev@openvswitch.org > > > Subject: RE: [ovs-dev] [PATCH V6 12/17] python tests: Ported Python > > > daemon to Windows > > > > > > I am wondering if it is better if we could just import the shared > > > library and call the detach function > > > (https://github.com/openvswitch/ovs/blob/master/lib/daemon- > > > windows.c#L342) instead of duplicating the effort. > > > > > > I wonder if the same could be applied un the *unix side as well. > > > > > > Thanks, > > > Alin. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] tests: daemon specific tests
On 12 July 2016 at 08:36, Alin Serdean wrote: > Testing out the named pipe implementation revealed a problem in > "daemon --detach startup errors". If the daemon actually started nobody > is stopping it. > In the case of test failure kill the daemon. > > Signed-off-by: Alin Gabriel Serdean > Thank you, applied! > --- > tests/daemon.at | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/daemon.at b/tests/daemon.at > index 8f88987..cf95cde 100644 > --- a/tests/daemon.at > +++ b/tests/daemon.at > @@ -153,7 +153,8 @@ AT_CLEANUP > AT_SETUP([daemon --detach startup errors]) > AT_CAPTURE_FILE([pid]) > OVSDB_INIT([db]) > -AT_CHECK([ovsdb-server --detach --no-chdir --pidfile="`pwd`"/pid > --unixctl="`pwd`"/nonexistent/unixctl db], [1], [], [stderr]) > +AT_CHECK([ovsdb-server --detach --no-chdir --pidfile="`pwd`"/pid > --unixctl="`pwd`"/nonexistent/unixctl db], [1], [], [stderr], > + [kill `cat pid`]) > AT_CHECK([grep 'ovsdb-server: could not initialize control socket' > stderr], >[0], [ignore], []) > AT_CHECK([test ! -s pid]) > -- > 1.9.5.msysgit.0 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock PID file
On 13 July 2016 at 10:35, Paul Boca wrote:
> If the PID file isn't locked then appctl.py detects it as stale and
> bails out without doing anything. Because of this lots of Python tests
> fail.
> Also this protects the PID file from being overwritten.
>
> I used only shared lock, in order to be compatible with Python tests,
> which try to acquire the lock exclusively. On Windows if the exclusive lock
> is used, than the read access is denied too for other instances of this
> file.
>
> Signed-off-by: Paul-Daniel Boca
> ---
> V2: No changes
> V3: No changes
> V4: No changes
> V5: Removed this patch from Python series.
> Removed unused constants and defined 0x as constant.
> Updated commit text.
> V6: flock returns now the error of GetLastError.
> Also it uses fd parameter instead of the global filep_pidfile.
> Removed unused local variable and unnecessary error message.
> V7: Keep a shared lock on PID file after the fopen.
> This ensures us that at most one process can write the same PID file.
> fopen with 'w' on Windows creates a file with FILE_SHARED_WRITE
> flag, so anyone with write access on file can write it.
> ---
> lib/daemon-windows.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
> index 8cf0fea..e6e1452 100644
> --- a/lib/daemon-windows.c
> +++ b/lib/daemon-windows.c
> @@ -18,6 +18,7 @@
> #include "daemon.h"
> #include "daemon-private.h"
> #include
> +#include
> #include
> #include "dirs.h"
> #include "ovs-thread.h"
> @@ -26,6 +27,14 @@
>
> VLOG_DEFINE_THIS_MODULE(daemon_windows);
>
> +/* Constants for flock function */
> +#defineLOCK_SH 0x0 /* Shared lock. */
> +#defineLOCK_EX LOCKFILE_EXCLUSIVE_LOCK /* Exclusive lock. */
>
When reading code, "LOCK_SH" does not tell me much. Can you please expand
it to LOCK_SHARED. You can get rid of LOCK_EX and instead use the real
value.
> +#defineLOCK_UN 0x8000 /* Unlock. Custom
> value. */
> +
> +/* High-order 32 bits of byte range to lock */
>
+#define LOCK_MAX_SIZE 0x
>
Any reason for this specific value? Anyone reading the code will start
wondering why this is important. If we don't care about it, why not just do
the same as the other invocation of LockFileEx does in the code base
(lib/lockfile.c). i.e. just set 1 in nNumberOfBytesToLockLow.
> +
> static bool service_create; /* Was --service specified? */
> static bool service_started; /* Have we dispatched service to
> start? */
>
> @@ -404,9 +413,35 @@ detach_process(int argc, char *argv[])
> }
>
> static void
> +flock(FILE* fd, int operation)
> +{
> +HANDLE hFile;
> +OVERLAPPED ov = {0};
> +
> +hFile = (HANDLE)_get_osfhandle(fileno(fd));
> +if (hFile == INVALID_HANDLE_VALUE) {
> +VLOG_FATAL("Invalid handle value");
>
The above message is not very helpful when someone sees it on the console.
Please have a look at other VLOG_FATAL messages in this file to see what
kind of messages are more helpful.
> +}
> +
> +if (operation & LOCK_UN) {
> +if (UnlockFileEx(hFile, 0, 0, LOCK_MAX_SIZE, &ov) == 0) {
> +VLOG_FATAL("Failed to unlock PID file (%s).",
> + ovs_lasterror_to_string());
> +}
> +} else {
> +if (LockFileEx(hFile, operation, 0, 0, LOCK_MAX_SIZE, &ov) ==
> FALSE) {
> +VLOG_FATAL("Failed to lock PID file (%s).",
> + ovs_lasterror_to_string());
> +}
> +}
> +}
> +
> +static void
> unlink_pidfile(void)
> {
> if (filep_pidfile) {
> +/* Remove the shared lock on file */
> +flock(filep_pidfile, LOCK_UN);
> fclose(filep_pidfile);
> }
> if (pidfile) {
> @@ -437,6 +472,8 @@ make_pidfile(void)
> VLOG_FATAL("failed to open %s (%s)", pidfile,
> ovs_strerror(errno));
> }
>
> +flock(filep_pidfile, LOCK_EX);
>
Won't the above call block indefinitely if the lock has already been taken
by someone else? We don't want the behavior when someone starts a daemon
and it simply hang there.
> +
> fatal_signal_add_hook(unlink_pidfile, NULL, NULL, true);
>
> fprintf(filep_pidfile, "%d\n", _getpid());
> @@ -444,6 +481,10 @@ make_pidfile(void)
> VLOG_FATAL("Failed to write into the pidfile %s", pidfile);
> }
>
> +flock(filep_pidfile, LOCK_SH);
> +/* This will remove the exclusive lock. The shared lock will remain */
> +flock(filep_pidfile, LOCK_UN);
>
I unsuccessfully tried to read MSDN documentation for the above behavior.
Can you please point me to the documentation which states that unlocking
once will move the lock from exclusive to shared?
> +
> /* Don't close the pidfile till the process exits. */
> }
>
> --
> 2.7.2.windows.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswit
Re: [ovs-dev] [PATCH v2 1/3] Windows: Local named pipe implementation
On 12 July 2016 at 20:32, Alin Serdean
wrote:
> Currently in the case of command line arguments punix/unix, on Windows
> we create a file, write a TCP port number to connect. This is a security
> concern.
>
> This patch adds support for the command line arguments punix/unix trying
> to mimic AF_UNIX behind a local named pipe.
>
> Signed-off-by: Alin Gabriel Serdean
>
If I apply this patch, then the compilation fails on Linux. Also, can you
please carefully look at commit cb54a8c57646a1549dcff0c2ad4c2d8b46bc2880
and commit e3f512b07c11de6b297050bb969fd0d8a07f9357 which added these
features in the first place. Those commits add a lot more than what this
series removes.
> ---
> v2: Address comments, fix leaks.
> ---
> lib/stream-windows.c | 587
> +++
> 1 file changed, 587 insertions(+)
> create mode 100644 lib/stream-windows.c
>
> diff --git a/lib/stream-windows.c b/lib/stream-windows.c
> new file mode 100644
> index 000..97e6f02
> --- /dev/null
> +++ b/lib/stream-windows.c
> @@ -0,0 +1,587 @@
> +/*
> + * Copyright (c) 2016 Cloudbase Solutions Srl
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "packets.h"
> +#include "poll-loop.h"
> +#include "socket-util.h"
> +#include "dirs.h"
> +#include "util.h"
> +#include "stream-provider.h"
> +#include "openvswitch/vlog.h"
> +
> +VLOG_DEFINE_THIS_MODULE(stream_windows);
> +
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 25);
> +
> +static void maybe_unlink_and_free(char *path);
> +
> +/* Buffer size suggested at the creation of the named pipe for reading and
> + * and writing operations */
> +#define BUFSIZE 65000
> +
> +/* Default local prefix of a named pipe */
> +#define LOCAL_PREFIX ".\\pipe\\"
> +
> +/* This function has the purpose to remove all the slashes received in s
> */
> +char*
> +remove_slashes(char *s) {
> +char *p1, *p2;
> +p1 = p2 = s;
> +
> +while (*p1) {
> +if ((*p1) == '\\' || (*p1) == '/') {
> +p1++;
> +} else {
> +*p2 = *p1;
> +p2++;
> +p1++;
> +}
> +}
> +*p2 = '\0';
> +return s;
> +}
> +
> +/* Active named pipe descriptor stream. */
> +struct windows_stream
> +{
> +struct stream stream;
> +HANDLE fd;
> +/* Overlapped operations used for reading/writing */
> +OVERLAPPED read;
> +OVERLAPPED write;
> +/* Flag to check if a reading/writing is pending*/
> +bool read_pending;
> +bool write_pending;
> +/* Flag to check if fd is a server HANDLE. In the case of a server
> handle
> + * we have to issue a disconnect before closing the actual handle */
> +bool server;
> +bool retry_connect;
> +char *pipe_path;
> +};
> +
> +static struct windows_stream *
> +stream_windows_cast(struct stream *stream)
> +{
> +stream_assert_class(stream, &windows_stream_class);
> +return CONTAINER_OF(stream, struct windows_stream, stream);
> +}
> +
> +HANDLE
> +create_snpipe(char *path) {
> +return CreateFile(path, GENERIC_READ | GENERIC_WRITE, 0, NULL,
> + OPEN_EXISTING,
> + FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED |
> + FILE_FLAG_NO_BUFFERING,
> + NULL);
> +}
> +
> +/* Active named pipe open */
> +static int
> +windows_open(const char *name, char *suffix, struct stream **streamp,
> + uint8_t dscp OVS_UNUSED)
> +{
> +char *connect_path;
> +HANDLE npipe;
> +DWORD mode = PIPE_READMODE_BYTE;
> +char* path;
> +FILE* file;
> +bool retry = false;
> +/* If the path does not contain a ':', assume it is relative to
> + * OVS_RUNDIR. */
> +if (!strchr(suffix, ':')) {
> +path = xasprintf("%s/%s", ovs_rundir(), suffix);
> +} else {
> +path = xstrdup(suffix);
> +}
> +
> +/* In the punix/unix argument the assumption is that there is a file
> + * created in the path (name) */
> +file = fopen(path, "r");
> +if (!file) {
> +free(path);
> +VLOG_DBG_RL(&rl, "%s: could not open %s (%s)", name, suffix,
> +ovs_strerror(errno));
> +return ENOENT;
> +} else {
> +fclose(file);
> +}
> +
> +/* Valid pipe names do not
Re: [ovs-dev] [PATCH v2 1/3] Windows: Local named pipe implementation
On 14 July 2016 at 19:00, Alin Serdean wrote: > Thanks for the review! Comments inlined. > > > > Thanks, > > Alin. > > > > *De la:* Guru Shetty [mailto:g...@ovn.org] > *Trimis:* Friday, July 15, 2016 1:27 AM > *Către:* Alin Serdean > *Cc:* dev@openvswitch.org > *Subiect:* Re: [ovs-dev] [PATCH v2 1/3] Windows: Local named pipe > implementation > > > > > > > > On 12 July 2016 at 20:32, Alin Serdean > wrote: > > Currently in the case of command line arguments punix/unix, on Windows > we create a file, write a TCP port number to connect. This is a security > concern. > > This patch adds support for the command line arguments punix/unix trying > to mimic AF_UNIX behind a local named pipe. > > Signed-off-by: Alin Gabriel Serdean > > > > If I apply this patch, then the compilation fails on Linux. Also, can you > please carefully look at commit cb54a8c57646a1549dcff0c2ad4c2d8b46bc2880 > and commit e3f512b07c11de6b297050bb969fd0d8a07f9357 which added these > features in the first place. Those commits add a lot more than what this > series removes. > > > > [Alin Gabriel Serdean: ] Sorry about the compilation error I will squash > the first two commits. Unless I am missing should I just update the > comments and man pages as well, or there is a part of the code I missed? > There were a couple of function declarations and man page changes missed. I just wanted you take a look at other changes to make sure that they are alright now too. > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock PID file
On 14 July 2016 at 15:52, Alin Serdean
wrote:
> > > +flock(filep_pidfile, LOCK_EX);
> > >
> > Won't the above call block indefinitely if the lock has already been
> taken by
> > someone else? We don't want the behavior when someone starts a daemon
> > and it simply hang there.
> [Alin Gabriel Serdean: ] Hard to say from the MSDN documentation we could
> add "| LOCKFILE_FAIL_IMMEDIATELY" when calling it just to be sure.
> >
> >
> >
> > > +
> > > fatal_signal_add_hook(unlink_pidfile, NULL, NULL, true);
> > >
> > > fprintf(filep_pidfile, "%d\n", _getpid()); @@ -444,6 +481,10 @@
> > > make_pidfile(void)
> > > VLOG_FATAL("Failed to write into the pidfile %s", pidfile);
> > > }
> > >
> > > +flock(filep_pidfile, LOCK_SH);
> > > +/* This will remove the exclusive lock. The shared lock will
> remain */
> > > +flock(filep_pidfile, LOCK_UN);
> > >
> > I unsuccessfully tried to read MSDN documentation for the above behavior.
> > Can you please point me to the documentation which states that unlocking
> > once will move the lock from exclusive to shared?
> [Alin Gabriel Serdean: ]
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365203(v=vs.85).aspx
> The part:
> "If the same range is locked with an exclusive and a shared lock, two
> unlock operations are necessary to unlock the region; the first unlock
> operation unlocks the exclusive lock, the second unlock operation unlocks
> the shared lock."
>
I see. Thank you. (I am blind!). I wonder whether we actually need the
exclusive lock then? If what we need is just shared lock, why not just take
it in the beginning? Would it have been possible to open the file in write
mode if someone had taken the exclusive lock in the first place?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock PID file
On 14 July 2016 at 19:25, Alin Serdean wrote: > > [Alin Gabriel Serdean: ] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365203(v=vs.85).aspx > The part: > "If the same range is locked with an exclusive and a shared lock, two > unlock operations are necessary to unlock the region; the first unlock > operation unlocks the exclusive lock, the second unlock operation unlocks > the shared lock." > > > > I see. Thank you. (I am blind!). I wonder whether we actually need the > exclusive lock then? If what we need is just shared lock, why not just take > it in the beginning? Would it have been possible to open the file in write > mode if someone had taken the exclusive lock in the first place? > > > > [Alin Gabriel Serdean: ] No worries the MS documentation is not that easy > to follow or precise in certain scenarios J. > > The problem is “Locking a portion of a file for *shared access denies* *all > processes* *write access* to the specified region of the file, including > the process that first locks the region. All processes can read the locked > region.” > > “Locking a portion of a file for *exclusive access* * denies all other > processes both read and write* access to the specified region of the > file. Locking a region that goes beyond the current end-of-file position is > not an error.” > > I agree it doesn’t make any sense why a shared lock would block the owner > but probably they had reasons to implement it that way. > What I was trying to say was, we open the file in write mode. It wouldn't have been successful if someone else had taken a lock (exclusive or shared). Am I correct? If so, why take exclusive lock again to write? Just write the pid and then take shared lock. Would that cause problems? (I must be missing some subtlety here.) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 1/3] Windows: Local named pipe implementation
On 14 July 2016 at 19:57, Alin Serdean wrote: > On 12 July 2016 at 20:32, Alin Serdean > wrote: > > Currently in the case of command line arguments punix/unix, on Windows > we create a file, write a TCP port number to connect. This is a security > concern. > > This patch adds support for the command line arguments punix/unix trying > to mimic AF_UNIX behind a local named pipe. > > Signed-off-by: Alin Gabriel Serdean > > > > If I apply this patch, then the compilation fails on Linux. Also, can you > please carefully look at commit cb54a8c57646a1549dcff0c2ad4c2d8b46bc2880 > and commit e3f512b07c11de6b297050bb969fd0d8a07f9357 which added these > features in the first place. Those commits add a lot more than what this > series removes. > > > > [Alin Gabriel Serdean: ] Sorry about the compilation error I will squash > the first two commits. Unless I am missing should I just update the > comments and man pages as well, or there is a part of the code I missed? > > There were a couple of function declarations and man page changes missed. > I just wanted you take a look at other changes to make sure that they are > alright now too. > > > > [Alin Gabriel Serdean: ] I think I’m blind! I still can’t see the function > declarations I missed. Can you please point them out? > You are fine. I think you missed https://github.com/openvswitch/ovs/blob/master/lib/stream-provider.h#L195 (not function declarations) > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2 1/3] Windows: Local named pipe implementation
On 14 July 2016 at 20:42, Guru Shetty wrote: > > > On 14 July 2016 at 19:57, Alin Serdean > wrote: > >> On 12 July 2016 at 20:32, Alin Serdean >> wrote: >> >> Currently in the case of command line arguments punix/unix, on Windows >> we create a file, write a TCP port number to connect. This is a security >> concern. >> >> This patch adds support for the command line arguments punix/unix trying >> to mimic AF_UNIX behind a local named pipe. >> >> Signed-off-by: Alin Gabriel Serdean >> >> >> >> If I apply this patch, then the compilation fails on Linux. Also, can you >> please carefully look at commit cb54a8c57646a1549dcff0c2ad4c2d8b46bc2880 >> and commit e3f512b07c11de6b297050bb969fd0d8a07f9357 which added these >> features in the first place. Those commits add a lot more than what this >> series removes. >> >> >> >> [Alin Gabriel Serdean: ] Sorry about the compilation error I will squash >> the first two commits. Unless I am missing should I just update the >> comments and man pages as well, or there is a part of the code I missed? >> >> There were a couple of function declarations and man page changes missed. >> I just wanted you take a look at other changes to make sure that they are >> alright now too. >> >> >> >> [Alin Gabriel Serdean: ] I think I’m blind! I still can’t see the >> function declarations I missed. Can you please point them out? >> > You are fine. I think you missed > https://github.com/openvswitch/ovs/blob/master/lib/stream-provider.h#L195 > (not function declarations) > Never mind. I think you still need them. > > >> >> > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock PID file
On 14 July 2016 at 20:03, Alin Serdean wrote: > > > De la: Guru Shetty [mailto:g...@ovn.org] > Trimis: Friday, July 15, 2016 5:49 AM > Către: Alin Serdean > Cc: Paul Boca ; dev@openvswitch.org > Subiect: Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock > PID file > > > > On 14 July 2016 at 19:25, Alin Serdean <mailto:aserd...@cloudbasesolutions.com>> wrote: > > [Alin Gabriel Serdean: ] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365203(v=vs.85).aspx > The part: > "If the same range is locked with an exclusive and a shared lock, two > unlock operations are necessary to unlock the region; the first unlock > operation unlocks the exclusive lock, the second unlock operation unlocks > the shared lock." > > I see. Thank you. (I am blind!). I wonder whether we actually need the > exclusive lock then? If what we need is just shared lock, why not just take > it in the beginning? Would it have been possible to open the file in write > mode if someone had taken the exclusive lock in the first place? > > [Alin Gabriel Serdean: ] No worries the MS documentation is not that easy > to follow or precise in certain scenarios ☺. > The problem is “Locking a portion of a file for shared access denies all > processes write access to the specified region of the file, including the > process that first locks the region. All processes can read the locked > region.” > “Locking a portion of a file for exclusive access denies all other > processes both read and write access to the specified region of the file. > Locking a region that goes beyond the current end-of-file position is not > an error.” > I agree it doesn’t make any sense why a shared lock would block the owner > but probably they had reasons to implement it that way. > > What I was trying to say was, we open the file in write mode. It wouldn't > have been successful if someone else had taken a lock (exclusive or > shared). Am I correct? If so, why take exclusive lock again to write? Just > write the pid and then take shared lock. Would that cause problems? (I must > be missing some subtlety here.) > [Alin Gabriel Serdean: ] If we just open the file in write mode and write > the pid and then take the shared lock, someone else could write in the file > between the moment we opened it and gained the shared lock. > > Thanks, I understand it now. (I had to write a small program to get it.) I did see though that a daemon will hang if it tries to take a exclusive lock without LOCKFILE_FAIL_IMMEDIATELY. ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock PID file
> On Jul 14, 2016, at 11:19 PM, Paul Boca wrote: > > Hi Guru! > > I will re-spin the patch with LOCKFILE_FAIL_IMMEDIATELY flag set to avoid > the hang of other daemons. There were a few other comments too. Please have a look at them too. > > Thanks, > Paul > >> -Original Message- >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Guru Shetty >> Sent: Friday, July 15, 2016 6:58 AM >> To: Alin Serdean >> Cc: dev@openvswitch.org >> Subject: Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock >> PID file >> >> On 14 July 2016 at 20:03, Alin Serdean >> wrote: >> >>> >>> >>> De la: Guru Shetty [mailto:g...@ovn.org] >>> Trimis: Friday, July 15, 2016 5:49 AM >>> Către: Alin Serdean >>> Cc: Paul Boca ; dev@openvswitch.org >>> Subiect: Re: [ovs-dev] [PATCH V7] windows: Added lockf function and lock >>> PID file >>> >>> >>> >>> On 14 July 2016 at 19:25, Alin Serdean >> <mailto:aserd...@cloudbasesolutions.com>> wrote: >>> >>> [Alin Gabriel Serdean: ] >>> https://msdn.microsoft.com/en- >> us/library/windows/desktop/aa365203(v=vs.85).aspx >>> The part: >>> "If the same range is locked with an exclusive and a shared lock, two >>> unlock operations are necessary to unlock the region; the first unlock >>> operation unlocks the exclusive lock, the second unlock operation unlocks >>> the shared lock." >>> >>> I see. Thank you. (I am blind!). I wonder whether we actually need the >>> exclusive lock then? If what we need is just shared lock, why not just take >>> it in the beginning? Would it have been possible to open the file in write >>> mode if someone had taken the exclusive lock in the first place? >>> >>> [Alin Gabriel Serdean: ] No worries the MS documentation is not that easy >>> to follow or precise in certain scenarios ☺. >>> The problem is “Locking a portion of a file for shared access denies all >>> processes write access to the specified region of the file, including the >>> process that first locks the region. All processes can read the locked >>> region.” >>> “Locking a portion of a file for exclusive access denies all other >>> processes both read and write access to the specified region of the file. >>> Locking a region that goes beyond the current end-of-file position is not >>> an error.” >>> I agree it doesn’t make any sense why a shared lock would block the owner >>> but probably they had reasons to implement it that way. >>> >>> What I was trying to say was, we open the file in write mode. It wouldn't >>> have been successful if someone else had taken a lock (exclusive or >>> shared). Am I correct? If so, why take exclusive lock again to write? Just >>> write the pid and then take shared lock. Would that cause problems? (I >> must >>> be missing some subtlety here.) >>> [Alin Gabriel Serdean: ] If we just open the file in write mode and write >>> the pid and then take the shared lock, someone else could write in the file >>> between the moment we opened it and gained the shared lock. >>> >>> Thanks, I understand it now. (I had to write a small program to get it.) I >> did see though that a daemon will hang if it tries to take a exclusive lock >> without LOCKFILE_FAIL_IMMEDIATELY. >> >> >> ___ >>> dev mailing list >>> dev@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/dev >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH, v2] ovn: Allow SNAT traffic destined to router ip
On 18 July 2016 at 05:22, Chandra S Vejendla wrote:
> When router ip is used as SNAT IP, traffic destined to router
> ip should not be dropped
>
Thank you for the fix. You will need to add your Signed-off-by. Can you
also add a "Fixes:" tag in commit message. Since this is a regression, I
wonder whether we should add a simple unit test that looks at the generated
logical flows to make sure that there is no "drop" for the SNAT IP address.
I also wonder, whether we should disable ICMP response to these SNAT IP
addresses from the router? Don't you see issues with that? I presume you
will have a situation where the ICMP response flow added by the router will
override the SNAT flow and the router will respond to ICMP instead of the
logical port.
> ---
> ovn/northd/ovn-northd.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 7ce509d..78c3a7d 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2399,11 +2399,16 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
> ds_put_cstr(&match, "ip4.dst == {");
> bool has_drop_ips = false;
> for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> +bool nat_ip_is_router_ip = false;
> for (int j = 0; j < n_nat_ips; j++) {
> if (op->lrp_networks.ipv4_addrs[i].addr == nat_ips[j]) {
> -continue;
> +nat_ip_is_router_ip = true;
> +break;
> }
> }
> +if (nat_ip_is_router_ip) {
> +continue;
> +}
> ds_put_format(&match, "%s, ",
>op->lrp_networks.ipv4_addrs[i].addr_s);
> has_drop_ips = true;
> --
> 2.6.1
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn.at: A "peer" is only for interconnected routers.
On 18 July 2016 at 10:35, Ben Pfaff wrote:
> On Mon, Jul 18, 2016 at 12:00:30AM -0700, Gurucharan Shetty wrote:
> > We should not use "peer" while connecting a router to a switch.
> > (Doing so, will cause ovn-northd to constantly create and destroy
> > port_binding records which causes CPU utilization of ovn-controller to
> > spike up.)
> >
> > Fixes: 31114af758c7e6 ("ovn-nbctl: Update logical router port commands.")
> > Signed-off-by: Gurucharan Shetty
>
> I updated the commit message to correctly say:
We should not use "peer" while connecting a router to a switch.
(Doing so, will cause ovn-northd to constantly create and destroy
logical_flow records which causes CPU utilization of ovn-controller to
spike up.)
> This seems like a bug in ovn-northd. Did you investigate why it
> happens?
>
I think I know ( I haven't put a debugger to confirm). We create a logical
flow incorrectly and add it via ovn_lflow_add() with a switch's datapath
and a router's pipeline stage (S_ROUTER_IN_ARP_RESOLVE) here (This is when
we incorrectly set router's peer as a switch):
https://github.com/openvswitch/ovs/blob/master/ovn/northd/ovn-northd.c#L2614
In build_lflows, we go through each record of SB database's logical flows
and then do a ovn_lflow_find() which returns a negative if the data was
wrongly inserted, so it goes ahead and deleted the record from SB database.
In the next block, it will insert it back into the SB database. I will send
one additional fix. But, I think we should also assert in ovn_lflow_add if
we add a datapath with a different datapath's pipeline - not sure what is a
nice way to do that.
>
> Acked-by: Ben Pfaff
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-northd: Warn when the peer of a router port is a switch port.
On 18 July 2016 at 11:44, Ryan Moats wrote: > "dev" wrote on 07/18/2016 03:39:56 AM: > > > From: Gurucharan Shetty > > To: dev@openvswitch.org > > Date: 07/18/2016 01:39 PM > > Subject: [ovs-dev] [PATCH] ovn-northd: Warn when the peer of a > > router port is a switch port. > > Sent by: "dev" > > > > Signed-off-by: Gurucharan Shetty > > --- > > Is just printing a warning enough? > I mean, shouldn't we try to *stop* this from happening? > Stop a admin from creating a wrong config? I guess, that is what the warning does. There is also a "continue", which does "stop" the config from going through to SB database. > > Ryan > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn.at: A "peer" is only for interconnected routers.
On 18 July 2016 at 13:11, Ben Pfaff wrote:
> On Mon, Jul 18, 2016 at 11:34:54AM -0700, Guru Shetty wrote:
> > On 18 July 2016 at 10:35, Ben Pfaff wrote:
> >
> > > On Mon, Jul 18, 2016 at 12:00:30AM -0700, Gurucharan Shetty wrote:
> > > > We should not use "peer" while connecting a router to a switch.
> > > > (Doing so, will cause ovn-northd to constantly create and destroy
> > > > port_binding records which causes CPU utilization of ovn-controller
> to
> > > > spike up.)
> > > >
> > > > Fixes: 31114af758c7e6 ("ovn-nbctl: Update logical router port
> commands.")
> > > > Signed-off-by: Gurucharan Shetty
> > >
> > > I updated the commit message to correctly say:
> > We should not use "peer" while connecting a router to a switch.
> > (Doing so, will cause ovn-northd to constantly create and destroy
> > logical_flow records which causes CPU utilization of ovn-controller
> to
> > spike up.)
> >
> >
> > > This seems like a bug in ovn-northd. Did you investigate why it
> > > happens?
> > >
> > I think I know ( I haven't put a debugger to confirm). We create a
> logical
> > flow incorrectly and add it via ovn_lflow_add() with a switch's datapath
> > and a router's pipeline stage (S_ROUTER_IN_ARP_RESOLVE) here (This is
> when
> > we incorrectly set router's peer as a switch):
> >
> https://github.com/openvswitch/ovs/blob/master/ovn/northd/ovn-northd.c#L2614
>
> Oh, good spotting, can we fix it something like this?
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 7ce509d..97e3271 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -715,7 +736,10 @@ join_logical_ports(struct northd_context *ctx,
> sizeof *op->od->router_ports * (op->od->n_router_ports +
> 1));
> op->od->router_ports[op->od->n_router_ports++] = op;
> } else if (op->nbr && op->nbr->peer) {
> -op->peer = ovn_port_find(ports, op->nbr->peer);
> +struct ovn_port *peer = ovn_port_find(ports, op->nbr->peer);
> +if (peer && peer->nbr) {
> +op->peer = peer;
> +}
> }
> }
> }
>
Since the original patch in question fixed faulty tests independently, I
had applied it as soon as I got your Ack. The above code snippet is good
underlying fix. So you have my:
Acked-by: Gurucharan Shetty
>
> > In build_lflows, we go through each record of SB database's logical flows
> > and then do a ovn_lflow_find() which returns a negative if the data was
> > wrongly inserted, so it goes ahead and deleted the record from SB
> database.
> >
> > In the next block, it will insert it back into the SB database. I will
> send
> > one additional fix. But, I think we should also assert in ovn_lflow_add
> if
> > we add a datapath with a different datapath's pipeline - not sure what
> is a
> > nice way to do that.
>
> Here's an idea (it compiles but I didn't test it):
>
Nice. I tested the below and the tests asserted with a wrong configuration.
You have my:
Acked-by: Gurucharan Shetty
I think the below patch which Ryan Acked is probably still relevant to
apply?
https://patchwork.ozlabs.org/patch/649723/
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 7ce509d..905f6a7 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -175,6 +175,20 @@ ovn_stage_to_str(enum ovn_stage stage)
> default: return "";
> }
> }
> +
> +/* Returns the type of the datapath to which a flow with the given
> 'stage' may
> + * be added. */
> +static enum ovn_datapath_type
> +ovn_stage_to_datapath_type(enum ovn_stage stage)
> +{
> +switch (stage) {
> +#define PIPELINE_STAGE(DP_TYPE, PIPELINE, STAGE, TABLE, NAME) \
> +case S_##DP_TYPE##_##PIPELINE##_##STAGE: return DP_##DP_TYPE;
> +PIPELINE_STAGES
> +#undef PIPELINE_STAGE
> +default: OVS_NOT_REACHED();
> +}
> +}
>
> static void
> usage(void)
> @@ -303,6 +317,13 @@ ovn_datapath_destroy(struct hmap *datapaths, struct
> ovn_datapath *od)
> }
> }
>
> +/* Returns 'od''s datapath type. */
> +static enum ovn_datapath_type
> +ovn_datapath_get_type(const struct ovn_datapath *od)
> +{
> +return od->nbs ? DP_SWITCH : DP_ROUTER;
> +}
> +
> static struct ovn_datapath *
> ovn_datapath_find
Re: [ovs-dev] [PATCH] datapath-windows: Fix various Geneve bugs
On 13 July 2016 at 20:21, Yin Lin wrote:
> Signed-off-by: Yin Lin
>
Thank you, applied.
> ---
> datapath-windows/ovsext/Flow.c | 2 +-
> datapath-windows/ovsext/Vport.c | 3 ++-
> datapath-windows/ovsext/Vport.h | 5 +
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/datapath-windows/ovsext/Flow.c
> b/datapath-windows/ovsext/Flow.c
> index bc0bb37..7a57f96 100644
> --- a/datapath-windows/ovsext/Flow.c
> +++ b/datapath-windows/ovsext/Flow.c
> @@ -1683,7 +1683,7 @@ OvsTunnelAttrToGeneveOptions(PNL_ATTR attr,
> option = (GeneveOptionHdr *)((UINT8 *)option + len);
> optLen -= len;
> }
> -memcpy(TunnelKeyGetOptions(tunKey), option, optLen);
> +memcpy(TunnelKeyGetOptions(tunKey), NlAttrData(attr),
> tunKey->tunOptLen);
> if (isCritical) {
> tunKey->flags |= OVS_TNL_F_CRT_OPT;
> }
> diff --git a/datapath-windows/ovsext/Vport.c
> b/datapath-windows/ovsext/Vport.c
> index 1462453..22741db 100644
> --- a/datapath-windows/ovsext/Vport.c
> +++ b/datapath-windows/ovsext/Vport.c
> @@ -724,7 +724,8 @@
> OvsFindTunnelVportByDstPortAndNWProto(POVS_SWITCH_CONTEXT switchContext,
> if (GetPortFromPriv(vport) == dstPort) {
> switch (nwProto) {
> case IPPROTO_UDP:
> -if (vport->ovsType != OVS_VPORT_TYPE_VXLAN) {
> +if (vport->ovsType != OVS_VPORT_TYPE_GENEVE &&
> +vport->ovsType != OVS_VPORT_TYPE_VXLAN) {
> continue;
> }
> break;
> diff --git a/datapath-windows/ovsext/Vport.h
> b/datapath-windows/ovsext/Vport.h
> index f0a9acd..1f4968e 100644
> --- a/datapath-windows/ovsext/Vport.h
> +++ b/datapath-windows/ovsext/Vport.h
> @@ -21,6 +21,7 @@
> #include "Stt.h"
> #include "Switch.h"
> #include "VxLan.h"
> +#include "Geneve.h"
>
> #define OVS_MAX_DPPORTS MAXUINT16
> #define OVS_DPPORT_NUMBER_INVALID OVS_MAX_DPPORTS
> @@ -183,6 +184,7 @@ static __inline BOOLEAN
> OvsIsTunnelVportType(OVS_VPORT_TYPE ovsType)
> {
> return ovsType == OVS_VPORT_TYPE_VXLAN ||
> + ovsType == OVS_VPORT_TYPE_GENEVE ||
> ovsType == OVS_VPORT_TYPE_STT ||
> ovsType == OVS_VPORT_TYPE_GRE;
> }
> @@ -270,6 +272,9 @@ GetPortFromPriv(POVS_VPORT_ENTRY vport)
> case OVS_VPORT_TYPE_VXLAN:
> dstPort = ((POVS_VXLAN_VPORT)vportPriv)->dstPort;
> break;
> +case OVS_VPORT_TYPE_GENEVE:
> +dstPort = ((POVS_GENEVE_VPORT) vportPriv)->dstPort;
> +break;
> default:
> ASSERT(! "Port is not a tunnel port");
> }
> --
> 2.8.0.windows.1
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: ovn-northd and von-controller take a high amount of CPU time.
On 21 July 2016 at 23:02, nickcooper-zhangtonghao <
nickcooper-zhangtong...@opencloud.tech> wrote:
> Hi all,
> When setting the logical switch port as the peer of logical router,
> I found a large number of ovn-northd log. The process of ovn-northd write
> quickly the log
> all the time. The worse thing that the process of ovn-northd and
> von-controller
> take a high amount of CPU time. I think this is a bug， undoubtedly.
> The path I provide may fix the bug.
>
> commands:
> ovn-nbctl ls-add ls0
> ovn-nbctl lsp-add ls0 ls0-p0
>
> ovn-nbctl lr-add lr0
> ovn-nbctl lrp-add lr0 lr0-p0 00:11:22:33:44:55 192.168.100.10/24
> peer=ls0-p0
>
You should not use "peer" while connecting a switch with a router. There
are patches that are under review that fix the high CPU percentage
behavior.
>
>
>
> When setting the logical switch port as the peer of logical router,
> the process of ovn-northd write quickly the log and take a high amount of
> CPU time.
>
> Signed-off-by: nickcooper-zhangtonghao
>
> ---
> ovn/northd/ovn-northd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 78679b1..4e83ad1 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2634,7 +2634,7 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
> * should be on peer's outport. */
> if (op->nbr->peer) {
> struct ovn_port *peer = ovn_port_find(ports,
> op->nbr->peer);
> -if (!peer) {
> +if (!peer || (peer && peer->nbs)) {
> continue;
> }
>
> --
> 1.8.3.1
>
>
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/3] ovn-northd: Only peer router ports to other router ports.
On 19 July 2016 at 09:07, Ben Pfaff wrote:
> A router port's "peer", if set, must point to another router port, but the
> code as written also accepted switch ports. This caused problems when
> switch ports were actually specified.
>
> Reported-by: Gurucharan Shetty
> Reported-at: http://openvswitch.org/pipermail/dev/2016-July/075524.html
> Signed-off-by: Ben Pfaff
>
Acked-by: Gurucharan Shetty
> ---
> ovn/northd/ovn-northd.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 7ce509d..9047635 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -496,6 +496,12 @@ struct ovn_port {
>
> struct lport_addresses lrp_networks;
>
> +/* The port's peer:
> + *
> + * - A switch port S of type "router" has a router port R as a
> peer,
> + * and R in turn has S has its peer.
> + *
> + * - Two connected logical router ports have each other as peer.
> */
> struct ovn_port *peer;
>
> struct ovn_datapath *od;
> @@ -715,7 +721,22 @@ join_logical_ports(struct northd_context *ctx,
> sizeof *op->od->router_ports * (op->od->n_router_ports +
> 1));
> op->od->router_ports[op->od->n_router_ports++] = op;
> } else if (op->nbr && op->nbr->peer) {
> -op->peer = ovn_port_find(ports, op->nbr->peer);
> +struct ovn_port *peer = ovn_port_find(ports, op->nbr->peer);
> +if (peer) {
> +if (peer->nbr) {
> +op->peer = peer;
> +} else {
> +/* An ovn_port for a switch port of type "router"
> does have
> + * a router port as its peer (see the case above for
> + * "router" ports), but this is set via
> options:router-port
> + * in Logical_Switch_Port and does not involve the
> + * Logical_Router_Port's 'peer' column. */
> +static struct vlog_rate_limit rl =
> +VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_WARN_RL(&rl, "Bad configuration: The peer of
> router "
> + "port %s is a switch port", op->key);
> +}
> +}
> }
> }
> }
> --
> 2.1.3
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/3] ovn-northd: Avoid redundant lookup of logical router port peer.
On 19 July 2016 at 09:07, Ben Pfaff wrote:
> An ovn_port keeps track of its peer in its 'peer' member, but the code
> updated by this commit instead did a redundant lookup of the peer.
>
> Signed-off-by: Ben Pfaff
>
Acked-by: Gurucharan Shetty
> ---
> ovn/northd/ovn-northd.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 9047635..8418f53 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2618,21 +2618,16 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
> *
> * The packet is still in peer's logical pipeline. So the
> match
> * should be on peer's outport. */
> -if (op->nbr->peer) {
> -struct ovn_port *peer = ovn_port_find(ports,
> op->nbr->peer);
> -if (!peer) {
> -continue;
> -}
> -
> +if (op->peer && op->peer->nbr) {
> ds_clear(&match);
> ds_put_format(&match, "outport == %s && reg0 == ",
> - peer->json_key);
> + op->peer->json_key);
> op_put_networks(&match, op, false);
>
> ds_clear(&actions);
> ds_put_format(&actions, "eth.dst = %s; next;",
>op->lrp_networks.ea_s);
> -ovn_lflow_add(lflows, peer->od, S_ROUTER_IN_ARP_RESOLVE,
> +ovn_lflow_add(lflows, op->peer->od,
> S_ROUTER_IN_ARP_RESOLVE,
>100, ds_cstr(&match), ds_cstr(&actions));
> }
> } else if (op->od->n_router_ports && strcmp(op->nbs->type,
> "router")) {
> --
> 2.1.3
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] ovn test failures
On 21 July 2016 at 06:05, Ryan Moats wrote: > "dev" wrote on 07/21/2016 06:32:02 AM: > > > From: Lance Richardson > > To: ovs dev > > Date: 07/21/2016 06:32 AM > > Subject: [ovs-dev] ovn test failures > > Sent by: "dev" > > > > It seems the failure rate for OVN end-to-end tests went up significantly > > when commit 70c7cfef188b5ae9940abd5b7d9fe46b1fa88c8e was merged earlier > > this week. > > > > After this commit, 100 iterations of "make check TESTSUITEFLAGs='-j8 -k > ovn'" > > gave (number of failures in left-most column): > > 2 2179: ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS FAILED > > (ovn.at:1312) > > 10 2183: ovn -- 2 HVs, 2 LS, 1 lport/LS, 2 peer LRs FAILED > > (ovn.at:2416) > > 52 2184: ovn -- 1 HV, 1 LS, 2 lport/LS, 1 LR FAILED > > (ovn.at:2529) > > 45 2185: ovn -- 1 HV, 2 LSs, 1 lport/LS, 1 LRFAILED > > (ovn.at:2668) > > 23 2186: ovn -- 2 HVs, 3 LS, 1 lport/LS, 2 peer LRs, static > > routes FAILED (ovn.at:2819) > > 53 2188: ovn -- 2 HVs, 3 LRs connected via LS, static routes > > FAILED (ovn.at:3053) > > 32 2189: ovn -- 2 HVs, 2 LRs connected via LS, gateway router > > FAILED (ovn.at:3237) > > 50 2190: ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR > > FAILED (ovn.at:3389) > > > > Immediately prior to this (at commit > > 48ff3e25abe31b761d2d3f3a2fd6ccaa783c79dc), > > the number of failures per 100 iterations was much lower: > > 1 2178: ovn -- 2 HVs, 4 lports/HV, localnet ports FAILED > > (ovn.at:1020) > > 1 2179: ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS FAILED > > (ovn.at:1307) > > 1 2179: ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS FAILED > > (ovn.at:1312) > > 9 2184: ovn -- 1 HV, 1 LS, 2 lport/LS, 1 LR FAILED > > (ovn.at:2529) > > 7 2186: ovn -- 2 HVs, 3 LS, 1 lport/LS, 2 peer LRs, static > > routes FAILED (ovn.at:2819) > > 1 2187: ovn -- send gratuitous arp on localnet FAILED > > (ovn.at:2874) > > 16 2188: ovn -- 2 HVs, 3 LRs connected via LS, static routes > > FAILED (ovn.at:3053) > > > > Any ideas? > > > > Thanks, > > > > Lance > > As author of that patch, I will admit that those numbers are a > bit disturbing, because they aren't consistent with what I was > seeing while developing and testing the patch series. > > What they make me suspect is that that patches doesn't catch all > state transitions (similar to what you uncovered with commit > f94705d729459d808fd139c8f95d5f1f8d8becc6) correctly. > > Two things come to mind: > 1) Make sure that all of the places where the code needs to request >a full process of tables are correctly handled. > 2) If a later step in the process finds that an earlier step in >the process needs to process the database rows fully during the >next cycle, use poll_immediate_wake so that processing happens >sooner than later. > Ryan, Were you planning to look at the failures? Should we revert the patch? > > Ryan > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V9] windows: Added lockf function and lock PID file
On 25 July 2016 at 05:50, Paul Boca wrote:
> If the PID file isn't locked then appctl.py detects it as stale and
> bails out without doing anything. Because of this lots of Python tests
> fail.
> Also this protects the PID file from being overwritten.
>
> I used only shared lock, in order to be compatible with Python tests,
> which try to acquire the lock exclusively. On Windows if the exclusive lock
> is used, than the read access is denied too for other instances of this
> file.
>
> Signed-off-by: Paul-Daniel Boca
> Acked-by: Alin Gabriel Serdean
>
Thank you, applied!
> ---
> V2: No changes
> V3: No changes
> V4: No changes
> V5: Removed this patch from Python series.
> Removed unused constants and defined 0x as constant.
> Updated commit text.
> V6: flock returns now the error of GetLastError.
> Also it uses fd parameter instead of the global filep_pidfile.
> Removed unused local variable and unnecessary error message.
> V7: Keep a shared lock on PID file after the fopen.
> This ensures us that at most one process can write the same PID file.
> fopen with 'w' on Windows creates a file with FILE_SHARED_WRITE
> flag, so anyone with write access on file can write it.
> V8: Added LOCKFILE_FAIL_IMMEDIATELY flag when trying to get exclusive lock
> on PID file in order to avoid hangs of other daemons that try to
> acquire
> exclusive lock over the same PID file
> V9: Small fatal error message update and on constants used.
> Lock only the first byte in PID file, this is enough in our case.
> ---
> lib/daemon-windows.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
> index 8cf0fea..d77724e 100644
> --- a/lib/daemon-windows.c
> +++ b/lib/daemon-windows.c
> @@ -18,6 +18,7 @@
> #include "daemon.h"
> #include "daemon-private.h"
> #include
> +#include
> #include
> #include "dirs.h"
> #include "ovs-thread.h"
> @@ -26,6 +27,10 @@
>
> VLOG_DEFINE_THIS_MODULE(daemon_windows);
>
> +/* Constants for flock function */
> +#defineLOCK_SHARED 0x0 /* Shared lock. */
> +#defineLOCK_UNLOCK 0x8000 /* Unlock. Custom
> value. */
> +
> static bool service_create; /* Was --service specified? */
> static bool service_started; /* Have we dispatched service to
> start? */
>
> @@ -404,9 +409,39 @@ detach_process(int argc, char *argv[])
> }
>
> static void
> +flock(FILE* fd, int operation)
> +{
> +HANDLE hFile;
> +OVERLAPPED ov = {0};
> +
> +hFile = (HANDLE)_get_osfhandle(fileno(fd));
> +if (hFile == INVALID_HANDLE_VALUE) {
> +VLOG_FATAL("Failed to get PID file handle (%s).",
> + ovs_lasterror_to_string());
> +}
> +
> +if (operation & LOCK_UNLOCK) {
> +if (UnlockFileEx(hFile, 0, 1, 0, &ov) == 0) {
> +VLOG_FATAL("Failed to unlock PID file (%s).",
> + ovs_lasterror_to_string());
> +}
> +} else {
> + /* Use LOCKFILE_FAIL_IMMEDIATELY flag to avoid hang of another
> daemon that tries to
> + acquire exclusive lock over the same PID file */
> +if (LockFileEx(hFile, operation | LOCKFILE_FAIL_IMMEDIATELY,
> + 0, 1, 0, &ov) == FALSE) {
> +VLOG_FATAL("Failed to lock PID file (%s).",
> + ovs_lasterror_to_string());
> +}
> +}
> +}
> +
> +static void
> unlink_pidfile(void)
> {
> if (filep_pidfile) {
> +/* Remove the shared lock on file */
> +flock(filep_pidfile, LOCK_UNLOCK);
> fclose(filep_pidfile);
> }
> if (pidfile) {
> @@ -437,6 +472,8 @@ make_pidfile(void)
> VLOG_FATAL("failed to open %s (%s)", pidfile,
> ovs_strerror(errno));
> }
>
> +flock(filep_pidfile, LOCKFILE_EXCLUSIVE_LOCK);
> +
> fatal_signal_add_hook(unlink_pidfile, NULL, NULL, true);
>
> fprintf(filep_pidfile, "%d\n", _getpid());
> @@ -444,6 +481,10 @@ make_pidfile(void)
> VLOG_FATAL("Failed to write into the pidfile %s", pidfile);
> }
>
> +flock(filep_pidfile, LOCK_SHARED);
> +/* This will remove the exclusive lock. The shared lock will remain */
> +flock(filep_pidfile, LOCK_UNLOCK);
> +
> /* Don't close the pidfile till the process exits. */
> }
>
> --
> 2.7.2.windows.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] Windows: daemon-windows lockfile
On 25 July 2016 at 14:58, Alin Serdean
wrote:
> _get_osfhandle returns an errno value not a GetLastErrorValue.
> (https://msdn.microsoft.com/en-us/library/ks2530z6(v=vs.120).aspx)
>
> Signed-off-by: Alin Gabriel Serdean
>
Thank you. Applied to master.
> ---
> lib/daemon-windows.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
> index d77724e..7e2e9da 100644
> --- a/lib/daemon-windows.c
> +++ b/lib/daemon-windows.c
> @@ -417,7 +417,7 @@ flock(FILE* fd, int operation)
> hFile = (HANDLE)_get_osfhandle(fileno(fd));
> if (hFile == INVALID_HANDLE_VALUE) {
> VLOG_FATAL("Failed to get PID file handle (%s).",
> - ovs_lasterror_to_string());
> + ovs_strerror(errno));
> }
>
> if (operation & LOCK_UNLOCK) {
> --
> 1.9.5.msysgit.0
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v2] ovn-northd: Combine two NAT loops into one.
On 26 July 2016 at 10:19, Ben Pfaff wrote: > On Wed, Jul 13, 2016 at 04:20:36AM -0700, Gurucharan Shetty wrote: > > Signed-off-by: Gurucharan Shetty > > --- > > ovn/northd/ovn-northd.c | 47 > ++- > > 1 file changed, 14 insertions(+), 33 deletions(-) > > > > diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c > > index b1c2c6c..52e3229 100644 > > --- a/ovn/northd/ovn-northd.c > > +++ b/ovn/northd/ovn-northd.c > > @@ -2330,27 +2330,30 @@ build_lrouter_flows(struct hmap *datapaths, > struct hmap *ports, > >ds_cstr(&match), ds_cstr(&actions)); > > } > > > > -/* ARP handling for external IP addresses. > > - * > > - * DNAT IP addresses are external IP addresses that need ARP > > - * handling. */ > > +ovs_be32 *nat_ips = xmalloc(sizeof *nat_ips * > op->od->nbr->n_nat); > > +size_t n_snat_ips = 0; > > The code might be a little clearer with s/nat_ips/snat_ips/, to match > the name of n_snat_ips. > Thanks, I made the change as suggested and applied this. > > Acked-by: Ben Pfaff > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-controller: squelch expected duplicate flow warnings
On 24 July 2016 at 10:07, Ryan Moats wrote:
> In the physical processing of ovn-controller, there are two
> sets of OF flows that are still fully recalculated every cycle:
>
> Flows that aren't associated with any logical flow, and
> Flows calculated based on multicast groups
>
> Because these flows are recalculated fully each cycle, full
> duplicates of existing OF flows are created and the OF management
> code in ovn-controller pollutes the logs with false positive
> warnings about repeated duplicates.
>
> As a short term measure, ignore full duplicates for both of
> these types of flows, but still warn if the action changes
> (as that is not expected and may be indicative of a problem).
>
> Signed-off-by: Ryan Moats
>
Even with this patch, I get consistent unit test failures when I run OVN
system tests via :
make check-kernel TESTSUITEFLAGS="-k ovn"
The test that fails has the following warning:
+2016-07-26T09:58:04.535Z|00013|ofctrl|WARN|duplicate flow with modified
action for parent a356d28e-84f1-4984-94b2-3ee5a3db2b9b: table_id=32,
priority=100, reg15=0x,metadata=0x6,
actions=set_field:0x1->reg15,resubmit(,34),set_field:0x->reg15,resubmit(,33)
> ---
> ovn/controller/ofctrl.c | 26 +-
> ovn/controller/ofctrl.h | 3 +++
> ovn/controller/physical.c | 28 +++-
> 3 files changed, 43 insertions(+), 14 deletions(-)
>
> diff --git a/ovn/controller/ofctrl.c b/ovn/controller/ofctrl.c
> index f0451b7..2b26f2d 100644
> --- a/ovn/controller/ofctrl.c
> +++ b/ovn/controller/ofctrl.c
> @@ -550,10 +550,10 @@ log_ovn_flow_rl(struct vlog_rate_limit *rl, enum
> vlog_level level,
> *
> * This just assembles the desired flow tables in memory. Nothing is
> actually
> * sent to the switch until a later call to ofctrl_run(). */
> -void
> -ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> +static void
> +_ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> const struct match *match, const struct ofpbuf *actions,
> -const struct uuid *uuid)
> +const struct uuid *uuid, bool dupwarn)
> {
> /* Structure that uses table_id+priority+various things as hashes. */
> struct ovn_flow *f = xmalloc(sizeof *f);
> @@ -591,8 +591,10 @@ ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> */
> if (ofpacts_equal(f->ofpacts, f->ofpacts_len,
>d->ofpacts, d->ofpacts_len)) {
> -static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> -log_ovn_flow_rl(&rl, VLL_INFO, f, "duplicate flow");
> +if (dupwarn) {
> +static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> +log_ovn_flow_rl(&rl, VLL_INFO, f, "duplicate flow");
> +}
> } else {
> static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> log_ovn_flow_rl(&rl, VLL_WARN, f,
> @@ -617,6 +619,20 @@ ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> f->uuid_hindex_node.hash);
> }
>
> +void
> +ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> +const struct match *match, const struct ofpbuf *actions,
> +const struct uuid *uuid) {
> +_ofctrl_add_flow(table_id, priority, match, actions, uuid, true);
> +}
> +
> +void
> +ofctrl_add_flow_no_warn(uint8_t table_id, uint16_t priority,
> +const struct match *match, const struct ofpbuf
> *actions,
> +const struct uuid *uuid) {
> +_ofctrl_add_flow(table_id, priority, match, actions, uuid, false);
> +}
> +
> /* Removes a bundles of flows from the flow table. */
> void
> ofctrl_remove_flows(const struct uuid *uuid)
> diff --git a/ovn/controller/ofctrl.h b/ovn/controller/ofctrl.h
> index 49b95b0..b591e82 100644
> --- a/ovn/controller/ofctrl.h
> +++ b/ovn/controller/ofctrl.h
> @@ -42,6 +42,9 @@ struct ovn_flow *ofctrl_dup_flow(struct ovn_flow
> *source);
> void ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> const struct match *, const struct ofpbuf *ofpacts,
> const struct uuid *uuid);
> +void ofctrl_add_flow_no_warn(uint8_t table_id, uint16_t priority,
> + const struct match *, const struct ofpbuf
> *ofpacts,
> + const struct uuid *uuid);
>
> void ofctrl_remove_flows(const struct uuid *uuid);
>
> diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
> index a104e33..9e6dff4 100644
> --- a/ovn/controller/physical.c
> +++ b/ovn/controller/physical.c
> @@ -549,8 +549,9 @@ consider_mc_group(enum mf_field_id mff_ovn_geneve,
> * group as the logical output port. */
> put_load(mc->tunnel_key, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
>
> -ofctrl_add_flow(OFTABLE_LOCAL_OUTPUT, 100,
> -&match, ofpacts_p, &mc->
Re: [ovs-dev] [PATCH] ovn-controller: squelch expected duplicate flow warnings
On 24 July 2016 at 10:07, Ryan Moats wrote:
> In the physical processing of ovn-controller, there are two
> sets of OF flows that are still fully recalculated every cycle:
>
> Flows that aren't associated with any logical flow, and
> Flows calculated based on multicast groups
>
> Because these flows are recalculated fully each cycle, full
> duplicates of existing OF flows are created and the OF management
> code in ovn-controller pollutes the logs with false positive
> warnings about repeated duplicates.
>
> As a short term measure, ignore full duplicates for both of
> these types of flows, but still warn if the action changes
> (as that is not expected and may be indicative of a problem).
>
> Signed-off-by: Ryan Moats
>
I also noticed that "commit 70c7cfef188b5ae9940abd5 (ovn-controller: Add
incremental processing to lflow_run and physical_run)" causes load
balancing system unit tests to fail. A little debugging shows that groups
are getting deleted when new flows are added. My hunch is that this is
likely because 'desired_groups' in ofctl_put gets deleted in every run. But
in the next run, it does not get updated as we no longer process all flows.
---
> ovn/controller/ofctrl.c | 26 +-
> ovn/controller/ofctrl.h | 3 +++
> ovn/controller/physical.c | 28 +++-
> 3 files changed, 43 insertions(+), 14 deletions(-)
>
> diff --git a/ovn/controller/ofctrl.c b/ovn/controller/ofctrl.c
> index f0451b7..2b26f2d 100644
> --- a/ovn/controller/ofctrl.c
> +++ b/ovn/controller/ofctrl.c
> @@ -550,10 +550,10 @@ log_ovn_flow_rl(struct vlog_rate_limit *rl, enum
> vlog_level level,
> *
> * This just assembles the desired flow tables in memory. Nothing is
> actually
> * sent to the switch until a later call to ofctrl_run(). */
> -void
> -ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> +static void
> +_ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> const struct match *match, const struct ofpbuf *actions,
> -const struct uuid *uuid)
> +const struct uuid *uuid, bool dupwarn)
> {
> /* Structure that uses table_id+priority+various things as hashes. */
> struct ovn_flow *f = xmalloc(sizeof *f);
> @@ -591,8 +591,10 @@ ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> */
> if (ofpacts_equal(f->ofpacts, f->ofpacts_len,
>d->ofpacts, d->ofpacts_len)) {
> -static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> -log_ovn_flow_rl(&rl, VLL_INFO, f, "duplicate flow");
> +if (dupwarn) {
> +static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> +log_ovn_flow_rl(&rl, VLL_INFO, f, "duplicate flow");
> +}
> } else {
> static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
> log_ovn_flow_rl(&rl, VLL_WARN, f,
> @@ -617,6 +619,20 @@ ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> f->uuid_hindex_node.hash);
> }
>
> +void
> +ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> +const struct match *match, const struct ofpbuf *actions,
> +const struct uuid *uuid) {
> +_ofctrl_add_flow(table_id, priority, match, actions, uuid, true);
> +}
> +
> +void
> +ofctrl_add_flow_no_warn(uint8_t table_id, uint16_t priority,
> +const struct match *match, const struct ofpbuf
> *actions,
> +const struct uuid *uuid) {
> +_ofctrl_add_flow(table_id, priority, match, actions, uuid, false);
> +}
> +
> /* Removes a bundles of flows from the flow table. */
> void
> ofctrl_remove_flows(const struct uuid *uuid)
> diff --git a/ovn/controller/ofctrl.h b/ovn/controller/ofctrl.h
> index 49b95b0..b591e82 100644
> --- a/ovn/controller/ofctrl.h
> +++ b/ovn/controller/ofctrl.h
> @@ -42,6 +42,9 @@ struct ovn_flow *ofctrl_dup_flow(struct ovn_flow
> *source);
> void ofctrl_add_flow(uint8_t table_id, uint16_t priority,
> const struct match *, const struct ofpbuf *ofpacts,
> const struct uuid *uuid);
> +void ofctrl_add_flow_no_warn(uint8_t table_id, uint16_t priority,
> + const struct match *, const struct ofpbuf
> *ofpacts,
> + const struct uuid *uuid);
>
> void ofctrl_remove_flows(const struct uuid *uuid);
>
> diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
> index a104e33..9e6dff4 100644
> --- a/ovn/controller/physical.c
> +++ b/ovn/controller/physical.c
> @@ -549,8 +549,9 @@ consider_mc_group(enum mf_field_id mff_ovn_geneve,
> * group as the logical output port. */
> put_load(mc->tunnel_key, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
>
> -ofctrl_add_flow(OFTABLE_LOCAL_OUTPUT, 100,
> -&match, ofpacts_p, &mc->header_.uuid)
Re: [ovs-dev] [PATCH] ovn-controller: squelch expected duplicate flow warnings
On 26 July 2016 at 15:54, Ryan Moats wrote: > > > > Guru Shetty wrote on 07/26/2016 03:54:29 PM: > > > From: Guru Shetty > > To: Ryan Moats/Omaha/IBM@IBMUS > > Cc: ovs dev > > Date: 07/26/2016 03:54 PM > > Subject: Re: [ovs-dev] [PATCH] ovn-controller: squelch expected > > duplicate flow warnings > > > > On 24 July 2016 at 10:07, Ryan Moats wrote: > > In the physical processing of ovn-controller, there are two > > sets of OF flows that are still fully recalculated every cycle: > > > > Flows that aren't associated with any logical flow, and > > Flows calculated based on multicast groups > > > > Because these flows are recalculated fully each cycle, full > > duplicates of existing OF flows are created and the OF management > > code in ovn-controller pollutes the logs with false positive > > warnings about repeated duplicates. > > > > As a short term measure, ignore full duplicates for both of > > these types of flows, but still warn if the action changes > > (as that is not expected and may be indicative of a problem). > > > > Signed-off-by: Ryan Moats > > > > I also noticed that "commit 70c7cfef188b5ae9940abd5 (ovn-controller: > > Add incremental processing to lflow_run and physical_run)" causes > > load balancing system unit tests to fail. A little debugging shows > > that groups are getting deleted when new flows are added. My hunch > > is that this is likely because 'desired_groups' in ofctl_put gets > > deleted in every run. But in the next run, it does not get updated > > as we no longer process all flows. > > That's going to take persisting the desired_groups data. > > I can take a shot if you'd like, just give me the link to the > patch set that includes the load balancing system unit tests > and I'll see what I can do to make it right ... > It already exists in the OVN repo. tests/system-ovn.at > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-controller: squelch expected duplicate flow warnings
> On Jul 26, 2016, at 5:30 PM, Ryan Moats wrote: > > Guru Shetty wrote on 07/26/2016 06:05:47 PM: > > > From: Guru Shetty > > To: Ryan Moats/Omaha/IBM@IBMUS > > Cc: ovs dev > > Date: 07/26/2016 06:06 PM > > Subject: Re: [ovs-dev] [PATCH] ovn-controller: squelch expected > > duplicate flow warnings > > > > On 26 July 2016 at 15:54, Ryan Moats wrote: > > > > > > > > Guru Shetty wrote on 07/26/2016 03:54:29 PM: > > > > > From: Guru Shetty > > > To: Ryan Moats/Omaha/IBM@IBMUS > > > Cc: ovs dev > > > Date: 07/26/2016 03:54 PM > > > Subject: Re: [ovs-dev] [PATCH] ovn-controller: squelch expected > > > duplicate flow warnings > > > > > > On 24 July 2016 at 10:07, Ryan Moats wrote: > > > In the physical processing of ovn-controller, there are two > > > sets of OF flows that are still fully recalculated every cycle: > > > > > > Flows that aren't associated with any logical flow, and > > > Flows calculated based on multicast groups > > > > > > Because these flows are recalculated fully each cycle, full > > > duplicates of existing OF flows are created and the OF management > > > code in ovn-controller pollutes the logs with false positive > > > warnings about repeated duplicates. > > > > > > As a short term measure, ignore full duplicates for both of > > > these types of flows, but still warn if the action changes > > > (as that is not expected and may be indicative of a problem). > > > > > > Signed-off-by: Ryan Moats > > > > > > I also noticed that "commit 70c7cfef188b5ae9940abd5 (ovn-controller: > > > Add incremental processing to lflow_run and physical_run)" causes > > > load balancing system unit tests to fail. A little debugging shows > > > that groups are getting deleted when new flows are added. My hunch > > > is that this is likely because 'desired_groups' in ofctl_put gets > > > deleted in every run. But in the next run, it does not get updated > > > as we no longer process all flows. > > > > That's going to take persisting the desired_groups data. > > > > I can take a shot if you'd like, just give me the link to the > > patch set that includes the load balancing system unit tests > > and I'll see what I can do to make it right ... > > > > It already exists in the OVN repo. tests/system-ovn.at > > Ack and verified that it is failing - I'll take a deeper look > later tonight/tomorrow and see what I can make work. > Thanks much. (Just to make sure you have the environment right, you should have the right kernel modules with conntrack support installed on your machine. On master, it will only work on pre 4.6 kernels if there is no ovs kernel module already instslled from upstream kernel. To make it work, you should either remove upstream kernel modules or install a /etc/depmod.d/openvswitch.conf to override upstream one. On 4.6 and above it should not matter as upstream kernel module has conntrack support. You can make sure that you get the tests working before the said commit so that you dont go on a wild goose chase.) > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-controller: update_ct_zone operates always on empty set
> On Jul 26, 2016, at 6:13 PM, Russell Bryant wrote:
>
>> On Tue, Jul 26, 2016 at 6:46 AM, wrote:
>>
>> From: Babu Shanmugam
>>
>> Commit 263064a (Convert binding_run to incremental processing.) removed
>> the usage
>> of all_lports from binding_run, but it is infact used in the context of
>> the caller,
>> especially by update_ct_zones().
>>
>> Without this change, update_ct_zones operates on an empty set always.
>>
>> Signed-off-by: Babu Shanmugam
>
> Ouch. This is a really bad regression. If I understand correctly, we're
> not setting a ct zone ID for any logical ports. All are just using the
> default zone of 0.
>
> We should think about a good way to test OVN's use of conntrack zones to
> ensure that entries end up in separate zones for separate ports. A good
> test for that may require userspace conntrack support, though.
I have added a couple of ovn tests in system-ovn.at that leverage kernel module
and conntrack. A basic test for firewall can be added.
>
> Another test we could do now would be looking at the flows in table 0 and
> ensuring that the input flow for each port has a different conntrack zone
> ID assigned. That feels like kind of a hack, though.
>
> ---
>> ovn/controller/binding.c| 4 +++-
>> ovn/controller/binding.h| 3 ++-
>> ovn/controller/ovn-controller.c | 2 +-
>> 3 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
>> index e83c1d5..7bc6fb4 100644
>> --- a/ovn/controller/binding.c
>> +++ b/ovn/controller/binding.c
>> @@ -230,7 +230,8 @@ consider_local_datapath(struct controller_ctx *ctx,
>>
>> void
>> binding_run(struct controller_ctx *ctx, const struct ovsrec_bridge
>> *br_int,
>> -const char *chassis_id, struct hmap *local_datapaths)
>> +const char *chassis_id, struct hmap *local_datapaths,
>> +struct sset *all_lports)
>> {
>> const struct sbrec_chassis *chassis_rec;
>> const struct sbrec_port_binding *binding_rec;
>> @@ -292,6 +293,7 @@ binding_run(struct controller_ctx *ctx, const struct
>> ovsrec_bridge *br_int,
>> }
>> }
>>
>> +sset_clone(all_lports, &local_ids);
>
> I don't think this is quite sufficient. It's missing, at least:
>
> - the IDs of sub-ports
>
> - localnet ports
>
> The old handling of building up all_lports ensure those got added.
>
>
>> shash_destroy(&lport_to_iface);
>> }
>>
>> diff --git a/ovn/controller/binding.h b/ovn/controller/binding.h
>> index 8753d44..fbd16c8 100644
>> --- a/ovn/controller/binding.h
>> +++ b/ovn/controller/binding.h
>> @@ -29,7 +29,8 @@ struct sset;
>> void binding_register_ovs_idl(struct ovsdb_idl *);
>> void binding_reset_processing(void);
>> void binding_run(struct controller_ctx *, const struct ovsrec_bridge
>> *br_int,
>> - const char *chassis_id, struct hmap *local_datapaths);
>> + const char *chassis_id, struct hmap *local_datapaths,
>> + struct sset *all_lports);
>> bool binding_cleanup(struct controller_ctx *, const char *chassis_id);
>>
>> #endif /* ovn/binding.h */
>> diff --git a/ovn/controller/ovn-controller.c
>> b/ovn/controller/ovn-controller.c
>> index 4d9490a..6a6bb93 100644
>> --- a/ovn/controller/ovn-controller.c
>> +++ b/ovn/controller/ovn-controller.c
>> @@ -425,7 +425,7 @@ main(int argc, char *argv[])
>> if (chassis_id) {
>> chassis_run(&ctx, chassis_id);
>> encaps_run(&ctx, br_int, chassis_id);
>> -binding_run(&ctx, br_int, chassis_id, &local_datapaths);
>> +binding_run(&ctx, br_int, chassis_id, &local_datapaths,
>> &all_lports);
>> }
>>
>> if (br_int && chassis_id) {
>> --
>> 2.5.5
>>
>> ___
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>
>
>
> --
> Russell Bryant
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] doc: Update INSTALL.Docker.md to reflect it's focus on OVN
On 27 July 2016 at 10:40, Kyle Mestery wrote: > While reading this document, the title stood out to me as not > accurate. The title indicates it will discuss how to use > Open vSwitch with Docker, but in reality, it's about using > Open Virtual Networking with Docker. > > This change updates the title, as well as the opening paragraphs > to more accurately reflect what the document is talking about. > > Signed-off-by: Kyle Mestery > Thank you! I fixed a couple of typos and applied this. > --- > INSTALL.Docker.md | 19 --- > 1 file changed, 8 insertions(+), 11 deletions(-) > > diff --git a/INSTALL.Docker.md b/INSTALL.Docker.md > index b7ca4ba..08758ae 100644 > --- a/INSTALL.Docker.md > +++ b/INSTALL.Docker.md > @@ -1,14 +1,11 @@ > -How to Use Open vSwitch with Docker > - > - > -This document describes how to use Open vSwitch with Docker 1.9.0 or > -later. This document assumes that you installed Open vSwitch by following > -[INSTALL.md] or by using the distribution packages such as .deb or .rpm. > -Consult www.docker.com for instructions on how to install Docker. > - > -Docker 1.9.0 comes with support for multi-host networking. Integration > -of Docker networking and Open vSwitch can be achieved via Open vSwitch > -virtual network (OVN). > +How to Use Open Virtual Networking With Docker > +== > + > +This document describes how to use Open Virtual Networking with Docker > +1.9.0 or later. This document assumes that you have installed Open > +vSwitch by following [INSTALL.md] or by using hte distribution packages > +such as .deb or.rpm. Consult www.docker.com for instructions on how to > +install Docker. Docker 1.9.0 comes with support for multi-host > networkign. > > > Setup > -- > 2.7.4 (Apple Git-66) > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/2] ovn:add easy SNAT test case
On 27 July 2016 at 23:30, Dongjun wrote: > Signed-off-by: Dongjun > Usually, we have a test with the corresponding code change. Can you have a look at https://www.mail-archive.com/dev@openvswitch.org/msg66099.html and see whether you are happy with the code change? > --- > tests/system-ovn.at | 106 > +++- > 1 file changed, 105 insertions(+), 1 deletion(-) > mode change 100644 => 100755 tests/system-ovn.at > > diff --git a/tests/system-ovn.at b/tests/system-ovn.at > old mode 100644 > new mode 100755 > index 13f380f..cb50fd4 > --- a/tests/system-ovn.at > +++ b/tests/system-ovn.at > @@ -1,4 +1,4 @@ > -AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, NAT]) > +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, SNAT and DNAT]) > AT_KEYWORDS([ovnnat]) > > CHECK_CONNTRACK() > @@ -168,6 +168,110 @@ as > OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d"]) > AT_CLEANUP > > +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, easy SNAT]) > +AT_KEYWORDS([ovnnat]) > + > +CHECK_CONNTRACK() > +ovn_start > +OVS_TRAFFIC_VSWITCHD_START() > +ADD_BR([br-int]) > + > +# Set external-ids in br-int needed for ovn-controller > +ovs-vsctl \ > +-- set Open_vSwitch . external-ids:system-id=hv1 \ > +-- set Open_vSwitch . > external-ids:ovn-remote=unix:$ovs_base/ovn-sb/ovn-sb.sock \ > +-- set Open_vSwitch . external-ids:ovn-encap-type=geneve \ > +-- set Open_vSwitch . external-ids:ovn-encap-ip=169.0.0.1 \ > +-- set bridge br-int fail-mode=secure > other-config:disable-in-band=true > + > +# Start ovn-controller > +start_daemon ovn-controller > + > +# Logical network: > +# Two LRs - R1 and R2 that are connected to each other via LS "join" > +# in 20.0.0.0/24 network. R1 has switchess foo (192.168.1.0/24) > connected to it. > +# R2 has alice (172.16.1.0/24) connectedto it. > +# R2 is a gateway router on which we add NAT rules. > +# > +#foo -- R1 -- join - R2 -- alice > + > +ovn-nbctl lr-add R1 > +ovn-nbctl lr-add R2 -- set Logical_Router R2 options:chassis=hv1 > + > +ovn-nbctl ls-add foo > +ovn-nbctl ls-add alice > +ovn-nbctl ls-add join > + > +ovn-nbctl lrp-add R1 foo 00:00:01:01:02:03 192.168.1.1/24 > +ovn-nbctl lrp-add R2 alice 00:00:02:01:02:03 172.16.1.1/24 > +ovn-nbctl lrp-add R1 R1_join 00:00:04:01:02:03 20.0.0.1/24 > +ovn-nbctl lrp-add R2 R2_join 00:00:04:01:02:04 20.0.0.2/24 > + > +# Connect foo to R1 > +ovn-nbctl lsp-add foo rp-foo -- set Logical_Switch_Port rp-foo \ > +type=router options:router-port=foo addresses=\"00:00:01:01:02:03\" > + > +# Connect alice to R2 > +ovn-nbctl lsp-add alice rp-alice -- set Logical_Switch_Port rp-alice \ > +type=router options:router-port=alice addresses=\"00:00:02:01:02:03\" > + > +# Connect R1 to join > +ovn-nbctl lsp-add join r1-join -- set Logical_Switch_Port r1-join \ > +type=router options:router-port=R1_join > addresses='"00:00:04:01:02:03"' > + > +# Connect R2 to join > +ovn-nbctl lsp-add join r2-join -- set Logical_Switch_Port r2-join \ > +type=router options:router-port=R2_join > addresses='"00:00:04:01:02:04"' > + > +# Static routes. > +ovn-nbctl lr-route-add R1 172.16.1.0/24 20.0.0.2 > +ovn-nbctl lr-route-add R2 192.168.0.0/16 20.0.0.1 > + > +# Logical port 'foo1' in switch 'foo'. > +ADD_NAMESPACES(foo1) > +ADD_VETH(foo1, foo1, br-int, "192.168.1.2/24", "f0:00:00:01:02:03", \ > + "192.168.1.1") > +ovn-nbctl lsp-add foo foo1 \ > +-- lsp-set-addresses foo1 "f0:00:00:01:02:03 192.168.1.2" > + > +# Logical port 'alice1' in switch 'alice'. > +ADD_NAMESPACES(alice1) > +ADD_VETH(alice1, alice1, br-int, "172.16.1.2/24", "f0:00:00:01:02:04", \ > + "172.16.1.1") > +ovn-nbctl lsp-add alice alice1 \ > +-- lsp-set-addresses alice1 "f0:00:00:01:02:04 172.16.1.2" > + > +# Add a SNAT rule > +ovn-nbctl -- --id=@nat create nat type="snat" logical_ip=192.168.1.2 \ > +external_ip=20.0.0.2 -- add logical_router R2 nat @nat > + > +# South-North SNAT: 'foo1' pings 'alice1'. But 'alice1' receives traffic > +# from 20.0.0.2 > +NS_CHECK_EXEC([foo1], [ping -q -c 3 -i 0.3 -w 2 172.16.1.2 | > FORMAT_PING], \ > +[0], [dnl > +3 packets transmitted, 3 received, 0% packet loss, time 0ms > +]) > + > +# We verify that SNAT indeed happened via 'dump-conntrack' command. > +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(20.0.0.2) | \ > +sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl > > +icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=20.0.0.2,id=),zone= > +]) > + > +OVS_APP_EXIT_AND_WAIT([ovn-controller]) > + > +as ovn-sb > +OVS_APP_EXIT_AND_WAIT([ovsdb-server]) > + > +as ovn-nb > +OVS_APP_EXIT_AND_WAIT([ovsdb-server]) > + > +as northd > +OVS_APP_EXIT_AND_WAIT([ovn-northd]) > + > +as > +OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d"]) > +AT_CLEANUP > > AT_SETUP([ovn -- load-balancing]) > AT_KEYWORDS([ovnlb]) > -- > 1.8.3.1 > > ___ > dev mailing list > dev@openvswi
Re: [ovs-dev] [PATCH] ovn: Rename "gateway" to "l3gateway".
On 26 July 2016 at 13:49, Russell Bryant wrote:
> When L3 gateway support was added, it introduced a port type called
> "gateway" and a corresponding option called "gateway-chassis". Since
> that time, we also have an L2 gateway port type called "l2gateway" and a
> corresponding option called "l2gateway-chassis". This patch renames the
> L3 gateway port type and option to "l3gateway" and "l3gateway-chassis"
> to make things a little more clear and consistent.
>
> Signed-off-by: Russell Bryant
>
Acked-by: Gurucharan Shetty
> ---
> ovn/controller/binding.c | 2 +-
> ovn/controller/patch.c | 4 ++--
> ovn/northd/ovn-northd.c | 12 ++--
> ovn/ovn-sb.xml | 18 +-
> 4 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
> index e83c1d5..78ebec4 100644
> --- a/ovn/controller/binding.c
> +++ b/ovn/controller/binding.c
> @@ -219,7 +219,7 @@ consider_local_datapath(struct controller_ctx *ctx,
> add_local_datapath(local_datapaths, binding_rec);
> }
> } else if (chassis_rec && binding_rec->chassis == chassis_rec
> - && strcmp(binding_rec->type, "gateway")) {
> + && strcmp(binding_rec->type, "l3gateway")) {
> if (ctx->ovnsb_idl_txn) {
> VLOG_INFO("Releasing lport %s from this chassis.",
>binding_rec->logical_port);
> diff --git a/ovn/controller/patch.c b/ovn/controller/patch.c
> index 707d08b..012e6ba 100644
> --- a/ovn/controller/patch.c
> +++ b/ovn/controller/patch.c
> @@ -346,9 +346,9 @@ add_logical_patch_ports(struct controller_ctx *ctx,
> const struct sbrec_port_binding *binding;
> SBREC_PORT_BINDING_FOR_EACH (binding, ctx->ovnsb_idl) {
> bool local_port = false;
> -if (!strcmp(binding->type, "gateway")) {
> +if (!strcmp(binding->type, "l3gateway")) {
> const char *chassis = smap_get(&binding->options,
> - "gateway-chassis");
> + "l3gateway-chassis");
> if (chassis && !strcmp(local_chassis_id, chassis)) {
> local_port = true;
> }
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 38a3d30..7f5927e 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -770,10 +770,10 @@ ovn_port_update_sbrec(const struct ovn_port *op)
> sbrec_port_binding_set_datapath(op->sb, op->od->sb);
> if (op->nbrp) {
> /* If the router is for l3 gateway, it resides on a chassis
> - * and its port type is "gateway". */
> + * and its port type is "l3gateway". */
> const char *chassis = smap_get(&op->od->nbr->options, "chassis");
> if (chassis) {
> -sbrec_port_binding_set_type(op->sb, "gateway");
> +sbrec_port_binding_set_type(op->sb, "l3gateway");
> } else {
> sbrec_port_binding_set_type(op->sb, "patch");
> }
> @@ -783,7 +783,7 @@ ovn_port_update_sbrec(const struct ovn_port *op)
> smap_init(&new);
> smap_add(&new, "peer", peer);
> if (chassis) {
> -smap_add(&new, "gateway-chassis", chassis);
> +smap_add(&new, "l3gateway-chassis", chassis);
> }
> sbrec_port_binding_set_options(op->sb, &new);
> smap_destroy(&new);
> @@ -802,9 +802,9 @@ ovn_port_update_sbrec(const struct ovn_port *op)
> }
>
> /* A switch port connected to a gateway router is also of
> - * type "gateway". */
> + * type "l3gateway". */
> if (chassis) {
> -sbrec_port_binding_set_type(op->sb, "gateway");
> +sbrec_port_binding_set_type(op->sb, "l3gateway");
> } else {
> sbrec_port_binding_set_type(op->sb, "patch");
> }
> @@ -818,7 +818,7 @@ ovn_port_update_sbrec(const struct ovn_port *op)
> smap_init(&new);
> smap_add(&new, "peer", router_port);
> if (chassis) {
> -smap_add(&new, "gateway-chassis", chassis);
> +smap_add(&new, "l3gateway-chassis", chassis);
> }
> sbrec_port_binding_set_options(op->sb, &new);
> smap_destroy(&new);
> diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
> index 3d26e65..3cdf91b 100644
> --- a/ovn/ovn-sb.xml
> +++ b/ovn/ovn-sb.xml
> @@ -1420,8 +1420,8 @@ tcp.flags = RST;
>database, which identifies logical ports via the conventions
> described
>in IntegrationGuide.md. (The exceptions are for
>Port_Binding records with type of
> - gateway, whose locations are identified by
> - ovn-northd via the options:gateway-chassis
> + l3gateway, whose locations are identified by
> + ovn-northd via the
> options:l3gateway-chassis
>column in this table. ovn-controller is still
Re: [ovs-dev] [PATCH v3] ovn: Allow SNAT traffic destined to router ip
On 18 July 2016 at 09:57, Chandra S Vejendla wrote:
> When router ip is used as SNAT IP, traffic destined to router
> ip should not be dropped
>
> Fixes: 4685e523695c ("ovn: Support multiple addresses on a single logical
> router port.")
> Signed-off-by: Chandra Sekhar Vejendla
>
I applied this as we do have a test provided by Dongjun and fixes a bug.
But that is a system test case. Do consider providing non-system unit test.
> ---
> ovn/northd/ovn-northd.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 7ce509d..78c3a7d 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2399,11 +2399,16 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
> ds_put_cstr(&match, "ip4.dst == {");
> bool has_drop_ips = false;
> for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> +bool nat_ip_is_router_ip = false;
> for (int j = 0; j < n_nat_ips; j++) {
> if (op->lrp_networks.ipv4_addrs[i].addr == nat_ips[j]) {
> -continue;
> +nat_ip_is_router_ip = true;
> +break;
> }
> }
> +if (nat_ip_is_router_ip) {
> +continue;
> +}
> ds_put_format(&match, "%s, ",
>op->lrp_networks.ipv4_addrs[i].addr_s);
> has_drop_ips = true;
> --
> 2.6.1
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/2] ovn:add easy SNAT test case
On 28 July 2016 at 06:55, Dong Jun wrote: > Yes, this test case fail currently and success with the modification. > If there is another same test case, ignore this patch is OK. > Thank you for the test. I applied the linked patch by Chandra as it was already reviewed and applied your unit test and also added you in AUTHORS. I did look at your second patch of the series. Please read CodingStyle.md for any future contributions. > > On 2016/7/28 21:31, Guru Shetty wrote: > >> >> >> On 27 July 2016 at 23:30, Dongjun > do...@dtdream.com>> wrote: >> >> Signed-off-by: Dongjun mailto:do...@dtdream.com>> >> >> >> Usually, we have a test with the corresponding code change. Can you have >> a look at https://www.mail-archive.com/dev@openvswitch.org/msg66099.html >> and see whether you are happy with the code change? >> >> --- >> tests/system-ovn.at <http://system-ovn.at> | 106 >> +++- >> 1 file changed, 105 insertions(+), 1 deletion(-) >> mode change 100644 => 100755 tests/system-ovn.at >> <http://system-ovn.at> >> >> diff --git a/tests/system-ovn.at <http://system-ovn.at> >> b/tests/system-ovn.at <http://system-ovn.at> >> old mode 100644 >> new mode 100755 >> index 13f380f..cb50fd4 >> --- a/tests/system-ovn.at <http://system-ovn.at> >> +++ b/tests/system-ovn.at <http://system-ovn.at> >> >> @@ -1,4 +1,4 @@ >> -AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, NAT]) >> +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, SNAT and >> DNAT]) >> AT_KEYWORDS([ovnnat]) >> >> CHECK_CONNTRACK() >> @@ -168,6 +168,110 @@ as >> OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d"]) >> AT_CLEANUP >> >> +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, easy SNAT]) >> +AT_KEYWORDS([ovnnat]) >> + >> +CHECK_CONNTRACK() >> +ovn_start >> +OVS_TRAFFIC_VSWITCHD_START() >> +ADD_BR([br-int]) >> + >> +# Set external-ids in br-int needed for ovn-controller >> +ovs-vsctl \ >> +-- set Open_vSwitch . external-ids:system-id=hv1 \ >> +-- set Open_vSwitch . >> external-ids:ovn-remote=unix:$ovs_base/ovn-sb/ovn-sb.sock \ >> +-- set Open_vSwitch . external-ids:ovn-encap-type=geneve \ >> +-- set Open_vSwitch . external-ids:ovn-encap-ip=169.0.0.1 \ >> +-- set bridge br-int fail-mode=secure >> other-config:disable-in-band=true >> + >> +# Start ovn-controller >> +start_daemon ovn-controller >> + >> +# Logical network: >> +# Two LRs - R1 and R2 that are connected to each other via LS "join" >> +# in 20.0.0.0/24 <http://20.0.0.0/24> network. R1 has switchess >> foo (192.168.1.0/24 <http://192.168.1.0/24>) connected to it. >> +# R2 has alice (172.16.1.0/24 <http://172.16.1.0/24>) connectedto >> it. >> +# R2 is a gateway router on which we add NAT rules. >> +# >> +#foo -- R1 -- join - R2 -- alice >> + >> +ovn-nbctl lr-add R1 >> +ovn-nbctl lr-add R2 -- set Logical_Router R2 options:chassis=hv1 >> + >> +ovn-nbctl ls-add foo >> +ovn-nbctl ls-add alice >> +ovn-nbctl ls-add join >> + >> +ovn-nbctl lrp-add R1 foo 00:00:01:01:02:03 192.168.1.1/24 >> <http://192.168.1.1/24> >> +ovn-nbctl lrp-add R2 alice 00:00:02:01:02:03 172.16.1.1/24 >> <http://172.16.1.1/24> >> +ovn-nbctl lrp-add R1 R1_join 00:00:04:01:02:03 20.0.0.1/24 >> <http://20.0.0.1/24> >> +ovn-nbctl lrp-add R2 R2_join 00:00:04:01:02:04 20.0.0.2/24 >> <http://20.0.0.2/24> >> + >> +# Connect foo to R1 >> +ovn-nbctl lsp-add foo rp-foo -- set Logical_Switch_Port rp-foo \ >> +type=router options:router-port=foo >> addresses=\"00:00:01:01:02:03\" >> + >> +# Connect alice to R2 >> +ovn-nbctl lsp-add alice rp-alice -- set Logical_Switch_Port >> rp-alice \ >> +type=router options:router-port=alice >> addresses=\"00:00:02:01:02:03\" >> + >> +# Connect R1 to join >> +ovn-nbctl lsp-add join r1-join -- set Logical_Switch_Port r1-join \ >> +type=router options:router-port=R1_join >> addresses='"00:0
Re: [ovs-dev] [PATCH 1/2] ovn:add easy SNAT test case
On 28 July 2016 at 07:48, Guru Shetty wrote: > > > On 28 July 2016 at 06:55, Dong Jun wrote: > >> Yes, this test case fail currently and success with the modification. >> If there is another same test case, ignore this patch is OK. >> > > Thank you for the test. I applied the linked patch by Chandra as it was > already reviewed and applied your unit test and also added you in AUTHORS. > I did look at your second patch of the series. Please read CodingStyle.md > for any future contributions. > I forgot to mention that I did add the following incremental to your test to make the test case more realistic. (Also, we still have a bug wherein we allow the router to respond to ICMP messages for a SNAT IP. This can be racy.) @@ -243,19 +243,19 @@ ovn-nbctl lsp-add alice alice1 \ # Add a SNAT rule ovn-nbctl -- --id=@nat create nat type="snat" logical_ip=192.168.1.2 \ -external_ip=20.0.0.2 -- add logical_router R2 nat @nat +external_ip=172.16.1.1 -- add logical_router R2 nat @nat # South-North SNAT: 'foo1' pings 'alice1'. But 'alice1' receives traffic -# from 20.0.0.2 +# from 172.16.1.1 NS_CHECK_EXEC([foo1], [ping -q -c 3 -i 0.3 -w 2 172.16.1.2 | FORMAT_PING], \ [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms ]) # We verify that SNAT indeed happened via 'dump-conntrack' command. -AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(20.0.0.2) | \ +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.1) | \ sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl -icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=20.0.0.2,id=),zon +icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=172.16.1.1,id=),z ]) > > >> >> On 2016/7/28 21:31, Guru Shetty wrote: >> >>> >>> >>> On 27 July 2016 at 23:30, Dongjun >> do...@dtdream.com>> wrote: >>> >>> Signed-off-by: Dongjun mailto:do...@dtdream.com >>> >> >>> >>> >>> Usually, we have a test with the corresponding code change. Can you have >>> a look at https://www.mail-archive.com/dev@openvswitch.org/msg66099.html >>> and see whether you are happy with the code change? >>> >>> --- >>> tests/system-ovn.at <http://system-ovn.at> | 106 >>> +++- >>> 1 file changed, 105 insertions(+), 1 deletion(-) >>> mode change 100644 => 100755 tests/system-ovn.at >>> <http://system-ovn.at> >>> >>> diff --git a/tests/system-ovn.at <http://system-ovn.at> >>> b/tests/system-ovn.at <http://system-ovn.at> >>> old mode 100644 >>> new mode 100755 >>> index 13f380f..cb50fd4 >>> --- a/tests/system-ovn.at <http://system-ovn.at> >>> +++ b/tests/system-ovn.at <http://system-ovn.at> >>> >>> @@ -1,4 +1,4 @@ >>> -AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, NAT]) >>> +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, SNAT and >>> DNAT]) >>> AT_KEYWORDS([ovnnat]) >>> >>> CHECK_CONNTRACK() >>> @@ -168,6 +168,110 @@ as >>> OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d"]) >>> AT_CLEANUP >>> >>> +AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, easy SNAT]) >>> +AT_KEYWORDS([ovnnat]) >>> + >>> +CHECK_CONNTRACK() >>> +ovn_start >>> +OVS_TRAFFIC_VSWITCHD_START() >>> +ADD_BR([br-int]) >>> + >>> +# Set external-ids in br-int needed for ovn-controller >>> +ovs-vsctl \ >>> +-- set Open_vSwitch . external-ids:system-id=hv1 \ >>> +-- set Open_vSwitch . >>> external-ids:ovn-remote=unix:$ovs_base/ovn-sb/ovn-sb.sock \ >>> +-- set Open_vSwitch . external-ids:ovn-encap-type=geneve \ >>> +-- set Open_vSwitch . external-ids:ovn-encap-ip=169.0.0.1 \ >>> +-- set bridge br-int fail-mode=secure >>> other-config:disable-in-band=true >>> + >>> +# Start ovn-controller >>> +start_daemon ovn-controller >>> + >>> +# Logical network: >>> +# Two LRs - R1 and R2 that are connected to each other via LS "join" >>> +# in 20.0.0.0/24 <http://20.0.0.0/24> network. R1 has switchess >>> foo (192.168.1.0/24 <http://192.168.1.0/24>) connected to it. >>>
Re: [ovs-dev] [PATCH v4] Windows: Local named pipe implementation
On 26 July 2016 at 12:57, Alin Serdean wrote: > Currently in the case of command line arguments punix/unix, on Windows > we create a file, write a TCP port number to connect. This is a security > concern. > > This patch adds support for the command line arguments punix/unix trying > to mimic AF_UNIX behind a local named pipe. > > This patch drops the TCP socket implementation behind command line > arguments punix/unix and switches to the local named pipe implementation. > > Since we do not write anything to the file created by the punix/unix > arguments, switch tests to plain file existence. > > Man pages and code comments have been updated. > > Signed-off-by: Alin Gabriel Serdean > Acked-by: Paul Boca > Thank you for this. This is a very useful addition. Does adding this commit fail any currently running unit tests on Windows? I have a few trivial comments below. Does the following incremental for the documentation make sense? If so, add them. diff --git a/lib/unixctl.man b/lib/unixctl.man index b27ec85..a7967c4 100644 --- a/lib/unixctl.man +++ b/lib/unixctl.man @@ -11,8 +11,7 @@ On Windows a local named pipe is used to listen for runtime management commands. A file is created in the absolute path as pointed by \fIsocket\fR or if \fB\-\-unixctl\fR is not used at all, a file is created as \fB\*(PN.ctl\fR in the configured \fIOVS_RUNDIR\fR directory. -The file exists just to mimic the behavior of a Unix socket domain -socket. +The file exists just to mimic the behavior of a Unix domain socket. .IP Specifying \fBnone\fR for \fIsocket\fR disables the control socket feature. diff --git a/ovsdb/remote-active.man b/ovsdb/remote-active.man index eb1c827..8cce6ea 100644 --- a/ovsdb/remote-active.man +++ b/ovsdb/remote-active.man @@ -14,5 +14,5 @@ square brackets, e.g.: \fBtcp:[::1]:6640\fR. .IP "\fBunix:\fIfile\fR" On POSIX, connect to the Unix domain server socket named \fIfile\fR. .IP -On Windows, connect to a local named pipe and a file is created in the -path \fIfile\fR to mimic the behavior of a Unix domain socket. +On Windows, connect to a local named pipe that is represented by a file created +in the path \fIfile\fR to mimic the behavior of a Unix domain socket. diff --git a/ovsdb/remote-passive.man b/ovsdb/remote-passive.man index f2eddd7..5da2de8 100644 --- a/ovsdb/remote-passive.man +++ b/ovsdb/remote-passive.man @@ -22,5 +22,5 @@ an IPv6 address, then wrap \fIip\fR with square brackets, e.g.: On POSIX, listen on the Unix domain server socket named \fIfile\fR for a connection. .IP -On Windows, listen on a local named pipe. A file is created in the +On Windows, listen on a local named pipe. A file is created in the path \fIfile\fR to mimic the behavior of a Unix domain socket. --- > v4: improve spelling in man pages > v3: squash commits update documentation and code comments > v2: Address comments, fix handle leaks. > --- > lib/automake.mk | 1 + > lib/stream-tcp.c | 115 -- > lib/stream-windows.c | 587 > +++ > lib/unixctl.c| 5 +- > lib/unixctl.man | 11 +- > lib/vconn-active.man | 3 +- > ovsdb/remote-active.man | 4 +- > ovsdb/remote-passive.man | 4 +- > tests/ovsdb-server.at| 6 +- > 9 files changed, 606 insertions(+), 130 deletions(-) > create mode 100644 lib/stream-windows.c > > diff --git a/lib/automake.mk b/lib/automake.mk > index 71c9d41..9067c95 100644 > --- a/lib/automake.mk > +++ b/lib/automake.mk > @@ -293,6 +293,7 @@ lib_libopenvswitch_la_SOURCES += \ > lib/latch-windows.c \ > lib/route-table-stub.c \ > lib/if-notifier-stub.c \ > + lib/stream-windows.c \ > lib/strsep.c > else > lib_libopenvswitch_la_SOURCES += \ > .snip... > new file mode 100644 > index 000..88fe17d > --- /dev/null > +++ b/lib/stream-windows.c > @@ -0,0 +1,587 @@ > +/* > + * Copyright (c) 2016 Cloudbase Solutions Srl > + * > + * Licensed under the Apache License, Version 2.0 (the "License"); > + * you may not use this file except in compliance with the License. > + * You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "packets.h" > +#include "poll-loop.h" > +#include "socket-util.h" > +#include "dirs.h" > +#include "util.h" > +#include "stream-provider.h" > +#include "openvswitch/vlog.h" > Do you need all the headers above? > + > +VLOG_DEFINE_THIS_MODULE(stream_windo
Re: [ovs-dev] [PATCH] system-ovn.at: Fix ICMP conntrack output.
On 28 July 2016 at 10:48, Joe Stringer wrote: > Recent changes to the dump-conntrack command provide more info > (type,code), but the system-ovn tests weren't updated for this. > Update the tests. > > Signed-off-by: Joe Stringer > Acked-by: Gurucharan Shetty > --- > tests/system-ovn.at | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/tests/system-ovn.at b/tests/system-ovn.at > index fd091b83d667..2a94d68a6e60 100755 > --- a/tests/system-ovn.at > +++ b/tests/system-ovn.at > @@ -111,7 +111,7 @@ NS_CHECK_EXEC([alice1], [ping -q -c 3 -i 0.3 -w 2 > 30.0.0.2 | FORMAT_PING], \ > # Check conntrack entries. > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.2) | \ > sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl > > -icmp,orig=(src=172.16.1.2,dst=30.0.0.2,id=),reply=(src=192.168.1.2,dst=172.16.1.2,id=),zone= > > +icmp,orig=(src=172.16.1.2,dst=30.0.0.2,id=,type=8,code=0),reply=(src=192.168.1.2,dst=172.16.1.2,id=,type=0,code=0),zone= > ]) > > # South-North SNAT: 'bar1' pings 'alice1'. But 'alice1' receives traffic > @@ -124,7 +124,7 @@ NS_CHECK_EXEC([bar1], [ping -q -c 3 -i 0.3 -w 2 > 172.16.1.2 | FORMAT_PING], \ > # We verify that SNAT indeed happened via 'dump-conntrack' command. > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(30.0.0.1) | \ > sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl > > -icmp,orig=(src=192.168.2.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=30.0.0.1,id=),zone= > > +icmp,orig=(src=192.168.2.2,dst=172.16.1.2,id=,type=8,code=0),reply=(src=172.16.1.2,dst=30.0.0.1,id=,type=0,code=0),zone= > ]) > > # Add static routes to handle east-west NAT. > @@ -143,14 +143,14 @@ NS_CHECK_EXEC([bar1], [ping -q -c 3 -i 0.3 -w 2 > 30.0.0.2 | FORMAT_PING], \ > # 30.0.0.2 to R2, it hits the DNAT rule and converts 30.0.0.2 to > 192.168.1.2 > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(30.0.0.2) | \ > sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl > > -icmp,orig=(src=192.168.2.2,dst=30.0.0.2,id=),reply=(src=192.168.1.2,dst=192.168.2.2,id=),zone= > > +icmp,orig=(src=192.168.2.2,dst=30.0.0.2,id=,type=8,code=0),reply=(src=192.168.1.2,dst=192.168.2.2,id=,type=0,code=0),zone= > ]) > > # As we have a SNAT rule that converts 192.168.2.2 to 30.0.0.1, the > source is > # SNATted and 'foo1' receives it. > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(30.0.0.1) | \ > sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl > > -icmp,orig=(src=192.168.2.2,dst=192.168.1.2,id=),reply=(src=192.168.1.2,dst=30.0.0.1,id=),zone= > > +icmp,orig=(src=192.168.2.2,dst=192.168.1.2,id=,type=8,code=0),reply=(src=192.168.1.2,dst=30.0.0.1,id=,type=0,code=0),zone= > ]) > > OVS_APP_EXIT_AND_WAIT([ovn-controller]) > @@ -255,7 +255,7 @@ NS_CHECK_EXEC([foo1], [ping -q -c 3 -i 0.3 -w 2 > 172.16.1.2 | FORMAT_PING], \ > # We verify that SNAT indeed happened via 'dump-conntrack' command. > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.1) | \ > sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl > > -icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=172.16.1.1,id=),zone= > > +icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=,type=8,code=0),reply=(src=172.16.1.2,dst=172.16.1.1,id=,type=0,code=0),zone= > ]) > > OVS_APP_EXIT_AND_WAIT([ovn-controller]) > -- > 2.9.0 > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v4] ovn-northd, tests: Adding IPAM to ovn-northd.
On 28 July 2016 at 11:37, Ben Pfaff wrote:
> On Wed, Jul 27, 2016 at 11:28:24AM -0700, Nimay Desai wrote:
> > Added an IPv4 and MAC addresses management system to ovn-northd. When a
> logical
> > switch's other_config:subnet field is set, logical ports attached to that
> > switch that have the keyword "dynamic" in their addresses column will
> > automatically be allocated a globally unique MAC address/unused IPv4
> address
> > within the provided subnet. The allocated address will populate the
> > dynamic_addresses column. This can be useful for a user who wants to
> deploy
> > many VM's or containers with networking capabilities, but does not care
> about
> > the specific MAC/IPv4 addresses that are assigned.
> >
> > Added tests in ovn.at for ipam.
> >
> > Signed-off-by: Nimay Desai
>
> The code uses the abbreviations 'ipam' and 'macam' a lot. IPAM is a
> fairly common term but I don't know what macam stands for. I think it
> would be a good idea to explain both terms in comments.
>
Do you think this incremental is helpful?
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 02b26bb..18756e9 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -62,8 +62,8 @@ static const char *default_sb_db(void);
#define MAC_ADDR_PREFIX 0x0A00ULL
#define MAC_ADDR_SPACE 0xff
-/* MAC address table of "struct eth_addr"s, that holds the MAC addresses
- * allocated by the ipam. */
+/* MAC address management (macam) table of "struct eth_addr"s, that holds
the
+ * MAC addresses allocated by the OVN ipam module. */
static struct hmap macam = HMAP_INITIALIZER(&macam);
^L
/* Pipeline stages. */
@@ -879,6 +879,12 @@ static void
build_ipam(struct northd_context *ctx, struct hmap *datapaths,
struct hmap *ports)
{
+/* IPAM generally stands for IP address management. In non-virtualized
+ * world, MAC addresses come with the hardware. But, with virtualized
+ * workloads, they need to be assigned and managed. This function
+ * does both IP address management (ipam) and MAC address management
+ * (macam). */
+
if (!ctx->ovnnb_txn) {
return;
}
>
> Here are some suggested improvements. The code improvements are, I
> hope, self-explanatory. The changes to the documentation are mainly to
> make it clear that ovn-northd does the work. (I find it really
> confusing when documentation says that something happens, but not what
> does it, because then you have to assume or guess what does it and it's
> easy to guess wrong.)
>
> I'm done with review. I'll leave it to Guru to shepherd this in though
> since he's been guiding the work.
>
> Acked-by: Ben Pfaff
>
> --8<--cut here-->8--
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 25af707..d5cbd37 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -867,21 +867,9 @@ ipam_allocate_addresses(struct ovn_datapath *od,
> struct ovn_port *op,
> ipam_insert_ip(od, ip, false);
> ipam_insert_mac(&mac, false);
>
> -/* Convert IP to string form. */
> -struct ds ip_ds;
> -ds_init(&ip_ds);
> -ds_put_format(&ip_ds, IP_FMT, IP_ARGS(htonl(ip)));
> -
> -/* Convert MAC to string form. */
> -struct ds mac_ds;
> -ds_init(&mac_ds);
> -ds_put_format(&mac_ds, ETH_ADDR_FMT, ETH_ADDR_ARGS(mac));
> -
> -char *new_addr = xasprintf("%s %s", mac_ds.string, ip_ds.string);
> -nbrec_logical_switch_port_set_dynamic_addresses(op->nbsp,
> -(const char*)
> new_addr);
> -ds_destroy(&ip_ds);
> -ds_destroy(&mac_ds);
> +char *new_addr = xasprintf(IP_FMT" "ETH_ADDR_FMT,
> + IP_ARGS(htonl(ip)), ETH_ADDR_ARGS(mac));
> +nbrec_logical_switch_port_set_dynamic_addresses(op->nbsp, new_addr);
> free(new_addr);
>
> return true;
> diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> index 249d3c5..85aa2d3 100644
> --- a/ovn/ovn-nb.xml
> +++ b/ovn/ovn-nb.xml
> @@ -125,11 +125,12 @@
>
>
>
> -If set, logical ports that are attached to this switch that have
> the
> -"dynamic" keyword in their addresses column will automatically be
> -allocated a globally unique MAC address/unused IPv4 address
> within the
> -provided IPv4 subnet. The allocated address will populate the
> - column.
> +Set this to an IPv4 subnet, e.g. 192.168.0.0/24, to
> enable
> +ovn-northd to automatically assign IP addresses
> within
> +that subnet. Use the dynamic keyword in the +table="Logical_Switch_Port"/> table's table="Logical_Switch_Port"
> +column="addresses"/> column to request dynamic address assignment
> for a
> +particular port.
>
>
>
> @@ -439,22 +440,23 @@
>
>dynamic
>
> -This indicates that the logical port should be automatically
> -assi
Re: [ovs-dev] [PATCH v2 1/7] datapath-windows: Explicitly name vport related event to vportEvent
On 25 July 2016 at 17:04, Sairam Venugopal wrote:
> OVS_EVENT_ENTRY currently handles only Vport related events. Updating the
> name of the struct to OVS_VPORT_EVENT_ENTRY. Remove OVS_EVENT_STATUS since
> it's currently not in use. Update the datapath to refer to events as
> vportEvents. This will aid in the introduction of other events.
>
> v2: Squash 1/9 and 3/9 into one commit. Added Acked-by.
>
I applied the series, thank you! Please note that you should not add
versioning information in the commit message. When you do a 'git am' of
this patch series, each commit has some versioning information. If they end
up in the eventual commit history, it does not add any useful information,
and looks wrong. You should add any of this versioning information below
the "---". You can look at some other patches in the mailing list for
examples. You can also try 'git am' ing your own patch to see the end
result.
>
> Signed-off-by: Sairam Venugopal
> Acked-By: Yin Lin
> Acked-by: Alin Gabriel Serdean
> ---
> datapath-windows/ovsext/Datapath.c | 7 ---
> datapath-windows/ovsext/DpInternal.h | 10 ++
> datapath-windows/ovsext/Event.c | 10 +-
> datapath-windows/ovsext/Event.h | 7 ---
> datapath-windows/ovsext/Vport.c | 12 ++--
> 5 files changed, 21 insertions(+), 25 deletions(-)
>
> diff --git a/datapath-windows/ovsext/Datapath.c
> b/datapath-windows/ovsext/Datapath.c
> index 4f47be5..e4d6ab1 100644
> --- a/datapath-windows/ovsext/Datapath.c
> +++ b/datapath-windows/ovsext/Datapath.c
> @@ -1582,7 +1582,7 @@ MapIrpOutputBuffer(PIRP irp,
> */
> static NTSTATUS
> OvsPortFillInfo(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
> -POVS_EVENT_ENTRY eventEntry,
> +POVS_VPORT_EVENT_ENTRY eventEntry,
> PNL_BUFFER nlBuf)
> {
> NTSTATUS status;
> @@ -1659,7 +1659,7 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
> usrParamsCtx,
> #endif
> NL_BUFFER nlBuf;
> NTSTATUS status;
> -OVS_EVENT_ENTRY eventEntry;
> +OVS_VPORT_EVENT_ENTRY eventEntry;
>
> ASSERT(usrParamsCtx->devOp == OVS_READ_DEV_OP);
>
> @@ -1675,7 +1675,8 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
> usrParamsCtx,
> NlBufInit(&nlBuf, usrParamsCtx->outputBuffer,
> usrParamsCtx->outputLength);
>
> /* remove an event entry from the event queue */
> -status = OvsRemoveEventEntry(usrParamsCtx->ovsInstance, &eventEntry);
> +status = OvsRemoveVportEventEntry(usrParamsCtx->ovsInstance,
> + &eventEntry);
> if (status != STATUS_SUCCESS) {
> /* If there were not elements, read should return no data. */
> status = STATUS_SUCCESS;
> diff --git a/datapath-windows/ovsext/DpInternal.h
> b/datapath-windows/ovsext/DpInternal.h
> index 42b5ec9..8abe61d 100644
> --- a/datapath-windows/ovsext/DpInternal.h
> +++ b/datapath-windows/ovsext/DpInternal.h
> @@ -328,19 +328,13 @@ enum {
> };
>
>
> -typedef struct _OVS_EVENT_ENTRY {
> +typedef struct _OVS_VPORT_EVENT_ENTRY {
> UINT32 portNo;
> OVS_VPORT_TYPE ovsType;
> UINT32 upcallPid;
> CHAR ovsName[OVS_MAX_PORT_NAME_LENGTH];
> UINT32 type;
> -} OVS_EVENT_ENTRY, *POVS_EVENT_ENTRY;
> -
> -
> -typedef struct _OVS_EVENT_STATUS {
> -uint32_t numberEntries;
> -OVS_EVENT_ENTRY eventEntries[0];
> -} OVS_EVENT_STATUS, *POVS_EVENT_STATUS;
> +} OVS_VPORT_EVENT_ENTRY, *POVS_VPORT_EVENT_ENTRY;
>
> #pragma pack(pop)
>
> diff --git a/datapath-windows/ovsext/Event.c
> b/datapath-windows/ovsext/Event.c
> index f9bea7f..8c7c3ec 100644
> --- a/datapath-windows/ovsext/Event.c
> +++ b/datapath-windows/ovsext/Event.c
> @@ -109,7 +109,7 @@ OvsCleanupEvent(POVS_OPEN_INSTANCE instance)
> *
> --
> */
> VOID
> -OvsPostEvent(POVS_EVENT_ENTRY event)
> +OvsPostVportEvent(POVS_VPORT_EVENT_ENTRY event)
> {
> POVS_EVENT_QUEUE_ELEM elem;
> POVS_EVENT_QUEUE queue;
> @@ -141,7 +141,7 @@ OvsPostEvent(POVS_EVENT_ENTRY event)
> return;
> }
>
> -RtlCopyMemory(&elem->event, event, sizeof elem->event);
> +RtlCopyMemory(&elem->vportEvent, event, sizeof elem->vportEvent);
> InsertTailList(&queue->elemList, &elem->link);
> queue->numElems++;
> OVS_LOG_INFO("Queue: %p, numElems: %d",
> @@ -409,8 +409,8 @@ unlock:
> *
> --
> */
> NTSTATUS
> -OvsRemoveEventEntry(POVS_OPEN_INSTANCE instance,
> -POVS_EVENT_ENTRY entry)
> +OvsRemoveVportEventEntry(POVS_OPEN_INSTANCE instance,
> + POVS_VPORT_EVENT_ENTRY entry)
> {
> NTSTATUS status = STATUS_UNSUCCESSFUL;
> POVS_EVENT_QUEUE queue;
> @@ -427,7 +427,7 @@ OvsRemoveEventEntry(POVS_OPEN_INSTANCE instance,
>
> if (queue->numElems) {
> elem = (POVS_EVENT_QUEUE_ELEM)RemoveHeadList(&queue->elemList);
> -
Re: [ovs-dev] [PATCH V8 00/17] Fix and enable Python tests on Windows
Thank you for the series. If I apply this series, 2 unit tests around python fail on Linux. Please see whats going on. On 26 July 2016 at 04:49, Paul Boca wrote: > This series of patches ports the python damons to Windows and > fixes the tests to work on Windows. > There are still some python tests that fail on Windows, from which > some are failing on Linux too. > The patches in this series are dependent and are related to > python tests on Windows. > > V2: Fixes more porting issues for Windows > V3: Fixes all python tests > This series was extended from 16 to 21 patches in order to solve > all python related tests in one series. > To run the tests on windows 'pypiwin32' is required to be > installed for both Python2 and Python3 (pip install pypiwin32). > V4: Rebased the entire series, if didn't apply anymore. > Fixed delete of PID file on exit of python daemon, this leaded to > removal of patch "python tests: Don't check if the PID file > gets deleted". > V5: Removed "windows: Added lockf function and lock PID file to be sent > individually and removed already merged patches from this series. > V6: Fixed some issues in porting the python daemon and enabled vlog/close > tests. > V7: Addressed the required changes after review. > Fixed flake8 errors, tested on Linux with flake8 and hacking libs > installed. > V8: Splitted python daemon in different files, one wrapper and 2 files, > each containing specific implementation for Windows/Linux > Addressed requested changes from previous version. > > Paul-Daniel Boca (17): > python tests: Implemented signal.alarm for Windows > python tests: Register signal handlers only on supported types on > Windows > python tests: Fixed ctl file name for Windows > python tests: Fixed unixctl python tests for Windows > python tests: Added fcntl module for Windows > python tests: Skip IPsec test on Windows > python tests: Skip TCP6 idl tests on Windows > python tests: Skip python tests on Windows where POSIX pid is used > python tests: Fixed OSError not iterable on Windows > python tests: Fixed abs_file_name function for Windows > python tests: Ported UNIX sockets to Windows > python tests: Prepare porting Python daemon on Windows > python tests: Ported Python daemon to Windows > at tests: Allow Python tests to be run on Windows > python tests: Ignore stderr output > python tests: Skip ovn-controller-vtep tests on Windows > tests: Skip vlog tests that try to move opened file > > INSTALL.Windows.md | 1 + > python/automake.mk | 3 + > python/ovs/daemon.py | 491 ++--- > python/ovs/daemon_unix.py | 530 > > python/ovs/daemon_windows.py | 535 > + > python/ovs/fatal_signal.py | 44 +++- > python/ovs/fcntl_win.py| 42 > python/ovs/jsonrpc.py | 4 + > python/ovs/poller.py | 7 + > python/ovs/socket_util.py | 56 - > python/ovs/stream.py | 9 +- > python/ovs/unixctl/__init__.py | 11 +- > python/ovs/unixctl/server.py | 16 +- > python/ovs/util.py | 6 +- > python/ovs/vlog.py | 12 + > tests/appctl.py| 4 +- > tests/atlocal.in | 7 - > tests/daemon-py.at | 14 ++ > tests/ovn-controller-vtep.at | 2 +- > tests/ovs-monitor-ipsec.at | 1 + > tests/ovsdb-idl.at | 1 + > tests/test-daemon.py | 4 +- > tests/test-ovsdb.py| 4 +- > tests/test-unix-socket.py | 3 +- > tests/unixctl-py.at| 15 +- > tests/vlog.at | 12 +- > 26 files changed, 1320 insertions(+), 514 deletions(-) > create mode 100644 python/ovs/daemon_unix.py > create mode 100644 python/ovs/daemon_windows.py > create mode 100644 python/ovs/fcntl_win.py > > -- > 2.7.2.windows.1 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
On 2 August 2016 at 10:23, Mickey Spiegel wrote: > On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball wrote: > > > > > > > On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant wrote: > > > >> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel > >> wrote: > >> > >> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel > > >> > wrote: > >> > > > >> > > -"dev" wrote: - > >> > >> To: Mickey Spiegel > >> > >> From: Russell Bryant > >> > >> Sent by: "dev" > >> > >> Date: 07/29/2016 10:02AM > >> > >> Cc: ovs dev > >> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage > >> > >> > >> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel < > >> mickeys@gmail.com > >> > > > >> > >> wrote: > >> > >> > >> > >>> > >> > >>> This patch adds a second logical switch ingress ACL stage, and > >> > >>> correspondingly a second logical switch egress ACL stage. This > >> > >>> allows for more than one ACL-based feature to be applied in the > >> > >>> ingress and egress logical switch pipelines. The features > >> > >>> driving the different ACL stages may be configured by different > >> > >>> users, for example an application deployer managing security > >> > >>> groups and a network or security admin configuring network ACLs > >> > >>> or firewall rules. > >> > >>> > >> > >>> Each ACL stage is self contained. The "action" for the > >> > >>> highest-"priority" matching row in an ACL stage determines a > >> > >>> packet's treatment. A separate "action" will be determined in > >> > >>> each ACL stage, according to the ACL rules configured for that > >> > >>> ACL stage. The "priority" values are only relevant within the > >> > >>> context of an ACL stage. > >> > >>> > >> > >>> ACL rules that do not specify an ACL stage are applied to the > >> > >>> default "acl" stage. > >> > >>> > >> > >>> Signed-off-by: Mickey Spiegel > >> > >> > >> > >> > >> > >> Could you expand on why priorities in a single stage aren't enough > to > >> > >> satisfy the use case? > >> > > > >> > > If two features are configured independently with a mix of > >> > > prioritized allow and drop rules, then with a single stage, a > >> > > new set of ACL rules must be produced that achieves the same > >> > > behavior. This is sometimes referred to as an "ACL merge" > >> > > algorithm, for example: > >> > > > >> > > >> > http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514 > >> > > > >> > > In the worst case, for example when the features act on different > >> > > packet fields (e.g. one on IP address and another on L4 port), > >> > > the number of rules required can approach > >> > > (# of ACL1 rules) * (# of ACL2 rules). > >> > > > >> > > While it is possible to code up such an algorithm, it adds > >> > > significant complexity and complicates whichever layer > >> > > implements the merge algorithm, either OVN or the CMS above. > >> > > > >> > > By using multiple independent pipeline stages, all of this > >> > > software complexity is avoided, achieving the proper result > >> > > in a simple and straightforward manner. > >> > > > >> > > Recent network hardware ASICs tend to have around 8 or 10 ACL > >> > > stages, though they tend to evaluate these in parallel given > >> > > all the emphasis on low latency these days. > >> > > >> > Throwing in an example to illustrate the difference between one > >> > ACL stage and two ACL stages: > >> > > >> > If two separate ACL stages: > >> > Feature 1 > >> > acl from-lport 100 (tcp == 80) allow-related > >> > acl from-lport 100 (tcp == 8080) allow-related > >> > acl from-lport 100 (udp) allow-related > >> > acl from-lport 100 (ip4.src == 10.1.1.0/24 && tcp) allow-related > >> > > >> > Feature 2 > >> > acl2 from-lport 300 (ip4.dst == 172.16.10.0/24) allow-related > >> > acl2 from-lport 300 (ip4.dst == 192.168.20.0/24) allow-related > >> > acl2 from-lport 200 (ip4.dst == 172.16.0.0/20) drop > >> > acl2 from-lport 200 (ip4.dst == 192.168.0.0/16) drop > >> > acl2 from-lport 100 (ip4.dst == 172.16.0.0/16) allow-related > >> > > >> > Combined in one stage, to get the equivalent behavior, this would > >> require: > >> > from-lport 300 (ip4.dst == 172.16.10.0/24 && tcp == 80) > allow-related > >> > from-lport 300 (ip4.dst == 172.16.10.0/24 && tcp == 8080) > >> allow-related > >> > from-lport 300 (ip4.dst == 172.16.10.0/24 && udp) allow-related > >> > from-lport 300 (ip4.dst == 172.16.10.0/24 && ip4.src == 10.1.1.0/24 > && > >> > tcp) allow-related > >> > from-lport 300 (ip4.dst == 192.168.20.0/24 && tcp == 80) > allow-related > >> > from-lport 300 (ip4.dst == 192.168.20.0/24 && tcp == 8080) > >> allow-related > >> > from-lport 300 (ip4.dst == 192.168.20.0/24 && udp) allow-related > >> > from-lport 300 (ip4.dst == 192.168.20.0/24 && ip4.src == 10.1.1.0/24 > >> && > >> > tcp) allow-related > >> > from-lport 200 (ip4.dst == 172.16.0.0/20) drop > >> > from-lport 200 (ip4.dst == 192.168.0.0/16) drop > >> > from-lport 100 (ip4.dst == 172.16.0.0/16
Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
On 2 August 2016 at 12:01, Russell Bryant wrote: > > On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty wrote: > >> The 2 ct_commit for deletion of firewall rules will likely be tricky. This >> will need unit tests. >> > > I don't think I understand the concern. Can you expand a bit on what you > mean by "2 ct_commit for deletion of firewall rules"? > My memory on how ct_commit(ct_label=1) works is a little hazy. There are 2 stages now. So whenever a firewall rule is deleted for an established connection, the default ct_commit(ct_label=1) will get hit and the connection is dropped. The same thing happens in the second stage for any removed firewall rule. In the second stage when a firewall rule is deleted ct_label is also set which will reflect in the first stage. Does not this cause confusion with the logic? > > > -- > Russell Bryant > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
On 2 August 2016 at 12:27, Russell Bryant wrote: > > > On Tue, Aug 2, 2016 at 3:17 PM, Guru Shetty wrote: > >> >> >> On 2 August 2016 at 12:01, Russell Bryant wrote: >> >>> >>> On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty wrote: >>> >>>> The 2 ct_commit for deletion of firewall rules will likely be tricky. >>>> This >>>> will need unit tests. >>>> >>> >>> I don't think I understand the concern. Can you expand a bit on what >>> you mean by "2 ct_commit for deletion of firewall rules"? >>> >> >> My memory on how ct_commit(ct_label=1) works is a little hazy. There are >> 2 stages now. So whenever a firewall rule is deleted for an established >> connection, the default ct_commit(ct_label=1) will get hit and the >> connection is dropped. The same thing happens in the second stage for any >> removed firewall rule. In the second stage when a firewall rule is deleted >> ct_label is also set which will reflect in the first stage. Does not this >> cause confusion with the logic? >> > > Setting ct_label back to 0 only happens in the stateful table. That > ct_commit will only occur if none of the ACL stages think the packet should > be dropped. I think it's OK. > I see. I think we should still consider unit tests now. Userspace datapath has ct_commit now (it still can't do NAT). That should ideally work. If that does not work, we should consider adding tests to system-ovn.at > > -- > Russell Bryant > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v7] Windows: Local named pipe implementation
On 2 August 2016 at 11:19, Alin Serdean
wrote:
> Currently in the case of command line arguments punix/unix, on Windows
> we create a file, write a TCP port number to connect. This is a security
> concern.
>
> This patch adds support for the command line arguments punix/unix trying
> to mimic AF_UNIX behind a local named pipe.
>
> This patch drops the TCP socket implementation behind command line
> arguments punix/unix and switches to the local named pipe implementation.
>
> Since we do not write anything to the file created by the punix/unix
> arguments, switch tests to plain file existence.
>
> Man pages and code comments have been updated.
>
> Signed-off-by: Alin Gabriel Serdean
> Acked-by: Paul Boca
>
Thank you, applied.
> ---
> v7: clarify that on 'unix' argument, we do not create a file
> v6: resubmit for patchwork
> v5: fix coding style
> v4: improve spelling in man pages
> v3: squash commits update documentation and code comments
> v2: Address comments, fix handle leaks.
> ---
> lib/automake.mk | 1 +
> lib/stream-tcp.c | 115 --
> lib/stream-windows.c | 581
> +++
> lib/unixctl.c| 5 +-
> lib/unixctl.man | 11 +-
> lib/vconn-active.man | 4 +-
> ovsdb/remote-active.man | 7 +-
> ovsdb/remote-passive.man | 4 +-
> tests/ovsdb-server.at| 6 +-
> 9 files changed, 603 insertions(+), 131 deletions(-)
> create mode 100644 lib/stream-windows.c
>
> diff --git a/lib/automake.mk b/lib/automake.mk
> index 646306d..97c83e9 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -302,6 +302,7 @@ lib_libopenvswitch_la_SOURCES += \
> lib/latch-windows.c \
> lib/route-table-stub.c \
> lib/if-notifier-stub.c \
> + lib/stream-windows.c \
> lib/strsep.c
> else
> lib_libopenvswitch_la_SOURCES += \
> diff --git a/lib/stream-tcp.c b/lib/stream-tcp.c
> index 2b57ca7..1749fad 100644
> --- a/lib/stream-tcp.c
> +++ b/lib/stream-tcp.c
> @@ -74,64 +74,6 @@ const struct stream_class tcp_stream_class = {
> NULL, /* run_wait */
> NULL, /* wait */
> };
> -
> -#ifdef _WIN32
> -#include "dirs.h"
> -
> -static int
> -windows_open(const char *name, char *suffix, struct stream **streamp,
> - uint8_t dscp)
> -{
> -int error, port;
> -FILE *file;
> -char *suffix_new, *path;
> -
> -/* If the path does not contain a ':', assume it is relative to
> - * OVS_RUNDIR. */
> -if (!strchr(suffix, ':')) {
> -path = xasprintf("%s/%s", ovs_rundir(), suffix);
> -} else {
> -path = xstrdup(suffix);
> -}
> -
> -file = fopen(path, "r");
> -if (!file) {
> -error = errno;
> -VLOG_DBG("%s: could not open %s (%s)", name, suffix,
> - ovs_strerror(error));
> -return error;
> -}
> -
> -error = fscanf(file, "%d", &port);
> -if (error != 1) {
> -VLOG_ERR("failed to read port from %s", suffix);
> -fclose(file);
> -return EINVAL;
> -}
> -fclose(file);
> -
> -suffix_new = xasprintf("127.0.0.1:%d", port);
> -
> -error = tcp_open(name, suffix_new, streamp, dscp);
> -
> -free(suffix_new);
> -free(path);
> -return error;
> -}
> -
> -const struct stream_class windows_stream_class = {
> -"unix", /* name */
> -false, /* needs_probes */
> -windows_open, /* open */
> -NULL, /* close */
> -NULL, /* connect */
> -NULL, /* recv */
> -NULL, /* send */
> -NULL, /* run */
> -NULL, /* run_wait */
> -NULL, /* wait */
> -};
> -#endif
>
> /* Passive TCP. */
>
> @@ -198,60 +140,3 @@ const struct pstream_class ptcp_pstream_class = {
> NULL,
> NULL,
> };
> -
> -#ifdef _WIN32
> -static int
> -pwindows_open(const char *name, char *suffix, struct pstream **pstreamp,
> - uint8_t dscp)
> -{
> -int error;
> -char *suffix_new, *path;
> -FILE *file;
> -struct pstream *listener;
> -
> -suffix_new = xstrdup("0:127.0.0.1");
> -
> -/* If the path does not contain a ':', assume it is relative to
> - * OVS_RUNDIR. */
> -if (!strchr(suffix, ':')) {
> -path = xasprintf("%s/%s", ovs_rundir(), suffix);
> -} else {
> -path = xstrdup(suffix);
> -}
> -
> -error = new_pstream(suffix_new, name, pstreamp, dscp, path, false);
> -if (error) {
> -goto exit;
> -}
> -listener = *pstreamp;
> -
> -file = fopen(path, "w");
> -if (!file) {
> -error = errno;
> -VLOG_DBG("could not open %s (%s)", path, ovs_strerror(error));
> -goto exit;
> -}
> -
> -fprintf(file, "%d\n", ntohs(listener->bound_port));
> -if (fflush(file) == EOF) {
> -
Re: [ovs-dev] [PATCH V11 01/17] python tests: Implemented signal.alarm for Windows
On 2 August 2016 at 10:45, Paul Boca wrote:
> signal.alarm is not available in Windows and would trigger an exception
> when called. Implemented this to mentain compatibility between
> Windows and Linux for python tests.
>
> Signed-off-by: Paul-Daniel Boca
> Acked-by: Alin Gabriel Serdean
> ---
> V2: No changes
> V3: Code styling changes
> V4: No changes
> V5: No changes
> V6: No changes
> V7: Added function signal_alarm in fatal_signal.py to avoid
> duplicating code
> V8: No changes
> V9: No changes
> V10: No changes
> V11: No changes
> ---
> python/ovs/fatal_signal.py | 24 +++-
> tests/appctl.py| 4 ++--
> tests/test-ovsdb.py| 4 ++--
> tests/test-unix-socket.py | 3 ++-
> 4 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/python/ovs/fatal_signal.py b/python/ovs/fatal_signal.py
> index 7308039..14605ac 100644
> --- a/python/ovs/fatal_signal.py
> +++ b/python/ovs/fatal_signal.py
> @@ -15,7 +15,7 @@
> import atexit
> import os
> import signal
> -
> +import sys
> import ovs.vlog
>
I removed the above change and applied.
>
> _hooks = []
> @@ -134,3 +134,25 @@ def _init():
> if signal.getsignal(signr) == signal.SIG_DFL:
> signal.signal(signr, _signal_handler)
> atexit.register(_atexit_handler)
> +
> +
> +def signal_alarm(timeout):
> +if sys.platform == "win32":
> +import os
> +import time
> +import threading
> +
> +class Alarm (threading.Thread):
> +def __init__(self, timeout):
> +super(Alarm, self).__init__()
> +self.timeout = timeout
> +self.setDaemon(True)
> +
> +def run(self):
> +time.sleep(self.timeout)
> +os._exit(1)
> +
> +alarm = Alarm(timeout)
> +alarm.start()
> +else:
> +signal.alarm(timeout)
> diff --git a/tests/appctl.py b/tests/appctl.py
> index e5bcf2c..e4f0696 100644
> --- a/tests/appctl.py
> +++ b/tests/appctl.py
> @@ -13,7 +13,6 @@
> # limitations under the License.
>
> import argparse
> -import signal
> import sys
>
> import ovs.daemon
> @@ -21,6 +20,7 @@ import ovs.unixctl
> import ovs.unixctl.client
> import ovs.util
> import ovs.vlog
> +from ovs.fatal_signal import signal_alarm
>
>
> def connect_to_target(target):
> @@ -52,7 +52,7 @@ def main():
> args = parser.parse_args()
>
> if args.timeout:
> -signal.alarm(int(args.timeout))
> +signal_alarm(int(args.timeout))
>
> ovs.vlog.Vlog.init()
> target = args.target
> diff --git a/tests/test-ovsdb.py b/tests/test-ovsdb.py
> index 88180a3..e9d4510 100644
> --- a/tests/test-ovsdb.py
> +++ b/tests/test-ovsdb.py
> @@ -17,7 +17,6 @@ from __future__ import print_function
> import getopt
> import re
> import os
> -import signal
> import sys
> import uuid
>
> @@ -29,6 +28,7 @@ import ovs.db.types
> import ovs.ovsuuid
> import ovs.poller
> import ovs.util
> +from ovs.fatal_signal import signal_alarm
> import six
>
>
> @@ -676,7 +676,7 @@ def main(argv):
> except TypeError:
> raise error.Error("value %s on -t or --timeout is not at "
>"least 1" % value)
> -signal.alarm(timeout)
> +signal_alarm(timeout)
> else:
> sys.exit(0)
>
> diff --git a/tests/test-unix-socket.py b/tests/test-unix-socket.py
> index ebfa054..c80fb13 100644
> --- a/tests/test-unix-socket.py
> +++ b/tests/test-unix-socket.py
> @@ -19,6 +19,7 @@ import socket
> import sys
>
> import ovs.socket_util
> +from ovs.fatal_signal import signal_alarm
>
>
> def main(argv):
> @@ -33,7 +34,7 @@ def main(argv):
> sockname2 = sockname1
>
> signal.signal(signal.SIGALRM, signal.SIG_DFL)
> -signal.alarm(5)
> +signal_alarm(5)
>
> # Create a listening socket under name 'sockname1'.
> error, sock1 = ovs.socket_util.make_unix_socket(socket.SOCK_STREAM,
> False,
> --
> 2.7.2.windows.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V11 02/17] python tests: Register signal handlers only on supported types on Windows
On 2 August 2016 at 10:45, Paul Boca wrote: > SIGHUP and SIGALRM are not available on Windows. > > Signed-off-by: Paul-Daniel Boca > Acked-by: Alin Gabriel Serdean > Applied. > --- > V2: Fixed Python function inet_open_active, treat WSAEWOULDBLOCK error as > EINPROGRESS on Windows > V3: No changes > V4: No changes > V5: No changes > V6: No changes > V7: Simplified the signal handlers code > V8: No changes > V9: No changes > V10: No changes > V11: No changes > --- > python/ovs/fatal_signal.py | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/python/ovs/fatal_signal.py b/python/ovs/fatal_signal.py > index 14605ac..73e4be6 100644 > --- a/python/ovs/fatal_signal.py > +++ b/python/ovs/fatal_signal.py > @@ -16,6 +16,7 @@ import atexit > import os > import signal > import sys > + > import ovs.vlog > > _hooks = [] > @@ -128,9 +129,13 @@ def _init(): > global _inited > if not _inited: > _inited = True > +if sys.platform == "win32": > +signals = [signal.SIGTERM, signal.SIGINT] > +else: > +signals = [signal.SIGTERM, signal.SIGINT, signal.SIGHUP, > + signal.SIGALRM] > > -for signr in (signal.SIGTERM, signal.SIGINT, > - signal.SIGHUP, signal.SIGALRM): > +for signr in signals: > if signal.getsignal(signr) == signal.SIG_DFL: > signal.signal(signr, _signal_handler) > atexit.register(_atexit_handler) > -- > 2.7.2.windows.1 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V10 04/17] python tests: Fixed unixctl python tests for Windows
On 1 August 2016 at 02:29, Paul Boca wrote: > For bogus pid file path, use a windows-like file path. > > Signed-off-by: Paul-Daniel Boca > Acked-by: Alin Gabriel Serdean > Applied. > --- > V2: No changes > V3: No changes > V4: No changes > V5: No changes > V6: No changes > V7: No changes > V8: No changes > V9: No changes > V10: No changes > --- > tests/unixctl-py.at | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/tests/unixctl-py.at b/tests/unixctl-py.at > index cbcd802..2031897 100644 > --- a/tests/unixctl-py.at > +++ b/tests/unixctl-py.at > @@ -92,11 +92,17 @@ m4_define([UNIXCTL_BAD_TARGET_PYN], > AT_CHECK_UNQUOTED([tail -1 stderr], [0], [dnl > appctl.py: cannot read pidfile "`pwd`/bogus.pid" (No such file or > directory) > ]) > - > - AT_CHECK([PYAPPCTL_PYN([$3]) -t /bogus/path.pid doit], [1], [], > [stderr]) > - AT_CHECK([tail -1 stderr], [0], [dnl > + if test "$IS_WIN32" = "no"; then > + AT_CHECK([PYAPPCTL_PYN([$3]) -t /bogus/path.pid doit], [1], [], > [stderr]) > + AT_CHECK([tail -1 stderr], [0], [dnl > appctl.py: cannot connect to "/bogus/path.pid" (No such file or directory) > ]) > + else > + AT_CHECK([PYAPPCTL_PYN([$3]) -t c:/bogus/path.pid doit], [1], [], > [stderr]) > + AT_CHECK([tail -1 stderr], [0], [dnl > +appctl.py: cannot connect to "c:/bogus/path.pid" (No such file or > directory) > +]) > + fi > > AT_CLEANUP]) > > -- > 2.7.2.windows.1 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V11 03/17] python tests: Fixed ctl file name for Windows
On 2 August 2016 at 10:45, Paul Boca wrote:
> On Windows the CTL filename doesn't contain the pid of the process.
>
> Signed-off-by: Paul-Daniel Boca
> Acked-by: Alin Gabriel Serdean
> ---
> V2: No changes
> V3: No changes
> V4: No changes
> V5: No changes
> V6: No changes
> V7: Fixed flake8 errors. Addressed changes required by review.
> V8: Fixed small alignement problem.
> V9: No changes
> V10: No changes
> V11: No changes
> ---
> python/ovs/unixctl/__init__.py | 11 +--
> python/ovs/unixctl/server.py | 10 --
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/python/ovs/unixctl/__init__.py
> b/python/ovs/unixctl/__init__.py
> index d3d3556..e2e5604 100644
> --- a/python/ovs/unixctl/__init__.py
> +++ b/python/ovs/unixctl/__init__.py
> @@ -13,6 +13,7 @@
> # limitations under the License.
>
> import six
> +import sys
>
> import ovs.util
>
> @@ -71,14 +72,20 @@ def command_register(name, usage, min_args, max_args,
> callback, aux):
> def socket_name_from_target(target):
> assert isinstance(target, strtypes)
>
> -if target.startswith("/"):
> +""" On Windows an absolute path contains ':' ( i.e: C:\ ) """
> +if target.startswith('/') or target.find(':') > -1:
> return 0, target
>
> +""" Leave it to read the pid file on Windows also, the tests expect
> this
> +error in case of failure. """
>
The above comment should not be here. We should not write code with
information on how it is tested. So I removed it and applied this.
> pidfile_name = "%s/%s.pid" % (ovs.dirs.RUNDIR, target)
> pid = ovs.daemon.read_pidfile(pidfile_name)
> if pid < 0:
> return -pid, "cannot read pidfile \"%s\"" % pidfile_name
>
> -return 0, "%s/%s.%d.ctl" % (ovs.dirs.RUNDIR, target, pid)
> +if sys.platform == "win32":
> +return 0, "%s/%s.ctl" % (ovs.dirs.RUNDIR, target)
> +else:
> +return 0, "%s/%s.%d.ctl" % (ovs.dirs.RUNDIR, target, pid)
>
> command_register("help", "", 0, 0, _unixctl_help, None)
> diff --git a/python/ovs/unixctl/server.py b/python/ovs/unixctl/server.py
> index cc712bf..8595ed8 100644
> --- a/python/ovs/unixctl/server.py
> +++ b/python/ovs/unixctl/server.py
> @@ -15,6 +15,7 @@
> import copy
> import errno
> import os
> +import sys
>
> import six
> from six.moves import range
> @@ -188,8 +189,13 @@ class UnixctlServer(object):
> if path is not None:
> path = "punix:%s" % ovs.util.abs_file_name(ovs.dirs.RUNDIR,
> path)
> else:
> -path = "punix:%s/%s.%d.ctl" % (ovs.dirs.RUNDIR,
> - ovs.util.PROGRAM_NAME,
> os.getpid())
> +if sys.platform == "win32":
> +path = "punix:%s/%s.ctl" % (ovs.dirs.RUNDIR,
> +ovs.util.PROGRAM_NAME)
> +else:
> +path = "punix:%s/%s.%d.ctl" % (ovs.dirs.RUNDIR,
> + ovs.util.PROGRAM_NAME,
> + os.getpid())
>
> if version is None:
> version = ovs.version.VERSION
> --
> 2.7.2.windows.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V11 08/17] python tests: Skip python tests on Windows where POSIX pid is used
On 2 August 2016 at 10:45, Paul Boca wrote: > There is a difference between POSIX pid and Windows pid, not all the time > are equal. > On Windows when a python script is started, a sh command is triggered as > the parent > for script. So when we try to get the daemon pid with 'echo $!', this will > get the pid of sh > not of python.exe as expected. > Also the 'kill' command expects a POSIX pid, not the Windows pid written > by the python > daemons in pid file. > > Signed-off-by: Paul-Daniel Boca > Acked-by: Alin Gabriel Serdean > I applied the patches till here. In this change, the following comment has been added for all the tests that are being skipped. Even those tests for which the comment is not relevant: "Skip this test for Windows, echo $! gives shell pid instead of parent process". So I am skipping this. Please re-look this patch. > --- > V2: No changes > V3: No changes > V4: No changes > V5: No changes > V6: No changes > V7: Added comments explaining why the tests are skipped. > Enabled back the JSON-RPC tests > V8: No changes > V9: No changes > V10: No changes > V11: No changes > --- > tests/daemon-py.at | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/tests/daemon-py.at b/tests/daemon-py.at > index e59c11d..b1ff4fd 100644 > --- a/tests/daemon-py.at > +++ b/tests/daemon-py.at > @@ -3,6 +3,8 @@ AT_BANNER([daemon unit tests - Python]) > m4_define([DAEMON_PYN], >[AT_SETUP([daemon - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_KEYWORDS([python daemon]) > AT_CAPTURE_FILE([pid]) > AT_CAPTURE_FILE([expected]) > @@ -26,6 +28,8 @@ DAEMON_PYN([Python3], [$HAVE_PYTHON3], [$PYTHON3]) > m4_define([DAEMON_MONITOR_PYN], >[AT_SETUP([daemon --monitor - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_CAPTURE_FILE([pid]) > AT_CAPTURE_FILE([parent]) > AT_CAPTURE_FILE([parentpid]) > @@ -73,6 +77,8 @@ DAEMON_MONITOR_PYN([Python3], [$HAVE_PYTHON3], > [$PYTHON3]) > m4_define([DAEMON_MONITOR_RESTART_PYN], >[AT_SETUP([daemon --monitor restart exit code - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_CAPTURE_FILE([pid]) > AT_CAPTURE_FILE([parent]) > AT_CAPTURE_FILE([parentpid]) > @@ -120,6 +126,8 @@ DAEMON_MONITOR_RESTART_PYN([Python3], [$HAVE_PYTHON3], > [$PYTHON3]) > m4_define([DAEMON_DETACH_PYN], >[AT_SETUP([daemon --detach - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_CAPTURE_FILE([pid]) > # Start the daemon and make sure that the pidfile exists immediately. > # We don't wait for the pidfile to get created because the daemon is > @@ -142,6 +150,8 @@ m4_define([CHECK], > m4_define([DAEMON_DETACH_MONITOR_PYN], >[AT_SETUP([daemon --detach --monitor - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_CAPTURE_FILE([daemon]) > AT_CAPTURE_FILE([olddaemon]) > AT_CAPTURE_FILE([newdaemon]) > @@ -219,6 +229,8 @@ DAEMON_DETACH_MONITOR_ERRORS_PYN([Python3], > [$HAVE_PYTHON3], [$PYTHON3]) > m4_define([DAEMON_DETACH_CLOSES_FDS_PYN], >[AT_SETUP([daemon --detach closes standard fds - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_CAPTURE_FILE([pid]) > AT_CAPTURE_FILE([status]) > AT_CAPTURE_FILE([stderr]) > @@ -243,6 +255,8 @@ DAEMON_DETACH_CLOSES_FDS_PYN([Python3], > [$HAVE_PYTHON3], [$PYTHON3]) > m4_define([DAEMON_DETACH_MONITOR_CLOSES_FDS_PYN], >[AT_SETUP([daemon --detach --monitor closes standard fds - $1]) > AT_SKIP_IF([test $2 = no]) > + # Skip this test for Windows, echo $! gives shell pid instead of > parent process > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_CAPTURE_FILE([pid]) > AT_CAPTURE_FILE([status]) > AT_CAPTURE_FILE([stderr]) > -- > 2.7.2.windows.1 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V11 09/17] python tests: Fixed OSError not iterable on Windows
On 2 August 2016 at 10:45, Paul Boca wrote:
> On Windows if this exception is triggered then it will raise an exception
> while in the
> exception handler.
>
> Signed-off-by: Paul-Daniel Boca
> Acked-by: Alin Gabriel Serdean
>
I added the following incremental and applied this.
diff --git a/python/ovs/poller.py b/python/ovs/poller.py
index 3ebaf5a..de6bf22 100644
--- a/python/ovs/poller.py
+++ b/python/ovs/poller.py
@@ -172,8 +172,7 @@ class Poller(object):
except OSError as e:
""" On Windows, the select function from poll raises
OSError
exception if the polled array is empty."""
-error = e.errno
-if error != errno.EINTR:
+if e.errno != errno.EINTR:
vlog.err("poll: %s" % os.strerror(e.errno))
except select.error as e:
# XXX rate-limit
> ---
> V2: No changes
> V3: No changes
> V4: No changes
> V5: No changes
> V6: No changes
> V7: No changes
> V8: Added comment when using OSError on Windows
> V9: No changes
> V10: No changes
> V11: No changes
> ---
> python/ovs/poller.py | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/python/ovs/poller.py b/python/ovs/poller.py
> index 20be801..3ebaf5a 100644
> --- a/python/ovs/poller.py
> +++ b/python/ovs/poller.py
> @@ -17,6 +17,7 @@ import ovs.timeval
> import ovs.vlog
> import select
> import socket
> +import os
>
> try:
> import eventlet.patcher
> @@ -168,6 +169,12 @@ class Poller(object):
> try:
> events = self.poll.poll(self.timeout)
> self.__log_wakeup(events)
> +except OSError as e:
> +""" On Windows, the select function from poll raises
> OSError
> +exception if the polled array is empty."""
> +error = e.errno
> +if error != errno.EINTR:
> +vlog.err("poll: %s" % os.strerror(e.errno))
> except select.error as e:
> # XXX rate-limit
> error, msg = e
> --
> 2.7.2.windows.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V11 11/17] python tests: Ported UNIX sockets to Windows
On 2 August 2016 at 10:45, Paul Boca wrote:
> AF_UNIX sockets are not supported on Windows.
> Instead of an AF_UNIX socket use localhost tcp connections to communicate
> between components. This makes the python sockets compatible with
> the ones used in Windows applications.
>
> In case the socket returns WSAEWOULDBLOCK, it is replaced by EAGAIN error
> in order to be compatible with Windows.
>
> Signed-off-by: Paul-Daniel Boca
> Acked-by: Alin Gabriel Serdean
>
I am skipping this. I suppose this does not work anymore as the servers can
use named pipes.
> ---
> V2: Fixed Python function inet_open_active, treat WSAEWOULDBLOCK error as
> EINPROGRESS on Windows
> V3: Use context managers for file handle leaks
> V4: No changes
> V5: No changes
> V6: No changes
> V7: Fix for JSON-RPC tests - treat WSAEWOULDBLOCK error as EAGAIN
> for compatibility
> V8: No changes
> V9: No changes
> V10: No changes
> V11: No changes
> ---
> python/ovs/jsonrpc.py| 4
> python/ovs/socket_util.py| 56
> +---
> python/ovs/stream.py | 9 +--
> python/ovs/unixctl/server.py | 6 +++--
> 4 files changed, 62 insertions(+), 13 deletions(-)
>
> diff --git a/python/ovs/jsonrpc.py b/python/ovs/jsonrpc.py
> index 6300c67..1bc3493 100644
> --- a/python/ovs/jsonrpc.py
> +++ b/python/ovs/jsonrpc.py
> @@ -14,6 +14,7 @@
>
> import errno
> import os
> +import sys
>
> import six
>
> @@ -274,6 +275,9 @@ class Connection(object):
> except UnicodeError:
> error = errno.EILSEQ
> if error:
> +if (sys.platform == "win32"
> + and error == errno.WSAEWOULDBLOCK):
> +error = errno.EAGAIN
> if error == errno.EAGAIN:
> return error, None
> else:
> diff --git a/python/ovs/socket_util.py b/python/ovs/socket_util.py
> index b358b05..949d27a 100644
> --- a/python/ovs/socket_util.py
> +++ b/python/ovs/socket_util.py
> @@ -17,6 +17,7 @@ import os
> import os.path
> import random
> import socket
> +import sys
>
> import six
> from six.moves import range
> @@ -54,6 +55,26 @@ def free_short_name(short_name):
> ovs.fatal_signal.unlink_file_now(link_name)
>
>
> +def compat_read_unix_socket(path):
> +try:
> +with open(path, "r+") as file_handle:
> +ret = int(file_handle.readline())
> +except IOError as e:
> +vlog.warn("%s: open: %s" % (path, e.strerror))
> +raise socket.error(errno.ENOENT)
> +
> +return ret
> +
> +
> +def compat_write_unix_socket(path, port):
> +try:
> +with open(path, "w") as file_handle:
> +file_handle.write(str(port))
> +except IOError as e:
> +vlog.warn("%s: open: %s" % (path, e.strerror))
> +raise socket.error(errno.ENOENT)
> +
> +
> def make_unix_socket(style, nonblock, bind_path, connect_path,
> short=False):
> """Creates a Unix domain socket in the given 'style' (either
> socket.SOCK_DGRAM or socket.SOCK_STREAM) that is bound to 'bind_path'
> (if
> @@ -65,7 +86,10 @@ def make_unix_socket(style, nonblock, bind_path,
> connect_path, short=False):
> None."""
>
> try:
> -sock = socket.socket(socket.AF_UNIX, style)
> +if sys.platform == "win32":
> +sock = socket.socket(socket.AF_INET, style)
> +else:
> +sock = socket.socket(socket.AF_UNIX, style)
> except socket.error as e:
> return get_exception_errno(e), None
>
> @@ -81,17 +105,28 @@ def make_unix_socket(style, nonblock, bind_path,
> connect_path, short=False):
> return e.errno, None
>
> ovs.fatal_signal.add_file_to_unlink(bind_path)
> -sock.bind(bind_path)
> +if sys.platform == "win32":
> +sock.bind(("127.0.0.1", 0))
> +compat_write_unix_socket(bind_path, sock.getsockname()[1])
> +else:
> +sock.bind(bind_path)
>
> -try:
> -os.fchmod(sock.fileno(), 0o700)
> -except OSError as e:
> -pass
> +try:
> +os.fchmod(sock.fileno(), 0o700)
> +except OSError as e:
> +pass
> if connect_path is not None:
> try:
> -sock.connect(connect_path)
> +if sys.platform == "win32":
> +port = compat_read_unix_socket(connect_path)
> +sock.connect(("127.0.0.1", port))
> +else:
> +sock.connect(connect_path)
> except socket.error as e:
> -if get_exception_errno(e) != errno.EINPROGRESS:
> +error = get_exception_errno(e)
> +if sys.platform == "win32" and error ==
> errno.WSAEWOULDBLOCK:
> +error = errno.EINPROGRESS
> +
Re: [ovs-dev] [PATCH V11 12/17] python tests: Prepare porting Python daemon on Windows
On 2 August 2016 at 10:45, Paul Boca wrote:
> Renamed daemon.py to daemon_unix.py and implemented a wrapper over it.
>
> Signed-off-by: Paul-Daniel Boca
> Acked-by: Alin Gabriel Serdean
>
As a standalone commit, this likely fails because it
calls ovs.daemon_windows which does not exist. I also notice that you have
made additional changes in daemon_unix.py. Please do that as a separate
commit with proper commit message.
Also, to be sure, please add the following to your .gitconfig
[diff]
renames = copies
> ---
> V8: Initial commit.
> V9: No changes
> V10: Fixed exception on Unix
> V11: No changes
> ---
> python/automake.mk| 1 +
> python/ovs/daemon.py | 489 ++
> python/ovs/daemon_unix.py | 530
> ++
> 3 files changed, 551 insertions(+), 469 deletions(-)
> create mode 100644 python/ovs/daemon_unix.py
>
> diff --git a/python/automake.mk b/python/automake.mk
> index 1c8fa38..4d3fcb6 100644
> --- a/python/automake.mk
> +++ b/python/automake.mk
> @@ -11,6 +11,7 @@ ovstest_pyfiles = \
> ovs_pyfiles = \
> python/ovs/__init__.py \
> python/ovs/daemon.py \
> + python/ovs/daemon_unix.py \
> python/ovs/fcntl_win.py \
> python/ovs/db/__init__.py \
> python/ovs/db/data.py \
> diff --git a/python/ovs/daemon.py b/python/ovs/daemon.py
> index bd06195..b1d6c36 100644
> --- a/python/ovs/daemon.py
> +++ b/python/ovs/daemon.py
> @@ -1,4 +1,4 @@
> -# Copyright (c) 2010, 2011, 2012 Nicira, Inc.
> +# Copyright (c) 2016 Cloudbase Solutions Srl
> #
> # Licensed under the Apache License, Version 2.0 (the "License");
> # you may not use this file except in compliance with the License.
> @@ -12,515 +12,66 @@
> # See the License for the specific language governing permissions and
> # limitations under the License.
>
> -import errno
> -import fcntl
> -import os
> -import resource
> -import signal
> import sys
> -import time
>
> -import ovs.dirs
> -import ovs.fatal_signal
> -import ovs.process
> -import ovs.socket_util
> -import ovs.timeval
> -import ovs.util
> -import ovs.vlog
> +# This is only a wrapper over Linux implementations
> +if sys.platform != "win32":
> +import ovs.daemon_unix as daemon_util
>
> -vlog = ovs.vlog.Vlog("daemon")
> -
> -# --detach: Should we run in the background?
> -_detach = False
> -
> -# --pidfile: Name of pidfile (null if none).
> -_pidfile = None
> -
> -# Our pidfile's inode and device, if we have created one.
> -_pidfile_dev = None
> -_pidfile_ino = None
> -
> -# --overwrite-pidfile: Create pidfile even if one already exists and is
> locked?
> -_overwrite_pidfile = False
> -
> -# --no-chdir: Should we chdir to "/"?
> -_chdir = True
> -
> -# --monitor: Should a supervisory process monitor the daemon and restart
> it if
> -# it dies due to an error signal?
> -_monitor = False
> -
> -# File descriptor used by daemonize_start() and daemonize_complete().
> -_daemonize_fd = None
> -
> -RESTART_EXIT_CODE = 5
> +RESTART_EXIT_CODE = daemon_util.RESTART_EXIT_CODE
>
>
> def make_pidfile_name(name):
> -"""Returns the file name that would be used for a pidfile if 'name'
> were
> -provided to set_pidfile()."""
> -if name is None or name == "":
> -return "%s/%s.pid" % (ovs.dirs.RUNDIR, ovs.util.PROGRAM_NAME)
> -else:
> -return ovs.util.abs_file_name(ovs.dirs.RUNDIR, name)
> +return daemon_util.make_pidfile_name(name)
>
>
> def set_pidfile(name):
> -"""Sets up a following call to daemonize() to create a pidfile named
> -'name'. If 'name' begins with '/', then it is treated as an absolute
> path.
> -Otherwise, it is taken relative to ovs.util.RUNDIR, which is
> -$(prefix)/var/run by default.
> -
> -If 'name' is null, then ovs.util.PROGRAM_NAME followed by ".pid" is
> -used."""
> -global _pidfile
> -_pidfile = make_pidfile_name(name)
> +daemon_util.set_pidfile(name)
>
>
> def set_no_chdir():
> -"""Sets that we do not chdir to "/"."""
> -global _chdir
> -_chdir = False
> +daemon_util.set_no_chdir()
>
>
> def ignore_existing_pidfile():
> -"""Normally, daemonize() or daemonize_start() will terminate the
> program
> -with a message if a locked pidfile already exists. If this function
> is
> -called, an existing pidfile will be replaced, with a warning."""
> -global _overwrite_pidfile
> -_overwrite_pidfile = True
> +daemon_util.ignore_existing_pidfile()
>
>
> def set_detach():
> -"""Sets up a following call to daemonize() to detach from the
> foreground
> -session, running this process in the background."""
> -global _detach
> -_detach = True
> +daemon_util.set_detach()
>
>
> def get_detach():
> -"""Will daemonize() really detach?"""
> -return _detach
> +return daemon_util.get_detach()
>
>
> def set_monitor():
> -"""Sets up a following call to daemonize() to fork a supervisory
> process to
> -monitor
Re: [ovs-dev] [PATCH V11 17/17] tests: Skip vlog tests that try to move opened file
On 2 August 2016 at 10:45, Paul Boca wrote: > On Windows if a file is opened by an application for writing, we cannot > move > it until all handles to that file are closed. > > Signed-off-by: Paul-Daniel Boca > Acked-by: Alin Gabriel Serdean > I skipped the patches till here (starting from the previously commented patch) as they are not relevant as I skipped the daemonization patch. I applied this one. > --- > V3: Initial commit > V4: No changes > V5: No changes > V6: Removed code that disables 'vlog/close' tests. > V7: Small comments changes > V8: No changes > V9: No changes > V10: No changes > V11: No changes > --- > tests/vlog.at | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tests/vlog.at b/tests/vlog.at > index 4907a1b..468e872 100644 > --- a/tests/vlog.at > +++ b/tests/vlog.at > @@ -148,6 +148,9 @@ AT_CLEANUP > > m4_define([VLOG_REOPEN_PYN], >[AT_SETUP([vlog - vlog/reopen - $1]) > + # This test won't work as-is on Windows because Windows doesn't allow > + # files that are open to be renamed. > + AT_SKIP_IF([test "$IS_WIN32" = "yes"]) > AT_SKIP_IF([test $2 = no]) > on_exit 'kill `cat test-unixctl.py.pid`' > > -- > 2.7.2.windows.1 > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH V3 2/4] ovs-ofctl: Fixed PID file naming on windows
On 7 June 2016 at 01:00, Paul Boca wrote:
> If an absolute path is given to --pidfile parameter (not containing ':')
> then the application name is used for PID file, ignoring the given name.
>
What is an example of absolute path that does not include ":"? Would that
be something like "/foo/bar/name.pid"? If so, doesn't your patch return
something like "/var/run/openvswitch/foo/bar/name.pid" ? That looks wrong
to me.
>
> Signed-off-by: Paul-Daniel Boca
> ---
> V2: Updated commit message
> ---
> lib/daemon-windows.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
> index ac71aa1..8cf0fea 100644
> --- a/lib/daemon-windows.c
> +++ b/lib/daemon-windows.c
> @@ -485,8 +485,12 @@ daemon_become_new_user(bool access_datapath
> OVS_UNUSED)
> char *
> make_pidfile_name(const char *name)
> {
> -if (name && strchr(name, ':')) {
> -return xstrdup(name);
> +if (name) {
> +if (strchr(name, ':')) {
> +return xstrdup(name);
> +} else {
> +return xasprintf("%s/%s", ovs_rundir(), name);
> +}
> } else {
> return xasprintf("%s/%s.pid", ovs_rundir(), program_name);
> }
> --
> 2.7.2.windows.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
>
>
>
> I am always a little nervous about putting things in schema that I know
> will change later,
> especially when it comes to the structure of the config.
>
> I am thinking of ovn-nb.ovsschema changes along the following lines:
>
> "Logical_Router": {
> "columns": {
> "name": {"type": "string"},
> "ports": {"type": {"key": {"type": "uuid",
> "refTable":
> "Logical_Router_Port",
> "refType": "strong"},
> "min": 0,
> "max": "unlimited"}},
> "static_routes": {"type": {"key": {"type": "uuid",
> "refTable":
> "Logical_Router_Static_Route",
> "refType": "strong"},
> "min": 0,
> "max": "unlimited"}},
> "default_gw": {"type": {"key": "string", "min": 0, "max":
> 1}},
> "enabled": {"type": {"key": "boolean", "min": 0, "max":
> 1}},
> +"nat": {"type": {"key": {"type": "uuid",
> + "refTable": "NAT”,
> + "refType": "strong"},
> + "min": 0,
> + "max": "unlimited"}},
> "options": {
> "type": {"key": "string",
>"value": "string",
>"min": 0,
>"max": "unlimited"}},
> "external_ids": {
> "type": {"key": "string", "value": "string",
> "min": 0, "max": "unlimited"}}},
> "isRoot": true},
>
>
> +“NAT”: {
> +"columns": {
> +"outside_ip": {"type": {"key": "string", "min": 0, "max":
> 1}},
> +"inside_ip": {"type": {"key": "string", "min": 0, "max":
> 1}},
> +"direction": {"type": {"key": {"type": "string",
> + "enum": ["set", ["dnat", “snat",
> "dnat_and_snat"]]}}},
> +"isRoot": false},
>
> DNAT maps from destination outside_ip to inside_ip.
> SNAT maps from source inside_ip to outside_ip.
> If direction == dnat or direction == dnat_and_snat, then check for
> inside_ip mask == 32
> If direction == snat or direction == dnat_and_snat, then check for
> outside_ip == 32
The names "inside_ip" and "outside_ip" keeps tripping me up. The
nomenclature feels similar to tunnel outside_ip and tunnel inside_ip. What
do you think about "logical_ip" and "physical_ip" instead?
>
>
> >As an addendum, the current schema does dnat:30.0.0.3=192.168.1.2. I
> >would like to enhance it to also be able to provide ports. Something
> >like dnat:30.0.0.3:4443=192.168.1.2:80
> >
> >So we will need to include the above with the new table that you are
> >thinking too.
>
> You can add outside_protocol, outside_l4_port, inside_protocol, and
> inside_l4_port.
>
> >> Note also that for distributed handling of floating IPs, we will need
> MAC
> >> addresses to go along with the floating IPs. This makes me think it
> might
> >> be worth having an indirection to a separate nat table.
>
> We will add outside_mac in the patch for distributed handling of floating
> IPs.
>
> Mickey
>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OpenStack Proposal: Integration with OVN L3 Gateway
On 8 June 2016 at 09:16, Amitabha Biswas wrote: > Hi Brian, > > The each gateway router only has a single transit network attached to it, > and each gateway router to connected to the common provider/external > network as well. We can probably do away with the transit network if we use > router pairing (at a later point). > The transit network would be needed with router peering too. (Router peering will only reduce a logical switch creation in OVN NB database apart from internal implementation details around logical datapaths). > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
>
>
> Thinking about "logical_ip" and "physical_ip", I am concerned that
> "physical_ip" will confuse people. When I hear "physical_ip", my mind
> wanders to pieces of hardware, which is not what this is about.
>
> How about "internal_ip"/"external_ip"?
>
I decided to use "logical_ip"/"external_ip". logical_ip feels like a good
term as I can easily associate it with logical_port.
>
> Mickey
>
> -Guru Shetty wrote: -
> To: Mickey Spiegel/San Jose/IBM@IBMUS
> From: Guru Shetty
> Date: 06/07/2016 08:14AM
> Cc: ovs dev
> Subject: Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway
> router.
>
>
>
> I am always a little nervous about putting things in schema that I know
> will change later,
> especially when it comes to the structure of the config.
>
> I am thinking of ovn-nb.ovsschema changes along the following lines:
>
> "Logical_Router": {
> "columns": {
> "name": {"type": "string"},
> "ports": {"type": {"key": {"type": "uuid",
> "refTable":
> "Logical_Router_Port",
> "refType": "strong"},
> "min": 0,
> "max": "unlimited"}},
> "static_routes": {"type": {"key": {"type": "uuid",
> "refTable":
> "Logical_Router_Static_Route",
> "refType": "strong"},
> "min": 0,
> "max": "unlimited"}},
> "default_gw": {"type": {"key": "string", "min": 0, "max":
> 1}},
> "enabled": {"type": {"key": "boolean", "min": 0, "max":
> 1}},
> +"nat": {"type": {"key": {"type": "uuid",
> + "refTable": "NAT”,
> + "refType": "strong"},
> + "min": 0,
> + "max": "unlimited"}},
> "options": {
> "type": {"key": "string",
>"value": "string",
>"min": 0,
>"max": "unlimited"}},
> "external_ids": {
> "type": {"key": "string", "value": "string",
> "min": 0, "max": "unlimited"}}},
> "isRoot": true},
>
>
> +“NAT”: {
> +"columns": {
> +"outside_ip": {"type": {"key": "string", "min": 0, "max":
> 1}},
> +"inside_ip": {"type": {"key": "string", "min": 0, "max":
> 1}},
> +"direction": {"type": {"key": {"type": "string",
> + "enum": ["set", ["dnat", “snat",
> "dnat_and_snat"]]}}},
> +"isRoot": false},
>
> DNAT maps from destination outside_ip to inside_ip.
> SNAT maps from source inside_ip to outside_ip.
> If direction == dnat or direction == dnat_and_snat, then check for
> inside_ip mask == 32
> If direction == snat or direction == dnat_and_snat, then check for
> outside_ip == 32
>
> The names "inside_ip" and "outside_ip" keeps tripping me up. The
> nomenclature feels similar to tunnel outside_ip and tunnel inside_ip. What
> do you think about "logical_ip" and "physical_ip" instead?
>
>
> >As an addendum, the current schema does dnat:30.0.0.3=192.168.1.2. I
> >would like to enhance it to also be able to provide ports. Something
> >like dnat:30.0.0.3:4443=192.168.1.2:80
> >
> >So we will need to include the above with the new table that you are
> >thinking too.
>
> You can add outside_protocol, outside_l4_port, inside_protocol, and
> inside_l4_port.
>
> >> Note also that for distributed handling of floating IPs, we will need
> MAC
> >> addresses to go along with the floating IPs. This makes me think it
> might
> >> be worth having an indirection to a separate nat table.
>
> We will add outside_mac in the patch for distributed handling of floating
> IPs.
>
> Mickey
>
>
>
>
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
On 2 June 2016 at 14:48, Ben Pfaff wrote: > On Thu, May 19, 2016 at 01:02:34PM -0700, Gurucharan Shetty wrote: > > For traffic from physical space to virtual space we need DNAT. > > The DNAT happens in the gateway router and reaches the logical > > port. The return traffic should be unDNATed. > > > > Traffic originating in virtual space heading to physical space > > should be SNATed. The return traffic is unSNATted. > > > > East-west traffic with the public destination IP address needs > > a DNAT. This traffic is punted to the l3 gateway where DNAT > > takes place. This traffic is also SNATed and eventually loops back to > > its destination. The SNAT is needed because we need the reverse traffic > > to go back to the l3 gateway and not short-circuit directly to the > source. > > > > This commit introduces 4 new logical actions. > > 1. ct_snat: To send the packet through SNAT zone to unSNAT packets. > > 2. ct_snat(IP): To SNAT to the provided IP address. > > 3. ct_dnat: To send the packet throgh DNAT zone to unDNAT packets. > > 4. ct_dnat(IP): To DNAT to the provided IP. > > > > This commit only provides the ability to do IP based NAT. This will > > eventually be enhanced to do PORT based NAT too. > > > > Command hints: > > > > Consider a distributed router "R1" that has switch foo (192.168.1.0/24) > > with a lport foo1 (192.168.1.2) and bar (192.168.2.0/24) with lport bar1 > > (192.168.2.2) connected to it. You connect "R1" to > > a gateway router "R2" via a switch "join" in (20.0.0.0/24) network. > > > > R2 has a switch "alice" (172.16.1.0/24) connected to it (to simulate > > external network). > > > > case: Add pure DNAT (north-south) > > > > Add a DNAT rule in R2: > > ovn-nbctl set logical_router R2 dnat:"30.0.0.2"=192.168.1.2 > > > > Now alice1 should be able to ping 192.168.1.2 via 30.0.0.2. > > > > case2 : Add pure SNAT (south-north) > > > > Add a SNAT rule in R2: > > > > ovn-nbctl set logical_router R2 snat:"192.168.1.0/24"=30.0.0.1 > > > > (You need a static route in R1 to send packets destined to outside > > world to go through R2) > > > > When foo1 pings alice1, alice1 receives traffic from 30.0.0.1 > > > > case3 : SNAT and DNAT (east-west traffic) > > > > Add a SNAT rule for bar1 > > ovn-nbctl set logical_router R2 snat:"192.168.2.2"=30.0.0.3 > > > > When bar1 pings 30.0.0.2, the traffic jumps to the gateway router > > and loops back to foo1 with a source ip address of 30.0.0.3 > > > > Signed-off-by: Gurucharan Shetty > > Thanks for working on this! > > The examples above are helpful. Is there someplace in the documentation > where it would be appropriate to include them? > I thought about this for a while and couldn't find a nice way to put this. I am hoping that when the upstream users at OpenStack use it, and based on their feedback, I will try to add some documentation. > > Can you add some test cases for action parsing to "ovn -- action > parsing" in ovn.at? (As an aside, I like to try to make sure that the > action parsing test cases exercise all the possible syntax errors; > usually that's easy.) > I added a few unit tests. > > Please mention the "ip" prerequisite in the ovn-sb.xml documentation. > Done > > I see a typo in the ovn-northd.8.xml documentation, > s/Northdbound/Northbound/ in a few places, e.g.: > + For each configuration in the OVN Northdbound database, that > asks > ... > + changed based on the configuration in the OVN Northdbound database. > ... > + For each configuration in the OVN Northdbound database, that > asks > Corrected. > > It appears to me that there is a lot of duplicated code in ovn-northd.c > for the different kinds of NAT. For example, I think that the following > would condense the SNAT code a good deal with less code (it does not > update the comments properly though): > The schema will be changed in the next version. I have tried to reduce code duplicity by moving all the NAT related code to a single code block. > Do you think that "non-distributed" is a good term? If it is a standard > term, then it's OK, but, if not, then negative terms are usually better > replaced by positive, for example perhaps "centralized" instead. > I have gotten rid of "non-distributed" and use "Gateway router" in its place. > > The documentation in ovn-sb.xml talks about recirculation. The person > looking at OVN logical flows is a couple of steps removed from > understanding what this means or the consequences. I wonder whether > there is a simple way to explain the meaning or why it is important. > I have re-worked the wordings. I will send the next version. > > Thanks again for implementing the gateway. > > Acked-by: Ben Pfaff > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 8/8] automake: Add ovs-bugtool.in to flake8-check.
> > > > All of these didn't appear to make the patchworks queue, > so the following is an ack of the whole series - I've > looked at all of them and they look good... > > Acked-by: Ryan Moats > > Thank you Ryan! I applied the series. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 8/8] automake: Add ovs-bugtool.in to flake8-check.
On 9 June 2016 at 13:14, Aaron Rosen wrote: > This patch seemed to break the build with some flake8 python3 errors for > me. I have a patch coming up to fix it. > Oink. Should I be doing more than a "pip install flake8" and make flake8-check to trigger these problems? > > On Thu, Jun 9, 2016 at 11:06 AM, Guru Shetty wrote: > >> > >> > >> > >> > All of these didn't appear to make the patchworks queue, >> > so the following is an ack of the whole series - I've >> > looked at all of them and they look good... >> > >> > Acked-by: Ryan Moats >> > >> > Thank you Ryan! I applied the series. >> ___ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-bugtool: Fix flake8 errors.
On 9 June 2016 at 13:22, Russell Bryant wrote:
> A previous commit added this file to be checked by flake8, but the file
> failed a number of checks done by the 'hacking' flake8 plugin.
>
> Fixes: b00bdc728e7a ("automake: Add ovs-bugtool.in to flake8-check.")
> Signed-off-by: Russell Bryant
>
Acked-by: Gurucharan Shetty
> ---
> utilities/bugtool/ovs-bugtool.in | 48
> ++--
> 1 file changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/utilities/bugtool/ovs-bugtool.in b/utilities/bugtool/
> ovs-bugtool.in
> index ecf01f6..cc18285 100755
> --- a/utilities/bugtool/ovs-bugtool.in
> +++ b/utilities/bugtool/ovs-bugtool.in
> @@ -33,6 +33,8 @@
> # or func_output().
> #
>
> +from __future__ import print_function
> +
> import getopt
> import re
> import os
> @@ -252,7 +254,7 @@ dev_null = open('/dev/null', 'r+')
> def output(x):
> global SILENT_MODE
> if not SILENT_MODE:
> -print x
> +print(x)
>
>
> def output_ts(x):
> @@ -355,7 +357,7 @@ def collect_data():
> elif 'func' in v:
> try:
> s = v['func'](cap)
> -except Exception, e:
> +except Exception as e:
> s = str(e)
> if check_space(cap, k, len(s)):
> v['output'] = StringIOmtime(s)
> @@ -373,7 +375,7 @@ def main(argv=None):
> collect_all_info = True
>
> if '--help' in sys.argv:
> -print """\
> +print("""
> %(argv0)s: create status report bundles to assist in problem diagnosis
> usage: %(argv0)s OPTIONS
>
> @@ -398,12 +400,12 @@ Output options:
>--outfd=FD write output to FD (requires --output=tar)
>--unlimitedignore default limits on sizes of data
> collected
>--debugprint ovs-bugtool debug info on stdout\
> -""" % {'argv0': sys.argv[0]}
> +""" % {'argv0': sys.argv[0]})
> sys.exit(0)
>
> # we need access to privileged files, exit if we are not running as
> root
> if os.getuid() != 0:
> -print >>sys.stderr, "Error: ovs-bugtool must be run as root"
> +print("Error: ovs-bugtool must be run as root", file=sys.stderr)
> return 1
>
> output_file = None
> @@ -418,8 +420,8 @@ Output options:
> argv, 'sy', ['capabilities', 'silent', 'yestoall', 'entries=',
> 'output=', 'outfd=', 'outfile=', 'all',
> 'unlimited',
> 'debug', 'ovs', 'log-days='])
> -except getopt.GetoptError, opterr:
> -print >>sys.stderr, opterr
> +except getopt.GetoptError as opterr:
> +print(opterr, file=sys.stderr)
> return 2
>
> try:
> @@ -439,7 +441,7 @@ Output options:
> if v in ['tar', 'tar.bz2', 'tar.gz', 'zip']:
> output_type = v
> else:
> -print >>sys.stderr, "Invalid output format '%s'" % v
> +print("Invalid output format '%s'" % v, file=sys.stderr)
> return 2
>
> # "-s" or "--silent" means suppress output (except for the final
> @@ -461,7 +463,8 @@ Output options:
> old = fcntl.fcntl(output_fd, fcntl.F_GETFD)
> fcntl.fcntl(output_fd, fcntl.F_SETFD, old |
> fcntl.FD_CLOEXEC)
> except:
> -print >>sys.stderr, "Invalid output file descriptor",
> output_fd
> +print("Invalid output file descriptor", output_fd,
> + file=sys.stderr)
> return 2
>
> if k == '--outfile':
> @@ -483,15 +486,16 @@ Output options:
> log_days = int(v)
>
> if len(params) != 1:
> -print >>sys.stderr, "Invalid additional arguments", str(params)
> +print("Invalid additional arguments", str(params),
> file=sys.stderr)
> return 2
>
> if output_fd != -1 and output_type != 'tar':
> -print >>sys.stderr, "Option '--outfd' only valid with
> '--output=tar'"
> +print("Option '--outfd' only valid with '--output=tar'",
> + file=sys.stderr)
> return 2
>
> if output_fd != -1 and output_file is not None:
> -print >>sys.stderr, "Cannot set both '--outfd' and '--outfile'"
> +print("Cannot set both '--outfd' and '--outfile'",
> file=sys.stderr)
> return 2
>
> if output_file is not None and not unlimited_data:
> @@ -713,10 +717,10 @@ exclude those logs from the archive.
> make_zip(subdir, output_file)
>
> if dbg:
> -print >>sys.stderr, "Category sizes (max, actual):\n"
> +print("Category sizes (max, actual):\n", file=sys.stderr)
> for c in caps.keys():
> -print >>sys.stderr, "%s (%d, %d)" % (c, caps[c][MAX_SIZE],
> - cap_sizes[c])
> +print("%s (%d, %d)" % (c, caps[c][MAX_SIZE],
> cap_sizes[c]),
> + file=sys.stderr)
>
> cleanup_ovsdb()
>
Re: [ovs-dev] [PATCH 8/8] automake: Add ovs-bugtool.in to flake8-check.
On 9 June 2016 at 13:27, Russell Bryant wrote: > On Thu, Jun 9, 2016 at 4:20 PM, Guru Shetty wrote: > > > On 9 June 2016 at 13:14, Aaron Rosen wrote: > > > > > This patch seemed to break the build with some flake8 python3 errors > for > > > me. I have a patch coming up to fix it. > > > > > > > > Sorry, I posted a patch before seeing this. > > http://openvswitch.org/pipermail/dev/2016-June/072579.html > > > > Oink. Should I be doing more than a "pip install flake8" and make > > flake8-check to trigger these problems? > > > The issue is that you also need the "hacking" flake8 plugin. "pip install > hacking" will do it. > I see now that it is explained in INSTALL.md. Sorry about that. > > We could detect if the hacking plugin is installed and force failure in > that case. A better solution is to switch to a different method of running > flake8 that ensures everyone who runs it always runs it in a consistent > environment the same set of packages and versions. I have a really old > patch that did that. I think it's worth resurrecting it to avoid any more > of this problem. > > -- > Russell Bryant > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] utilities/ovs-docker: Add support for specifying vlan tag on add-port cal
On 11 June 2016 at 05:28, Brian Turek wrote:
> Signed-off-by: Brian Turek
>
Thank you for your contribution. How did you send this patch? I couldn't
apply it on my local tree using 'git am'. Sending it via 'git send-email'
usually gets it right.
The change in the patch itself is not much, so I took a look. The thing
that concerns me a bit with this patch is that I could potentially run
commands of the form:
utilities/ovs-docker add-port br-int eth1 f5f314682193 --vlan="2 -- set
bridge br-int external_ids:hello=hi"
We could avoid it by doing something like this instead:
diff --git a/utilities/ovs-docker b/utilities/ovs-docker
index 43cea54..82c0343 100755
--- a/utilities/ovs-docker
+++ b/utilities/ovs-docker
@@ -90,6 +90,10 @@ add_port () {
MTU=`expr X"$1" : 'X[^=]*=\(.*\)'`
shift
;;
+--vlan=*)
+TAG=`expr X"$1" : 'X[^=]*=\(.*\)'`
+shift
+;;
*)
echo >&2 "$UTIL add-port: unknown option \"$1\""
exit 1
@@ -134,6 +138,15 @@ add_port () {
exit 1
fi
+if [ -n "$TAG" ]; then
+if ovs_vsctl set port "${PORTNAME}_l" tag="$TAG"; then :; else
+echo >&2 "$UTIL: Failed to set vlan $tag"
+ovs_vsctl del-port "${PORTNAME}_l"
+ip link delete "${PORTNAME}_l"
+exit 1
+fi
+fi
+
ip link set "${PORTNAME}_l" up
>
> diff --git a/utilities/ovs-docker b/utilities/ovs-docker
> index 43cea54..98892b6 100755
> --- a/utilities/ovs-docker
> +++ b/utilities/ovs-docker
> @@ -90,6 +90,10 @@ add_port () {
> MTU=`expr X"$1" : 'X[^=]*=\(.*\)'`
> shift
> ;;
> +--vlan=*)
> +TAG="tag=$(expr X"$1" : 'X[^=]*=\(.*\)')"
> +shift
> +;;
> *)
> echo >&2 "$UTIL add-port: unknown option \"$1\""
> exit 1
> @@ -126,7 +130,7 @@ add_port () {
>
> # Add one end of veth to OVS bridge.
> if ovs_vsctl --may-exist add-port "$BRIDGE" "${PORTNAME}_l" \
> - -- set interface "${PORTNAME}_l" \
> + $TAG -- set interface "${PORTNAME}_l" \
> external_ids:container_id="$CONTAINER" \
> external_ids:container_iface="$INTERFACE"; then :; else
> echo >&2 "$UTIL: Failed to add "${PORTNAME}_l" port to bridge
> $BRIDGE"
> @@ -224,15 +228,15 @@ usage: ${UTIL} COMMAND
> Commands:
>add-port BRIDGE INTERFACE CONTAINER [--ipaddress="ADDRESS"]
> [--gateway=GATEWAY] [--macaddress="MACADDRESS"]
> -[--mtu=MTU]
> +[--mtu=MTU] [--vlan=VLAN]
> Adds INTERFACE inside CONTAINER and connects it as a
> port
> in Open vSwitch BRIDGE. Optionally, sets ADDRESS on
> INTERFACE. ADDRESS can include a '/' to represent
> network
> -prefix length. Optionally, sets a GATEWAY, MACADDRESS
> -and MTU. e.g.:
> +prefix length. Optionally, sets a GATEWAY, MACADDRESS,
> +MTU, and VLAN. e.g.:
> ${UTIL} add-port br-int eth1 c474a0e2830e
> --ipaddress=192.168.1.2/24 --gateway=192.168.1.1
> ---macaddress="a2:c3:0d:49:7f:f8" --mtu=1450
> +--macaddress="a2:c3:0d:49:7f:f8" --mtu=1450 --vlan=10
>del-port BRIDGE INTERFACE CONTAINER
> Deletes INTERFACE inside CONTAINER and removes its
> connection to Open vSwitch BRIDGE. e.g.:
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] cannot find v4 of DNAT changes in mailing list
Hello Flavio, It does exist in the archives: http://openvswitch.org/pipermail/dev/2016-June/072565.html Probably ended up in your spam folder? Thanks, Guru On 13 June 2016 at 13:12, Flaviof wrote: > Hi Guru, > > For some odd reason the v4 of your changes in patchwork [v4] > does not seem to be visible via the mailing list. Is that because you > submitted it via GitHub?!? > > Thanks, > > -- flaviof > > [v4]: https://patchwork.ozlabs.org/patch/633069/ > > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v4] ovn: DNAT and SNAT on a gateway router.
On 9 June 2016 at 00:37, Gurucharan Shetty wrote:
> For traffic from physical space to virtual space we need DNAT.
> The DNAT happens in the gateway router and reaches the logical
> port. The return traffic should be unDNATed.
>
> Traffic originating in virtual space heading to physical space
> should be SNATed. The return traffic is unSNATted.
>
> East-west traffic with the public destination IP address needs
> a DNAT. This traffic is punted to the l3 gateway where DNAT
> takes place. This traffic is also SNATed and eventually loops back to
> its destination. The SNAT is needed because we need the reverse traffic
> to go back to the l3 gateway and not short-circuit directly to the source.
>
> This commit introduces 4 new logical actions.
> 1. ct_snat: To send the packet through SNAT zone to unSNAT packets.
> 2. ct_snat(IP): To SNAT to the provided IP address.
> 3. ct_dnat: To send the packet throgh DNAT zone to unDNAT packets.
> 4. ct_dnat(IP): To DNAT to the provided IP.
>
> This commit only provides the ability to do IP based NAT. This will
> eventually be enhanced to do PORT based NAT too.
>
> Command hints:
>
> Consider a distributed router "R1" that has switch foo (192.168.1.0/24)
> with a lport foo1 (192.168.1.2) and bar (192.168.2.0/24) with lport bar1
> (192.168.2.2) connected to it. You connect "R1" to
> a gateway router "R2" via a switch "join" in (20.0.0.0/24) network.
>
> R2 has a switch "alice" (172.16.1.0/24) connected to it (to simulate
> external network).
>
> case: Add pure DNAT (north-south)
>
> Add a DNAT rule in R2:
> ovn-nbctl -- --id=@nat create nat type="dnat" logical_ip=192.168.1.2 \
> external_ip=30.0.0.2 -- add logical_router R2 nat @nat
>
> Now alice1 should be able to ping 192.168.1.2 via 30.0.0.2.
>
> case2 : Add pure SNAT (south-north)
>
> Add a SNAT rule in R2:
>
> ovn-nbctl -- --id=@nat create nat type="snat" logical_ip=192.168.2.2 \
> external_ip=30.0.0.1 -- add logical_router R2 nat @nat
>
> (You need a static route in R1 to send packets destined to outside
> world to go through R2. The logical_ip can be a subnet.)
>
> When bar1 pings alice1, alice1 receives traffic from 30.0.0.1
>
> One could combine case1 and case2 with nat type="dnat_and_snat"
> if the IP addresses are the same.
>
> case3 : SNAT and DNAT (east-west traffic)
>
> When bar1 pings 30.0.0.2, the traffic jumps to the gateway router
> and loops back to foo1 with a source ip address of 30.0.0.1
>
> Signed-off-by: Gurucharan Shetty
> ---
> v3->v4:
> 1. Added unit tests and updated documentation based on blp's comments.
> 2. Changed schema to make it easier for OpenStack users.
>
This patch no longer applies on the tip of the master branch because of a
merge conflict. So for easier reference, I rebased it and pushed it here:
https://github.com/shettyg/ovs/tree/gateway
>
> ---
> ovn/lib/actions.c | 83
> ovn/northd/ovn-northd.8.xml | 131 ---
> ovn/northd/ovn-northd.c | 187
> ++--
> ovn/ovn-nb.ovsschema| 19 -
> ovn/ovn-nb.xml | 65 +--
> ovn/ovn-sb.xml | 41 ++
> ovn/utilities/ovn-nbctl.c | 5 ++
> tests/ovn.at| 17
> 8 files changed, 524 insertions(+), 24 deletions(-)
>
> diff --git a/ovn/lib/actions.c b/ovn/lib/actions.c
> index 5f0bf19..4a486a0 100644
> --- a/ovn/lib/actions.c
> +++ b/ovn/lib/actions.c
> @@ -442,6 +442,85 @@ emit_ct(struct action_context *ctx, bool recirc_next,
> bool commit)
> add_prerequisite(ctx, "ip");
> }
>
> +static void
> +parse_ct_nat(struct action_context *ctx, bool snat)
> +{
> +const size_t ct_offset = ctx->ofpacts->size;
> +ofpbuf_pull(ctx->ofpacts, ct_offset);
> +
> +struct ofpact_conntrack *ct = ofpact_put_CT(ctx->ofpacts);
> +
> +if (ctx->ap->cur_ltable < ctx->ap->n_tables) {
> +ct->recirc_table = ctx->ap->first_ptable + ctx->ap->cur_ltable +
> 1;
> +} else {
> +action_error(ctx,
> + "\"ct_[sd]nat\" action not allowed in last table.");
> +return;
> +}
> +
> +if (snat) {
> +ct->zone_src.field = mf_from_id(MFF_LOG_SNAT_ZONE);
> +} else {
> +ct->zone_src.field = mf_from_id(MFF_LOG_DNAT_ZONE);
> +}
> +ct->zone_src.ofs = 0;
> +ct->zone_src.n_bits = 16;
> +ct->flags = 0;
> +ct->alg = 0;
> +
> +add_prerequisite(ctx, "ip");
> +
> +struct ofpact_nat *nat;
> +size_t nat_offset;
> +nat_offset = ctx->ofpacts->size;
> +ofpbuf_pull(ctx->ofpacts, nat_offset);
> +
> +nat = ofpact_put_NAT(ctx->ofpacts);
> +nat->flags = 0;
> +nat->range_af = AF_UNSPEC;
> +
> +int commit = 0;
> +if (lexer_match(ctx->lexer, LEX_T_LPAREN)) {
> +ovs_be32 ip;
> +if (ctx->lexer->token.type == LEX_T_INTEGER
> +&& ctx->lexer->token.format == LEX_F_IPV4) {
> +ip = ctx->lexer->token.value.ipv4;
> +} else {
> +act
