summaryrefslogtreecommitdiff
path: root/ovn/ovn-nb.ovsschema
Commit message (Collapse)AuthorAgeFilesLines
* ovn: support applying ACLs to port groupsHan Zhou2018-05-091-2/+7
| | | | | | | | | | | | | | | | Although port group can be used in match conditions of ACLs, it is still inconvenient for clients to figure out the lswitches that each ACL should be applied to. This patch supports applying ACLs to port groups directly instead of applying to each related lswitch individually. It provides convenience for clients such as k8s and OpenStack Neutron. Requested-at: https://mail.openvswitch.org/pipermail/ovs-dev/2018-March/344856.html Requested-by: Guru Shetty <guru@ovn.org> Requested-by: Daniel Alvarez Sanchez <dalvarez@redhat.com> Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Support port groups in ACLsHan Zhou2018-04-131-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables using port group names in ACL match conditions. Users can create a port group in northbound DB Port_Group table, and then use the name of the port group in ACL match conditions for "inport" or "outport". It can help reduce the number of ACLs for CMS clients such as OpenStack Neutron, for the use cases where a group of logical ports share same ACL rules except the "inport"/"outport" part. Without this patch, the clients have to create N (N = number of lports) ACLs, and this patch helps achieve the same goal with only one ACL. E.g.: to-lport 1000 "outport == @port_group1 && ip4.src == {IP1, IP2, ...}" allow-related There was a similar attempt by Zong Kai Li in 2016 [1]. This patch takes a slightly different approach by using weak refs instead of strings, which requires a new table instead of reusing the address set table. This way it will also benefit for a follow up patch that enables generating address sets automatically from port groups to avoid a lot a trouble from client perspective [2]. An extra benefit of this patch is that it could enable conjunctive match effectively. As reported at [3], this patch was tested together with the conjunctive match enhancement patch [4], and huge performance improvement (more than 10x faster) was seen because of this. [1] https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html [2] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-February/046260.html [3] https://mail.openvswitch.org/pipermail/ovs-dev/2018-March/344873.html [4] https://patchwork.ozlabs.org/patch/874433/ Reported-by: Daniel Alvarez Sanchez <dalvarez@redhat.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-February/046166.html Tested-by: Mark Michelson <mmichels@redhat.com> Reviewed-by: Mark Michelson <mmichels@redhat.com> Reviewed-by: Daniel Alvarez <dalvarez@redhat.com> Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: OVN Support QoS meterGuoshuai Li2018-01-241-3/+11
| | | | | | | | | | | | | | | | | This feature is used to limit the bandwidth of flows, such as floating IP. ovn-northd changes: 1. add bandwidth column in NB's QOS table. 2. add QOS_METER stages in Logical switch ingress/egress. 3. add set_meter() action in SB's LFlow table. ovn-controller changes: add meter_table for meter action process openflow meter table. Now, This feature is only supported in DPDK. Signed-off-by: Guoshuai Li <ligs@dtdream.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* OVN: Add external_ids to NAT and Logical_Router_Static_Route tables.Lucas Alvares Gomes2017-12-041-4/+10
| | | | | | | | | | The external_ids column is missing from the NAT and Logical_Router_Static_Route tables. Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Daniel Alvarez <dalvarez@redhat.com> Acked-by: Miguel Angel Ajo <majopela@redhat.com>
* ovn-northd: Add logical flows to support native IPv6 RAZongkai LI2017-11-021-2/+5
| | | | | | | | | | | | | | | | | | | | This patch adds logical flows which sends IPv6 Router Advertisement packet in response to the IPv6 Router Solicitation request. It uses the actions "put_nd_ra_opts" to transform the RS packet to RA packet in the newly added ingress stage "lr_in_nd_ra_options" in router pipeline. If the action "put_nd_ra_opts" is successful, it sends the RA packet back to the originating port in the next ingress stage "lr_in_nd_ra_response". A new column "ipv6_ra_configs" is added in the Logical_Router_Port table, which the CMS is expected to configure IPv6 RA configurations - "address_mode" and "mtu" for adding these flows. Co-authored-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Zongkai LI <zealokii@gmail.com> Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Acked-by: Miguel Angel Ajo <majopela@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Add support for ACL logging.Justin Pettit2017-07-281-3/+12
| | | | | | Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Han Zhou <zhouhan@gmail.com> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: l3ha, NBDB and SBDB changes and documentationmajopela@redhat.com2017-07-161-3/+25
| | | | | | | | | | | | | | | | | | | | | | | This commit introduces the north and south db changes necessary for the l3ha router implementation. It defines a new Table in both NBDB and SBDB. The Gateway_Chassis table is created, with a tiny difference between NBDB and SBDB, NBDB references the chassis via it's name (chassis_name) and SBDB references the chassis via reference (chassis) to the Chassis table. In NBDB a new column (gateway_chassis) is added to Logical_Router_Ports with a list of Gateway_Chassis which can be empty. In SBDB a new column (gateway_chassis) is added to Port_Binding with the same list, this column will be used for ports of type chassis-redirect. Bump minor version since we've added new backwards compatible features. Co-authored-by: Russell Bryant <russell@ovn.org> Signed-off-by: Miguel Angel Ajo <majopela@redhat.com> Signed-off-by: Russell Bryant <russell@ovn.org>
* ovn: ssl proto/cipher configuration in nb/sb dbLance Richardson2017-06-071-1/+3
| | | | | | | | | | | Add SSL protocol and cipher columns to SSL tables in northbound and southbound databases. Start nb/sb ovsdb-server with command- line options to use these columns. Add support to ovn-nbctl and ovn-sbctl "set-ssl" commands for user-friendly management of these settings. Signed-off-by: Lance Richardson <lrichard@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-northd: Add logical flows to support native DNSNuman Siddique2017-05-021-2/+18
| | | | | | | | | | | | | | | | | | | | | | OVN implements native DNS resolution which can be used to resolve the internal DNS names belonging to a logical datapath. To support this, a new table 'DNS' is added in the NB DB. A new column 'dns_records' is added in 'Logical_Switch' table which references to the 'DNS' table. Following flows are added for each logical switch if configured with DNS records in the 'dns_records' column - A logical flow in DNS_LOOKUP stage which uses the action 'dns_lookup' to transform the DNS query to DNS reply packet and advances to the next stage - DNS_RESPONSE. - A logical flow in DNS_RESPONSE stage which implements the DNS responder by sending the DNS reply from previous stage back to the inport. Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Acked-by: Gurucharan Shetty <guru@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Bump ovn-nb schema version.Russell Bryant2017-04-271-2/+2
| | | | | | | | | | | | | Commit b89d25e5694b made the "router" DHCPv4 option optional instead of mandatory. This did not actually change the schema, but there's no good way for a client of the northbound database to know if this change is present without bumping the schema version. This is needed for a client to work with versions before and after this change. Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1670666 Fixes: b89d25e5694b ("ovn: Modify the DHCPv4 router option to optional") Signed-off-by: Russell Bryant <russell@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: distributed NAT flowsMickey Spiegel2017-01-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the flows required in the ingress and egress pipeline stages in order to support NAT on a distributed logical router. NAT functionality is associated with the logical router gateway port. The flows that carry out NAT functionality all have match conditions on inport or outport equal to the logical router gateway port. There are additional flows that are used to redirect traffic when necessary, using the tunnel key of a "chassisredirect" SB port binding in order to redirect traffic to the instance of the logical router gateway port on the centralized "redirect-chassis". North/south traffic subject to one-to-one "dnat_and_snat" is handled in a distributed manner, with south-to-north traffic going to the local instance of the logical router gateway port. North/south traffic subject to (possibly one-to-many) "snat" is handled in a centralized manner, with south-to-north traffic going to the instance of the logical router gateway port on the "redirect-chassis". North-to-south traffic is directed to the corresponding chassis by limiting ARP responses to the appropriate instance of the logical router gateway port on one chassis. For centralized NAT rules, this is the instance on the "redirect-chassis". For distributed NAT rules, this is the chassis where the corresponding logical port resides, using an ethernet address specified in the NB NAT rule to trigger upstream MAC learning. East/west NAT traffic is all handled in a centralized manner. While it is certainly possible to handle some of this traffic in a distributed manner, the centralized approach keeps the NAT flows simpler and cleaner. The expectation is that east/west NAT traffic is not as important to optimize as north/south NAT traffic, with most east/west traffic not requiring NAT. Automated tests are currently limited to only a single node. The single node automated tests cover both north/south and east/west traffic flows. Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* ovn: Introduce distributed gateway port and "chassisredirect" port bindingMickey Spiegel2017-01-191-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently OVN distributed logical routers achieve reachability to physical networks by passing through a "join" logical switch to a centralized gateway router, which then connects to another logical switch that has a localnet port connecting to the physical network. This patch adds logical port and port binding abstractions that allow an OVN distributed logical router to connect directly to a logical switch that has a localnet port connecting to the physical network. In this patch, this logical router port is called a "distributed gateway port". The primary design goal of distributed gateway ports is to allow as much traffic as possible to be handled locally on the hypervisor where a VM or container resides. Whenever possible, packets from the VM or container to the outside world should be processed completely on that VM's or container's hypervisor, eventually traversing a localnet port instance on that hypervisor to the physical network. Whenever possible, packets from the outside world to a VM or container should be directed through the physical network directly to the VM's or container's hypervisor, where the packet will enter the integration bridge through a localnet port. However, due to the implications of the use of L2 learning in the physical network, as well as the need to support advanced features such as one-to-many NAT (aka IP masquerading), where multiple logical IP addresses spread across multiple chassis are mapped to one external IP address, it will be necessary to handle some of the logical router processing on a specific chassis in a centralized manner. For this reason, the user must associate a chassis with each distributed gateway port. In order to allow for the distributed processing of some packets, distributed gateway ports need to be logical patch ports that effectively reside on every hypervisor, rather than "l3gateway" ports that are bound to a particular chassis. However, the flows associated with distributed gateway ports often need to be associated with physical locations. This is implemented in this patch (and subsequent patches) by adding "is_chassis_resident()" match conditions to several logical router flows. While most of the physical location dependent aspects of distributed gateway ports can be handled by restricting some flows to specific chassis, one additional mechanism is required. When a packet leaves the ingress pipeline and the logical egress port is the distributed gateway port, one of two different sets of actions is required at table 32: - If the packet can be handled locally on the sender's hypervisor (e.g. one-to-one NAT traffic), then the packet should just be resubmitted locally to table 33, in the normal manner for distributed logical patch ports. - However, if the packet needs to be handled on the chassis associated with the distributed gateway port (e.g. one-to-many SNAT traffic or non-NAT traffic), then table 32 must send the packet on a tunnel port to that chassis. In order to trigger the second set of actions, the "chassisredirect" type of southbound port_binding is introduced. Setting the logical egress port to the type "chassisredirect" logical port is simply a way to indicate that although the packet is destined for the distributed gateway port, it needs to be redirected to a different chassis. At table 32, packets with this logical egress port are sent to a specific chassis, in the same way that table 32 directs packets whose logical egress port is a VIF or a type "l3gateway" port to different chassis. Once the packet arrives at that chassis, table 33 resets the logical egress port to the value representing the distributed gateway port. For each distributed gateway port, there is one type "chassisredirect" port, in addition to the distributed logical patch port representing the distributed gateway port. A "chassisredirect" port represents a particular instance, bound to a specific chassis, of an otherwise distributed port. A "chassisredirect" port is associated with a chassis in the same manner as a "l3gateway" port. However, unlike "l3gateway" ports, "chassisredirect" ports have no associated IP or MAC addresses, and "chassisredirect" ports should never be used as the "inport". Any pipeline stages that depend on port specific IP or MAC addresses should be carried out in the context of the distributed gateway port's logical patch port. Although the abstraction represented by the "chassisredirect" port binding is generalized, in this patch the "chassisredirect" port binding is only created for NB logical router ports that specify the new "redirect-chassis" option. There is no explicit notion of a "chassisredirect" port in the NB database. The expectation is when capabilities are implemented that take advantage of "chassisredirect" ports (e.g. distributed gateway ports), flows specifying a "chassisredirect" port as the outport will be added as part of that capability. Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-nb: remote connection management in nb dbLance Richardson2016-12-211-5/+48
| | | | | | | | | Add support for managing remote connections, including SSL configuration, to northbound db schema, and add necessary commands to ovn-nbctl. Signed-off-by: Lance Richardson <lrichard@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Add a case of policy based routing.Gurucharan Shetty2016-11-031-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVN currently supports multiple gateway routers (residing on different chassis) connected to the same logical topology. When external traffic enters the logical topology, they can enter from any gateway routers and reach its eventual destination. This is achieved with proper static routes configured on the gateway routers. But when traffic is initiated in the logical space by a logical port, we do not have a good way to distribute that traffic across multiple gateway routers. This commit introduces one particular way to do it. Based on the source IP address or source IP network of the packet, we can now jump to a specific gateway router. This is very useful for a specific use case of Kubernetes. When traffic is initiated inside a container heading to outside world, we want to be able to send such traffic outside the gateway router residing in the same host as that of the container. Since each host gets a specific subnet, we can use source IP address based policy routing to decide on the gateway router. Rationale for using the same routing table for both source and destination IP address based routing: Some hardware network vendors support policy routing in a different table on arbitrary "match". And when a packet enters, if there is a match in policy based routing table, the default routing table is not consulted at all. In case of OVN, we mainly want policy based routing for north-south traffic. We want east-west traffic to flow as-is. Creating a separate table for policy based routing complicates the configuration quite a bit. For e.g., if we have a source IP network based rule added, to decide a particular gateway router as a next hop, we should add rules at a higher priority for all the connected routes to make sure that east-west traffic is not effected in the policy based routing table itself. Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* DSCP marking on packetsBabu Shanmugam2016-10-051-2/+24
| | | | | | | | | | | This patch adds support for marking qos on IP packets based on arbitrary match criteria for a logical switch. Signed-off-by: Babu Shanmugam <bschanmu@redhat.com> Suggested-by: Mickey Spiegel <mickeys.dev@gmail.com> Acked-by: Mickey Spiegel <mickeys.dev@gmail.com> [blp@ovn.org fixes races in the test and added ovn-trace checks] Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-nbctl: Add LB commands.nickcooper-zhangtonghao2016-10-031-2/+3
| | | | | | | | | | | | | | This patch provides the command line to create a load balancer. You can create a load balancer independently and add it to multiple switches or routers. A single load balancer can have multiple vips. Add a name column for the load balancer. With --add-duplicate, the command really creates a new load balancer with a duplicate name. This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database. This patch also provides the unit tests and the documentation. Signed-off-by: nickcooper-zhangtonghao <nickcooper-zhangtonghao@opencloud.tech> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* ovn-northd: Tag allocation for nested containers.Gurucharan Shetty2016-09-091-2/+7
| | | | | | | | | When there are hundreds of nodes controlled by OVN, the workflow to track and allocate unique tags across multiple hosts becomes complicated. It is much easier to let ovn-northd do the allocation. Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn-northd: Add load-balancers to gateway routers.Gurucharan Shetty2016-09-091-2/+7
| | | | | | | | | | | | | | Load-balancers in gateway routers lets us load-balance north-south traffic. This commit adds a new table called "DEFRAG" in the logical router pipeline to defragment packets and to track them. Once the packet is tracked, new connections get a group id as an action. The group in turn chooses a DNAT action. Established connections go through the DNAT table for a regular DNAT. Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: Ability to set multiple load balancers.Gurucharan Shetty2016-08-151-2/+2
| | | | | | | | | | | The schema prevented one from setting more than one load balancer to a switch. This removes that anomaly. (The test has a slightly unrelated change where it increases the number of connections to get rid of some occasional unit test failures.) Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn-northd: Add logical flows to support DHCPv6Numan Siddique2016-08-141-2/+7
| | | | | | | | | | | | | | | | | | | OVN implements native DHCPv6. DHCPv6 options are stored in the 'DHCP_Options' NB table and logical ports refer to this table to configure the DHCPv6 options. For each logical port configured with DHCPv6 Options following flows are added - A logical flow which copies the DHCPv6 options to the DHCPv6 request packets using the 'put_dhcpv6_opts' action and advances the packet to the next stage. - A logical flow which implements the DHCPv6 reponder by sending the DHCPv6 reply back to the inport once the 'put_dhcpv6_opts' action is applied. Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-northd, tests: Adding IPAM to ovn-northd.Nimay Desai2016-07-281-2/+8
| | | | | | | | | | | | | | | | | 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 <nimaydesai1@gmail.com> Acked-by: Ben Pfaff <blp@ovn.org> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* ovn: Make it possible for CMS to detect when the OVN system is up-to-date.Ben Pfaff2016-07-261-2/+12
| | | | | | | | | | | | | | | | | Until now, there has been no reliable for the CMS (or ovn-nbctl, or anything else) to detect when changes made to the northbound configuration have been passed through to the southbound database or to the hypervisors. This commit adds this feature to the system, by adding sequence numbers to the northbound and southbound databases and adding code in ovn-nbctl, ovn-northd, and ovn-controller to keep those sequence numbers up-to-date. The biggest user-visible change from this commit is new a new option --wait to ovn-nbctl. With --wait=sb, ovn-nbctl now waits for ovn-northd to update the southbound database; with --wait=hv, it waits for the changes to make their way to Open vSwitch on every hypervisor. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Russell Bryant <russell@ovn.org>
* ovn-northd: Add logical flows to support native DHCPv4Numan Siddique2016-07-261-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVN implements a native DHCPv4 support which caters to the common use case of providing an IP address to a booting instance by providing stateless replies to DHCPv4 requests based on statically configured address mappings. To do this it allows a short list of DHCPv4 options to be configured and applied at each compute host running ovn-controller. A new table 'DHCP_Options' is added in OVN NB DB to store the DHCP options. Logical ports refer to this table to configure the DHCPv4 options. For each logical port configured with DHCPv4 Options following flows are added - A logical flow which copies the DHCPv4 options to the DHCPv4 request packets using the 'put_dhcp_opts' action and advances the packet to the next stage. - A logical flow which implements the DHCP reponder by sending the DHCPv4 reply back to the inport once the 'put_dhcp_opts' action is applied. Signed-off-by: Numan Siddique <nusiddiq@redhat.com> Co-authored-by: Ben Pfaff <blp@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org> Tested-by: Ramu Ramamurthy <ramu.ramamurthy@us.ibm.com> Acked-by: Ramu Ramamurthy <ramu.ramamurthy@us.ibm.com>
* ovn: Support multiple addresses on a single logical router port.Justin Pettit2016-07-121-3/+5
| | | | | | | | | | | Supporting multiple addresses is only mildly interesting for IPv4. However, it is a requirement for IPv6, which will arrive in a future commit. This commit introduces the extract_lrp_networks() function to ovn-util.[ch]. Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: Remove 'default_gw' from logical router table.Justin Pettit2016-07-121-3/+2
| | | | | | | | | With static routes, it's not necessary to have a separate default gateway parameter. This also makes configuring router ports clearer when IPv6 and IPv4 addresses may be assigned to the same port. Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: Add support for Load balancers.Gurucharan Shetty2016-07-031-2/+20
| | | | | | | | | | | | | | | | | | | | | | This commit adds schema changes to the OVN_Northbound database to support Load balancers. In ovn-northd, it adds two logical tables to program logical flows. It adds a 'pre_lb' table that sits before 'pre_stateful' table. For packets that need to be load balanced, this table sets reg0[0] to act as a hint for the pre-stateful table to send the packet to the conntrack table for defragmentation. It also adds a 'lb' table that sits before 'stateful' table. For packets from established connections, this table sets reg0[2] to indicate to the 'stateful' table that the packet needs to be sent to connection tracking table to just do NAT. In stateful table, packet for a new connection that needs to be load balanced is given a ct_lb($IP_LIST) action. Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: Add address set support for ACLs.Russell Bryant2016-07-031-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature was originally proposed here: http://openvswitch.org/pipermail/dev/2016-March/067440.html A common use case for OVN ACLs involves needing to match a set of IP addresses. outport == "lp1" && ip4.src == {10.0.0.5, 10.0.0.25, 10.0.0.50} This example match only has 3 addresses, but it could easily have hundreds of addresses. In some cases, the same large set of addresses needs to be used in several ACLs. This patch adds a new Address_Set table to OVN_Northbound so that a set of addresses can be specified once and then referred to by name in ACLs. To recreate the above example, you would first create an address set: $ ovn-nbctl create Address_Set name=set1 addresses="10.0.0.5","10.0.0.25","10.0.0.50" Then you can refer to this address set by name in an ACL match: outport == "lp1" && ip4.src == $set1 Signed-off-by: Russell Bryant <russell@ovn.org> Signed-off-by: Babu Shanmugam <bschanmu@redhat.com> Co-authored-by: Flavio Fernandes <flavio@flaviof.com> Signed-off-by: Flavio Fernandes <flavio@flaviof.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: DNAT and SNAT on a gateway router.Gurucharan Shetty2016-06-211-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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 <guru@ovn.org> Acked-by: Flavio Fernandes <flavio@flaviof.com>
* ovn: Use Logical_Switch_Port in NB.Justin Pettit2016-06-111-4/+4
| | | | | | | | | | | | We have both logical switch and router ports. Router ports are referenced in "Logical_Router_Port" table, so this make it more consistent. Also change internal use of "lport" to "lsp". Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ryan Moats <rmoats@us.ibm.com> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn: Introduce l3 gateway router.Gurucharan Shetty2016-06-021-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ovn-northd: Add support for static_routes.Steve Ruan2016-05-041-2/+13
| | | | | | | | | | | | | | | | | | Logical patch ports are used to connect logical routers together. Static routes are used to select between different logical router ports when exiting a logical router. Reported-by: Na Zhu <nazhu@cn.ibm.com> Reported-by: Dustin Lundquist <dlundquist@linux.vnet.ibm.com> Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1545140 https://bugs.launchpad.net/networking-ovn/+bug/1539347 Signed-off-by: Steve Ruan <ruansx@cn.ibm.com> [guru@ovn.org provided the unit test.] Co-authored-by: Gurucharan Shetty <guru@ovn.org> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* ovn: Add column enabled to table Logical_RouterJunoZhu2016-04-221-2/+3
| | | | | | | | | | | | | This patch add column "enabled" to table Logical_Router for setting router administrative state. The type of "enabled" is bool. If the administrative state is false, delete all the flows relevant to the logical router from table Logical_Flow. Signed-off-by: Na Zhu <nazhu@cn.ibm.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn-northd: Fix peering of routers.Gurucharan Shetty2016-04-011-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Currently, the ovn-nb man page says that the 'peer' in a logical_router_port table should point to the name of the peer's logical router port. But the schema had declared this column as a uuid. This looks not to be the intention as peers for logical switches connected to routers is a name (and not a uuid). So this patch changes the schema to be name. 2. In the southbound database, in the port_binding table, for a logical_router_port, the peer was pointing back to itself. This was causing ovn-controller to create patch ports where the peer was wrongly pointing back to the source itself. This clearly looks to be an error. So this patch fixes the peer in southbound database to correclty point to the real peer. 3. ovn-northd.c currently skips generating logical flows to transfer packets between two peers with comment about needing 'ARP for neighboring routers'. It looked to me that since the router peer is a logical object that has to be created in OVN-NB database, we always need to statically assign the mac address. So this patch picks the mac address from the database. Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org> Acked-by: Ryan Moats <rmoats@us.ibm.com>
* ovn: use name instead of uuid as key of logical router portsHan Zhou2015-11-291-2/+3
| | | | | | | | | | Before this patch, logical switch ports were using name as key but logical router ports using uuid, which confuses user when trouble- shooting, and names of patch ports unreadable. This patch unifies it by using "name" field also for logical router ports. Signed-off-by: Han Zhou <zhouhan@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovn: Remove duplicate versions from schemas.Russell Bryant2015-11-031-3/+4
| | | | | | | | | | | Since commit 5935835968c9d36ffe306863f0c8079d3b670e2a, the OVN nb and sb schema definitions have included duplicate version entries. In the nb case, the version has since been updated to 2.0.0, but only in one place. Remove the duplicate version entries that were at the bottom of the files. Signed-off-by: Russell Bryant <rbryant@redhat.com> Acked-by: Ben Pfaff <blp@nicira.com>
* ovn: Reduce range of ACL priorities.Justin Pettit2015-10-191-3/+3
| | | | | | | | | | | To implement stateful ACLs, we've needed to reserve multiple logical flow priorities in the ACL table. Rather than continue to have a strange range of ACL priorities, we'll make ACL priority range 0 to 32767 and then offset them by 1000 when inserting them into the logical flow table. Signed-off-by: Justin Pettit <jpettit@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* ovn-nb: Add "enabled" column to Logical_Router_Port.Ben Pfaff2015-10-161-1/+2
| | | | | | | | | | | | This is just for symmetry with Logical_Port, since it seems that if users want to be able to disable switch ports they might want to disable router ports as well. There is no "up" column because a logical router port doesn't have the same concept. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Justin Pettit <jpettit@nicira.com>
* ovn-nb: Change how router ports work.Ben Pfaff2015-10-161-6/+2
| | | | | | | | | | | | | | | This is for two reasons. First, a router port is not really much of a special case from a logical switch's point of view. For switching purposes, it works exactly the same as any other port. Having a special column for it just adds artificial special cases. Second, the previous form of router ports specified that all of them use the logical port name "ROUTER". This seemed to make sense at the time but now it is just adding more special cases. Instead just giving them names like any other port makes life easier. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Justin Pettit <jpettit@nicira.com>
* ovn-nb: Rename Port_Bindings 'macs' column to 'addresses'.Ben Pfaff2015-10-161-4/+4
| | | | | | | In an upcoming commit this column will also support IP+MAC pairs. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Justin Pettit <jpettit@nicira.com>
* ovn-nb: Extend schema to support networks of routers.Ben Pfaff2015-10-161-3/+7
| | | | | Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Justin Pettit <jpettit@nicira.com>
* ovn: Add schema versions and checksum to schema files.Gurucharan Shetty2015-10-021-0/+2
| | | | | Signed-off-by: Gurucharan Shetty <gshetty@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* ovn: Change the valid tag values.Gurucharan Shetty2015-10-021-1/+1
| | | | | | | | A tag value of 0 is not used by containers running inside VMs. Signed-off-by: Gurucharan Shetty <gshetty@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* ovn-nb: Add direction and reduce max priority for ACLs.Justin Pettit2015-09-101-1/+3
| | | | | | | | | Introduce a new "direction" column to the ACL table that accepts the values "to-lport" and "from-lport". Also reserve the ACL priority 65535 for return traffic associated with the "allow-related" action. Signed-off-by: Justin Pettit <jpettit@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* ovn: Add type and options to logical port.Russell Bryant2015-07-311-0/+6
| | | | | | | | | | | | | | | | We have started discussing the use of the logical port abstraction in OVN to represent special types of connections into an OVN logical switch. This patch proposes some schema updates to reflect these special types of logical ports. A logical port can have a "type" and a set of options specific to that type. Some examples of logical port types would be "vtep" for connectivity to a VTEP gateway or "localnet" for a connection to a locally accessible network via an ovs bridge. Actualy support for these (or other) types will come in later patches. Signed-off-by: Russell Bryant <rbryant@redhat.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* Add 'name' field to logical router port NB schemaGal Sagie2015-07-211-0/+1
| | | | | Signed-off-by: Gal Sagie <gal.sagie@gmail.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* ovn-nb: Add per-port IP addresses to routers.Ben Pfaff2015-07-161-1/+0
| | | | | | | | A router needs one IP address per port, not just one for the whole router. Reported-by: Gal Sagie <gal.sagie@gmail.com> Reported-at: http://openvswitch.org/pipermail/dev/2015-July/057242.html Signed-off-by: Ben Pfaff <blp@nicira.com>
* ovn-nb: Add 'name' field to Logical RouterGal Sagie2015-07-141-0/+1
| | | | | | | | | | Adding a name identifier will increase convinence for Openstack (or Other CMS) that want to identify the logical router (or store the CMS id in the router name) Signed-off-by: Gal Sagie <gal.sagie@gmail.com> Acked-by: Russell Bryant <rbryant@redhat.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* ovn: Take advantage of OVSDB garbage collection in OVN_Northbound schema.Ben Pfaff2015-07-021-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, the OVN_Northbound schema has been designed to sidestep a weakness in the OVSDB protocol when a column has a great deal of data in it. In the current OVSDB protocol, whenever a column changes, the entire new value of the column is sent to all of the clients that are monitoring that column. That means that adding or removing a small amount of data, say 1 element in a set, requires sending all of the data, which is expensive if the column has a lot of data. One example of a column with potential to have a lot of data is the set of ports within a logical switch, if a logical switch has a large number of ports. Thus, the existing OVN_Northbound schema has each Logical_Port point to its containing Logical_Switch instead of the other way around. This sidesteps the problem because it does not use any large columns. The tradeoff that this forces, however, is that the schema cannot take advantage of OVSDB's garbage collection feature, where it automatically deletes rows that are unreferenced. That's a problem for Neutron because of Neutron-internal races between deletion of a Logical_Switch and creation of new Logical_Ports on the switch being deleted. When such a race happens, OVSDB refuses to delete the Logical_Switch because of references to it from the newly created Logical_Port (although Neutron does delete the pre-existing logical ports). To solve the problem, this commit changes the OVN_Northbound schema to use a set of ports within Logical_Switch. That will lead to large columns for large logical switches; I plan to address that (though I don't have code written) by enhancing the OVSDB protocol. With this commit applied, the database will automatically cascade deleting a logical switch row to delete all of its ports, ACLs, and its router port (if any). This commit makes some pretty pervasive changes to ovn-northd, but they are mostly beneficial to the code readability because now it becomes possible to trivially iterate through the ports that belong to a switch, which was difficult before the schema change. This commit will break the Neutron integration until that is changed to handle the new database schema. CC: Aaron Rosen <arosen@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Russell Bryant <rbryant@redhat.com> Acked-by: Justin Pettit <jpettit@nicira.com>
* ovn: Add logical port 'enabled' state.Russell Bryant2015-06-241-0/+1
| | | | | | | | | | | | | | This patch adds a new column to the Logical_Port table of the OVN_Northbound database called 'enabled'. The purpose is to allow a port to be administratively enabled or disabled. It is sometimes useful to keep a port and its related configuration, but temporarily disable it, which means no traffic is allowed in or out of the port. The implementation is fairly non-invasive as it only required minor changes to the logical pipeline. Signed-off-by: Russell Bryant <rbryant@redhat.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* ovn-nb: Disallow priority 0 ACLs.Ben Pfaff2015-04-201-1/+1
| | | | | | | | | | | | | | We need to have a priority-0 logical datapath flow to act as a catch-all. The easiest way to make sure that it doesn't overlap with NB-provided ACLs is to prohibit them from using priority 0. Maybe we should restrict ACLs to some smaller range of priorities to allow for higher- and lower- priority flows in the logical datapath table. I haven't carefully thought it through. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Russell Bryant <rbryant@redhat.com> Acked-by: Justin Pettit <jpettit@nicira.com>
View Lorry Controller Status