summaryrefslogtreecommitdiff
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* ovn-northd: Fix the HA_Chassis sync issue in OVN SB DBNuman Siddique2019-04-252-17/+84
| | | | | | | | | | | | | | | | | | | | | ovn-northd deletes and recreates HA_Chassis rows (which belong to a HA_Chassis_Group) whenever the HA_Chassis_Group/Gateway_Chassis rows in Northbound DB are out of sync. If a Chassis table row in Southbound DB is deleted and if this row is referenced by HA_Chassis row (in Southbound DB), then the present code syncs the HA_Chassis rows continously and this causes the ovn-controller's to wake up and results in 100% cpu usage. This was a simple case which the commit 1be1e0e5e0d1 ("ovn: Add generic HA chassis group") missed out addressing. This patch fixes this issue. Fixes: 1be1e0e5e0d1 ("ovn: Add generic HA chassis group") Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2019-April/048580.html Reported-by: Daniel Alvarez Sanchez (dalvarez@redhat.com) Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: Add support for Transport ZonesLucas Alvares Gomes2019-04-221-0/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is adding support for Transport Zones. Transport zones (a.k.a TZs) is way to enable users of OVN to separate Chassis into different logical groups that will only form tunnels between members of the same groups. Each Chassis can belong to one or more Transport Zones. If not set, the Chassis will be considered part of a default group. Configuring Transport Zones is done by creating a key called "ovn-transport-zones" in the external_ids column of the Open_vSwitch table from the local OVS instance. The value is a string with the name of the Transport Zone that this instance is part of. Multiple TZs can be specified with a comma-separated list. For example: $ sudo ovs-vsctl set open . external-ids:ovn-transport-zones=tz1 or $ sudo ovs-vsctl set open . external-ids:ovn-transport-zones=tz1,tz2,tz3 This configuration is also exposed in the Chassis table of the OVN Southbound Database in a new column called "transport_zones". The use for Transport Zones includes but are not limited to: * Edge computing: As a way to preventing edge sites from trying to create tunnels with every node on every other edge site while still allowing these sites to create tunnels with the central node. * Extra security layer: Where users wants to create "trust zones" and prevent computes in a more secure zone to communicate with a less secure zone. This patch is also backward compatible so the upgrade guide for OVN [0] is still valid and the ovn-controller service can be upgraded before the OVSDBs. [0] http://docs.openvswitch.org/en/latest/intro/install/ovn-upgrades/ Reported-by: Daniel Alvarez Sanchez <dalvarez@redhat.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2019-February/048255.html Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb raft: Avoid unnecessary reconnecting during leader election.Han Zhou2019-04-221-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | If a server claims itself as "disconnected", all clients connected to that server will try to reconnect to a new server in the cluster. However, currently a server would claim itself as disconnected even when itself is the candidate and try to become the new leader (most likely it will be), and all its clients will reconnect to another node. During a leader fail-over (e.g. due to a leader failure), it is expected that all clients of the old leader will have to reconnect to other nodes in the cluster, but it is unnecessary for all the clients of a healthy node to reconnect, which could cause more disturbance in a large scale environment. This patch fixes the problem by slightly change the condition that a server regards itself as disconnected: if its role is candidate, it is regarded as disconnected only if the election didn't succeed at the first attempt. Related failure test cases are also unskipped and all passed with this patch. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb-cluster-testsuite.at: Restores "clustered transactions" tests back.Han Zhou2019-04-222-6/+2
| | | | | | | | | | In commit-2bcb3b70 (ovsdb raft: Move ovsdb cluster tests to separate testsuite.) the "clustered transactions" tests were left unexecuted because they depend on "EXECUTION_EXAMPLES", which is defined in ovsdb-execution.at. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Generate ICMPv4 packet in router pipeline for larger packetsNuman Siddique2019-04-221-0/+167
| | | | | | | | | | | | | | | | | | | | | This patch adds 2 stages in router pipeline after ARP_RESOLVE and adds the logical flows to check the packet length and generate ICMPv4 packet. * S_ROUTER_IN_CHK_PKT_LEN - Which checks the packet length using check_pkt_larger OVN action * S_ROUTER_IN_LARGER_PKTS - Which generates icmp packet with type 3 (Destination Unreachable), code 4 (Frag Needed and DF was Set) icmp4.frag_mtu = gw_mtu In order to add these logical flows, CMS should set the option 'gateway_mtu' for the distributed logical router port. Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Support OVS action 'check_pkt_larger' in OVNNuman Siddique2019-04-221-0/+13
| | | | | | | | | | | | | | | Previous commit added a new OVS action 'check_pkt_larger'. This patch supports that action in OVN. The syntax to use this would be reg0[0] = check_pkt_larger(LEN) Upcoming commit will make use of this action in ovn-northd and will generate an ICMPv4 packet if the packet length is greater than the specified length. Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Add a new OVN action 'icmp4_error'Numan Siddique2019-04-221-0/+15
| | | | | | | | | | | | This action is similar to the existing 'icmp4' OVN action except that that this action is expected to be used to generate an ICMPv4 packet in response to an error in original IP packet. When this action injects the icmpv4 packet, it also copies the original IP datagram following the icmp4 header as per RFC 1122: 3.2.2 Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Add a new OVN field icmp4.frag_mtuNuman Siddique2019-04-222-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support OVN specific fields (which are not yet supported in OpenvSwitch to set or modify values) a generic OVN field support is added in this patch. These OVN fields gets translated to controller actions. This patch adds only one field for now - icmp4.frag_mtu. It should be fairly straightforward to add similar fields in the near future. Example usage. action=(icmp4 {"eth.dst <-> eth.src; " "icmp4.type = 3; /* Destination Unreachable */ " "icmp4.code = 4; /* Fragmentation Needed */ " icmp4.frag_mtu = 1442; ... "next; };") action=(icmp4.frag_mtu = 1500; ..) pinctrl module of ovn-controller will set the specified value in the the low-order 16 bits of the ICMP4 header field that is labelled "unused" in the ICMP specification as defined in the RFC 1191. Upcoming patch will use it to send an icmp4 packet if the source IPv4 packet destined to go via external gateway needs to be fragmented. Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Add a new OVS action check_pkt_largerNuman Siddique2019-04-223-0/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new action 'check_pkt_larger' which checks if the packet is larger than the given size and stores the result in the destination register. Usage: check_pkt_larger(len)->REGISTER Eg. match=...,actions=check_pkt_larger(1442)->NXM_NX_REG0[0],next; This patch makes use of the new datapath action - 'check_pkt_len' which was recently added in the commit [1]. At the start of ovs-vswitchd, datapath is probed for this action. If the datapath action is present, then 'check_pkt_larger' makes use of this datapath action. Datapath action 'check_pkt_len' takes these nlattrs * OVS_CHECK_PKT_LEN_ATTR_PKT_LEN - 'pkt_len' to check for * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER (optional) - Nested actions to apply if the packet length is greater than the specified 'pkt_len' * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL (optional) - Nested actions to apply if the packet length is lesser or equal to the specified 'pkt_len'. Let's say we have these flows added to an OVS bridge br-int table=0, priority=100 in_port=1,ip,actions=check_pkt_larger:100->NXM_NX_REG0[0],resubmit(,1) table=1, priority=200,in_port=1,ip,reg0=0x1/0x1 actions=output:3 table=1, priority=100,in_port=1,ip,actions=output:4 Then the action 'check_pkt_larger' will be translated as - check_pkt_len(size=100,gt(3),le(4)) datapath will check the packet length and if the packet length is greater than 100, it will output to port 3, else it will output to port 4. In case, datapath doesn't support 'check_pkt_len' action, the OVS action 'check_pkt_larger' sets SLOW_ACTION so that datapath flow is not added. This OVS action is intended to be used by OVN to check the packet length and generate an ICMP packet with type 3, code 4 and next hop mtu in the logical router pipeline if the MTU of the physical interface is lesser than the packet length. More information can be found here [2] [1] - https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next/+/4d5ec89fc8d14dcdab7214a0c13a1c7321dc6ea9 [2] - https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html Suggested-by: Ben Pfaff <blp@ovn.org> Signed-off-by: Numan Siddique <nusiddiq@redhat.com> CC: Ben Pfaff <blp@ovn.org> CC: Gregory Rose <gvrose8192@gmail.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* stream-ssl: Add support for TLS SNI (Server Name Indication).Ben Pfaff2019-04-162-0/+22
| | | | | | | | | | | This TLS extension, introduced in RFC 3546, allows the server to know what host the client believes it is contacting, the TLS equivalent of the Host: header in HTTP. Tested-by: Yifeng Sun <pkusunyifeng@gmail.com> Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com> Requested-by: Shivaram Mysore <smysore@servicefractal.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: add the possibility to configure a static IPv4/IPv6 address and dynamic MACLorenzo Bianconi2019-04-161-0/+14
| | | | | | | | | | | | | | | Add the possibility to configure a static IPv4 and/or IPv6 address and get MAC address dynamically allocated. This can be done using the following commands: $ovn-nbctl ls-add sw0 $ovn-nbctl set Logical-Switch sw0 other_config:subnet=192.168.0.0/24 $ovn-nbctl set Logical-switch sw0 other_config:ipv6_prefix=2001::0 $ovn-nbctl lsp-add sw0 lsp0 -- lsp-set-addresses lsp0 "dynamic 192.168.0.1 2001::1" Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Policy-based routing (PBR) in OVN.Mary Manohar2019-04-162-0/+429
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PBR provides a mechanism to configure permit/deny and reroute policies on the router. Permit/deny policies are similar to OVN ACLs, but exist on the logical-router. Reroute policies are needed for service-insertion and service-chaining. Currently, policies are stateless. To achieve this, a new table is introduced in the ingress pipeline of the Logical-router. The new table is between the ‘IP Routing’ and the ‘ARP/ND resolution’ table. This way, PBR can override routing decisions and provide a different next-hop. This Patch: a. Changes in OVN NB Schema to introduce a new table in the Logical router. b. Add commands to ovn-nbctl to add/delete/list routing policies. c. Changes in ovn-northd to process routing-policy configurations. A new table 'Logical_Router_Policy' has been added in the northbound schema. The table has the following columns: * priority: Rules with numerically higher priority take precedence over those with lower. * match: Uses the same expression language as the 'match' column of 'Logical_Flow' table in the OVN Southbound database. * action: allow/drop/reroute nexthop: Nexthop IP address. Each row in this table represents one routing policy for a logical router. The 'action' column for the highest priority matching row in this table determines a packet's treatment. If no row matches, packets are allowed by default. The new ovn-nbctl commands are as follows: 1. Add a new ovn-nbctl command to add a routing policy. lr-policy-add ROUTER PRIORITY MATCH ACTION [NEXTHOP] Nexthop is an optional parameter. It needs to be provided only when 'action' is 'reroute'. A policy is uniquely identified by priority and match. Multiple policies can have the same priority. 2. Add a new ovn-nbctl command to delete a routing policy. lr-policy-del ROUTER [PRIORITY [MATCH]] Takes priority and match as optional parameters. If priority and match are specified, the policy with the given priority and match is deleted. If priority is specified and match is not specified, all rules with that priority are deleted. If priority is not specified, all the rules would be deleted. 3. Add a new ovn-nbctl command to list routing-policies in the logical router. lr-policy-list ROUTER ovn-northd changes are to get routing-policies from northbound database and populate the same as logical flows in the southbound database. A new table called 'POLICY' is introduced in the Logical router's ingress pipeline. Each routing-policy configured in the northbound database translates into a single logical flow in the new table. The columns from the Logical_Router_Policy table are used as follows: The priority column is used as priority in the logical-flow. The match column is used as the 'match' string in the logical-flow. The action column is used to determine the action of the logical-flow. When the 'action' is reroute, if the nexthop ip-address is a connected router port or the IP address of a logical port, the logical-flow is constructed to route the packet to the nexthop ip-address. Signed-off-by: Mary Manohar <mary.manohar@nutanix.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Support a new Logical_Switch_Port.type - 'external'Numan Siddique2019-04-162-8/+824
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of OpenStack + OVN, when the VMs are booted on hypervisors supporting SR-IOV nics, there are no OVS ports for these VMs. When these VMs sends DHCPv4, DHPCv6 or IPv6 Router Solicitation requests, the local ovn-controller cannot reply to these packets. OpenStack Neutron dhcp agent service needs to be run to serve these requests. With the new logical port type - 'external', OVN itself can handle these requests avoiding the need to deploy any external services like neutron dhcp agent. To make use of this feature, CMS has to - create a logical port for such VMs - set the type to 'external' - create an HA chassis group and associate the logical port to it or associate an already existing HA chassis group. - create a localnet port for the logical switch - configure the ovn-bridge-mappings option in the OVS db. HA chassis with the highest priority becomes the master of the HA chassis group and the ovn-controller running in that 'chassis', claims the Port_Binding for that logical port and it adds the necessary DHCPv4/v6 OF flows. Since the packet enters the logical switch pipeline via the localnet port, the inport register (reg14) is set to the tunnel key of localnet port in the match conditions. In case the chassis goes down for some reason, next higher priority HA chassis becomes the master and claims the port. When the VM with the external port, sends an ARP request for the router ips, only the chassis which has claimed the port, will reply to the ARP requests. Rest of the chassis on receiving these packets drop them in the ingress switch datapath stage - S_SWITCH_IN_EXTERNAL_PORT which is just before S_SWITCH_IN_L2_LKUP. This would guarantee that only the chassis which has claimed the external ports will run the router datapath pipeline. Acked-by: Mark Michelson <mmichels@redhat.com> Acked-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-northd: Delete the references to gateway_chasss in SB DBNuman Siddique2019-04-162-31/+376
| | | | | | | | | | | | | | | | | | Previous patch in the series added the support in ovn-controller to use ha_chassis_group table in SB DB to support HA chassis and establishing BFD tunnels instead of the gateway_chassis table. There is no need for ovn-northd to create any gateway_chassis rows in SB DB. This patch does that and deletes the code which is not required anymore. This patch also now supports 'ha_chassis_group' to be associated with a distributed logical router port and ignores 'gateway_chassis' and 'redirect-chassis' if set along with 'ha_chassis_group'. Acked-by: Mark Michelson <mmichels@redhat.com> Acked-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Add generic HA chassis groupNuman Siddique2019-04-162-29/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the tables - 'HA_Chassis_Group' and 'HA_Chassis' in both OVN Northbound and Southbound DBs to support generic HA Chassis groups in OVN. CMS can create a group of HA chassis with the priorities assigned to each chassis in the group. An HA chassis group can be associated to a distributed logical router port. An upcoming patch will make use of it while supporting 'external'* logical ports. HA chassis group is similar to the existing gateway chassis support in OVN which is used by the distributed gateway router ports. This patch tries to abstract this so that, the HA chassis support can be leveraged by not just distributed gateway router ports. If a logical router port has a set of gateway chassis associated to it, ovn-northd will create HA chassis group in Southbound DB and add these gateway chassis to this group. ovn-northd would still create gateway chassis in Southbound DB as ovn-controller still doesn't support using the HA chassis group. Next patch in the series will add the support in ovn-controller to make use of HA chassis group instead of gateway chassis. The patch following that will delete creation of gateway chassis in Southbound DB. HA_Chasss_Group table in Southbound DB has a column - 'ref_chassis'. This column is used to store the list of chassis which references the HA chassis group. This information will be used by ovn-controller in an upcoming patch to establish BFD sessions with the required chassis. Suppose if there is an HA chassis group - 'hagrp1' in the Southbound DB and it has HA chasiss list - ha1, ha2 and ha3 and this HA chassis group is used by a distributed logical router port, then ovn-northd will update the 'ref_chassis' with the list of chassis which has claimed all the logical switch ports which are connected to the logical router which has this distributed logical router port. Acked-by: Han Zhou <hzhou8@ebay.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb raft: Fix duplicated transaction execution when leader failover.Han Zhou2019-04-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a transaction is submitted from a client connected to a follower, if leader crashes after receiving the execute_command_request from the follower and sending out append request to the majority of followers, but before sending execute_command_reply to the follower. The transaction would finally got commited by the new leader. However, with current implementation the transaction would be commited twice. For the root cause, there are two cases: Case 1, the connected follower becomes the new leader. In this case, the pending command of the follower will be cancelled during its role changing to leader, so the trigger for the transaction will be retried. Case 2, another follower becomes the new leader. In this case, since there is no execute_command_reply from the original leader (which has crashed), the command will finally timed out, causing the trigger for the transaction retried. In both cases, the transaction will be retried by the server node's trigger retrying logic. This patch fixes the problem by below changes: 1) A pending command can be completed not only by execute_command_reply, but also when the eid is committed, if the execute_command_reply never came. 2) Instead of cancelling all pending commands during role change, let the commands continue waiting to be completed when the eid is committed. The timer is increased to be twice the election base time, so that it has the chance to be completed when leader crashes. This patch fixes the two raft failure test cases previously disabled. See the test case for details of how to reproduce the problem. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb raft: Test cases for cluster failures when there are pending transactions.Han Zhou2019-04-151-0/+173
| | | | | | | | | | | | | | | | | | | | | | | | | Implement test cases for the failure scenarios when there are pending transactions from clients. This patch implements test cases for different combinations of conditions with the help of previously added test commands and options for cluster mode. The conditions include: - Connected node from which client transaction is executed: leader, follower - Crashed node: leader, follower that is connected, or the other follower - Crash point: - For leader: - before/after receiving execute_command_request - before/after sending append_request - before/after sending execute_command_reply - For follower: - before/after sending execute_command_request - after receiving append_request There are 16 test cases in total, and 9 of them are skipped purposely because of the bugs found by the test cases to avoid CI failure. They will be enabled in coming patches when the corresponding bugs are fixed. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb raft: Sync commit index to followers without delay.Han Zhou2019-04-151-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When update is requested from follower, the leader sends AppendRequest to all followers and wait until AppendReply received from majority, and then it will update commit index - the new entry is regarded as committed in raft log. However, this commit will not be notified to followers (including the one initiated the request) until next heartbeat (ping timeout), if no other pending requests. This results in long latency for updates made through followers, especially when a batch of updates are requested through the same follower. $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done real 0m34.154s user 0m0.083s sys 0m0.250s This patch solves the problem by sending heartbeat as soon as the commit index is updated in leader. It also avoids unnessary heartbeat by resetting the ping timer whenever AppendRequest is broadcasted. With this patch the performance is improved more than 50 times in same test: $ time for i in `seq 1 100`; do ovn-nbctl ls-add ls$i; done real 0m0.564s user 0m0.080s sys 0m0.199s Torture test cases are also updated because otherwise the tests will all be skipped because of the improved performance. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb raft: Move ovsdb cluster tests to separate testsuite.Han Zhou2019-04-153-2/+37
| | | | | | | | | | | Tests in ovsdb-cluster.at are relatively slow, especially torture tests, and they will be changed in the future costing high CPU, to make the tests more effective. So we move the tests to a separate testsuite, so that we can execute them separately, probably with lower parallelism to avoid exhausting system resources. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb.at: Move ovsdb macros from ovsdb.at to ovsdb-macros.at.Han Zhou2019-04-152-137/+137
| | | | | Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* windows, tests: Allow tests to run on MSYS2Alin Gabriel Serdean2019-04-091-1/+1
| | | | | Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* checkpatch: Normalize exit code for WindowsAlin Gabriel Serdean2019-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using python `sys.exit(-1)` on Windows produces mixed results. Let's take the following results from different shells: CMD >python -c "import sys; sys.exit(-1)" & echo %errorlevel% 1 MSYS $ python -c "import sys; sys.exit(-1)" && echo $? 0 WSL $ python -c "import sys; sys.exit(-1)"; echo $? 255 this results in the following tests to fail: checkpatch 10: checkpatch - sign-offs FAILED (checkpatch.at:32) 11: checkpatch - parenthesized constructs FAILED (checkpatch.at:32) 12: checkpatch - parenthesized constructs - for FAILED (checkpatch.at:32) 13: checkpatch - comments FAILED (checkpatch.at:32) because of: ./checkpatch.at:32: exit code was 0, expected 255 This patch introduces a positive constant for the default exit code (1) similar to other OVS utilities. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org> Acked-by: Aaron Conole <aconole@redhat.com>
* odp-util: Do not rewrite fields with the same values as matchedEli Britstein2019-03-252-8/+8
| | | | | | | | | To improve performance and avoid wasting resources for HW offloaded flows, do not rewrite fields that are matched with the same value. Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Eli Britstein <elibr@mellanox.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: Make periodic RAs consistent with RA responder.Mark Michelson2019-03-251-1/+1
| | | | | | | | | | | | This commit makes periodic RAs from OVN consistent with the RAs sent in response to RSs. Specifically, this ensures that prefix flags are set correctly for each address mode. This commit also gets rid of some redundant definitions for RA prefix option flags from packets.h in favor of the ones in ovn-l7.h. Signed-off-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: Always send prefix option in RAsMark Michelson2019-03-251-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVN's behavior when sending router advertisements has been to include IP prefix information only if the address mode is set to "slaac" or "dhcp_stateless". In these modes, sending the prefix to the client is necessary so that it may automatically provision its IP address. We do not send the prefix option when the address mode is set to "dhcp_stateful" since there is no need for the client to automatically provision an IP address. This logic is flawed, however. When using dhcp_stateful, we provide a managed IPv6 address for a client. However, because we do not provide prefix information in our RAs, the client does not know the prefix length for the address it has been allocated. With dhclient, we have seen it assume either /64 or /128, depending on which version is being used. This may not accurately reflect the prefix length being used by the DHCP server though. The fix here is to always send prefix information in our RAs, regardless of address mode. The key difference lies in how we set the A (autonomous addressing) flag. For slaac and dhcp_stateless address modes, we will set this flag, indicating the client should provision its own address based on the prefix we have sent. For dhcp_stateful, we will not set this flag. This way, it is clear the prefix is informational, and the client should not try to provision its own IPv6 address. Signed-off-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* tests: Remove maximum version kernel check.Darrell Ball2019-03-253-15/+13
| | | | | | | | | | | | | | | | | | The macro 'OVS_CHECK_KERNEL' was checking for maximum supported kernel version. This means checks like 'OVS_CHECK_KERNEL(3, 10, 4, 18)' in various tests need to be updated when each new kernel version is supported. This is unnecessary as these tests are expected to continue to work in later kernel versions. Fix this by changing the macro to check for minimum version only and update the macro name accordingly. This patch does not make any possible corrections to the indicated minimum kernel version specified by the callers of the macro. Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com> Signed-off-by: Darrell Ball <dlu998@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: fix the bug of bucket counter is not updatedLi Wei2019-03-251-0/+16
| | | | | | | | | | | | | | | | | | After inserting/removing a bucket, we don't update the bucket counter. When we call ovs-ofctl dump-group-stats br-int, a panic happened. Reproduce steps: 1. ovs-ofctl -O OpenFlow15 add-group br-int "group_id=1, type=select, selection_method=hash bucket=bucket_id=1,weight:100,actions=output:1" 2. ovs-ofctl insert-buckets br-int "group_id=1, command_bucket_id=last, bucket=bucket_id=7,weight:800,actions=output:1" 3. ovs-ofctl dump-group-stats br-int gdb) bt at ../sysdeps/posix/libc_fatal.c:175 ar_ptr=<optimized out>) at malloc.c:5049 group_id=<optimized out>, cb=cb@entry=0x55cab8fd6cd0 <append_group_stats>) at ofproto/ofproto.c:6790 Signed-off-by: solomon <liwei.solomon@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* python: Monitor Database table to manage lifecycle of IDL client.Ted Elhourani2019-03-222-31/+165
| | | | | | | | | | | | | | | | | | | | | | | | The Python IDL implementation supports ovsdb cluster connections. This patch is a follow up to commit 31e434fc98, it adds the option of connecting to the leader (the default) in the Raft-based cluster. It mimics the exisiting C IDL support for clusters introduced in commit 1b1d2e6daa. The _Server database schema is first requested, then a monitor of the Database table in the _Server Database. Method __check_server_db verifies the eligibility of the server. If the attempt to obtain a monitor of the _Server database fails and a cluster id was not provided this implementation proceeds to request the data monitor. If a cluster id was provided via the set_cluster_id method then the connection is aborted and a connection to a different node is instead attempted, until a valid cluster node is found. Thus, when supplied, cluster id is interpreted as the intention to only allow connections to a clustered database. If not supplied, connections to standalone nodes, or nodes that do not have the _Server database are allowed. change_seqno is not incremented in the case of Database table updates. Acked-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ted Elhourani <ted.elhourani@nutanix.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* dpif-netdev.at: Add basic test for partial HW offloading.Ilya Maximets2019-03-131-0/+74
| | | | | | | | Simple test for basic partial HWOL functionality. Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@samsung.com> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
* OVN: Add support for DHCP option 150 - TFTP server addressLucas Alvares Gomes2019-03-072-3/+4
| | | | | | | | | | | | | | | | | OpenStack Ironic relies on a few DHCP options [0] that were not supported in OVN yet. This patch is adding the last one which is the option 150 (TFTP server address, RFC5859 [1]). Note that this option is Cisco proprietary, the IEEE standard that matches with this requirement is Option 66. The difference is that 150 allows to multiple IPs to be specified and 66 only allows one. [0] https://github.com/openstack/ironic/blob/3f6d4c6a789b12512d6cc67cdbc93ba5fbf29848/ironic/common/pxe_utils.py#L44-L54 [1] https://tools.ietf.org/html/rfc5859 Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: Add support for DHCP option 210 - path prefixLucas Alvares Gomes2019-03-072-3/+4
| | | | | | | | | | | | OpenStack Ironic relies on few DHCP options [0] that are not yet supported in OVN, one of them is the 210 (PATH PREFIX, RFC5071 [1]). [0] https://github.com/openstack/ironic/blob/3f6d4c6a789b12512d6cc67cdbc93ba5fbf29848/ironic/common/pxe_utils.py#L44-L54 [1] https://tools.ietf.org/html/rfc5071#section-5 Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: select a random mac_prefix if not providedLorenzo Bianconi2019-03-051-0/+13
| | | | | | | | | | | | | | Select a random IPAM mac_prefix if it has not been provided by the user. With this patch the admin can avoid to configure mac_prefix in order to avoid L2 address collisions if multiple OVN deployments share the same broadcast domain. Remove MAC_ADDR_PREFIX definitions/occurrences since now mac_prefix is always provided to ovn-northd Acked-by: Numan Siddique <nusiddiq@redhat.com> Tested-by: Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovsdb-monitor: Support monitor_cond_since.Han Zhou2019-02-281-1/+300
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* oss-fuzz: Fix oss build errors because of ovs API changeYifeng Sun2019-02-271-2/+3
| | | | | | Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13432 Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-nbctl: Add lsp-get-ls commandLucas Alvares Gomes2019-02-271-0/+14
| | | | | | | | | | | | This commit adds the following command: lsp-get-ls: Get the logical switch which the port belongs to. This command is handy for scripting since there's no logical switch id in the Logical_Switch_Port table. Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* conntrack: Skip ephemeral ports with specified port range.Darrell Ball2019-02-251-0/+50
| | | | | | | | | | | | | | | This patch removes the fallback to ephemeral ports when a SNAT port range is specified; DNAT already does not fallback to ephemeral ports, in general. This is not restrictive to the user and makes it easier to limit NAT L4 port selection. The documentation is updated and a new test is added to enforce the behavior. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-February/356607.html Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.") Signed-off-by: Darrell Ball <dlu998@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* odp-util: Improve log messages and error reporting for Netlink parsing.Ben Pfaff2019-02-254-13/+21
| | | | | | | | As a side effect, this also reduces a lot of log messages' severities from ERR to WARN. They just didn't seem like messages that in general reported anything that would prevent functioning. Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-controller: Provide the option to set the datapath-type of br-intNuman Siddique2019-02-221-0/+14
| | | | | | | | | | | | If the integration bridge is deleted, ovn-controller recreates it but the previous datapath-type value is lost if it was set. This patch adds the code in ovn-controller to set the datapath-type if it is configured by the user in the 'external_ids:ovn-bridge-datapath-type' column of OpenvSwitch table. Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* tests: Fix udp checksums for some tests.Darrell Ball2019-02-223-21/+4
| | | | | | | Also, enable the kernel side tests since these will pass now. Signed-off-by: Darrell Ball <dlu998@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-nbctl: Daemon mode should retry when IDL connection lost.Han Zhou2019-02-221-0/+8
| | | | | | | | | | | | | | | When creating IDL, "retry" was set to false. However, in daemon mode, reconnecting upon DB server failure should be transparent to user. This even impacts HA mode. E.g. in clustered mode, although IDL tries to connect to next server, but at the first retry the server fail-over may not be completed yet, and it stops retry after N (N = number of remotes) times. This patch makes sure in daemon mode retry is set to true so that the daemon will automatically retry forever. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Add a simple test to check port binding when "encap-ip" external_ids is set.root2019-02-221-0/+180
|
* Support for multiple VTEP in OVNvenu iyer2019-02-221-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVN uses tunnels to achieve logical network connectivity. The tunnel IP to be used when communicating with a node is configured using an external_ids field called "ovn-encap-ip" (and "ovn-encap-type" to indicate the type of tunnel - geneve, vxlan, stt). The fact that "ovn-encap-ip" is a single IP is significantly limiting when used in certain scenarios. Primarly, if we have multiple NICs on a system and want to assign SR-IOV VFs from different NICs to a guest (as logical ports), then we'll still end up using the "ovn-encap-ip" to encapsulate traffic from different VFs. This means we'll end up using only one NIC on the physical, thereby not maintaining the VF-PF association while also not using all the physical NICs. It is possible to bond all the NICs and use the bond IP as the "encap-ip", but bonding multiple NICs has its own limitations, i.e. NICs supporting OVS flows offload don't work with bonding - this severly undermines SR-IOV use with OVS (i.e. if all the processing needs to be done in the host despite giving VFs to guests). +-------------------------------------------------------+ +-------------------------~ |Hypervisor I (chassis-ID = HV1) | |Hypervisor II | | | |+----------------------+ | | || guest | | | || | | | |+-------|----------|---+ | | (ovn-chassis-id) | | | vf0_rep +-------+ | | +-------+ | | | encap-ip=IP1 | | | | (HV1@IP1) | | | |------------------------------| |-------------------------------| | | | | |br-int | | | |br-int | | | | vf0_rep | | | | (HV1@IP2) | | | | | encap-ip=IP2 | |-------------------------------| | | | |-------------------| | | | | +-------+ | | | +-------+ | | | | |vf0 |vf0 | | | | +---------+ +---------+ | | | +---| nic1 |--| nic2 |----------------------------+ | +--------------------------~ +---------+ +---------+ V | | Tunnel Ports |pf=IP1 |pf=IP2 between Hypervisors. Note: The above uses a NIC that supports OVS with SR-IOV (e.g. Mellanox CX-5) which uses a "representor" to plug in a VF to the OVS bridge. This patch enables a list of comma separated IP addresses to be specified in "ovn-encap-ip", thus allowing the node to be reached via any IP combined with the "ovn-encap-type" - assuming physical routing allows that. Additionally, it also introduces an way to specify the encap IP to be used for a logical port (so that the VF-PF mapping is maintained when traversing the logical path over a tunnel). A new "encap-ip" external_ids can be configured on an Interface to indicate this. On the SB these changes appear as an additional column in port_bindings as "encap". The encap record for a port points to an encap record on its chassis. If the port is not explicitly associated with an encap-ip (using external_ids), the encap record is empty, which means the preferred tunnel will be used to reach the port's chassis. The intention is also to have no functional changes in the default case, i.e when there is only one "ovn-encap-ip". The changes have been tested with multiple encap-ip addresses, SR-IOV and for backwards compatibality (in the case where there is only one ovn-encap-ip) with an OVN SB that doesn't include these changes.
* checkpatch: Escape range operators inside regex.Ilya Maximets2019-02-221-0/+18
| | | | | | | | | | | | | | | | | | | | | ' -(' matches a single character in the range between ' ' (index 32) and '(' (index 40). This leads to the false positive: WARNING: Line lacks whitespace around operator #445 FILE: ovsdb/monitor.c:573: if (--mcs->n_refs == 0) { Need to escape '-' to have a right behaviour. This patch additionally escapes all other '-' chars in the similar regexes and makes them be one per line to ease the review in case of future changes. Basic unit tests added. CC: Joe Stringer <joe@ovn.org> Fixes: 0d7b16daea50 ("checkpatch: Check for infix operator whitespace.") Signed-off-by: Ilya Maximets <i.maximets@samsung.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Userspace datapath: Add fragmentation handling.Darrell Ball2019-02-143-46/+237
| | | | | | | | | | | | | | | | Fragmentation handling is added for supporting conntrack. Both v4 and v6 are supported. After discussion with several people, I decided to not store configuration state in the database to be more consistent with the kernel in future, similarity with other conntrack configuration which will not be in the database as well and overall simplicity. Accordingly, fragmentation handling is enabled by default. This patch enables fragmentation tests for the userspace datapath. Signed-off-by: Darrell Ball <dlu998@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* tests: Add missed local stack checks.Darrell Ball2019-02-141-0/+2
| | | | | | Acked-by: Justin Pettit <jpettit@ovn.org> Signed-off-by: Darrell Ball <dlu998@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* monitor: Fix crash when monitor condition adds new columns.Han Zhou2019-02-141-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: change load balancer references to weak in NB schemaDaniel Alvarez2019-02-111-1/+9
| | | | | | | | | | | | | | | | | | | | When a load balancer is added to multiple logical switches and routers it has be to be removed from all of them before being able to delete due to the current 'strong' reference in the NB schema. By changing it to 'weak', users can simply remove the load balancer without having to remove all the references manually. In particular, this will make things easier for networking-ovn, the OpenStack integration project as it'll save some calculations upon load balancer deletion. The update path has been successfully from the previous version of the schema. Acked-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Signed-off-by: Daniel Alvarez <dalvarez@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Remove support for OpenFlow 1.6 (draft).Ben Pfaff2019-02-055-165/+54
| | | | | | | | | ONF abandoned the OpenFlow specification, so that OpenFlow 1.6 will never be completed. It did not contain much in the way of useful features, so remove what support Open vSwitch already had. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Justin Pettit <jpettit@ovn.org>
* Fix OpenFlow v1.3.4 Conf test failures: 430.500, 430.510psiyengar2019-02-041-0/+14
| | | | | | | | | | This commit adds additional verification to nx_pull_header__() in lib/nx-match.c to distinguish between bad match and bad action header conditions and return the appropriate error type/code. Signed-off-by: Prashanth Iyengar <prashanth_iyengar@alliedtelesis.com> Reviewed-by: Tony van der Peet <tony.vanderpeet@alliedtelesis.co.nz> Reviewed-by: Rahul Gupta <Rahul_Gupta@alliedtelesis.com>
* datapath: Add support for kernel 4.18.xYifeng Sun2019-02-041-6/+6
| | | | | | | | | | | | | | No code changing is necessary to support 4.18.x. Only one kernel test failed and it is in the process of being fixed. Updated .travis.yml to include 4.18.x and also use latest 4.17 version. Updated test files to test 4.18 kernel. Tested-by: Greg Rose <gvrose8192@gmail.com> Reviewed-by: Greg Rose <gvrose8192@gmail.com> Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
View Lorry Controller Status