Dynamic traffic redirection for virtual gateways of distributed tunnel structures

Abstract

A system for redirecting traffic is provided. The system can allow a first switch to join a virtual switch in combination with a second switch of an overlay tunnel fabric. Paths between respective pairs of switches of an underlay network of the fabric can be determined based on a routing process. The first switch and the second switch can each participate in the routing process. Accordingly, packets of a tunnel to the virtual switch can be distributed among paths to the first switch and the second switch. The system can determine a trigger condition that indicates that subsequently received packets via the tunnel are to be directed to the path to the second switch. The first switch and the second switch can remain in an operational state. The system can then advertise a high cost for a link to the first switch for the routing process in the underlay network.

Description

Technical Field

[0001] This disclosure relates to communication networks. More specifically, this disclosure relates to methods and systems for facilitating efficient traffic redirection of virtual gateways in distributed tunneling structures. Attached Figure Description

[0002] Figure 1 The illustration shows an example of traffic redirection using a virtual gateway switch (VGS) with a distributed tunneling structure of the underlying physical network according to one aspect of this application.

[0003] Figure 2A An example of event-driven traffic redirection for a VGS in a distributed tunneling structure according to one aspect of this application is illustrated.

[0004] Figure 2B The illustration shows a non-exhaustive set of events that cause traffic redirection in a distributed tunneling structure VGS according to one aspect of this application.

[0005] Figure 3 An example of the internal operation of a VGS participating in a switch in a distributed tunneling structure that facilitates traffic redirection according to one aspect of this application is illustrated.

[0006] Figure 4 A flowchart illustrating a process by which a VGS-participating switch facilitates event-driven traffic redirection according to one aspect of this application is presented.

[0007] Figure 5 A flowchart illustrating the process by which a switch in a distributed tunneling architecture according to one aspect of this application redirects traffic to participating switches in the architecture's VGS is presented.

[0008] Figure 6 An exemplary switch is illustrated in accordance with one aspect of this application, which facilitates VGS support for effective traffic direction.

[0009] In the accompanying drawings, the same reference numerals refer to the same elements. Detailed Implementation

[0010] The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein can be applied to other examples and applications without departing from the spirit and scope of the invention. Therefore, the invention is not limited to the aspects shown, but is accorded the widest scope consistent with the claims.

[0011] The Internet is the delivery medium for a wide range of applications running on both physical and virtual devices. These applications generate ever-increasing traffic demands. Therefore, equipment vendors are racing to build switches with diverse functionalities. For this purpose, switches may support different protocols and services. For example, a switch may support tunneling and Virtual Private Networks (VPNs). The switch can then facilitate VPN overlay routing over tunnels. For instance, an Ethernet VPN (EVPN) can be deployed as overlay over a set of Virtual Extensible Local Area Networks (VXLANs). To deploy a VPN over a tunnel, the corresponding tunnel endpoints can map the corresponding client Virtual Local Area Networks (VLANs) to a corresponding Tunnel Network Identifier (TNI), which identifies the virtual network used for the tunnel.

[0012] The TNI can appear in the tunnel header of encapsulated packets and is used to forward encapsulated packets via the tunnel. For example, if the tunnel is based on VXLAN, the TNI can be the Virtual Network Identifier (VNI) in the VXLAN header, and the tunnel endpoint can be the VXLAN Tunnel Endpoint (VTEP). If Layer 3 routing and forwarding are required, the TNI can also be mapped to the Virtual Router and Forwarder (VRF) associated with the tunnel. Because VPNs can be distributed over tunnel structures, VPNs over tunnel structures can also be called distributed tunnel structures. The gateway of the structure can be a Virtual Gateway Switch (VGS) shared among multiple participating switches. Typically, each participating switch can receive traffic from the tunnel to the VGS via an equi-cost path. Therefore, selecting which participating switch should receive traffic under specific network conditions (e.g., due to one or more events) can be challenging.

[0013] One aspect of this technology provides a system for redirecting traffic. This system allows a first switch to join a second switch to join a virtual switch. The virtual switch can operate as a gateway including an overlay tunnel structure for the first and second switches. Paths between corresponding switch pairs in the underlying network of the overlay tunnel structure can be determined based on routing procedures. The first and second switches can participate in the routing procedure individually. Therefore, packets tunneled to the virtual switch can be distributed along paths to the first and second switches in the underlying network. The system can then determine a triggering condition at the first switch that indicates that packets subsequently received via the tunnel to the virtual switch will be redirected to the path to the second switch. However, the first and second switches can remain operational. After determining the triggering condition, the system can advertise the high cost of the link to the first switch in relation to the routing procedure in the underlying network, thereby bypassing the distribution of packets to the virtual switch along paths to the first and second switches.

[0014] In this variant, the system can determine whether an event has been completed. If the event has been completed, the system can advertise the default cost of the link to the first switch for the routing process in the underlying network, thereby resetting the distribution of packets to the virtual switch in the path to the first and second switches.

[0015] In this variation, the trigger condition can indicate that the tunnel state is inconsistent between the switch and the second switch.

[0016] In a variation of this, the trigger condition can indicate that the traffic volume on the inter-switch link between the first and second switches exceeds a threshold.

[0017] In a variation of this, the trigger condition can indicate that the tunnel to the virtual switch is operational at the first switch before the host is detected via the edge port.

[0018] In a variation of this, the triggering condition can indicate that the first switch has been restarted and that packet processing for covering the tunnel structure is operational in the second switch.

[0019] In a variation of this, the triggering condition may indicate one or more of the following: a non-operational edge connection at the first switch, and unavailable route adjacency to the client's device, thereby indicating the client's migration.

[0020] In a variation of this, the trigger condition can indicate the start of a timer, and the timer indicates the duration of the event.

[0021] In this variation, the system can configure high cost in the routing information associated with the underlying network. Then, announcing the high cost can include sending link-state advertisements using a local instance of the routing procedure.

[0022] The aspects described herein address the issue of redirecting traffic to a subset of participating switches in the fabric's VGS by: (i) configuring differentiated costs (e.g., high costs) to the remaining participating switches after a triggering event is determined; and (ii) advertising the differentiated costs to neighboring switches in the underlying network of the fabric. Thus, using the routing procedures of the underlying network, other switches in the fabric can determine that traffic to the VGS should be carried via the corresponding path to the subset of participating switches. In this way, other switches can avoid forwarding traffic to the remaining participating switches during the event.

[0023] The infrastructure may include a Virtual Gateway (VGS) that can couple the infrastructure to other networks. Typically, at least two switches can be combined to operate as a single switch to facilitate the VGS. Switches participating in the VGS can be referred to as participating switches. A corresponding participating switch can treat other participating switches as peer participating switches (or peer-to-peer switches). The VGS can be associated with one or more virtual addresses (e.g., virtual Internet Protocol (IP) addresses and / or virtual Media Access Control (MAC) addresses). The corresponding tunnels formed at the VGS can use virtual addresses to form tunnel endpoints. As a result, other tunnel endpoints of the infrastructure can treat the VGS as other tunnel endpoints of the tunnel, rather than any participating switch.

[0024] Participating switches can advertise the same virtual address (e.g., a virtual IP address) to other switches in the underlying network, which are non-participating switches. Because participating switches form a Virtual Group System (VGS), corresponding paths between participating switches typically have the same routing weight (e.g., the same number of hops or the same total link weight). Therefore, during routing in the underlying network, participating switches can be considered equidistant from non-participating switches. Consequently, non-participating switches in the underlying network can establish paths to the corresponding participating switch associated with the virtual address. Because participating switches can be equidistant during routing, paths from non-participating switches to participating switches can be established as Equal Cost Multipath (ECMP) paths to the VGS.

[0025] To forward traffic toward the VGS in the architecture, a non-participating switch can operate as a tunnel endpoint, and the VGS can be another tunnel endpoint. The non-participating switch can perform load balancing (e.g., based on hashing of the corresponding packets) across the equi-cost path to the VGS and select one of the participating switches as the destination in the underlying network, thus selecting the corresponding path from ECMP. The non-participating switch can then forward packets via tunnels between the tunnel endpoints. Even if one of the paths to the VGS is selected in the underlying network, the destination of the tunnel header corresponds to the virtual address associated with the VGS.

[0026] If an event adversely affects the ability of participating switches to process traffic destined for the VGS, the corresponding non-participating switches may need to divert traffic to other participating switches in the VGS. Therefore, non-participating switches may need to avoid selecting paths to affected participating switches in the underlying network. Consequently, the routing procedures of the underlying network (e.g., exterior gateway protocols, such as eBGP) should not select that path as one of the ECMPs to the VGS during the event. To this end, the routing procedures of the underlying network may advertise a higher path cost than other paths to the VGS. Therefore, the path to the VGS may not be considered as an ECMP.

[0027] Because events in a network can be dynamic, the initiation and termination of path avoidance should also be dynamic. Specifically, when an event completes, path avoidance should no longer be effective, and the cost of the path should be reset to the cost of other paths. When the path cost is reset, all paths to the VGS may have the same cost during the routing process. However, existing technologies do not support this event-driven dynamic adjustment of path costs for the routing process of the underlying network infrastructure. Manually configuring path costs for the routing process can be error-prone and may not be feasible.

[0028] To address this issue, the participating switch can dynamically determine events that might require non-participating switches in the architecture to avoid forwarding traffic to that participating switch. The participating switch can maintain routing process instances, such as eBGP instances, for the underlying network. Upon determining an event, the routing process instance can advertise the distinguishable cost (e.g., high cost) of the links coupled to the participating switch, while simultaneously advertising the virtual address of the VGS to the underlying network. The distinguishable cost can be based on Autonomous System (AS) path-prepend or Multiple Exit Discriminator (MED). As a result, the routing process instance of the corresponding non-participating switch can determine that the device associated with that virtual address (i.e., the VGS) is reachable via a path with distinguishable cost and a set of paths with the same cost. Here, the distinguishable cost path could be a path to the participating switch affected by the event.

[0029] It should be noted that non-participating switches (NPSs) can use the path selection process to choose the underlying network path for tunnels from the NPS to the VGS. In other words, because there are multiple switches in the VGS, multiple paths can exist for tunnels with the same virtual address to the VGS. NPSs can use different paths leading to different participating switches to forward packets of the same flow. However, NPSs may not include distinguishable cost paths in the underlying network's path selection process for subsequent packets to the VGS.

[0030] For example, if non-participating switches typically use hash functions to select the path from ECMP to VGS in the underlying network, they can exclude the distinguishable cost path from the hashing process because that path is no longer part of the ECMP to VGS path. Therefore, for subsequent packets, non-participating switches can avoid sending packets to participating switches affected by the event. In this way, non-participating switches can forward traffic only to participating switches unaffected by the event. As a result, traffic to the VGS in the architecture can be redirected to other participating switches in the VGS.

[0031] Subsequently, the participating switches can determine that the event is complete. Then, the routing process instance of the participating switches can advertise the reset cost for the links coupled to the participating switches, while simultaneously advertising the virtual address of the VGS to the underlying network. The reset cost can be the cost of the link prior to the event. The value of the reset cost ensures that the path to the participating switches is included in the ECMP to the VGS. As a result, the routing process instance of the non-participating switches can determine that the device associated with the virtual address (i.e., the VGS) is reachable via a set of paths with the same cost. Therefore, the non-participating switches can begin including paths to the participating switches affected by the event in their path selection process for subsequent packets to the VGS.

[0032] In this way, the participating switches can redirect traffic flows to the VGS in the infrastructure by announcing distinguishable costs and resetting costs upon event detection and completion, respectively. This allows the VGS to use the underlying network's routing procedures to redirect traffic without affecting the tunneling protocols of the overlay network. Cost adjustments can be performed during the underlying network's routing procedures even when the VGS's virtual address is still associated with the affected participating switch. Furthermore, the initiation and termination of avoidance by the affected participating switch can be dynamically executed upon event detection and completion, respectively.

[0033] The process of dynamically redirecting traffic to a subset of participating switches can be performed by a centralized controller (e.g., a software-defined networking (SDN) controller) or by an application running on the participating switches. For example, the controller or application can configure differentiated costs and reset costs in the participating switches' local databases upon event detection and completion, respectively. Based on this update, routing daemons associated with the underlying network's routing procedures can facilitate the advertising of differentiated costs and reset costs.

[0034] In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or structured switch operating at any network layer. "Switch" should not be construed as limiting the examples of the invention to Layer 2 networks. Any device that can forward traffic to external devices or other switches can be called a "switch". Any physical or virtual device (e.g., a virtual machine or switch operating on a computing device) that can forward traffic to end devices can be called a "switch". Examples of "switch" include, but are not limited to, Layer 2 switches, Layer 3 routers, routing switches, components of Gen-Z networks, or structured switches comprising multiple similar or heterogeneous smaller physical and / or virtual switches.

[0035] The term "packet" refers to a group of bits that can be transmitted together over a network. "Packet" should not be construed as limiting the examples of this invention to Layer 3 networks. "Packet" can be replaced by other terms referring to a group of bits, such as "message," "frame," "cell," "datagram," or "transaction." Furthermore, the term "port" can refer to a port that can receive or transmit data. "Port" can also refer to the hardware, software, and / or firmware logic that facilitates the operation of that port.

[0036] Figure 1 The illustration depicts an example of traffic redirection for a VGS using a distributed tunneling structure of an underlying physical network according to one aspect of this application. Network 100 may include multiple switches and devices. In some examples, network 100 may be Ethernet, InfiniBand, or other networks, and may use corresponding communication protocols such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. Network 100 may include a distributed tunneling structure 110, which includes switches 101, 102, 103, 104, and 105. Switches 101 and 102 of structure 110 may be coupled to a core switch 106. Structure 110 may be coupled to an external network 120 via switch 106.

[0037] exist Figure 1 In the structure 110, the corresponding links indicated by dashed lines can be tunnels. The switches in structure 110 can form a tunnel mesh. Examples of tunnels may include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization Using GRE (NVGRE), Geneve Networking Virtualization Encapsulation (Geneve), and Internet Protocol Security (IPsec). The corresponding links indicated by dashed lines in structure 110 can be links in the underlying network (or underlying network) 150 of structure 110. The underlying network 150 can be a physical network, and the corresponding links in the underlying network 150 can be physical links. A VPN 130, such as an EVPN, can be deployed on structure 110. Structure 110 may include a VGS 106 that can couple structure 110 to an external network 120. An external switch 107 can be coupled to the VGS 106, thereby coupling the external network 120 to structure 110.

[0038] Here, switches 101 and 102 can be combined to operate as a single switch to facilitate VGS 106. VGS 106 can be associated with one or more virtual addresses (e.g., virtual IP addresses and / or virtual MAC addresses). The corresponding tunnels formed at VGS 106 can use virtual addresses to form tunnel endpoints. To efficiently manage data forwarding, switches 101 and 102 can maintain an inter-switch link (ISL) 140 between them for sharing control and / or data packets. ISL 140 can be a Layer 2 or Layer 3 connection that allows data forwarding between switches 101 and 102. ISL 140 can also be based on a tunnel between switches 101 and 102 (e.g., a VXLAN tunnel).

[0039] Because the virtual address of VGS 106 is associated with both switches 101 and 102, other tunnel endpoints in fabric 110 (such as switches 103, 104, and 105) can treat VGS 106 as another tunnel endpoint, rather than switches 101 and 102. To forward traffic to VGS 106 in fabric 110, a non-participating switch such as switch 103 can operate as one tunnel endpoint, and VGS 106 can be another. From each of the non-participating switches 103, 104, and 105, a set of ECMPs can exist to VGS 106. The corresponding paths in the ECMPs can lead to one of the participating switches of VGS 106. Figure 1 In the example, the number of paths in ECMP can be two, leading to switches 101 and 102 respectively.

[0040] During operation, switch 103 can receive packets from device 112 via an edge port (e.g., an Ethernet port). If the packet is destined for device 114, switch 103 can encapsulate the packet in a tunnel header and forward the encapsulated packet to VGS 106 via tunnel 132. The encapsulated packet can then be carried by links in the underlying network 150 to one of switches 101 and 102. Switch 103 can perform load balancing operations between equivalent paths in the underlying network 150 that tunnel 132 can traverse. For example, switch 103 can apply a hash function to the packet and select one of switches 101 and 102 as the destination in the underlying network 150, thereby selecting the corresponding path from ECMP. Switch 103 can then forward the packet on the selected path via tunnel 132. Even if one of the paths to VGS 106 is selected in the underlying network 150, the destination in the tunnel header can correspond to the virtual address associated with VGS 106.

[0041] If event 160 adversely affects the ability of participating switch 101 to handle traffic destined for VGS 106, switches 103, 104, and 105 may need to divert traffic to other participating switches 102 in VGS 106. In this scenario, non-participating switches such as switch 103 may need to avoid selecting path 134 to switch 101 in the underlying network 150. Therefore, the routing procedure instance (RPI) 174 (e.g., an eBGP instance) on switch 103 for the underlying network 150 should not select path 134 as one of the ECMPs to VGS 106 during the duration of event 160. To this end, RPI 172 on switch 101 for the underlying network 150 may advertise that the path cost of path 134 to VGS 106 is higher than the cost of another path to VGS 106, the other path being to switch 102. Therefore, paths to switches 101 and 102 may not be considered ECMPs.

[0042] Since event 160 can be dynamic, the initiation and termination of avoidance for path 134 should also be dynamic. Specifically, when event 160 completes, avoidance for path 134 should no longer be effective, and the cost of path 134 should be reset to the cost of path 136. When the cost of path 134 is reset, paths 134 and 136 to VGS 106 may have the same cost from switch 103 (e.g., from RPI 174). However, the prior art does not support this event-driven dynamic adjustment of the cost of path 134 for RPIs 172 and 174 of the underlying network 150. Manually configuring the cost of path 134 for RPIs 172 and 174 may be error-prone and may be impractical.

[0043] To address this issue, switches 101 and 102 can dynamically determine the occurrence of event 160, which may require non-participating switches 103, 104, and 105 to avoid forwarding traffic to switch 160. When switch 101 determines event 160, RPI 172 can advertise the distinguishable cost (e.g., high cost) of the link to coupled switch 101, while simultaneously advertising the virtual address of VGS 106 to the underlying network 150. The distinguishable cost can be based on AS "path-pre-configured" or MED. For example, switch 101 can send corresponding Link State Advertisements (LSAs) 152, 154, and 156 via links to non-participating switches 103, 104, and 105, respectively. The corresponding LSAs may include route updates indicating distinguishable costs. Upon receiving LSA 152, RPI 174 of switch 103 can update the Routing Information Base (RIB) and the corresponding Forwarding Information Base (FIB) at switch 103 accordingly. RPI 174 can then determine that the device associated with the virtual address (i.e., VGS 106) is reachable via path 134 with distinguishable cost and path 136 with default cost associated with ECMP to VGS 106.

[0044] Typically, switch 103 can use a path selection process to select one or more paths 134 and 136 in the underlying network 150 for tunnel 132 from switch 103 to VGS 106. In other words, because there are two switches 101 and 102 in VGS 106, there can be two paths for tunnel 132 with the same virtual address to VGS 106. Switch 103 can use the different paths to switches 101 and 102 to forward packets of the same flow. However, switch 103 may not include path 134 in the path selection process in the underlying network 150 for subsequent packets to VGS 106. For example, if switch 103 typically uses a hash function to select a path from equivalent paths 134 and 136, path 134 can be excluded from the hash process because path 134 is no longer part of the ECMP to VGS 106. Therefore, for subsequent packets, switch 103 can avoid sending packets to switch 101 and can forward traffic only to switch 102. As a result, traffic destined for VGS 106 in structure 110 can be redirected to switch 102 of VGS 106.

[0045] Subsequently, switch 101 can determine that event 160 has been completed. Then, switch 101's RPI 172 can advertise the reset cost for the link to coupled switch 101, while simultaneously advertising the virtual address of VGS 106 to the underlying network 150. The reset cost can be the cost of the link prior to event 160. The value of the reset cost ensures that path 134 is included in the ECMP to VGS 106. Switch 101 can then send the corresponding LSA with the reset cost via the links to non-participating switches 103, 104, and 105. As a result, switch 103's RPI 174 can then determine that the device associated with the virtual address (i.e., VGS 106) is reachable via paths 134 and 136 with the same cost. Therefore, switch 103 can begin including path 134 to switch 101 affected by event 160 in the path selection process for subsequent packets to VGS 106.

[0046] In this way, switch 101 can redirect traffic from switches 103, 104, and 105 in structure 110 to VGS 106 by announcing distinguishable costs and resetting costs upon detection and completion of event 160, respectively. This allows VGS 106 to use the routing procedures of the underlying network 150 to redirect traffic without affecting the tunneling protocols of the overlay network in structure 110. RPI 172 can also perform cost adjustments during the routing process of the underlying network 150, even while the virtual address of VGS 106 remains associated with the affected switch 101. Furthermore, the initiation and termination of avoidance of path 134 and the corresponding switch 101 can be dynamically executed upon detection and completion of event 160, respectively.

[0047] The process of dynamically redirecting traffic to switch 102 can be performed by a centralized controller (e.g., an SDN controller) or an application running on switch 101. The controller or application can configure differentiated costs and reset costs in a local database on switch 101 upon detection and completion of event 160, respectively. The local database can be a link cost table for RPI 172 at switch 101. The link cost table on switch 101 can be located in the local database. Based on updates, the routing daemon associated with RPI 172 can facilitate the advertising of differentiated costs and reset costs.

[0048] Figure 2AAn example of event-driven traffic redirection for a VGS in a distributed tunneling structure according to one aspect of this application is illustrated. In this example, devices 112 and 114 can communicate with each other via structure 110. Device 114 can be coupled to switch 107, which can be coupled to structure 110 via link aggregation group (LAG) 200. Therefore, switch 107 can be coupled to switches 101 and 102, and the coupled links can be aggregated based on a link aggregation protocol such as Link Aggregation Control Protocol (LACP). Device 112 can send data stream 212 to device 114. Data stream 212 can include a sequence of packets. Switch 103 can receive packets from data stream 212 and determine that packets from data stream 212 should be forwarded to VGS 106. Switch 103 can then encapsulate these packets with a tunnel header associated with tunnel 132. Based on a path selection process, the encapsulated packets are distributed on paths 134 and 136.

[0049] However, due to event 160, switch 101, although associated with the virtual address of VGS 106, may not be able to process packets effectively. In other words, even if switch 101 is operational (i.e., neither powered down nor unavailable), switch 101 may still fail to process packets effectively due to event 160. Examples of event 160 may include, but are not limited to: inconsistent operational states of tunnel 132 at switches 101 and 102, excessive use of ISL 140, inoperability of the connection to device 214, traffic arriving before device 214 is detected, reloading or restarting of switch 101, migration of connections from switch 101 to switch 102, and timer-based triggering (e.g., user-defined events). For example, if tunnel 132 becomes operational and packets of data stream 212 arrive at switch 101 before the presence of device 214 is determined, switch 101 may fail to process the packets correctly.

[0050] Switch 101 can maintain a set of triggering conditions for a corresponding event. If the triggering conditions are met, switch 101 can determine that the corresponding event has occurred. After determining that the triggering conditions for event 160 are met, switch 101 can determine the initiation (or triggering) of event 160. Then, RPI 172 can send LSA 152 with distinguishable cost to switch 103 in the underlying network 150. After receiving LSA 152, RPI 174 of switch 103 can update local routing information. RPI 174 can then determine that packets of data flow 212 should be redirected from path 134 to path 136. Switch 103 can then forward subsequent encapsulated packets of data flow 212 via path 136, thereby dynamically redirecting the encapsulated packets of data flow 212 to 106 in VGS structure 110.

[0051] Switch 101 can also maintain a set of reset conditions for the corresponding event. If the reset conditions are met, switch 101 can determine that the corresponding event has been completed. After determining that the reset conditions for event 160 are met, switch 101 can determine the termination (or completion) of event 160. RPI 172 can then send an LSA with reset cost to switch 103 in the underlying network 150. Upon receiving the LSA, RPI 174 of switch 103 can update local routing information. RPI 174 can then determine that packets of data flow 212 can now be forwarded via paths 134 and 136. Switch 103 can then forward subsequent encapsulated packets of data flow 212 via both paths 134 and 136, thereby dynamically repositioning the encapsulated packets of data flow 212 to VGS 106 in architecture 110.

[0052] Similarly, device 114 can send data stream 214 to device 112. Switch 107 can receive packets of data stream 214 and determine that the packets should be forwarded to fabric 110. Since switch 107 is coupled to fabric 110 via LAG 200, switch 107 can select one of the links in LAG 200 and forward the corresponding packets of data stream 214 via the selected link. For the same data stream 214, switch 107 can select different links in LAG 200 for different packets. As a result, both switches 101 and 102 can receive packets of data stream 212. However, due to event 160, switch 101 may be unable to forward traffic via fabric 110. Therefore, switch 101 can forward packets of data stream 212 to switch 102 via ISL 140. In this way, even if switch 101 is operational, any inefficiency or interruption in traffic forwarding at switch 101 can be avoided.

[0053] Switch 101 can maintain a set of events that may cause traffic redirection. Figure 2B The illustration depicts a non-exhaustive set of events that causes traffic redirection in a VGS of a distributed tunneling architecture according to one aspect of this application. The event set 250 at switch 101 may include event 254, trigger condition 256, and reset condition 258. If trigger condition 256 is met, switch 101 can determine that event 254 has occurred. Furthermore, if reset condition 256 is met, switch 101 can determine that event 254 has been completed. The corresponding event may be associated with event identifier 252, which may be included in an LSA to notify other switches in architecture 110 about the event. Switch 101 may store the event set 250 in a data structure such as an event table. The event table may be a database table.

[0054] Event identifier 262 can correspond to an event with inconsistent tunnel states. A trigger condition can indicate that, for a specific tunnel, the local tunnel state is closed and the peer tunnel state is open. For example, the state of tunnel 132 at switch 101 could be "open," while the state at switch 102 could be "closed." A reset condition can indicate that all tunnel states are open (i.e., at both switches 101 and 102). Another event identifier 264 can correspond to an event where an ISL (e.g., ISL 140) is overutilized by redirected traffic. A trigger condition can indicate that the traffic volume on the ISL exceeds a threshold. Similarly, a reset condition can indicate that the traffic volume on the ISL is below a threshold for a period of time, which prevents the ping-pong effect.

[0055] Furthermore, event identifier 266 may correspond to an event in which client-facing connections (e.g., switch virtual interfaces (SVIs) or switch ports for clients) are inoperable. A trigger condition may indicate that all edge connections are inoperable at the local switch. For example, the configuration associated with a client device may not be "on" at switch 101. A corresponding reset condition may indicate that at least a subset of edge connections are operable (e.g., connections to a subset of client devices may be operable). Additionally, event identifier 268 may correspond to an event indicating that traffic arrives via the structure before a host (e.g., a client device) is detected from the edge port. A trigger condition may then indicate that a tunnel at the switch is operable before a local host, such as an end device, is detected (e.g., tunnel 132 at switch 101). A reset condition may include host information obtained from the edge port(s).

[0056] Furthermore, event identifier 270 may correspond to an event indicating a reload / reboot of the local switch. Triggering conditions may indicate that the local switch has been initialized and the VPN is operational at the peer switch. For example, switch 101 may be initialized after a power cycle, and the VPN may be operational on switch 102. Due to the reboot of switch 101, local tunnels at switch 101 (such as tunnel 132) may be inoperable for a short period. However, switch 103 can become aware of the presence of switch 101 in the underlying network 150 and begin selecting a path to switch 101. However, since the tunnel is not yet operational, forwarding may fail via tunnel 132 in structure 110, resulting in a collision. A reset condition may then indicate that all tunnel states are now open (i.e., at both switches 101 and 102).

[0057] Furthermore, event identifier 272 can correspond to an event indicating a single point of client connection. For example, due to client migration, all client devices may be coupled only to switch 102 and not to switch 101. A trigger condition can indicate that routing adjacency to the client device is unavailable. A reset condition can then indicate that routing adjacency to the client device has been re-established and the corresponding router has been re-acquired. Event set 250 can also include user-defined events, such as timer-based events associated with event identifier 274. Users, such as administrators, can define timers to indicate the duration for which traffic should be redirected. Thus, a trigger condition can be the start of a timer, and a reset condition can be the completion of a timer.

[0058] Figure 3 An example of internal operation within a participating switch of a VGS in a distributed tunneling architecture facilitating traffic redirection according to one aspect of this application is illustrated. Switch 101 may maintain a database 310 (e.g., based on the Open vSwitch Database (OVSDB)) for storing configuration information associated with switch 101. For example, a list of costs for corresponding adjacent links may be maintained in a table in database 310. Configuration daemon 302 of switch 101 may update the configuration information in database 310. RPI 172 may be facilitated by routing daemon 304 (e.g., a BGP daemon). Based on routing updates from routing daemon 304, configuration daemon 302 may update database 310 to facilitate traffic redirection from switch 101.

[0059] During operation, routing daemon 304 can detect that a triggering condition associated with an event is met (i.e., the event is triggered or initiated) (operation 312). Based on the detection of the triggering condition, configuration daemon 302 can configure differentiated costs for links to the local switch (operation 314). For example, configuration daemon 302 can configure differentiated costs for links to switch 101 in database 310. The configuration of differentiated costs allows routing daemon 304 to advertise differentiated costs in the underlying network (operation 316). Therefore, the corresponding routing daemons on other switches in the underlying network can determine that links to switch 101 are associated with differentiated costs.

[0060] The routing daemon 304 can then monitor the completion of the event (operation 318). Subsequently, the routing daemon 304 can detect that the corresponding reset condition associated with the event has been met (i.e., the event has completed or terminated) (operation 320). Based on the detection of the reset condition, the configuration daemon 302 can configure a reset cost for the link to the local switch (operation 322). The reset cost can correspond to the default cost indicated in the ECMP to the VGS. The configuration of the reset cost allows the routing daemon 304 to advertise the reset cost in the underlying network (operation 324). Therefore, the corresponding routing daemons on other switches in the underlying network can determine the links to switch 101 associated with the reset cost. Therefore, other switches can incorporate the path to switch 101 during the path selection process.

[0061] Figure 4 A flowchart illustrating a process by which a VGS participating switch facilitates event-driven traffic redirection according to one aspect of this application is presented. During operation, the switch can monitor a set of events for triggering (operation 402) and determine whether the triggering conditions of the event are met (i.e., the event is triggered) (operation 404). The switch can continue monitoring the set of events for triggering until the triggering conditions are met (operation 402). On the other hand, if the triggering conditions of the event are met, the switch can set differentiated costs for links arriving at the local switch (operation 406). Therefore, the switch can configure differentiated costs in its local database (operation 408) and advertise the differentiated costs to the corresponding neighbors in the underlying network (operation 410).

[0062] The switch can then monitor the completion of the triggering event (operation 412) and determine whether the event's reset condition is met (i.e., the event is complete) (operation 414). The switch can continue monitoring the completion of the triggering event until the event's reset condition is met (operation 412). Alternatively, if the event's reset condition is met, the switch can set a reset cost for the link reaching the local switch (operation 416). Therefore, the switch can configure the reset cost in its local database (operation 418) and advertise the reset cost to the corresponding neighbor in the underlying network (operation 420).

[0063] Figure 5 A flowchart illustrating the process by which a switch in a distributed tunneling architecture according to one aspect of this application redirects traffic to a participating switch in the architecture's VGS is presented. During operation, the switch may receive the distinguishable cost of links arriving at the participating switch in the local VGS (operation 502). The switch may then update the local forwarding information associated with the participating switch in the underlying network based on the distinguishable cost (operation 504). This allows the switch to avoid the participating switch during path selection.

[0064] Subsequently, the switch can receive the reset cost of the link to the participating switch in the local VGS (operation 506). The switch can then update the local forwarding information associated with the participating switch in the underlying network based on the reset cost (operation 508). This allows the switch to incorporate the path to that participating switch into the path selection process. The forwarding information can be stored in one or more tables, such as FIB and RIB. These tables can be stored in the switch's database.

[0065] Figure 6 An exemplary switch facilitating VGS support for effective traffic direction is illustrated according to one aspect of this application. In this example, switch 600 includes multiple communication ports 602, packet processor 610, and storage device 650. Switch 600 may also include switch hardware 660 (e.g., processing hardware of switch 600, such as its application-specific integrated circuit (ASIC) chip) that includes information based on which switch 600 processes the packet (e.g., determining the output port used for the packet). Packet processor 610 extracts and processes header information from received packets. Packet processor 610 can identify switch identifiers (e.g., MAC addresses and / or IP addresses) associated with switch 600 in the packet header.

[0066] Communication port 602 may include an inter-switch communication channel for communicating with other switches and / or user equipment. The communication channel may be implemented via a conventional communication port and based on any open or proprietary format. Communication port 602 may include one or more Ethernet ports capable of receiving frames encapsulated in Ethernet headers. Communication port 602 may also include one or more IP ports capable of receiving IP packets. The IP ports are capable of receiving IP packets and may be configured with IP addresses. Packet processor 610 can process Ethernet frames and / or IP packets. The corresponding ports of communication port 602 can operate as ingress ports and / or egress ports.

[0067] Switch 600 may maintain a database 652 (e.g., in storage device 650). Database 652 may be a relational database and may run on one or more DBMS instances. Database 652 may store information associated with the routing, configuration, and interfaces of switch 600. Switch 600 may include a VGS logical block 642 and a routing logical block 644. VGS logical block 642 allows switch 600 to operate as a VGS, such as VGS 106, in a distributed tunneling architecture. For this purpose, VGS logical block 642 may be combined with another switch. Routing logical block 644 facilitates the operation of RPIs for switch 600 and determines paths in the underlying network.

[0068] Switch 600 may include a redirection logic block 630, which may include a triggering logic block 632, a reset logic block 634, and a cost logic block 636. The redirection logic block 630 can operate in conjunction with the routing logic block 644. The triggering logic block 632 can monitor a set of events and determine whether the triggering conditions for an event are met. The reset logic block 634 can monitor the process of triggering an event and determine whether the reset conditions for the event are met.

[0069] If an event is triggered, cost logic block 636 can configure distinguishable costs for local routing information (e.g., in database 652) and advertise distinguishable costs via the corresponding link-coupled switch 600. Conversely, when the triggering event completes, cost logic block 636 can configure reset costs for local routing information (e.g., in database 652) and advertise reset costs via the corresponding link-coupled switch 600. Switch 600 can use either distinguishable or reset costs advertised, including route updates via LSAs.

[0070] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which can be any device or medium capable of storing code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as magnetic disks, magnetic tapes, CDs (compressed discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or hereafter developed.

[0071] The methods and processes described in the detailed description section may be embodied in code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied in data structures and code and stored within the computer-readable storage medium.

[0072] The methods and processes described herein may be executed by and / or included in hardware modules or devices. These modules or devices may include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software modules or pieces of code at specific times, and / or other programmable logic devices now known or developed later. When the hardware modules or devices are activated, they execute the methods and processes included therein.

[0073] The foregoing description of examples of the invention has been presented for illustrative and descriptive purposes only. It is not intended to be exhaustive or limiting of this disclosure. Therefore, many modifications and variations will be apparent to those skilled in the art. The scope of the invention is defined by the appended claims.

Claims

1. A method comprising: A virtual switch is added by combining a first switch and a second switch, wherein the virtual switch operates as a gateway for an overlay tunnel structure, the overlay tunnel structure including the first switch and the second switch, wherein a routing process is used to determine the path between corresponding switch pairs in the underlying network of the overlay tunnel structure, wherein the first switch and the second switch each participate in the routing process, and wherein packets of the tunnel to the virtual switch are distributed in the paths to the first switch and the second switch in the underlying network; The first switch determines the triggering condition of the event, which indicates that packets subsequently received via the tunnel to the virtual switch will be routed to the second switch, wherein the first switch and the second switch remain in an operational state; as well as In response to determining the triggering condition, the high cost of the link to the first switch is advertised for the routing process in the underlying network, thereby bypassing the distribution of packets to the first switch in the paths to the first switch and the second switch.

2. The method according to claim 1, further comprising: In response to determining that the event is complete, the default cost of the link to the first switch is announced for the routing process in the underlying network, thereby resetting the distribution of packets to the virtual switch in the paths to the first switch and the second switch.

3. The method according to claim 1, wherein the triggering condition indicates that the tunnel state is inconsistent between the first switch and the second switch.

4. The method according to claim 1, wherein the triggering condition indicates that the traffic volume on the inter-switch link between the first switch and the second switch is higher than a threshold.

5. The method of claim 1, wherein the triggering condition indicates that the tunnel to the virtual switch is operable at the first switch before the host is detected via the edge port.

6. The method of claim 1, wherein the triggering condition indicates: The first switch has been restarted; and Packet processing for the overlay tunnel structure is operable in the second switch.

7. The method of claim 1, wherein the triggering condition indicates one or more of the following: Inoperable edge connections at the first switch; and The unavailability of routes to the client's device indicates the client's migration.

8. The method of claim 1, wherein the triggering condition indicates the start of a timer, and the timer indicates the duration of the event.

9. The method of claim 1, further comprising configuring the high cost in routing information associated with the underlying network; The high cost mentioned in the announcement includes sending link-state announcements using a local instance of the routing procedure.

10. A non-transitory computer-readable storage medium storing instructions, said instructions causing the computer to perform a method when executed by the computer, said method comprising: A virtual switch is added by combining a first switch and a second switch, wherein the virtual switch operates as a gateway for an overlay tunnel structure, the overlay tunnel structure including the first switch and the second switch, wherein a routing process is used to determine the path between corresponding switch pairs in the underlying network of the overlay tunnel structure, wherein the first switch and the second switch each participate in the routing process, and wherein packets of the tunnel to the virtual switch are distributed in the paths to the first switch and the second switch in the underlying network; The first switch determines the triggering condition of the event, which indicates that packets subsequently received via the tunnel to the virtual switch will be routed to the second switch, wherein the first switch and the second switch remain in an operational state; as well as In response to determining the triggering condition, for the routing process in the underlying network, a high cost of the link to the first switch is announced, thereby bypassing the distribution of packets to the first switch in the paths to the first switch and the second switch.

11. The non-transitory computer-readable storage medium of claim 10, wherein the method further comprises, in response to determining that the event is complete, announcing the default cost of the link to the first switch for the routing process in the underlying network, thereby resetting packet distribution to the virtual switch in the path to the first switch and the second switch.

12. The non-transitory computer-readable storage medium of claim 10, wherein the triggering condition indicates that the tunnel state is inconsistent between the first switch and the second switch.

13. The non-transitory computer-readable storage medium of claim 10, wherein the triggering condition indicates that the traffic volume on the inter-switch link between the first switch and the second switch is higher than a threshold.

14. The non-transitory computer-readable storage medium of claim 10, wherein the triggering condition indicates that the tunnel to the virtual switch is operable at the first switch before a host is detected via the edge port.

15. The non-transitory computer-readable storage medium of claim 10, wherein the triggering condition indicates: The first switch has been restarted; and Packet processing for the overlay tunnel structure is operable in the second switch.

16. The non-transitory computer-readable storage medium of claim 10, wherein the triggering condition indicates one or more of the following: Inoperable edge connections at the first switch; and The unavailability of routes to the client's device indicates the client's migration.

17. The non-transitory computer-readable storage medium of claim 10, wherein the triggering condition indicates the start of a timer, and the timer indicates the duration of the event.

18. The non-transitory computer-readable storage medium of claim 10, wherein the method further comprises configuring the high cost in routing information associated with the underlying network; The high cost mentioned in the announcement includes sending link-state announcements using a local instance of the routing procedure.

19. A computer system comprising: processor; Memory devices; A gateway logic block is used to participate in a virtual computer system in conjunction with a second computer system, wherein the virtual computer system is to operate as a gateway for an overlay tunnel structure, the overlay tunnel structure including the computer system and the second computer system, wherein a path between corresponding pairs of computer systems in the underlying network of the overlay tunnel structure is determined based on a routing process, wherein the computer system and the second computer system each participate in the routing process, and wherein packets for tunnels to the virtual computer system are distributed among the paths to the computer system and the second computer system in the underlying network; A trigger logic block is used to determine the triggering condition of an event, the triggering condition indicating that a packet subsequently received via the tunnel to the virtual computer system will be directed to a path to the second computer system, wherein the computer system and the second computer system remain in an operational state; as well as A cost logic block is used to, in response to determining the triggering condition, announce the high cost of the link to the computer system for the routing process in the underlying network, thereby bypassing the distribution of packets to the computer system in the path to the computer system and the second computer system.

20. The computer system of claim 19, further comprising a reset logic block for determining whether the event has been completed; and The cost logic block is further configured to: advertise the default cost of the link to the computer system for the routing process in the underlying network, thereby resetting the distribution of packets to the virtual computer system in the path to the computer system and the second computer system.

Images