LOOP DETECTION IN A COMPLEX TOPOLOGY WITH MULTIPLE DISTRIBUTED TUNNEL FABRICS

Abstract

A device (600) comprising: a packet processor (610); a detection logic block (630) with an indicator logic block (632) and a loop logic block (636);wherein the indicator logic block (632) is configured to insert a predetermined value at the device into an output tunnel header of a first packet of a data flow, wherein a destination address of the output tunnel header corresponds to a remote device of a first overlay tunnel fabric containing the device, and wherein the predetermined value is unique for the device in a loop detection domain comprising at least the first overlay tunnel fabric and a second overlay tunnel fabric, and wherein the tunnel encapsulation for each overlay tunnel fabric is initiated and terminated within the overlay tunnel fabric, and wherein the indicator logic block (632) is further configured to receive a second packet of the data flow from the second overlay tunnel fabric via the remote device, wherein the second packet is in an input tunnel header with a destination address corresponding to the device is encapsulated;and for the second packet to determine whether the predetermined value is present in the input tunnel header, and wherein the loop logic block (636) is configured to determine, in response to the identification of the predetermined value in the input tunnel header, that a loop is present in the loop detection domain, wherein the device (600) is characterized in that the indicator logic block (632) is further configured to insert the predetermined value into different fields of the output tunnel header of the first packet of the data flow or into different output tunnel headers of the first packet of the data flow.

Description

BACKGROUND Area The present disclosure relates to communication networks. More precisely, the present disclosure relates to a method and a system for facilitating loop detection in a complex topology with multiple distributed tunnel fabrics. Examples of systems and methods for detecting a tunnel loop are disclosed in document US 2009 / 0238080 A1. BRIEF DESCRIPTION OF THE FIGURES Fig. 1 shows an example of loop detection in a complex network topology with multiple distributed tunnel fabrics according to one aspect of the present application. Fig. 2 shows an example of distributed communication for loop detection in a complex network topology with multiple distributed tunnel fabrics according to one aspect of the present application. Fig. 3A shows an example of including a loop indicator in a tunnel header using an additional Next-Protocol header according to one aspect of the present application. Fig. 3B shows an example of including a loop indicator in a tunnel header using an additional protocol header according to one aspect of the present application. Fig. 3C shows an example of including a loop indicator in a tunnel header using a set of reserved flag bits according to one aspect of the present application.Figure 3D shows an example of including a loop indicator in a tunnel header using a reserved field, according to one aspect of the present application. Figure 4A shows a flowchart illustrating the process of a switch with a loop indicator in a tunnel header according to one aspect of the present application. Figure 4B shows a flowchart illustrating the process of a switch detecting a loop based on a loop indicator in a tunnel header, according to one aspect of the present application. Figure 5A shows a flowchart illustrating the process of a participating switch of a virtual gateway switch (VGS) integrating a loop indicator associated with the local fabric into a tunnel header, according to one aspect of the present application.Figure 5B shows a flowchart illustrating the process of a participating switch of a VGS that integrates a loop indicator associated with a remote fabric in a tunnel header, in accordance with one aspect of the present application. Figure 6 shows an exemplary switch that facilitates loop detection in a complex network topology with multiple distributed tunnel fabrics, in accordance with one aspect of the present application. In the illustrations, identical numbers refer to the same elements of the illustration. DETAILED DESCRIPTION The following description is intended to enable the person skilled in the art to manufacture and apply the technology and is given in connection with a specific application and its requirements. Various modifications of the disclosed examples will be readily apparent to the person 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 present invention. Therefore, the present invention is not limited to the aspects shown but has the broadest scope of application compatible with the claims. The internet is the transmission medium for a multitude of applications running on physical and virtual devices. Such applications have led to an increasing demand for data traffic. Consequently, device manufacturers are striving to develop switches with versatile functionality. To this end, a switch can support various protocols and services. For example, the switch can support tunneling and virtual private networks (VPNs). The switch can then facilitate overlay routing for a VPN across the tunnels. For instance, an Ethernet VPN (EVPN) can be deployed as an overlay across a set of virtual extensible local area networks (VXLANs).To establish a VPN over the tunnels, a corresponding tunnel endpoint can map a corresponding virtual local area network (VLAN) to a corresponding tunnel network identifier (TNI), which can identify a virtual network for a tunnel. The TNI can appear in a tunnel header, which encapsulates a packet and is used to forward the encapsulated packet over a tunnel. For example, if the tunnel is based on VXLAN, the TNI can be a virtual network identifier (VNI) of a VXLAN header, and a tunnel endpoint can be a VXLAN tunnel endpoint (VTEP). A TNI can also be mapped to the virtual routing and forwarding (VRF) associated with the tunnels if Layer 3 routing and forwarding is required. Because a VPN can be distributed across the fabric, a VPN over the tunnel fabric can also be referred to as a distributed tunnel fabric. A gateway of the fabric can be a virtual gateway switch (VGS) shared by multiple participating switches. Since a tunnel in the fabric is a Layer 2 overlay on an underlying Layer 3 network (e.g., a VXLAN network), the TNI can be used to overlay the tunnel fabric.While an Internet Protocol (IP) network can enable loop detection, it can be an essential feature for the overlying Layer 2 network. One aspect of the present technology can provide a loop detection device in a loop detection domain comprising a plurality of overlay tunnel fabrics. The device can include an indicator logic block that can insert a predetermined value, which may be unique to the device in the loop detection domain, into an output tunnel header of a packet in a data flow. The destination address of the output tunnel header can correspond to a remote device within an overlay tunnel fabric containing the device. Tunnel encapsulation for a corresponding overlay tunnel fabric can be initiated and terminated within the overlay tunnel fabric itself. The indicator logic block can determine, for each packet in the data flow from a remote overlay tunnel fabric of the loop detection domain, whether the predetermined value is present in an input tunnel header for the received packet.After identifying the predetermined value in the input tunnel header line, a loop logic block of the device can determine that a loop exists in the loop detection domain. In one variation of this aspect, the indicator logic block can determine whether the predetermined value is present in the inbound tunnel header by applying a packet check rule to the data flow packet in the device's forwarding hardware. In another variant, the device's forwarding hardware includes a ternary content-addressable memory (TCAM). An entry in the TCAM can contain the packet inspection rule. In one variation of this aspect, the remote device can be a gateway of the overlay tunnel fabric. The gateway can maintain an inter-fabric tunnel with a second gateway of the remote overlay tunnel fabric. The inter-fabric tunnel can span a routed network. In one variation of this aspect, the loop logic block can detect the presence of the loop in the loop detection domain by forwarding the received packet to a control plane of the device. In one variation of this aspect, the device can include a detection logic block that can apply the packet inspection rule to a plurality of data flows. The loop logic block can then determine the presence of the loop in the loop detection domain if the predetermined value is identified in a received packet of at least one data flow. In one variation of this aspect, the indicator logic block can insert the predetermined value at a predetermined position in the output tunnel header. The predetermined position can be determined based on a tunnel protocol associated with the output tunnel header. In another variant, the predetermined position can correspond to one or more of the following elements: a field of the exit tunnel header and an additional header supported by the exit tunnel header. One aspect of the present technology can provide a loop detection device in a loop detection domain comprising a plurality of overlay tunnel fabrics. The device can include an encapsulation logic block that can determine whether a predetermined value is present in an input tunnel header encapsulating a packet of a data flow. The source address of the input tunnel header can correspond to a remote device of an overlay tunnel fabric containing the device. The predetermined value can be unique to the remote device in the loop detection domain. Tunnel encapsulation for a corresponding overlay tunnel fabric is initiated and terminated within the overlay tunnel fabric. When the presence of the predetermined value is detected, the encapsulation logic block can retrieve the predetermined value before decapsulating the input tunnel header. An indicator logic block of the device can then insert the predetermined value into an output tunnel header, encapsulating the packet. The destination address of the output tunnel header can correspond to a remote overlay tunnel fabric in the loop detection domain. In one variation of this aspect, the encapsulation logic block can determine whether the predetermined value is present in the input tunnel header by applying a forwarding rule in the device's forwarding hardware. The forwarding rule can specify that the predetermined value should be transferred from the input tunnel header to the output tunnel header. In another variant, the device's forwarding hardware includes a ternary content-addressable memory (TCAM). A TCAM entry can contain the forwarding rule. In one variation of this aspect, the indicator logic block can insert the predetermined value at a predetermined position in the output tunnel header. The predetermined position can be determined based on a tunnel protocol associated with the output tunnel header. The aspects described here solve the problem of efficiently detecting a loop in a complex network that may contain multiple distributed tunnel fabrics by (i) including a unique loop indicator, associated with a switch in a fabric, in a tunnel header; and (ii) detecting the presence of a loop upon seeing the unique indicator in the tunnel header of an incoming packet. The switch can monitor the field of the tunnel header that may contain the unique identifier. Since the fields of the tunnel header of an incoming packet are commonly monitored, the switch can detect a field in the complex network with minimal computational overhead. Typically, a switch pair in a distributed tunnel fabric forwards packets to each other via a tunnel connecting them. Examples of tunnels include VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization with GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), and Internet Protocol Security (IPsec). Forwarding the packet through the tunnel involves encapsulating the packet with a tunnel header containing the source and destination addresses, and forwarding the packet based on the destination address in the tunnel header. A tunnel header can contain additional information in one or more fields. Some tunnel headers also allow the inclusion of additional headers to transmit further information. The fabric can contain a Virtual Grid Service (VGS), which connects the fabric to other networks. Typically, at least two switches can be interconnected to operate as a single switch to enable the VGS. The switches participating in the VGS can be referred to as participating switches. Each participating switch can consider the other participating switches as participating peer switches. One or more virtual addresses (e.g., a virtual IP address and / or a virtual MAC (Media Access Control) address) can be assigned to the VGS. A corresponding tunnel formed at the VGS can use the virtual address to form the tunnel endpoint. Consequently, other tunnel endpoints in the fabric can consider the VGS as the other tunnel endpoint for a tunnel, rather than one of the participating switches. To route traffic to the VGS, a tunnel endpoint in the fabric can perform a load balancing operation (e.g., based on hashing a relevant packet) and select one of the participating switches as the destination (i.e., another tunnel endpoint). The tunnel endpoint can then forward the packet over a tunnel between the tunnel endpoints. Typically, a source for a multicast group might be located outside the fabric, while the client hosts might be connected to the fabric (e.g., reachable via the endpoint switches). The hosts can then reach the rest of the network (e.g., the internet) through the VGS. Under certain circumstances, a network can have a complex topology with multiple fabrics. The Virtual Grid Systems (VGS) of these fabrics can be interconnected via a routed network (e.g., using the Border Gateway Protocol (BGP)). The fabrics can be located in different geographic locations. A corresponding VGS pair can form a tunnel between them to communicate over the routed network. Therefore, the complex network topology can be viewed as a multi-hop overlay network. For example, the VGS can terminate a tunnel connected to the local fabric for a packet and re-encapsulate the packet with another tunnel to forward it over the routed network. Due to the geographical distribution of the complex network, a specific portion of the network may be managed by different administrative units. Furthermore, endpoints (e.g., user devices or hosts) can be mobile due to virtual machine (VM) migration and wireless mobility. Consequently, the workload of clients or tenants can move across fabrics and become unpredictable. Because of the complexity of the topology, the diverse management, and the unpredictable workload, identifying a loop in such a complex network can be challenging. To detect a loop in a network, a switch can inject a synthetic traffic flow into the network. This synthetic traffic can be multi-destination traffic (e.g., broadcast, unknown unicast, or multicast (BUM) traffic) in a virtual local area network (VLAN) or Internet Protocol (IP) traffic. When the switch receives packets of the synthetic flow back, it can forward them to a loop detection process. The loop detection process can then determine if a loop exists. However, if the network operates over multiple paths, such as the fabric or the underlying physical network, the synthetic flow packets might be correctly forwarded to the switch. Consequently, the switch might incorrectly detect a loop. The switch can avoid such a scenario by inspecting a number of data flows returning to it. The switch can sample packets from actual traffic flows and forward copies of the sampled packets to the loop detection process. However, monitoring packets from a large number of flows can require a large number of corresponding rules in the switch's hardware resources (e.g., entries in the ternary content-addressable memory (TCAM)). Since these resources are limited in the switch, such a significant overhead can strain resources. In particular, because the capacity of a TCAM is limited, a large number of filter rules in the TCAM can be inefficient. To resolve this issue, the switch can incorporate a unique loop indicator, associated with the switch, into the tunnel header of a data stream packet. This unique loop indicator can then be used to identify packets within the data stream. The packet can be received by an edge port of the switch. A corresponding edge port can connect an end device (or host) to the switch. Therefore, the packets received by the edge port can be Layer 2 packets, such as Ethernet frames. The switch can include the unique indicator in a field or an additional header associated with the tunnel header. The switch can perform this operation for a predetermined test period whenever loop detection is required.The inclusion of the unique indicator in the header can occur at the data plane without forwarding the packet to the control plane, where additional intervention would be required. Since the packet's destination address can be mapped to a device outside the local fabric, the switch can forward the encapsulated packet to the fabric's VGS (Virtual Gear Switch). The VGS can be configured with a forwarding rule in the forwarding hardware of the participating switches (e.g., in the TCAMs of the participating switches) that instructs the VGS to copy the unique indicator, if present, into an outgoing tunnel header. Accordingly, upon receiving the encapsulated packet, the VGS (i.e., the receiving participating switch) can determine the unique indicator and decapsulate the tunnel header to obtain the packet. If the packet is destined for a device reachable via a remote fabric, the VGS can re-encapsulate the packet with an inter-fabric tunnel header. Based on the rule, the VGS can include the unique indicator in the inter-fabric tunnel header and forward the encapsulated packet to the remote fabric via the routed network.Since the tunneling protocols for intra-fabric and inter-fabric communication can differ, the unique indicator can be placed in different fields or additional headers. The remote VGS can receive the encapsulated packet and obtain the unique identifier. Due to a configuration error, the remote VGS can flood the local fabric (i.e., forward it through a corresponding tunnel within the local fabric). The remote VGS can also forward the packet to another VGS via an inter-fabric tunnel. Based on the rule in the forwarding hardware, the remote VGS can embed the unique identifier in the header of the inter-fabric tunnel. In this way, the packet carrying the unique identifier in the respective tunnel headers can travel across multiple fabrics to return to the originating fabric, thus creating a loop. After receiving the packet, the VGS of the originating fabric can forward the packet back to the originating switch. The forwarding hardware of the originating switch can be configured with a packet inspection rule that instructs the switch to filter for the unique indicator in the tunnel header of the data flow. The rule can also specify that if the unique indicator is identified in the tunnel header, a copy of the packet should be passed to a loop detection process, such as a control plane tool. The rule could, for example, be a match-and-punt filter configured in the switch's TCAM. The filter can match a specific flow (e.g., the packet flow) and forward the packet carrying the unique indicator to the loop detection process. This filtering can simplify the packet inspection process for the switch. In this way, a single rule in the forwarding hardware can facilitate loop detection without burdening the switch's hardware resources. Forwarding a single packet to the loop detection process can be an indication of a loop. However, the loop detection process can determine the presence of the loop after receiving a certain number of forwarded packets. The switch can remove the rule from the forwarding hardware if a loop is detected or the test period has expired. For example, the switch can remove the entry containing the rule from the switch's TCAM. The switch can embed the unique indicator in packets of a corresponding data flow originating from an endpoint and available to the edge port for the duration of the test. This allows the loop detection process to identify the specific data flow that caused the loop. Consequently, the switch can use the same unique indicator for multiple flows without requiring separate rules for each flow. Therefore, the forwarding hardware does not need flow matching rules (e.g., matching source and destination identifiers and ports) for each individual flow to detect a loop. After detecting a loop, the loop detection process can facilitate loop protection by disabling a tunnel to prevent the loop from occurring within a fabric. The loop detection process can also facilitate loop isolation by identifying which devices are causing the loop. If multiple switches in the complex network, which may belong to different fabrics, perform the loop detection process simultaneously, using the same indicator can lead to false positives. Therefore, each switch in the complex network should use an indicator unique to that switch. In other words, indicators must not be duplicated across the entire complex network. Consequently, the indicator used by a specific switch in a specific network should be unique. To avoid assigning a unique indicator to every switch, a unique value associated with the switch can be used as the unique indicator. Examples of such a unique value include a MAC (Media Access Control) address, an administrative or administrator IP address assigned to the switch, and a hardware tag (e.g., the serial number of the chassis). In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or fabric switch operating at any network layer. The term "switch" is not to be understood as limiting the examples of the present invention to Layer 2 networks. Any device capable of forwarding traffic to an external device or another switch can be called a "switch." Any physical or virtual device (e.g., a virtual machine or a switch operating on a computer) capable of forwarding traffic to an end device can be called a "switch." Examples of a "switch" include, but are not limited to, a Layer 2 switch, a Layer 3 router, a routing switch, a component of a Gen Z network, or a fabric switch comprising a plurality of similar or heterogeneous smaller physical and / or virtual switches. The term "packet" refers to a group of bits that can be transported together over a network. The term "packet" is not to be understood as limiting examples of the present invention to Layer 3 networks. The term "packet" can be replaced by other terms that refer to a group of bits, such as "message," "frame," "cell," "datagram," or "transaction." Furthermore, the term "port" can refer to the port that can receive or send data. The term "port" can also refer to the hardware, software, and / or firmware logic that can facilitate the operation of that port. Figure 1 shows an example of loop detection in a complex network topology with multiple distributed tunnel fabrics according to one aspect of the present application. A network 100 can comprise a number of switches and devices. In some examples, the network 100 can be based on one or more of the following networks: Ethernet, InfiniBand, or other networks. Accordingly, the network 100 can use a suitable communication protocol, e.g., the Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. The network 100 can have a complex network topology with a plurality of tunnel fabrics 110, 120, 130, and 140. These fabrics can be interconnected via a routed network 150 (e.g., a BGP network). Therefore, the network 100 can be referred to as a complex network. A corresponding connection in each of fabrics 110, 120, 130, and 140 can be a tunnel. The switches in each fabric can form a network of tunnels. Examples of tunnels include VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization with GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), and Internet Protocol Security (IPsec). A VPN 119, such as an EVPN, can be used over fabric 110. Similarly, a VPN can also be used over each of fabrics 120, 130, and 140. In Figure 1, fabric 110 can be connected to network 150 via VGS 111 from fabric 110. Switches 112 and 113 of fabric 110 can operate together as a single switch to enable VGS 111. VGS 111 can be connected to one or more virtual addresses (e.g., a virtual IP address and / or a virtual MAC address).A corresponding tunnel formed at VGS 111 can use the virtual address to form the tunnel endpoint. Consequently, other tunnel endpoints, such as switches 114, 115, and 116 of Fabric 110, can consider VGS 111 as the other tunnel endpoint for a tunnel instead of switches 112 and 113. To route traffic toward VGS 111, a switch in Fabric 110, such as switch 115, can perform a load balancing operation and select one of switches 112 and 113 as the destination (i.e., the other tunnel endpoint). Similarly, Fabric 120 can include VGS 121 and switches 122 and 123; Fabric 130 can include VGS 131 and switches 132, 133, and 134; and Fabric 140 can include VGS 141 and switches 142 and 143. An endpoint 117, e.g., a client device or a host, can be connected to switch 115. Endpoints 118, 124, and 135 can be connected to switches 115, 122, and 133, respectively. Endpoints 144 and 145 can be connected to switch 142.An end device can be a VM, a physical device, or a physical device on which a VM is running (e.g., on an operating system). In network 100, the fabrics can be located in different geographic locations. A corresponding VGS pair, e.g., VGS 111 and 121, can form a tunnel between them to communicate via network 150. Accordingly, a packet from device 118 to device 124 can be sequentially routed through corresponding tunnels in Fabric 110, Network 150, and Fabric 120. For example, VGS 111 can terminate a tunnel in Fabric 110 for the packet and re-encapsulate the packet with another tunnel to route it through Network 150. Therefore, Network 100 can be considered a multi-hop overlay network. Due to the geographical distribution of Network 100, a corresponding Fabric of Network 100 can be managed by different administrative units. Furthermore, endpoints, such as devices 117 and 124, can be mobile due to VM migration and wireless mobility. Consequently, the client or tenant workload in Network 100 can move across fabrics and become unpredictable. Due to the complexity of the network 100 topology, the different management of the fabrics, and the unpredictable workload, loop detection in network 100 can be challenging. To detect a loop in network 100, a switch, e.g., switch 115, can inject a synthetic traffic flow into network 100. This synthetic traffic can be multi-destination traffic (e.g., BUM traffic in a VLAN or IP traffic). When switch 115 receives packets of the synthetic traffic flow, it can forward them to a loop detection process. The loop detection process can then determine the presence of a loop. However, the underlying physical network of fabric 110 can operate with multiple paths. Therefore, the packets of the synthetic flow can be correctly forwarded to switch 115.Consequently, the switch 115 may incorrectly detect a loop. To avoid such a scenario, Switch 115 might need to examine a large number of data flows returning to it. Switch 115 can sample packets from actual traffic flows and forward copies of the sampled packets to the loop detection process. Since Network 100 may comprise several fabrics, each employing multi-path routing in its underlying networks, detecting such a loop could require sampling a large number of flows. However, monitoring packets from a large number of flows could require a large number of corresponding rules in the hardware resources (e.g., TCAM entries) of Switch 115. Because these resources are limited in Switch 115, such a significant overhead could strain its resources. To solve this problem, switch 115 can embed a loop indicator 170, uniquely associated with switch 115, in a tunnel header of a data flow packet. Therefore, the loop indicator 170 can also be referred to as a unique loop indicator 170 or unique indicator 170. The unique indicator 170 can tag packets of the data flow and can therefore also be called a flow tag. During operation, switch 115 can receive a packet 152 from end device 118 via an edge port of switch 115. The packet 152 may be destined for the outside of network 110. Switch 115 can encapsulate the packet 152 with a tunnel header to create an encapsulated packet 154. The tunnel header allows the forwarding of packet 154 through the appropriate tunnel. The source address of the tunnel header can be an identifier, such as an IP address, of switch 115. Since the destination address of packet 152 may correspond to a device not connected to network 110, the destination address of the tunnel header may be an identifier of VGS 111. Examples of tunnel headers include a VXLAN header, a Generic Protocol Extension for VXLAN (VXLAN-GPE) header, a VXLAN-Geneve header, a VXLAN Group Policy Option (VXLAN-GPO) header, an IPSec header, and a GRE header. If the tunnel header contains a VXLAN or VXLAN-GPO header, switch 115 may include the unique identifier 170 in a field of the tunnel header. However, if the tunnel header contains a VXLAN-GPE or VXLAN-Geneve header, switch 115 may include the unique identifier 170 in an additional header associated with the tunnel header. Switch 115 can continue to add the unique indicator 170 to the packets belonging to the flow of packet 152 for a predetermined test period if loop detection is required at switch 115. An administrator can configure the test period and trigger the loop detection operation at switch 115. Because switch 115 can embed the unique indicator 170 in a data plane packet (i.e., in the actual data flow received by device 118), switch 118 can perform loop detection without forwarding packet 154 to the control plane for additional intervention. Switch 115 can then forward the encapsulated packet 154 to VGS 111. Switches 112 and 113 of VGS 111 can be configured with a forwarding rule in the forwarding hardware (e.g., in the corresponding entries of the TCAMs of switches 112 and 113). The forwarding rule can instruct VGS 111 (i.e., switches 112 and 113) to copy the unique indicator 170, if present, from an incoming tunnel header to an outgoing tunnel header. Accordingly, upon receiving the encapsulated packet 154, VGS 111 can obtain the unique indicator 110 from the tunnel header of the receiving participating switch. VGS 111 can then decapsulate the tunnel header to receive packet 152. If packet 152 is destined for a device reachable via Fabric 140, VGS 111 can re-encapsulate packet 152 with an Inter-Fabric Tunnel header to create an Inter-Fabric packet 156.Based on the rule, VGS 111 can include a unique indicator 170 in the Inter-Fabric-Tunnel header and forward the packet 156 to Fabric 140 via network 150. Since the tunnel protocols for communication within and between fabrics can differ, the unique identifier 170 can be placed in different fields or additional headers in packets 154 and 156. VGS 141 can receive packet 156 and retrieve the unique identifier 170 from the tunnel header. VGS 141 can then decapsulate the tunnel header to obtain packet 152. Due to a configuration error, VGS 141 can flood fabric 140 by encapsulating packet 152 and forwarding it through the appropriate tunnels in fabric 140. VGS 141 can also encapsulate packet 152 with an inter-fabric tunnel header to create an inter-fabric packet 158. Based on the rule in the forwarding hardware of the participating switches of VGS 141 from Fabric 140, VGS 141 can include a unique indicator 170 in the Inter-Fabric-Tunnel header.VGS 141 can then forward packet 158 ​​to VGS 131 via the corresponding inter-fabric tunnel to Fabric 130. VGS 131 can retrieve the unique identifier 170 from the tunnel header of packet 158 ​​and decapsulate the tunnel header to obtain packet 152. If VGS 131 is also misconfigured, it can encapsulate packet 152 with an inter-fabric tunnel header to create an inter-fabric packet 160. Based on the rule in the forwarding hardware of the participating switches of VGS 131 from Fabric 130, VGS 131 can include a unique identifier 170 in the inter-fabric tunnel header. VGS 111 can then forward packet 160 back to VGS 111 via the corresponding inter-fabric tunnel to Fabric 110, thus creating a loop. VGS 111 can then receive packet 152 from packet 160 and encapsulate packet 152 with an encapsulation header to create an encapsulated packet 162. VGS 111 can then insert a unique indicator 170 into the encapsulation header and forward packet 162 back to the originating switch 115. The forwarding hardware of switch 115 can be configured with a rule that instructs switch 115 to filter for the unique indicator 170 in the tunnel header of packet 152. This rule can be a packet inspection rule in a TCAM entry of switch 115. The rule can also instruct that if the unique indicator 170 is identified in the tunnel header, a copy of packet 162 should be forwarded to a loop detection process 180, such as a control plane loop detection tool. Based on the unique indicator 170 in the tunnel header of packet 162, the loop detection process 180 can determine the presence of a loop and notify an administrator of the loop. In this way, a single rule in the forwarding hardware of switch 115 can facilitate the loop detection process without burdening the hardware resources of switch 115. Forwarding a single packet, for example, packet 162, to the loop detection process 180 may be sufficient to indicate a loop in network 100. However, loop detection process 180 can determine the presence of the loop when it receives a threshold number of forwarded packets from the forwarding hardware of switch 115. Switch 115 can remove the rule from the forwarding hardware when a loop is detected or the test period expires. Switch 115 can contain a unique indicator 170 for a specific flow originating from terminal device 118 for the test period. This allows the loop detection process 180 to identify a single flow that caused the loop. Consequently, switch 115 can use the same unique indicator 170 for multiple flows without requiring individual rules for each flow. Therefore, to detect a loop, the forwarding hardware of switch 115 does not need rules for mapping data flows (e.g., mapping source and destination identifiers and ports) for each data flow. After detecting a loop, the loop detection process 180 can facilitate loop protection by disabling a tunnel to prevent the loop from occurring within fabric 110.The loop detection process 180 can also facilitate loop isolation by identifying which devices are causing the loop. If multiple switches, such as switches 115 and 143 of network 100, belonging to different fabrics 110 and 140 respectively, simultaneously execute an instance of the loop detection process 180, using the same indicator can lead to false positives. Therefore, each switch in network 100 can use a loop indicator that is unique to that specific switch. In other words, loop indicator 170 must not be repeated in network 100, not even for a switch in a different fabric, such as fabric 120, 130, or 140. Consequently, loop indicator 170 assigned to switch 115 should be distinguishable from loop indicator 172 assigned to switch 143. To avoid manually assigning the unique indicators 170 and 172 to switches 115 and 143 respectively, a unique value assigned to a switch can be used as the unique indicator.The unique value can be a MAC address, an administrative or administrator IP address assigned to the switch, or a hardware tag. For example, the unique identifiers 170 and 172 could be the administrator IP addresses assigned to switches 115 and 143, respectively. Figure 2 shows an example of distributed communication for loop detection in a complex network topology with multiple distributed tunnel fabrics, according to one aspect of the present application. During operation, the terminal device 118 can send a packet to the switch 115 via an edge port (Operation 202). The packet may be destined for a device reachable via a remote fabric. Upon receiving the packet, the switch 115 can encapsulate the packet and insert the unique identifier 170 into the tunnel header of the packet (Operation 204). The switch 115 can then send the encapsulated packet to VGS 111 (Operation 206). VGS 111 can receive the unique identifier 170 and decapsulate the tunnel header (Operation 208). Based on the packet's destination, VGS 111 can determine that the packet should be sent to a remote fabric. VGS 111 can then encapsulate the packet with an inter-fabric header and include the unique identifier 170 in the inter-fabric header, based on a rule configured in the forwarding hardware of each participating switch of VGS 111 (Operation 210). Subsequently, VGS 111 can send the encapsulated inter-fabric packet to VGS 141, which is the gateway for Remote Fabric 140, as described in conjunction with Fig. 1 (Operation 212). If VGS 141 is configured with errors, VGS 141 can forward an encapsulated inter-fabric packet with the unique identifier 170 to VGS 131 (Operation 214). If VGS 131 is configured with errors, VGS 131 can forward an encapsulated inter-fabric packet carrying the unique indicator 170 back to VGS 111 (Operation 216), creating a loop in network 100. VGS 111 can receive the unique identifier 170 and decapsulate the inter-fabric header (Operation 218). VGS 111 can then encapsulate the packet with a tunnel header and include the unique identifier 170 in the tunnel header (Operation 220). Subsequently, VGS 111 can send the encapsulated packet back to the originating switch 115 (Operation 222). Switch 115 can detect the unique identifier 170 and forward the packet to the loop detection process 180 (Operation 224). Loop detection process 180 can determine that a packet with the unique identifier 170 has returned to switch 115 and detect the presence of a loop in network 100 (Operation 226). The forwarding hardware of switch 115 can contain a rule for determining the presence of the unique indicator in an incoming encapsulated packet and forwarding the encapsulated packet to loop detection process 180. This rule could, for example, be a match-and-punt filter configured in TCAM. The filter can match a specific flow (e.g., the flow of packets received at switch 115) and forward (e.g., move forward) the packet carrying the unique indicator to loop detection process 180. It should be noted that the filter can also match multiple flows received at switch 115 (e.g., all flows received at an edge port). Therefore, a single filter may be sufficient to facilitate forwarding to loop detection process 180 without burdening the hardware resources of switch 115. Figure 3A shows an example of including a loop indicator in a tunnel header using an additional Next Protocol header according to one aspect of the present application. A VXLAN header 300, which may be a VXLAN-GPE header, may contain a set of flags 302, a reserved field 304, a Next Protocol field 306, a VNI field 308, and a reserved field 310. The VXLAN-GPE header 300 may allow a user-defined header to be transmitted as an additional header. The Next Protocol field 306 identifies the next header transmitted by the VXLAN-GPE header 300. The VXLAN-GPE standard (e.g., the Internet Engineering Task Force (IETF) Draft for VXLAN-GPE) specifies a set of values ​​for the Next Protocol field 306. For example, a hexadecimal value of 1, 2 or 3 in the next protocol field 306 can indicate an additional IP version 4, IP version 6 or Ethernet header, respectively. Furthermore, the value range also includes a number of unallocated areas. A value from the unallocated area can be used to indicate the presence of an additional Loop Indicator header 312. This value can be predefined (e.g., defined and configured by an administrator) and persist throughout the complex network, such as network 100 in Figure 1. A unique Loop Indicator 314 can be carried by Loop Indicator header 312. Loop Indicator header 312 can conform to the requirements of the VXLAN-GPE format. Thus, if the exit tunnel for a switch is based on VXLAN-GPE, the switch can include the unique indicator 314 in Loop Indicator header 312 and the predefined value in the next protocol field 306 of the VXLAN-GPE header 300. Figure 3B shows an example of including a loop indicator in a tunnel header using an additional protocol type header according to one aspect of the present application. A VXLAN header 320, which may be a VXLAN Geneva header, may contain a set of flags 322, a reserved field 324, a protocol type field 326, a VNI field 328, and a reserved field 320. The VXLAN Geneva header 320 may also support variable-length operations 332. The VXLAN Geneva header 320 may also allow the transmission of a user-defined header as an additional header. The protocol type field 326 may identify the next header transmitted by the VXLAN Geneva header 320. The VXLAN-Geneve standard (e.g., the IETF Request for Comment (RFC) for VXLAN-Geneve) specifies the protocol types and their corresponding values. Such a value can be included in the protocol type field 326. One of the unused values ​​for protocol type field 326 can be used to indicate the presence of an additional loop indicator header 334. This value can persist across the entire complex network. A unique loop indicator 336 can be carried by loop indicator header 334. Loop indicator header 334 can be adapted to the requirements of the VXLAN Geneva format. Thus, if the output tunnel for a switch is based on VXLAN Geneva, the switch can include the unique indicator 336 in loop indicator header 334 and the predefined value in protocol type field 326 of VXLAN Geneva header 320. Figure 3C shows an example of including a loop indicator in a tunnel header using a set of reserved flag bits, according to one aspect of the present application. A VXLAN header 340, which may be a VXLAN GPO header, may contain a set of flags 342, a Group Policy Identifier field 344, a VNI field 346, and a reserved field 348. Because the VXLAN GPO header 340 may not support an additional header, one of the fields of the VXLAN GPO header 340 may contain a unique loop indicator 350. For example, the VXLAN GPO header 340 may contain a unique indicator 350 in a set of reserved bits in flags 342 (indicated by bold lines). Due to the limited number of bits available for transmitting such an indicator, the number of unique loop indicators in a complex network may be limited. In this example, four reserved bits can support sixteen unique indicators. Therefore, the loop detection process can be performed simultaneously on sixteen different switches in the complex network. Unique indicator 350 can share the bit space with the Group Policy identifier field 344 and the VNI field 346. Therefore, a corresponding switch in the complex network can know the bit sharing and the number of bits allocated to unique indicator 350. In this way, standard VXLAN GPO policies and loop detection functions do not overlap. Figure 3D shows an example of including a loop indicator in a tunnel header using a reserved field, in accordance with an aspect of the present application. A VXLAN header 360, which may be a standard VXLAN header, may contain a set of flags 362, a reserved field 364, a VNI field 366, and a reserved field 368. Since the VXLAN header 360 may not support an additional header, one of the fields of the VXLAN header 360 may contain a unique loop indicator 350. For example, the VXLAN GPO header 340 may contain a unique indicator 370 in at least part of the reserved field 364. Since the reserved field 364 may have a large number of bits, the unique indicator 370 may support a large number of unique indicators. Figure 4A shows a flowchart illustrating the process of a switch enclosing a loop indicator in a tunnel header, in accordance with one aspect of the present application. During operation, the switch can receive a packet destined for the outside of the network via an edge port (Operation 402) and encapsulate the packet with a tunnel header (Operation 404). The switch can then determine whether the packet flow is selected for the detection process (Operation 406). If the flow is selected, the switch can also determine whether the test period has expired (Operation 408). If the flow is selected (Operation 406) and the test period has not yet expired (Operation 408), the switch can select the unique indicator associated with the local switch (Operation 412) and insert the unique indicator into the tunnel header (Operation 414). If the flow is not selected (Operation 406), the test period has expired (Operation 408), or the switch has already integrated the unique indicator into the tunnel header (Operation 414), the switch can forward the encapsulated packet to the local network's VGS (Operation 410). Figure 4B shows a flowchart illustrating the process of loop detection by a switch based on a loop indicator in a tunnel header, according to one aspect of the present application. During operation, the switch can receive an encapsulated packet from the local network's VGS (Operation 452) and determine if the indicator is present in the encapsulated packet (Operation 454). If the indicator is present in the encapsulated packet, the switch can retrieve the unique indicator from the tunnel header (Operation 456) and determine if the unique indicator is associated with the local switch (Operation 458). If the unique indicator is associated with the local switch, the switch can forward the encapsulated packet to the local instance of the loop detection process (Operation 460). If, on the other hand, the indicator is not present in the encapsulated packet (Operation 454) or the unique indicator is not associated with the local switch (Operation 458), the switch can decapsulate the tunnel header to obtain the inner packet (Operation 462). The switch can then determine the local destination devices based on the destination address of the inner packet (Operation 464). For example, if the destination address is a multicast address, the local destination devices can be the receivers (or clients) of the multicast group associated with that multicast address. The switch can then forward the inner packet to the local destination devices (Operation 466). Figure 5A shows a flowchart illustrating the process of a participating switch of a VGS inserting a loop indicator associated with the local fabric into a tunnel header, in accordance with one aspect of the present application. During operation, the switch may receive an encapsulated packet from a remote endpoint of the local network (Operation 502) and determine whether the unique indicator is present in the packet (Operation 504). If the indicator is present in the encapsulated packet, the switch may retrieve the unique indicator from the tunnel header (Operation 506). If the indicator is not present in the encapsulated packet (Operation 504), or after retrieving the unique indicator (Operation 506), the switch may decapsulate the tunnel header to obtain the inner packet (Operation 508). The switch can then determine a remote VGS corresponding to the destination address of the inner packet (Operation 510) and encapsulate the inner packet with an inter-fabric tunnel header for forwarding to the remote VGS (Operation 512). The switch can determine if the local switch has received the indicator (Operation 514). If the indicator has been received, the switch can include the unique indicator in the inter-fabric tunnel header (Operation 516). If the indicator is not received (Operation 514) or after the unique indicator has been inserted (Operation 516), the switch can forward the encapsulated packet to the remote VGS (Operation 518). Figure 5B shows a flowchart illustrating the process of a participating switch of a VGS inserting a loop indicator associated with a remote fabric into a tunnel header, in accordance with one aspect of the present application. During operation, the switch can receive a packet from the remote VGS of a remote fabric (Operation 552) and determine whether the unique indicator is present in the packet (Operation 554). If the indicator is present in the encapsulated packet, the switch can retrieve the unique indicator from the tunnel header (Operation 556). If the indicator is not present in the encapsulated packet (Operation 554), or after retrieving the unique indicator (Operation 556), the switch can decapsulate the tunnel header to obtain the inner packet (Operation 558). The switch can then determine whether the inner packet should be forwarded within the local fabric (Operation 560). If the inner packet is to be forwarded within the local fabric, the switch can determine the remote endpoints that correspond to the destination address of the inner packet (Operation 562). If the inner packet is not to be forwarded within the local fabric (Operation 560), or after determining the remote endpoints (Operation 562), the switch can also determine whether the inner packet should be forwarded to a remote fabric (Operation 564). If the inner packet is to be forwarded to a remote fabric, the switch can determine the remote VGS that corresponds to the destination address of the inner packet (Operation 566). If the inner packet is not to be forwarded to a remote fabric (Operation 564) or after determining the remote VGS (Operation 566), the switch can encapsulate copies of the inner packet with appropriate headers for forwarding to the specified remote destinations (Operation 568). For the remote endpoints, the headers can be, for example, tunnel headers. On the other hand, the header for the remote VGS can be an inter-fabric header. The switch can determine whether the local switch has received the indicator (Operation 570). If the indicator has been received, the switch can insert the unique indicator into an appropriate header (Operation 572). If the indicator is not received (Operation 570) or after inserting the unique indicator (Operation 572), the switch can forward the encapsulated packets to the appropriate remote destinations (Operation 574). Figure 6 shows an exemplary switch that facilitates loop detection in a complex network topology with multiple distributed tunnel fabrics, according to one aspect of the present application. In this example, a switch 600 comprises a number of communication ports 602, a packet processor 610, and a storage device 650. The switch 600 may also include switch hardware 660 (e.g., processing hardware of the switch 600, such as its application-specific integrated circuit chips (ASIC chips)) that contains information on the basis of which the switch 600 processes packets (e.g., determines output ports for packets). The packet processor 610 extracts and processes header information from the received packets. The packet processor 610 can identify a switch identifier (e.g., a MAC address and / or an IP address) that is assigned to the switch 600 in the header of a packet. The 602 communication ports can provide communication channels between switches for communication with other switches and / or user devices. These communication channels can be implemented via a standard communication port and can be based on any open or proprietary format. The 602 communication ports can include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. The 602 communication ports can also include one or more IP ports capable of receiving IP packets. An IP port can receive an IP packet and can be configured with an IP address. The 610 packet processor can process Ethernet frames and / or IP packets. A corresponding 602 communication port can function as an input port and / or an output port. The switch 600 can host a database 652 (e.g., in the storage device 650). The database 652 can be a relational database and can run on one or more DBMS instances. The database 652 can store information associated with a specific multicast group, tunnel, EVPN, unique indicator information, and interfaces assigned to the switch 600. The switch 600 can contain a VGS logic block 642. The VGS logic block 642 can enable the switch 600 to operate as a VGS, such as VGS 111, in a tunnel fabric. For this purpose, the VGS logic block 642 can operate in conjunction with another switch. The switch 600 can also contain a detector logic block 644, which can facilitate a loop detection process (e.g., a control plane tool) for the switch 600. Consequently, the detector logic block 644 can operate in a control plane of the switch 600. The switch 600 can contain a detection logic block 630, which can include an indicator logic block 632, an encapsulation logic block 634, and a loop logic block 636. The detection logic block 630 can determine a test period for loop detection in a complex network. The indicator logic block 632 can determine a unique indicator associated with the switch 600. The indicator logic block 632 can also insert the unique indicator into an encapsulation header (e.g., a tunnel header or an inter-fabric header) of a packet. The encapsulation logic block 634 can obtain a unique indicator from an input encapsulation header and insert the unique indicator into an output encapsulation header. Loop logic block 636 can pass a copy of an encapsulated packet to the loop detection process if a unique indicator associated with switch 600 is identified in the encapsulated packet. 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 floppy disks, magnetic tapes, CDs (Compact Discs), DVDs (Digital Versatile Discs or Digital Video Discs), or other media capable of storing computer-readable media known today or developed in the future. The procedures and processes described in the "Detailed Description" section can be embodied as code and / or data, which can be stored on 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 procedures and processes that are embodied as data structures and code and stored on the computer-readable storage medium. The procedures and processes described here can be executed by and / or contained within hardware modules or devices. These modules or devices may include, but are not limited to, an application-specific integrated circuit (ASIC chip), a field-programmable gate array (FPGA), a dedicated or shared processor that executes a specific software module or piece of code at a specific time, and / or other programmable logic devices known today or developed later. When the hardware modules or devices are activated, they execute the procedures and processes contained within them.

Claims

A device (600) comprising: a packet processor (610); a detection logic block (630) with an indicator logic block (632) and a loop logic block (636);wherein the indicator logic block (632) is configured to insert a predetermined value at the device into an output tunnel header of a first packet of a data flow, wherein a destination address of the output tunnel header corresponds to a remote device of a first overlay tunnel fabric containing the device, and wherein the predetermined value is unique for the device in a loop detection domain comprising at least the first overlay tunnel fabric and a second overlay tunnel fabric, and wherein the tunnel encapsulation for each overlay tunnel fabric is initiated and terminated within the overlay tunnel fabric, and wherein the indicator logic block (632) is further configured to receive a second packet of the data flow from the second overlay tunnel fabric via the remote device, wherein the second packet is in an input tunnel header with a destination address corresponding to the device is encapsulated;and for the second packet to determine whether the predetermined value is present in the input tunnel header, wherein the loop logic block (636) is configured to determine, in response to the identification of the predetermined value in the input tunnel header, that a loop is present in the loop detection domain, wherein the device (600) is characterized in that the indicator logic block (632) is further configured to insert the predetermined value into different fields of the output tunnel header of the first packet of the data flow or into different output tunnel headers of the first packet of the data flow. Device (600) according to claim 1, wherein the indicator logic block (632) determines whether the predetermined value is present in the input tunnel header by applying a packet check rule for the data flow to the second packet at the forwarding hardware of the device. Device (600) according to claim 2, wherein the forwarding hardware of the device includes a ternary content-addressable memory, TCAM; and wherein an entry of the TCAM comprises the packet inspection rule. Device (600) according to claim 1, wherein the remote device is a gateway of the first overlay tunnel fabric which maintains an inter-fabric tunnel with a second gateway of the second overlay tunnel fabric; and wherein the inter-fabric tunnel spans a routed network. Device (600) according to claim 1, wherein the loop logic block (626) determines the presence of the loop in the loop detection domain by forwarding the second packet to a control level of the device. Device (600) according to claim 2 or 3, wherein the detection logic block (630) is further configured to apply the packet inspection rule to a plurality of data flows; and wherein the loop logic block (636) is further configured to determine the presence of the loop in the loop detection domain in response to the identification of the predetermined value in a received packet from at least one of the plurality of data flows. Device (600) according to claim 1, wherein the indicator logic block (632) is further configured to insert the predetermined value at a predetermined position in the output tunnel header of the first packet, wherein the predetermined position is determined on the basis of a tunnel protocol associated with the output tunnel header. Device (600) according to claim 7, wherein the predetermined location corresponds to one or more of the following elements: a field of the output tunnel header; and an additional header supported by the output tunnel header. A method comprising: - Inserting a predetermined value by a switch into an output tunnel header of a first packet of a data flow, wherein a destination address of the output tunnel header corresponds to a remote switch of a first overlay tunnel fabric containing the switch, and wherein the predetermined value is unique for the switch in a loop detection domain comprising at least the first overlay tunnel fabric and a second overlay tunnel fabric, and wherein tunnel encapsulation is initiated and terminated for each overlay tunnel fabric within the overlay tunnel fabric; - Receiving a second packet of the data flow from the second overlay tunnel fabric via the remote switch, wherein the second packet is encapsulated in an input tunnel header with a destination address corresponding to the switch; - Determining, for the second packet, whether the predetermined value in the An entry tunnel header is present;and – in response to the identification of the predetermined value in the input tunnel header, determining that a loop exists in the loop detection domain; wherein the method is characterized by inserting the predetermined value into different fields of the output tunnel header of the first packet of the data flow or into different output tunnel headers of the first packet of the data flow. The method of claim 9, wherein determining whether the predetermined value is present in the input tunnel header comprises applying a packet check rule for the data flow to the second packet by forwarding hardware of the switch. Method according to claim 10, wherein the forwarding hardware of the switch includes a ternary content-addressable memory, TCAM; and wherein an entry of the TCAM comprises the packet inspection rule. Method according to claim 10, wherein the remote switch is a gateway switch of the first overlay tunnel fabric which maintains an inter-fabric tunnel with a second gateway switch of the second overlay tunnel fabric; and wherein the inter-fabric tunnel spans a routed network. Method according to claim 10, wherein the determination of the presence of the loop in the loop detection domain further comprises forwarding the second packet to a control plane of the switch. The method of claim 10, further comprising: applying the packet inspection rule to a plurality of data flows and determining the presence of the loop in the loop detection domain in response to the identification of the predetermined value in a received packet of at least one of the plurality of data flows. The method of claim 10, further comprising inserting the predetermined value at a predetermined position in the output tunnel header of the first packet, wherein the predetermined position is determined on the basis of a tunnel protocol associated with the output tunnel header. The method of claim 15, wherein the predetermined location corresponds to one or more of the following elements: a field of the output tunnel header and an additional header supported by the output tunnel header. A device (600) comprising: a packet processor (610); a detection logic block (630) with an encapsulation logic block (634) and an indicator logic block (632); wherein the encapsulation logic block (634) is configured to determine in the device whether a predetermined value is present in an input tunnel header encapsulating a packet of a data flow, wherein a source address of the input tunnel header corresponds to a remote device of a first overlay tunnel fabric containing the device, and wherein the predetermined value is unique for the remote device in a loop detection domain comprising at least the first overlay tunnel fabric and a second overlay tunnel fabric, and wherein the tunnel encapsulation for each overlay tunnel fabric is initiated and terminated within the overlay tunnel fabric, and wherein the device (600) is further equipped toin response to the determination of the presence of the predetermined value, to retrieve the predetermined value and to decapsulate the input tunnel header in order to receive the packet, wherein the indicator logic block (632) is configured to insert the predetermined value into an output tunnel header that encapsulates the packet, wherein a destination address of the output tunnel header corresponds to a switch in the second remote overlay tunnel fabric, wherein the device (600) is further characterized in that the indicator logic block (632) is configured to insert the predetermined value into different fields of the output tunnel header of the packet or into different output tunnel headers of the packet. Device (600) according to claim 17, wherein the encapsulation logic block (634) determines whether the predetermined value is present in the input tunnel header by applying a forwarding rule through forwarding hardware of the device to the encapsulated packet, wherein the forwarding rule specifies that the predetermined value is to be carried from the input tunnel header to the output tunnel header. Device (600) according to claim 18, wherein the forwarding hardware of the device includes a ternary content-addressable memory, TCAM; and wherein an entry of the TCAM comprises the forwarding rule. Device (600) according to claim 17, wherein the indicator logic block (632) is further configured to insert the predetermined value at a predetermined position in the output tunnel header, wherein the predetermined position is determined on the basis of a tunnel protocol associated with the output tunnel header.

Images