Juniper Networks, Inc.

Hewlett-packard Development Company, L.p.

Atul S Moghe

Jacopo Pianigiani

Tong Jiang

Ankur Tandon

Rishabh Ramakant Tulsian

Sukhdev S Kapur

Vivekananda Shenoy

Ignatious Johnson Christober

Joseph Williams

Suresh K Balineni

Michael Henkel

Vinod Nair

Ashok Ganesan

Sridevi JeevaRaj

Manish Krishnan

Michal Styszynski

Sahana Sekhar Palagrahara Chandrashekar

Soumil Ramesh Kulkarni

Jeba Paulaiyan

Thomas Murray

Prasad Miriyala

Kiran N Kasim

Akshaya Muralidharan

Édouard Thuleau

Jeffrey S Marshall

Anantharamu Suryanarayana

Mahesh Sivakumar

Gurminder Singh

Fnu Nadeem

Srinivas Akkipeddi

Nagendra Prasath Maynattamai Prem Chandran

Dale Davis

Shivayogi Ugaji

Praveen Karadakal

Parag Sanghvi

Patrik Bok

Nagendra Maynattamai

Supriya Sridhar

Sai G Sitharaman

Thomas A Murray

In an example, a method includes processing, by an application programming interface (API) server implemented by a configuration node of a network controller for a software-defined networking (SDN) architecture system, requests for operations on native resources of a container orchestration system; processing, by a custom API server implemented by the configuration node, requests for operations on custom resources for SDN architecture configuration, wherein each of the custom resources for SDN architecture configuration corresponds to a type of configuration object in the SDN architecture system; detecting, by a control node of the network controller, an event on an instance of a first custom resource of the custom resources; and by the control node, in response to detecting the event on the instance of the first custom resource, obtaining configuration data for the instance of the first custom resource and configuring a corresponding instance of a configuration object in the SDN architecture.

Cloud native software-defined network architecture

An example data center system includes server devices hosting data of a first tenant and a second tenant of the data center, network devices of an interconnected topology coupling the server devices including respective service virtual routing and forwarding (VRF) tables, and one or more service devices that communicatively couple the network devices, wherein the service devices include respective service VRF tables for the first set of server devices and the second set of server devices, and wherein the service devices apply services to network traffic flowing between the first set of server devices and the second set of server devices using the first service VRF table and the second service VRF table.

Service chaining among devices of interconnected topology

A system for configuring a data center includes a fabric management server coupled to a management switch. A provisional Software Defined Networking (SDN) controller executing on the fabric management server can discover physical servers coupled to the management switch, receive network interface configuration information from the physical servers, and use the discovered network interface configuration information to determine a configuration for switches and servers coupled to an IP fabric. The configuration can be migrated to a full functionality SDN controller.

Initializing network device and server configurations in a data center

In general, techniques are described for a creating a virtual network router within a software defined network (SDN) architecture. A network controller for the SDN architecture system may include processing circuitry that is configured to execute a configuration node and a control node. The configuration node may process a request by which to create a virtual network router (VNR), where the virtual network router may cause the network controller to interconnect a first virtual network (VN) and a second VN. The VNR may represent a logical abstraction of one or more policies that cause import and/or export of routing information between the first VN and the second VN. The control node configures the first VN and the second VN according to the one or more policies to enable the import and/or the export of routing information between the first VN and the second VN via the VNR.

Virtual network routers for cloud native software-defined network architectures

A virtual port group abstraction can facilitate automated configuration of devices in a data center. For example, a data center administrator can define a virtual port group to include a set of logical and physical interfaces for devices allocated to a particular department or other group within a company. An administrator for the department can then utilize a user interface to perform actions with respect to the virtual port group. The actions can include configuration actions, modeling actions and/or deployment actions. An action received by a network management controller such as a Software-Defined Networking (SDN) controller can be converted into the appropriate actions for the relevant logical and physical interfaces that are configured to be part of the virtual port group.

Virtual port group

An example controller device that manages a plurality of network devices includes one or more processing units implemented in circuitry and configured to receive, via an application programming interface (API) framework, an indication of an intent. The intent includes data indicating an update to a data structure including a plurality of nodes representing the plurality of network devices and a plurality of edges connecting the plurality of nodes. The one or more processing units are further configured to process the intent to select a topology compiler from a plurality of topology compilers and invoke, via the API framework, the selected topology compiler using a role of a network device of the plurality of network devices and an indication of the network device as input to generate abstract configuration information. The one or more processing units are further configured to configure the network device based on the abstract configuration information.

Topology compiler for network management system

Network controllers are described that enable creation of logical interconnects between logical routers of different, isolated virtual networks and for auto-generation and deployment of routing policies to control 'leaking' of select routes amongst the different virtual networks. In one example, a network controller includes a memory and processing circuitry configured to identify a source logical router of a first virtual network and a destination logical router of a second virtual network implemented on one or more physical devices of a switch fabric, form a policy defining one or more rules for controlling leaking of one or more of the routes through a logical router interconnect from the source logical router to the destination logical router, and push the policy to the one or more physical devices of the switch fabric for application to communications through the logical router interconnect.

Data center tenant network isolation using logical router interconnects for virtual network route leaking

In general, techniques are described for defining and executing device-independent commands on a network having a plurality of network devices. In some examples, a controller includes a graphical user interface. The controller displays, via the graphical user interface, network devices that support a device-independent command selected from one or more device-independent commands, wherein each device-independent command performs one or more operations on supported network devices. The controller receives, via the graphical user interface, user input selecting two or more of the displayed network devices and performs the one or more operations of the selected device-independent command on the selected network devices. In some examples, performing includes executing tasks associated with each network device, wherein the tasks, when executed, perform the one or more operations on each respective network device.

User customization and automation of operations on a software-defined network

An access profile includes configuration characteristics that are defined using device and operating system agnostic attributes. Thus, the access profiles are not necessarily dependent or otherwise tied to any particular vendor or network OS. When a system administrator configures one or more service access points, the system administrator need only specify the vendor and network OS agnostic characteristics that are to be 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 agnostic access profile attributes. The generated configuration commands and data can be provided to a network device hosting the service access point using a vendor specific and/or network OS specific configuration application program interface.

Vendor agnostic profile-based modeling of service access endpoints in a multitenant environment

Techniques are disclosed for providing a Software Defined Networking (SDN) controller with real-time or near-real time visibility of the operation of data center fabrics to determine whether the DCI was properly configured. For example, an SDN controller receives high-level configuration data that describes a desired state of a network managed by the SDN controller at a high level of abstraction. The SDN controller applies a transformation function to the high-level configuration data to generate a low-level configuration data for network devices configured to implement the desired state of the network. SDN controller configures the SDN controller as a peer to the network devices to obtain one or more routes exchanged between the network devices. The SDN controller sends the low-level configuration data to the network devices to cause the network devices to implement the desired state of the network.

Inter-data center software-defined network controller network

An example method includes determining, by a network controller, based on a high-level data model, vendor-agnostic device information for a first network device, translating the vendor-agnostic device information into vendor-specific device information, sending, to the first network device, first configuration information included in the vendor-specific device information to cause the first network device to switch into a maintenance mode and enable diversion of network traffic from the first network device to a second network device, responsive to verifying that the first network device has diverted the traffic, initiating maintenance procedures on the first network device while the first network device is in the maintenance mode, and sending, to the first network device, second configuration information included in the vendor-specific device information to cause the first network device to switch out of the maintenance mode and enable reversion of network traffic from the second device to the first network device.

Automation of maintenance mode operations for network devices

An example method includes identifying, based on a received indication, at least a first network device that is to be placed in the maintenance mode, determining device information for the first network device, sending, to the first network device, first configuration information included in the device information to cause the first network device to switch into a maintenance mode and enable diversion of network traffic from the first network device to a second network device, responsive to verifying that the first network device has diverted the traffic, initiating maintenance procedures on the first network device while the first network device is in the maintenance mode, and sending, to the first network device, second configuration information included in the device information to cause the first network device to switch out of the maintenance mode and enable reversion of network traffic from the second device to the first network device.

Growing community of inventors

San Jose, CA, United States of America

Atul S Moghe