Inter-segment traffic policy enforcement by network fabric control plane

Abstract

This disclosure describes techniques for operating a control plane in a network fabric. The techniques include determining a stateless rule corresponding to a communication between a first segment of the network fabric and a second segment of the network fabric. The techniques also include configuring the control plane to enforce the stateless rule.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Application No. 17 / 084,453, filed October 29, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to the implementation of inter-segment traffic policies, and more specifically, to the implementation of inter-segment traffic policies by the network fabric control plane. Background Technology

[0004] Virtual Routing and Forwarding (VRF) technology is becoming increasingly prevalent in networks such as enterprise networks. VRF is a technology used in Internet Protocol (IP) networks where multiple instances of routing tables existing simultaneously within a single router are used concurrently. Therefore, network paths can be segmented without using multiple routers.

[0005] For example, one or more logical or physical interfaces can belong to a corresponding VRF; the term "VRF" can be used to refer to one of several segments across the entire network. VRFs do not share routing tables; therefore, IP packets routed along a network path within a specific VRF are forwarded only between interfaces on the same VRF. For example, a VRF can be considered equivalent to a Layer 3 Virtual Local Area Network (VLAN) at Layer 2. Network segmentation (including VRF technology and other types of segmentation) is an architectural approach to dividing a network into multiple segments, each acting as its own smaller network. This segmentation allows network administrators to control traffic between segments based on granular policies that can be enforced by border routers and / or firewalls.

[0006] Enterprise networks utilizing VRF technology can deploy at least one firewall to regulate, for example, communication between VRFs within the enterprise network, and to regulate other data traffic (including, for example, data traffic to / from outside the enterprise network).

[0007] For example, the network architecture may not allow inter-VRF communication. Instead, external firewalls and / or converged routers can be used to regulate inter-VRF communication. For instance, a converged router can connect to a VRF-aware router whose interface is in a common VRF (typically the default VRF), while the VRF-aware router has interfaces in all VRFs where inter-VRF communication might occur. Furthermore, firewalls can apply firewall policies (e.g., policies that block or allow certain types of network traffic not specified in policy exceptions) to provide security for inter-VRF communication. Firewalls and converged routers can advertise necessary routes to the network to attract relevant traffic and apply firewall policies to that traffic, including inter-VRF communication.

[0008] Along with VRF technology, Software Defined Access (SDA) technology has become increasingly prevalent. For example, SDA can be used in environments where mobile devices frequently access enterprise network resources. This access can be provided securely through SDA. However, due to the number and capabilities of external devices (e.g., firewalls and converged routers) and the complex configurations that may be used to handle these large numbers of mobile devices and network segments, policy enforcement via one or more firewalls and one or more external routers becomes more challenging and expensive. Attached Figure Description

[0009] The following detailed description is given with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which the reference numeral first appears. The same reference numerals are used in different drawings to denote similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale relative to each other.

[0010] Figure 1 This is an architecture diagram of an example network in which the enterprise architecture control plane configures stateless firewall policies.

[0011] Figure 2 This is an architecture diagram of another example network in which the enterprise architecture control plane is configured with stateless firewall policies.

[0012] Figure 3 This is a flowchart illustrating an example of configuring a stateless firewall policy in an enterprise architecture control plane, showing the data and timing flow.

[0013] Figure 4 This is a flowchart illustrating an example of configuring a stateless firewall policy in the enterprise architecture control plane, showing the data and timing flow, where the external firewall advertises a selected prefix to attract traffic from a selected VN in the enterprise architecture.

[0014] Figure 5 This is a flowchart illustrating an example process for configuring the network structure control plane within a network structure, where stateless firewall policies are applied to inter-segment communication within the network structure.

[0015] Figure 6 This is a flowchart illustrating the process by which the network structure control plane applies strategies to inter-segment network traffic.

[0016] Figure 7 An example computer architecture is shown that enables a computer to execute program components for implementing the functions described herein. Detailed Implementation

[0017] Overview

[0018] The invention is set forth in the independent claims and in the dependent claims. A feature of one aspect may be applied to any aspect alone or in combination with other aspects.

[0019] This disclosure describes a technique for operating a network structure control plane within a network structure. The technique includes determining stateless rules corresponding to communication between a first segment and a second segment of the network structure. The technique also includes configuring the network structure control plane to enforce the stateless rules.

[0020] Furthermore, the techniques described herein can be executed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described herein.

[0021] Example Implementation

[0022] The Locator / ID Separation Protocol (LISP), defined in RFC 6830 ("The Locator / ID Separation Protocol (LISP)," dated January 2013), is the routing and addressing architecture for the Internet Protocol. The LISP routing architecture addresses issues related to scaling, multihoming, inter-site traffic engineering, and mobility. Addresses on the Internet combine location (how a device attaches to the network) and identity semantics into a single 32-bit (IPv4 address) or 128-bit (IPv6 address) number. LISP separates location from identity. Simply put, with LISP, a device's location in the network (network layer locator) can change, but who the device is in the network (network layer identifier) ​​remains the same. LISP separates the end-user device identifier from the routing locator used by others to reach them. The LISP routing architecture is designed to separate a device's identity (i.e., endpoint identifier (EID)) from its location (i.e., routing locator (RLOC)).

[0023] The LISP control plane is similar to the Domain Name System (DNS). For example, DNS resolves a device's hostname to an IP address, allowing other devices to communicate with that device over an IP network. On the other hand, LISP resolves EIDs to RLOCs. Traditional IP routing populates routing tables with IP prefixes. LISP does not use EID prefixes to populate its routing tables. Instead, LISP uses a distributed mapping system where EIDs are mapped to RLOCs. These mappings are stored in a distributed EID-to-RLOC database. When an ingress tunnel router (ITR) needs to find an RLOC address, it sends a mapping request query to the LISP protocol's mapping system. Typically, the LISP protocol operates in the context of Virtual Networks (VNs) or VRFs or "LISP instances." VNs / VRFs are usually isolated from each other, preventing endpoints in one VN / VRF from communicating with endpoints in another. LISP extranets enable this communication, for example, allowing service sharing between provider VNs / VRFs and subscriber VNs / VRFs. Subscriber VN / VRFs can communicate with provider VN / VRFs, but one subscriber VN / VRF typically cannot communicate with another subscriber VN / VRF.

[0024] In some examples, subscribers to different VRFs can communicate with the VRF provider, but subscribers to different VRFs cannot communicate with each other. The techniques disclosed herein can provide firewall policy enforcement between VRFs / VNs / groups within an enterprise network architecture, for example, by enhancing existing LISP protocols and their inter-VRF communication capabilities. If the SDA architecture control plane is configured with a policy that allows such inter-VRF communication, this inter-VRF communication capability can, for example, enable a subscriber to one VRF to communicate with a subscriber to another VRF. For example, this policy could be a stateless firewall policy, allowing it to be enforced based on the content of a single packet, without referencing the content of packets preceding or following that single packet. For example, the policy could refer to the source IP address and destination IP address in that single packet. The SDA architecture control plane can, based on this policy and based on the source IP address and destination IP address in that single packet, determine whether the SDA architecture control can allow the packet to be transmitted from the device assigned the source IP address to the device assigned the destination IP address. Examples of other information that the SDA architecture control plane can use in processing the policy may include Transmission Control Block (TCB) information or network header information per packet.

[0025] In one example, an enterprise architecture (such as an SDA architecture control plane) handles VRF / VN / group firewall policy enforcement by enhancing the existing LISP protocol and its inter-VRF communication capabilities without consuming expensive router access control lists (ACLs) or ternary content-addressable memory (TCAM) resources. As mentioned above, the LISP protocol is defined in RFC 6830. Enhancements can include at least two scenarios. In the first scenario, the firewall (typically outside the SDA architecture) advertises a specific prefix to attract inter-VN traffic from devices within the enterprise connected to the SDA architecture. In the second scenario, the firewall advertises a default 0 / 0 route to attract all VN traffic from the enterprise.

[0026] According to the LISP protocol, the SDA architecture uses a mapping server / mapping resolver (MSMR) to implement policies between VN / VRFs, as shown in the following example:

[0027] External network ext1

[0028] eid-record-provider instance-id 3 (VRF-provider)

[0029] 30.0.0.0 / 8

[0030] IP - Any

[0031] !

[0032] eid-record-subscriber instance-id 1 (VRF-A)

[0033] 10.0.0.0 / 8

[0034] IP - Any

[0035] !

[0036] eid-record-subscriber instance-id 2. (VRF-B)

[0037] 20.0.0.0 / 8

[0038] IP - Any

[0039] ! ...

[0040] !

[0041] Therefore, for example, subscriber VRF-A and subscriber VRF-B can each communicate with their respective VRF providers. However, subscriber VRF-A and subscriber VRF-B cannot communicate with each other because subscriber-to-subscriber communication between VRFs is not permitted according to the LISP protocol. Furthermore, the existing extranetting policy with "ip-any" allows new prefixes to be learned in the policy (if those prefixes are registered in the instance / VRF on MSMR). Additionally, this policy does not allow any overlapping prefixes to be learned simultaneously in different VRFs.

[0042] This disclosure describes how to extend an existing LISP policy using an extended policy, as shown in the following example:

[0043] External network ext1

[0044] EID - Record - Provider Instance - ID 3 ...

[0045] !

[0046] eid-record-subscriber instance-id 1

[0047] 10.0.0.0 / 8

[0048] IP - Any

[0049] Serve <id>{s2s / firewall} Example 2

[0050] [<prefix> / all / ip-any]

[0051] !

[0052] eid-record-subscriber instance-id 2

[0053] 20.0.0.0 / 8

[0054] IP - Any

[0055] Serve <id>{S2S / Firewall} Example 1

[0056] [<prefix> / all / ip-any]

[0057] !

[0058] Inserting the following line into the policy for the s2s / firewall service will allow subscriber VRF-A (instance-id 1) to communicate with VRF-B (instance-id 2).

[0059] Serve <id>{s2s / firewall} Example 2

[0060] [<prefix> / all / ip-any]

[0061] as well as

[0062] Serve <id>{S2S / Firewall} Example 1

[0063] [<prefix> / all / ip-any]

[0064] Inter-VRF communication can be used for:

[0065] • "Ip-any": Any "learned" VRF prefix between two VRFs.

[0066] • "All": Allows all prefixes between VRFs (two VRFs) to communicate via the policy.

[0067] • "Configured": Allows VRFs to communicate via a policy for a given / known <prefix>.

[0068] Therefore, for example, the SDA architecture control plane can dynamically / automatically learn "all" prefixes of stateless policies enforced across VRF firewalls, while the firewalls can still enforce policies targeting internet traffic and / or other stateful policies. For example, due to existing extranet policies, the MSMR of the SDA architecture control plane may already know and / or learn all the individual prefixes of each subscriber VRF that is allowed to communicate with the provider VRF (e.g., 10 / 8 for VRF-A and 20 / 8 for VRF-B in the example configuration above).

[0069] Therefore, for example, a firewall can send 0 / 0 routes to the boundary of an SDA architecture. Thus, the boundary router can register 0 / 0 routes with MSMR for S2S / firewall services via a Default Proxy Ingress / Exgress Tunnel Router (PxTR). A PxTR can be a combination of a Proxy Ingress Tunnel Router (PITR) and a Proxy Exgress Tunnel Router (PETR) within the same physical device, where the difference between PITR and PETR lies in whether they have decapsulation or encapsulation capabilities based on the flow direction.

[0070] The PITR allows non-LISP sites to send packets to LISP sites. The PITR performs two main functions. One is initiating EID advertisements. The PITR, on behalf of LISP sites, advertises a highly concentrated EID prefix space to non-LISP sites, making them reachable. The other main function is encapsulating legacy internet traffic. The PITR encapsulates non-LISP internet traffic into LISP packets and routes them to their destination RLOC. The PETR is used to allow traffic from LISP sites to non-LISP sites. The PETR acts as an ETR for traffic originating from LISP sites and destined for non-LISP sites.

[0071] Because the border router registers the 0 / 0 route with MSMR for S2S / firewall services via the default proxy ingress / egress tunnel router, MSMR can generate a complete prefix list of all prefixes for inter-VRF communication. Therefore, MSMR itself can establish and apply inter-VRF policies for all prefixes, offloading this processing from the firewall / converged router in the architecture.

[0072] Due to the registration of the default PETR on the S2S / firewall, external firewalls can still enforce policies on internet traffic. This includes registering the default PETR with the MSMR. This allows the MSMR to redirect all unknown / internet traffic on the ingress tunnel router to the registered PETR. In other words, the PETR connects LISP-capable sites to the core network (e.g., the internet) without LISP capabilities via the ETR and MSMR. The ETR and MSMR publish the site's EID-to-RLOC mapping, respond to mapping request messages, and decapsulate and deliver LISP-encapsulated user data to the end systems at the site. During operation, the ETR sends periodic mapping registration messages to all its configured MSMRs. These mapping registration messages contain EID-to-RLOC entries for all EID-numbered networks connected to the ETR site.

[0073] For example, an ETR receiving a mapping request message verifies whether the request matches an EID that the ETR has authority over, constructs an appropriate mapping response message containing the mapping information configured for the ETR, and sends the message to an ITR (whose RLOC is listed in the mapping response message). An ETR receiving a LISP-encapsulated packet (directed to one of its multiple RLOCs) decapsulates the packet, verifies that the internal header is destined for an EID-numbered terminal system at its site, and then forwards the packet to the terminal system using intra-site routing.

[0074] In another scenario, the SDA architecture control plane can dynamically / automatically learn specific prefixes from stateless policies implemented across VRF firewalls. For cross-VRF communication, the firewall advertises specific prefixes for traffic from one VRF to another (or vice versa), such as traffic from VRF-A to VRF-B (or vice versa). These prefixes can then be imported into the route at the border router using LISP, thus being registered with MSMR by the border router. Since existing inter-VRF / extranet policies have "IP-any" in all subscriber VRFs, these registered prefixes (from firewall advertisements) will attempt to be added to the existing inter-VRF / extranet policies. These incoming inter-VRF prefixes may overlap with the VRF's own prefixes in the policy and may be rejected because "overlap" may not be allowed according to certain policy conditions. However, MSMR can recognize these overlapping prefixes entering the policy, and since the "new / recommended / modified policy" has "ip-any" as part of the "service s2s / firewall," these prefixes are learned as firewall prefixes in MSMR.

[0075] Once the MSMR has learned these prefixes, it can provide the learned prefixes to the DNAC / controller, making these prefixes "configured prefixes." Once the DNAC configures these prefixes to the MSMR, the MSMR can enforce inter-VRF policies without relying on firewalls within the architecture for inter-VRF communication. For example, the process could allow only selective prefixes to communicate between subscriber VRFs, thus enabling the kind of stateless policy control that external firewalls might otherwise provide.

[0076] Figure 1 This diagram illustrates the architecture of example network 100, in which the enterprise infrastructure control plane configures stateless firewall policies. Network 100 includes an enterprise infrastructure 102, which may be, for example, an SDA network including VRF-A and VRF-B. Network 100 includes border routers 104 and 106. Network 100 also includes edge routers 108 and 110. Enterprise infrastructure 102 also includes one or more MSMRs 112; the control plane of enterprise infrastructure 102 includes at least an MSMR 112. MSMR 112 includes a stateless firewall policy 113.

[0077] VRF-A subscriber 114 is coupled to enterprise structure 102 via border router 104. VRF-B subscriber 116 is coupled to enterprise structure 102 via border router 104. VRF-A subscriber 118 is coupled to enterprise structure 102 via edge router 108. VRF-B subscriber 120 is coupled to enterprise structure 102 via edge router 108. VRF-A subscriber 122 is coupled to enterprise structure 102 via edge router 110. VRF-A subscriber 124 is coupled to enterprise structure 102 via edge router 110.

[0078] Enterprise structure 102 is coupled to VRF provider subnet 126, such as an extranet, via border router 106 and external router 128. Enterprise structure 102 is coupled to WAN branch 130 via border router 106 and external router 140.

[0079] Enterprise architecture 102 is coupled to firewall 132 via border router 104 and external router 134. Firewall 132 is coupled to the Internet (VRF - External) via external router 138.

[0080] To facilitate control of inter-VRF communication by the enterprise architecture control plane (including via MSMR 112), firewall 132 sends O / O routes to enterprise architecture 102 via external router 134 and border router 104. Border router 104 monitors the O / O routers and generates default proxy ingress / egress tunnel router (PxTR) registrations for the s2s / firewall service. Therefore, MSMR 112 forms a complete prefix list of all prefixes for inter-VRF communication. Due to extranet policies, MSMR 112 already knows and / or learns all individual prefixes of each subscriber VRF allowed to communicate with the VRF-provider subnet 126.

[0081] In this way, MSMR 112 builds and applies inter-VRF policies for all prefixes to offload the application of stateless policies used for inter-VRF communication. Firewall 132 and / or border routers in the enterprise infrastructure 102 may apply stateless policies to this inter-VRF traffic in other ways. Due to subscriber-to-subscriber (s2s) default -etr registration, internet traffic can still be inspected by the external firewall 132.

[0082] Figure 2 This diagram illustrates the architecture of another example network 200, in which the enterprise infrastructure control plane configures stateless firewall policies. Network 200 includes an enterprise infrastructure 202, which may be, for example, an SDA network including VRF-A and VRF-B. Network 200 includes border routers 204 and 206. Network 200 also includes edge routers 208 and 210. Enterprise infrastructure 202 also includes one or more MSMRs 212; the control plane of enterprise infrastructure 202 includes at least an MSMR 212. MSMR 212 includes a stateless firewall policy 213.

[0083] VRF-A subscriber 214 is coupled to enterprise structure 202 via border router 204. VRF-B subscriber 216 is coupled to enterprise structure 202 via border router 204. VRF-A subscriber 218 is coupled to enterprise structure 202 via edge router 208. VRF-B subscriber 220 is coupled to enterprise structure 202 via edge router 208. VRF-A subscriber 222 is coupled to enterprise structure 202 via edge router 210. VRF-A subscriber 224 is coupled to enterprise structure 202 via edge router 210.

[0084] Enterprise structure 202 is coupled to VRF provider subnet 226, such as an extranet, via border router 206 and external router 228. Enterprise structure 202 is coupled to WAN branch 230 via border router 206 and external router 232.

[0085] Enterprise structure 202 is coupled to VRF provider subnet 226, such as an extranet, via border router 206 and external router 228. Enterprise structure 202 is coupled to WAN branch 230 via border router 206 and external routers 240 and 242.

[0086] For inter-VRF communication, firewall 238 advertises a specific prefix of VRF-A to VRF-B (or vice versa). Figure 2 In the example, there is one of each of the VRF-A prefix (20.1.1.0 / 24) and the VRF-B prefix (10.1.1.0 / 24). The VRF-A and VRF-B prefixes are then imported into the route at border router 204 using LISP, so border router 204 registers the VRF-A and VRF-B prefixes with MSMR 212. The policy across VRFs / extranets has "ip-any" in all subscriber VRFs, so MSMR 212 will attempt to register the prefix by adding the prefix (from firewall advertisement) to the existing inter-VRF / extranet policy. Incoming inter-VRF prefixes may overlap with the VRF's own prefix in the policy, and MSMR 212 can reject them because "overlapping" prefixes may not be allowed.

[0087] However, MSMR 212 can identify overlapping prefixes based on, for example, any new / recommended / modified policy that is part of a "service S2S / firewall" with an IP address. MSMR 212 can learn these prefixes as firewall prefixes, and once MSMR 212 has learned these prefixes, it can be configured with them, and MSMR 212 can enforce inter-VRF policies without firewall 238. For example, prefixes can be sent to a central controller to make them "configured prefixes," and the central controller can configure MSMR 212 with these prefixes in the architecture for inter-VRF communication.

[0088] Configuring MSMR 212 in this way allows communication across subscriber VRFs only for the selected prefix, thus enabling this stateless control provided by the firewall.

[0089] Figure 3 This is a flowchart illustrating an example of configuring a stateless firewall policy in the enterprise architecture control plane, showing the data and timing flow. The external firewall advertises the default 0 / 0 route to intercept all VN traffic from the enterprise architecture. The network includes a central management controller 302. The central management controller 302 may, for example, provide a controller and analytics platform with a single control panel, allowing administrators to configure the network from a centralized location. The network also includes a mapping database frontend, which... Figure 3 The example is LISPMSMR. The network also includes a border router 306, through which firewall 308 can access the enterprise fabric. First host 310 (Host1) belongs to a VRF with the prefix 10.1.1.1. First host 310 is coupled to the enterprise fabric via external router 312 (xTR1). External router 314 (xTR2) couples a second host 316 (Host2) belonging to a VRF with the prefix 20.1.1.1 to the enterprise fabric.

[0090] At 352, the central management controller 302 communicates with the MSMR 304. Specifically, the central management controller 302 provides a message to the MSMR 304 to configure a service S2S / firewall policy to learn ("all") Subscriber 1 to Subscriber 2 firewall prefixes as part of the extranet policy. That is, the central management controller 302 provides a message to the MSMR 304 to configure firewall 308 to learn all Subscriber 1 to Subscriber 2 prefixes as part of the extranet policy.

[0091] At this point, the MSMR 304's extranet policy table knows all subscriber prefixes because 10 / 8 and 20 / 8 are already part of subscriber VRF-A (10 / 8 subnet) and VRF-B (20 / 8 subnet). MSMR 304 automatically adds the inter-VRF prefixes \n (10 / 8 in VRF-B and 20 / 8 in VRF-A) to the corresponding VRF's service policy table (because the service policy has "all").

[0092] At 354, the central management controller 302 configures the border router 306 with the LISP "default-ETR" with s2s / firewall service to monitor the 0 / 0 routers advertised by the firewall 308.

[0093] At 356, firewall 308 advertises the 0 / 0 routes in VRF-A and VRF-B to border router 306 to attract all VRF traffic.

[0094] Simultaneously, border router 306 monitors 0 / 0 routes and registers them with MSMR 304. That is, at 358, border router 306 provides MSMR 304 with a default-etr mapping registration, which includes firewall / s2s services. This registration may not be provided to MSMR 304's site registry, but can instead be entered into the default-etr / Internet policy table as either a service RLOC or a default-service-etr.

[0095] At 360, host 1 (10.1.1.1) communicates with xTR1 (VRF-A) 312. xTR1 (VRF-A) 312 receives traffic from source host 1 310 in subnet 10 / 8 and directs it to destination (host 2 316) in subnet 20 / 8.

[0096] At position 362, xTR1 (VRF-A) 312 communicates with MSMR 304 to provide a mapping request for the destination in subnet 20 / 8. MSMR 304 first looks up its own instance table, then the extranet table, then the service policy table of the source instance, and finally finds the destination subnet address for 20 / 8 in the s2s / firewall service policy table.

[0097] At position 364, MSMR communicates with xTR1 (VRF-A) 312. That is, if the s2s / firewall policy allows communication from 10 / 8 to 20 / 8, the MSMR 304 mapping responds with an xTR2 RLOC. Otherwise, the MSMR mapping responds with a negative mapping response of "abandon". This indicates that if the configured service is "s2s", firewall 308 may not participate in inter-VRF traffic. If the configured service is "firewall", MSMR 304 sends a regular mapping response with xTR2 as the RLOC. MSMR 304 sends a regular mapping response with the registered service - default - etr (boundary) as the RLOC.

[0098] At position 366, xTR1 (VRF-A) 312 communicates with MSMR 304 to provide a mapping request for an Internet destination.

[0099] At 368, MSMR 304 communicates with xTR1 (VRF-A) 312. MSMR 304 responds with Service-Default-etr as RLOC (UMR or negative mapping response) because the destination is not found in the local VRF and not in the extranet policy table, but rather in Service_Default_etr in the local VRF's Default-etr / Internet table. Meanwhile, xTR1 (VRF-A) 312 receives the mapping response with the border RLOCC, installs it in the mapping buffer, and sends the encapsulated packet to border router 306 (or Service-Default-etr).

[0100] At 370, xTR1 (VRF-A) 312 provides encapsulated traffic to border router 306. At 372, border router 306 decapsulates the traffic and forwards the internet traffic to firewall 308. If the policy in firewall 308 allows it, firewall 308 permits the internet traffic to be sent to the internet.

[0101] At position 374, firewall 308 communicates with border router 306 to cancel the 0 / 0 route.

[0102] At position 376, border router 306 communicates with MSMR 304 to unregister the default -etr with the s2s / firewall. Traffic passing through the s2s / firewall does not affect this unregistration.

[0103] like Figure 3 As shown in the flowchart, MSMR 304 can handle stateless firewall policies, thereby reducing the involvement of firewall 308 in the authentication of traffic between VRFs.

[0104] Figure 4 This is a flowchart illustrating an example of configuring a stateless firewall policy in the enterprise architecture control plane, showing the data and timing flow. The external firewall advertises selected prefixes to attract traffic from selected VNs within the enterprise architecture.

[0105] and Figure 3 The network shown in the flowchart is similar. Figure 4 The network shown in the flowchart includes a central management controller 402. The central management controller 402 may, for example, provide a controller and analytics platform with a single control panel, allowing administrators to configure the network from a centralized location. The network also includes a mapping database front-end, which... Figure 4 The example used is LISP MSMR. The network also includes a border router 406, through which firewall 408 can access the enterprise fabric. First host 410 (Host1) belongs to a VRF with the prefix 10.1.1.1. First host 410 is coupled to the enterprise fabric via external router 412 (xTR1). External router 414 (xTR2) couples a second host 416 (Host2) to the enterprise fabric; this host belongs to a VRF with the prefix 20.1.1.1.

[0106] At 452, the central management controller 402 communicates with the MSMR 404. Specifically, the central management controller 402 sends a message to the MSMR 404, causing the MSMR 402 to configure the s2s / firewall service policy to learn the firewall policy from subscriber 1 (VRF-A subnet 10 / 8) to subscriber 2 (VRF-B subnet 20 / 8) as part of a dynamic extranet policy.

[0107] At 454, the central management controller 402 communicates with the border router 406 to configure the border router 406 for a LISP "routing-import" for a specific prefix advertised via firewall 408.

[0108] At 456, firewall 408 advertises the inter-VRF prefixes (10 / 8 in VRF-B and 20 / 8 in VRF-A) to border router 406. This advertising of the inter-VRF prefixes by firewall 408 is intended to attract inter-VRF traffic. At least in part, based on this advertising by firewall 408, border router 406 imports the inter-VRF prefixes (10 / 8 in VRF-B and 20 / 8 in VRF-A) to register these inter-VRF prefixes with MSMR 404.

[0109] At 458, border router 406 communicates with MSMR 404. Specifically, border router 406 provides MSMR 404 with a mapping registration of inter-VRF prefixes (prefix 10 / 8 in VRF-B and prefix 20 / 8 in VRF-A). MSMR 404 adds the inter-VRF prefixes to its site registry for the corresponding VRFs and also provides the inter-VRF prefixes to its extranet policy table. MSMR 404 provides the inter-VRF prefixes to its extranet policy table at least in part because of the use of "ip-any" in its s2s / firewall service policy. Simultaneously, MSMR 404's extranet policy table detects overlapping prefixes because the 10 / 8 prefix of VRF-A and the 20 / 8 prefix of VRF-B are overlapping prefixes (since 10 / 8 and 20 / 8 are already part of VRF-A and VRF-B, respectively). Furthermore, MSMR 404's extranet policy table accepts and "learns" the overlapping prefixes (firewall policy prefixes) in its extranet s2s / firewall service policy.

[0110] At 460, MSMR 404 informs the central management controller 402 that the MSMR has learned the policy for the prefix used for inter-VRF communication, and MSMR 404 also indicates the learned prefix to the central management controller 402.

[0111] At 462, the central management controller 402 configures MSMR 404 as "configured" using the learned policy, so that inter-VRF traffic in the learned prefix can be verified by MSMR 404 instead of by firewall 408.

[0112] At 464, the central management controller 402 disables firewall 408 for inter-VRF policies, at least because MSMR 404 is configured to enforce inter-VRF policies.

[0113] At 466, the firewall communicates with border router 406 to withdraw the inter-VRF route from border router 406, and at 468, border router 406 communicates with MSMR 404 to deregister the inter-VRF prefix.

[0114] At 470, host 1 (10.1.1.1) 410 sends traffic to external router 412 xTR1 (VRF-A). More specifically, external router 412 xTR1 (VRF-A) receives traffic from source host 1 410 in subnet 10 / 8 to destination host 2 416 in subnet 20 / 8.

[0115] At position 472, external router 412 xTR1 (VRF-A) communicates with MSMR 404 to request a mapping of the destination in VRF-B (20 / 8). MSMR 404 looks up the address in its own instance table, then in the extranet table, and then in the service policy table of the source instance. MSMR finds the VRF-B 20 / 8 subnet address in the s2s / firewall policy table.

[0116] At 474, if the s2s / firewall policy allows inter-VRF communication from 10 / 8 to 20 / 8, MSMR 404 communicates with external router 412 xTR1 (VRF-A) to map the response using the RLOC of external router 414 xTR2 (VRF-B). Otherwise, MSMR responds with a negative mapping response of "abandon". In this case, MSMR 404 applies the stateless firewall policy, and firewall 408 itself does not need to apply this stateless firewall policy.

[0117] External router 412 xTR1 (VRF-A) receives the mapping response using external router 414 xTR2 RLOC, and it installs the response in its mapping cache according to the inter-VRF policy.

[0118] At 476, external router 412 xTR1 (VRF-A) sends encapsulated traffic to external router 414 xTR2 (VRF-B). At 478, external router 414 decapsulates the traffic and sends the decapsulated packets to host 2 (20.1.1.1) 416.

[0119] As by Figure 4 As shown in the flowchart, MSMR 404 can handle stateless firewall policies, thereby reducing the involvement of firewall 308 in the authentication of traffic between VRFs.

[0120] Figure 5 This is a flowchart illustrating an example process that allows configuring a network structure control plane within a network architecture using stateless firewall policies for inter-segment communication within the network architecture. The network structure control plane may include a computer with one or more processors to perform operations including applying stateless firewall policies to inter-segment communication within the network architecture. For example, in a network architecture operating according to the LISP protocol, the network structure control plane may include an MSMR configured to perform operations such as converting source and / or destination indications in messages into identifiers that can be used to route messages across the network.

[0121] At position 502, the network architecture control plane receives a message from the serving router, which is coupled to the firewall service for communication. This message is generated at least in part by a firewall advertisement from the firewall service to attract communication between the first and second segments of the network architecture. For example, the firewall could be a standard firewall configured to monitor network traffic and allow or block data packets based on a set of security rules.

[0122] At position 504, the network structure control plane determines the stateless rules corresponding to communication between the first and second segments of the network structure. For example, the network structure control plane can process messages received from a firewall and determine, based on the firewall's configured policies, whether communication between the first and second segments is permitted.

[0123] At point 506, as indicated by a message received from the firewall and processed by the network structure control plane, the network structure control plane is configured with a policy that allows communication between the first segment and the second segment. For example, the network structure control plane can configure its extranet policy table using a stateless firewall policy that indicates that communication is allowed between the first segment and the second segment.

[0124] As a result, the network structure control plane can be configured to apply policies to inter-segment network traffic, thereby reducing the involvement of firewall services in the authentication of inter-segment network traffic.

[0125] A network architecture control plane configured with policies for inter-segment network traffic can apply these policies with minimal or no involvement from firewall services. For example, Figure 6 This is a flowchart illustrating the process by which the network structure control plane applies strategies to inter-segment network traffic.

[0126] At position 602, the network structure control plane receives messages originating from the first structure segment and destined for the second structure segment. For example, the network structure control plane could be an MSMR of a network structure operating according to the LISP protocol.

[0127] At position 604, the network structure control plane applies a policy to determine whether to allow the message to be delivered to the second structure segment. This policy could be, for example, a stateless firewall policy configured on the network structure control plane. The network structure control plane may have learned the stateless firewall policy because external firewall services advertise routes to attract inter-segment network traffic.

[0128] While the network architecture control plane may include MSMR for network architectures operating according to the LISP protocol, the techniques described herein are not limited to network architectures operating according to the LISP protocol. For example, the LISP protocol operates in a "pull" mode, where information for forwarding packets (i.e., mapping) is obtained on demand. Other protocols, such as Border Gateway Protocol (BGP), operate in a "push" mode, where routing information is advertised to network devices before the time it is needed. The techniques described herein are applicable to pull-mode protocols other than LISP. Furthermore, the techniques described herein are applicable to push-mode protocols, such as BGP EVPN with centralized router reflectors, and other push-mode protocols with centralized entities like MSMR.

[0129] Figure 7 An example computer architecture is shown for a computer 700 capable of executing program components for achieving the above-described functions. Figure 7 The illustrated computer architectures show the architecture of server computers, workstations, desktop computers, laptop computers, tablet computers, network devices, e-readers, smartphones, or other computing devices, and can be used to execute any of the software components presented herein. In some examples, computer 700 may correspond to the network infrastructure devices discussed herein.

[0130] Computer 700 includes a baseboard 702 or "motherboard," which is a printed circuit board on which numerous components or devices can be connected via a system bus or other electrical communication paths. In an illustrative configuration, one or more central processing units (CPUs) 704 operate together with a chipset 706. The CPU 704 may, for example, be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 700.

[0131] The CPU 704 performs operations by transitioning from one discrete physical state to the next, and this transition is achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include: electronic circuitry (e.g., flip-flops) that maintains one of two binary states, and electronic circuitry that provides the output state based on a logical combination of the states of one or more other switching elements (e.g., logic gates). These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractor units, arithmetic logic units, floating-point units, and so on.

[0132] Chipset 706 provides an interface between the CPU 704 and the remaining components and devices on the substrate 702. Chipset 706 can provide an interface to RAM 708, which serves as the main memory in computer 700. Chipset 706 can also provide an interface to computer-readable storage media, such as read-only memory (ROM) 710 or non-volatile RAM (NVRAM), to store basic routines that facilitate booting computer 700 and transferring information between various components and devices. ROM 710 or NVRAM can also store other software components necessary for the operation of computer 700 according to the configuration described herein. Figure 7 As shown, ROM 710 or NVRAM can also store data that can be used by computer 700 to generate and / or process authentication information in messages exchanged between computer 700 and other devices. In other examples, this data may be stored elsewhere, such as in RAM 708.

[0133] Computer 700 can operate in a networked environment, using logical connections to remote computing devices and computer systems via a network. For example, chipset 706 may include the ability to provide network connectivity via a network interface controller (NIC) 712 (e.g., a Gigabit Ethernet adapter). NIC 712 can connect computer 700 to other computing devices via a network. It should be understood that multiple NICs 712 may be present in computer 700, thereby connecting the computer to other types of networks and remote computer systems. In some cases, NIC 712 may include at least one inlet and / or at least one outlet. Input / output controllers 716 may be provided for other types of input / output.

[0134] Computer 700 can be connected to storage device 718, which provides non-volatile storage for the computer. Storage device 718 may, for example, store operating system 720, programs 722, and data 724. Storage device 718 can be connected to computer 700 via storage controller 714 connected to chipset 706. Storage device 718 may include one or more physical storage units. Storage controller 714 can connect to physical storage units via interfaces such as Serial Attached SCSI (SAS) interface, Serial Advanced Technology Attachment (SATA) interface, Fibre Channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0135] Data 724 may, for example, include a stateless policy for inter-segment communication within the network structure controlled by the network structure control plane. The stateless policy may, for example, include a source prefix indication and a destination prefix indication, for a source subscriber device in the first segment and a destination subscriber device in the second segment, respectively. For this purpose, the policy indication may allow communication between the source subscriber device and the destination subscriber device for inter-segment communication within the network structure. As part of the network structure control plane, the computer may apply the stateless policy for inter-segment communication to enable communication within the network structure.

[0136] Computer 700 can store data on storage device 718 by transforming the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific transformation of the physical state can depend on various factors. Examples of these factors may include, but are not limited to, the technology used to implement the physical storage units, whether storage device 718 is characterized as a primary storage device or a secondary storage device, etc. For example, computer 700 can store information on storage device 718 by issuing instructions via storage controller 714 to change the magnetic properties of a specific location in a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification; the examples provided above are merely for the purpose of description. Computer 700 can further read information from storage device 718 by detecting the physical state or characteristics of one or more specific locations in the physical storage units.

[0137] In addition to the aforementioned storage device 718, computer 700 may access other computer-readable storage media (e.g., program modules, data structures) to store and retrieve information or other data, including data used to generate and / or process evidentiary information. Those skilled in the art will understand that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by computer 700.

[0138] In summary, this disclosure describes a technique for operating a control plane within a network architecture. This technique includes determining stateless rules corresponding to communication between a first segment and a second segment of the network architecture. The technique also includes configuring the control plane to enforce these stateless rules.

[0139] While the invention has been described with respect to specific embodiments, it should be understood that the scope of the invention is not limited to these specific embodiments. Because other modifications and alterations made to suit specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, but rather includes all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0140] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions are merely illustrative of some embodiments falling within the scope of the claims of this application.< / id> < / id> < / id> < / id>

Claims

1. A method for operating a control plane in a network structure, the method comprising the following operations: At the control plane that implements network policies regarding communication within the network structure, stateless rules corresponding to communication between the first virtual routing and forwarding VRF segment and the second VRF segment of the network structure are received; Receive a first network layer prefix associated with a first subscriber device in the first VRF segment and a second network layer prefix associated with a second subscriber device in the second VRF segment; Add the first network layer prefix associated with the first VRF segment and the second network layer prefix associated with the second VRF segment to the site registry of the control plane; Receive a packet sent from a first subscriber device in the first VRF segment, the packet having a source address included in the first network layer prefix and a destination address included in the second network layer prefix; and The stateless rule, the source address, and the destination address are used to determine whether the packet is allowed to be transmitted from the first VRF segment to the second VRF segment.

2. The method of claim 1, further comprising at least one of the following operations: The firewall service is configured to either not enforce the stateless rule or to coordinate with the control plane to enforce at least one of the stateless or stateful rules.

3. The method according to claim 1, further comprising: The control plane receives messages from a serving router, which is coupled to a firewall service for communication. The messages are at least partially derived from firewall advertisements of the firewall service to attract communication between a first VRF segment and a second VRF segment of the network structure. as well as Configuring the control plane to implement the stateless rule includes configuring the control plane to allow communication between the first VRF segment and the second VRF segment of the network structure according to the message.

4. The method according to claim 3, wherein: The firewall advertisement includes an indication of a specific prefix to attract inter-segment VRF communication from at least one subscriber associated with the specific prefix.

5. The method according to claim 3, wherein: The firewall advertisement includes an indication of an arbitrary prefix to attract inter-segment VRF communication from at least one subscriber associated with that arbitrary prefix.

6. The method according to any one of claims 1 to 5, further comprising: The control plane is configured using the stateless rules as at least part of the external network policy.

7. The method according to any one of claims 1 to 5, wherein: The network structure is of the Locator ID Separation Protocol (LISP) type; and The control plane includes at least a mapping server / mapping resolver (MSMR).

8. The method according to any one of claims 1 to 5, wherein: The network structure is of type BGP EVPN; and The control plane includes at least a centralized route reflector.

9. A method for operating a control plane in a network structure, the method comprising the following operations: At the control plane that implements network policies regarding communication within the network structure, policies corresponding to communication between the first virtual routing and forwarding VRF segment and the second VRF segment of the network structure are received; Receive a first network layer prefix associated with a first subscriber device in the first VRF segment and a second network layer prefix associated with a second subscriber device in the second VRF segment; Receive a message originating from a first VRF segment of the network structure and destined for a second VRF segment of the network structure, the message having a source address and a destination address; as well as The policy is applied, and the source address and the destination address are used to determine whether the message is allowed to be provided to the second VRF segment.

10. The method of claim 9, further comprising: Configure the control plane using the aforementioned strategy.

11. The method according to claim 9 or 10, wherein, The strategy includes indications for the first VRF segment and indications for the second VRF segment.

12. A system for operating a control plane in a network structure, comprising: One or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: At the control plane that implements network policies regarding communication within the network structure, stateless rules corresponding to communication between the first virtual routing and forwarding VRF segment and the second VRF segment of the network structure are received; Receive a first network layer prefix associated with a first subscriber device in the first VRF segment and a second network layer prefix associated with a second subscriber device in the second VRF segment; Add the first network layer prefix associated with the first VRF segment and the second network layer prefix associated with the second VRF segment to the site registry of the control plane; Receive a packet sent from a first subscriber device in the first VRF segment, the packet having a source address included in the first network layer prefix and a destination address included in the second network layer prefix; as well as The stateless rule, the source address, and the destination address are used to determine whether the packet is allowed to be transmitted from the first VRF segment to the second VRF segment.

13. The system of claim 12, wherein the operation further comprises at least one of the following: The firewall service is configured to either not enforce the stateless rule or to coordinate with the control plane to enforce at least one of the stateless or stateful rules.

14. The system according to claim 12 or 13, wherein the operation further comprises: The control plane receives messages from a serving router, which is coupled to a firewall service for communication. The messages are at least partially derived from firewall advertisements of the firewall service to attract communication between a first VRF segment and a second VRF segment of the network structure. as well as Configuring the control plane to implement the stateless rule includes configuring the control plane to allow communication between the first VRF segment and the second VRF segment of the network structure according to the message.

15. The system according to claim 14, wherein: The firewall advertisement includes an indication of a specific prefix to attract inter-segment VRF communication from at least one subscriber associated with the specific prefix.

16. The system according to claim 14, wherein: The firewall advertisement includes an indication of an arbitrary prefix to attract inter-segment VRF communication from at least one subscriber associated with that arbitrary prefix.

17. The system according to claim 12 or 13, wherein the operation further comprises: The control plane is configured using the stateless rules as at least part of the external network policy; The network structure is of the Locator ID Separation Protocol (LISP) type; as well as The control plane includes at least a mapping server / mapping resolver (MSMR).

18. An apparatus operating in the control plane of a network structure, the apparatus comprising: A module for receiving stateless rules corresponding to communication between a first virtual routing and forwarding VRF segment and a second VRF segment of the network structure at the control plane for implementing network policies regarding communication in the network structure; A module for receiving a first network layer prefix associated with a first subscriber device in the first VRF segment and a second network layer prefix associated with a second subscriber device in the second VRF segment; A module for adding the first network layer prefix associated with the first VRF segment and the second network layer prefix associated with the second VRF segment to the site registry of the control plane; A module for receiving packets sent from a first subscriber device in the first VRF segment, the packets having a source address included in the first network layer prefix and a destination address included in the second network layer prefix; as well as A module for determining, using the stateless rule, the source address, and the destination address, whether the packet is permitted to be transmitted from the first VRF segment to the second VRF segment.

19. The apparatus of claim 18, further comprising a module for implementing the method of any one of claims 2 to 8.

20. An apparatus for operating a control plane in a network structure, the apparatus comprising: A module for receiving, at the control plane, a policy corresponding to communication between a first virtual routing and forwarding VRF segment and a second VRF segment of the network structure, in implementing a network policy regarding communication in the network structure; A module for receiving a first network layer prefix associated with a first subscriber device in the first VRF segment and a second network layer prefix associated with a second subscriber device in the second VRF segment; A module for receiving messages originating from a first VRF segment of the network structure and destined for a second VRF segment of the network structure, the messages having a source address and a destination address; as well as The module used to apply the policy and use the source address and the destination address to determine whether to allow the message to be provided to the second VRF segment.

21. The apparatus of claim 20, further comprising a module for implementing the method of claim 10 or 11.

22. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 11.

23. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 11.

Images