Ethernet tree (E-TREE) integrated routing and bridging (IRB) with egress link protection

Abstract

Embodiments of the present disclosure relate to an Ethernet tree (E-TREE) integrated routing and bridging (IRB) with egress link protection. The first leaf provider edge device may determine that the customer edge device is multihomed behind the first leaf provider edge device and the second leaf provider edge device. Based on determining that the customer edge device is multi-homed accessed, the first leaf provider edge device may create a protected path for a network address of the customer edge device through the second leaf provider edge device. The first leaf provider edge device may prevent traffic not received from the core network from being provided to the customer edge device through the protection path.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to Indian Provisional Patent Application No. 202441010895 and U.S. Patent Application No. 19 / 044,491, filed on February 16, 2024, and entitled “ETHERNET-TREE (E-TREE) INTEGRATED ROUTING AND BRIDGING (IRB) WITH EGRESS LINK PROTECTION,” the disclosures of which are considered part of and incorporated by reference into this patent application. Background Art

[0003] In a multipoint Ethernet service, the root node of a tree called an Ethernet tree (E-tree), customer stations (typically represented by attached circuits (ACs)) are labeled as either root stations or leaf stations. Customer stations can also be identified by media access control (MAC) addresses and virtual local area network (VLAN) tags. Summary of the Invention

[0004] Some embodiments described herein relate to a method. The method may include determining, by a first leaf provider edge device, that a customer edge device is multi-homed behind the first leaf provider edge device and a second leaf provider edge device. The method may include creating, via the second leaf provider edge device, a protection path for a network address of the customer edge device based on the determination that the customer edge device is multi-homed. The method may also include preventing traffic not received from a core network from being provided to the customer edge device via the protection path.

[0005] Some embodiments described herein relate to a first leaf provider edge device. The first leaf provider edge device may include one or more memories and one or more processors. The one or more processors may be configured to determine that a customer edge device is multi-homed behind the first leaf provider edge device and a second leaf provider edge device, and based on determining that the customer edge device is multi-homed, create a protection path for a network address of the customer edge device through the second leaf provider edge device. The one or more processors may be configured to prevent traffic that is not received from a core network from being provided to the customer edge device over the protection path, and enable Ethernet tree integrated routing and bridging to prevent leaf-to-leaf inter-subnet traffic.

[0006] Some embodiments described herein relate to a non-transitory computer-readable medium storing an instruction set. The instruction set, when executed by one or more processors of a first leaf provider edge device, can cause the first leaf provider edge device to: determine that a customer edge device is multi-homed behind the first leaf provider edge device and a second leaf provider edge device, and based on the determination that the customer edge device is multi-homed, create a protection path for a network address of the customer edge device through the second leaf provider edge device. The instruction set, when executed by one or more processors of the first leaf provider edge device, can cause the first leaf provider edge device to: prevent traffic not received from a core network from being provided to the customer edge device via the protection path, and enable Ethernet tree integrated routing and bridging with egress link protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figures 1A to 1D is an illustration of an example associated with providing Ethernet tree integrated routing and bridging with egress link protection.

[0008] Figure 2 is an illustration of an example environment in which the systems and / or methods described herein may be implemented.

[0009] Figure 3 and Figure 4 yes Figure 2 A diagram of example components of one or more devices in a .

[0010] Figure 5 is a flow chart of an example process for providing Ethernet tree integrated routing and bridging with egress link protection. DETAILED DESCRIPTION

[0011] The following detailed description of example implementations refers to the accompanying drawings, in which the same reference numerals in different drawings may identify the same or similar elements.

[0012] An Ethernet Virtual Private Network (EVPN) can allow a group of dispersed client sites (e.g., sites included in a VLAN) to connect using a data layer. An EVPN can include one or more Customer Edge (CE) devices that are connected to one or more Provider Edge (PE) devices. When a destination MAC is multi-homed to a Provider Edge device using a leaf Ethernet segment (ES), failover may need to be implemented in the event of an egress link failure. In one usage scenario, an Ethernet tree (E-tree) service can be set up in a network with leaf Provider Edge devices and a root Provider Edge device, and the Customer Edge device is multi-homed to a group of leaf Provider Edge devices. When traffic is transmitted from the root Provider Edge device to a Customer Edge device that is multi-homed to a leaf Provider Edge device, it is expected that the network can converge quickly when an egress link failure occurs. However, current technologies fail to provide such rapid convergence.

[0013] Current technology also fails to support E-tree integrated routing and bridging (IRB) and E-tree IRB with egress link protection. Egress link protection with fast failover is limited to E-LAN or EVPN E-trees for customer edge devices that are multi-homed to a root provider edge device. When the destination MAC is behind a leaf provider edge device that is multi-homed, E-tree egress link protection is not defined because E-tree inherently prevents leaf-to-leaf communication. E-tree IRB can enable the IRB to act as a root node when the leaf or root node is at the provider edge. However, in the case of leaf-to-leaf IRB, the leaf or root node attributes are lost after routing, and it is not possible to identify whether the traffic source has leaf or root node attributes after layer 3 routing.

[0014] Therefore, current technologies for providing E-tree services consume computing resources (e.g., processing resources, memory resources, communication resources, etc.), network resources, etc., which is associated with a failure to provide egress link protection when the destination device is located behind a multi-homed leaf provider edge device, loss of leaf node and root node attributes after routing, and a failure to identify whether the traffic source has leaf node or root node attributes. Furthermore, current technologies for providing E-tree services with root node behavior may result in long convergence times without egress link protection and may result in leaf-to-leaf node communication for inter-subnet traffic (communication that should be prevented based on E-tree rules).

[0015] Some embodiments described herein relate to a network that provides Ethernet tree integrated routing and bridging with egress link protection. For example, a first leaf provider edge device may determine that a customer edge device is multi-homed behind the first leaf provider edge device and a second leaf provider edge device. Based on determining that the customer edge device is multi-homed, the first leaf provider edge device may create a protection path for a network address of the customer edge device through the second leaf provider edge device. The first leaf provider edge device may prevent traffic that is not received from the core network from being provided to the customer edge device over the protection path. In some embodiments, the first leaf provider edge device may enable E-tree IRB to prevent leaf-to-leaf inter-subnet traffic and may enable E-tree IRB with egress link protection.

[0016] In this way, the network provides Ethernet tree integrated routing and bridging with egress link protection. For example, the network can provide egress link protection for fast convergence when the destination MAC is multi-homed to a leaf provider edge device, and can provide E-tree intra-subnet traffic with egress link protection while still blocking leaf-to-leaf communication for intra-subnet traffic. The network can provide EVPN E-tree IRB for inter-subnet traffic for leaf provider edge devices and root provider edge devices, and can resolve leaf-to-leaf scenarios while IRB has root node behavior. The network can also provide a combination of E-tree IRB and egress link protection support. Therefore, the network saves computing resources, network resources, etc., which would otherwise be consumed due to the failure to provide egress link protection when the destination device is located behind a leaf provider edge device that is multi-homed, the loss of leaf and root node attributes after routing, the failure to identify whether the traffic source has leaf or root node attributes, etc.

[0017] Figures 1A to 1D is a diagram of an example 100 associated with providing Ethernet tree integrated routing and bridging with egress link protection. Figures 1A to 1D As shown, example 100 includes a first customer edge device (CE1), a second customer edge device (CE2), a third customer edge device (CE3), a root provider edge device (R1), a first leaf provider edge device (L1), and a second leaf provider edge device (L2). The first customer edge device, the second customer edge device, the third customer edge device, the root provider edge device, the first leaf provider edge device, and the second leaf provider edge device can be as follows: Figures 1A to 1D Further details regarding the first customer edge device, the second customer edge device, the third customer edge device, the root provider edge device, the first leaf provider edge device, and the second leaf provider edge device are provided elsewhere herein.

[0018] Figure 1A Describes an example of providing egress link protection associated with traffic within a subnet. Figure 1A As shown, and by reference numeral 105, a first leaf provider edge device (L1) can determine that an access interface between the first leaf provider edge device (L1) and a second customer edge device (CE2) has failed (e.g., is inoperable). For example, the first leaf provider edge device (L1) can determine that the access interface has failed based on: link state detection (e.g., by a link layer protocol that detects the presence of a physical link), failure to receive a response to a keep-alive message within a specified time, a Simple Network Management Protocol (SNMP) indicating that the access interface has failed, a routing protocol indicating that the access interface has failed, etc.

[0019] like Figure 1A As further shown, and by reference numeral 110, the first leaf provider edge device (L1) can utilize egress link protection (ELP) to implement fast routing for traffic directed to the second customer edge device (CE2). For example, to utilize egress link protection, the first leaf provider edge device (L1) can relax prohibitions on leaf-to-leaf node communications for a protection path to implement a protection path between leaf provider edge devices (e.g., the first leaf provider edge device (L1) and the second leaf provider edge device (L2)) that share the same multi-homed access leaf Ethernet segment (ES).

[0020] like Figure 1A As further shown, and by reference numeral 115, to establish egress link protection for layer 2 traffic, the first leaf provider edge device (L1) may determine that a second customer edge device (CE2) is multi-homed behind the first leaf provider edge device (L1) and the second leaf provider edge device (L2). For example, each of the first leaf provider edge device (L1) and the second leaf provider edge device (L2) may utilize a link layer discovery protocol (LLDP) or other link state detection mechanism to determine whether there is an active link to the second customer edge device (CE2). The second customer edge device (CE2) may be configured with connections to the first leaf provider edge device (L1) and the second leaf provider edge device (L2). Each of the first leaf provider edge device (L1) and the second leaf provider edge device (L2) may perform link state detection and learn a MAC address of the second customer edge device (CE2) (e.g., a MAC2 address of 20.1.1.1 / 24). The first leaf provider edge device (L1) and the second leaf provider edge device (L2) may synchronize link status and routing information to confirm that the second customer edge device (CE2) is multi-homed.

[0021] like Figure 1AAs further shown, and by reference numeral 120, the first leaf provider edge device (L1) can create a protection path for the MAC2 address (20.1.1.1 / 24) of the second customer edge device (CE2). For example, the leaf provider edge device and the root provider edge device can share the same (multiple) routing targets. When the first leaf provider edge device (L1) determines that the second customer edge device (CE2) is multi-homed behind the first leaf provider edge device (L1) and the second leaf provider edge device (L2), the first leaf provider edge device (L1) can create a protection path for the MAC2 address of the second customer edge device (CE2). In some embodiments, the first leaf provider edge device (L1) can program the MAC2 address in the forwarding plane with a lower weight to point to the access interface (e.g., determined to have failed) and program the MAC2 address with a higher weight to point to the protection path.

[0022] In some embodiments, as Figure 1A As shown, when the first leaf provider edge device (L1) receives traffic destined for the second customer edge device (CE2) from the third customer edge device (C3), the first leaf provider edge device (L1) can use the protection path to provide the traffic to the second leaf provider edge device (L2). The second leaf provider edge device (L2) can provide the traffic to the second customer edge device (CE2).

[0023] like Figure 1A As further shown, and by reference numeral 125, the first leaf provider edge device (L1) can prevent traffic received from the first customer edge device (CE1) from being provided to the second customer edge device (CE2) via a protection path. For example, only known unicast traffic (e.g., traffic received from the core network) can utilize the protection path in the event of a failure of the egress link to the second customer edge device (CE2). Because the MAC2 address is installed with the leaf node attribute, local switching from leaf node to leaf node may not be performed on the first leaf provider edge device (L1). Therefore, traffic received from the first customer edge device (CE1) can be prevented from being provided to the second customer edge device (CE2) via the protection path or local link.

[0024] Figure 1B An example of providing inter-subnet traffic with E-tree IRB is described, where the root PE device (R1) is the third leaf PE device (L3). Figure 1B, if E-tree is required for IRB, only root nodes or leaf nodes per provider edge device range may be allowed. When the provider edge device is a leaf provider edge device or a root provider edge device, E-tree IRB is supported as follows. IRB can act as a root node role and perform layer 3 routing regardless of whether the provider edge device is a leaf node or a root node. Since the layer 2 root node / leaf node attributes are lost after layer 3 routing, there is a backdoor for inter-subnet traffic from leaf node to leaf node. The first leaf provider edge device (L1) can provide inter-subnet routing for a destination MAC with root node attributes or a destination address outside the EVPN network. This opens a backdoor for inter-subnet communication from a local or remote leaf customer edge device to another leaf customer edge device.

[0025] For example, for inter-subnet traffic sent from the first customer edge device (CE1) to the second customer edge device (CE2), and after layer 3 routing, the first leaf provider edge device (L1) can forward it to the MAC2 address of the second customer edge device (CE2) based on the next hop used by the MAC2 address. In addition, for inter-subnet traffic sent from the third customer edge device (CE3) to the second customer edge device (CE2), and after layer 3 routing, the first leaf provider edge device (L1) can forward it to the MAC2 address of the second customer edge device (CE2) based on the next hop used by the MAC2 address. Figure 1B As shown and referenced by numeral 130, this may result in leaf-to-leaf inter-subnet forwarding, which should be prevented.

[0026] Figure 1C An example of providing inter-subnet traffic with E-tree IRB is further described, where the root PE device (R1) is replaced by a third leaf PE device (L3). Figure 1C As shown and indicated by reference numeral 135, the first leaf provider edge device (L1) may install the MAC2 address in the forwarding plane for the bridge domain to which the MAC2 address belongs. For example, to support E-tree IRB and prevent leaf-to-leaf inter-subnet traffic, the first leaf provider edge device (L1) may install the MAC2 address of the second customer edge device (CE2) in the forwarding plane for the bridge domain to which the MAC2 address belongs.

[0027] like Figure 1CAs further shown, and by reference numeral 140, the first leaf provider edge device (L1) can install a host Internet Protocol (IP) address (e.g., an IP version 4 address or an IP version 6 address) associated with the MAC2 address in the forwarding plane based on a root node attribute or a leaf node attribute. For example, the first leaf provider edge device (L1) can install a host IP address associated with the MAC2 address in the forwarding plane based on a root node attribute or a leaf node attribute associated with an EVPN type 2 (T2) route for the destination MAC / IP address. If the MAC2 address has a root node attribute, the next hop associated with the IP host route can remain unchanged. When the first leaf provider edge device (L1) learns a MAC / IP binding for a MAC behind a second leaf provider edge device (L2) having a leaf node attribute, the next hop can be associated with a discarded next hop (e.g., an IP host route for a second customer edge device (CE2) can be associated with a discarded next hop). As Figure 1C As shown, this may prevent the first leaf provider edge device (L1) from forwarding traffic received from the first customer edge device (CE1) to the second customer edge device (CE2).

[0028] like Figure 1C As further shown, and by reference numeral 145, the third leaf provider edge device (L3) can install the MAC2 address in the forwarding plane for the bridge domain to which the MAC2 address belongs. For example, if the third leaf provider edge device (L3), as a remote leaf provider edge device, learns the MAC to IP binding for the second customer edge device (CE2), the third leaf provider edge device (L3) can perform the same function as the first leaf provider edge device (L1) due to the leaf node attribute of the MAC2 address. To support E-tree IRB and prevent leaf-to-leaf inter-subnet traffic, the third leaf provider edge device (L3) can install the MAC2 address of the second customer edge device (CE2) in the forwarding plane for the bridge domain to which the MAC2 address belongs.

[0029] like Figure 1CAs further shown, and by reference numeral 150, the third leaf provider edge device (L3) can install a host IP address associated with the MAC2 address in the forwarding plane based on a root node attribute or a leaf node attribute. For example, the third leaf provider edge device (L3) can install a host IP address associated with the MAC2 address in the forwarding plane based on a root node attribute or a leaf node attribute associated with a T2 route for the destination MAC / IP address. If the MAC2 address has a root node attribute, the next hop associated with the IP host route may not change. When the third leaf provider edge device (L3) learns a MAC / IP binding for a MAC behind a second leaf provider edge device (L2) having a leaf node attribute, the next hop may be associated with a discarded next hop (e.g., an IP host route for a second customer edge device (CE2) may be associated with a discarded next hop). As Figure 1C As shown, this may prevent the third leaf provider edge device (L3) from forwarding traffic received from the third customer edge device (CE3) to the second customer edge device (CE2).

[0030] Figure 1D An example of providing egress link protection with E-tree IRB for a customer edge device that is multi-homed to a leaf provider edge device is described. Figure 1D As shown, and by reference numeral 155, the first leaf provider edge device (L1) can create a protection path for a MAC2 address. For example, when the first leaf provider edge device (L1) determines that a second customer edge device (CE2) is multi-homed behind the first leaf provider edge device (L1) and the second leaf provider edge device (L2), the first leaf provider edge device (L1) can create a protection path for the MAC2 address of the second customer edge device (CE2). In some embodiments, the first leaf provider edge device (L1) can program the MAC2 address in the forwarding plane with a lower weight to point to the access interface (e.g., determined to have failed) and program the MAC2 address with a higher weight to point to the protection path.

[0031] like Figure 1DAs further shown, and by reference numeral 160, the first leaf provider edge device (L1) can install a host IP address associated with the MAC2 address in the forwarding plane based on a root node attribute or a leaf node attribute. For example, to prevent leaf-to-leaf "backdoor" inter-subnet traffic, the first leaf provider edge device (L1) can install a host IP address associated with the MAC2 address in the forwarding plane based on a root node attribute or a leaf node attribute associated with an EVPN T2 route for the destination MAC / IP address. If the MAC2 address has the root node attribute, the next hop associated with the IP host route can remain unchanged. When the first leaf provider edge device (L1) learns an address MAC / IP binding for a MAC behind a second leaf provider edge device (L2) having the leaf node attribute, the next hop can be associated with a discarded next hop (e.g., an IP host route for a second customer edge device (CE2) can be associated with a discarded next hop).

[0032] like Figure 1D As further shown and indicated by reference numeral 165, the root provider edge device (R1) can perform asymmetric routing based on EVPN T2 routing. For example, to provide the root provider edge device (R1) with IRB egress link protection support, the root provider edge device (R1) can perform asymmetric routing based on EVPN T2 routing, thereby eliminating the need for layer 3 routing for inter-subnet traffic on the first leaf provider edge device (L1).

[0033] like Figure 1D As further shown, and by reference numeral 170, the first leaf provider edge device (L1) can perform egress link protection for a second multi-homed customer edge device (CE2) for asymmetric inter-subnet traffic from another ingress provider edge device. For example, when asymmetric traffic reaches the first leaf provider edge device (L1) through a bridge domain, the first leaf provider edge device (L1) can perform egress link protection support for the second multi-homed customer edge device (CE2) in the bridge domain to which the second customer edge device (CE2) belongs. The first leaf provider edge device (L1) can use asymmetric routing for the EVPN network (e.g., no type 5 advertisements for host addresses belonging to the EVPN network; and no EVPN type 2 symmetric route advertisements). Therefore, as Figure 1D As shown, when the first leaf provider edge device (L1) receives traffic destined for the first customer edge device (CE1) from the third customer edge device (CE3), the first leaf provider edge device (L1) can provide the traffic to the second leaf provider edge device (L2) through the protection path. The second leaf provider edge device (L2) can provide the traffic to the first customer edge device (CE1).

[0034] In this way, the network provides Ethernet tree integrated routing and bridging with egress link protection. For example, the network can provide egress link protection for fast convergence when the destination MAC is multi-homed to a leaf provider edge device, and can provide E-tree intra-subnet traffic with egress link protection while still blocking leaf-to-leaf communication for intra-subnet traffic. The network can provide EVPN E-tree IRB for inter-subnet traffic for leaf provider edge devices and root provider edge devices, and can address leaf-to-leaf scenarios while IRB has root node behavior. The network can also provide a combination of E-tree IRB and egress link protection support. Therefore, the network saves computing resources, network resources, etc., which would otherwise be consumed due to the failure to provide egress link protection when the destination device is located behind a leaf provider edge device that is multi-homed, the loss of leaf and root node attributes after routing, the failure to identify whether the traffic source has leaf or root node attributes, etc.

[0035] As mentioned above, Figures 1A to 1D Provided as an example. Other examples may be related to Figures 1A to 1D Different than described. Figures 1A to 1D The number and arrangement of devices shown in FIG are provided as examples. In practice, there may be additional devices, fewer devices, different devices, or Figures 1A to 1D The equipment shown in the figure is arranged differently. Figures 1A to 1D Two or more of the devices shown in the figure may be implemented in a single device, or Figures 1A to 1D The single device shown in can be implemented as multiple distributed devices. Additionally or alternatively, Figures 1A to 1D The set of devices (e.g., one or more devices) shown in FIG can perform the operations described as being performed by Figures 1A to 1D One or more functions performed by another set of devices shown in .

[0036] Figure 2 is an illustration of an example environment 200 in which the systems and / or methods described herein may be implemented. Figure 2 As shown, environment 200 may include a customer edge device 210, a set of network devices 220 (shown as network devices 220-1 through 220-N), and a network 230. Network devices 220 may correspond to Figures 1A to 1D The root provider edge device and the leaf provider edge device are shown in FIG. The devices in environment 200 can be interconnected through wired connections, wireless connections, or a combination of wired and wireless connections.

[0037] The customer edge device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information (such as the information described herein). For example, the customer edge device 210 may include a mobile phone (e.g., a smartphone or a radio phone), a laptop, a tablet computer, a desktop computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart watch, a pair of smart glasses, a heart rate monitor, a fitness tracker, smart clothing, smart jewelry, or a head-mounted display), a network device, a server device, a group of server devices, or similar types of devices. In some embodiments, the customer edge device 210 can receive network traffic from other customer edge devices 210 and / or provide network traffic to other customer edge devices 210 via the network 230 (e.g., by using the network device 220 as an intermediary to route data packets).

[0038] The network device 220 includes one or more devices that can receive, process, store, route and / or provide traffic (e.g., data packets or other information or metadata) in the manner described herein. For example, the network device 220 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router or a provider core router), a virtual router, a route reflector, a regional border router, or other types of routers. Additionally or alternatively, the network device 220 may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, or a data center server), a load balancer, and / or similar devices. In some embodiments, the network device 220 may be a physical device implemented in a housing (such as a chassis). In some embodiments, the network device 220 may be a virtual device implemented by one or more computer devices in a cloud computing environment or a data center. In some embodiments, a group of network devices 220 may be a group of data center nodes for routing traffic flows through the network 230.

[0039] The network 230 includes one or more wired and / or wireless networks. For example, the network 230 may include a packet-switched network, a cellular network (e.g., a fifth-generation (5G) network, a fourth-generation (4G) network (such as a Long Term Evolution (LTE) network), a third-generation (3G) network, a code division multiple access (CDMA) network, 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., a public switched telephone network (PSTN)), 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 combinations of these or other types of networks.

[0040] Figure 2The number and arrangement of devices and networks shown in the FIGURES are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or different Figure 2 The devices shown are arranged in different devices and / or networks. Figure 2 Two or more of the devices shown in the figure may be implemented in a single device, or Figure 2 The single device shown in FIG200 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) in environment 200 may perform one or more functions described as being performed by another set of devices in environment 200.

[0041] Figure 3 yes Figure 2 300. The example components may be included in a device 300, which may correspond to a customer edge device 210 and / or a network device 220. In some embodiments, a customer edge device 210 and / or a network device 220 may include one or more devices 300 and / or one or more components of a device 300. Figure 3 As shown, device 300 may include a bus 310 , a processor 320 , a memory 330 , an input component 340 , an output component 350 , and a communication interface 360 .

[0042] The bus 310 includes one or more components that enable wired and / or wireless communication between components of the device 300. The bus 310 may be coupled to the device 300, such as by operative coupling, communicative coupling, electronic coupling, and / or electrical coupling. Figure 3 The processor 320 includes a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a controller, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or other types of processing components. The processor 320 can be implemented in hardware, firmware, or a combination of hardware and software. In some embodiments, the processor 320 includes one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0043] Memory 330 includes volatile memory and / or non-volatile memory. For example, memory 330 may include random access memory (RAM), read-only memory (ROM), a hard drive and / or other types of memory (e.g., flash memory, magnetic memory and / or optical memory). Memory 330 may include internal memory (e.g., RAM, ROM or hard drive) and / or removable memory (e.g., removable via a universal serial bus connection). Memory 330 may be a non-transient computer-readable medium. Memory 330 stores information, instructions and / or software (e.g., one or more software applications) related to the operation of device 300. In some embodiments, memory 330 includes one or more memories coupled to one or more processors (e.g., processor 320) (such as via bus 310).

[0044] Input components 340 enable device 300 to receive input (such as user input and / or sensory input). For example, input components 340 may include a touch screen, a keyboard, keys, a mouse, buttons, a microphone, a switch, a sensor, a global positioning system sensor, an accelerometer, a gyroscope, and / or an actuator. Output components 350 enable device 300 to provide output (such as through a display, a speaker, and / or a light-emitting diode). Communication interface 360 enables device 300 to communicate with other devices via wired and / or wireless connections. For example, communication interface 360 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and / or an antenna.

[0045] The device 300 can perform one or more operations or processes described herein. For example, a non-transient computer-readable medium (e.g., memory 330) can store an instruction set (e.g., one or more instructions or codes) for execution by the processor 320. The processor 320 can execute the instruction set to perform one or more operations or processes described herein. In some embodiments, the execution of the instruction set by one or more processors 320 causes one or more processors 320 and / or the device 300 to perform one or more operations or processes described herein. In some embodiments, hard-wired circuits can be used instead of instructions or together with instructions to perform one or more operations or processes described herein. Additionally or alternatively, the processor 320 can be configured to perform one or more operations or processes described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware circuits and software.

[0046] Figure 3 The number and arrangement of components shown in FIG are provided as examples. Device 300 may include additional components, fewer components, different components, or components that are different from those in FIG. Figure 3Additionally or alternatively, a set of components (eg, one or more components) of device 300 may perform one or more functions described as being performed by another set of components of device 300.

[0047] Figure 4 yes Figure 2 4. The example components may be included in device 400. Device 400 may correspond to network device 220. In some embodiments, network device 220 may include one or more devices 400 and / or one or more components of device 400. Figure 4 As shown, the device 400 may include one or more input components 410-1 to 410-B (B≥1) (hereinafter collectively referred to as input component 410, individually referred to as input component 410), a switching component 420, one or more output components 430-1 to 430-C (C≥1) (hereinafter collectively referred to as output component 430, individually referred to as output component 430), and a controller 440.

[0048] The input component 410 can be one or more attachment points for a physical link and can be one or more entry points for incoming traffic (such as data packets). The input component 410 can process the incoming traffic (such as by performing data link layer encapsulation or decapsulation). In some embodiments, the input component 410 can transmit and / or receive data packets. In some embodiments, the input component 410 can include an input line card that includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more interface cards (IFCs), a packet forwarding component, a line card controller component, an input port, a processor, a memory, and / or an input queue. In some embodiments, the device 400 may include one or more input components 410.

[0049] The switch component 420 can interconnect the input component 410 with the output component 430. In some embodiments, the switch component 420 can be implemented via one or more crossbar switches, buses, and / or shared memory. The shared memory can act as a temporary buffer to store data packets from the input component 410 before the data packets are ultimately dispatched to the output component 430. In some embodiments, the switch component 420 can enable communication between the input component 410, the output component 430, and / or the controller 440.

[0050] The output component 430 can store data packets and can schedule data packets for transmission on the output physical link. The output component 430 can support data link layer encapsulation or decapsulation, and / or support multiple higher-level protocols. In some embodiments, the output component 430 can transmit data packets and / or receive data packets. In some embodiments, the output component 430 can include an output line card that includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memory, and / or output queues. In some embodiments, the device 400 can include one or more output components 430. In some embodiments, the input component 410 and the output component 430 can be implemented by the same set of components (e.g., the input / output component can be a combination of the input component 410 and the output component 430).

[0051] The controller 440 includes a processor in the form of a CPU, a GPU, an APU, a microprocessor, a microcontroller, a DSP, an FPGA, an ASIC, and / or other types of processors. The processor can be implemented in hardware, firmware, or a combination of hardware and software. In some embodiments, the controller 440 may include one or more processors that can be programmed to perform a function.

[0052] In some embodiments, the controller 440 may include RAM, ROM, and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, optical memory, etc.) that store information and / or instructions for use by the controller 440.

[0053] In some embodiments, the controller 440 can communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about the network topology. The controller 440 can create a routing table based on the network topology information, can create a forwarding table based on the routing table, and can forward the forwarding table to the input component 410 and / or the output component 430. The input component 410 and / or the output component 430 can use the forwarding table to perform route lookups for incoming and / or outgoing data packets.

[0054] Controller 440 can perform one or more of the processes described herein. Controller 440 can perform these processes in response to executing software instructions stored on 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 distributed across multiple physical storage devices.

[0055] The software instructions may be read from another computer-readable medium or from another device via a communication interface into a memory and / or storage component associated with the controller 440. When executed, the software instructions stored in the memory and / or storage component associated with the controller 440 may cause the controller 440 to 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, the embodiments described herein are not limited to any particular combination of hardware circuitry and software.

[0056] Figure 4 The number and arrangement of components shown in FIG are provided as examples. In practice, device 400 may include additional components, fewer components, different components, or components that are different from those in FIG. Figure 4 Additionally or alternatively, a set of components (eg, one or more components) of device 400 may perform one or more functions described as being performed by another set of components of device 400.

[0057] Figure 5 is a flow chart of an example process 500 for providing Ethernet tree integrated routing and bridging with egress link protection. In some embodiments, Figure 5 One or more of the process blocks in can be executed by a network device (e.g., network device 220). In some embodiments, Figure 5 One or more of the process blocks in can be performed by another device or device group that is separate from or includes the network device, such as a customer edge device (e.g., customer edge device 210) and / or another network device (e.g., network device 220). Additionally or alternatively, Figure 5 One or more of the process blocks in can be performed by one or more components of the device 300, such as the processor 320, the memory 330, the input component 340, the output component 350 and / or the communication interface 360. Additionally or alternatively, Figure 5 One or more blocks in FIG. 4 may be performed by one or more components of device 400 , such as input component 410 , switch component 420 , output component 430 , and / or controller 440 .

[0058] In some embodiments, process 500 may involve customer devices having either IPv4 or IPv6 or both IPv4 and IPv6 host addresses. For integrated routing and bridging (IRB) egress link protection support, process 500 may use asymmetric IRB routing for inter-subnet traffic in a network. The process 500 may be applied assuming that all customer edge devices attached to an EVPN network device have either root node attributes or leaf node attributes, rather than a hybrid of root node or leaf node attributes. Asymmetric IRB routing may be applied to an ingress network device. After layer 3 routing at the ingress network device, if the destination IP host address does not point to a drop (e.g., next hop), traffic may be forwarded to the egress network device via layer 2 EVPN. Additionally, asymmetric IRB routing may be applied on the ingress network device.

[0059] like Figure 5 As shown, process 500 may include determining that a customer edge device is multi-homed behind a first leaf provider edge device and a second leaf provider edge device (block 510). For example, the first leaf provider edge device may determine that the customer edge device is multi-homed behind the first leaf provider edge device and the second leaf provider edge device, as described above. In some embodiments, determining that the customer edge device is multi-homed behind the first leaf provider edge device and the second leaf provider edge device includes synchronizing link state and routing information with the second leaf provider edge device, and determining that the customer edge device is multi-homed based on synchronizing the link state and routing information with the second leaf provider edge device.

[0060] like Figure 5 As further shown, process 500 may include: based on determining that the customer edge device is multi-homed, creating a protection path for the network address of the customer edge device and through the second leaf provider edge device (block 520). For example, the first leaf provider edge device may create a protection path for the network address of the customer edge device and through the second leaf provider edge device based on determining that the customer edge device is multi-homed, as described above. In some embodiments, creating the protection path for the network address of the customer edge device includes: programming the network address in a forwarding plane between the first leaf provider edge device and the customer edge device to point to an access interface with a first weight; and programming the network address in the forwarding plane to point to the protection path with a second weight, wherein the second weight is greater than the first weight.

[0061] like Figure 5 As further shown, process 500 may include preventing traffic not received from the core network from being provided to the customer edge device via the protection path (block 530). For example, the first leaf provider edge device may prevent traffic not received from the core network from being provided to the customer edge device via the protection path, as described above.

[0062] In some embodiments, process 500 includes determining that an access interface between a first leaf provider edge device and a customer edge device is inoperable; receiving traffic from a core network; and providing the traffic to the customer edge device via a protection path and a second leaf provider edge device based on determining that the access interface between the first leaf provider edge device and the customer edge device is inoperable.

[0063] In some embodiments, process 500 includes: detecting an egress link failure to a customer edge device; and based on detecting the egress link failure to the customer edge device, allowing traffic received from a core network to be provided to the customer edge device via a protection path. In some embodiments, process 500 includes: enabling Ethernet tree integrated routing and bridging to prevent leaf-to-leaf inter-subnet traffic. In some embodiments, process 500 includes: enabling Ethernet tree integrated routing and bridging with egress link protection.

[0064] In some embodiments, process 500 includes: installing a network address of a customer edge device in a forwarding plane for a bridge domain to which the network address belongs; and installing a host Internet Protocol (IP) address associated with the network address in the forwarding plane based on a root node attribute or a leaf node attribute. In some embodiments, process 500 includes: maintaining a next hop associated with the IP host address when the network address is associated with the root node attribute. In some embodiments, process 500 includes: associating the next hop associated with the IP host address with a discarded next hop when the network address is associated with the leaf node attribute. In some embodiments, process 500 includes: preventing traffic not received from the core network from being provided to the customer edge device based on installing the network address and the host IP address in the forwarding plane.

[0065] In some embodiments, process 500 includes: determining that an access interface between a first leaf provider edge device and another customer edge device is inoperable; receiving traffic from a core network; and providing the traffic to the other customer edge device via a protection path and a second leaf provider edge device based on determining that the access interface between the first leaf provider edge device and the other customer edge device is inoperable. In some embodiments, process 500 includes: performing egress link protection for asymmetric traffic for a multi-homed customer edge device.

[0066] although Figure 5 Example blocks of process 500 are shown, but in some implementations, process 500 may include additional blocks, fewer blocks, different blocks, or different Figure 5 The blocks shown in FIG500 are arranged differently. Additionally or alternatively, two or more blocks in process 500 can be performed in parallel.

[0067] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications may be made in light of the above disclosure or may be acquired from practice of the embodiments.

[0068] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. It is apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code - it should be understood that both software and hardware can be used to implement the systems and / or methods based on the description herein.

[0069] Although 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 the various embodiments. In fact, many of these features can be combined in ways not explicitly 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 the various embodiments includes the combination of each dependent claim with every other claim in the claim set.

[0070] Unless explicitly described, any element, action or instruction used in this article should not be interpreted as key or necessary. In addition, as used herein, the articles "one" and "an" are intended to include one or more projects and can be used interchangeably with "one or more". In addition, as used herein, the article "the" is intended to include one or more projects referenced in connection with the article "the" and can be used interchangeably with "one or more". In addition, as used herein, the term "set" is intended to include one or more projects (e.g., related projects, unrelated projects, combinations of related and unrelated projects, etc.) and can be used interchangeably with "one or more". When referring to only one project, the phrase "only one" or similar language is used. In addition, as used herein, the terms "having", "having", "with", etc. are intended to be open terms. In addition, unless otherwise expressly stated, the phrase "based on" is intended to represent "at least partially based on". In addition, as used herein, the term "or" is intended to be inclusive when used in a series and can be used interchangeably with "and / or", unless otherwise expressly stated (e.g., if used in combination with "either" or "only one").

[0071] In the foregoing description, various exemplary embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes may be made thereto, and that additional embodiments may be implemented, without departing from the broader scope of the present invention as set forth in the claims. The description and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method comprising: determining, by the first leaf provider edge device, that a customer edge device is multi-homed behind the first leaf provider edge device and a second leaf provider edge device; The first leaf provider edge device, based on determining that the customer edge device is multi-homed, creates a protection path for the network address of the customer edge device through the second leaf provider edge device; as well as Traffic that is not received from a core network is prevented by the first leaf provider edge device from being provided to the customer edge device over the protection path.

2. The method according to claim 1, further comprising: determining that an access interface between the first leaf provider edge device and the customer edge device is inoperable; Receive traffic from the core network; as well as Based on determining that the access interface between the first leaf provider edge device and the customer edge device is inoperable, the traffic is provided to the customer edge device through the protection path and the second leaf provider edge device.

3. The method of claim 1 , wherein determining that the customer edge device is multi-homed behind the first leaf provider edge device and the second leaf provider edge device comprises: synchronizing link state and routing information with the second leaf provider edge device; as well as Based on synchronizing the link status and the routing information with the second leaf provider edge device, it is determined that the customer edge device is multi-homed.

4. The method of claim 1 , wherein creating the protection path for the network address of the customer edge device comprises: programming the network address to point to an access interface between the first leaf provider edge device and the customer edge device in a forwarding plane with a first weight; as well as programming the network address in the forwarding plane to point to the protection path with a second weight, The second weight is greater than the first weight.

5. The method according to claim 1, further comprising: detecting an egress link failure to the customer edge device; as well as Based on detecting the egress link failure to the customer edge device, traffic received from the core network is allowed to be provided to the customer edge device over the protection path.

6. The method according to claim 1, further comprising: Enable Ethernet tree integrated routing and bridging to prevent leaf-to-leaf inter-subnet traffic.

7. The method according to claim 1, further comprising: Enables Ethernet tree integrated routing and bridging with egress link protection.

8. First leaf provider edge equipment, including: one or more memories; as well as One or more processors for: determining that a customer edge device is multi-homed behind the first leaf provider edge device and the second leaf provider edge device; creating, based on determining that the customer edge device is multi-homed, a protection path for the network address of the customer edge device through the second leaf provider edge device; preventing traffic not received from the core network from being provided to the customer edge device via the protection path; and Enable Ethernet tree integrated routing and bridging to prevent leaf-to-leaf inter-subnet traffic.

9. The first leaf provider edge device of claim 8, wherein the one or more processors are further configured to: installing the network address of the customer edge device in a forwarding plane for the bridge domain to which the network address belongs; and A host Internet Protocol (IP) address associated with the network address is installed in the forwarding plane based on a root node attribute or a leaf node attribute.

10. The first leaf provider edge device of claim 9, wherein the one or more processors are further configured to: When the network address is associated with the root node attribute, a next hop associated with the IP host address is maintained.

11. The first leaf provider edge device of claim 9, wherein the one or more processors are further configured to: When the network address bound to the IP host address is associated with the leaf node attribute, the next hop associated with the IP host address is associated with a discarded next hop.

12. The first leaf provider edge device of claim 9, wherein the one or more processors are further configured to: Based on installing the host IP address in the forwarding plane, traffic not received from the core network is prevented from being provided to the customer edge device.

13. The first leaf provider edge device of claim 8, wherein the one or more processors are further configured to: determining that an access interface between the first leaf provider edge device and another customer edge device is inoperable; Receive traffic from the core network; and Based on determining that the access interface between the first leaf provider edge device and the another customer edge device is inoperable, providing the traffic to the another customer edge device through the protection path and the second leaf provider edge device.

14. The first leaf provider edge device of claim 8, wherein the one or more processors are further configured to: For the multi-homed customer edge device, egress link protection is performed for asymmetric traffic.

15. A non-transitory computer-readable medium storing an instruction set, the instruction set comprising: One or more instructions that, when executed by one or more processors of a first leaf provider edge device, cause the first leaf provider edge device to: determining that a customer edge device is multi-homed behind the first leaf provider edge device and the second leaf provider edge device; creating, based on determining that the customer edge device is multi-homed, a protection path for the network address of the customer edge device through the second leaf provider edge device; preventing traffic not received from the core network from being provided to the customer edge device via the protection path; as well as Enables Ethernet tree integrated routing and bridging with egress link protection.

16. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the first leaf provider edge device to: determining that an access interface between the first leaf provider edge device and the customer edge device is inoperable; Receive traffic from the core network; and Based on determining that the access interface between the first leaf provider edge device and the customer edge device is inoperable, the traffic is provided to the customer edge device through the protection path and the second leaf provider edge device.

17. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions that cause the first leaf provider edge device to determine that the customer edge device is multi-homed behind the first leaf provider edge device and the second leaf provider edge device cause the first leaf provider edge device to: synchronizing link state and routing information with the second leaf provider edge device; and Based on synchronizing the link status and the routing information with the second leaf provider edge device, it is determined that the customer edge device is multi-homed.

18. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions that cause the first leaf provider edge device to create the protection path for the network address of the customer edge device cause the first leaf provider edge device to: programming the network address to point to an access interface between the first leaf provider edge device and the customer edge device in a forwarding plane with a first weight; and programming the network address in the forwarding plane to point to the protection path with a second weight, The second weight is greater than the first weight.

19. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the first leaf provider edge device to: detecting an egress link failure to the customer edge device; and Based on detecting the egress link failure to the customer edge device, traffic received from the core network is allowed to be provided to the customer edge device over the protection path.

20. The non-transitory computer readable medium of claim 15, wherein the Ethernet tree integrated routing and bridging prevents leaf-to-leaf inter-subnet traffic.

Images