Patent ID: 12192095

DETAILED DESCRIPTION

The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

A network, such as an EVPN, a VXLAN, and/or an EVPN-VXLAN, enables a group of dispersed customer sites to be connected using a Layer 2 virtual bridge and/or a Layer 3 underlay. The network may include customer edge devices connected to provider edge devices that route traffic to and from the customer edge devices.

In a multi-homed scenario, a customer edge device is connected to two or more provider edge devices that provide redundancy and network service to the customer edge device. The customer edge device is connected to the two or more provider edge devices by a plurality of links (e.g., a first group of links that connect the customer edge device to a first provider edge device, a second group of links that connect the customer edge device to a second provider edge device, and/or the like) that form a link aggregation group (LAG). According to the link aggregation control protocol (LACP), the customer edge device sends link aggregation control protocol data units (LACPDUs) to the two or more provider edge devices via the plurality of links to cause the two or more provider edge devices to maintain (e.g., keep up) the plurality of links and therefore maintain the LAG.

In some cases, the customer edge device undergoes a provisioning or updating process that requires the customer edge device to shut down and/or reboot. During this process, the customer edge device ceases sending the LACPDUs to the two or more provider edge devices via the plurality of links. This often causes the two or more provider edge devices to cease maintaining the plurality of links, which therefore causes the links to be torn down because the two or more provider edge devices are no longer receiving LACPDUs. Consequently, the customer edge device is no longer connected to the two or more provider edge devices and therefore is unable to communicate with the network to obtain, from another customer edge device on the network, one or more file images that are needed by the customer edge device to complete the provisioning or updating process.

In some cases, the two or more provider edge devices may be manually configured (e.g., by a network administrator) to maintain the plurality of links while the customer edge device undergoes the provisioning or updating process, but this can be a resource intensive, time-consuming process that is susceptible to human error. For example, failing to remove the manual configuration after the customer edge device completes the provisioning or updating process may allow the plurality of links to be maintained, even when the customer edge device, the two or more provider edge devices, and/or the plurality of links are experiencing performance issues. This can result in communication failure, packet data loss, traffic blackholing, and/or the like.

Some implementations described herein provide a provider edge device associated with a LAG that maintains, according to the LACP, a set of links that connect the provider edge device to a consumer edge device associated with the LAG. The provider edge device determines that the provider edge device is not receiving LACPDUs from the consumer edge device via the set of links. The provider edge device determines, based on a message from another provider edge device associated with the LAG, that the other provider edge device is not receiving LACPDUs from the consumer edge device. Accordingly, the provider edge device causes the set of links to have a maintain LAG status, which causes the provider edge device to keep up the set of links and to cease maintaining the set of links according to the LACP. The provider edge device routes one or more packets to or from the consumer edge device via the set of links (e.g., while the set of links has the maintain LAG status).

In some implementations, the provider edge device determines, after routing the one or more packets to or from the consumer edge device via the set of links, that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device. Accordingly, the provider edge device causes the set of links to cease having the maintain LAG status, which causes the provider edge device to cease keeping up the set of links and to maintain the set of links according to the LACP.

In this way, the provider edge device described herein automatically maintains a set of links associated with a LAG to facilitate provisioning or updating of a customer edge device. Accordingly, this allows for a customer edge device to communicate with another customer edge device via a set of links of the provider edge device that are associated with the LAG to allow the customer edge device to complete a provisioning or updating process. This reduces a need for manually configuring the provider edge device, as well as other provider edge devices associated with the LAG, and therefore conserves computing resources (e.g., processing resources, memory resources, communication resources, and/or power resources, among other examples) of a device (e.g., a client device) that would otherwise be needed to manually configure the provider edge device and the other provider edge devices. Further, this reduces a likelihood of human error or other network misconfiguration issues from being introduced into a network associated with the provider edge device. This prevents at least some communication failure, packet data loss, traffic blackholing, and/or the like, that would otherwise occur using manual configuration. Accordingly, the provider edge device can improve a performance of the provider edge device, other provider edge devices associated with the LAG, the customer edge device, and/or the network.

FIGS.1A-1Eare diagrams of an example implementation100associated with maintaining a set of links associated with a LAG to facilitate provisioning or updating of a customer edge device. As shown inFIGS.1A-1E, example implementation100includes multiple customer edge devices (e.g., shown as customer edge devices CE1and CE2) and multiple provider edge devices (e.g., shown as provider edge devices PE1through PE N, where N≥2). These devices are described in more detail below in connection withFIGS.2-4.

As shown inFIG.1A, the customer edge device CE1may be connected to provider edge devices PE1through PE N. The customer edge device CE1may be connected to the provider edge devices PE1through PE N by a plurality of links, such as Gigabit Ethernet (ge) links. The customer edge device CE1may aggregate the plurality of links via a LAG to share traffic among the plurality of links and to enhance connection reliability. For example, the customer edge device CE1may bundle the plurality of links using an aggregation protocol, such as the Link Aggregation Control Protocol (LACP) (e.g., in active mode or passive mode). As shown inFIG.1A, the customer edge device CE1may be connected to the provider edge device PE1via a set of links LAG1(e.g., comprising one or more links), may be connected to the provider edge device PE2via a set of links LAG2(e.g., comprising one or more links), and/or may be connected to the provider edge device PE N via a set of links LAGN(e.g., comprising one or more links), where the set of links LAG1through LAGNare associated with the LAG.

As shown inFIG.1A, the provider edge devices PE1through PE N may be connected to a network (e.g., an EVPN, a VXLAN, or an EVPN-VXLAN, among other examples). In this way, the customer edge device CE1may be multi-homed with provider edge devices PE1through PE N over the network. As further shown inFIG.1A, the customer edge device CE2may be connected to the network. The customer edge device CE1may communicate with the customer edge device CE2via the LAG (e.g., via the sets of links LAG1through LAGN), via the provider edge devices PE1through PE N, and via the network.

As further shown inFIG.1A, and by reference number105, the customer edge device CE1may send LACPDUs (e.g., according to the LACP) to the provider edge devices PE1through PE N (e.g., to maintain the sets of links LAG1through LAGNthat comprise the LAG). For example, the customer edge device CE1may send LACPDUs to the provider edge device PE1via the set of links LAG1to maintain the set of links LAG1, may send LACPDUs to the provider edge device PE2via the set of links LAG2to maintain the set of links LAG2, and/or may send LACPDUs to the provider edge device PE N via the set of links LAGNto maintain the set of links LAGN.

When a provider edge device receives an LACPDU from the customer edge device CE1via a set of links associated with the LAG and the provider edge device, the provider edge device may update (e.g., according to the LACP) a data structure (e.g., a database, an electronic file structure, and/or an electronic file, among other examples) to indicate that the set of links have an “active” status. For example, when the provider edge device PE1receives an LACPDU via a link of the set of links LAG1, the provider edge device PE1may update an entry of a data structure (e.g., that is included and/or accessible to the provider edge device PE1) that is associated with the set of links LAG1to indicate that the set of links LAG1has an “active” status. Accordingly, a provider edge device may maintain a set of links associated with the LAG (e.g., “keep up” the set of links) when the set of links has an active status. For example, the provider edge device PE1, based on determining that an entry of the data structure indicates that the set of links LAG1has an active status, may maintain the set of links LAG1.

As further shown inFIG.1A, and by reference number110, the provider edge devices may communicate with each other to indicate a respective “LACPDU reception status” of the provider edge devices. An LACPDU reception status of a provider edge device may indicate whether the provider edge device is receiving LACPDUs (e.g., whether the provider edge device is actively receiving LACPDUs) from the customer edge device CE1via a set of links associated with the LAG and the provider edge device. For example, the LACPDU reception status may indicate whether the provider edge device received an LACPDU within a particular time interval (e.g., the previous 10 seconds, the previous 30 seconds, or the previous 60 seconds, among other examples).

In some implementations, a provider edge device associated with a LAG may generate and send respective messages to other provider edge devices associated with the LAG. A message may indicate the LACPDU reception status of the provider edge device. In some implementations, a message may be an Ethernet segment route message. The provider edge device may generate and send the message on a scheduled basis (e.g., every 10 seconds, every 30 seconds, or every 60 seconds, among other examples), on a triggered basis (e.g., when the LACPDU reception status changes), and/or on an on-demand basis (e.g., based on a request from another provider edge device), among other examples.

The provider edge device may send a message to another provider edge device associated with the LAG via the network. For example, the provider edge device may send the message via a link of the provider edge device that is connected to the network (e.g., a link that is not included in a set of links of the provider edge device that is associated with the LAG). Accordingly, the other provider edge device may receive the message from the provider edge device via the network. For example, the other provider edge device may receive the message via a link of the other provider edge device that is connected to the network (e.g., a link that is not included in a set of links of the receiver provider edge device that is associated with the LAG).

As an example, the provider edge device PE1may determine an amount of time since a time of receipt of an LACPDU from the customer edge device CE1via the set of links LAG1and determine whether the amount of time is greater than an LACPDU time-out interval (e.g., a time-out interval associated with tearing down links associated with a LAG according to the LACP). When the provider edge device PE1determines that the amount of time is greater than the LACPDU time-out interval, the provider edge device PE1may determine that the provider edge device PE1is not receiving LACPDUs. Alternatively, when the provider edge device PE1determines that the amount of time is less than or equal to the LACPDU time-out interval, the provider edge device PE1may determine that the provider edge device PE1is receiving LACPDUs.

The provider edge device PE1may generate a message that includes the LACPDU reception status of the provider edge device PE1(e.g., that provider edge device PE1is receiving or not receiving LACPDUs). The provider edge device PE1may send the message to one or more of provider edge devices PE1through PE N. For example, the provider edge device PE1may send the message to the provider edge device PE2via a link of the provider edge device PE1that is not included in the set of links LAG1. The message may propagate through the network and the provider edge device PE2may receive the message via a link of the provider edge device PE2that is not included in the set of links LAG2.

In some implementations, a message generated and sent by a provider edge device may include additional information, such as an internet protocol (IP) address of the provider edge device, an identifier associated with the LAG, and/or the like. The identifier associated with the LAG may be an Ethernet segment identifier (ESI) associated with the LAG. The provider edge device may process information included in an LACPDU received by the customer edge device CE1(e.g., an identifier identifying the customer edge device CE1, port key information associated with the customer edge device CE1, and/or the like) to determine the ESI associated with the LAG. Accordingly, each provider edge device associated with the LAG may determine the same ESI for the set of links that connect the provider edge device to the customer edge device CE1.

Turning toFIG.1B, and reference number115, the customer edge device CE1may stop sending LACPDUs. For example, the customer edge device may undergo a customer edge device provisioning process or a customer edge device updating process that requires the customer edge device CE1to stop communicating with the provider edge devices PE1through PE N for a period of time and/or that requires the customer edge device CE1to perform a shutdown and/or reboot sequence. Accordingly, provider edge devices PE1through PE N may stop receiving LACPDUs on respective sets of links associated with the LAG. For example, the provider edge device PE1may stop receiving LACPDUs via the set of links LAG1, the provider edge device PE2may stop receiving LACPDUs via the set of links LAG2, and/or the provider edge device PE1may stop receiving LACPDUs via the set of links LAGN.

As further shown inFIG.1B, and by reference number120, the provider edge device PE1may determine that the provider edge devices PE1through PE N are not receiving LACPDUs. In some implementations, the provider edge device PE1may determine that the provider edge device PE1is not receiving LACPDUs from the CE device via the set of links LAG1. For example, the provider edge device PE1may identify a time of receipt of a last (i.e., most recent) LACPDU received by the provider edge device PE1from the customer edge device CE1via the set of links LAG1. The provider edge device PE1may determine an amount of time since the time of receipt and determine whether the amount of time is greater than an LACPDU time-out interval (e.g., a time-out interval associated with tearing down links associated with a LAG according to the LACP). When the provider edge device PE1determines that the amount of time is greater than the LACPDU time-out interval, the provider edge device PE1may determine that the provider edge device PE1is not receiving LACPDUs from the customer edge device CE1via the set of links LAG1.

In some implementations, the provider edge device PE1may determine that another provider edge device, of the provider edge devices PE2through PE N, is not receiving LACPDUs. For example, the provider edge device PE1may receive a message (e.g., as described above in relation toFIG.1Aand reference number110) from the provider edge device PE2. The provider edge device PE1may process (e.g., parse) the message to identify an LACPDU reception status of the provider edge device PE2, an ESI associated with the set of links LAG2, an IP address of the provider edge device PE2, and/or the like. The provider edge device PE1may determine that the ESI associated with the set of links LAG2matches an ESI associated with the set of links LAG1, and may therefore determine that the message is providing information associated with the LAG. Accordingly, when the LACPDU reception status of the provider edge device PE2indicates that the provider edge device PE2is not receiving LACPDUs, the provider edge device PE1may determine that the provider edge device PE2is not receiving LACPDUs from the customer edge device CE1(e.g., via the set of links LAG2).

As further shown inFIG.1B, and by reference number125, the provider edge device PE1may determine that the provider edge device PE1is not core isolated (e.g., that the provider edge device PE1is not disconnected from the network). For example, the provider edge device PE1may determine, based on receiving the message from the provider edge device PE2(e.g., via a link of the provider edge device PE1that is connected to the network), that the provider edge device PE1is not core isolated. As another example, the provider edge device PE1may monitor the link of the provider edge device PE1that is connected to the network to determine whether the provider edge device PE1is core isolated. When the provider edge device PE1does not detect traffic being transmitted or received by the link, the provider edge device PE1may determine that the provider edge device PE1is core isolated. The provider edge device PE1may therefore allow the set of links LAG1to be torn down according to the LACP (e.g., when the provider edge device PE1is not receiving LACPDUs from the customer edge device CE1via the set of links LAG1). Alternatively, when the provider edge device PE1detects traffic being transmitted or received by the link, the provider edge device PE1may determine that the provider edge device PE1is not core isolated. Accordingly, the provider edge device PE1may perform one or more of the additional processing steps described herein.

As further shown inFIG.1B, and by reference number130, the provider edge device PE1may determine that the provider edge device PE1is a designated provider edge device for the LAG (e.g., a provider edge device that is to maintain a set of links associated with the LAG to maintain the LAG). For example, the provider edge device PE1may identify an IP address of the provider edge device PE1(e.g., based on a connection with the network) and/or may identify an IP address of the provider edge device PE1(e.g., based on information included in the message provided by the provider edge device PE2to the provider edge device PE1). The provider edge device PE1may determine that the IP address of the provider edge device PE1is preferable to the IP address of the provider edge device PE2(e.g., a value associated with the IP address of the provider edge device PE1is lower than a value associated with the IP address of the provider edge device PE2) and, therefore, may determine that the provider edge device PE1is the designated provider. Accordingly, the provider edge device PE1may determine that the set of links LAG1are to be maintained (and that the set of links LAG2are not to be maintained).

As further shown inFIG.1B, and by reference number135, the provider edge device PE1may determine that the set of links LAG1are to be maintained (e.g., based on determining that the provider edge device PE1is the designated provider edge device). Accordingly, in some implementations, the provider edge device PE1may cause the set of links LAG1to have a “maintain LAG” status. For example, the provider edge device PE1may identify an entry in a data structure that is associated with the LAG (e.g., the same data structure that is described above in relation toFIG.1Aand reference number105, or a different data structure) that identifies the set of links LAG1and a status of the set of links LAG1. The provider edge device PE1may update the entry to indicate the maintain LAG status for the set of links LAG1.

In some implementations, causing the set of links LAG1to have the maintain LAG status may cause the provider edge device PE1to maintain (e.g., keep up) the set of links LAG1(e.g., until the set of links LAG1no longer has the maintain LAG status). For example, when the set of links LAG1has the maintain LAG status, the provider edge device PE1may cease maintaining the set of links according to the LACP (e.g., by preventing the set of links LAG1from being torn down even though the provider edge device is not receiving LACPDUs from the customer edge device CE1).

Turning toFIG.1C, and reference number140, the customer edge device CE1may communicate with the customer edge device CE2. For example, the customer edge device CE1and the customer edge device CE2may exchange one or more packets via the set of links LAG1(e.g., that are being maintained by the provider edge device PE1), via the provider edge device PE1, via the link of the provider edge device PE1that is connected to the network, via the network, and via a link that connects the customer edge device CE2to the network. As further shown inFIG.1C, the other sets of links that were associated with the LAG (e.g., the sets of links LAG2through LAGN) and were not assigned a maintain LAG status, were torn down by the provider edge devices PE2through PE N according to the LACP (e.g., because the provider edge devices PE2through PE N did not receive LACPDUs from the customer edge device CE1via the sets of links LAG2through LAGN). Accordingly, the provider edge device PE1may route the one or more packets to or from the customer edge device CE1via the set of links LAG1.

The one or more packets may be associated with one or more file images for provisioning or updating the customer edge device CE1. For example, the provider edge device PE1may route one or more packets between the customer edge device CE1and the customer edge device CE2to allow the customer edge device CE1to be provisioned and/or updated with file images provided by the customer edge device CE2.

Turning toFIG.1D, and reference number145, the customer edge device CE1may resume sending LACPDUs via the sets of links that are associated with the LAG. For example, after the customer edge device CE1completes the customer edge device provisioning process and/or the customer edge device updating process (e.g., that required the customer edge device CE1to perform a shutdown and/or reboot sequence) the customer edge device CE1may send LACPDUs on the respective sets of links LAG1through LAGNto the provider edge devices PE1through PE N (e.g., in a similar manner to that described herein in relation toFIG.1Aand reference number105). Accordingly, provider edge devices PE1through PE N may receive LACPDUs from the customer edge device CE1via the sets of links LAG1through LAGN.

As further shown inFIG.1D, and by reference number150, the provider edge devices PE1through PE N may communicate with each other to indicate the respective LACPDU reception status of the provider edge devices (e.g., in a similar manner to that described herein in relation toFIG.1Aand reference number110). For example, the provider edge device PE1may generate and send messages to provider edge devices PE2through PE N that indicate an LACPDU reception status of the provider edge device PE1.

Turning toFIG.1E, and reference number155, the provider edge device PE1may determine that at least one of the provider edge devices PE1through PE N is receiving LACPDUs. In some implementations, the provider edge device PE1may determine that the provider edge device PE1is receiving LACPDUs from the customer edge device CE1via the set of links LAG1. For example, the provider edge device PE1may identify a time of receipt of an LACPDU received by the provider edge device PE1from the customer edge device CE1via the set of links LAG1(e.g., that was received by the provider edge device PE1after the customer edge device CE1resumed sending LACPDUs). The provider edge device PE1may determine an amount of time since the time of receipt and determine whether the amount of time is less than or equal to the LACPDU time-out interval. When the provider edge device PE1determines that the amount of time is less than or equal to the LACPDU time-out interval, the provider edge device PE1may determine that the provider edge device PE1is receiving LACPDUs. As another example, the provider edge device PE1may receive a number of LACPDUs from the customer edge device CE1via the set of links LAG1(e.g., within a particular time period, such as 10 seconds, 30 seconds, or 60 seconds, among other examples). The provider edge device PE1may determine whether the number of LACPDUs satisfies (e.g., is greater than or equal to) a threshold. When the provider edge device PE1determines that the number of LACPDUs satisfies the threshold, the provider edge device PE1may determine that the provider edge device PE1is receiving LACPDUs from the CE device.

In some implementations, the provider edge device PE1may determine that another provider edge device, of the provider edge devices PE2through PE N, is receiving LACPDUs (e.g., in a similar manner as that described herein in relation toFIG.1Band reference number120). For example, the provider edge device PE1may receive a message (e.g., as described above in relation toFIG.1Aand reference number110andFIG.1Dand reference number150) from the provider edge device PE2. The provider edge device PE1may determine that the ESI associated with the set of links LAG2matches an ESI of the set of links LAG1, and may therefore determine that the message is providing information associated with the LAG. Accordingly, when the LACPDU reception status of the provider edge device PE2indicates that the provider edge device PE2is receiving LACPDUs, the provider edge device PE1may determine that the provider edge device PE2is receiving LACPDUs from the customer edge device CE1(e.g., via the set of links LAG2).

As further shown inFIG.1E, and by reference number160, the provider edge device PE1may determine that the set of links LAG1are to cease having the maintain LAG status (e.g., based on determining that at least one of the provider edge devices PE1through PE N is receiving LACPDUs from the customer edge device CE1). Accordingly, in some implementations, the provider edge device PE1may cause the set of links LAG1to cease having the maintain LAG status. For example, the provider edge device PE1may identify an entry in the data structure (e.g., that is associated with the LAG) that identifies the set of links LAG1and a status of the set of links LAG1. The provider edge device PE1may update the entry to indicate that the maintain LAG status for the set of links LAG1has been removed.

In some implementations, causing the set of links LAG1to cease having the maintain LAG status may cause the provider edge device PE1to cease keeping up the set of links LAG1(e.g., regardless of the condition of customer edge device CE1). Accordingly, the provider edge device PE1may resume maintaining the set of links LAG1according to the LACP (e.g., keep up the set of links LAG1while the provider edge device PE1receives LACPDUs from the customer edge device CE1and/or tear down the set of links LAG1when the provider edge device PE1does not receive LACPDUs from the customer edge device CE1).

As indicated above,FIGS.1A-1Eare provided as an example. Other examples may differ from what is described with regard toFIGS.1A-1E. The number and arrangement of devices shown inFIGS.1A-1Eare provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices than those shown inFIGS.1A-1E. Furthermore, two or more devices shown inFIGS.1A-1Emay be implemented within a single device, or a single device shown inFIGS.1A-1Emay be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) shown inFIGS.1A-1Emay perform one or more functions described as being performed by another set of devices shown inFIGS.1A-1E.

FIG.2is a diagram of an example environment200in which systems and/or methods, described herein, may be implemented. As shown inFIG.2, environment200may include customer edge device210-1and customer edge device210-2(hereinafter referred to collectively as “customer edge devices210,” and individually as “customer edge device210”); provider edge device220-1through provider edge device220-n(hereinafter referred to collectively as “provider edge devices220,” and individually as “provider edge device220”); and a network230. Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Customer edge device210includes one or more devices (e.g., one or more traffic transfer devices) capable of processing and/or transferring traffic. For example, customer edge device210may include a firewall, a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar type of device. In some implementations, customer edge device may be connected to provider edge device220via a link, a plurality of links, one or more groups of links, and/or the like, as described elsewhere herein. In some implementations, customer edge device210may transmit traffic to provider edge device220and receive traffic from provider edge device220, as described elsewhere herein. In some implementations, customer edge device210may be a physical device implemented within a housing, such as a chassis. In some implementations, customer edge device210may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center.

Provider edge device220includes one or more devices (e.g., one or more traffic transfer devices) capable of processing and/or transferring traffic. For example, provider edge device220may include a firewall, a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar type of device. In some implementations, provider edge device220may receive traffic from customer edge device210and may transmit the traffic to another customer edge device210, as described elsewhere herein. In some implementations, provider edge device220may be a physical device implemented within a housing, such as a chassis. In some implementations, provider edge device220may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center.

Network230includes one or more wired and/or wireless networks. For example, network230may include a cellular network (e.g., a long-term evolution (LTE) network, a 3G network, a 4G network, a 5G network, a new radio (NR) network, a code division multiple access (CDMA) network, and/or the like), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), an Ethernet network, an Ethernet virtual private network (EVPN), a virtual extensible local area network (VXLAN), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, or the like, and/or a combination of these or other types of networks.

The number and arrangement of devices and networks shown inFIG.2are provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown inFIG.2. Furthermore, two or more devices shown inFIG.2may be implemented within a single device, or a single device shown inFIG.2may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment200may perform one or more functions described as being performed by another set of devices of environment200.

FIG.3is a diagram of example components of a device300, which may correspond to customer edge device210and/or provider edge device220. In some implementations, customer edge device210and/or provider edge device220may include one or more devices300and/or one or more components of device300. As shown inFIG.3, device300may include a bus310, a processor320, a memory330, a storage component340, an input component350, an output component360, and a communication component370.

Bus310includes a component that enables wired and/or wireless communication among the components of device300. Processor320includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field-programmable gate array, an application-specific integrated circuit, and/or another type of processing component. Processor320is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor320includes one or more processors capable of being programmed to perform a function. Memory330includes a random access memory, a read only memory, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory).

Storage component340stores information and/or software related to the operation of device300. For example, storage component340may include a hard disk drive, a magnetic disk drive, an optical disk drive, a solid state disk drive, a compact disc, a digital versatile disc, and/or another type of non-transitory computer-readable medium. Input component350enables device300to receive input, such as user input and/or sensed inputs. For example, input component350may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system component, an accelerometer, a gyroscope, and/or an actuator. Output component360enables device300to provide output, such as via a display, a speaker, and/or one or more light-emitting diodes. Communication component370enables device300to communicate with other devices, such as via a wired connection and/or a wireless connection. For example, communication component370may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and/or an antenna.

Device300may perform one or more processes described herein. For example, a non-transitory computer-readable medium (e.g., memory330and/or storage component340) may store a set of instructions (e.g., one or more instructions, code, software code, and/or program code) for execution by processor320. Processor320may execute the set of instructions to perform one or more processes described herein. In some implementations, execution of the set of instructions, by one or more processors320, causes the one or more processors320and/or the device300to perform one or more processes described herein. In some implementations, hardwired circuitry may be used instead of or in combination with the instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

The number and arrangement of components shown inFIG.3are provided as an example. Device300may include additional components, fewer components, different components, or differently arranged components than those shown inFIG.3. Additionally, or alternatively, a set of components (e.g., one or more components) of device300may perform one or more functions described as being performed by another set of components of device300.

FIG.4is a diagram of example components of a device400. Device400may correspond to customer edge device210and/or provider edge device220. In some implementations, customer edge device210and/or provider edge device220may include one or more devices400and/or one or more components of device400. As shown inFIG.4, device400may include one or more input components410-1through410-B (B≥1) (hereinafter referred to collectively as input components410, and individually as input component410), a switching component420, one or more output components430-1through430-C (C≥1) (hereinafter referred to collectively as output components430, and individually as output component430), and a controller440.

Input component410may be one or more points of attachment for physical links and may be one or more points of entry for incoming traffic, such as packets. Input component410may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component410may transmit and/or receive packets. In some implementations, input component410may include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and/or input queues. In some implementations, device400may include one or more input components410.

Switching component420may interconnect input components410with output components430. In some implementations, switching component420may be implemented via one or more crossbars, via busses, and/or with shared memories. The shared memories may act as temporary buffers to store packets from input components410before the packets are eventually scheduled for delivery to output components430. In some implementations, switching component420may enable input components410, output components430, and/or controller440to communicate with one another.

Output component430may store packets and may schedule packets for transmission on output physical links. Output component430may support data link layer encapsulation or decapsulation, and/or a variety of higher-level protocols. In some implementations, output component430may transmit packets and/or receive packets. In some implementations, output component430may include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and/or output queues. In some implementations, device400may include one or more output components430. In some implementations, input component410and output component430may be implemented by the same set of components (e.g., and input/output component may be a combination of input component410and output component430).

Controller440includes a processor in the form of, for example, a CPU, a GPU, an APU, a microprocessor, a microcontroller, a DSP, an FPGA, an ASIC, and/or another type of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, controller440may include one or more processors that can be programmed to perform a function.

In some implementations, controller440may include a RAM, a ROM, and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and/or instructions for use by controller440.

In some implementations, controller440may communicate with other devices, networks, and/or systems connected to device400to exchange information regarding network topology. Controller440may create routing tables based on the network topology information, may create forwarding tables based on the routing tables, and may forward the forwarding tables to input components410and/or output components430. Input components410and/or output components430may use the forwarding tables to perform route lookups for incoming and/or outgoing packets.

Controller440may perform one or more processes described herein. Controller440may perform these processes in response to executing software instructions stored by a non-transitory computer-readable medium. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

Software instructions may be read into a memory and/or storage component associated with controller440from another computer-readable medium or from another device via a communication interface. When executed, software instructions stored in a memory and/or storage component associated with controller440may cause controller440to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

The number and arrangement of components shown inFIG.4are provided as an example. In practice, device400may include additional components, fewer components, different components, or differently arranged components than those shown inFIG.4. Additionally, or alternatively, a set of components (e.g., one or more components) of device400may perform one or more functions described as being performed by another set of components of device400.

FIG.5is a flowchart of an example process500associated with maintaining a set of links associated with a LAG to facilitate provisioning or updating of a customer edge device. In some implementations, one or more process blocks ofFIG.5may be performed by a provider edge device (e.g., provider edge device220). The provider edge device may be associated with a LAG. In some implementations, one or more process blocks ofFIG.5may be performed by another device or a group of devices separate from or including the provider edge device, such as a customer edge device (e.g., customer edge device210). Additionally, or alternatively, one or more process blocks ofFIG.5may be performed by one or more components of device300, such as processor320, memory330, storage component340, input component350, output component360, and/or communication component370; one or more components of device400, such as input component410, switching component420, output component430, and/or controller440; and/or the like.

As shown inFIG.5, process500may include maintaining, according to an LACP, a set of links that connect the provider edge device to a consumer edge device associated with the LAG (block510). For example, the provider edge device may maintain, according to an LACP, a set of links that connect the provider edge device to a consumer edge device associated with the LAG, as described above.

As further shown inFIG.5, process500may include determining that the provider edge device is not receiving LACPDUs from the consumer edge device via the set of links (block520). For example, the provider edge device may determine that the provider edge device is not receiving LACPDUs from the consumer edge device via the set of links, as described above.

As further shown inFIG.5, process500may include receiving a message from another provider edge device associated with the LAG (block530). For example, the provider edge device may receive a message from another provider edge device associated with the LAG, as described above.

As further shown inFIG.5, process500may include processing the message to determine that the other provider edge device is not receiving LACPDUs from the consumer edge device (block540). For example, the provider edge device may process the message to determine that the other provider edge device is not receiving LACPDUs from the consumer edge device, as described above.

As further shown inFIG.5, process500may include causing, based on determining that the provider edge device is not receiving LACPDUs from the consumer edge device and determining that the other provider edge device is not receiving LACPDUs from the consumer edge device, the set of links to have a maintain LAG status(block550). For example, the provider edge device may cause, based on determining that the provider edge device is not receiving LACPDUs from the consumer edge device and determining that the other provider edge device is not receiving LACPDUs from the consumer edge device, the set of links to have a maintain LAG status, as described above. In some implementations, causing the set of links to have the maintain LAG status causes the provider edge device to keep up the set of links and to cease maintaining the set of links according to the LACP.

As further shown inFIG.5, process500may include routing, based on causing the set of links to have the maintain LAG status, one or more packets to or from the consumer edge device via the set of links (block560). For example, the provider edge device may route, based on causing the set of links to have the maintain LAG status, one or more packets to or from the consumer edge device via the set of links, as described above.

Process500may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.

In a first implementation, the message is an Ethernet segment route message that indicates an LACPDU reception status of the other provider edge.

In a second implementation, alone or in combination with the first implementation, determining that the provider edge device is not receiving LACPDUs from the consumer edge device via the set of links comprises identifying a time of receipt of a last LACPDU received by the provider edge device from the consumer edge device via the set of links, determining an amount of time since the time of receipt, and determining that the amount of time is greater than an LACPDU time-out interval.

In a third implementation, alone or in combination with one or more of the first and second implementations, causing the set of links to have the maintain LAG status comprises determining, based on receiving the message, that the provider edge device is not core isolated, identifying, based on determining that the provider edge device is not core isolated, an Internet protocol (IP) address of the provider edge device and an IP address of the other provider edge device, determining, based on the IP address of the provider edge device and the IP address of the other provider edge device, that the set of links are to be maintained, and updating an entry of a data structure associated with the LAG that indicates a status of the set of links to indicate the maintain LAG status for the set of links.

In a fourth implementation, alone or in combination with one or more of the first through third implementations, causing the set of links to have the maintain LAG status comprises identifying an entry in a data structure associated with the LAG, wherein the entry identifies the set of links and a status of the set of links, and updating the entry of the data structure to indicate the maintain LAG status for the set of links.

In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, process500includes determining, by the provider edge device and after routing the one or more packets to or from the consumer edge device via the set of links, that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, and causing, by the provider edge device and based on determining that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, the set of links to cease having the maintain LAG status, wherein causing the set of links to cease having the maintain LAG status causes the provider edge device to cease keeping up the set of links and to maintain the set of links according to the LACP.

In a sixth implementation, alone or in combination with one or more of the first through fifth implementations, causing the set of links to cease having the maintain LAG status comprises identifying an entry in a data structure associated with the LAG, wherein the entry identifies the set of links and the maintain LAG status for the set of links, and updating the entry of the data structure to remove the maintain LAG status for the set of links.

In a seventh implementation, alone or in combination with one or more of the first through sixth implementations, determining that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device comprises receiving a number of LACPDUs from the consumer edge device, determining that the number of LACPDUs satisfies a threshold, and determining, based on determining that the number of LACPDUs satisfies the threshold, that the provider edge device is receiving LACPDUs from the consumer edge device.

In an eighth implementation, alone or in combination with one or more of the first through seventh implementations, determining that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device comprises receiving an additional message associated with the LAG from the other provider edge device, and processing the message to determine that the other provider edge device is receiving LACPDUs from the consumer edge device.

AlthoughFIG.5shows example blocks of process500, in some implementations, process500may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG.5. Additionally, or alternatively, two or more of the blocks of process500may be performed in parallel.

FIG.6is a flowchart of an example process600associated with maintaining a set of links associated with a LAG to facilitate provisioning or updating of a customer edge device. In some implementations, one or more process blocks ofFIG.6may be performed by a provider edge device (e.g., provider edge device220). In some implementations, one or more process blocks ofFIG.6may be performed by another device or a group of devices separate from or including the provider edge device, such as customer edge device (e.g., customer edge device210). Additionally, or alternatively, one or more process blocks ofFIG.5may be performed by one or more components of device300, such as processor320, memory330, storage component340, input component350, output component360, and/or communication component370; one or more components of device400, such as input component410, switching component420, output component430, and/or controller440; and/or the like.

As shown inFIG.6, process600may include determining that the provider edge device is not receiving LACPDUs from a consumer edge device via a set of links associated with a LAG that connect the provider edge device to the consumer edge device (block610). For example, the provider edge device may determine that the provider edge device is not receiving LACPDUs from a consumer edge device via a set of links associated with a LAG that connect the provider edge device to the consumer edge device, as described above.

As further shown inFIG.6, process600may include receiving a message from another provider edge device associated with the LAG (block620). For example, the provider edge device may receive a message from another provider edge device associated with the LAG, as described above.

As further shown inFIG.6, process600may include processing the message to determine that the other provider edge device is not receiving LACPDUs from the consumer edge device (block630). For example, the provider edge device may process the message to determine that the other provider edge device is not receiving LACPDUs from the consumer edge device, as described above.

As further shown inFIG.6, process600may include causing, based on determining that the provider edge device is not receiving LACPDUs from the consumer edge device and determining that the other provider edge device is not receiving LACPDUs from the consumer edge device, the set of links to have a maintain LAG status (block640). For example, the provider edge device may cause, based on determining that the provider edge device is not receiving LACPDUs from the consumer edge device and determining that the other provider edge device is not receiving LACPDUs from the consumer edge device, the set of links to have a maintain LAG status, as described above.

As further shown inFIG.6, process600may include routing, based on causing the set of links to have the maintain LAG status, one or more packets to or from the consumer edge device via the set of links (block650). For example, the provider edge device may route, based on causing the set of links to have the maintain LAG status, one or more packets to or from the consumer edge device via the set of links, as described above.

As further shown inFIG.6, process600may include determining, after routing the one or more packets to or from the consumer edge device via the set of links, that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device (block660). For example, the provider edge device may determine, after routing the one or more packets to or from the consumer edge device via the set of links, that the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, as described above.

As further shown inFIG.6, process600may include causing, based on determining that provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, the set of links to cease having the maintain LAG status (block670). For example, the provider edge device may cause, based on determining that provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, the set of links to cease having the maintain LAG status, as described above.

Process600may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.

In a first implementation, the message is received by the provider edge device via a link that is associated with an Ethernet virtual private network (EVPN) and that is not included in the set of links.

In a second implementation, alone or in combination with the first implementation, processing the message to determine that the other provider edge device is not receiving LACPDUs from the consumer edge device includes processing the message to identify an Ethernet segment identifier (ESI) associated with another set of links of the other provider edge device and an LACPDU reception status of the other provider edge device, determining that the ESI associated with the other set of links matches an ESI of the set of links, and determining, after determining that the ESI associated with the other set of links matches the ESI of the set of links, that the other provider edge device is not receiving LACPDUs from the consumer edge device based on the LACPDU reception status of the other provider edge device.

In a third implementation, alone or in combination with one or more of the first and second implementations, causing the set of links to have the maintain LAG status includes determining, based on determining that the provider edge device is not receiving LACPDUs from the consumer edge device and determining that the other provider edge device is not receiving LACPDUs from the consumer edge device, that the consumer edge device is not sending LACPDUs, identifying, based on determining that the consumer edge device is not sending LACPDUs, an IP address of the provider edge device and an IP address of the other provider edge device, determining, based on the IP address of the provider edge device and the IP address of the other provider edge device, that the set of links are to be maintained, and updating an entry of a data structure associated with the LAG that indicates a status of the set of links to indicate the maintain LAG status for the set of links.

In a fourth implementation, alone or in combination with one or more of the first through third implementations, the provider edge device maintained the set of links according to an LACP before causing the set of links to have the maintain LAG status, and causing the set of links to have the maintain LAG status includes causing the set of links to cease being maintained by the provider edge device according to the LACP.

In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, causing the set of links to cease having the maintain LAG status includes causing the set of links to be maintained by the provider edge device according to an LACP.

AlthoughFIG.6shows example blocks of process600, in some implementations, process600may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG.6. Additionally, or alternatively, two or more of the blocks of process600may be performed in parallel.

FIG.7is a flowchart of an example process700associated with maintaining a set of links associated with a LAG to facilitate provisioning or updating of a customer edge device. In some implementations, one or more process blocks ofFIG.7may be performed by a provider edge device (e.g., provider edge device220). In some implementations, one or more process blocks ofFIG.7may be performed by another device or a group of devices separate from or including the provider edge device, such as a customer edge device (e.g., customer edge device210). Additionally, or alternatively, one or more process blocks ofFIG.5may be performed by one or more components of device300, such as processor320, memory330, storage component340, input component350, output component360, and/or communication component370; one or more components of device400, such as input component410, switching component420, output component430, and/or controller440; and/or the like.

As shown inFIG.7, process700may include determining that the provider edge device and another provider edge device are not receiving LACPDUs from a consumer edge device, wherein the provider edge device is connected to the consumer edge device via a first set of links of a LAG, and wherein the other provider edge device is connected to the consumer edge via a second set of links of the LAG (block710). For example, the provider edge device may determine that the provider edge device and another provider edge device are not receiving LACPDUs from a consumer edge device, wherein the provider edge device is connected to the consumer edge device via a first set of links of a LAG, and wherein the other provider edge device is connected to the consumer edge via a second set of links of the LAG, as described above.

As further shown inFIG.7, process700may include causing, based on determining that the provider edge device and the other provider edge device are not receiving LACPDUs from the consumer edge device, the first set of links to have a maintain LAG status (block720). For example, the provider edge device may cause, based on determining that the provider edge device and the other provider edge device are not receiving LACPDUs from the consumer edge device, the first set of links to have a maintain LAG status, as described above.

As further shown inFIG.7, process700may include determining, after causing the first set of links to have a maintain LAG status, that at least one of the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device (block730). For example, the provider edge device may determine, after causing the first set of links to have a maintain LAG status, that at least one of the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, as described above.

As further shown inFIG.7, process700may include causing, based on determining that at least one of the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, the first set of links to cease having the maintain LAG status (block740). For example, the provider edge device may cause, based on determining that at least one of the provider edge device or the other provider edge device is receiving LACPDUs from the consumer edge device, the first set of links to cease having the maintain LAG status, as described above.

Process700may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.

In a first implementation, determining that the provider edge device and the other provider edge device are not receiving LACPDUs from the consumer edge device includes determining that the provider edge device has not received an LACPDU from the consumer edge via the first set of links for at least a particular amount of time, determining that the particular amount of time is greater than an LACPDU time-out interval, receiving, from the other provider edge device, a message indicating a LACPDU reception status of the other provider edge device, and determining, based on the LACPDU reception status of the message and determining that the particular amount of time is greater than the LACPDU time-out interval, that the provider edge device and the other provider edge device are not receiving LACPDUs from the consumer edge device.

In a second implementation, alone or in combination with the first implementation, causing the first set of links to have the maintain LAG status includes identifying, based on determining that the provider edge device and the other provider edge device are not receiving LACPDUs from the consumer edge device, an IP address of the provider edge device and an IP address of the other provider edge device, determining, based on the IP address of the provider edge device and the IP address of the other provider edge device, that the first set of links are to be maintained and the second set of links are not to be maintained, and updating an entry of a data structure associated with the LAG that indicates a status of the first set of links to indicate the maintain LAG status for the set of links.

In a third implementation, alone or in combination with one or more of the first and second implementations, process700includes causing, after causing the first set of links to have the maintain LAG status and before causing the first set of links to cease having the maintain LAG status, the first set of links to be maintained between the provider edge device and the consumer edge device.

In a fourth implementation, alone or in combination with one or more of the first through third implementations, process700includes routing, after causing the first set of links to have the maintain LAG status and before causing the first set of links to cease having the maintain LAG status, one or more packets to or from the consumer edge device, wherein the one or more packets are associated with one or more file images for provisioning or updating the consumer edge device.

AlthoughFIG.7shows example blocks of process700, in some implementations, process700may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG.7. Additionally, or alternatively, two or more of the blocks of process700may be performed in parallel.

The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the implementations.

As used herein, traffic or content may include a set of packets. A packet may refer to a communication structure for communicating information, such as a protocol data unit (PDU), a service data unit (SDU), a network packet, a datagram, a segment, a message, a block, a frame (e.g., an Ethernet frame), a portion of any of the above, and/or another type of formatted or unformatted unit of data capable of being transmitted via a network.

As used herein, satisfying a threshold may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

As used herein, the term “component” is intended to be broadly construed as hardware, firmware, or a combination of hardware and software. It will be apparent that systems and/or methods described herein may be implemented in different forms of hardware, firmware, and/or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods are described herein without reference to specific software code—it being understood that software and hardware can be used to implement the systems and/or methods based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set. As used herein, a phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same item.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items), and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and/or,” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of”).