Patent Application
20240356838
Ethernet Virtual Private Tree (E-TREE), or rooted point-to-multipoint Ethernet Virtual Connection (EVC), is a Layer 2 service defined by the Metro-Ethernet Forum (MEF) that provides an Ethernet virtual local area network (VLAN) configuration suitable for multicast services. Illustratively, the Internet Engineering Task Force (IETF) Internet Draft entitled “Requirements for MEF E-Tree Support in VPLS″<draft-ietf-l2vpn-etree-reqt> by Key et al. specifies the requirements for supporting MEF E-TREE service in layer-2 virtual private network (L2VPN). Other types of EVCs defined for Carrier Ethernet networking are the E-Line and E-LAN.
To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.
Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure. Thus, the following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure can be references to the same embodiment or any embodiment; and such references mean at least one of the embodiments.
Reference to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others.
The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Alternative language and synonyms may be used for any one or more of the terms discussed herein, and no special significance should be placed upon whether or not a term is elaborated or discussed herein. In some cases, synonyms for certain terms are provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any terms discussed herein is illustrative only and is not intended to further limit the scope and meaning of the disclosure or of any example term. Likewise, the disclosure is not limited to various embodiments given in this specification.
For clarity of explanation, in some instances, the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.
Any of the steps, operations, functions, or processes described herein may be performed or implemented by a combination of hardware and software services or services, alone or in combination with other devices. In some embodiments, a service can be software that resides in memory of a client device and/or one or more servers of a content management system and perform one or more functions when a processor executes the software associated with the service. In some embodiments, a service is a program or a collection of programs that carry out a specific function. In some embodiments, a service can be considered a server. The memory can be a non-transitory computer-readable medium.
In some embodiments, the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer-readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The executable computer instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, solid-state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include servers, laptops, smartphones, small form factor personal computers, personal digital assistants, and so on. The functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
Without intent to limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the embodiments of the present disclosure are given below. Note that titles or subtitles may be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, technical and scientific terms used herein have the meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, the present document, including definitions will control.
Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
One or more aspects of the present disclosure are directed to dynamic ingress and egress filtering of Broadcast, Unknown Unicast, and Multicast (BUM) traffic in an interconnected network of Ethernet Virtual Private Networks (EVPN). Each EVPN in this inter-connected network may have a Provider Edge (PE) that can dynamically determine whether to perform ingress filtering, at the PE, of network traffic received at the PE from one or more end terminals (nodes) connected to the PE or to forward the network traffic for egress filtering at another PE associated with an end terminal (node) to which the network traffic is destined. The decision as to whether a PE is to perform ingress filtering or should forward traffic to other PEs for egress filtering can dynamically change depending on the status of nodes connected to each PE (i.e., root node or leaf node). As will be described below, effective implementation of this dynamic filtering is premised on (1) each PE accurately advertising routes (e.g., Inclusive Multicast Ethernet Tag (IMET) routes) associated therewith; and (2) route advertisements received from other PEs in the network.
In one aspect, a method includes receiving, at a first Provider Edge (PE) of a first Ethernet Virtual Private Network (EVPN) in an inter-connected network of EVPNs, one or more of information on status of one or more nodes connected to the first PE, the one or more nodes being one of a leaf node or a root node; and a respective advertisement message from one or more second PEs of one or more second EVPNs in the inter-connected network of EVPNs. The method further includes performing, at the first PE, one or more of: generating, based on the information, a route advertisement message indicative of the status of the one or more nodes connected to the first PE, wherein the route advertisement message is shared with one or more second PEs; and based on the respective advertisement message received from each of the one or more second PEs, dynamically adjust configurations at the first PE, to perform ingress filtering or egress filtering of Broadcast, Unknown Unicast, and Multicast (BUM) traffic received at the first PE.
In another aspect, the method further includes generating a first flood list, the first flood list encompassing all PEs in the inter-connected network of EVPNs; and generating a second flood list, the second flood list excluding any of the one or more second PEs with only a leaf indication included in the respective advertisement message received therefrom.
In another aspect, the method further includes receiving the BUM traffic, at the first PE, from the leaf node attached to the first PE; and performing ingress filtering of the BUM traffic received at first PE from the leaf node to prevent the BUM traffic from being sent to the any of the one or more second PEs with only the leaf indication.
In another aspect, the ingress filtering includes sending the BUM traffic to all PEs included in the second flood list.
In another aspect, the BUM traffic is sent to all PEs in the second flood list with a leaf VxLAN Network Identifier (VNI) identifying the BUM traffic as being from a leaf node, the leaf VNI enabling a receiving PE from among the one or more second PEs to perform egress filtering prior to sending the BUM traffic to a leaf node associated with the receiving PE.
In another aspect, the method further includes receiving the BUM traffic, at the first PE, from one of the one or more second PEs; and determining whether to perform egress filtering of the BUM traffic based on a VxLAN Network Identifier (VNI) associated with the BUM traffic.
In another aspect, the first PE performs egress filtering of the BUM traffic if the VNI associated with the BUM traffic identifies the BUM traffic as originating from a leaf node attached to the one of the one or more second PEs from which the BUM traffic is received, and one of the one or more nodes is the leaf node.
In one aspect, an inter-connected network of Ethernet Virtual Private Networks (EVPNs) includes a plurality of Provider Edges (PEs) including a first PE and one or more second PEs. The first PE is configured to receive one or more of information on status of one or more nodes connected to the first PE, the one or more nodes being one of a leaf node or a root node; and a respective advertisement message from the one or more second PEs. The first PE is further configured to perform one or more of generating, based on the information, a route advertisement message indicative of the status of the one or more nodes connected to the first PE, wherein the route advertisement message is shared with one or more second PEs; and based on the respective advertisement message received from each of the one or more second PEs, dynamically adjust configurations at the first PE, to perform ingress filtering or egress filtering of Broadcast, Unknown Unicast, and Multicast (BUM) traffic received at the first PE.
In one aspect, one or more non-transitory computer-readable media include computer-readable instructions, which when executed by one or more processors at a first Provider Edge (PE) of an inter-connected network of Ethernet Virtual Private Networks (EVPNs), cause the first PE to receive one or more of information on status of one or more nodes connected to the first PE, the one or more nodes being one of a leaf node or a root node; and a respective advertisement message from one or more second PEs of one or more second EVPNs in the inter-connected network of EVPNs; and perform one or more of: generating, based on the information, a route advertisement message indicative of the status of the one or more nodes connected to the first PE, wherein the route advertisement message is shared with one or more second PEs; and based on the respective advertisement message received from each of the one or more second PEs, dynamically adjust configurations at the first PE, to perform ingress filtering or egress filtering of Broadcast, Unknown Unicast, and Multicast (BUM) traffic received at the first PE.
As noted above, Ethernet Virtual Private Tree (E-TREE), or rooted point-to-multipoint Ethernet Virtual Connection (EVC), is a Layer 2 service defined by the Metro-Ethernet Forum (MEF) that provides an Ethernet virtual local area network (VLAN) configuration suitable for multicast services. Illustratively, the Internet Engineering Task Force (IETF) Internet Draft entitled “Requirements for MEF E-Tree Support in VPLS″<draft-ietf-l2vpn-etree-reqt> by Key et al. specifies the requirements for supporting MEF E-TREE service in layer-2 virtual private network (L2VPN). Other types of EVCs defined for Carrier Ethernet networking are the E-Line and E-LAN.
The sites in an E-TREE service have constrained connectivity, and are designated as being Root and/or Leaf. The service is set up such that:
Current solutions for addressing E-TREE in L2VPN (whether for virtual private LAN service (VPLS), Virtual Private Multicast Service (VPMS) or Ethernet Virtual Private Network (EVPN)) rely on an egress-filtering model. This means that the egress (i.e., disposition) PE device (e.g., the PE to which a destination for network traffic is attached) decides on whether to forward or drop traffic destined to a local attachment circuit, to satisfy the E-TREE connectivity constraints. This model unnecessarily wastes the bandwidth of the Multi-Protocol Label Switching (MPLS) network, where leaf-to-leaf traffic, all known unicast traffic, and ingress-replicated multi-destination traffic (broadcast, unicast unknown, and multicast (BUM) traffic), is transported over the MPLS network only to be dropped on the egress PE.
As will be described below, the present disclosure provides a dynamic ingress and egress filtering for BUM traffic that addresses the shortcomings of existing solutions.
A computer network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations. Many types of networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), or synchronous digital hierarchy (SDH) links. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Computer networks may be further interconnected by an intermediate network node, such as a router, to extend the effective “size” of each network.
Since management of interconnected computer networks can prove burdensome, smaller groups of computer networks may be maintained as routing domains or autonomous systems. The networks within an autonomous system (AS) are typically coupled together by conventional “intradomain” routers configured to execute intradomain routing protocols, and are generally subject to a common authority. To improve routing scalability, a service provider (e.g., an ISP) may divide an AS into multiple “areas” or “levels.” It may be desirable, however, to increase the number of nodes capable of exchanging data; in this case, interdomain routers executing interdomain routing protocols are used to interconnect nodes of the various ASes. Moreover, it may be desirable to interconnect various ASes that operate under different administrative domains. As used herein, an AS, area, or level is generally referred to as a “domain.”
In an E-Tree service, a customer site that is typically represented by an Attachment Circuit (AC) (e.g., an 802.1Q VLAN tag), is labeled as either a Root or a Leaf site. The terms site and node may be used interchangeably throughout this disclosure. A customer site may also be represented by a Media Access Control (MAC) address along with a VLAN tag. Root sites can communicate with all other customer sites (both Root and Leaf sites). However, Leaf sites can communicate with Root sites but not with other Leaf sites. Throughout this disclosure, a site is represented by an AC. Furthermore, an EVPN network is represented by one or more Customer Edge (CE) devices connected to a Provider Edge (PE) via one or more ACs.
In non-limiting example of
In example of
In this scenario, there may be no EVPN data-plane communications among leaf PEs belonging to the same BD. However, EVPN control-plane communications among these PEs may occur because of host mobility (i.e., a host can move from one leaf PE to another leaf PE in the same BD). Therefore, EVPN unicast MAC/IP routes need to be exchanged among the leaf PEs to allow for EVPN MAC mobility procedures to get executed properly. This implies a single Route Target just like baseline EVPN per EVI must be used for this scenario.
Furthermore, in this scenario, known unicast traffic from a leaf PE destined to another leaf PE is dropped at the ingress PE (i.e., known unicast traffic from a leaf PE is only allowed to a root PE). For instance, traffic from CE 118 to CE 108 will be subject to ingress filtering and is dropped at PE 120. This ingress filtering of known unicast traffic is achieved by signaling extensions to EVPN for coloring EVPN MAC/IP routes. For scenario of
When BGP route policies are used to enable ingress filtering of BUM traffic in case of ingress replication (for the BDs that need this policy), the transmit policy matches on EVPN IMET route and colors the IMET route with a BGP standard community attribute, as known, and the receiver PE checks IMET routes with such color and discards them.
However, when E-Tree topology is dynamic in nature and can vary between, for example, the example scenario of
In non-limiting example of
In example of
In order to perform egress filtering for BUM traffic received at the egress PE (e.g., PE 212), the ingress PE (e.g., PE 220) needs to color the BUM traffic in data plane to indicate if the traffic is coming from a Root or a Leaf. The egress PE uses this indication in data plane to make a decision as to whether to perform egress filtering of the received BUM traffic or not.
In this scenario, the transmission of BUM traffic to an egress PE (in a given BD) that is only configured with leaf ACs, can be optimized by performing ingress filtering of BUM traffic prior to transmitting the BUM traffic to the egress PE. However, because of the dynamic nature of AC leaf/root activation on a PE, EVPN signaling extensions may be needed. These extensions are described below with reference to
It should be noted that networks 100 and 200 of
It was noted previously that filtering of BUM traffic can be optimized by performing ingress filtering of BUM traffic from at PE of a leaf AC to other PEs with leaf only ACs in case of ingress replication. Furthermore, it was noted that a PE role, for a given BD, as a leaf-only, root-only, or both leaf-and-root can change dynamically as new ACs can be added or existing ACs can be modified or deleted. This optimization may be performed dynamically via EVPN signaling extensions and without any operator manual intervention, as will be described below.
EVPN signaling extensions that can enable dynamic ingress and egress filtering of BUM traffic with ingress duplication may be two folded. In other words, the signaling extensions include each PE properly advertising the state of ACs (e.g., leaf, root, and/or both) connected thereto (i.e., each PE acting as an advertising PE) and each PE receiving the advertising of the state of ACs associated with other PEs and appropriately updating its record (i.e., each PE acting as a receiving PE). Furthermore, signaling extensions may occur over the control plane.
At block 302, PE 120 may monitor AC(s) attached (connected) thereto. In example of
At block 304, PE 120 may determine (detect) an active leaf AC that is attached to PE 120. In example of
At block 306, PE 120 determines if an active root AC is also attached thereto. In example of
If at block 306, PE 120 determines that no active root is attached to PE 120 (NO at block 306), then at block 308, PE 120 generates and advertises an IMET route for PE 120. This advertisement can include an indication that no active root AC is attached to PE 120, that there is an active leaf AC attached to PE 120, along with a valid VNI for the active leaf AC (e.g., root tag=0, leaf tag=1; leaf VNI=ABC).
If at block 306, PE 120 determines that an active root AC is attached to PE 120 (YES at block 306), then at block 312, PE 120 generates and advertises an IMET route for PE 120. This advertisement can include an indication that an active root AC is attached to PE 120, that there is an active leaf AC attached to PE 120, along with a valid leaf VNI for the active leaf AC (e.g., root tag=1, leaf tag=1; leaf VNI=EFG).
After PE 120 advertises the IMET route at block 308, at block 310, PE 120 determines if an active root is detected subsequent to the detection at block 306. In one example, process of block 310 may be merged into block 306.
If an active root is detected at block 310 (YES at block 310), the process proceeds to block 312, as described above. However, if an active root is not detected at block 310 (NO at block 310), the process proceeds to block 316, which will be described below.
Referring back to block 312 and after advertising the IMET route at block 312, PE 120 may proceed to block 312. At this point, PE 120 may have one or more leaf ACs and one or more root ACs attached thereto. At block 314, PE 120 determines whether a last one of active root ACs has become inactive. If PE 120 determines that the last one of active root ACs has become inactive (YES at block 314), the process reverts back to block 308 and PE 120 may repeat blocks 308 to 314.
However, if PE 120 determines that at least one active root remains attached to PE 120 (NO at block 314), at block 316, PE 120 determines if the last one of active leaf ACs is now inactive. If PE 120 determines that at least one active leaf AC remains (NO at block 316), the process reverts back to block 308 and PE 120 may repeat blocks 308 to 314.
However, if PE 120, at block 316, determines that the last active leaf AC is now inactive (YES at block 316), then at block 318, PE 120 re-advertises the IMET route with no E-tree ECs (e.g., E-TREE EC field is empty as shown in conditions 1 or 2 in Table-1 below).
Table 1 below outlines the different types of IMET route advertisements that each PE, as an advertising PE, may signal to other PEs over the control plane indicative of root and/or leaf AC(s) connected thereto:
As noted above, a PE may be an advertising PE (informing other PEs of the state of AC(s) connected thereto) or may be a receiving PE that can update its own ingress/egress filtering of BUM traffic based on the route advertisements received from other PEs and the state of ACs connected thereto. Hereinafter, signaling procedure for a receiving PE is described.
At block 402, PE 112 receives at least one route advertisement from one or more advertising PEs. In one example, PE 112 may receive a route advertisement (IMET route advertisement) from each of PEs 104 and 120. In one example, each route advertisement may be received in the form of Table-1, as whole, or an individual entry thereof (e.g., any one or more of condition 1, condition 2, condition 3, and/or condition 4).
At block 404, PE 112 determines if an E-Tree EC field of the received route advertisement is empty (e.g., if the route advertisement corresponding to condition 1 and/or 2). If the E-Tree EC field is not empty (NO at block 404), then at block 406, PE 112 adds advertising PE from which the route advertisement is received to PE 112's flood list, per IETF [RFC7432] and/or IETF [RFC8365]. A route advertisement with an empty E-tree EC field is indicative of the advertising PE having only a root AC associated therewith, in which case no filtering of BUM traffic is to be performed as traffic routing from a root AC to another root AC or leaf AC is allowed, as described above.
However, if the E-tree EC field is empty (YES at block 404), then at block 408, PE 112 determines if the E-Tree EC includes leaf indication only with a valid VNI (e.g., route advertisement corresponding to condition 3 in Table-1) or not. If the E-tree EC includes leaf indication only (YES at block 406), at block 410, PE 112 determines whether PE 112 has only root AC(s) associated with PE 112 or both root and leaf AC(s). In non-limiting example of
If at block 410, PE 112 determines that PE 112 has only root or both root and leaf AC(s) associated with PE 112 (YES at block 410), then at block 412, PE 112 determines whether PE 112 is configured for ingress replication or P2MP tunnel. If configured for P2MP tunnel, then at block 414, PE 112 joins a tree for advertising PE from which route advertisement is received at block 402 (for the BD associated with the advertising PE). Thereafter, the process proceeds to block 422, which will be described below.
However, if PE 112 is configured for ingress replication, at block 426, PE 112 adds the advertising PE to an “All-PEs” flood list at PE 112 and excludes the advertising PE from a “non-leaf PEs” flood list at PE 112. Thereafter, the process proceeds to block 422, which will be described below.
Referring back to block 410, if PE 112 determines that PE 112 has only leaf AC(s) associated with PE 112 (does not have only root or both root and leaf AC(s) associated with PE 112) (NO at block 410), at block 416, PE 112 determines whether PE 112 is configured for ingress replication or P2MP tunnel. If configured for P2MP tunnel, then at block 418, PE 112 does not join a tree for advertising PE from which route advertisement is received at block 402 (for the BD associated with the advertising PE). Thereafter, the process proceeds to block 422, which will be described below.
However, if PE 112 is configured for ingress replication, at block 420, PE 112 excludes receiving PE from a flood list at PE 112. Thereafter, the process proceeds to block 422, which will be described below.
Referring back to block 408, if PE 112 determines that E-tree EC field does not include leaf only indication with valid VNI (NO at block 408), meaning E-tree EC field includes root only and/or root and leaf AC indications (e.g., condition 4 in Table-1), then at block 424, PE 112 adds advertising PE to “All-PEs” flood list at PE 112 when PE 112 is configured to ingress replication, or joins a multicast tree for advertising PE (for the BD associated with the advertising PE) if PE 112 is configured to P2MP tunnel.
At block 422, PE 112 configures leaf AC(s) associated with PE 112 for egress filtering of BUM traffic received from other PEs (e.g., PE 112 ensures that BUM traffic received from a leaf site associated with another PE is filtered and dropped before the BUM traffic reaches a leaf site associated with PE 112).
Accordingly, each PE in an inter-connected network of EVPNs can implement control plane signaling extensions as an advertising and receiving PE per processes of
Table-2 summarizes dynamic ingress and egress filtering of BUM traffic at a given PE, over the data plane, using signaling extensions described above:
With control plane signaling extensions set as described above, data plane filtering of BUM traffic may be performed as follows:
For ingress replication, BUM traffic coming from a leaf AC on a local PE (e.g., BUM traffic coming from AC 122 to local (ingress) PE 120, uses “non-leaf PEs” of PE 120. That is BUM traffic coming from AC 122 may be forwarded by PE 120 to PEs included in the “non-leaf PEs” flood list of PE 120, as shown in Table-2. On the other hand, for BUM traffic coming from a root AC at a local PE (e.g., BUM traffic coming AC 106 at local (ingress) PE 104) uses “All PEs” flood list of PE 104. That is BUM traffic coming from root AC 106 is not subject to ingress filtering at PE 104 and is forwarded to all other PEs to be subjected to egress filtering at a PE having a leaf AC associated therewith (according to option 1).
For P2MP and MP2MP tunnels, Leaf-only PEs, do not join the multicast tunnels from other Leaf PEs, Root-only or Root-and-Leaf PEs join the multicast tunnels from Leaf PEs, All PEs join the multicast tunnels from Root-only and Root-and-Leaf PEs.
For all multicast tunnels, an imposition PE (an ingress PE) uses leaf VNI for BUM traffic coming from a leaf AC on a local PE (e.g., BUM traffic coming from AC 122 on local (ingress) PE 120), per condition 2 in Table-2. An imposition PE uses base VNI for BUM traffic coming from a root AC on a local PE (e.g., BUM traffic coming AC 106 at local (ingress) PE 104), per condition 1 in Table-2.
On the other hand, a disposition PE (an egress PE), sends BUM traffic received with a leaf VNI only to root AC(s) associated with the disposition PE. For instance, PE 212, when receiving BUM traffic from PE 220 with a leaf VNI, performs egress filtering to drop the traffic and prevent the traffic from reaching leaf AC 214 but sends the BUM traffic to root AC 216.
Furthermore, a disposition PE (an egress PE), upon receiving BUM traffic with base VNI, sends the BUM traffic to both root and leaf AC(s) attached thereto. In other words, when a PE receives BUM traffic that is originated at a root site, the egress PE (similar to the ingress PE) need not perform any filtering and can simply forward the BUM traffic to all sites attached to the egress PE. For instance, BUM traffic received at PE 212 with base VNI from PE 204 (BUM traffic originating from root AC 206) is neither subject to ingress filtering at PE 204 nor is subject to egress filtering at PE 212. Hence, PE 212 simply forwards the BUM traffic to both root and leaf sites via AC 214 and AC 216.
In one example, an imposition PE, when sending BUM traffic, uses a leaf VNI if the traffic is sourced from a leaf site. If the BUM traffic is sourced from a root site, then existing base VNI is used. The leaf VNI identifies both the BD and the leaf role.
A disposition PE, when receiving a VxLAN or GENEVE encapsulated packet with leaf VNI, performs egress filtering accordingly (i.e., the disposition PE drops the packet at the egress leaf ACs and passes it at the egress root ACs).
At block 502, the first PE may receive information on status of one or more nodes (e.g., AC(s)) connected to the first PE. In one example, status of a node can be an indication of whether node is a root node or a leaf node and also whether the leaf or root node is active or inactive, as described above with reference to
At block 504, the first PE may further receive a respective advertisement message from one or more second PEs (other PEs in network 100 or 200 that may be advertising PEs from the perspective of the first PE). In one example, the respective advertisement message received from each of the one or more second PEs may be a respective IMET route advertisement generated by the respective of the one or more second PEs per the process of
At block 506, the first PE may generate a route advertisement message indicative of the status of the one or more nodes connected to the first PE. The process of generating the route advertisement message (e.g., IMET route advertisement) may be performed as described above with reference to
At block 508, the first PE may dynamically adjust configurations on the first PE to switch between ingress and egress filtering on BUM traffic received at the first PE. This dynamic adjust may be based on both the advertisement message(s) received from the one or more second PEs and the status of nodes (AC(s)) attached to the first PE.
In one example, using the advertisement messages received from the one or more second PEs, the first PE may generate a first flood list and a second flood list. Using these flood lists, the first PE may create a table to determine which flood list to use when receiving BUM network traffic either from nodes attached to the first PE or BUM traffic forwarded to the first PE by one or more of the second PEs. This table may be the same as table-2 described above.
Processes described above with reference to blocks 502, 504, 506, and 508 may be performed over the control plane. In other words, advertisement messages with updated information on status of nodes associated with each PE in the network may be shared among PEs over the control plane. However, the actual ingress and/or egress filtering of BUM traffic may be performed over the data plane.
As an example, the first PE may receive BUM traffic from a root node attached to the first PE. According to table-2, since the traffic is originating from a root node, the first flood list (encompassing all of the one or more second PEs) is used and the first PE forwards the BUM traffic to all other PEs in the network.
In another example, the first PE may receive BUM traffic from a leaf node attached to the first PE. Since the traffic is originating from a leaf node, the first PE performs ingress filtering by forwarding the BUM traffic to all PEs included in the second flood list. PEs in the second flood list exclude any PE that has only leaf nodes associated therewith.
In sending the BUM traffic to PEs included in the second flood list, the first PE may also include a leaf VNI with the BUM traffic that identifies the BUM traffic as originating from a leaf node. When second PE that has both root and leaf node(s) associated therewith, receives the BUM traffic and observes the leaf VNI, the second PE performs egress filtering by dropping the BUM traffic for the leaf node(s) associated with the second PE.
In another example, the first PE may receive BUM traffic from one of the second PEs. Such BUM traffic may be received at the first PE either because (1) the traffic originates from a root node at the second PE from which the BUM traffic is received, or (2) the first PE has both root and leaf node(s) associated therewith. In one example, the first PE determines that the BUM traffic has originated from a root node at the second PE, if the BUM traffic has a base VNI associated with it. However, if the BUM traffic has a leaf VNI associated with it (under (2)), then the first PE performs egress filtering of the BUM traffic in order to prevent the BUM traffic from reaching the leaf node attached to the first PE.
In some embodiments, computing system 600 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple data centers, a peer network, etc. In some embodiments, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some embodiments, the components can be physical or virtual devices.
Example computing system 600 includes at least one processing unit (CPU or processor) 604 and connection 602 that couples various system components including system memory 608, read-only memory (ROM) 610, and/or random access memory (RAM) 612 to processor 604. Computing system 600 can include a cache of high-speed memory 606 connected directly with, in close proximity to, or integrated as part of processor 604.
Processor 604 can include any general purpose processor and a hardware service or software service, such as services 616, 618, and 620 stored in storage device 614, configured to control processor 604 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 604 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.
To enable user interaction, computing system 600 includes an input device 626, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system 600 can also include output device 622, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input/output to communicate with computing system 600. Computing system 600 can include communication interface 624, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
Storage device 614 can be a non-volatile memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read-only memory (ROM), and/or some combination of these devices.
The storage device 614 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 604, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 604, connection 602, output device 622, etc., to carry out the function.
For clarity of explanation, in some instances, the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.
Any of the steps, operations, functions, or processes described herein may be performed or implemented by a combination of hardware and software services or services, alone or in combination with other devices. In some embodiments, a service can be software that resides in memory of a client device and/or one or more servers of a content management system and perform one or more functions when a processor executes the software associated with the service. In some embodiments, a service is a program or a collection of programs that carry out a specific function. In some embodiments, a service can be considered a server. The memory can be a non-transitory computer-readable medium.
In some embodiments, the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer-readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The executable computer instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, solid-state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include servers, laptops, smartphones, small form factor personal computers, personal digital assistants, and so on. The functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer-readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The executable computer instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, solid-state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include servers, laptops, smartphones, small form factor personal computers, personal digital assistants, and so on. The functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.
Claim language or other language reciting “at least one of” a set and/or “one or more” of a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language reciting “at least one of A and B” or “at least one of A or B” means A, B, or A and B. In another example, claim language reciting “at least one of A, B, and C” or “at least one of A, B, or C” means A, B, C, or A and B, or A and C, or B and C. or A and B and C. The language “at least one of” a set and/or “one or more” of a set does not limit the set to the items listed in the set. For example, claim language reciting “at least one of A and B” or “at least one of A or B” can mean A, B, or A and B, and can additionally include items not listed in the set of A and B.
This application claims priority to U.S. Provisional Application No. 63/496,974 filed on Mar. 19, 2023, the entire content of which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63496974 | Apr 2023 | US |
