Service insertion method, device and system at a logical gateway

Abstract

The present invention relates to service insertion methods, devices and systems at logical gateways. Many companies and other entities use software-defined data centers (e.g., local data centers and / or public cloud data centers) to host their networks. Providers of software-defined data centers typically offer a variety of network security options, but some entities want to incorporate existing third-party security services (or other services) into their hosted networks. Therefore, technology for more easily incorporating these services into virtual networks would be useful.

Description

[0001] This application is a divisional application of the invention patent application with application number 201980057472.1, application date August 21, 2019, and invention name “Service insertion method, device and system at logical gateway”. Background Art

[0002] Many companies and other entities use software-defined data centers (e.g., local data centers and / or public cloud data centers) to host their networks. Providers of software-defined data centers typically offer a variety of network security options, but some entities want to incorporate existing third-party security services (or other services) into their hosted networks. Therefore, technology for more easily incorporating these services into virtual networks would be useful. Summary of the invention

[0003] Some embodiments provide a network management and control system that enables integration of third-party service machines for processing data traffic entering and / or exiting a logical network. These third-party services may include various types of non-packet forwarding services, such as firewalls, virtual private network (VPN) services, network address translation (NAT), load balancing, etc. In some embodiments, the network management and control system manages the integration of these service machines, but does not manage the life cycle of the machines themselves.

[0004] In some embodiments, the logical network includes at least one logical switch to which a logical network endpoint (e.g., a data computing node such as a virtual machine, a container, etc.) is connected and a logical router for handling data traffic entering and / or exiting the logical network. In addition, the logical network may include multiple logical switches logically connected to each other through the aforementioned logical router or another logical router. In some embodiments, the logical network includes multiple tiers of logical routers. The logical routers in the first tier connect groups of logical switches (e.g., logical switches for a specific tenant). For data traffic sent to and from the logical network (e.g., data traffic from an external client connected to a web server hosted in the logical network, etc.), these first-tier logical routers are connected to logical routers in the second tier. The second-tier logical routers are implemented at least in part in a centralized manner for handling connections to external networks, and in some embodiments, third-party service machines are attached to centralized components of these logical routers. The logical networks of other embodiments include only a single tier of logical routers to which third-party services are attached.

[0005] In some embodiments, a network management and control system (hereinafter referred to as a network control system) receives both (i) configuration data defining a logical network (i.e., a logical switch, an attachment of a data computing node to a logical switch, a logical router, etc.) and (ii) configuration data attaching a third-party service to a logical router (i.e., a logical router that handles connections to an external network). Based on the configuration data, the network control system configures various managed forwarding elements to implement the logical forwarding elements (logical switches, distributed aspects of logical routers, etc.) and other packet processing operations of the logical network (e.g., distributed firewall rules). In addition, some embodiments configure a specific managed forwarding element operating on a gateway machine to implement a centralized logical routing component that handles the connection of the logical network to one or more external networks. Such a managed forwarding element on the gateway machine is also configured to redirect (e.g., using policy-based routing) at least a subset of the inbound and / or outbound data traffic between the logical network and the external network to the attached third-party service via a separate interface of the gateway.

[0006] In some embodiments, receiving configuration data for attaching a third-party service includes several separate configuration inputs (e.g., from an administrator). After configuring the logical router, some embodiments receive configuration data that (i) defines a service attachment interface of the logical router, (ii) defines a logical switch to which the service attachment interface is connected, (iii) defines a service interface (e.g., an interface of a service machine to which data traffic is redirected), and (iv) connects the service attachment interface of the logical router and the service interface to the logical switch. In addition, in some embodiments, the administrator defines a rule or a set of rules that specifies which inbound and / or outbound traffic is redirected to the service interface.

[0007] Some embodiments use a variety of different topologies to enable multiple services to connect to a logical router. For example, multiple services can be connected to the same logical switch, in which case the services all have interfaces in the same subnet and can send data traffic directly between each other (if configured to do so). In this setup, the logical router can have a single interface connected to the logical switch (for traffic to all services), or a separate interface connected to the logical switch for each attached service. In other cases, a separate logical switch can be defined for each service (with a separate logical router interface connected to each logical switch). In addition, multiple interfaces can be defined for each service machine to handle different sets of traffic (e.g., traffic to / from different external networks or different logical network subnets).

[0008] In addition, in some embodiments, the service machine can be connected to the logical router via different types of connections. Specifically, some embodiments allow the service machine to be connected in either of the following ways: (i) L2 wire plug-in mode or (ii) L3 single-arm mode. In L2 mode, two interfaces of the logical router are connected to two separate interfaces of the service machine via two separate logical switches, and data traffic is sent to the service machine via one of the interfaces and received back from the service machine via the other interface. Data traffic can be sent to the service machine via one interface for traffic entering the logical network and via another interface for traffic exiting the logical network. In L3 mode, a single interface is used on the logical router for each connection to the service machine.

[0009] Once configured, the gateway redirects some or all data traffic between the logical network and the external network to the service machine. As described above, some embodiments use a set of policy-based routing (PBR) rules to determine whether to redirect each data message. In some embodiments, the gateway applies these PBR rules to outgoing data messages after performing logical routing on the data messages, and applies the PBR rules to incoming data messages before performing logical routing and / or switching on the incoming data messages.

[0010] That is, for outgoing data messages, the gateway performs logical switching (if necessary), then performs logical routing against the routing components connected to the external network to determine that the data message is actually directed outside the logical network, and then applies PBR rules to determine whether to redirect the data message to the service. If the data message is redirected, the gateway forwards the data message to the external network when it returns from the service (if the data message is not dropped / blocked by the service).

[0011] For incoming data messages, the gateway applies PBR rules to determine whether to redirect the data message to a service before processing it through any logical forwarding elements. If the data message is redirected, the gateway then performs logical routing and switching on the data message when it returns from the service (if the data message is not dropped / blocked by the service), etc., to determine how to forward the data message to the logical network.

[0012] In some embodiments, the PBR rules use a two-phase lookup to determine whether to redirect a data message (and to which interface to redirect the data message). Specifically, each rule specifies a unique identifier, rather than the PBR rules (i.e., routing rules based on header fields other than the destination network address) providing redirection details. Each identifier corresponds to a service machine, and the gateway stores dynamically updated data structures for each identifier. In some embodiments, these data structures indicate the type of connection to the service (e.g., L2 line plug-in or L3 single-arm), the network address of the interface of the service to which the data message is redirected (for L2 mode, some embodiments use a virtual network address corresponding to the data link layer address of the gateway's return service attachment interface), dynamically updated state data, and failover policies. The state data is dynamically updated based on the health / reachability of the service, which can be tested using a heartbeat protocol such as bidirectional forwarding detection (BFD). In some embodiments, the failover policy specifies how to handle data messages when the service is unreachable. These failover policy options may include, for example, discarding data messages, forwarding data messages to their destination without redirecting to the service, redirecting to a backup service machine, and the like.

[0013] The foregoing summary is intended to serve as a brief introduction to some embodiments of the present invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The following detailed description and the drawings referenced in the detailed description will further describe the embodiments described in the summary as well as other embodiments. Therefore, in order to understand all the embodiments described in this document, a comprehensive review of the summary, the detailed description and the drawings is required. In addition, the subject matter claimed is not limited by the illustrative details in the summary, the detailed description and the drawings, but is defined by the appended claims, because the subject matter claimed may be embodied in other specific forms without departing from the spirit of the subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The novel features of the invention are set forth in the appended claims. However, for purposes of illustration, several embodiments of the invention are set forth in the following drawings.

[0015] Figure 1 An example logical network to which third-party services of some embodiments may connect is conceptually illustrated.

[0016] Figure 2 An example of connecting a third-party service machine to a centralized router is conceptually shown.

[0017] Figure 3 A process of some embodiments for configuring a gateway machine of a logical network to redirect incoming and / or outgoing data traffic to a third-party service machine is conceptually illustrated.

[0018] Figure 4 A centralized routing component is conceptually illustrated with two service attachment interfaces connected to two separate service endpoint interfaces of a third-party service machine via two separate logical switches.

[0019] Figure 5 A centralized routing component is conceptually illustrated with one service attachment interface connected to two separate interfaces of a third-party service machine via one logical switch.

[0020] Figure 6 A centralized routing component is conceptually illustrated with one service attachment interface connected to interfaces of two different third-party service machines via one logical switch.

[0021] Figure 7 A centralized routing component is conceptually illustrated with two service attachment interfaces, each service attachment interface connected to a different one of the two service machines via a separate logical switch.

[0022] Figure 8 The path of an incoming data message through multiple logical processing stages implemented by a third-party service machine and a gateway managed forwarding element connected in L3 one-arm mode is shown.

[0023] Fig. 9 shows the outgoing data message passing through Figure 8 The gateway MFE and third-party service machines implement multiple logical processing stages of the path.

[0024] Fig.10 The path of an incoming data message through multiple logical processing stages implemented by a third-party service machine and a gateway MFE connected in L2 line plug-in mode is shown.

[0025] Fig.11 shows the outgoing data message passing through Fig.10 The gateway MFE and third-party service machines implement multiple logical processing stages of the path.

[0026] Fig.12 A process of some embodiments for applying policy-based routing redirection rules to data messages is conceptually illustrated.

[0027] Fig.13 A table showing policy-based routing rules.

[0028] Fig.14 A data structure is conceptually illustrated as being dynamically updated based on changes in the connection status of a service machine to which the data structure redirects data messages.

[0029] Fig.15 An electronic system for implementing some embodiments of the present invention is conceptually illustrated. DETAILED DESCRIPTION

[0030] In the following detailed description of the present invention, many details, examples and embodiments of the present invention are described and illustrated. However, it is clear and obvious to those skilled in the art that the present invention is not limited to the embodiments described, and the present invention can be implemented without some of the specific details and examples discussed.

[0031] Some embodiments provide a network management and control system that enables integration of third-party service machines for processing data traffic entering and / or exiting a logical network. These third-party services may include various types of non-packet forwarding services, such as firewalls, virtual private network (VPN) services, network address translation (NAT), load balancing, etc. In some embodiments, the network management and control system manages the integration of these service machines, but does not manage the life cycle of these machines themselves (thus referring to these service machines as third-party services).

[0032] In some embodiments, the logical network includes at least one logical switch to which a logical network endpoint (e.g., a data computing node such as a virtual machine, a container, etc.) is connected and a logical router for processing data traffic entering and / or exiting the logical network. In addition, the logical network may include multiple logical switches logically connected to each other through the aforementioned logical router or another logical router.

[0033] Figure 1 An example logical network 100 to which third-party services of some embodiments may be connected is conceptually illustrated. As shown, the logical network 100 includes a tier-0 logical router 105 (also referred to as a provider logical router), a tier-1 logical router 110 (also referred to as a tenant logical router), and two logical switches 115 and 120. Data computing nodes (DCNs) 125-140 (e.g., virtual machines, containers, etc.) are attached to each of the logical switches 115 and 120. These data computing nodes 125 exchange data messages with each other and with one or more external networks 145 through a physical network that implements the logical network (e.g., within a data center).

[0034] The logical network 100 represents an abstraction of a network configured by a user of a network management and control system in some embodiments. That is, in some embodiments, the network administrator configures the logical network 100 as a conceptual collection of logical switches, routers, etc., where policies are applied to these logical forwarding elements. The network management and control system generates configuration data for physical managed forwarding elements (e.g., software virtual switches operated in virtualization software of hosts, virtual machines, and / or bare metal machines that operate as logical network gateways, etc.) to implement these logical forwarding elements. For example, when a DCN 125-140 hosted on a physical host sends a data message, in some embodiments, the managed forwarding element executed in the virtualization software of the host processes the data message to implement the logical network. The managed forwarding element will apply the logical switch configuration for the logical switch to which the DCN is attached, and then apply the layer 1 logical router configuration, etc. to determine the destination of the data message.

[0035] In some embodiments, such as in this example, the logical network includes multiple layers of logical routers. Logical routers in the first layer (e.g., Tier 1 logical router 110) connect groups of logical switches (e.g., logical switches for a particular tenant). For data traffic sent to and from the logical network (e.g., data traffic from external clients connected to web servers hosted in the logical network, etc.), these first-tier logical routers connect to logical routers in the second layer (e.g., Tier 0 logical router 105).

[0036] The network management and control system (hereinafter referred to as the network control system) of some embodiments defines multiple routing components for at least some logical routers. Specifically, the tier-0 logical router 105 in this example has a distributed routing component 150 ("distributed router") and a centralized routing component 155, which are connected through an internal logical switch 160 called a transit logical switch. In some cases, multiple centralized routers are defined for the tier-0 logical router, each of which is connected to the transit logical switch 160. For example, some embodiments define two centralized routers, one active and one standby.

[0037] In some embodiments, the distributed router 150 and the transit logical switch 160 are implemented in a distributed manner (e.g., using logical switches 115 and 120 and the first-level logical router 110), which means that the first-hop managed forwarding elements of the data message apply the policies of those logical forwarding elements to the data message. However, the centralized routers 155 are implemented in a centralized manner (i.e., a single host implements each such centralized router). These centralized routers handle the connection of the logical network to external networks (e.g., to other logical networks implemented in the same or other data centers, to external web clients, etc.). The centralized routers can perform various stateful services (e.g., network address translation, load balancing, etc.) and exchange routes with one or more external routers (using, for example, BGP or OSPF). Different embodiments can implement centralized routers using bare metal machines, virtual machines, virtual switches executed in the host's virtualization software, or other contexts.

[0038] As mentioned, some embodiments allow administrators to attach third-party services to logical routers using a network control system. In some such embodiments, these third-party services are attached to a centralized router (e.g., centralized router 155 of the Tier-0 router) that handles data traffic between logical network endpoints and external networks. Although the subsequent discussion primarily relates to the connection of third-party services to Tier-0 logical routers, in some embodiments, third-party services may also be connected to Tier-1 logical routers.

[0039] Figure 2 An example of connecting a third-party service machine 200 to a centralized router 205 is conceptually shown. Specifically, in some embodiments, a network administrator defines a service attachment interface 210 on a logical router, a service endpoint 215 for the third-party service machine, a specific logical switch 220 for service attachment, and attaches both the service attachment interface 210 and the service endpoint 215 to the logical switch 220. In some embodiments, the administrator provides this information through an application programming interface (API) of a management plane of the network control system (e.g., using a network management application user interface that converts user interactions into API calls to the management plane).

[0040] In some embodiments, the management plane receives (i) configuration data that defines a logical network (i.e., a logical switch, an attachment of a data computing node to a logical switch, a logical router, etc.), and configuration data that attaches one or more third-party services to a logical router that handles the connection of the logical network to an external network. Based on the configuration data, the network control system configures various managed forwarding elements to implement the logical forwarding elements (logical switches, distributed aspects of logical routers, etc.) and other packet processing operations for the logical network (e.g., distributed firewall rules). In some embodiments, the management plane generates configuration data based on inputs and provides the configuration data to a central control plane (e.g., a set of centralized controllers). The central control plane identifies the managed forwarding elements that require each atomic configuration data and distributes the configuration data to local controllers for each identified managed forwarding element. These local controllers are then responsible for configuring the managed forwarding elements (including gateway machines that implement centralized routers) to implement the logical forwarding elements of the logical network, including redirecting appropriate data messages to third-party services (e.g., according to policy-based routing rules provided by an administrator).

[0041] In some embodiments, receiving configuration data for attaching a third-party service includes several separate configuration inputs (eg, from an administrator). Figure 3 Conceptually illustrates a process 300 of some embodiments for configuring a gateway machine of a logical network to redirect incoming and / or outgoing data traffic to a third-party service machine. In some embodiments, process 300 is performed by a management plane of a network control system that receives input through API calls.

[0042] In the description of this process, it is assumed that a logical network has been configured and includes a logical router having at least one centralized component configured to handle data traffic entering and exiting the logical network. Some embodiments configure specific managed forwarding elements operating on a gateway machine to implement these centralized logical routing components that handle the connection of the logical network to one or more external networks.

[0043] As shown, process 300 begins by receiving (at 305) input to define a service attachment interface for a logical router. In some embodiments, the service attachment interface is a dedicated type of interface for a logical router. In different embodiments, an administrator defines the service attachment interface either on a specific centralized component or generally on logical routers. In the latter case, the management plane either applies the interface to a specific one component (e.g., if the administrator defines that the service attachment interface will only handle traffic sent to or from a specific uplink interface of a logical router assigned to a specific centralized component), or creates a separate interface for each centralized component of the logical router. For example, in some embodiments, active and standby centralized routing components are defined, and interfaces are created on each of these components.

[0044] Next, the process 300 receives (at 310) input to define a logical switch for connecting the logical router to a third-party service. In addition, the process receives (at 315) input to attach a service attachment interface to the logical switch. In some embodiments, the creation of the logical switch is similar to the logical switch of the logical network to which the data computing node (e.g., VM, etc.) is attached. In other embodiments, the logical switch is defined by an administrator as a specific service attachment logical switch. The logical switch has a privately allocated subnet that (i) includes the network address of the service attachment interface attached to the logical switch, and (ii) only needs to include enough network addresses for any interface of the third-party service and any service attachment interface connected to the logical switch. For example, as shown below, using Classless Inter-Domain Routing (CIDR) notation, a logical switch that connects a single logical router interface to a single third-party service interface can be a " / 31" subnet. Even if the logical router performs route advertisements to external physical routers for the logical network subnets (e.g., using BGP or OSPF), in some embodiments, the subnets for the service attachment logical switches are not advertised (or entered into the routing tables for various logical router layers).

[0045] In some embodiments, if the logical router includes multiple centralized components (e.g., active and standby components), and the service attachment interface corresponds to an interface on each of these components, attaching the service attachment interface actually attaches each of these interfaces to the logical switch. In this case, each centralized component interface has a separate network address in the subnet of the logical switch.

[0046] Next, process 300 receives (at 320) input to define a service endpoint interface, and receives (at 325) input to attach the service endpoint interface to the logical switch (to which the service attachment interface of the logical router is attached). In some embodiments, the service endpoint interface represents an interface on a third-party service machine. In some embodiments, when an administrator defines endpoint interfaces to which a centralized routing component will connect, these interfaces can be service endpoint interfaces (also referred to as logical endpoint interfaces, which correspond to service machines and are connected to the service attachment interface through a logical switch) or external interfaces (also referred to as virtual endpoint interfaces, which correspond to network addresses reachable from a centralized component). An external router interface is an example of this latter interface.

[0047] In addition, some embodiments require an administrator to define third-party service machines (either through the network control system or through a separate data center computing manager). For example, in some embodiments, the network administrator defines both the service type and the service instance (e.g., an instance of the service type). As described above, the service endpoint interface should also have a network address within the subnet of the logical switch to which the interface is attached.

[0048] It should be understood that operations 305-325 need not be performed in Figure 3 For example, a network administrator may initially create two interfaces (a service attachment interface on a logical router and a service endpoint interface representing a third-party service), and then subsequently create a logical switch and attach the interfaces to the logical switch.

[0049] In addition, process 300 receives (at 330) one or more rules for redirecting data messages to a service endpoint interface. In some embodiments, these are policy-based routing rules that (i) specify which incoming and / or outgoing traffic will be redirected to the service interface, and (ii) are applied by the gateway machine independently of its usual routing operations. In some embodiments, the administrator defines redirection rules based on one or more data message header fields (such as source and / or destination network addresses, source and / or destination transport layer ports, transport protocols, interfaces on which data messages are received, etc.). For each service interface, the administrator can create one redirection rule or multiple rules. For example, the data messages that are redirected can include all incoming and / or outgoing data messages for a particular uplink, data messages sent only from or to a particular logical switching subnet, etc.

[0050] Finally, after receiving the above configuration data, process 300 configures (at 335) the gateway machine to implement the centralized logical router and redirection to the service endpoint interface. Then, process 300 ends. If multiple centralized routing components have logical switch interfaces attached to the service endpoints, a gateway machine for each of these components is configured. In some embodiments, the management plane generates configuration data for the service attachment interface and redirection rules and provides this information to the central control plane. The central control plane identifies each gateway machine that needs this information and provides the appropriate configuration data to the local controller of the gateway machine. The local controller of some embodiments converts the configuration data into a format readable by the gateway machine (if it is not already in such a format) and directly configures the gateway machine to implement policy-based routing rules.

[0051] Some embodiments use a variety of different topologies to enable multiple services to connect to a logical router. For example, multiple services can be connected to the same logical switch, in which case the services all have interfaces in the same subnet and can send data traffic directly between each other (if configured to do so). In this setup, the logical router can have a single interface connected to the logical switch (for traffic to all services), or have a separate interface connected to the logical switch for each attached service. In other cases, a separate logical switch can be defined for each service (with a separate logical router interface connected to each logical switch). In addition, multiple interfaces can be defined for each service machine to handle different sets of traffic (e.g., traffic to / from different external networks or different logical network subnets).

[0052] Figure 4-7 Several different such topologies for connecting a centralized routing component of a logical router to one or more service machines are conceptually illustrated. Each of these figures shows a centralized router connected to one or more logical switches to which one or more service machines are also connected. It should be understood that these figures represent a logical view of the connections, and in some embodiments, a gateway machine implementing a centralized router will also implement (multiple) logical switches.

[0053] Figure 4A centralized routing component 400 is conceptually illustrated with two service attachment interfaces connected to two separate service endpoint interfaces of a third-party service machine 405 via two separate logical switches 410 and 415. This topology essentially uses a separate service attachment interface and a separate logical switch for each connection to a third-party service. In this example, each of the logical switches 410 and 415 is assigned a " / 31" subnet that includes two network addresses. Since each logical switch is created specifically for connecting one service attachment interface of the centralized routing component 400 to the service machine 405, only two addresses are required for each switch. In some embodiments, redirection rules for the router redirect data messages sent to and from each uplink to a different interface of the third-party service machine (thereby using a different one of the service attachment interfaces).

[0054] Figure 5 A centralized routing component 500 is conceptually illustrated with one service attachment interface connected to two separate interfaces of a third-party service machine 505 via one logical switch 510. In some embodiments, for each third-party service machine, the administrator creates a logical switch using one service attachment interface on the centralized router component, but defines multiple service endpoint interfaces for the third-party service machine. In this case, the logical switch subnet accommodates a larger number of network addresses (in this example, a " / 24" subnet is used). In some embodiments, redirection rules are set to redirect data messages sent to and from each uplink to different interfaces of the third-party service machine via the same service attachment interface and logical switch. In some embodiments, using a setup with multiple service endpoint interfaces attached to the same logical switch on a service machine requires the third-party service machine to use a separate routing table (e.g., a virtual routing and forwarding instance) for each interface.

[0055] Figure 6A centralized routing component 600 is conceptually shown with one service attachment interface connected to interfaces of two different third-party service machines 605 and 610 via one logical switch 615. The service machines 605 and 610 in this scenario can provide two separate services (e.g., a firewall and a cloud extension service), or be the primary and backup machines for a single high-availability service. In some embodiments, because the interfaces of the service machines 605 and 610 are on the same logical switch, data messages can also be sent from one service to another. In this example, the centralized routing component 600 has a single uplink; some embodiments using this configuration will include two service attachments and two logical switches, each connected to the (different) interfaces of the two service machines, to handle data messages received for or destined for the two different uplinks.

[0056] Figure 7 A centralized routing component 700 is conceptually illustrated with two service attachment interfaces, each connected to a different one of two service machines 705 and 710 via separate logical switches 715 and 720. As with the previous example, the two service machines can provide two separate services or can serve as the primary and backup machines for a single high-availability service. In this example, the centralized routing component has a single uplink; some embodiments using this configuration will include two additional service attachments corresponding to each additional uplink, which are connected to separate interfaces on each service machine via separate logical switches. In these examples, the use of separate interfaces on the service machines corresponding to each different uplink allows the service machines to apply specific processing configurations to data messages sent to or received from each different uplink.

[0057] In addition to these various topologies, in some embodiments, third-party service machines may also be connected to the centralized routing component via different types of connections. Specifically, some embodiments allow service machines to be connected in (i) L2 line plug-in mode or (ii) L3 single-arm mode. Fig.10 and Fig.11 In the L2 mode shown, two interfaces of the logical router are connected to two separate interfaces of the service machine via two separate logical switches, and data traffic is sent to the service machine via one of the interfaces and received back from the service machine via the other interface. For traffic entering the logical network, data traffic can be sent to the service machine via one interface, and for traffic exiting the logical network, data traffic is sent to the service machine via the other interface.

[0058] exist Figure 8 and Fig. 9In the L3 mode shown, a single interface is used on the logical router for each connection to a service machine. Once configured, the gateway redirects some or all data traffic between the logical network and the external network to the service machine. As described above, some embodiments use a set of policy-based routing (PBR) rules to determine whether to redirect each data message. In some embodiments, the gateway applies these PBR rules to outgoing data messages after performing logical routing on the data messages, and applies the PBR rules to incoming data messages before performing logical routing and / or switching on the incoming data messages.

[0059] Figure 8 The path (represented by dashed lines) of an incoming data message through multiple logical processing stages implemented by the gateway management forwarding element 800 and the third-party service machine 805 is shown. As mentioned above, in this example, the third-party service machine is connected in L3 one-arm mode. In this mode, the data message is sent to the network address of the third-party service machine, and the third-party service machine sends the data message back to the network address of the logical router service attachment interface.

[0060] The gateway MFE 800 implements several stages of logical network processing, including policy-based routing (PBR) redirection rules 810, centralized routing component processing 815, service attachment logical switch processing 820, and additional logic processing 825 (e.g., transit logical switch processing, distributed routing component processing, processing for logical routers and / or logical switches at other levels to which network endpoints are connected, etc.). In some embodiments, the gateway MFE 800 is a data path in a bare metal computer or a virtual machine (e.g., a data path based on a data plane development kit (DPDK)). The gateway MFE of other embodiments executes a data path in the virtualization software of the host. Yet other embodiments implement a portion of the logic processing in such a data path while implementing a centralized routing component in a virtual machine, namespace, or similar construct.

[0061] for Figure 8 For incoming data messages in the gateway MFE 800, the gateway MFE 800 applies PBR rules 810 to determine whether to redirect the data message before processing the data message through any logical forwarding element. In some embodiments, the gateway MFE also performs additional operations before applying the PBR rules, such as IPSec and / or other locally applied services. The PBR rules described in more detail below identify whether a given data message will be redirected (e.g., based on various data message header fields, such as source and / or destination IP addresses), how to redirect data messages that match a specific set of header field values, etc. In this case, the PBR rule 810 specifies an interface that redirects the data message to the third-party service machine 805.

[0062] Based on this determination, the centralized routing component process 815 identifies that the redirection interface corresponds to the service attachment logical switch, so the gateway MFE 800 then performs the logical switch process 820. Based on the logical switch process, the gateway MFE sends the data message (e.g., with encapsulation) to the third-party service machine 805. The service machine 805 performs its service processing (e.g., firewall, NAT, cloud extension, etc.) and returns the data message to the gateway MFE (unless the service discards / blocks the data message). When the data message returns from the service, the gateway MFE then performs the centralized routing component process 815 (e.g., routing based on the destination network address), and then performs additional logical processing operations 825. In some embodiments, the data message returned from the third-party service machine is marked with a flag to indicate that the PBR rule does not need to be applied again. Based on these operations, the gateway MFE 800 sends the data message to its destination in the logical network (e.g., by encapsulating the data message and sending the data message to a host in a data center).

[0063] Fig. 9 The path of an outgoing data message through multiple logical processing stages implemented by the gateway MFE 800 and the third-party service machine 805 is shown (represented by dashed lines). Upon receiving a data message, the gateway MFE 800 first applies any logical network processing 825 required by the centralized routing component, such as a transit logical switch (between the distributed routing component and the centralized routing component). In some cases, the tier-1 logical router will also have a centralized routing component implemented on the gateway MFE, in which case the additional logical processing may include the centralized routing component, the distributed routing component of the tier-0 logical router, the transit logical switch between them, etc.

[0064] The centralized routing component process 815 identifies the uplink interface as its output interface, which causes the PBR rule 810 to be applied. In this case, these rules also redirect the outgoing data message to the service machine 805, so the gateway MFE 800 applies the centralized routing component process 815 again, and then applies the service attachment logical switch process 820, and sends the data message to the third-party service machine 805. Assuming that the data message is not dropped by the service machine 805, the gateway MFE 800 receives the data message via its interface corresponding to the service attachment logical switch. At this point, the centralized routing component process 815 again identifies the uplink as the output interface for the component, and the gateway MFE sends the data message to the external physical network router associated with the uplink. As described above, when the data message is received from the service machine 805, the data message is marked with a flag so that in some embodiments, the gateway MFE does not apply the PBR rule 810 again.

[0065] If the service machine is logically connected to the tier-1 logical router, then in some embodiments, the PBR rules are applied after the tier-1 logical router processing and before the tier-0 logical router processing (for outgoing data messages). When returning from the service machine, the gateway MFE then applies the tier-0 distributed routing component, the transit logical switch, and the tier-0 centralized routing component. Incoming traffic is similarly processed by applying the PBR rules after the tier-0 distributed routing component and before applying the tier-1 centralized routing component.

[0066] As mentioned above, Fig.10 and Fig.11 The use of an L2 line plug-in model to connect a service machine to a centralized routing component is shown. Fig.10 The path (represented by dashed lines) of an incoming data message through multiple logical processing stages implemented by the gateway MFE 1000 and the third-party service machine 1005 is shown. In L2 line plug-in mode, two interfaces of the logical router are associated with each connection to the service machine 1005. Data messages are sent to the service machine via one of the interfaces and returned via the other interface.

[0067] like Figure 8 and 9 , gateway MFE 1000 implements PBR redirection rules 1010, centralized routing component processing 1015, and additional logic processing 1030. Because there are two separate interfaces for connecting to service machine 1005, gateway MFE 1000 also implements two separate service attachment logical switches 1020 and 1025. In some embodiments, the interface associated with the first logical switch 1020 is an "untrusted" interface, while the interface associated with the second logical switch 1025 is a "trusted" interface. In this figure, each centralized routing component service attachment interface is associated with a separate interface of gateway MFE 1000. However, in other embodiments, these service attachment interfaces share a gateway MFE interface.

[0068] for Fig.10For incoming data messages in the first logical switch 1020, the gateway MFE 1000 applies the PBR rules 1010 to determine whether to redirect the data message before processing the data message by any logical forwarding element. In some embodiments, the gateway MFE also performs additional operations before applying the PBR rules, such as IPSec and / or other locally applied services. The PBR rules described in more detail below identify whether a given data message is to be redirected (e.g., based on various data message header fields, such as source and / or destination IP addresses), how to redirect data messages that match a specific set of header field values, etc. In this case, the PBR rule 1010 specifies that the data message is to be redirected to the interface of the third-party service machine 805 associated with the first logical switch 1020.

[0069] Based on this determination, the centralized routing component process 815 identifies that the redirection interface corresponds to the first service attachment logical switch 1020. Because the service machine 1005 is connected in L2 wire plug mode, the centralized routing component uses the MAC address of that interface as the source address of the redirected data message, and uses the MAC address of another service attachment interface (connected to the second logical switch 1025) as the destination address. This causes the data message to be returned by the service machine 1005 to the second (trusted) interface.

[0070] The gateway MFE 1000 then performs a logical switching process 1020 and sends a data message to a third-party service machine 1005 based on the logical switching process. The service machine 1005 performs its service processing (e.g., firewall, NAT, cloud extension, etc.) and returns the data message to the gateway MFE (unless the service discards / blocks the data message). When the data message returns from the service, the gateway MFE identifies the second logical switch 1025 for processing based on the destination address of the data message and / or the gateway MFE interface on which the message is received, and then performs processing by the centralized routing component 1015 (e.g., routing based on the destination network address), and then performs additional logical processing operations 1030. In some embodiments, the data message returned from the third-party service machine is marked with a flag to indicate that the PBR rule does not need to be applied again. Based on these operations, the gateway MFE 800 sends the data message to its destination in the logical network (e.g., by encapsulating the data message and sending the data message to a host in a data center).

[0071] Fig.11The path of an outgoing data message through multiple logical processing stages implemented by the gateway MFE 1000 and the third-party service machine 1005 connected in L2 line plug-in mode is shown (represented by dotted lines). Upon receiving the data message, the gateway MFE 1000 first applies any logical network processing 1030 required by the centralized routing component before, such as a transit logical switch (between the distributed routing component and the centralized routing component). In some cases, the 1st level logical router will also have a centralized routing component implemented on the gateway MFE, in which case the additional logical processing 1030 may include the centralized routing component, the distributed routing component of the 0th level logical router, the transit logical switch between them, etc.

[0072] The centralized routing component process 1015 then identifies the uplink interface as its output interface, which results in the application of the PBR rules 1010. In this case, these rules redirect the outgoing data message to the service machine 805 via the trusted interface attached to the second logical switch 1025. Therefore, the gateway MFE 800 again applies the centralized routing component process 1015, then applies the process of the second service attachment logical switch 1025, and sends the data message to the third-party service machine 1005. In this direction, the data message has the trusted interface MAC address as its source address and the untrusted interface MAC address as its destination address, and for incoming data messages, traverses the reverse path from the centralized routing component 1015 to the service machine 1005 and back.

[0073] Assuming that the data message is not dropped by the service machine 1005, the gateway MFE 800 receives the data message via the interface corresponding to the first service attachment logical switch 1020. At this point, the centralized routing component process 1015 again identifies the uplink as an output interface, and the gateway MFE sends the data message to the external physical network router associated with the uplink. As described above, in some embodiments, when received from the service machine 1005, the data message is marked with a flag so that the gateway MFE does not apply the PBR rule 1010 again.

[0074] In some embodiments, the PBR rules use a two-phase lookup to determine whether to redirect a data message (and to which interface to redirect the data message). Specifically, each rule specifies a unique identifier, rather than the PBR rules directly providing redirection details. Each identifier corresponds to a service machine, and the gateway stores a dynamically updated data structure for each identifier that provides details about how to redirect the data message.

[0075] Fig.12The process 1200 for applying policy-based routing redirection rules to data messages of some embodiments is conceptually illustrated. In some embodiments, when applying PBR rules to incoming (from an external network) or outgoing (from a logical network) data messages, the process 300 is performed by a process such as Figure 8-Figure 11 The gateway MFE is executed as shown. Fig.13 The process 1200 is described below, which shows a set of PBR rules and data structures for some of these rules.

[0076] As shown, process 1200 begins by receiving (at 1205) a data message for PBR processing. This can be a data message received from an external network via a logical router uplink or a data message sent by a logical network endpoint for which the gateway MFE has identified the uplink as an outflow port of a centralized routing component. In some embodiments, process 1200 is not applied to data messages with a flag set indicating that the data message is received from a third-party service machine.

[0077] Then, process 1200 performs (at 1210) a lookup of a set of PBR rules. In some embodiments, these rules are organized as a set of flow entries with match conditions and actions for data messages that match each set of match conditions. Depending on the context of the gateway data path, the PBR rules of some embodiments use a hash table (or set of hash tables) that uses one or more hashes of a set of data message header fields. Other embodiments use other techniques to identify matching PBR rules.

[0078] Fig.13 A table of PBR rules 1300 is shown. In this case, the rules all match on the source and destination IP addresses, but the PBR rules of some embodiments may also match on other header fields (and combinations of other header fields and source and / or destination IP addresses). For example, the first two match conditions are opposites of each other, one for processing incoming data messages (from 70.70.70.0 / 24 in the external network to the 60.60.60.0 / 24 subnet in the logical network) and the other for processing the corresponding outgoing data messages. The third match condition matches on any data message sent from the source subnet 20.20.20.0 / 24 (i.e., regardless of the destination address). As further described below, actions specify unique policy identifiers, rather than specific redirection actions.

[0079] return Fig.12, the process 1200 determines (at 1215) whether the data message matches any PBR rule based on the PBR lookup. In some embodiments, the PBR rule table includes a default (lowest priority) rule (or set of rules) for data messages that do not match any other rules. If the data message does not match any PBR rule (or only matches the default rule), the process forwards (at 1220) the data message to its destination without any redirection. Thus, outgoing data messages are sent to the appropriate physical router (after performing any additional IPSec or other local service processing), while incoming data messages begin logical processing at the centralized logical router.

[0080] On the other hand, if the data message matches one of the PBR rules, the process looks up (at 1225) the data structure for the unique identifier specified by the matched PBR rule. Fig.13 As shown, the actions of each PBR rule do not directly specify redirecting the matching data message to a specific next hop address. Instead, these actions specify a unique policy identifier, which in turn maps to a corresponding dynamically updated data structure. That is, the gateway MFE is configured to store a data structure for each unique identifier specified in the PBR action. These data structures can be database table entries or any other type of modifiable data structure. In some embodiments, based on, for example, current network conditions, the gateway MFE is configured as some or all fields of the data structure.

[0081] In some embodiments, these data structures indicate the type of connection to the service (e.g., L2 patch or L3 single-arm), the network address of the service's interface to which the data message is redirected, dynamically updated state data, and a failover policy. The state data is dynamically updated based on the health / reachability of the service, which can be tested using a heartbeat protocol such as bidirectional forwarding detection (BFD). In some embodiments, the failover policy specifies how to handle data messages if the service is unreachable.

[0082] Fig.13The contents of two of these data structures are shown. Data structure 1305 for unique identifier ABCDE indicates that the service machine to which the policy is redirected is connected in L2 line plug-in mode (so that data messages in the opposite direction that match the second PBR rule will be redirected to the same service machine in the opposite direction). Data structure 1305 also indicates a pseudo IP address for redirection. This pseudo IP is not actually the address of the service machine, but resolves to the MAC address of the service attachment interface of the centralized routing component via which the data message will be returned (e.g., for incoming data messages, a trusted interface of the centralized routing component). In some embodiments, this address resolution can be performed using a statically configured ARP entry.

[0083] In addition, data structure 1305 specifies the current BFD state of the connection to the service machine (the connection is currently up) and a failover policy indicating how to handle data messages if the BFD state is down. It should be noted that although these examples use BFD, other mechanisms for monitoring the reachability of the service machine may also be used (e.g., other heartbeat protocols, other measurements of connection status, etc.). In this case, the failover policy indicates that if the service computer is unavailable, the data message should be discarded. Other failover policy options may include, for example, forwarding the data message to its destination without redirecting to the service, redirecting to a backup service machine, etc.

[0084] The data structure 1310 for the unique identifier ZYXWV indicates that the service machine to which this policy is redirected is connected in L3 one-arm mode, so the redirection IP address provides the address of the service machine interface (rather than a pseudo IP). The BFD state of this connection is also up, but in this case, the failover policy provides redirection to a backup service machine at a different IP address on a different subnet (i.e., connected to a different logical switch).

[0085] return Fig.12 , process 1200 processes (at 1230) the data message according to the instructions in the data structure for the unique identifier. This may include redirecting the data message to the next hop IP address specified by the data structure; if the connection is down and the failure policy specifies to discard the data message, then discard the data message; or if the connection is down and the failure policy specifies to ignore the redirection, then forward the data message according to the logical network processing.

[0086] As described above, the data structure for each redirection policy is dynamically updated by the gateway MFE. In some embodiments, a BFD thread is executed on the gateway machine to (i) send BFD messages to the service machine and (ii) receive BFD messages from the service machine. For a service machine connected in L3 single-arm mode, the service machine also executes a BFD thread that sends BFD messages to the gateway. On the other hand, in L2 line plug-in mode, the BFD thread sends BFD messages to the service machine from one of the interfaces that connects the centralized routing component to the service machine, and receives these messages back on another interface. Some such embodiments send BFD messages (wherein the BFD messages are sent from a trusted interface and received at an untrusted interface, and vice versa) through two interfaces. This process is described in more detail in U.S. patent application Ser. No. 15 / 937,615, which is incorporated herein by reference. In some embodiments, one BFD thread is executed on each gateway MFE and exchanges messages with all connected service machines, while in other embodiments, a separate BFD thread is executed on the gateway MFE to exchange messages with each connected service machine. When the BFD thread detects that BFD messages are no longer being received from a particular service machine, the gateway MFE modifies the data structure for that service machine.

[0087] Fig.14 Conceptually illustrates a data structure 1310 that is dynamically updated based on changes in the connection state of the service machine to which the data structure redirects data messages. The figure shows the data structure 1310 and the connection between the gateway machine 1400 and two service machines 1415 and 1420 at two stages 1405 and 1410.

[0088] In the first stage 1405, the data structure 1310 is in Fig.13The same status indicates that the connection to the service machine endpoint interface 169.254.10.1 is currently up according to the BFD status. The gateway machine 1400, in addition to operating the gateway MFE using its logical network processing, PBR rules, etc., also executes a BFD thread 1425. This BFD thread 1425 periodically sends BFD messages to both the first service machine 1415 (at its interface with an IP address of 169.254.10.1) and the second service machine 1420 (at its interface with an IP address of 169.254.11.1). In addition, each of these service machines 1415 and 1420 executes their own BFD threads 1430 and 1435, respectively, which periodically send BFD messages to the gateway machine. As shown by the large X, at this stage 1405, the connection between the gateway machine 1400 and the first service machine 1415 becomes down. This may occur due to physical connection problems, problems with the service machine 1415 crashing, etc. Therefore, the BFD thread 1425 will no longer receive BFD messages from the service machine 1415.

[0089] In the second stage 1410, the connection between the gateway machine 1400 and the service machine 1415 no longer exists. In addition, the data structure 1305 has been dynamically updated by the gateway MFE to indicate that the BFD state is down. As a result of the failover policy specified by the data structure 1305, data messages with source IPs in the subnet 20.20.20.0 / 24 will be redirected to the 169.254.11.1 interface of the second service machine 1420 until the connection with the first service machine 1415 is restored to up.

[0090] In some embodiments, multiple threads can write to data structures 1305 and 1310. For example, some embodiments allow the BFD thread as well as the configuration receiver thread to both write to these data structures (e.g., to modify the BFD state and make any configuration changes received from the network control system). In addition, one or more packet processing threads can read these data structures to perform packet lookups. Some embodiments enable these packet processing threads to read from the data structures even if one of the writer threads is currently accessing these structures so that packet processing is not interrupted by the writer thread.

[0091] Fig.15An electronic system 1500 for implementing some embodiments of the present invention is conceptually illustrated. The electronic system 1500 may be a computer (e.g., a desktop computer, a personal computer, a tablet computer, a server computer, a mainframe, a blade computer, etc.), a phone, a PDA, or any other type of electronic device. Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 1500 includes a bus 1505, (multiple) processing units 1510, a system memory 1525, a read-only memory 1530, a permanent storage device 1535, an input device 1540, and an output device 1545.

[0092] Bus 1505 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 1500. For example, bus 1505 communicatively connects processing unit(s) 1510 with read-only memory 1530, system memory 1525, and permanent storage device 1535.

[0093] Processing unit(s) 1510 retrieves instructions to be executed and data to be processed from these various memory units in order to perform the processes of the present invention. In various embodiments, the processing unit(s) may be a single processor or a multi-core processor.

[0094] Read-only memory (ROM) 1530 stores static data and instructions required by the processing unit(s) 1510 and other modules of the electronic system. On the other hand, permanent storage device 1535 is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 1500 is turned off. Some embodiments of the present invention use a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) as permanent storage device 1535.

[0095] Other embodiments use removable storage devices (e.g., floppy disks, flash drives, etc.) as permanent storage devices. Like permanent storage device 1535, system memory 1525 is a read-write memory device. However, unlike storage device 1535, system memory is a volatile read-write memory, such as random access memory. System memory stores some instructions and data that the processor needs at runtime. In some embodiments, the processes of the present invention are stored in system memory 1525, permanent storage device 1535, and / or read-only memory 1530. (Multiple) processing unit 1510 retrieves instructions to be executed and data to be processed from these different memory units in order to perform the processing of some embodiments.

[0096] Bus 1505 is also connected to input and output devices 1540 and 1545. Input devices enable a user to transmit information and select commands to the electronic system. Input device 1540 includes an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). Output device 1545 displays images generated by the electronic system. Output devices include printers and display devices, such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Some embodiments include devices such as touch screens as input and output devices.

[0097] Finally, if Fig.15 As shown, bus 1505 also couples electronic system 1500 to a network 1565 via a network adapter (not shown). In this manner, the computer may be part of a computer network, such as a local area network ("LAN"), a wide area network ("WAN"), or an intranet, or one of the networks such as the Internet. Any or all of the components of electronic system 1500 may be used in conjunction with the present invention.

[0098] Some embodiments include electronic components such as microprocessors, storage devices, and memories that store computer program instructions in a machine-readable or computer-readable medium (or referred to as a computer-readable storage medium, a machine-readable medium, or a machine-readable storage medium). Some examples of such computer-readable media include RAM, ROM, compact disk-read only disk (CD-ROM), recordable compact disk (CD-R), rewritable compact disk (CD-RW), read-only digital versatile disk (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini-SD card, micro-SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable The computer readable medium may store a computer program that is executable by at least one processing unit and includes a set of instructions for performing various operations. Examples of computer programs or computer code include machine code such as produced by a compiler, and files including high-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0099] Although the above discussion mainly refers to a microprocessor or multi-core processor that executes software, some embodiments are performed by one or more integrated circuits such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). In some embodiments, such an integrated circuit executes instructions stored on the circuit itself.

[0100] As used in this specification, the terms "computer," "server," "processor," and "memory" all refer to electronic or other technical devices. These terms do not include people or groups of people. For the purpose of this description, the term display refers to displaying on an electronic device. As used in this specification, the terms "computer-readable medium," "computer-readable media," and "machine-readable medium" are entirely limited to tangible, physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other temporary signals.

[0101] This specification relates throughout to computing and network environments including virtual machines (VMs). However, a virtual machine is only one example of a data computing node (DCN) or a data computing end node (also referred to as an addressable node). A DCN may include a non-virtualized physical host, a virtual machine, a container that runs on top of a host operating system without a hypervisor or a separate operating system, and a hypervisor kernel network interface module.

[0102] In some embodiments, VMs operate on the host using their own client operating systems using the resources of the host virtualized by virtualization software (e.g., hypervisors, virtual machine monitors, etc.). Tenants (i.e., owners of VMs) can choose which applications to run on top of the guest operating system. On the other hand, some containers are structures that run on top of the host operating system without the need for a hypervisor or a separate guest operating system. In some embodiments, the host operating system uses namespaces to isolate containers from each other, and thus provides operating system-level isolation of different application groups operating in different containers. This isolation is similar to the VM isolation provided in an environment virtualized by a hypervisor of virtualized system hardware, so it can be considered a form of virtualization that isolates different application groups running in different containers. Such containers are more lightweight than VMs.

[0103] In some embodiments, the hypervisor kernel network interface module is a non-VMDCN that includes a network stack with a hypervisor kernel network interface and receive / transmit threads. An example of a hypervisor kernel network interface module is the vmknic module, which is a component of VMware's ESXi TM part of the management program.

[0104] It should be understood that although this description relates to VMs, the examples given may be any type of DCN, including physical hosts, VMs, non-VM containers, and hypervisor kernel network interface modules. In fact, in some embodiments, the example network may include a combination of different types of DCNs.

[0105] Although the present invention has been described with reference to many specific details, those skilled in the art will recognize that the present invention can be implemented in other specific forms without departing from the spirit of the present invention. Fig.10 and Fig.12 ) conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. Specific operations may not be performed in a continuous series of operations, and different specific operations may be performed in different embodiments. In addition, a process may be implemented using multiple sub-processes or as part of a larger macro process. Therefore, it will be understood by those of ordinary skill in the art that the present invention is not limited by the foregoing illustrative details, but is defined by the appended claims.

Claims

1. A method for forwarding a data message, the method comprising: performing a lookup to map a set of header fields of the data message to a specific identifier corresponding to a specific service that performs non-forwarding processing on the data message, wherein the specific identifier is one of a plurality of identifiers to which the header fields of the data message are mapped, each identifier corresponding to a different service and associated with a separate dynamically updated data structure, the dynamically updated data structure including instructions for forwarding the data message to the corresponding service; using a particular dynamically updated data structure associated with the particular identifier to retrieve instructions for forwarding the data message to the particular service; and forwarding the data message according to instructions retrieved from a specific data structure associated with the specific identifier, The specific dynamically updated data structure associated with the specific identifier specifies (i) an IP address for reaching the specific service, (ii) a reachability status for the specific service, and (iii) a failover strategy for when the specific service is unreachable.

2. The method of claim 1, wherein: The method is performed by a gateway of a logical network implemented in a data center, the gateway being used to process data messages between a logical network endpoint operating in the data center and a physical network external to the data center.

3. The method of claim 2, wherein: The logical network includes (i) at least one logical switch to which the logical network endpoints are connected and (ii) a logical router; The logical router includes a distributed routing component and one or more centralized routing components; and The gateway implements one of the centralized routing components to process data messages between the logical network endpoints and a physical network external to the data center.

4. The method of claim 1, wherein: The lookup includes a policy-based routing decision.

5. The method of claim 1, wherein: The set of header fields includes at least a source network address of the data message.

6. The method of claim 1, wherein: The specific service is a third-party service executed on one or more virtual machines.

7. The method of claim 1, wherein: The reachability status is dynamically updated based on a reachability protocol.

8. The method of claim 1, wherein: The specific service is connected using a layer 2 (L2) circuit plug-in mode, wherein the IP address is a pseudo address corresponding to an interface of a gateway that forwards the data message.

9. The method of claim 8, wherein: The interface is a first interface, wherein the gateway executes a Bidirectional Forwarding Detection (BFD) thread, the BFD thread sends a BFD message to the specific service through a second interface and receives the BFD message from the specific service through the first interface.

10. The method of claim 1, wherein: The IP address is the address of the machine that implements the specific service.

11. The method of claim 1, wherein: The failover policy specifies that data messages are discarded when the particular service is unreachable.

12. The method of claim 1, wherein: The failover policy specifies routing of data messages based on a destination network address when the particular service is unreachable.

13. The method of claim 1, wherein: The failover policy specifies a backup service to which the data message is to be redirected when the particular service is unreachable.

14. A machine-readable medium storing a program, which, when executed by at least one processing unit, implements the method according to any one of claims 1 to 13.

15. A computing device comprising: a set of processing units; as well as A machine-readable medium storing a program which, when executed by at least one of the processing units, implements the method according to any one of claims 1-13.

16. A system comprising means for implementing the method according to any one of claims 1-13.

17. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 13.

Images