Layer 3 routing loop prevention system

The present disclosure relates generally to information handling systems, and more particularly to a layer 3 routing loop prevention system for information handling systems.

As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.

Information handling systems such as, for example, switches or routers, are utilized in directing data traffic through networks. In some situations, multiple devices may be used to provide a logical switch that is used to direct data traffic. For example, a plurality of control bridge devices may be coupled to a plurality of port extender devices to provide a logical switch such as, for example, per the Institute of Electrical and Electronics Engineers (IEEE) 802.1BR standard. In some scenarios, links between the control bridge devices and/or port extender devices may be aggregated. In such aggregated link situations, the failure of one or more aggregated links can create issues that result in layer 3 routing loops. For example, a port extender device may be coupled to two control bridge devices via a first Link Aggregation Group (LAG) that includes a first link to a first control bridge device and a second link to the second control bridge device, and the first and second control bridge devices may be coupled together via a second LAG (sometimes referred to as an Inter-Chassis Link (ICL)). When the first link in first LAG to the first control bridge device fails, the first control bridge device may failover to a backup path that results in the first control bridge device forwarding traffic destined for the port extender device over the second LAG to the second control bridge device, and the second control bridge device forwarding that traffic to the port extender device over the second link. Similarly, when the second link in first LAG to the second control bridge device fails, the second control bridge device may failover to a backup path that results in the second control bridge device forwarding traffic destined for the port extender device over the second LAG to the first control bridge device, and the first control bridge device forwarding that traffic to the port extender device over the first link.

However, if both the first link and the second link in the first LAG fail or are otherwise unavailable at the same time, such failover behavior may be enabled in both the first control bridge device and the second control bridge device. As such, the first control bridge device may failover to the backup path that results in the first control bridge device forwarding traffic destined for the port extender device over the second LAG to the second control bridge device, the second control bridge device may failover to the backup path that results in the second control bridge device forwarding that traffic back over the second LAG to the first control bridge device, and so on until the time to live (TTL) of the traffic reaches zero. During the time until the TTL reaches zero, the traffic will loop between the first control bridge device and the second control bridge device, using bandwidth of the second LAG and reducing the bandwidth of the logical switch.

Accordingly, it would be desirable to provide a layer 3 routing loop prevention system.

According to one embodiment, an information handling system (IHS) includes at least one first port that is coupled to at least one first link in a first link aggregation group (LAG) provided on an extender device; a second port that provides a second link to a control bridge device; a processing system that is coupled to the at least one first port and the second port; a memory system that includes instructions that, when executed by the processing system, cause the processing system to provide a packet processing engine that is configured to: receive a first packet through the second link from the control bridge device, wherein the first packet is directed to the extender device; determine that the at least one first link is unavailable for forwarding the first packet to the extender device; determine that the first packet includes a control bridge device failover identifier; determine that the performance of layer 3 forwarding will result in the first packet being sent to the control bridge device; and drop the first packet in response to determining that the first packet was received through the at least one second link, includes the control bridge device failover identifier, and will be sent to the control bridge device if layer 3 forwarding is performed.

FIG. 1 is a schematic view illustrating an embodiment of an information handling system.

FIG. 2 is a schematic view illustrating an embodiment of a layer 3 routing loop prevention system.

FIG. 3 is a schematic view illustrating an embodiment of a networking device in the layer 3 routing loop prevention system of FIG. 2 .

FIG. 4 is a flow chart illustrating an embodiment of a method for preventing layer 3 routing loops.

FIG. 5 a is a schematic view illustrating an embodiment of the operation of the layer 3 routing loop prevention system of FIG. 2 operating according to the method of FIG. 4 .

FIG. 5 b is a schematic view illustrating an embodiment of the operation of the layer 3 routing loop prevention system of FIG. 2 operating according to the method of FIG. 4 .

FIG. 5 c is a schematic view illustrating an embodiment of the operation of the layer 3 routing loop prevention system of FIG. 2 operating according to the method of FIG. 4 .

FIG. 5 d is a schematic view illustrating an embodiment of the operation of the layer 3 routing loop prevention system of FIG. 2 operating according to the method of FIG. 4 .

FIG. 5 e is a schematic view illustrating an embodiment of the operation of the layer 3 routing loop prevention system of FIG. 2 operating according to the method of FIG. 4

For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., personal digital assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, touchscreen and/or a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.

In one embodiment, IHS 100 , FIG. 1 , includes a processor 102 , which is connected to a bus 104 . Bus 104 serves as a connection between processor 102 and other components of IHS 100 . An input device 106 is coupled to processor 102 to provide input to processor 102 . Examples of input devices may include keyboards, touchscreens, pointing devices such as mouses, trackballs, and trackpads, and/or a variety of other input devices known in the art. Programs and data are stored on a mass storage device 108 , which is coupled to processor 102 . Examples of mass storage devices may include hard discs, optical disks, magneto-optical discs, solid-state storage devices, and/or a variety other mass storage devices known in the art. IHS 100 further includes a display 110 , which is coupled to processor 102 by a video controller 112 . A system memory 114 is coupled to processor 102 to provide the processor with fast storage to facilitate execution of computer programs by processor 102 . Examples of system memory may include random access memory (RAM) devices such as dynamic RAM (DRAM), synchronous DRAM (SDRAM), solid state memory devices, and/or a variety of other memory devices known in the art. In an embodiment, a chassis 116 houses some or all of the components of IHS 100 . It should be understood that other buses and intermediate circuits can be deployed between the components described above and processor 102 to facilitate interconnection between the components and the processor 102 .

Referring now to FIG. 2 , an embodiment of a layer 3 routing loop prevention system 200 is illustrated. In the illustrated embodiment, the layer 3 routing loop prevention system 200 includes a logical switch 202 that is provided by a pair of networking devices 204 a and 204 b connected to a pair of extender devices 206 a and 206 b , respectively, that are further connected to an extender device 208 in order to couple the networking devices 204 a and 204 b to the extender device 208 . The networking devices 204 a and 206 b are coupled together by a first link aggregation group (LAG) 210 that includes a plurality of first LAG links 210 a . Furthermore, the networking device 204 a is coupled to the extender device 206 a by a second LAG 212 that includes a plurality of second LAG links 212 a , and the networking device 204 b is coupled to the extender device 206 b by a third LAG 212 that includes a plurality of third LAG links 214 a . The extender devices 206 a and 206 b are coupled to the extender device 208 by a fourth LAG 216 that includes a plurality of fourth LAG links 216 a and 216 b . As is known in the art, any of the LAGs 210 , 212 , 214 , and 216 may be provided by combining multiple network connections (e.g., links provided between ports on the devices) in parallel in order to increase throughput and/or provide redundancy. Such aggregation may be accomplished via link aggregation control protocol such as those defined in IEEE 802.1AX and IEEE 802.1aq, as well by proprietary solutions such as Virtual Trunk Linking (VLT) and/or other aggregation solutions known in the art. For example, in some of the embodiments discussed below, the fourth LAG 216 is described as provided by VLT.

Either or both of the networking devices 206 a and 206 b may be the IHS 100 discussed above with reference to FIG. 1 and/or may include some or all of the components of the IHS 100 . In some of the embodiments discussed below, the networking devices 204 a and 204 b are described as first and second control bridge devices, but in other embodiments may include any of a variety of different networking devices known in the art. Any of the extender devices 206 a , 206 b , and 208 may be the IHS 100 discussed above with reference to FIG. 1 and/or may include some or all of the components of the IHS 100 . In some of the embodiments discussed below, the extender devices 206 a , 206 b , and 208 are described as port extender devices, but in other embodiments may include any of a variety of different extender devices known in the art. Furthermore, a physical or logical switch may be provided by wide variety of devices that will benefit from the teachings of the present disclosure similarly as described below for the logical switch, and those devices are envisioned as falling within the scope of the present disclosure as well. Thus, while a specific configuration of the networking devices 204 a and 204 b and the extender devices 206 a , 206 b , and 208 are illustrated, one of skill in the art in possession of the present disclosure will recognize that the networking devices, extender devices, and other devices (e.g., other than networking/control bridge devices and extender/port extender devices) may be coupled together in different manners to perform the functions discussed below while remaining within the scope of the present disclosure.

Each of the networking devices 204 a and 204 b are illustrated as coupled to a network 218 . As discussed below, either or both of the networking devices 206 a and 206 b may receive data traffic packets through the network 218 from source devices that may be the IHS 100 discussed above with reference to FIG. 1 . Each of the extender devices 206 a , 206 b , and/or 208 may be coupled to one or more host devices. In the illustrated embodiment, the extender device 206 a is coupled to host device(s) 220 , the extender device 206 b is coupled to host device(s) 222 , and the extender device 208 is coupled to host device(s) 224 . Any or all of the host devices 220 , 222 , and 224 may be the may be the IHS 100 discussed above with reference to FIG. 1 , and in specific examples may provide a destination device that is the destination of a data traffic packet received by either of the networking devices 204 a and/or 204 b as discussed in further detail below.

Referring now to FIG. 3 , an embodiment of a networking device 300 is illustrated. In an embodiment, the networking device 300 may be either or both of the networking devices 204 a and/or 204 b discussed above with reference to FIG. 2 . As discussed above, in specific embodiments, the networking device 300 may be a control bridge device utilized with port extender devices in providing a logical switch, but in other embodiments may include a wide variety of networking devices known in the art. The networking device 300 includes a chassis 302 that may house the components of the networking device 300 . In an embodiment, the networking device 300 includes a processing system (not illustrated, but which may include the processor 102 discussed above with reference to FIG. 1 ) that is housed in the chassis 302 and that is coupled to a memory system (not illustrated, but which may include the system memory 114 discussed above with reference to FIG. 1 ) that is housed in the chassis 302 and that includes instructions that, when executed by the processing system, cause the processing system to provide a packet processing engine 304 that is configured to perform the functions of the packet processing engines and networking devices discussed below. While the packet processing engine 304 is primarily described below as performing layer 3 routing loop prevention functions, one of skill in the art in possession of the present disclosure will recognize that the packet processing engine 304 may perform a variety of other networking device functions known in the art (e.g., packet receipt, packet routing, etc.) while remaining within the scope of the present disclosure.

In the illustrated embodiment, the packet processing engine 304 is coupled to a plurality of first ports 306 (e.g., via a coupling between the processing system and the ports 306 ). For example, with reference to FIG. 2 , the first ports 306 may be provided on the networking device 204 a and aggregated to provide the second LAG 212 to the extender device 206 a , and/or may be provided on the networking device 204 b and aggregated to provide the third LAG 214 to the extender device 206 b . In the illustrated embodiment, the packet processing engine 304 is also coupled to a plurality of second ports 308 (e.g., via a coupling between the processing system and the ports 308 ). For example, with reference to FIG. 2 , the second ports 308 may be provided on the networking device 204 a and/or the networking device 204 b and aggregated to provide the first LAG 210 between the networking devices 204 a and 204 b . In the illustrated embodiment, the packet processing engine 304 is also coupled to a port 310 (e.g., via a coupling between the processing system and the port 310 ). For example, with reference to FIG. 2 , the third ports 310 may be provided on the networking device 204 a and/or the networking device 204 b and may provide one or more links coupled to the network 218 .

The packet processing engine 304 is also coupled to one or more databases (e.g., via a coupling between the processing system and a storage device in the networking device 300 ) that stores information to enable the layer 3 routing loop prevention functions discussed below. In the illustrated embodiment, those databases include a backup routing database 312 and an access control list database 314 . In the examples discussed below, the backup routing database 312 may be part of a routing database (not illustrated) and may include a backup “next-hop”, routing path, or other instruction that provides one or more actions for the packet processing engine 304 to perform in response to determining that a link to a destination though an extender device is unavailable such that data cannot be sent over a primary data path (e.g., including in the routing database), as discussed in further detail below. In the examples discussed below, the access control list database 314 may include permissions, rules, or other instructions that provides one or more actions for the packet processing engine 304 to perform to determine whether and/or how to route a packet, as discussed in further detail below. While not illustrated, the networking device 300 may include a communication system (e.g., a Network Interface Controller (NIC)) or other subsystem that includes a networking device address such as, for example, a Media Access Control (MAC) address and/or other address associated with the networking device 300 . While specific databases are illustrated and described as including specific information below, one of skill in the art in possession of the present disclosure will recognize that a variety of different databases and/or instructions other than those illustrated may be provided for the packet processing engine 304 in order to provide for the layer 3 routing loop prevention functions discussed below while remaining within the scope of the present disclosure.

Referring now to FIG. 4 , an embodiment of a method 400 for preventing layer 3 route looping is illustrated. In the embodiment illustrated and discussed below, the method 400 is utilized to prevent layer 3 routing loops between the networking/control bridge devices 204 a and 204 b when coupled to the extender/port extender device 208 through a fourth/VLT LAG 216 that is provided to a pair of extender/port extender devices 206 a and 206 b that are respectively directly connected to the networking devices 204 a and 204 b via second and third LAGs 212 and 214 . In order to illustrate the some of the benefits of the layer 3 routing loop prevention system 200 described herein, conventional layer 3 routing failover mechanisms are described briefly below with regard to a simplified VLT system as well as the VLT system illustrated in FIG. 2 .

First consider a simplified VLT system (not illustrated) that provides two networking/control bridge devices (e.g., the networking devices 204 a and 204 b ) that are connected together by an Inter-Chassis Link (ICL)/LAG (e.g., the first LAG 210 ) and that are each connected to an extender/port extender device (e.g., the extender device 208 ) by a VLT LAG (e.g., the fourth LAG 216 ). Thus, the simplified VLT system is substantially similar to the system illustrated in FIG. 2 , except with the removal of the extender devices 206 a and 206 b such that the networking devices 204 a and 204 b are directly connected to the extender device 208 by the links 216 a and 216 b , respectively, in the fourth LAG 216 . In a conventional VLT failover scenario, if the link 216 a between the networking device 204 a the extender device 208 becomes unavailable, the networking device 204 a may activate a failover mechanism and begin performing layer 3 routing of packets such that those packet are sent to the networking device 204 b (e.g., by adding ports (e.g., the ports 308 ) in the ICL/LAG 210 as part of the VLT LAG 216 ). If the link 216 b between the networking device 204 b and the extender device 208 also becomes unavailable, the networking device 204 b will also add ports (e.g., the ports 308 ) in the ICL/LAG 210 as part of the VLT LAG 216 . However, the networking device 204 b will begin performing layer 2 routing of the packets, and those packets will be source suppressed such that packets received from the networking device 204 a will not be sent back over the ICL/LAG 210 , thus preventing looping behavior.

Now consider a VLT system substantially similar to that illustrated in FIG. 2 . In such a system, the conventional VLT failover scenario can cause issues because the extender device 208 is not directly connected to the networking devices 204 a and 204 b , but rather coupled to the networking devices 204 a and 204 b via “access” or intermediate extender devices 206 a and 206 b . As such, the conventional VLT failover mechanism discussed above can prevent data traffic from reaching host device(s) 220 and/or 222 that are coupled to the intermediate extender devices 206 a and 206 b , respectively. For example, if the link 216 a between the extender device 206 a and the extender device 208 becomes unavailable, the networking device 204 a will begin performing the layer 3 routing of the packets such that those packet are sent to the networking device 204 b as discussed above, and there will be no path available for routing packets to the host device(s) 220 . Furthermore, if the links 216 a and 216 b between the both the extender devices 206 a and 206 b and the extender device 208 become unavailable, the networking device 204 a will begin performing the layer 3 routing of the packets such that those packet are sent to the networking device 204 b , and the networking device 204 b will begin performing the layer 3 routing of the packets such that those packet are sent back to the networking device 204 a , causing a layer 3 routing loop that will continue until the TTL of the packet goes to zero, during which the bandwidth of the ICL/LAG 210 will be occupied by that looping packet.

Furthermore, source suppression or other default blocking techniques on the ICL/LAG 210 to prevent the packet from being sent back over the ICL/LAG 210 to the networking device that forwarded it can also cause issues that discourage the use of such techniques. For example, if peer routing between the networking devices 204 a and 204 b is disabled, the networking devices 204 a may perform layer 3 routing when the destination address in the packet (e.g., a Media Access Control (MAC) destination address) matches the address (e.g., a MAC address) of the networking device 204 a , and may perform layer 2 routing when the destination address in the packet matches the address of the networking device 204 b (and vice versa). In such a situation, the networking device 204 a may provide the gateway through the logical switch 202 for a source host (not illustrated) that is coupled to the network 218 , and layer 3 packets from that source host may reach either of networking device 204 a or 204 b due to, for example, LAG hashing behavior by a switch (not illustrated) in the network 218 that is coupled to the networking devices 204 a and 204 b by a LAG (not illustrated). If that source host sends a packet that is directed to one of the host device(s) 222 and that packet is received by the networking device 204 b , that packet may then be layer 3 forwarded by the networking device 204 b over the ICL/LAG 210 to the networking device 204 a (i.e., because the networking device 204 a is the gateway for the source host and the packet includes a destination address of the networking device 204 a ). The networking device 204 a would then layer 3 forward the packet back to the networking device 204 b over the ICL LAG 210 so that the networking device 204 b may then forward that packet on to the host device 222 that is its destination. As such, source suppression or other blocking techniques would result in the networking device 204 b dropping that packet in such scenarios.

As discussed in further detail below, the method 400 may be utilized to avoid the issues discussed above, as well as other layer 3 routing loop issues, by providing for the determination by a networking device that its peer networking device has attempted to layer 3 route a packet and, if that has occurred, dropping that packet if the performance of layer 3 routing will result in that packet being forwarded back to the peer networking device. As such, the networking devices 204 a and 204 b of the layer 3 routing loop prevention system 200 are able to identify scenarios in which layer 3 routing loops can occur, and provide a mechanism to stop those loops. One of skill in the art in possession of the present disclosure will recognize that such functionality may coexist with the conventional layer 2 link failover mechanisms discussed above. The method 400 begins at block 402 where a packet that is directed to an extender device is received at a first networking device. Referring now to FIG. 5 a , in an embodiment a packet is received (as indicated by the arrow 500 in FIG. 5 a ) from a source host (not illustrated) by the networking device 204 a through the network 218 . For example, at block 402 the packet processing engine 304 in the networking device 300 / 204 a may receive the packet through the port 310 and determine that the packet is directed to the extender device 208 based on an L2 or L3 lookup in a table in the networking device 300 / 204 a and/or utilizing other techniques known in the art.

The method 400 then proceeds to block 404 where it is determined that a link from the first networking device to the extender device is unavailable. In an embodiment, the packet processing engine 304 in the networking device 300 / 204 a may determine that the link 216 a between the extender device 206 a and the extender device 208 is unavailable (e.g., as illustrated by element 502 in FIG. 5 a ). For example, the link 216 a between the extender device 206 a and the extender device 208 may be unavailable due to a link failure, and/or a variety of other issues known in the art. While only one of the link 216 a in the fourth LAG 216 is illustrated as being unavailable, as discussed below, in some situations both of the links 216 a and 216 b in the fourth LAG 216 may fail or otherwise become unavailable at the same time (e.g., due to a LAG failure). The packet processing engine 304 in the networking device 300 / 204 a may determine that its link 216 a to the extender device 208 is unavailable in response to detecting that unavailability based on any of a variety of IEE 802.1br protocol factors known in the art. In an embodiment, in response to determining that its link 216 a to the extender device 208 is unavailable, the packet processing engine 304 in the networking device 300 / 204 a may enable a failover group for the extender device 208 . For example, that failover group may include a backup next-hop, routing path, or other instruction in the backup routing database 312 of networking device 300 / 204 a that causes the packet processing engine 304 to forward packets over the ICL/first LAG 210 to the networking device 204 b , as well as perform the additional actions discussed below.

The method 400 then proceeds to block 406 where a first networking device failover identifier is provided in the packet. In some embodiments, the packet processing engine 304 in the networking device 300 / 204 a may provide the first networking device failover identifier by providing an address of the networking device 300 / 204 a (e.g., a MAC address) as the source of the packet. In addition, the packet processing engine 304 in the networking device 300 / 204 a may provide the first networking device failover identifier by providing an address of the networking device 204 b (e.g., a MAC address) as the destination of the packet. In specific embodiments, at block 406 , the packet processing engine 304 in the networking device 300 / 204 a does not modify the Virtual Local Area Network (VLAN) for the packet, and does not decrement the TTL for the packet. As discussed below, such actions at block 406 provide for layer 3 routing when the extender device 208 becomes unavailable while also providing an indication to the networking device 204 b about the activation of the failover mechanism in the networking device 204 a.

In some experimental embodiments, it has been found that the provision of the networking device addresses (e.g., the MAC addresses of the networking devices 204 a and 204 b ) as the source and destination of the packet at block 406 as discussed above can cause some issues. For example, the ACL space for some conventional networking devices restrict how ACL entries are defined, and the provision of the networking device MAC addresses as the source and destination of the packet as discussed above can result in duplicate information being stored in the ACL space, thus providing for an inefficient use of that ACL space. With such systems, different embodiments of block 406 may be performed. In those embodiments, the packet processing engine 304 in the networking device 300 / 204 a may provide the first networking device failover identifier by providing an address of the networking device 204 b (e.g., a MAC address) as the destination of the packet, while providing an extension channel identifier (ECID) in the packet such as, for example, a reserved ECID. For example, the reserved ECID may be configured to assign the packet a virtual port, which as discussed below may be used to by the networking device 204 b indication to determine that the failover mechanism in the networking device 204 a has been activated. In specific embodiments, at block 406 , the packet processing engine 304 in the networking device 300 / 204 a does not modify the source address or the VLAN for the packet, and does not decrement the TTL for the packet. While a few examples of the first networking device failover identifier have been described, one of skill in the art in possession of the present disclosure will recognize that other identifiers, metadata, and/or information may be provided in or with the packet to identify that the failover mechanism of a networking device has been activated while remaining within the scope of the present disclosure.

The method 400 then proceeds to block 408 where layer 3 forwarding is performed to send the packet to the second networking device. Referring now to FIG. 5 b , in an embodiment, subsequent to performing the actions at block 406 discussed above, the packet processing engine 304 in the networking device 300 / 204 a operates to perform layer 3 forwarding of the packet as per the backup next-hop/routing path in the backup routing database 312 such that the packet is sent through the port(s) 308 and over the link(s) 210 a of the first LAG 210 to the networking device 204 b (as illustrated by the arrow 504 ). The details of layer 3 forwarding of packets are known in the art and not described in detail herein. The method 400 then proceeds to block 410 where the packet directed to the extender device is received at the second networking device. In an embodiment, the packet processing engine 304 in the networking device 300 / 204 b receives the packet that is directed to the extender device 208 through its port(s) 308 .

The method 400 then proceeds to block 412 where it is determined that a link from the second networking device to the extender device is unavailable. Referring now to FIG. 5 c , in an embodiment, the packet processing engine 304 in the networking device 300 / 204 b may determine that the link 216 b between the extender device 206 b and the extender device 208 is unavailable (e.g., as illustrated by the element 506 in FIG. 5 c ). For example, the link 216 b between the extender device 206 b and the extender device 208 may be unavailable due to a link failure, and/or a variety of other issues known in the art. The packet processing engine 304 in the networking device 300 / 204 b may determine that its link 216 b to the extender device 208 is unavailable in response to detecting that unavailability based on any of a variety of IEE 802.1br protocol factors known in the art.

The method 400 then proceeds to block 414 where it is determined that the packet includes the first networking device failover identifier. In some embodiments, the packet processing engine 304 in the networking device 300 / 204 b may determine that the packet includes the first networking failover identifier when the packet is received over the ICL/first LAG 210 , the source of the packet includes the address of the networking device 204 a (e.g., its MAC address), and the destination of the packet includes the address of the networking device 204 b (e.g., its MAC address). For example, the determinations at block 414 may be made using an ACL entry in the ACL database 314 having match criteria that includes an incoming port that is part of the ICL/first LAG 210 , an incoming packet source address that is the MAC address of the first networking device 204 a , and a destination address of the packet that is the MAC address of the networking device 204 b . In other embodiments, the packet processing engine 304 in the networking device 300 / 204 b may determine that the packet includes the first networking failover identifier when the packet is received over the ICL/first LAG 210 and the packet includes the reserved ECID (or is assigned a virtual port via a reserved ECID as discussed above). For example, the determinations at block 414 may be made using an ACL entry in the ACL database 314 having match criteria that includes an ingress interface that is part of the ICL/first LAG 210 and the reserved ECID/assigned virtual port. While a few examples have been provided, one of skill in the art in possession of the present disclosure will recognize how other failover identifiers may be determined to be included in the packet using other information and/or combinations of information while remaining within the scope of the present disclosure. If the packet does not include the first networking device failover identifier, then the packet may be forwarded based on a layer 3 forwarding decision such that the packet can be routed back on the ICL/first LAG 210 .

The method 400 then proceeds to decision block 416 where it is determined whether layer 3 forwarding will send the packet to the first networking device. In embodiments where the link 216 b is available and/or there are other paths to the extender device 208 that do not go through the networking device 204 a (neither of which is illustrated), the packet processing engine 304 may determine at decision block 416 that layer 3 forwarding will not result in the packet being sent to the networking device 204 a . In response, the method 400 will proceed to block 418 where the packet is forwarded to the extender device. In an embodiment, the packet processing engine 304 in the networking device 300 / 204 b will then perform layer 3 forwarding of the packet to send the packet to the extender device 208 through the available path that does not include the networking device 204 a . As such, when the link 216 a is unavailable but the networking device 204 b has available links or paths to the extender device 208 , the packet is forwarded to the extender device 208 .

In an embodiment, in response to determining that its link 216 b to the extender device 208 was unavailable at block 412 , the packet processing engine 304 in the networking device 300 / 204 b may have enabled a failover group for the extender device 208 that includes a backup next-hop, routing path, or other instruction in the backup routing database 312 of the networking device 204 b that would cause the packet processing engine 304 to forward packets over the ICL/first LAG 210 to the networking device 204 a . At decision block 416 , with the failover group enabled, the packet processing engine 304 in the networking device 300 / 204 b may access the backup routing database 312 and determine that when the link 216 b to the extender device 208 is unavailable, the backup next hop, path, or other instruction provides for the layer 3 forwarding of the packet back over the ICL/first LAG 210 to the networking device 204 a.

In response to determining that layer 3 forwarding of the packet will result in the packet being forwarded back over the ICL/first LAG 210 to the networking device 204 a at decision block 416 , the method 400 will proceed to block 420 where the packet is dropped. Referring now to FIG. 5 c , in an embodiment, the packet processing engine 304 in the networking device 204 b drops the packet (as indicated by element 508 ). For example, the determination at decision block 416 may be made using an ACL entry in the ACL database 314 having match criteria that includes an egress port that is part of the ICL/first LAG 210 and that is determined by a layer 3 routing action. As such, the ACL database may include an ACL entry having match criteria that includes an incoming port that is part of the ICL/first LAG 210 , an incoming packet source address that is the MAC address of the first networking device 204 a , a destination address of the packet that is the MAC address of the networking device 204 b , and a layer 3 routing egress port that is part of the ICL/first LAG 210 , and when a packet and/or actions associated with that packet match those match criteria, the packet processing engine 304 will drop that packet.

In another example, the determinations at decision block 416 may be made using an ACL entry in the ACL database 314 having match criteria that includes a next hop that will send the packet back to the device from which it was received and that is determined by a layer 3 routing action. As such, the ACL database may include an ACL entry having match criteria that includes an ingress interface that is part of the ICL/first LAG 210 , that the packet includes the reserved ECID/assigned virtual port, and a layer 3 routing next hop that will return the packet to the device from which it was received, and when a packet and/or actions associated with that packet match those match criteria, the packet processing engine 304 will drop that packet.

The embodiment illustrated in FIGS. 5 a , 5 b , and 5 c and discussed above provides an example of a system in which peer routing is enabled between the networking devices 204 a and 204 b . In such an example, the packet may be received at the networking device 204 a with a destination address that is the MAC address of the networking device 204 a . The networking device 204 a may determine that the link 216 a is unavailable such that its failover mechanism activates and the packet is sent over the first LAG 210 with the destination address changed to the MAC address of the networking device 204 b and the reserved ECID added. The networking device 204 b may then receive the packet, determine that the link 216 b is unavailable, and that the packet has been assigned a virtual port due to the reserved ECID. With the link unavailable, the failover mechanism for the networking device 204 b will activate such that the packet will be associated with an instruction to send it back over the first LAG 210 to the networking device 204 a . However, that packet will match the ACL entry due to that packet being received over the first LAG 210 , having been assigned the virtual port, and being subject to layer 3 routing that will result in it being sent back to the networking device 204 a , and as a result that packet will be dropped.

FIGS. 5 a , 5 b , 5 d , and 5 e provide an example of a system in which peer routing is disabled between the networking devices 204 a and 204 b . In such an example, the packet may be received at the networking device 204 a with a destination address that is the MAC address of the networking device 204 b . The networking device 204 a may then switch the packet over the first LAG 210 without adding the reserved ECID to that packet because, as discussed above, the destination address of the packet is not the MAC address of the networking device 204 a . The networking device 204 b receives the packet and determines that the link 216 b is unavailable such that its failover mechanism activates and the packet is sent back over the first LAG 210 (as indicated by the arrow 510 ) with the destination address changed to the MAC address of the networking device 204 a and the reserved ECID added. The networking device 204 a may then receive the packet, determine that the link 216 a is unavailable, and that the packet has been assigned a virtual port due to the reserved ECID. With the link unavailable, the failover mechanism for the networking device 204 a will activate such that the packet will be associated with an instruction to send it back over the first LAG 210 to the networking device 204 b . However, that packet will match the ACL entry due to that packet being received over the first LAG 210 , having been assigned the virtual port, and being subject to layer 3 routing that will result in it being sent back to the networking device 204 b , and as a result that packet will be dropped (as indicated by element 512 ).

Thus, systems and methods have been described that prevent layer 3 routing loops. In a specific example, the systems and methods allow a control bridge device to indirectly indicate to a peer control bridge device that layer 3 routing was attempted to send a packet to a port extender device that was unreachable over a link between the control bridge device and the port extender device. Such indirect indications can be enabled by modifying packet fields in the packet such as the source MAC address and/or adding a reserved ECID before sending that packet over an ICL to the peer control bridge device. The peer control bridge device can detect the source MAC address and/or reserved ECID that indicate that layer 3 routing was attempted by the control bridge device, and if the packet is to be routed back over the ICL to the control bridge device, the peer control bridge device will then drop that packet to prevent the layer 3 routing loop. Such mechanisms scale well as the layer 3 backup next-hop is common for all the next hops destined for a port extender device port, and may be enabled by a single ACL entry. In addition, this failover mechanism integrates easily with layer 2 failover mechanisms.

Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.