Apparatus, system, and method for improving the efficiency of link-failure detection

A disclosed method may include (1) receiving, via a physical interface of a network device, a hello packet that includes information specific to a fault-detection session established between the physical interface and an additional physical interface of a remote device via a link, (2) identifying, within the information, a plurality of statuses that correspond to a plurality of virtual interfaces partitioned on the additional physical interface of the remote device, (3) determining, based at least in part on the statuses of the virtual interfaces, that the link supporting the fault-detection session established between the physical interface and the additional physical interface has experienced at least a partial failure, and then in response to determining that the link has experienced the at least partial failure, (4) performing a remedial action to address the at least partial failure of the link. Various other apparatuses, systems, and methods are also disclosed.

BACKGROUND

Network devices (such as routers and switches) are often used to forward traffic within a network and/or across networks. These network devices may represent and/or form the infrastructure of such networks. In some examples, these network devices may include and/or house various physical interfaces. In such examples, these physical interfaces may each be partitioned into multiple virtual and/or logical interfaces.

In one example, virtual interfaces partitioned on physical interfaces of different network devices may establish fault-detection sessions with one another. For example, a virtual interface partitioned on one physical interface and another virtual interface partitioned on a remote physical interface may establish a Bidirectional Forwarding Detection (BFD) session with one another. As part of this fault-detection session, these virtual interfaces may exchange hello packets to inform each other of their respective statuses.

Unfortunately, this traditional configuration of the communication session may lead to certain deficiencies and/or shortcomings that negatively impact the efficiency of link-failure detection for the virtual interfaces. For example, even though multiple virtual interfaces are partitioned on each of two remote physical interfaces, this traditional configuration of the communication session may call for each pair of virtual interfaces to exchange their own individual hello packets with one another. In this example, the various hello packets exchanged between each pair of virtual interfaces may be processed individually. The burden of generating, transmitting, and/or processing the vast number of hello packets may impair and/or inhibit the performance and/or efficiency of the respective hosts.

The instant disclosure, therefore, identifies and addresses a need for additional and improved apparatuses, systems, and methods for improving the efficiency of link-failure detection.

SUMMARY

As will be described in greater detail below, the instant disclosure generally relates to apparatuses, systems, and methods for probing the status of unreachable virtual interfaces partitioned on remote physical interfaces. In one example, a method for accomplishing such a task may include (1) receiving, via a physical interface of a network device, a hello packet that includes information specific to a fault-detection session established between the physical interface and an additional physical interface of a remote device via a link, (2) identifying, within the information included in the hello packet, a plurality of statuses that correspond to a plurality of virtual interfaces partitioned on the additional physical interface of the remote device, (3) determining, based at least in part on the statuses of the virtual interfaces, that the link supporting the fault-detection session established between the physical interface and the additional physical interface has experienced at least a partial failure, and then in response to determining that the link has experienced the at least partial failure, (4) performing a remedial action to address the at least partial failure of the link.

Similarly, a system that implements the above-identified method may include a physical processor configured to execute various modules stored in memory. In one example, this system may include and/or execute (1) a receiving module that receives, via a physical interface of a network device, a hello packet that includes information specific to a fault-detection session established between the physical interface and an additional physical interface of a remote device via a link, (2) an identification module that identifies, within the information included in the hello packet, a plurality of statuses that correspond to a plurality of virtual interfaces partitioned on the additional physical interface of the remote device, (3) a determination module that determines, based at least in part on the statuses of the virtual interfaces, that the link supporting the fault-detection session established between the physical interface and the additional physical interface has experienced at least a partial failure, and (4) a remedy module that performs a remedial action to address the at least partial failure of the link in response to the determination that the link has experienced the at least partial failure.

Additionally or alternatively, an apparatus that implements the above-identified method may include a physical interface of a network device that is communicatively coupled to an additional physical interface of a remote device via a link. The apparatus may also include a physical processor that is communicatively coupled to the physical interface of the network device. In one example, the physical processor may (1) receive, via the physical interface, a hello packet that includes information specific to a fault-detection session established between the physical interface and the additional physical interface of the remote device via the link, (2) identify, within the information included in the hello packet, a plurality of statuses that correspond to a plurality of virtual interfaces partitioned on the additional physical interface of the remote device, (3) determine, based at least in part on the statuses of the virtual interfaces, that the link supporting the fault-detection session established between the physical interface and the additional physical interface has experienced at least a partial failure, and then (4) perform a remedial action to address the at least partial failure of the link in response to determining that the link has experienced the at least partial failure.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present disclosure describes various apparatuses, systems, and methods for improving the efficiency of link-failure detection. As will be explained in greater detail below, embodiments of the instant disclosure may enable physical interfaces to identify, gather, and/or collect the statuses of all their corresponding virtual interfaces. For example, a first set of virtual interfaces may be partitioned on a first physical interface included on a network device. In this example, a second set of virtual interfaces may be partitioned on a second physical interface included on a remote device.

Continuing with this example, one virtual interface partitioned on the first physical interface and one virtual interface partitioned on the second physical interface may establish a BFD session with each other. In addition, another virtual interface partitioned on the first physical interface and another virtual interface partitioned on the second physical interface may also establish a BFD session with each other. Rather than having each virtual interface included in the first set exchange hello packets with their counterparts partitioned on the second physical interface, the first physical interface may identify, gather, and/or collect the statuses of the entire first set of virtual interfaces and then transmit a single hello packet to the second physical interface on behalf of the first set of virtual interfaces. This single hello packet may include, identify, and/or indicate the status of each virtual interface partitioned on the first physical interface.

Similarly, rather than having each virtual interface included in the second set exchange hello packets with their counterparts partitioned on the first physical interface, the second physical interface may identify, gather, and/or collect the statuses of the entire second set of virtual interfaces and then transmit a single hello packet to the first physical interface on behalf of the second set of virtual interfaces. This single hello packet may include, identify, and/or indicate the status of each virtual interface partitioned on the second physical interface.

Accordingly, under this new configuration of BFD technology, hello packets may be exchanged at the physical-interface level, as opposed to the virtual-interface level. As a result, the first and second physical interfaces may be able to transmit and/or process far fewer hello packets, potentially improving the performance and/or efficiency of the respective hosts involved in the BFD session when compared to traditional BFD technology.

The following will provide, with reference toFIGS. 1, 2, and 4, detailed descriptions of exemplary apparatuses, systems, and corresponding implementations for probing the status of unreachable virtual interfaces partitioned on remote physical interfaces. Detailed descriptions of corresponding computer-implemented methods will be provided in connection withFIG. 3. Detailed descriptions of an exemplary echo request and an exemplary echo reply will be provided in connection withFIGS. 5 and 6. In addition, detailed descriptions of an exemplary computing system for carrying out these methods will be provided in connection withFIG. 6.

FIG. 1shows an exemplary system100that facilitates improving the efficiency of link-failure detection. As illustrated inFIG. 1, system100may include one or more modules102for performing one or more tasks. As will be explained in greater detail below, modules102may include a receiving module104, an identification module106, a determination module108, a remedy module110, and a communication module112. Although illustrated as separate elements, one or more of modules102inFIG. 1may represent portions of a single module or application (such as an operating system and/or a BFD application or client).

As illustrated inFIG. 1, exemplary system100may further include one or more interfaces, such as a physical interface120and/or virtual interfaces122(1)-(N). In some examples, physical interface120may include and/or represent a physical interface that facilitates the flow of traffic within a network and/or across networks. For example, physical interface120may include and/or represent a NIC that has direct connections with other interfaces within a network. Additional examples of physical interface120include, without limitation, packet forwarding engines, routing engines, Physical Interface Cards (PICS), Flexible PIC Concentrators (FPCs), Switch Interface Boards (SIBS), control boards, communication ports, connector interface panels, line cards, egress interfaces, ingress interfaces, portions of one or more of the same, combinations or variations of one or more of the same, and/or any other suitable interface.

As illustrated inFIG. 1, virtual interfaces122(1)-(N) may be partitioned on physical interface120. Accordingly, virtual interfaces122(1)-(N) may share the infrastructure of physical interface120for communication purposes. In some examples, physical interface120may be logically divided into virtual interfaces122(1)-(N). In one example, virtual interfaces122(1)-(N) may each establish and/or maintain a communication session with an interface included and/or partitioned on a remote device.

As illustrated inFIG. 1, exemplary system100may additionally include one or more packets, such as a hello packet126. In some examples, hello packet126may be exchanged between physical interfaces involved in a BFD session. In one example, hello packet126may serve to notify a local physical interface of the statuses of virtual interfaces partitioned on a remote physical interface. Accordingly, hello packet126may be used to detect link failures that occur between the local physical interface and the remote physical interface. Additionally or alternatively, hello packet126may be used to detect link failures that occur between the virtual interfaces partitioned on the local physical interface and the virtual interfaces partitioned on the remote physical interface. Examples of hello packet126include, without limitation, BFD control packets, Open Shortest Path First (OSPF) packets, Link Aggregation Control Protocol (LACP) packets, combinations of one or more of the same, and/or any other suitable hello packet.

As illustrated inFIG. 1, hello packet126may include and/or represent information128. Examples of information128include and/or identify, without limitation, protocol versions, diagnostic codes, current communication states or conditions, control information, authentication information, packet sizes or lengths, discriminator values, minimum receive or transmits intervals, status indicators for virtual interfaces partitioned on a network interface, combinations of one or more of the same, and/or any other suitable information.

An apparatus for improving the efficiency of link-failure detection may include all or portions of exemplary system100. In some examples, system100inFIG. 1may be implemented in a variety of ways. For example, all or a portion of exemplary system100may represent portions of exemplary system200inFIG. 2. As shown inFIG. 2, system200may include a network device202and a remote device206in communication via a link230. In one example, link230may represent part of and/or be include in network204.

As illustrated inFIG. 2, network device202may include and/or represent instances of memory140, physical processor130, and/or physical interface120. Similarly, remote device206may also include and/or represent instances of memory140, physical processor130, and/or a physical interface220. In one example, virtual interfaces222(1)-(N) may be partitioned on physical interface220. Additionally or alternatively, link230may provide connectivity between physical interface120of network device202and/or physical interface220of remote device206.

In some examples, and as will be described in greater detail below, one or more of modules102may cause network device202to (1) receive, via physical interface120, hello packet126that includes information128specific to a fault-detection session established between physical interface120and physical interface220of remote device206via link230, (2) identify, within information128included in hello packet126, a plurality of statuses that correspond to virtual interfaces222(1)-(N) partitioned on physical interface220of remote device206, (3) determine, based at least in part on the statuses of virtual interfaces222(1)-(N), that link230supporting the fault-detection session established between physical interface120and physical interface220has experienced at least a partial failure, and then (4) perform a remedial action to address the at least partial failure of link230in response to determining that link230has experienced the at least partial failure.

Network device202and remote device206each generally represent any type or form of physical computing device capable of reading computer-executable instructions and/or handling network traffic. In one example, network device202and/or remote device206may include and/or represent routers (such as provider edge routers, hub routers, spoke routers, autonomous system boundary routers, and/or area border routers) that receives, routes, forwards, and/or otherwise handles network traffic. Additional examples of network device202and/or remote device206include, without limitation, switches, hubs, modems, bridges, repeaters, gateways, multiplexers, network adapters, network interfaces, client devices, laptops, tablets, desktops, servers, cellular phones, Personal Digital Assistants (PDAs), multimedia players, embedded systems, wearable devices, gaming consoles, variations or combinations of one or more of the same, and/or any other suitable network devices.

In some examples, network device202and/or remote device206may represent intermediate hops along a network path. Accordingly, network device202and/or remote device206may not necessarily be the initial source and/or final destination of certain traffic. An apparatus for improving the efficiency of link-failure detection may include and/or represent all or a portion of network device202or remote device206.

Network204generally represents any medium or architecture capable of facilitating communication or data transfer. In one example, network204may include network device202and/or remote device206. Additionally or alternatively, network204may include other devices that facilitate communication among network device202and/or remote device206. In this example, network204may facilitate communication or data transfer using wireless and/or wired connections. Examples of network204include, without limitation, an intranet, a Wide Area Network (WAN), a Local Area Network (LAN), a Personal Area Network (PAN), the Internet, Power Line Communications (PLC), a cellular network (e.g., a Global System for Mobile Communications (GSM) network), portions of one or more of the same, variations or combinations of one or more of the same, and/or any other suitable network. Although not illustrated in this way inFIG. 2, network204may also include additional devices (such as client devices, servers, network devices, etc.).

FIG. 3is a flow diagram of an exemplary computer-implemented method300for improving the efficiency of link-failure detection. The steps shown inFIG. 3may be performed by any suitable computer-executable code and/or computing system, including system100inFIG. 1, system200inFIG. 2, system600inFIG. 6, and/or variations or combinations of one or more of the same. In one example, each of the steps shown inFIG. 3may represent an algorithm whose structure includes and/or is represented by multiple sub-steps, examples of which will be provided in greater detail below.

As illustrated inFIG. 3, at step310one or more of the systems described herein may receive a hello packet at a physical interface of a network device. For example, receiving module104may, as part of network device202and/or remote device206inFIG. 2, receive hello packet126at physical interface120of network device202via link230. In this example, hello packet126may have originated from or passed through physical interface220of remote device206. As will be described in greater detail below, hello packet126may include and/or identify information128that is specific to a fault-detection session (such as a BFD session) established between physical interface120and physical interface220.

The systems described herein may perform step310in a variety of ways and/or contexts. In some examples, receiving module104may monitor physical interface120for hello packets. While monitoring physical interface120in this way, receiving module104may receive hello packet126at physical interface120as hello packet126arrives via link230.

In some examples, communication module112may establish the fault-detection session between physical interfaces120and220. Many types or forms of fault-detection sessions may be implemented. For example, communication module112may establish a BFD session between physical interfaces120and220. In one example, the BFD session may rely on and/or be supported by the OSPF and/or LACP protocols. Accordingly, communication module112may include and/or represent an OSPF and/or LACP module.

To facilitate establishing the fault-detection session, communication module112may pair virtual interfaces122(1) and222(1) via link230. In some examples, communication module112may pair multiple virtual interfaces partitioned on physical interface120with multiple virtual interfaces partitioned on physical interface220. For example, communication module112may pair virtual interfaces122(1) and222(1) via link230as well as virtual interfaces122(N) and222(N) via link230.

In one example, communication module112may activate virtual interface122(1) and/or virtual interface222(1). By doing so, communication module112may set and/or configure virtual interface122(1) and/or virtual interface222(1) to serve as the active interface(s) within the fault-detection session. Additionally or alternatively, communication module112may deactivate virtual interface122(N) and/or virtual interface222(N). By doing so, communication module112may set and/or configure virtual interface122(N) and/or virtual interface222(N) to serve as the backup interface(s) within the fault-detection session. Such backup interfaces may be activated and/or brought online in the event that the corresponding active interfaces experience a failure that impairs communication. In other words, the backup interfaces may be activated and/or brought online when connectivity between the active interfaces is lost.

In some examples, the fault-detection session may implement and/or involve link aggregation technology. For example, communication module112may group the active virtual interface(s) and backup virtual interface(s) partitioned on physical interface120via the LACP protocol. In this example, communication module112may group the active virtual interface(s) and backup virtual interface(s) partitioned on physical interface220via the LACP protocol. These groupings may each serve as an aggregate link and/or a Link Aggregation Group (LAG).

In some examples, the fault-detection session may implement and/or involve Virtual Machines (VMs) and/or Virtual Extension Local Area Network (VXLAN) technology. For example, communication module112may create a VXLAN tunnel between a VXLAN tunnel endpoint at physical interface120and an additional VXLAN tunnel endpoint at physical interface220. By doing so, physical interfaces120and220may be able to exchange hello packets via the VXLAN tunnel. Accordingly, receiving module104may receive hello packet126via the VXLAN tunnel endpoint as hello packet126arrives via the VXLAN tunnel.

In some examples, communication module112may set and/or configure the fault-detection session to initially operate in an asynchronous mode. In the asynchronous mode, physical interfaces120and220may exchange hello packets with one another on a periodic basis. The fault-detection session may, however, switch from the asynchronous mode to a demand mode under certain conditions. In the demand mode, physical interfaces120and220may exchange hello packets with one another on an as-needed basis, as opposed to a periodic basis. For example, in the demand mode, physical interfaces120and220may refrain from exchanging hello packets unless a certain event and/or condition occurs and/or is detected.

In some examples, communication module112may set and/or configure the fault-detection session to initially operate at the physical-interface level, as opposed to the virtual-interface level. When operating at the physical-interface level, the fault-detection session may call for physical interfaces120and220to exchange hello packets on behalf of their respective virtual interfaces. In contrast, when operating at the virtual-interface level, the fault-detection session may call for virtual interfaces122(1)-(N) to exchange hello packets directly with virtual interfaces222(1)-(N). Because the virtual-interface level may necessitate the exchange of individual hello packets for each pair of virtual interfaces, the physical-interface level may represent a more efficient, faster way to achieve fault or link-failure detection.

In some examples, the fault-detection session may operate at the physical-interface level until a link failure occurs and/or is detected. Accordingly, before a link failure occurs and/or is detected, physical interfaces120and220may exchange hello packets on behalf of their respective virtual interfaces. However, after such a link failure, the fault-detection session may begin operating at the virtual-interface level. In other words, once a link failure occurs and/or is detected, virtual interfaces122(1)-(N) may start exchanging hello packets directly with virtual interfaces222(1)-(N).

As a specific example, physical interface220of remote device206may identify, collect, and/or gather the statuses of virtual interfaces222(1)-(N). Physical interface220may generate hello packet126that includes, within information128, a set of virtual-interface indices that indicate whether virtual interfaces222(1)-(N) are currently up or down. Physical interface220may then transmit hello packet126to physical interface120via link230. As hello packet126arrives at physical interface120, receiving module104may receive hello packet126and/or prepare the same for processing.

Returning toFIG. 3, at step320one or more of the systems described herein may identify, within the information included in the hello packet, a plurality of statuses that correspond to a plurality of virtual interfaces partitioned on the additional physical interface of the remote device. For example, identification module106may, as part of network device202and/or remote device206inFIG. 2, identify the current statuses of virtual interfaces222(1)-(N) within information128included in hello packet126. In one example, in the event that a certain virtual interface is currently reachable and functional, information128may identify that virtual interface as being up and/or online. However, in the event that a certain virtual interface is currently unreachable or nonfunctional, information128may identify that virtual interface as being down and/or offline.

The systems described herein may perform step320in a variety of ways and/or contexts. In some examples, identification module106may search hello packet126for control information. During this search, identification module106may identify information128within hello packet126. As illustrated inFIG. 4, information128may include and/or identify various types and/or sections of information (in this example, the protocol version of hello packet126, diagnostic codes for virtual interfaces222(1)-(N), current communication states or conditions of virtual interfaces222(1)-(N), control information for virtual interfaces222(1)-(N), the packet size or length of hello packet126, discriminator values for virtual interfaces122(1)-(N) and222(1)-(N), minimum receive or transmits intervals, status indicators for virtual interfaces222(1)-(N), combinations of one or more of the same, and/or any other suitable information).

In one example, identification module106may identify a set of virtual-interface indices in information128inFIG. 4(in this example, “|vf1|vf2|vf3| . . . ”). In this example, the set of virtual-interface indices may correspond to and/or represent the statuses of virtual interfaces222(1)-(N). These virtual-interface indices may indicate that some of virtual interfaces222(1)-(N) are currently up or healthy while others are currently down or broken.

In one example, identification module106may identify the statuses of all virtual interfaces partitioned on physical interface220. Additionally or alternatively, identification module106may identify the statuses of a subset (e.g., less than all) of the virtual interfaces partitioned on physical interface220.

In one example, identification module106may identify, within information128, a diagnostic code identifying and/or indicating a past action that previously led to the status of one of virtual interfaces222(1)-(N) changing from down to up. Additionally or alternatively, the diagnostic code may specify the reason for the last change in BFD session state at physical interface220and/or one or more of virtual interfaces222(1)-(N).

Returning toFIG. 3, at step330one or more of the systems described herein may determine, based at least in part on the statuses of the virtual interfaces, that the link supporting the fault-detection session established between the physical interface and the additional physical interface has experienced at least a partial failure. For example, determination module108may, as part of network device202and/or remote device206inFIG. 2, determine that link230supporting the fault-detection session established between physical interface120and physical interface220has experienced at least a partial failure. In this example, determination module108may arrive at and/or make this determination based at least in part on the statuses of virtual interfaces222(1)-(N) as identified within information128of hello packet126.

The systems described herein may perform step330in a variety of ways and/or contexts. In one example, determination module108may determine that one or more of virtual interfaces222(1)-(N) have gone down. As a result, determination module108may determine link230has experienced at least a partial failure.

In one example, determination module108may determine that all of virtual interfaces222(1)-(N) have gone down. As a result, determination module108may determine that link230has experienced a complete failure. In another example, determination module108may determine that only one of virtual interfaces222(1)-(N) has gone down and the rest of virtual interfaces222(1)-(N) remain up. As a result, determination module108may determine that link230has experienced a minor or partial failure.

In one example, determination module108may examine and/or analyze the diagnostic code identified in information128of hello packet126. In this example, determination module108may determine that link230has experienced the failure based at least in part on this examination and/or analysis. In one embodiment, this analysis and/or examination may indicate and/or suggest that the link failure resulted from a software malfunction. Additionally or alternatively, this analysis and/or examination may indicate and/or suggest that the link failure resulted from a hardware malfunction. Determination module108may also determine and/or identify the underlying cause and/or source of the failure in accordance with the examination and/or analysis.

Returning toFIG. 3, at step340one or more of the systems described herein may perform a remedial action to address the at least partial failure of the link in response to the determination that the link has experienced the at least partial failure. For example, remedy module110may, as part of network device202and/or remote device206inFIG. 2, perform a remedial action to address the at least partial failure of link230. In this example, remedy module110may initiate the remedial action in response to the determination that link230has experienced the at least partial failure.

The systems described herein may perform step340in a variety of ways and/or contexts. In one example, remedy module110may facilitate making a packet forwarding decision that accounts for the virtual interfaces that have gone down. For example, remedy module110may notify a routing engine of network device202that one or more of virtual interfaces222(1)-(N) have gone down. In response to this notification, the routing engine may make a packet forwarding decision that accounts for those virtual interfaces that have gone down. As a result of this packet forwarding decision, the routing engine may reroute traffic from link230to an alternative link (not necessarily illustrated inFIG. 2) due at least in part to one or more of virtual interfaces222(1)-(N) having gone down. Physical interface120may then forward traffic along the alternative link due at least in part to one or more of virtual interfaces222(1)-(N) having gone down.

In one example, remedy module110may facilitate establishing a subsequent fault-detection session. For example, remedy module110may notify an OSPF and/or LACP module that one or more of virtual interfaces222(1)-(N) have gone down. In response to this notification, the OSPF and/or LACP module may establish a subsequent fault-detection session between one or more of virtual interfaces122(1)-(N) and other virtual interfaces partitioned on another remote physical interface.

In one example, remedy module110may facilitate switching from operating the BFD session at the physical-interface level to operating the BFD session at the virtual-interface level. For example, remedy module110may notify communication module112that one or more of virtual interfaces222(1)-(N) have gone down. In response to this notification, communication module112may reconfigure and/or reprogram the BFD session such that virtual interfaces122(1)-(N) and222(1)-(N) exchange hello packets directly with one another instead of relying on physical interfaces120and220to relay the respective virtual-interface statuses. Additionally or alternatively, communication module112may switch the fault-detection session from asynchronous mode to demand mode such that subsequent hello packets are exchanged on an as-needed basis instead of a periodic basis.

In some examples, in the event that the link failure resulted from a software malfunction, remedy module110may attempt to fix the software malfunction. In one example, remedy module110may perform one or more reboot actions to resolve the software malfunction. For example, remedy module110may direct remote device206to power cycle physical interface220. Additionally or alternatively, remedy module110may direct remote device206to power cycle itself and/or physical interface220.

In some examples, remedy module110may notify an administrator that one or more of virtual interfaces222(1)-(N) have gone down. In response to this notification, the administrator may do any number of things in an effort to fix the underlying reason that the virtual interfaces went down. For example, the administrator may reattach a physical component of link230to at least one of physical interfaces120and220.

In some examples, remedy module110may attempt to address the underlying cause of the link failure by redoing the same action that previously led the failed virtual interface(s) to return from down to up. For example, remedy module110may select the past action indicated by the diagnostic code identified within information128. In this example, remedy module110may repeat the same action indicated by the diagnostic code in an effort to fix the underlying cause of the link failure.

Although many of the foregoing methods are described from the perspective of network device202, remote device206may perform the same methods in connection with the fault-detection session. For example, one or more of modules102may cause remote device206to (1) receive, via physical interface220, a hello packet that includes information specific to a fault-detection session established between physical interface120and physical interface220via link230, (2) identify, within the information included in the hello packet, a plurality of statuses that correspond to virtual interfaces122(1)-(N) partitioned on physical interface120, (3) determine, based at least in part on the statuses of virtual interfaces122(1)-(N), that link230supporting the fault-detection session established between physical interface120and physical interface220has experienced at least a partial failure, and then (4) perform a remedial action to address the at least partial failure of link230in response to determining that link230has experienced the at least partial failure.

FIG. 6is a block diagram of an exemplary computing system600capable of implementing and/or being used in connection with one or more of the embodiments described and/or illustrated herein. In some embodiments, all or a portion of computing system600may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the steps described in connection withFIG. 3. All or a portion of computing system600may also perform and/or be a means for performing and/or implementing any other steps, methods, or processes described and/or illustrated herein.

Computing system600broadly represents any type or form of electrical load, including a single or multi-processor computing device or system capable of executing computer-readable instructions. Examples of computing system600include, without limitation, workstations, laptops, client-side terminals, servers, distributed computing systems, mobile devices, network switches, network routers (e.g., backbone routers, edge routers, core routers, mobile service routers, broadband routers, etc.), network appliances (e.g., network security appliances, network control appliances, network timing appliances, SSL VPN (Secure Sockets Layer Virtual Private Network) appliances, etc.), network controllers, gateways (e.g., service gateways, mobile packet gateways, multi-access gateways, security gateways, etc.), and/or any other type or form of computing system or device.

Computing system600may be programmed, configured, and/or otherwise designed to comply with one or more networking protocols. According to certain embodiments, computing system600may be designed to work with protocols of one or more layers of the Open Systems Interconnection (OSI) reference model, such as a physical layer protocol, a link layer protocol, a network layer protocol, a transport layer protocol, a session layer protocol, a presentation layer protocol, and/or an application layer protocol. For example, computing system600may include a network device configured according to a Universal Serial Bus (USB) protocol, an Institute of Electrical and Electronics Engineers (IEEE) 1394 protocol, an Ethernet protocol, a T1 protocol, a Synchronous Optical Networking (SONET) protocol, a Synchronous Digital Hierarchy (SDH) protocol, an Integrated Services Digital Network (ISDN) protocol, an Asynchronous Transfer Mode (ATM) protocol, a Point-to-Point Protocol (PPP), a Point-to-Point Protocol over Ethernet (PPPoE), a Point-to-Point Protocol over ATM (PPPoA), a Bluetooth protocol, an IEEE 802.XX protocol, a frame relay protocol, a token ring protocol, a spanning tree protocol, and/or any other suitable protocol.

Computing system600may include various network and/or computing components. For example, computing system600may include at least one processor614and a system memory616. Processor614generally represents any type or form of processing unit capable of processing data or interpreting and executing instructions. For example, processor614may represent an application-specific integrated circuit (ASIC), a system on a chip (e.g., a network processor), a hardware accelerator, a general purpose processor, and/or any other suitable processing element.

Processor614may process data according to one or more of the networking protocols discussed above. For example, processor614may execute or implement a portion of a protocol stack, may process packets, may perform memory operations (e.g., queuing packets for later processing), may execute end-user applications, and/or may perform any other processing tasks.

System memory616generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and/or other computer-readable instructions. Examples of system memory616include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, or any other suitable memory device. Although not required, in certain embodiments computing system600may include both a volatile memory unit (such as, for example, system memory616) and a non-volatile storage device (such as, for example, primary storage device632, as described in detail below). System memory616may be implemented as shared memory and/or distributed memory in a network device. Furthermore, system memory616may store packets and/or other information used in networking operations.

In certain embodiments, exemplary computing system600may also include one or more components or elements in addition to processor614and system memory616. For example, as illustrated inFIG. 6, computing system600may include a memory controller618, an Input/Output (I/O) controller620, and a communication interface622, each of which may be interconnected via communication infrastructure612. Communication infrastructure612generally represents any type or form of infrastructure capable of facilitating communication between one or more components of a computing device. Examples of communication infrastructure612include, without limitation, a communication bus (such as a Serial ATA (SATA), an Industry Standard Architecture (ISA), a Peripheral Component Interconnect (PCI), a PCI Express (PCIe), and/or any other suitable bus), and a network.

Memory controller618generally represents any type or form of device capable of handling memory or data or controlling communication between one or more components of computing system600. For example, in certain embodiments memory controller618may control communication between processor614, system memory616, and I/O controller620via communication infrastructure612. In some embodiments, memory controller618may include a Direct Memory Access (DMA) unit that may transfer data (e.g., packets) to or from a link adapter.

I/O controller620generally represents any type or form of device or module capable of coordinating and/or controlling the input and output functions of a computing device. For example, in certain embodiments I/O controller620may control or facilitate transfer of data between one or more elements of computing system600, such as processor614, system memory616, communication interface622, and storage interface630.

In certain embodiments, communication interface622may also represent a host adapter configured to facilitate communication between computing system600and one or more additional network or storage devices via an external bus or communications channel. Examples of host adapters include, without limitation, Small Computer System Interface (SCSI) host adapters, Universal Serial Bus (USB) host adapters, IEEE 1394 host adapters, Advanced Technology Attachment (ATA), Parallel ATA (PATA), Serial ATA (SATA), and External SATA (eSATA) host adapters, Fibre Channel interface adapters, Ethernet adapters, or the like. Communication interface622may also enable computing system600to engage in distributed or remote computing. For example, communication interface622may receive instructions from a remote device or send instructions to a remote device for execution.

As illustrated inFIG. 6, exemplary computing system600may also include a primary storage device632and/or a backup storage device634coupled to communication infrastructure612via a storage interface630. Storage devices632and634generally represent any type or form of storage device or medium capable of storing data and/or other computer-readable instructions. For example, storage devices632and634may represent a magnetic disk drive (e.g., a so-called hard drive), a solid state drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash drive, or the like. Storage interface630generally represents any type or form of interface or device for transferring data between storage devices632and634and other components of computing system600.

In some examples, all or a portion of system100inFIG. 1may represent portions of a cloud-computing or network-based environment. Cloud-computing and network-based environments may provide various services and applications via the Internet. These cloud-computing and network-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface. Various functions described herein may also provide network switching capabilities, gateway access capabilities, network security functions, content caching and delivery services for a network, network control services, and/or and other networking functionality.