Vendor-independent profile based modeling of service access endpoints in a multi-tenant environment

Abstract

A vendor-independent profile-based modeling of service access endpoints in a multi-tenant environment is disclosed. An access profile includes configuration characteristics defined using device- and operating system-independent attributes. Thus, the access profile does not necessarily rely on or bind to any particular vendor or network OS. When a system administrator configures one or more service access points, the system administrator only needs to specify the vendor- and network OS-independent characteristics associated with the service access point. A configuration generator can generate vendor-specific and / or network-specific configuration commands and data from the vendor- and network OS-independent access profile attributes. The generated configuration commands and data can be provided to network devices hosting the service access points using vendor-specific and / or network OS-specific configuration application programming interfaces.

Description

[0001] This application is a divisional application, with its parent application having application number 201911337293.1, application date of December 23, 2019, and invention title "Modeling of Service Access Endpoints Based on Vendor-Independent Profiles in a Multi-Tenant Environment".

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 888,958, filed August 19, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to computer networks, and more specifically, to configuring network devices and servers. Background Technology

[0004] In a typical cloud data center environment, a large number of interconnected servers provide computing (e.g., compute nodes) and / or storage capacity to run various applications. For example, a data center includes facilities that host applications and services for its customers. For instance, a data center hosts all infrastructure equipment, such as network and storage systems, redundant power supplies, and environmental controls. In a typical data center, storage systems and application server clusters are interconnected via a high-speed switching fabric provided by one or more layers of physical network switches and routers.

[0005] A typical data center can include hundreds of physical network switches and thousands of storage and application servers. These devices within a data center are typically supplied by many different vendors and manufacturers, resulting in varying hardware and software configuration requirements and interfaces. Even within a single product line from a manufacturer, there may be different hardware configurations and different network operating systems (OS) using different configuration interfaces. For example, depending on the model and version of the switch hardware, a switch in a particular product line may have a different chipset than another switch in the same product line. Given the above, a typical data center can utilize many different configuration interfaces for the potentially thousands of network devices within the data center. Summary of the Invention

[0006] Network devices from different vendors running different network operating systems can be configured using vendor-independent, device-independent, and network operating system (OS)-independent configuration profiles (called access profiles). Vendor-, device-, and network OS-independent access profiles can specify various network operation characteristics using configuration interfaces or network OS attributes that are not bound to any specific vendor or device. Attributes that can be used in the access profile can be selected to represent a unified set of different characteristics or features used to model the system administrator's intent regarding the configuration of service access points. This contrasts with traditional systems that typically force users to use many different configuration commands and parameters that may be vendor-, device-, or network OS-specific. Therefore, access profiles are not necessarily dependent on or otherwise bound to any specific vendor or network OS. When a system administrator configures one or more service access points, the system administrator only needs to specify the vendor-, device-, and network OS-independent characteristics associated with the service access point. Configuration generators can generate vendor-specific, device-specific, and / or network OS-specific configuration commands and data from vendor-, device-, and network OS-independent access profile attributes. The generated device-specific configuration commands and data (e.g., parameters) can be provided to network devices at managed service access points using vendor-specific and / or network OS-specific configuration APIs.

[0007] In one example aspect, a method includes: obtaining hardware configuration information for each of a plurality of network devices; receiving an instruction to select a serving access point for a first network device among the plurality of network devices; receiving an instruction to select a device-independent service feature; associating an access profile with the selected serving access point based on the device-independent service feature, the access profile having one or more device-independent attributes defining the selected device-independent service feature; and determining one or more device-specific configuration commands and configuration parameters conforming to a first configuration interface of the first network device, based at least in part on the one or more device-independent attributes of the access profile associated with the selected serving access point.

[0008] In another example aspect, a software-defined networking (SDN) controller includes: one or more processors coupled to a memory including executable instructions to cause the one or more processors to: obtain hardware configuration information of each of a plurality of network devices on a network partially controlled by the SDN controller; receive an instruction to select a serving access point for a first network device among the plurality of network devices; receive an instruction to select a device-independent service feature; associate an access profile with the selected serving access point based on the device-independent service feature, the access profile having one or more device-independent attributes defining the selected device-independent service feature; and determine one or more device-specific configuration commands and configuration parameters conforming to a first configuration interface of the first network device, based at least in part on the one or more device-independent attributes of the access profile associated with the selected serving access point.

[0009] In another example aspect, a computer-readable medium including instructions is provided for causing one or more programmable processors to: obtain hardware configuration information of each of a plurality of network devices on a network partially controlled by an SDN controller; receive an instruction to select a serving access point for a first network device among the plurality of network devices; receive an instruction to select a device-independent service feature; associate an access profile with the selected serving access point based on the device-independent service feature, the access profile having one or more device-independent attributes defining the selected device-independent service feature; determine one or more device-specific configuration commands and configuration parameters conforming to a first configuration interface of the first network device, based at least in part on the one or more device-independent attributes of the access profile associated with the selected serving access point; and provide one or more device-specific configuration commands and configuration parameters to the first network device via the first configuration interface.

[0010] Details of one or more examples are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from the specification, drawings, and claims. Attached Figure Description

[0011] Figure 1 This is a block diagram illustrating an example computer network system based on the technology described herein.

[0012] Figure 2 It provides Figure 1 A block diagram showing further details of an example SDN controller in an example computer network system.

[0013] Figure 3 This is to show in further detail Figure 1 A block diagram of an example implementation of a data center in an example computer network system.

[0014] Figure 4 This is a block diagram illustrating network configuration data according to the technology described herein.

[0015] Figure 5 This is a flowchart illustrating a method for device-independent modeling of service access endpoints according to the technology described herein.

[0016] Throughout the text and in the accompanying drawings, the same reference numerals denote the same elements. Detailed Implementation

[0017] Figure 1 This is a block diagram illustrating an example computer network system 8 according to the technology described herein. The example computer network system 8 can be described using the following reference... Figures 2 to 5 The described technology is used for configuration.

[0018] exist Figure 1The example computer network system 8 includes data centers 10A to 10X (collectively referred to as "data center 10"), which are interconnected with each other via a service provider network 7 and with a customer network associated with tenant 11. Any or all of data centers 10A to 10X can be multi-tenant data centers. Multi-tenant data centers provide services to multiple customers (i.e., tenants).

[0019] Figure 1 An example implementation of a computer network system 8 and a data center 10A is shown, which hosts one or more cloud-based computing networks, computing domains, or projects, commonly referred to herein as a cloud computing cluster. Cloud-based computing clusters can coexist in a common overall computing environment, such as a single data center, or be distributed across different environments, such as different data centers. Cloud-based computing clusters can be, for example, different cloud environments, such as OpenStack cloud environments, Kubernetes cloud environments, or various combinations of other computing clusters, domains, networks, etc. Other implementations of the computer network system 8 and data center 10A may be suitable in other situations. Such implementations may include... Figure 1 The examples include a subset of components and / or may include Figure 1 Additional components not shown. Data centers 10B to 10X may include the same or similar features and are configured to perform the same or similar functions as described herein with respect to data center 10A.

[0020] exist Figure 1 In the example shown, data center 10A provides an operating environment for tenant 11's applications and services, and tenant 11 is coupled to data center 10A via service provider network 7 through gateway 108. Although combined Figure 1 The functions and operations described in the computer network system 8 can be shown as distributed across Figure 1 On multiple devices, but in other examples, attributed to Figure 1 Features and techniques of one or more devices may be implemented internally by native components of one or more such devices. Similarly, one or more such devices may include certain components and perform various techniques, which may be attributed to one or more other devices in the description herein. Furthermore, certain operations, techniques, features, and / or functions may be combined Figure 1 These operations, techniques, features, and / or functions may be described or performed by specific components, devices, and / or modules. In other examples, such operations, techniques, features, and / or functions may be performed by other components, devices, or modules. Therefore, some operations, techniques, features, and / or functions attributable to one or more components, devices, or modules may be attributable to other components, devices, and / or modules, even if not specifically described in this way herein.

[0021] Data Center 10A hosts infrastructure equipment such as network and storage systems, redundant power supplies, and environmental controls. Service Provider Network 7 can be coupled to one or more networks managed by other providers and can therefore form part of a large-scale public network infrastructure (e.g., the Internet). In some examples, Data Center 10A can represent one of many geographically distributed network data centers. Figure 1 As shown in the example, data center 10A is a facility that provides network services to tenant 11. Tenant 11 can be a collective entity, such as a business, government, or individual. For example, data center 10A can host network services for several businesses and end users, and therefore can be called a multi-tenant data center. Other exemplary services may include data storage, virtual private networks, traffic engineering, file services, data mining, scientific or supercomputing, etc. In some examples, data center 10A is a single network server, network peer, etc., that can provide services to multiple businesses and end users.

[0022] exist Figure 1 In the example, data center 10A includes a set of storage systems and application servers, including servers 12A to 12X (collectively referred to as “Server 12”) interconnected via a high-speed switching fabric 20 provided by one or more physical network switches and routers. Server 12 acts as a physical computing node in the data center. For example, each server 12 may provide an operating environment for the execution of one or more application workloads. As described herein, the terms “application workload” or “workload” are used interchangeably to refer to an application workload. Workloads may be executed in a virtualized environment, such as virtual machine 36, containers, or some type of virtualized instance, or in some cases, on a bare metal server that executes the workload directly rather than indirectly in a virtualized environment. Each server 12 may alternatively be referred to as a host computing device, or more simply, a host. Server 12 may execute one or more workloads on one or more virtualized instances, such as virtual machine 36, containers, or other virtualized execution environments used to run one or more services (e.g., Virtualized Network Functions (VNFs)). Some or all of Server 12 may be bare metal servers (BMS). A BMS may be a physical server dedicated to a specific tenant (i.e., a customer).

[0023] Switching infrastructure 20 may include top-of-rack (TOR) switches 16A to 16N coupled to the distribution layer of chassis switches 18A to 18M, and data center 10A may include one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection and / or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices. Data center 10A includes servers 12A to 12X interconnected via one or more layers of physical network switches and routers provided by switching infrastructure 20. Switching infrastructure 20 is provided by a set of interconnected TOR switches 16A to 16N (collectively referred to as "TOR switches 16") coupled to the distribution layer of chassis switches 18A to 18M (collectively referred to as "chassis switches 18"). In some examples, chassis switches 18 may operate as backbone nodes, and TOR switches 16 may operate as leaf nodes in data center 10A. Although not shown, the data center 10A may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection and / or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators or other network devices.

[0024] In this example, TOR switch 16 and chassis switch 18 provide redundant (multi-homed) connectivity to server 12 to gateway 108 and service provider network 7. Chassis switch 18 aggregates traffic flows and provides high-speed connectivity between TOR switches 16. TOR switch 16 may be a network device providing Layer 2 (MAC) and / or Layer 3 (e.g., IP) routing and / or switching capabilities. Both TOR switch 16 and chassis switch 18 may include one or more processors and memory and be capable of executing one or more software processes. Chassis switch 18 is coupled to gateway 108, which can perform Layer 3 routing to route network traffic between data center 10A and tenant 11 via service provider network 7.

[0025] Switching fabric 20 can perform Layer 3 routing to route network traffic between data center 10A and tenant 11 via service provider network 7. Gateway 108 is used to forward and receive packets between switching fabric 20 and service provider network 7. Data center 10A includes an overlay network that extends switching fabric 20 from physical switches 18, 16 to software or “virtual” switches. For example, virtual routers 30A to 30X, located in servers 12A to 12X respectively, can extend switching fabric 20 by being communicatively coupled to one or more physical switches located within switching fabric 20. Virtual switches can dynamically create and manage one or more virtual networks that can be used to communicate between application instances. In one example, virtual routers 30A to 30X act as overlay networks, providing the ability to decouple the virtual address of an application from the physical address (e.g., IP address) of one of the servers 12A to 12X on which the application is running. Each virtual network can use its own addressing and security scheme and can be considered orthogonal to the physical network and its addressing scheme. Various technologies can be used to transmit packets within and between virtual networks via the physical network.

[0026] According to one or more examples of this disclosure, a software-defined networking (“SDN”) controller 132 provides a logically and, in some cases, physically centralized controller for facilitating the operation of one or more virtual networks within a data center 10A. The terms SDN controller and Virtual Network Controller (“VNC”) are used interchangeably in this disclosure. In some examples, the SDN controller 132 operates in response to configuration input received from an orchestration engine 130 via a northbound API 131, which in turn operates in response to configuration input received from an administrator 24 operating a user interface device 129 (UI device 129). The administrator may be a structure administrator responsible for the overall operation of the data center or a system administrator of a data center tenant. In this case, the system administrator may be able to see the service access points of network devices assigned to a tenant, and may not be able to see or interact with network devices assigned to a different tenant.

[0027] In some respects, the SDN controller 132 may be part of a high availability (HA) cluster and provide HA cluster configuration services. Additional information regarding the SDN controller 132 operating with other devices or other software-defined networks in Data Center 10A can be found in International Application No. PCT / US2013 / 044378, filed June 5, 2013, entitled “PHYSICAL PATH DETERMINATION FOR VIRTUALNETWORK PACKET FLOWS”; and U.S. Patent Application Serial No. 15 / 476,136, filed March 31, 2017, entitled “SESSION-BASED TRAFFIC STATISTICS LOGGING FOR VIRTUAL ROUTERS”, the entire contents of which are incorporated herein by reference as fully set forth herein.

[0028] For example, an SDN platform can be used in data center 10 to control and manage network behavior. In some cases, the SDN platform includes logically centralized and physically distributed SDN controllers (e.g., SDN controller 132) and a distributed forwarding plane in the form of virtual routers that extend the network from physical routers and switches in the data center switching infrastructure to a virtual overlay network hosted in virtual servers.

[0029] In some examples, SDN controller 132 manages the network and network services, such as load balancing and security, and allocates resources from server 12 to various applications via southbound API 133. That is, southbound API 133 represents a set of communication protocols used by SDN controller 132 to ensure that the actual state of the network equals the desired state specified by orchestration engine 130. For example, one such communication protocol may include a message forwarding communication protocol, such as XMPP. For example, SDN controller 132 handles high-level requests from orchestration engine 130 by configuring physical switches, such as TOR switch 16, chassis switch 18, and switching fabric 20; physical routers; physical service nodes, such as firewalls and load balancers; and virtual services, such as virtual firewalls in a virtualized environment. SDN controller 132 maintains routing, network, and configuration information in a state database. SDN controller 132 transfers appropriate subsets of routing and configuration information from the state database to virtual routers 30A to 30X or agents 35A to 35X on each server 12A to 12X. Figure 1 (in the context of "AGENT").

[0030] As described herein, each server 12 includes corresponding forwarding components 39A to 39X (hereinafter referred to as "forwarding components 39"), which perform data forwarding and traffic statistics collection functions for the workloads executed on each server 12. Figure 1 In the example, each forwarding component is described as a virtual router that performs packet routing and coverage functions. Figure 1 The "VR30A to VR 30X" in the text) and the virtual agent that communicates with the SDN controller 132 and configures the virtual router 30 as a response ( Figure 1 (VA 35A to VA 35X).

[0031] In this example, each virtual router 30A to 30X implements at least one routing instance for the corresponding virtual network within data center 10, routing packets to the appropriate virtual machine, container, or other element executing within the operating environment provided by the server. For example, packets received by the virtual router of server 12A from the underlying physical network structure may include an external header to allow the physical network structure to tunnel the payload or "internal packet" to the physical network address of the network interface of server 12A executing the virtual router. The external header may include not only the physical network address of the server's network interface but also a virtual network identifier, such as a Virtual Extensible Local Area Network (VxLAN) label or Multiprotocol Label Switching (MPLS) label identifying a virtual network and the corresponding routing instance executed by the virtual router. The internal packet includes an internal header with a destination network address that conforms to the virtual network addressing space of the virtual network identified by the virtual network identifier.

[0032] exist Figure 1In the example, SDN controller 132 learns routes and other information (e.g., configuration) and distributes it to all compute nodes in data center 10. VR agent 35, a forwarding component 39 running inside the compute nodes, typically programs the data forwarding element (virtual router 30) with the forwarding information when it receives routing information from SDN controller 132. SDN controller 132 sends the routing and configuration information to VR agent 35 using a messaging protocol (e.g., XMPP protocol semantics) instead of a heavier-weighted protocol (e.g., a routing protocol such as BGP). In XMPP, SDN controller 132 and the agent transmit routes and configurations on the same channel. When receiving routes from VR agent 35, SDN controller 132 acts as a messaging protocol client, and in this case, VR agent 35 acts as a messaging protocol server. Conversely, when SDN controller sends routes to VR agent 35, SDN controller 132 acts as a messaging protocol server to VR agent 35, which is a messaging protocol client. SDN controller 132 can send security policies to VR agent 35 applied to virtual router 30.

[0033] User interface device 129 can be implemented as any suitable computing system, such as a mobile or non-mobile computing device operated by a user and / or administrator 24. According to one or more aspects of this disclosure, user interface device 129 can, for example, represent a workstation, laptop or notebook computer, desktop computer, tablet computer, smartphone, or any other computing device that can be operated by a user and / or present a user interface.

[0034] In some examples, orchestration engine 130 manages the functionality of data center 10A, such as compute, storage, networking, and application resources. For instance, orchestration engine 130 can create virtual networks for tenants (i.e., customers) within or between data centers. Orchestration engine 130 can attach workloads (WLs) to tenants' virtual networks. Orchestration engine 130 can connect tenants' virtual networks to external networks, such as the Internet or a VPN. Orchestration engine 130 can implement security policies on a set of workloads or at the boundary of tenant networks. Orchestration engine 130 can deploy network services (e.g., load balancers) within tenants' virtual networks.

[0035] In some examples, SDN controller 132 manages the network and network services, such as load balancing and security, and allocates resources from server 12 to various applications via southbound API 133. That is, southbound API 133 represents a set of communication protocols used by SDN controller 132 to ensure that the actual state of the network equals the desired state specified by orchestration engine 130. For example, SDN controller 132 fulfills high-level requests from orchestration engine 130 by configuring physical switches, such as TOR switch 16, chassis switch 18, and switching fabric 20; physical routers; physical service nodes, such as firewalls and load balancers; and virtual services, such as virtual firewalls in VMs. SDN controller 132 maintains routing, networking, and configuration information in a state database.

[0036] Typically, traffic between any two network devices (e.g., between network devices (not shown) within switching fabric 20, or between server 12 and tenant 11, or between servers 12) can traverse the physical network using many different paths. For example, there may be several different equal-cost paths between two network devices. In some cases, packets belonging to network traffic from one network device to another can be distributed across a variety of possible paths at each network switching node using a routing strategy called multi-path routing. For example, the Internet Engineering Task Force (IETF) RFC 2992, “Analysis of an Equal-Cost Multi-Path Algorithm,” describes a routing technique for routing packets along equal-cost multi-path routes. The technique analysis in RFC 2992 describes a specific multi-path routing strategy that involves assigning flows to bins by hashing packet header fields that send all packets from a particular traffic flow over a single deterministic path.

[0037] Virtual routers (Virtual Router 30A to Virtual Router 30X, in) Figure 1The virtual router (collectively referred to as "virtual router 30") performs multiple routing instances for the corresponding virtual networks within data center 10A and routes packets to the appropriate workloads executed within the operating environment provided by server 12. Each server 12 may include a virtual router. For example, packets received by virtual router 30A of server 12A from the underlying physical network structure may include an external header to allow the physical network structure to tunnel the payload or "internal packet" to the physical network address of the network interface of server 12A. The external header may include not only the physical network address of the server's network interface but may also include a virtual network identifier, such as a VxLAN label or Multiprotocol Label Switching (MPLS) label identifying a virtual network and the corresponding routing instance performed by the virtual router. Internal packets include an internal header with a destination network address that conforms to the virtual network addressing space of the virtual network identified by the virtual network identifier.

[0038] The aforementioned physical and virtual resources (servers, switches, virtual routers, etc.) can be allocated to tenant 11 for exclusive or shared use. Resource allocation to a specific tenant can be directed by an administrator 24 (e.g., a infrastructure administrator) operating the user interface device 129. Data center 10A can have thousands of chassis switches 18 and TOR switches 16, as well as hundreds of servers 12. These network devices can include different models from the same manufacturer and devices from many different manufacturers. Furthermore, these devices can run various network operating environments (OS). A technical challenge in this heterogeneous data center environment is that traditional systems do not provide administrators with any means to configure devices from different manufacturers running different network OSes using a consistent interface, thus ensuring that the configuration reflects the administrator's overall intent for the data center configuration. Instead, to configure devices, administrators typically have to utilize many different interfaces, which may be specific to the manufacturer, model, and network OS of the device being configured. Therefore, administrators may need to utilize many different interfaces and commands to configure network devices in the data center. The various configuration interfaces can be challenging for administrators, potentially leading to technical issues such as device misconfiguration that could prevent devices in Data Center 10A from communicating effectively with each other or from communicating at all.

[0039] One practical application of the aforementioned technology is that network devices from different vendors with varying hardware configurations and network operating systems can be configured using vendor-independent, device-independent, and operating system-independent configuration interfaces. Reducing the workload and expertise required to configure various devices in a data center are some examples of the advantages that these methods can offer compared to previous configuration approaches, and these advantages can be further enhanced by avoiding errors and improving network scalability.

[0040] In some aspects, the architecture management server 140 can discover network devices and obtain hardware configuration information 146 from them. The hardware configuration information 146 can be maintained in a configuration database 142. The hardware configuration information 146 may include the number and type of network devices in the data center 10A. Furthermore, the hardware configuration information 146 may include hardware manufacturer information (e.g., product manufacturer and model, version identifier, version level, serial number, etc.), network interface information (e.g., manufacturer, model, network type, supported protocols, communication speed, etc.), available storage, processor type, and other information about the hardware and components of the network devices (e.g., switches, routers, or servers). The hardware configuration information may include information about chipsets that can be used on a particular network device. Additionally, the configuration database 142 may maintain other configuration or operational data. The hardware configuration information 146 can be referenced below. Figure 4 Organize the data using a described data model.

[0041] User interface device 129 can be used (e.g., by administrator 24) to assign access profile 148 to service access endpoints within the data center. Such service access endpoints can be virtual interfaces supported by physical ports or network interfaces of switches, routers, and servers listed and described in the hardware configuration information 146 of the data center 10A. As an example, a service access point can be an interface from a network device to a virtual local area network (VLAN) in an Ethernet Virtual Private Network (EVPN) VXLAN within the data center. Tenants can receive various communication and application services via the service access endpoint.

[0042] Access profile 148 may include data describing service characteristics of the service access endpoint in a vendor-independent, device-independent, and operating system-independent manner. The term "device-independent" will be used to describe features, attributes, commands, or parameters that may be vendor-independent, device-independent, and / or network OS-independent. In other words, the device-independent service characteristics described in access profile 148 are not necessarily tied to any specific vendor, network device, or network OS. These characteristics may include Class of Service (CoS) characteristics, communication speed and bandwidth characteristics, and communication protocol characteristics. In some aspects, access profile 148 may include a set of device-independent service characteristics provided by different hardware vendors, software vendors, network OSes, etc., which may be specified as part of the access endpoint configuration. The parameters associated with device-independent services may vary from access profile to access profile based on the user's configuration intent. As an example only, a first access profile may be associated with a user intent to provide high-quality service (QoS) via the service access endpoint, while a second access profile may be associated with a user intent to provide lower QoS. In this example, device-independent service characteristics may include one or more attributes defining high QoS. Attributes may also be represented in a device-independent manner and therefore may be referred to as device-independent attributes. As an example, attributes associated with high QoS include high bandwidth and low latency. Therefore, device-independent service characteristics of high QoS can include attributes specifying high bandwidth and low latency values. Access profile 148 may have a name, tag, or other identifier that uniquely identifies the access profile.

[0043] Access profile 148 and its corresponding network device and port assignments can be maintained in configuration database 142. For example, the user interface available in user interface device 129 can provide identifiers for network devices and hardware discovered in data center 10A. Furthermore, user interface device 129 can provide a user interface for assigning access profile 148 to discovered network devices and ports listed and described in hardware configuration information 146. Although shown in a single configuration database 142, hardware configuration 146 and access profile 148 can be maintained in separate databases.

[0044] Figure 2This is a block diagram providing further details of an example SDN controller 132 for configuring a target network device 202 according to the techniques disclosed herein. The target network device 202 (e.g., 202A through 202D) can be a network device configured as part of a new data center configuration, a network device configured as a result of adding a tenant to an existing data center, or a target network device already assigned to a tenant being reconfigured. The techniques described herein are not limited to any particular configuration purpose. A network device can be referred to as a target network device when it is the target of configuration commands and data. In some aspects, a target network device can be a physical device, such as a physical switch, router, or server. In some aspects, a target network device can be a virtual device, such as a virtual machine, virtual server, virtual router, VLAN interface, cloud-based virtual machine, or other virtual device. In some aspects, the SDN controller 132 may include a configuration generator 208 that generates device-specific configuration commands and data (e.g., parameters) that can be used to configure network device 202 in data center 10A. Figure 2 In the example shown, two tenants 208 (208A and 208B) are assigned a target network device 202 from n network devices in data center 10A. The target network device 202 can originate from any of many k vendors. Figure 2 The suppliers are labeled A through K. Therefore, in Figure 2 In the example shown, tenant 208A has two target network devices 202A and 202B assigned to it, and tenant 208B has two target network devices 202C and 202D assigned to it. Target network device 202A is from vendor A, target network devices 202B and 202C are provided by vendor B, and target network device 202D is provided by vendor K. Target network devices 202A and 202B can be different types, models, versions, etc., and can run different network OSes. For the sake of illustration of various aspects of this disclosure, it will be assumed that target network devices 202B and 202C are from the same vendor, are the same device type, have the same version, and run the same network OS.

[0045] exist Figure 2In the example shown, the network device has access endpoints 210 (e.g., 210A through 210D). Access endpoint 210 can be a network port, a line card network interface, etc. Although only one access endpoint is shown for each device 202, network device 202 may have more than one access endpoint 210. Furthermore, all network devices implement a vendor-specific configuration application programming interface (API) 204. Target network device 202A implements configuration API 204A. Because target network devices 202B and 202C are from the same vendor, are of the same device type, and have the same version and network OS running on them, they can also have the same configuration API 204B. Target network device 202D may implement configuration API 204K.

[0046] Configuration generator 208 can also implement configuration API 204, corresponding to the configuration API used in the data center. Therefore, in Figure 2 In the example shown, configuration generator 208 implements configuration APIs 204A, 204B, and 204K to communicate with the corresponding configuration APIs 204A, 204B, and 204K on target network devices 202A to 202D.

[0047] Configuration generator 208 can read hardware configuration information 146 and vendor-independent access profile 148 to determine vendor-specific configuration data and commands used to configure network device 202. Access profile 148 can have various attributes 210, including data that defines or specifies the characteristics and features of the target network device 202 associated with access profile 248 in a vendor-independent, device-independent, and network OS-independent manner. Attributes available for access profile 148 can be selected to represent different characteristics, features, and parameters to model the system administrator's intent regarding configuring the service access point, rather than vendor-specific configuration commands and parameters. In some aspects, one or more attributes 210 can be related to CoS or QoS. For example, one or more attributes 210 can specify the extent to which, and what CoS marking and shaping, should be applied to traffic generated at access endpoint 210. In some aspects, one or more attributes 210 can specify how broadcast unknown unicast and multicast traffic should be limited to prevent network flooding or storms. For example, one or more attributes 210 can specify thresholds in terms of bit rate or packet rate. Independent thresholds can be set for broadcast rate, multicast rate, and unknown unicast rate. Other attribute 210 can be used to specify or define other desired service access endpoint characteristics.

[0048] In some respects, access profiles can be organized as Extensible Markup Language (XML) files. However, other formats may be used, and are within the scope of this disclosure.

[0049] The system can receive instructions that the target device 202 will be configured. For example, the orchestration engine 130 can instruct the SDN controller 132 that the target device 202 needs to be configured. As another example, a user (e.g., administrator 24) can create or update an access profile 148 associated with device 202. When configuring (or reconfiguring) the target device 202, the configuration generator 208 can read the hardware configuration information 146 associated with the target device 202 to determine the vendor associated with the target device 202, the device type of the target device 202, and / or the model information of the target device 202. The configuration generator can also read the access profile 148 associated with the target device 202 to obtain device-independent, vendor-independent, and / or network OS-independent information regarding the expected device-independent service characteristics of the target device 202. The configuration generator 208 can use the hardware configuration information and the device-independent attributes of the expected device-independent service characteristics to generate device-specific configuration commands and / or configuration data to provide to the target device 202 via a vendor-specific configuration API 204 suitable for that device. As used herein, device-specific configuration commands or parameters refer to configuration commands or parameters that may be specific to a particular vendor, device, or network operating system. In other words, device-specific configuration commands or parameters may be specific to a particular vendor, device, device category, or network operating system, and therefore may not be irrelevant to the device vendor, the device itself, or the network operating system running on the device.

[0050] SDN controller 132 may include one or more processors that execute software instructions, such as software instructions for defining software or computer programs, stored in a computer-readable storage medium, such as a non-transitory computer-readable medium, including storage devices (e.g., disk drives or optical drives) and / or memory (e.g., flash memory, random access memory, or RAM) or any other type of volatile or non-volatile memory, the memory storing instructions that cause one or more processors to perform the techniques described herein. Alternatively or additionally, SDN controller 132 may include dedicated hardware, such as one or more integrated circuits, one or more application-specific integrated circuits (ASICs), one or more dedicated processors (ASSPs), one or more field-programmable gate arrays (FPGAs), or any combination of one or more of the foregoing examples of dedicated hardware, for performing the techniques described herein.

[0051] The SDN controller 132 can be executed by one or more compute nodes, which can correspond to any form of computing resource. Each compute node can be a physical computing device, or a component of a cloud computing system, server cluster, and / or server group (or a portion thereof) that provides services to client devices and other devices or systems. Therefore, any compute node can represent a physical computing device, a virtual computing device, a virtual machine, a container, and / or other virtual computing device.

[0052] Figure 3 This is to show in further detail Figure 1 A block diagram illustrating an example implementation of a data center in an example computer network system. Figure 3 In the example, data center 10A includes a fabrication management server 140 communicatively coupled to management switch 302. Other data center components, such as SDN controller 132, server 12, chassis switch 18, and TOR switch 16, are also communicatively coupled to management switch 302. The management switch, server connections to the management switch, and switch connections form an out-of-band management network.

[0053] Each server 12 may include a management network interface 304, an IP structure switching interface 306, and an Intelligent Platform Management Interface (IPMI) 312. The management network interface 304 provides a hardware and / or software interface for transmitting data between servers 12A to 12X and the management switch 302. The IP structure switching interface 306 provides a hardware and / or software interface for transmitting data between servers 12A to 12X and the TOR switches 16A to 16N.

[0054] IPMI 312 provides an interface to a computing system (e.g., any server 12) that can be used to monitor and manage the operation of the computing system independently of its main processor and operating system. For example, IPMI 312 can enable system administrators to manage computing systems that are powered down, not fully configured, or lack the ability to operate or communicate as expected.

[0055] The structure management server 140 can control the execution of various discovery and configuration-related workflows. As described above, the data collected, generated, and used by the structure management server 140 can be maintained in the configuration database 142 as hardware configuration information 146.

[0056] Configuration generator 208 can use the hardware configuration information 148 collected as described above and access profile 148 to configure some or all of chassis switch 18, TOR switch 16 and server 12.

[0057] Figure 4This is a block diagram illustrating an example network configuration data model according to the techniques described herein. The example network configuration data model can be used to specify a data structure for data stored in a data store (e.g., configuration database 142). Figure 4 The example network configuration data model presented can correspond to hardware configuration information 146, which is added as a result of the structure management server 140 discovering the network device.

[0058] In some respects, network configuration data structures can be added as a result of the IP structure discovery workflow executed by the structure management server 140. After executing the IP structure discovery workflow, the structure management server 140 learns configuration data about the switches. Figure 4 In the example shown, physical router data structure 402 may include data about a specific TOR switch identified as "QFX_TOR_1". For example, QFX_TOR_1 may be assigned to TOR switch 12A ( Figure 2 The identification label. Furthermore, in Figure 4 In the example shown, the structure management server 140 has discovered three ports on switch QFX_TOR_1 and, in response, creates physical interface data structures 404A, 404B, and 404C to represent physical ports GE_001, GE_002, and GE_003 on switch QFX_TOR_1. Data structures for logical interfaces (not shown) that can be associated with the physical interface data structures can also be created by the structure management server 140.

[0059] Figure 4 Further examples of network configuration data structures that can be added as a result of the server discovery workflow executed by the structure management server 140 are shown. The description will refer to a single discovered server (e.g., server 12A). Figure 4 This is an example data structure. Similar data structures can be added to other servers. Figure 4 In the example shown, the structure management server 140 has discovered server 12A and created a terminal system data structure 410 describing server 12A. In this example, server 12A is assigned the identifier "INFRA_BMS_1". The structure management server 140 has discovered that server 12A has three ports, and in response, can create three port data structures 408A, 408B, and 408C to store data describing the ports. Furthermore, the structure management server 140 has discovered that the three ports are physically linked to three corresponding switch ports, and creates references from each of the port data structures 408A to 408C describing the three server 12A ports to the corresponding physical interface data structures 404A to 404C describing the physical interfaces of the switches.

[0060] Furthermore, the server discovery workflow and IP structure discovery workflow executed by the structure management server 140 can collect information that can be used to create or update node profile data structures 412 to 416. Node profile data structures 412 to 416 can describe aspects of the specific hardware associated with the switch (e.g., chassis switch 18 or TOR switch 16) or server 12 described by the physical router data structure 402. Figure 4 In the example shown, node profile data structure 412 includes data identifying the server's vendor or manufacturer (e.g., "VENDOR 1") and the roles the server can support. Hardware data structure 414 can describe a specific type of server (e.g., "SERVERTYPE"). For example, the server type can identify a brand name or other labels that identify the server type. Card data structure 416 can include data describing the network interfaces available on the identified server.

[0061] The node profile data structure 412 can be linked to the hardware platform data structure 426. The hardware platform data structure 426 may include fields identifying the hardware platforms supported by the node profile. For example, the hardware platform data structure 426 may include fields identifying the manufacturer / model of the server or physical router, the processor type of the server or physical router, etc. The node profile 412 can be linked to a data structure (not shown) describing the line cards and roles associated with the node.

[0062] Figure 5 This is a flowchart illustrating a method for vendor-independent, device-independent, and network OS-independent modeling of service access endpoints according to the techniques described herein. In some aspects, these operations can be performed during the initial configuration of network devices in a new data center. In further aspects, these operations can be performed when new network devices are added to the data center. In still other aspects, these operations can be performed when network devices are reconfigured.

[0063] In some respects, hardware configuration information (502) can be obtained for network devices (e.g., network devices in a data center). Network devices in a data center may be manufactured by various vendors and can run various operating systems. As mentioned above, based on the vendor supplying the network device, the model of the network device, the version of the network device, etc., the network device may have various different configuration interfaces. In some respects, hardware configuration information can be obtained through one or more discovery processes. For example, when initially configuring a data center, the discovery operation can be initiated by various workflows. In some respects, workflows can enable the infrastructure management server to automatically obtain hardware configuration information from devices on the infrastructure management network. For example, the workflow can utilize IPMI or other discovery technologies to obtain hardware configuration information from switches and servers on the network. The obtained information can be combined with other information available from the system administrator, such as VLANs, subnets, loopbacks, Autonomous System Numbers (ASNs), etc., that will be configured in the data center network. The infrastructure management server can store this information as part of the hardware configuration information 146 in the configuration database 142 of the data center network.

[0064] In some respects, system administrators or other users can create access profiles (504). Access profiles can include data defining desired characteristics of the service access endpoint in a vendor-independent, device-independent, and / or network OS-independent manner. In other words, these characteristics can be defined so that they are not tied to any particular vendor, device, or network operating system's scheme for defining characteristics. In some respects, access profiles can define features specifying desired CoS, QoS, and / or network storm / flood prevention characteristics. For example, users can set one or more attributes of the access profile to specify the extent and what CoS marking and shaping should be applied to traffic generated at the access endpoint. Furthermore, users can set one or more attributes of the access profile to specify how network storms or flooding situations should be handled. For example, users can specify how to limit broadcast, unknown unicast, and multicast (BUM) traffic to prevent network flooding or storms. Users can set one or more attributes to specify thresholds for bit rate or packet rate. In some respects, users can set independent thresholds for broadcast rate, multicast rate, and unknown unicast rate. Users can set additional attributes in the access profile that can be used to specify or define other desired service access endpoint characteristics.

[0065] The configuration generator can receive instructions to configure the service access point (506). For example, a system administrator or other user can utilize user interface device 129 ( Figure 1The system administrator selects one or more service access points to configure. In some cases, the system administrator can specify a particular port or line card on the switch or server to be configured. In other cases, the user can select a specific VLAN to configure. Service access points that are part of a VLAN can be indicated to the configuration generator as the service access points to be configured. The system administrator can also select other groups, such as port groups, to indicate which service access points to configure.

[0066] The configuration generator can receive an indication (508) of desired device-independent service characteristics to be used for configuring the indicated service access point. For example, a system administrator can specify desired device-independent service characteristics and determine an existing access profile with device-independent attributes corresponding to the desired characteristics, or can create an access profile with device-independent attributes of the specified desired characteristics. The configuration generator can receive desired CoS, QoS, or broadcast storm / flood control characteristics. The system can assign an access profile to the indicated service access point based on the indicated device-independent service characteristics (510).

[0067] For each indicated service access point, the configuration generator can generate device-specific configuration commands and configuration data (e.g., configuration parameters) (512) based on the hardware configuration of the network device hosting the indicated service access point (as determined at 502) and the access profile associated with the service access point. In some aspects, the configuration generator can use the hardware configuration information associated with the network device hosting the service access point to determine the device-specific API used to generate configuration commands and data conforming to the device-specific API. The configuration generator can also use device-independent attributes from the access profile associated with the indicated service access point to generate configuration commands and data. For example, the configuration generator can translate device-independent attribute values ​​into configuration commands and data conforming to vendor-specific and / or network OS-specific configuration APIs supported by the network device hosting the indicated service access point.

[0068] The configuration generator can then use the vendor-specific configuration API to provide the generated vendor-specific configuration commands and data to the network device at the service access point indicated by the hosting provider (514).

[0069] As described above, a configuration generator can transform device- and network OS-independent service access point characteristics into vendor- and network OS-specific configuration commands and data. A technical problem with traditional systems is that users typically have to use different vendor-specific configuration APIs based on the network device's vendor and the network OS running on the device. This lack of consistency in configuration APIs increases the likelihood of misconfiguration and erroneous network operations. Therefore, the technology described herein provides a unified, vendor-independent solution to this problem for configuring service access points on different network devices.

[0070] The techniques described herein can be implemented using hardware, software, firmware, or any combination thereof. Various features described as modules, engines, units, or components can be implemented together in an integrated logic device, or individually as discrete but interoperable logic devices or other hardware devices. In some cases, various features of an electronic circuit can be implemented as one or more integrated circuit devices, such as integrated circuit chips or chipsets.

[0071] If implemented in hardware, this disclosure may relate to devices such as processors or integrated circuit devices (e.g., integrated circuit chips or chipsets). Alternatively or additionally, if implemented in software or firmware, these techniques may be implemented at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, the computer-readable data storage medium may store these instructions executed by a processor.

[0072] Computer-readable media can form part of a computer program product, which may include packaging materials. Computer-readable media may include computer data storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, etc. In some examples, the article of manufacture may include one or more computer-readable storage media.

[0073] In some examples, computer-readable storage media may include non-transitory media. The term "non-transitory" can mean that the storage medium is not contained in a carrier wave or propagating signal. In some examples, non-transitory storage media may store data that changes over time (e.g., in RAM or cache).

[0074] The code or instructions can be software and / or firmware executed by processing circuitry, which includes one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some aspects, the functionality described in this disclosure can be provided within software or hardware modules.

Claims

1. A network device configuration method, comprising: Receive an instruction to select a physical or virtual interface for a first network device among a plurality of network devices, including a second network device; Receive an instruction to select device service features, which are not vendor-specific, wherein the device service features include service type CoS tagging features or CoS shaping features; Determine or create an access profile having one or more device-independent attributes that define selected device service characteristics, and associate the access profile with the physical or virtual interface based on the device service characteristics; and Based at least in part on one or more device attributes of the access profile associated with the physical or virtual interface, one or more device-specific configuration commands and configuration parameters conforming to the first configuration interface of the first network device are determined.

2. The method according to claim 1, further comprising: The first configuration interface provides the first network device with one or more device-specific configuration commands and configuration parameters.

3. The method according to claim 1, wherein, The virtual interface includes a Virtual Local Area Network (VLAN) interface.

4. The method according to claim 1, wherein, The physical interface includes the network interface of a switch, router, or server.

5. The method according to claim 1, wherein, The first network device has a second configuration interface that is different from the first configuration interface, and the method further includes: determining one or more device-specific configuration commands and configuration parameters that conform to the second configuration interface, based at least in part on one or more device attributes of an access profile associated with the physical or virtual interface of the first network device.

6. The method according to claim 5, wherein, One or more attributes defining the device service characteristics are not specific to a first supplier and are not specific to a second supplier, wherein the first supplier is different from the second supplier.

7. The method according to any one of claims 1-6, further comprising: Receive and selectively communicate with multiple network devices via Virtual Local Area Networks (VLANs). Specifically, determining the one or more device-specific configuration commands and configuration parameters includes determining one or more device-specific configuration commands and configuration parameters for each of the plurality of network devices.

8. A software-defined networking (SDN) controller, comprising: One or more processors are coupled to a memory, the memory including executable instructions to cause the one or more processors to: Receive an instruction to select a physical or virtual interface for a first network device among a plurality of network devices, including a second network device; Receive an instruction to select device service features, which are not vendor-specific, wherein the device service features include service type CoS tagging features or CoS shaping features; Determine or create an access profile having one or more device-independent attributes that define selected device service characteristics, and associate the access profile with the physical or virtual interface based on the device service characteristics; and Based at least in part on one or more device attributes of the access profile associated with the physical or virtual interface, one or more device-specific configuration commands and configuration parameters conforming to the first configuration interface of the first network device are determined.

9. The SDN controller according to claim 8, wherein, The instructions also include: Instructions for providing the one or more device-specific configuration commands and configuration parameters to the first network device via the first configuration interface.

10. The SDN controller according to claim 8, wherein, The virtual interface includes a Virtual Local Area Network (VLAN) interface.

11. The SDN controller according to claim 8, wherein, The physical interface includes the network interface of a switch, router, or server.

12. The SDN controller according to claim 8, wherein, The first network device has a second configuration interface different from the first configuration interface, and wherein the instructions further include: instructions for determining one or more device-specific configuration commands and configuration parameters conforming to the second configuration interface, based at least in part on one or more device attributes of an access profile associated with the physical or virtual interface of the first network device.

13. The SDN controller according to claim 12, wherein, One or more attributes defining the device service characteristics are not specific to a first supplier and are not specific to a second supplier, wherein the first supplier is different from the second supplier.

14. The SDN controller according to claim 12, wherein, The first network device is assigned to at least one of the first tenant of the data center or the second tenant of the data center.

15. The SDN controller according to any one of claims 8-14, wherein, The first network device includes a virtual device.

16. A non-transitory computer-readable medium comprising instructions for causing one or more programmable processors to perform the following: Receive an instruction to select a physical or virtual interface for a first network device among a plurality of network devices, including a second network device; Receive an instruction to select device service features, wherein the device service features are not vendor-specific, wherein, The device service features include service type CoS tagging features or CoS shaping features; Determine or create an access profile having one or more device-independent attributes that define the selected device service characteristics, and associate the access profile with the physical interface or virtual interface according to the device service characteristics; and Based at least in part on one or more device attributes of the access profile associated with the physical or virtual interface, one or more device-specific configuration commands and configuration parameters conforming to the first configuration interface of the first network device are determined.

17. The non-transitory computer-readable medium according to claim 16, wherein, The first network device has a second configuration interface different from the first configuration interface, and wherein the instructions further include: instructions for determining one or more device-specific configuration commands and configuration parameters conforming to the second configuration interface, based at least in part on one or more device attributes of an access profile associated with the physical or virtual interface of the first network device.

Images