Fine-grained role-based segmentation in overlay networks

Abstract

The embodiment of the invention relates to fine-grained role-based segmentation in an overlay network. A system for facilitating segmentation by a first switch overlying a tunnel construction is provided. During operation, the system may receive a routing update packet for the fabric. The packet may be based on a control plane that allows switching of routing information via the tunnel, and may include a first medium access control (MAC) address learned at the second switch, and a first role identifier of the first role. The first role may indicate an access level granted to a first device associated with the first MAC address. The system may store the first MAC address and the first role identifier in a local address data structure. Upon receiving the packet from the first device, the system may then determine whether the local device is allowed to receive the packet from the first device based on the first role identifier and the first segmentation policy.

Description

Background Art

[0001] A communication network may be composed of several types of technologies or layers. For example, a heterogeneous multi-layer network such as an overlay network may be formed based on tunnels and virtual private networks (VPNs) such as Ethernet VPN (EVPN). In some examples, switches in an overlay network may be coupled to each other via a set of tunnels (e.g., a virtual extensible local area network (VXLAN)). BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1A An example of an overlay network that facilitates fine-grained role-based traffic segmentation according to an aspect of the present application is illustrated.

[0003] Figure 1B An example of a switch in a distributed tunnel efficiently learning fine-grained role-based policies according to an aspect of the present application is illustrated.

[0004] Figure 2 An example of constructing a routing packet for announcing a role in association with a network address in an overlay network according to an aspect of the present application is illustrated.

[0005] Figure 3 An example of fine-grained role discovery of a migration terminal device according to an aspect of the present application is illustrated.

[0006] Figure 4A A flow chart illustrating an example of a process for a switch to learn a network address and associated role according to an aspect of the present application is presented.

[0007] Figure 4B A flow chart illustrating an example of a process for a switch to obtain a remotely learned network address and associated role according to an aspect of the present application is presented.

[0008] Figure 5 A flow chart illustrating an example of a process by which a switch facilitates fine-grained role-based traffic segmentation in accordance with an aspect of the present application is presented.

[0009] Figure 6 An example of a switch supporting fine-grained role-based traffic segmentation according to an aspect of the present application is illustrated.

[0010] In the drawings, like reference numerals refer to the same drawing elements. DETAILED DESCRIPTION

[0011] The present disclosure relates to a method and system for efficiently implementing fine-grained (e.g., at the network address level) role-based business segmentation in a distributed tunnel construction. As mentioned above, heterogeneous multi-layer networks such as overlay networks can be formed based on tunnels and VPNs. Switches in an overlay network can be coupled to each other via a set of tunnels (such as, VXLAN). Overlay routes for VPNs on tunnels can be determined using routing protocols such as the Border Gateway Protocol (BGP). In order to deploy a VPN on a tunnel, a corresponding tunnel endpoint can map a corresponding client virtual local area network (VLAN) to a corresponding tunnel network identifier (TNI), which can identify the virtual network of the tunnel. When a switch in the construction learns an address, the switch can share the address with other switches via a construction routing packet (e.g., EVPN network layer reachability information (NLRI)).

[0012] The TNI may appear in an encapsulation fabric routing packet and be used in a tunnel header that forwards the encapsulation packet via a tunnel. For example, if a tunnel is formed based on a VXLAN, the TNI may be a virtual network identifier (VNI) of the VXLAN header, and the tunnel endpoint may be a VXLAN tunnel endpoint (VTEP). If Layer 3 routing and forwarding is required, the TNI may also be mapped to a virtual routing and forwarding (VRF) associated with the tunnel. Since VPNs may be distributed onto a tunnel fabric, VPNs on a tunnel fabric may also be referred to as distributed tunnel fabrics. Since the fabric is an overlay network, the corresponding switches in the fabric may be tunnel endpoints of one or more tunnels. In addition, the gateway switch of the fabric may be a virtual gateway switch (VGS) shared between multiple participating switches.

[0013] Role-based segmentation can facilitate role-based separation of services in the network (for example, guests are not allowed to communicate with engineers). Typically, the definition of roles in the network and the policies that control the services between roles are maintained at the switches that couple the terminal devices. Respective terminal devices such as hosts and servers can be coupled to the overlay network via access switches. In order to implement role-based segmentation, the corresponding access switches need to know the roles of other terminal devices. However, in a multi-configuration network, it may not be possible to uniformly support the synchronization of the roles of terminal devices. Therefore, it may be challenging to efficiently segment services in an overlay network.

[0014] The various aspects described herein solve the problem of efficiently managing roles and implementing associated segmentation in an overlay network by: (i) including the role information of the terminal device in the constructed routing packet for the corresponding network address of the shared terminal device; and (ii) maintaining the role information in the local data structure of the corresponding switch in association with the network address. When learning the network address of the terminal device from the local port, the switch can discover the role of the terminal device. The switch can then include the role information (e.g., an identifier associated with the role) in the constructed routing packet for the shared network address. The corresponding switch that learns the network address can then store the role in association with the network address. In this way, the role can be distributed and maintained in a fine-grained manner at the network address level.

[0015] The distributed tunnel structure in the overlay network can be coupled to other networks via the gateway switch (which may include VGS) of the structure. Typically, at least two switches can operate in conjunction with each other as a single switch to facilitate VGS. The switches participating in VGS can be referred to as participating switches. The corresponding participating switches can regard other participating switches as peer participating switches (or, peer switches). The corresponding participating switch pairs can be coupled to each other via inter-switch links (ISLs). VGS can be associated with one or more virtual network addresses (e.g., virtual Internet Protocol (IP) addresses and / or virtual media access control (MAC) addresses). The corresponding tunnels formed at the VGS can use virtual addresses to form tunnel endpoints. Therefore, the other tunnel endpoints of the structure (i.e., other switches) can regard VGS as other tunnel endpoints of the tunnel, rather than any participating switches.

[0016] To forward traffic to the VGS, the corresponding switches in the construction can perform a load balancing operation (e.g., based on a hash of the corresponding packets) and select one of the participating switches as the destination (i.e., as another tunnel endpoint). The switch can then forward the packet via the tunnel between the tunnel endpoints. Thus, the endpoint can forward the multicast control packet to one of the participating switches, which in turn can share the control packet with a peer participating switch via the ISL. If the construction is a multi-construction network, the construction can be one of the multiple constructions that form the network. The corresponding construction can then include a gateway switch, which in turn can include a VGS, which can be coupled to a remote gateway switch of another construction, an external network, or both.

[0017] For example, a gateway switch can be coupled to a remote gateway switch via an inter-fabric tunnel (i.e., a tunnel coupling two fabrics). Packets received at the gateway switch via an intra-fabric tunnel (i.e., a tunnel within a fabric) can be encapsulated with a tunnel header associated with the intra-fabric tunnel. The gateway switch can decapsulate the tunnel header and recapsulate the packet with another tunnel header associated with the inter-fabric tunnel. The corresponding switches operating as tunnel endpoints in the fabric can use a routing protocol, such as BGP. In a multi-fabric overlay network, the routing of the intra-fabric tunnel can be determined by using internal BGP (iBGP), while the routing of the inter-fabric tunnel can be determined by using external BGP (eBGP).

[0018] In an overlay network, a user's role may indicate a set of privileges and resources that the user can access in the overlay network. Thus, a role may indicate a level of access granted to a user's terminal device in the overlay network. Depending on the employment of an enterprise, a user may be associated with a role. For example, an engineer and an accountant of an enterprise may be associated with the roles of "engineer" and "accountant", respectively. Role-based segmentation may facilitate role-based business segmentation. Thus, a user with a "guest" role may not be allowed to communicate with a user with an "engineer" role. When the user's terminal device is authenticated using the user's credentials, the terminal device becomes associated with the user's role and is assigned to a virtual local area network (VLAN) corresponding to the role. In a multi-construction overlay network, an access (or, edge) switch may determine the role of a terminal device from a VLAN.

[0019] Using existing technology, an access switch can maintain a set of segmentation policies. The corresponding policy can indicate whether a device associated with one role is allowed to communicate with a device associated with another role. In other words, the corresponding policy can indicate which role pairs are allowed to communicate with each other. Therefore, policies can control inter-role traffic in an overlay network. Policies can be defined by a user at a management server (e.g., a network administrator), which in turn can provide definitions to access switches. When a terminal device is coupled to the overlay network, the corresponding access switch can learn the role of the terminal device and implement segmentation based on the policy.

[0020] A source switch coupled to a source terminal device may receive a data packet from a source via a local port. The source switch may include role information (such as a role identifier or a role tag) associated with the source terminal device in an encapsulation header of the data packet. For example, the source switch may include a role identifier using a group policy option (GPO) tag of a tunnel encapsulation header. The role information is propagated to corresponding encapsulation headers until the data packet reaches a destination switch coupled to a destination terminal device. Upon receiving the packet, the destination switch may obtain the role information of the source terminal device from the encapsulation header. By comparing the role information of the source terminal device and the destination terminal device with the policy, the destination switch may determine whether to allow the destination terminal device to receive services from the source terminal device.

[0021] Therefore, in order to implement role-based segmentation, the destination switch needs to know the role information of the requesting host and the policies associated therewith. Therefore, the role information of the corresponding terminal device needs to be distributed in the access switches of the overlay network. If the overlay network includes multiple structures, it may be challenging to distribute the role information among all access switches. Without distributing the role information, if the terminal device moves to a different structure, the user may need to re-authenticate, which may cause disruption to ongoing operations (such as collaboration and conferencing). In addition, if the VLAN associated with the role is not configured at the new access switch, the terminal device may not be able to move to the access switch. Therefore, the corresponding access switch may need to program a large number of policies for all roles in the forwarding hardware, even though the switch may not couple terminal devices associated with several roles.

[0022] To address this issue, role-based segmentation can be deployed at the granularity of the network address (such as a MAC or IP address) of the terminal device. When a switch in the overlay network learns the network address of the terminal device, the switch can store the role identifier of the role associated with the terminal device in a local address data structure (ADS). If the network address is a MAC address, the ADS can be a MAC learning table stored in a content addressable memory (CAM). In this way, the switch can maintain role information at the network address level. Subsequently, the switch can distribute the role information, which may include a role identifier, to other switches (e.g., tunnel endpoints) in the overlay network, which role identifier can uniquely identify the role in the overlay network. When a remote switch learns a MAC address based on the distribution, the remote switch can obtain the role information and store the role information in the local ADS.

[0023] Typically, in an overlay network, when a switch learns a MAC address of a terminal device, the switch can share the learned MAC address with other switches via a routing update. The routing update can be incorporated into a constructed routing packet, which can be a routing update packet and distributed to the corresponding other switches (i.e., tunnel endpoints) of the overlay network. Because role information can be maintained at the granularity of a network address (such as a MAC address), the switch can include role information associated with the MAC address in the constructed routing packet. Existing types of constructed routing packets (such as EVPN routing update type 2) can include additional fields to include role information. Alternatively, the switch can use a new routing update type (e.g., type "X") to distribute role information. Using the new routing update type, the switch can share role information at the granularity of a MAC address without including other network attributes, thereby reducing the overhead of distribution. The new routing update type can also support additional information associated with the role. For example, the constructed routing packet can include a policy identifier associated with the role.

[0024] If the terminal device migrates to a new access switch, the switch may already know the role of the terminal device based on the role information shared by the original switch. For example, if the terminal device is a virtual machine (VM), the migration can correspond to the migration of the VM to a new host coupled to the switch. Therefore, when the switch determines the role associated with the terminal device, the switch can apply the policies and privileges associated with the role without requiring reauthentication of the terminal device. In other words, the switch can facilitate the level of access to the terminal device indicated by the role. This allows the terminal device to receive ongoing data flows without interruption. In this way, the role associated with the corresponding MAC address can ensure efficient implementation of role-based segmentation in the overlay network.

[0025] Before discovering the terminal device, if the role is not associated with the locally coupled terminal device, the switch may not program the policy associated with the role. The switch can then obtain the policies associated with the role from the policy repository and program them in the local forwarding hardware. The repository can be a local repository (e.g., a switch database) maintained in software on the switch or a remote device (e.g., a cloud-based server). Alternatively, if the policy is not programmed locally, the switch can prevent the terminal device from being coupled to the switch. In some examples, the corresponding receiving switch that constructs the routing packet can map the associated policy identifier set to the corresponding role identifier in the role data structure (RDS). When the terminal device associated with the role becomes coupled to the switch, the switch can identify the policy from the RDS.

[0026] In this disclosure, the term "switch" is used in a general sense, and it may refer to any stand-alone or structural switch operating in any network layer. "Switch" should not be interpreted as limiting the examples of the present invention to Layer 2 networks. Any device that can forward traffic to an external device or another switch can be referred to as a "switch". Any physical or virtual device that can forward traffic to a terminal device (e.g., a virtual machine or switch operating on a computing device) can be referred to as a "switch". Examples of "switches" include, but are not limited to, Layer 2 switches, Layer 3 routers, routing switches, components of a Gen-Z network, or structural switches comprising multiple similar or heterogeneous smaller physical and / or virtual switches.

[0027] The term "packet" refers to a group of bits that can be transported together on a network. "Packet" should not be interpreted as limiting the examples of the present invention to a specific layer of the network protocol stack. "Packet" can be replaced by other terms referring to a group of bits, such as "message", "frame", "cell", "datagram" or "transaction". In addition, the term "port" can refer to a port that can receive or transmit data. "Port" can also refer to hardware, software and / or firmware logic that can facilitate the operation of the port.

[0028] Figure 1A An example of an overlay network that facilitates fine-grained role-based business segmentation according to one aspect of the present application is illustrated. Overlay network 100 may include multiple switches and devices, and may include heterogeneous network components, such as layer 2 and layer 3 jumps and tunnels. In some examples, network 100 may be Ethernet, InfiniBand, or other networks, and may use corresponding communication protocols, such as Internet Protocol (IP), Fiber Channel over Ethernet (FCoE), or other protocols. Network 100 may include multiple distributed tunnel structures 110 and 120. Therefore, network 100 may be a multi-structure network. Structure 110 may include switches 111, 113, 114, 116, and 118, and structure 120 may include switches 121, 123, 124, and 126. Respective switches in the corresponding structures may be associated with MAC addresses and IP addresses. In the corresponding structures of network 100, switches may be coupled to each other via tunnels.

[0029] exist Figure 1A, the corresponding links represented by solid lines between the switch pairs may indicate tunnels. The switches of the corresponding structures in the network 100 may form a mesh of tunnels. Examples of tunnels may include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization Using GRE (NVGRE), Generic Network Virtualization Encapsulation (Geneve), Internet Protocol Security (IPsec), and Multi-Protocol Label Switching (MPLS). Tunnels in the structure may be formed on an underlying network (or, an underlying network). The underlying network may be a physical network, and the corresponding links of the underlying network may be physical links. The corresponding switch pairs in the underlying network may be BGP peers. VPN 102 such as Ethernet VPN (EVPN) may be deployed on the structure 110. Similarly, VPN 104 may be deployed on the structure 120.

[0030] VGS 112 may operate as a gateway switch for fabric 110 and facilitate external communications for fabric 110. In fabric 110, switches 111 and 113 may operate in conjunction with each other as a single switch to facilitate VGS 112. Similarly, VGS 122 may operate as a gateway switch for fabric 120 and facilitate external communications for fabric 120. In fabric 120, switches 121 and 123 may operate in conjunction with each other as a single switch to facilitate VGS 122. VGS 112 and 122 may couple fabrics 110 and 120, respectively, to a wide area network (WAN) 160, such as an enterprise network or the Internet.

[0031] In configuration 110, switches 111 and 113 may operate in conjunction with each other as a single switch to facilitate VGS 112. VGS 112 may be associated with one or more virtual addresses (e.g., a virtual IP address and / or a virtual MAC address). The corresponding tunnels formed at VGS 112 may use the virtual addresses to form tunnel endpoints. In order to efficiently manage data forwarding, switches 111 and 113 may maintain an ISL between them to share control and / or data packets. The ISL may be a layer 2 or layer 3 connection that allows data forwarding between switches 111 and 113. The ISL may also be based on a tunnel (e.g., a VXLAN tunnel) between switches 111 and 113.

[0032] Because the virtual address of VGS102 is associated with both switches 111 and 113, other tunnel endpoints of fabric 110 (such as switches 114, 116, and 118) can view VGS112 as other tunnel endpoints of the tunnel, rather than switches 111 and 113. In order to forward traffic to VGS112 in fabric 110, a remote switch such as switch 114, 116, or 118 can operate as a tunnel endpoint, while VGS112 can be another tunnel endpoint. There can be a set of paths (e.g., multiple paths of equal cost or ECMP) from the corresponding remote switches of fabric 110 to VGS112. For example, the ECMP can include a path to switch 111 and another path to switch 113. Therefore, the corresponding path in the underlying network can lead to one of the participating switches of VGS112.

[0033] In network 100, VGS112 can be coupled to VGS122 via an inter-structure tunnel (i.e., a tunnel coupling structures 110 and 120). Packets between structures 110 and 120 can be received at VGS112 via an intra-structure tunnel within structure 110 and can be encapsulated with a tunnel header associated with the intra-structure tunnel. VGS112 can decapsulate the tunnel header and recapsulate the packet with another tunnel header associated with the inter-structure tunnel. Upon receiving the packet, VGS122 can decapsulate the tunnel header and recapsulate the packet with another tunnel header associated with the intra-structure tunnel to send the packet to the intended recipient. In order to facilitate the forwarding of packets, VGS112 can determine the routing of the intra-structure tunnel using iBGP and the routing of the inter-structure tunnel using eBGP.

[0034] In network 100, end devices 132 and 136 are coupled to switches 118 and 114, respectively, of fabric 110, while end device 134 is coupled to switch 126 of fabric 120. End devices 132, 134, and 136 may be associated with MAC addresses 142, 144, and 146, respectively. In addition, IP addresses 152, 154, and 156 may be assigned to end devices 132, 134, and 136, respectively. End devices 134 and 136 may be associated with roles 140, which may indicate privileges and resources accessible to end devices 134 and 136 in network 100. On the other hand, end device 132 may be associated with roles 150, which may indicate privileges and resources accessible to end device 132 in network 100.

[0035] Role-based segmentation can facilitate role-based traffic segmentation. Traffic segmentation can be defined in a set of segmentation policies. One such policy can indicate that an end device with role 140 may not be allowed to communicate with an end device with role 150. When end devices 132, 134, and 136 are authenticated with corresponding credentials, they can be assigned to corresponding VLANs corresponding to roles 140 and 150. Using existing technology, switches 114, 118, and 126 can maintain segmentation policies that can control inter-role traffic in network 100. Policies can be defined by an administrator at a management server, which in turn can provide definitions to switches 114, 118, and 126. These switches can then implement role-based segmentation in network 100.

[0036] Therefore, in order to implement role-based segmentation, switches 114, 118, and 126 need to know the role information of end devices 132, 134, and 136 and the policies associated therewith. Since network 100 includes multiple structures 110 and 120, it may be challenging to distribute role information among switches 114, 118, and 126. Without distributing role information, if end device 132 moves from structure 110 to structure 120, end device 132 may need to re-authenticate, which may cause disruption to ongoing operations (such as collaboration and conferencing). In addition, if a VLAN associated with role 150 is not configured at a new access switch of structure 120, end device 132 may not be able to move to the switch. Therefore, each access switch of structures 110 and 120 may need to program a large number of policies for all roles in the forwarding hardware, which may strain the limited hardware resources of the switch.

[0037] To address this issue, the network 100 can maintain and distribute role information at the granularity of the network address. When the switch 118 learns the MAC address 142, the switch 118 can also discover that the role 150 is assigned to the terminal device 132. In order to discover the role 150, the switch 118 can determine the VLAN configured for the terminal device 132 and determine the role associated with the VLAN. The switch 118 can then store the role 150 in the local ADS172 in association with the MAC address 142. The ADS172 can be a MAC learning table stored in the CAM of the switch 132. Storing the role can include storing role information associated with the role, such as a role identifier. The entry for the MAC address 142 in the ADS172 can include an additional column for storing the role 150. Similarly, when the switches 126 and 114 learn the MAC addresses 144 and 146, respectively, the switches 126 and 114 can discover the role 140. Switches 126 and 114 may then store role 140 in local ADS 174 and ADS 176, respectively, in association with MAC addresses 144 and 146. In this manner, switches in network 100 may maintain role information at the MAC address level.

[0038] When the switch 118 learns the MAC address 142 as a new address, the switch 118 can distribute the MAC address 142 in the network 100 using the fabric routing packet 162. Because the role 150 is learned and maintained using the MAC address 142, the switch 118 can include the role 150 in the packet 162. The fabric routing packet 162 can also include the corresponding network addresses and roles associated with other terminal devices (if any) coupled to the switch 118. By combining the distribution of network addresses and roles into one fabric routing packet, the switch 118 can reduce the processing overhead associated with the fabric routing packet. The switch 118 can then encapsulate the packet 162 in a corresponding tunnel header (e.g., a VXLAN header) and forward the encapsulated packet 162 via the corresponding tunnel. Upon receiving the encapsulated packet 162, the VGS 112 can decapsulate the tunnel header, re-encapsulate the packet 162 with another tunnel header associated with the inter-fabric tunnel, and send the encapsulated packet 162 to the fabric 120. VGS 122 may then decapsulate the tunnel header and recapsulate packet 162 with another tunnel header associated with the intra-fabric tunnel to send encapsulated packet 162 to switches 124 and 126. This allows other switches in network 100 to learn MAC address 142 and role 150 of end device 132.

[0039] Similarly, switch 114 can learn MAC address 146 and discover the role 140 of end device 136. Switch 114 can then distribute MAC address 146 and role 140 in network 100 using constructed routing packet 166. In the same manner, switch 126 can learn MAC address 144 and discover the role 140 of end device 134. Switch 126 can then distribute MAC address 144 and role 140 in network 100 using constructed routing packet 164. When a remote switch such as switch 126 receives packet 162, switch 126 can store MAC address 142 and role 150 in ADS 174. In the same manner, when a remote switch such as switch 118 receives packets 164 and 166, switch 118 can store MAC addresses 144 and 146 and corresponding role 140 in ADS 172, respectively. In some examples, the respective receiving switches of packets 162, 164, and 166 can map the associated policy identifier sets to corresponding roles in the RDS. When an end device associated with a role becomes coupled to a switch, the switch may identify a policy from the RDS.

[0040] Because role information can be maintained at the granularity of a MAC address, packets 162, 164, and 166 can carry corresponding role information in association with MAC addresses 142, 144, and 146, respectively. Packets 162, 164, and 166 can be based on existing types of constructed routing packets, such as EVPN routing update type 2. There can then be additional fields in packets 162, 164, and 166 that include role information. Alternatively, packets 162, 164, and 166 can be based on a new routing update type (e.g., type "X") that can distribute role information. Using the new routing update type, packets 162, 164, and 166 can contain role information at the granularity of a MAC address without including other network attributes, thereby reducing the overhead of distribution. Packets 162, 164, and 166 can also support additional information, such as a policy identifier associated with the role.

[0041] During operation, terminal device 134 may send packet 160, which may be a unicast or multi-destination packet, to terminal devices 132 and 136. Switch 126 may receive packet 160 via a local port and encapsulate packet 160 with an encapsulation header. Switch 126 may include role 140 (i.e., a role identifier or role tag of role 140) in the encapsulation header. Switch 126 may include role 140 using a GPO tag of a tunnel encapsulation header. The corresponding encapsulation header may propagate role 140 until packet 160 reaches a destination switch coupled to a destination terminal device. Upon receiving encapsulated packet 160, switch 114 may obtain role information of terminal device 134 from the encapsulation header and obtain role information of terminal device 136 from ADS 176. Switch 114 may then determine that both terminal devices 134 and 136 are associated with the same role 140, and therefore, terminal device 136 is allowed to receive packet 160.

[0042] On the other hand, switch 118 can determine that end devices 132 and 134 are associated with roles 150 and 140, respectively. Based on the corresponding policy, switch 118 can determine that end device 132 is not allowed to receive packet 160. Therefore, switch 118 can avoid forwarding packet 160 to end device 132 and can discard packet 160. In this way, switches 114, 118, and 126 can efficiently discover the corresponding roles of end devices 132, 134, and 136, and implement segmentation accordingly. Because the same packet can be used to efficiently distribute learned MAC addresses and role information, packets 162, 164, and 166 can ensure efficient use of bandwidth and fast convergence because a smaller number (i.e., no duplication) of bytes are processed.

[0043] Figure 1BAn example of a switch in a distributed tunnel construction that efficiently learns fine-grained role-based policies according to one aspect of the present application is illustrated. Assume that a new terminal device 138 is coupled to a switch 124 of a fabric 120. The terminal device 138 may be associated with a MAC address 148 and an IP address 158. In addition, the terminal device 138 may be associated with a role 150, which may indicate privileges and resources accessible to the terminal device 138 in the network 100. Before discovering the end device 138, if the role 150 is not associated with the locally coupled terminal device, the switch 124 may not program the policy 170 associated with the role 150 in the forwarding hardware 184 of the switch 124. The policy 170 may indicate one or more of the following: a role that is allowed to receive traffic from the role 150, a role that is allowed to send traffic to the role 150, and role-specific traffic processing instructions. By not programming the policy 170 before discovering the terminal device associated with the role 150, the switch 124 can ensure efficient utilization of the forwarding hardware 184.

[0044] Upon discovery of the terminal device 138, the switch 124 may obtain the policy 170 from the policy repository 180 instead of programming the policy in the forwarding hardware 184. The repository 180 may be a local repository (e.g., a switch database) maintained in the software 182 of the switch 124. The repository 180 may also be a cloud-based database running on the server 190. The switch 124 may identify the corresponding policies associated with the roles 150 in the repository 180 to determine the policies 170 and retrieve them from the repository 180. If retrieved from the server 190, the switch 124 may store the policies 170 in a local instance of the repository 180. Alternatively, if the policies 170 are not programmed locally, the switch 124 may prevent the terminal device 138 from being coupled to the switch 124. The switch 124 may then generate an error message for the administrator to indicate that the terminal device 138 is not deployable with the switch 124.

[0045] Figure 2An example of a constructed routing packet for announcing a role in association with a network address in an overlay network according to an aspect of the present application is illustrated. A constructed routing packet 200, such as an EVPN type 2 routing update or a new type "X" packet, can be used to announce a role. Thus, packet 200 can be a routing update packet that can announce a routing update in a structure. In this example, packet 200 can be an instance of packet 164 propagated from VGS 112 in structure 110. Packet 200 can include a reachability information field 202 (i.e., an NLRI field), which can include a value 222 indicating that the reachability information is a layer 2 or layer 3 route. Packet 200 can also include a type field 204, which can include a value 224 indicating a routing type 2 or a new routing type "X". Length field 206 can indicate the length (e.g., number of bytes) of packet 200.

[0046] The packet 200 may include fields 208, 210, and 212 for a MAC address, an IP address, and a VNI. If the packet 200 is an instance of the packet 164, the fields 208 and 210 may include the MAC address 142 and the IP address 152 of the terminal device 134, respectively. The field 212 may include a VNI 220 associated with a VLAN configured for the terminal device 134. The VNI 220 may be fabric 110 specific and may be different for the same VLAN in the fabric 120. Since the role 140 of the terminal device 134 is learned and maintained at the granularity of the MAC address 144, the packet 200 may also include a role field 214 that may represent the role 140. Thus, the field 214 may include an identifier of the role 140. The packet 200 may also include corresponding network addresses and roles associated with other terminal devices (if any) coupled to the switch 126. In this case, the fields 208, 210, 212, and 214 are repeated for each of the other terminal devices. This merging can reduce the processing overhead associated with constructing routing packets.

[0047] When the switch 118 receives a packet 200 from the VGS 112, the switch 118 may generate an entry in the ADS 172 using the information obtained from the packet 200. The entry may include the MAC address 144, the IP address 154, the VNI 220, and the role 140. The entry may also include the IP address 250 of the VGS 112 in the column of the tunnel endpoint from which the packet 200 has been received. The IP address 250 may be a virtual IP address associated with the VGS 112. The entry allows the switch 118 to forward packets destined for the MAC address 144 to the VGS 112. In addition, the switch 118 may include the role 140 in the encapsulation header of the packet based on the entry in the ADS 172. In this way, fine-grained role-based segmentation at the MAC address level allows the switch 118 to efficiently maintain and utilize role information in the network 100.

[0048] Figure 3 1 illustrates an example of fine-grained role discovery for migrating end devices according to one aspect of the present application. Assume that end device 132 migrates from switch 118 to switch 126 (indicated by a dashed arrow). If end device 132 is a VM, the migration may correspond to a new host (e.g., a VM) coupled to switch 126. Figure 3 142). Because switch 118 has a role 150 for terminal device 132 that is shared with other switches in network 100, switch 126 may already know role 150. Therefore, role 150 for terminal device 132 may be protected at switch 126. Therefore, when switch 126 identifies terminal device 132 via a local port and learns MAC address 142, switch 126 may determine that terminal device 132 has been authenticated and assigned role 150, and may apply policy 170 associated with role 150 without requiring reauthentication of terminal device 132. This allows terminal device 132 to receive ongoing data streams without interruption.

[0049] Prior to discovering the terminal device 132, the forwarding hardware 310 of the switch 126 may include the policy 370 associated with the role 140 due to the terminal device 134. However, the forwarding hardware 310 may not include the policy 170 associated with the role 150. Upon discovering the terminal device 132, the switch 126 may obtain the policy 170 from the policy repository 300 and program the policy in the forwarding hardware 310. The repository 300 may be a local repository or a cloud-based database maintained in the software of the switch 126. The switch 126 may identify the corresponding policy associated with the role 150 in the repository 300 to determine the policy 170, and retrieve them from the repository 300. Alternatively, if the policy 170 is not programmed locally, the switch 126 may prevent the terminal device 132 from migrating to the switch 126. The switch 1246 may then generate an error message for the administrator to indicate that the terminal device 132 is not deployable with the switch 126.

[0050] Figure 4A A flow chart illustrating an example of a process for a switch to learn a network address and an associated role according to one aspect of the present application is presented. During operation, the switch may detect a terminal device via a local port (operation 402) and determine a network address and a role associated with the terminal device (operation 404). The switch may store the role in an address data structure in association with one or more network addresses (e.g., a MAC address) (operation 406). The switch may then generate a constructed routing packet with a corresponding routing type (operation 408). The routing type may be an EVPN routing type 2 or a new routing type. The switch may incorporate the network address and the role into the constructed routing packet (operation 410) and send the constructed routing packet to the corresponding other switches of the local structure (operation 412).

[0051] The switch may also determine whether the policy associated with the role is programmed (operation 414). If the policy is not programmed, the switch may determine whether the policy is available locally (e.g., in a local database) (operation 416). If the policy is not available locally, the switch may obtain the policy associated with the role from a remote policy repository (e.g., from a cloud server) (operation 418) and store the policy in a local policy repository (operation 420). If the policy is available locally (operation 416) or when the policy is stored in a local policy repository (operation 420), the switch may program the policy associated with the role from the local repository into the local forwarding hardware (operation 422).

[0052] Figure 4BA flow chart illustrating an example of a process for a switch to obtain a remotely learned network address and associated role according to an aspect of the present application is presented. During operation, the switch may receive a constructed routing packet with a corresponding routing type (operation 452). The switch may then determine whether the routing type is supported (operation 454). If the routing type is supported, the switch may obtain a network address and a role associated with the terminal device from the constructed routing packet (operation 456). Subsequently, the switch may store the role in association with the network address in an address data structure (operation 458).

[0053] Figure 5 A flow chart illustrating an example of a process for a switch to facilitate fine-grained role-based traffic segmentation according to an aspect of the present application is presented. During operation, the switch may receive a packet destined for a terminal device (operation 502). The packet may also be a multi-destination packet to be forwarded via a port coupled to the terminal device. The switch may determine a source address and a destination address of the packet (operation 504). The switch may then determine a corresponding role associated with the source address and the destination address from an address data structure (operation 506).

[0054] Subsequently, the switch may identify the policy associated with the role (operation 508) and determine whether forwarding is allowed based on the policy (operation 510). If forwarding is allowed, the switch may forward the packet to the terminal device (operation 512). On the other hand, if forwarding is not allowed, the switch may avoid forwarding the packet to the terminal device (operation 514). The switch may also discard the packet. The traffic segmentation process may be performed at the forwarding hardware of the switch.

[0055] Figure 6 An example of a switch supporting fine-grained role-based business segmentation according to an aspect of the present application is illustrated. In this example, the switch 600 may include multiple communication ports 602, a packet processor 610, and a storage device 650. The switch 600 may also include switch hardware 660 (e.g., processing hardware of the switch 600, such as its application-specific integrated circuit (ASIC) chip), which includes information based on which switch 600 processes the packet (e.g., determines the output port of the packet). The packet processor 610 can extract and process header information from the received packet. The packet processor 610 can identify a switch identifier (e.g., a MAC address and / or an IP address) associated with the switch 600 in the header of the packet.

[0056] The communication port 602 may include an inter-switch communication channel for communicating with other switches and / or user equipment. The communication channel may be implemented via a conventional communication port and based on any open or proprietary format. The communication port 602 may include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. The communication port 602 may also include one or more IP ports capable of receiving IP packets. The IP port may receive IP packets and may be configured with an IP address. The packet processor 610 may process Ethernet frames and / or IP packets. The corresponding ports of the communication port 602 may operate as inlet ports and / or outlet ports.

[0057] The switch 600 may maintain a database 652 (e.g., in a storage device 650). The database 652 may be a relational database and may run on one or more database management system (DBMS) instances. The database 652 may store information associated with the routing, configuration, and interfaces of the switch 600. The database 652 may store routing data structures (e.g., RIBs), ADSs, policy repositories, and RDSs of the switch 600. The switch 600 may include a tunnel logic block 670 that may establish a tunnel with a remote switch in an overlay network, thereby allowing the switch 600 to operate as a tunnel endpoint. The switch 600 may include a role logic block 630 that may allow the switch 600 to facilitate business segmentation based on fine-grained roles. The role logic block 630 may include a discovery logic block 632, a distribution logic block 634, a policy logic block 636, and an implementation logic block 638.

[0058] The discovery logic block 632 can detect locally coupled terminal devices, learn the network addresses of the terminal devices, and discover the roles of the terminal devices. The distribution logic block 634 can incorporate the roles into the constructed routing packets in association with the network addresses, and distribute the packets to the corresponding other switches of the local structure. The policy logic block 636 can determine the policies associated with the roles. If the policies are not programmed locally, the policy logic block 636 can obtain the policies from the repository and program them in the switch hardware 660. The implementation logic block 636 can determine whether to forward the packet to the terminal device based on the policies associated with the corresponding roles of the source and destination of the packet.

[0059] The description herein is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a specific application and its requirements. Various modifications of the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the illustrated examples, but conforms to the widest scope consistent with the claims.

[0060] One aspect of the present technology may provide a system for facilitating segmentation by a first switch of an overlay tunnel construction. During operation, the system may receive a routing update packet for an overlay tunnel construction. The routing update packet may be based on a control plane that allows the exchange of routing information via a tunnel, and may include a first media access control (MAC) address learned at a second switch and a first role identifier of a first role associated with the first MAC address. The role may indicate an access level granted to a first device associated with the first MAC address in the overlay tunnel construction. The system may store the first MAC address and the first role identifier in a local address data structure. The system may receive a packet from a first device, where the packet is destined for a local device. The system may then determine whether to allow the local device to receive a packet from the first device based on the first role identifier and a first segmentation policy. The first segmentation policy may be associated with the respective roles of the first device and the local device.

[0061] In a variation of this aspect, the routing update packet may also include an Internet Protocol (IP) address of the first device and a virtual network identifier (VNI) associated with a virtual local area network (VLAN) of the first device.

[0062] In yet another variation, the system may store the IP address, the VNI, and the address of the remote tunnel endpoint of the tunnel in association with the first MAC address in the address data structure.

[0063] In a variation of this aspect, the address data structure may be a MAC address learning table stored in forwarding hardware of the first switch.

[0064] In a variation of this aspect, the system can learn the first MAC address via the local port and determine the first role associated with the first MAC address from the address data structure. The system can then allow the first device to communicate with the overlay tunnel fabric via the first switch, thereby bypassing reauthentication of the first device.

[0065] In a variation of this aspect, the system can learn a second MAC address and a second role identifier of the second device via the local port. The system can then determine whether a second segmentation policy associated with the second role identifier is locally configured. If the second segmentation policy is not locally configured, the system can perform corrective action on the second device.

[0066] In yet another variation, the corrective action of the second device may include one of: retrieving the second policy from the policy repository and configuring the second policy locally; and preventing the second device from communicating with the overlay tunnel fabric via the first switch.

[0067] In a variation of this aspect, the control plane is based on Ethernet Virtual Private Network (EVPN).The routing update packet can then be one of: EVPN routing type 2 and a new type of EVPN network layer reachability information (NLRI) for sharing information associated with the role.

[0068] In a variation of this aspect, the routing update packet may also include a plurality of MAC addresses including the first MAC address and respective role identifiers associated with the plurality of MAC addresses.

[0069] The data structures and codes described in this detailed description are typically stored on a computer-readable storage medium, which can be any device or medium that can store code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices (such as disks, tapes, CDs (compact disks), DVDs (digital versatile disks or digital video disks)), or other media capable of storing computer-readable media now known or later developed.

[0070] The methods and processes described in the detailed description section may be implemented as code and / or data, which may be stored in the above-mentioned computer-readable storage medium. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes implemented as data structures and codes and stored in the computer-readable storage medium.

[0071] The methods and processes described herein may be performed by and / or included in hardware logic blocks or devices. These logic blocks or devices may include, but are not limited to, application specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), dedicated or shared processors that execute a specific software logic block or piece of code at a specific time, and / or other programmable logic devices now known or later developed. When the hardware logic blocks or devices are activated, they execute the methods and processes included therein.

[0072] The foregoing descriptions of examples of the present invention are presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present disclosure. Therefore, many modifications and variations will be apparent to practitioners in the art. The scope of the present invention is defined by the appended claims.

Claims

1. A method comprising: receiving, by a first switch of an overlay tunnel construction, a routing update packet, wherein the routing update packet includes a first media access control (MAC) address learned at a second switch and a first role identifier of a first role associated with the first MAC address, wherein the first role indicates an access level granted to a first device associated with the first MAC address in the overlay tunnel construction, and wherein the routing update packet is based on a control plane that permits exchange of routing information via the tunnel; The first switch stores the first MAC address and the first role identifier in a local address data structure; receiving, by the first switch, a packet from the first device, wherein the packet is destined for a local device; as well as A determination is made as to whether the local device is permitted to receive the packet from the first device based on the first role identifier and a first segmentation policy associated with respective roles of the first device and the local device. 2 . The method according to claim 1 , wherein the routing update packet further includes an Internet Protocol (IP) address of the first device and a virtual network identifier (VNI) associated with a virtual local area network (VLAN) of the first device.

3. The method according to claim 2, further comprising: The IP address, the VNI, and the address of the remote tunnel endpoint of the tunnel are stored in the address data structure in association with the first MAC address. 4 . The method of claim 1 , wherein the address data structure is a MAC address learning table stored in forwarding hardware of the first switch.

5. The method according to claim 1, further comprising: Learning the first MAC address by the first switch via a local port; determining, from the address data structure, the first role associated with the first MAC address; as well as The first device is allowed to communicate with the overlay tunnel fabric via the first switch, thereby bypassing re-authentication of the first device.

6. The method according to claim 1, further comprising: Learning, by the first switch via the local port, a second MAC address and a second role identifier of a second device; determining whether a second segmentation policy associated with the second role identifier is locally configured; as well as In response to determining that the second segmentation policy is not locally configured, performing corrective action for the second device.

7. The method of claim 6, wherein the corrective action for the second device further comprises one of the following: Retrieving, by the first switch, the second policy from a policy repository and locally configuring the second policy; and The second device is prevented from communicating with the overlay tunnel construction via the first switch.

8. The method of claim 1, wherein the control plane is based on an Ethernet Virtual Private Network (EVPN), and wherein the routing update packet is one of: EVPN routing type 2, and a new type of EVPN network layer reachability information (NLRI) for sharing information associated with a role.

9. The method of claim 1, wherein the routing update packet further comprises: A plurality of MAC addresses including the first MAC address; as well as Respective role identifiers associated with the plurality of MAC addresses.

10. A non-transitory computer-readable storage medium storing instructions which, when executed by a processor of a switch of a network, cause the processor to perform a method comprising: receiving, at a first switch of an overlay tunnel fabric, a routing update packet, wherein the routing update packet includes a first media access control (MAC) address learned at a second switch and a first role identifier of a first role associated with the first MAC address, wherein the first role indicates an access level granted to a first device associated with the first MAC address in the overlay tunnel fabric, and wherein the routing update packet is based on a control plane that permits exchange of routing information via the tunnel; Storing the first MAC address and the first role identifier in an address data structure of the first switch; receiving, at the first switch, a packet from the first device, wherein the packet is destined for a local device; as well as A determination is made as to whether the local device is permitted to receive the packet from the first device based on the first role identifier and a first segmentation policy associated with respective roles of the first device and the local device.

11. The non-transitory computer-readable storage medium of claim 10, wherein the routing update packet further comprises an Internet Protocol (IP) address of the first device and a virtual network identifier (VNI) associated with a virtual local area network (VLAN) of the first device.

12. The non-transitory computer-readable storage medium of claim 11, wherein the method further comprises: The IP address, the VNI, and the address of the remote tunnel endpoint of the tunnel are stored in the address data structure in association with the first MAC address.

13. The non-transitory computer-readable storage medium of claim 10, wherein the address data structure is a MAC address learning table stored in forwarding hardware of the first switch.

14. The non-transitory computer-readable storage medium of claim 10, wherein the method further comprises: At the first switch, learning the first MAC address via a local port; determining, from the address data structure, the first role associated with the first MAC address; as well as The first device is allowed to communicate with the overlay tunnel fabric via the first switch, thereby bypassing re-authentication of the first device.

15. The non-transitory computer-readable storage medium of claim 10, wherein the method further comprises: At the first switch, learning a second MAC address and a second role identifier of a second device via a local port; determining whether a second segmentation policy associated with the second role identifier is locally configured; as well as In response to determining that the second segmentation policy is not locally configured, performing corrective action for the second device.

16. The non-transitory computer-readable storage medium of claim 15, wherein the corrective action for the second device further comprises one of: retrieving, by the first switch, the second policy from a policy repository and locally configuring the second policy; and The second device is prevented from communicating with the overlay tunnel construction via the first switch.

17. The non-transitory computer-readable storage medium of claim 10, wherein the control plane is based on an Ethernet Virtual Private Network (EVPN), and wherein the routing update packet is one of: EVPN routing type 2, and a new type of EVPN network layer reachability information (NLRI) for sharing information associated with a role.

18. The non-transitory computer-readable storage medium of claim 10, wherein the routing update packet further comprises: A plurality of MAC addresses including the first MAC address; as well as Respective role identifiers associated with the plurality of MAC addresses.

19. A computer system comprising: processor; Memory devices; a communications port to receive a routing update packet in an overlay tunnel configuration, wherein the routing update packet includes a first media access control (MAC) address learned at a remote computer system and a first role identifier of a first role associated with the first MAC address, wherein the first role indicates an access level granted to a first device associated with the first MAC address in the overlay tunnel configuration, and wherein the routing update packet is based on a protocol that permits exchange of routing information via the tunnel; A control circuit system including a discovery logic block and an implementation logic block; wherein the discovery logic block is used to store the first MAC address and the first role identifier in an address data structure of the computer system; and The implementation logic block is used to: identifying a packet received from the first device, wherein the packet is destined for a local device; as well as A determination is made as to whether the local device is permitted to receive the packet from the first device based on the first role identifier and a first segmentation policy associated with respective roles of the first device and the local device.

20. The computer system of claim 19, wherein the discovery logic block is further configured to: learning the first MAC address via a local port; and determining, from the address data structure, the first role associated with the first MAC address; and The implementation logic block is further configured to allow the first device to communicate with the overlay tunnel structure via the computer system, thereby bypassing re-authentication of the first device.

Images