Demystifying Cisco ACI for HP Servers with OneView, Virtual Connect and B22 Modules

Transcription

1 Technical white paper Demystifying Cisco ACI for HP Servers with OneView, Virtual Connect and B22 Modules Updated: 7/7/2015 Marcus D Andrea, HP DCA

2 Table of contents Introduction... 3 Testing Topologies... 4 Cisco ACI Overview... 7 Understanding the ACI Policy Model and Keeping it Simple... 7 Cisco ACI Switching and APIC Key Integration Elements for HP VLAN Tagging in ACI Virtual Machine Manager Domain(VMM) with ACI and HP Configuring Hypervisors in ACI without VMM integration Server Infrastructure Virtual Connect FlexFabric 20/40 F8 with Cisco ACI FlexFabric 20/40 F8 Overview Ports and Port Numbering FlexFabric 20/40 F8 with OneView Key Integrations and Best Practices with ACI FlexFabric 20/40 F8 with Virtual Connect Manager Key Integrations and Best Practices with ACI Cisco Nexus HP B22 Module with Cisco ACI Cisco Nexus HP B22 Overview Cisco Nexus HP B22 with OneView Key Integrations with ACI Cisco Nexus HP B22 Supported Topologies with ACI HP Operations Orchestration with Cisco ACI and OneView HP Operations Orchestration Overview HP OneView REST API Cisco ACI REST API ACI References Conclusion... 30

3 Introduction This document provides a basis for understanding and demystifying Cisco ACI with HP solutions. This guide provides information to show how the solutions work together but does not detail all of the implementation tasks necessary to deploy Cisco ACI.. For detailed installation steps, please see the ACI References section at the end of this document. The hardware and software for Cisco ACI testing included the following: Infrastructure Components Products Version Blade server H/W HP BladeSystem C7000 Chassis with ProLiant BL460 Gen8 and Gen 9 servers SPP Blade server I/O HP Virtual Connect FlexFabric-20/40 F8 Module for c-class BladeSystem 4.31/4.45 Networking Cisco ACI Fabric Nexus 9504 Spine and Nexus 9396 PX Leaf NXOS 11.0 (4h) ACI Networking Cisco Application Policy Infrastructure Controller (APIC) 1.0(4h) Networking Cisco Nexus HP-B22 NXOS 11.0 (4h) ACI Management S/W Products Version Virtual Machine Management VMware vcenter and vsphere 5.5 Bare Metal Microsoft Windows 2012 R2 Virtual Machine Ubuntu Server 64-bit Infrastructure Management Virtual Connect Manager HP OneView infrastructure management virtual appliance 1.20 Virtual Connect Manager 4.45

4 Testing Topologies Figure 1: Virtual Connect FlexFabric 20/40 with OneView The above topology reflects an HP C7000 blade enclosure managed by HP OneView 1.20 and connected to a pair of ACI leaf switches with Virtual Connect FlexFabric 20/40 F8 Modules. The blades inside the systems are loaded with Windows and VSphere along with a test Ubuntu VM.

5 Figure 2: Cisco Nexus HP B22 with HP OneView The above topology reflects an HP C7000 blade enclosure managed by HP OneView 1.20 and connected to a pair of ACI leaf switches with Cisco Nexus B22 for HP. The blades inside the systems are loaded with Windows and VSphere along with a test Ubuntu VM.

6 Figure 3: Virtual Connect FlexFabric 20/40 with Virtual Connect Manager The above topology reflects an HP C7000 blade enclosure managed by HP Virtual Connect Manager 4.45 and connected to a pair of ACI leaf switches with Virtual Connect FlexFabric 20/40 F8 Modules. The blades inside the systems are loaded with Windows and VSphere along with a test Ubuntu VM.

7 Cisco ACI Overview Cisco Application Centric Infrastructure (ACI) is a new Data Center architecture from Cisco that implements a policy based approach in order to abstract traditional networking constructs. ACI is based on two primary components which include the Nexus 9000 series switches and Application Policy Infrastructure Controllers (APICs). The Nexus 9000 platform provides the physical infrastructure while the APIC is a clustered policy management system responsible for all aspects of fabric configuration and monitoring. The Nexus 9000 switches leverage a traditional Broadcom Advanced Integrated Switching Circuit (ASIC) as well as a custom Cisco ASIC that is only used when ACI mode is enabled and ACI code is running on the Nexus 9000 switches. ACI uses a policy model to control communication between systems components and applications. The policy model introduces a number of different constructs which include End Point Groups (EPG), Application Profiles, Contracts, Filters, as well as objects associated with external connectivity (for both Layer 2 and Layer 3). The ACI architecture leverages a spine and leaf topology with all endpoint devices connected into the leaf nodes. Endpoint devices can include existing infrastructure switches, routers, load balancers, servers, and other various devices. The spine nodes only connects leaf nodes and no other devices are directly connected to the spine. ACI can integrated into L4-L7 devices and services using a concept of services graphs but this will not be covered in this paper. Understanding the ACI Policy Model and Keeping it Simple The ACI fabric is enabled through a set of policies delivered from the APIC and pushed down into the Nexus 9000 series switches. ACI Policies are built from a set of logical constructs. Logical constructs take all the underlying configurations behind the scenes of the network and abstract them for use in a large scale deployment (as opposed to simply configuring one switch). ACI itself is a large scale fabric but when you look at how the policy of ACI is designed, you can see an architectural approach that is similar to other Cisco Data Center products. To fully understand the logical constructs of ACI they must first be simplified and translated to terms that are familiar to network engineers and architects. Below is a quick list of logical constructs with simplification: Tenant A tenant is a logical container construct for application profiles that allow access control of an entire realm of resources. In simple terms, think of a tenant as a unique customer or a unique organization.

8 Bridge Domain A bridge domain represents a Layer 2 construct. Think of this as a layer 2 switch without any routing functionality. Private Network/Context A context is a simple layer 3 domain definition and is analogous to a Virtual Route Forwarder (VRF) from a networking point of view. Endpoints Endpoints are just what they sound like and can be anything from Servers, Storage, Routers, or other devices.

9 Endpoint Group The Endpoint Group construct contains a collection of Endpoints. A simple way to think of this this is group nesting in systems in which you have a distribution lists that contains smaller subsets of distribution lists. Contracts Contracts define who can communicate with whom in ACI. EPG s can only communicate with other EPGs according to contract rules. If you want to communicate in the same EPG you do not need a contract but if you want to communicate between EPG s both parties need to agree. Filters- Provide a construct to manipulate Layer 2 thru Layer 4 protocol types and ports. Think Access Control Lists (ACL) if you have a security background.

10 External Connectivity External connectivity is just what it sounds like and surfing the web will require some external connectivity from the ACI fabric to the outside world. Another aspect of ACI that is not covered in this paper but is key to getting an ACI fabric provisioned is fabric/access policies. Fabric/access policies leverage things like interfaces, Virtual Port Channels, Link Aggregation Control Protocol, Network Time Protocol, DHCP etc. This can be found in most of the Cisco documentation and anything that is modified from default perspective to make ACI work with HP will be covered in this paper. Access Polices are defined under the Fabric menu. A sample HP B22 FEX Interface Profile Definition is shown below. Cisco ACI Switching and APIC Key Integration Elements for HP The first key item to understand about ACI is that you need to forget your traditional routing and switching CLI basics and learn how the ACI fabric works. The configuration concept of things like switchport mode access has evolved into configuration and terms like tagged, untagged and 802.1P in the world of ACI. Virtual Local Area Network (VLAN) was used for the concept of segmented broadcast domains in the traditional networking world but not in the world of ACI. In ACI VLANs become an encapsulation mechanism to transport traffic, which can also be done with Virtual Extensible Area Networks (VXLAN). VLAN Tagging in ACI When you get into the configuration of ACI and start mapping out physical interfaces in is important to understand the limitations and operations of how VLAN tags work when applied against ports in EPG s which will be discussed later in this document.

11 Modes of Operation for VLAN Tagging: 1. Tagged When this option is used the leaf node is expecting the incoming traffic to be tagged with a specified VLAN ID. This is similar to traditional Nexus command Switchport mode trunk. 2. Untagged When this option is used the leaf node expects untagged traffic which is traffic that does not have a VLAN ID. This is similar to traditional Nexus command Switchport mode access P When this option is used the leaf node expects tagged traffic with 802.1P headers. This is similar to the traditional Nexus command Switchport trunk native vlan. Rules of VLAN/VXLAN ID s with these modes of operation: 1. When using tagged VLAN/VXLAN ID in multiple EPGs with the same interface the VLAN/VXLAN ID must be unique. 2. When using untagged VLAN/VXLAN ID against an interface this interface can only be bound in one EPG. 3. When using 802.1P option on an interface this designation can exist in only one EPG. However, the same interface can exist in another EPG and have a tagged option applied against it. Encap Mode Multiple VLANs Supported Use Case Untagged No Bare Metal Server Tagged Yes Hypervisor (VMWare, Hyper-V, KVM) 802.1P Yes Hypervisor with PXE, Provisioning Server etc. Link Layer Discovery Protocol in ACI with HP Link Layer Discovery Protocol (LLDP) is key to ACI as it allows the APIC to learn the location of devices and hosts and translate that into leaf connectivity. When ACI gets an LLDP frame it cares about the Local Port ID field as well as the Management Field. LLDP Frame of Virtual Connect Uplink Port into ACI Leaf: Virtual Machine Manager Domain(VMM) with ACI and HP The Virtual Machine Manager Domain enables an administrator to configure connectivity policies for virtual machine controllers consisting of two key components. The first component of VMM is the Virtual Machine Controller element which is really just VMware vcenter or Microsoft System Center Virtual Machine Manager (SCVMM). The second component is the VMM Domain which groups VM Controllers with similar networking policy requirements by publishing networking configuration in an ACI managed Distributed Virtual Switch (DVS). It is important to understand that two modes of operation exist in an ACI world in regards to virtualization, which are static or VMM integrated. Cisco supports the standard vsphere Distributed Virtual Switch (DVS) for integration with ACI or the optional Cisco Advanced Virtual Switch. For the purpose of this paper the focus will be the native

12 vsphere DVS functionality controlled and maintained by ACI. The topic of LLDP is important in this deployment as the endpoint information that sits on the downlinks of HP Virtual Connect must be presented to the DVS. Virtual Connect Manager version 4.45 will provide the ability to pass LLDP information to the DVS for consumption by the ACI Fabric. Note: OneView 1.20 does not support VMM integrated deployment. LLDP Information dynamically learned in ACI from the VMM Integration as well as what the Virtual Connect downlink port is reporting back to the DVS which is illustrated below. Verification of the DVS deployment will be shown from a VC perspective in the upcoming figures and will correlate with the above graphic to help stich together the pieces of the integration.

13 Below is the integration of ACI VMM with a VSphere 5.5 U2 VCenter deployed in a topology outline in Figure 3: leveraging Virtual Connect DVS in VCenter for Virtual Connect 4.45 Deployment: LLDP-VC Cluster with Ubuntu-1 VM and MAC address 00:50:56:a5:f7:fe and IP Address

14 On a leaf node of the ACI Fabric, endpoints can be displayed by issuing the show endpoint command. The green arrow shows the MAC address of the Ubuntu-1 Virtual Machine which was learned dynamically across port eth 1/11. Ubuntu-1 VM is pinging gateway to verify proper operation of DVS and dynamic mapping in ACI.

15 Configuring Hypervisors in ACI without VMM integration In ACI if the fabric cannot be fully dynamic and integrated by VMM it is possible to make things work, it just translates into more steps from an ACI perspective. If the HP Virtual Connect Modules are running code below version 4.45 or if the modules are managed by HP OneView, then LLDP on the downlinks ports facing servers will not be enabled. If LLDP cannot be seen correctly from a VMM/DVS integration, then the previous ACI VMM integration approach will not work. However, traditional VSwitches, OpenVSwitches or any other custom VSwitch/Hypervisor combination can still work behind the ACI Fabric. The key is understanding that an encapsulating VLAN needs to be applied to an uplink interface by another EPG and tied into a universal contract for communication between EPG s. The topology in Figure 1: (Virtual Connect FlexFabric 20/48 F8 module with OneView 1.20) was used for this implementation. A scalable approach to making static items work in ACI is to configure an EPG corresponding to the VMs doing static mapping with ACI and define a separate encapsulating VLAN (vlan 55 in the following example) to the interface that is already extended over into the Virtual Connect modules. Think of this approach as adding another allowed VLAN to a trunk port. By using this simple method any number of VMs behind a vsphere host that is leveraging a regular vswitch can communicate on an ACI fabric. Below is a traditional VMWare VSwitch deployment in OneView with VC 20/40 Modules.

16 Ubuntu-2 Virtual Machine on VLAN-55 of VSwitch with MAC Address 00:50:56:a5:16:9c and IP Address On a leaf node of the ACI Fabric, endpoints can be displayed by issuing the show endpoint command. The green arrow shows the MAC address of the Ubuntu-2 Virtual Machine.

17 Ubuntu-2 VM is pinging gateway and to verify proper operation of VSwitch. This section has covered the key ACI Switching and APIC Integration elements for making Cisco ACI and HP interoperability successful.

18 Server Infrastructure The HP BladeSystem c7000 enclosure houses the VMware hosts. Server infrastructure management is provided by HP OneView software. HP OneView is HP s converged infrastructure platform managing server provisioning, monitoring, and LAN/SAN networking configuration tasks. HP OneView integrates functions of all traditional HP management software such as Onboard Administrator, Virtual Connect Manager, Virtual Connect Enterprise Manager and Insight Control software. OneView software is packaged as VMware virtual appliance ova format. Users can download software at Detailed HP OneView installation and initial setup procedure are discussed in HP OneView 1.20 Deployment and Management Guide. Virtual Connect FlexFabric 20/40 F8 with Cisco ACI FlexFabric 20/40 F8 Overview FlexFabric 20/40 Module: HP Virtual Connect FlexFabric-20/40 F8 Modules are the simplest, most flexible way to connect virtualized server blades to data or storage networks. VC FlexFabric-20/40 F8 modules eliminate network sprawl at the server edge with one device that converges traffic inside enclosures and directly connects to external LANs and SANs. Using Flex-20 technology with Fiber Channel over Ethernet and accelerated iscsi, these modules converge traffic over high-speed 10Gb/20Gb connections to servers with HP FlexFabric Adapters. Each redundant pair of Virtual Connect FlexFabric modules provide eight adjustable downlink connections ( six Ethernet and two Fiber Channel, or six Ethernet and two iscsi or eight Ethernet) to dual-port 10Gb/20Gb FlexFabric Adapters on each server. Up to twelve uplinks with eight Flexport and four QSFP+ interfaces, without splitter cables, are available for connection to upstream Ethernet and Fiber Channel switches. Including splitter cables up to 24 uplinks are available for connection to upstream Ethernet and Fiber Channel. VC FlexFabric-20/40 F8 modules avoid the confusion of traditional and other converged network solutions by eliminating the need for multiple Ethernet and Fiber Channel switches, extension modules, cables and software licenses. Also, Virtual Connect wire-once connection management is built-in enabling server adds, moves, and replacements in minutes instead of days or weeks. Ports and Port Numbering The HP Virtual Connect FlexFabric 20/40 F8 Module has 4x40G QSPF+ and 8x1/10G SFP+ Ethernet or 2/4/8GB FC interfaces as uplink ports. For the downlink ports, you have 16x10/20Gb Ethernet links towards HP BladeSystem C7000 server bays with a single downlink to a server support up to 3 FlexNICs and 1 FlexHBA or 4 FlexNICs. A FlexHBA can be configured to transport either FCOE or Accelerated iscsi. The 4xQSFP port numbers start with Q1.1 and end with Q4.4. If you decide to leverage a breakout cable you will have 4 10Gb ports per QSFP slot so Q1.1 through Q1.4 would be available for 10Gb. If a 40Gb QSFP is placed in Q1 then Q1.1 will appear as populated and port Q1.2-Q1.4 will be unavailable. Below is an example of how a 40Gb port would appear in OneView with the 20/40 Module.

19 The 8xSFP+ port numbers start from X1 and end with X8. These ports can accommodate 1/10Gb Ethernet or 2/4/8GB FC connections. Below you can see a variety of different connections options and how they would appear in OneView include FC, Ethernet, and stacking between Virtual Connect Modules. Ports X5-X6 and X7-X8 are called paired ports and each paired port can be set to Ethernet or Fiber Channel but mixing of both traffic types in the same paired set is not allowed. An example of a configuration that would not be allowed is putting a 10Gb Ethernet in port X7 and then trying to enable Fiber Channel on port X8. However, you could have FCOE on port X8 because it would be running at 10Gb. You cannot mix 1Gb and 10Gb on the same paired port set as well. They are paired in terms of internal clocking source but there is no performance penalty by using paired ports comparing with individual ports X1-X4. Ports X9 and X10 are dedicated internal horizontal cross-connects which provide 2x20Gb connectivity. FlexFabric 20/40 F8 with OneView Key Integrations and Best Practices with ACI Understanding LLDP is instrumental in making FlexFabric 20/40 F8 module with OneView a working solution with ACI since LLDP provides needed information from both uplinks and downlinks to integrate ACI and the VMM elements. However the focus for OneView is a static configuration with ACI and not an integrated configuration with ACI and VMM. The topology leveraged for this is depicted in Figure 1: Note: OneView 1.20 does not support VMM integration into ACI as LLDP downlink information is not available. Since Virtual Connect passes VLAN information it is important to extend and configure any VLANS that will be used in regards to ACI encapsulation. The Virtual Connect Module can operate in three modes: Private Network, Tunnel Mode, or Mapped Mode). Details and information providing these modes of operation can be located in the Virtual Connect Cookbook. In regards to ACI and Virtual Connect we will focus on two modes, Tunnel Mode and Mapped Mode and the caveats and restrictions they have regarding ACI. Tunnel Mode: Tunnel Mode allows packets with VLAN s tagged to pass through Virtual Connect without modification but more importantly for large scale designs thinking about the number of VLAN s to extend to each VC Domain is and after thought versus the competition as they may need to extend all 4096 vlans. Mapped Mode: In Mapped Mode all VLAN Tags are examined. The big limitation is that 162 virtual networks are allowed to be extend at the server profile layer which is not the case of Tunnel Mode. This mode also requires all of the VLAN that would be required by ACI to be extended down to VC which is not the case in Tunnel Mode.

20 ACI Static Endpoint definition with encapsulating VLAN-55 for one VM. A Network Set was created in OneView to carry the management encapsulating VLAN 60 and the VM VLAN-55. Notice that VLAN 60 is set to untagged which translated into an 802.1p vlan-60 interface definition in ACI.

21 ACI configuration for connection going into Virtual Connect FlexFabric 20/40 with encapsulating vlan-60 and 802.1p Tag. In OneView 1.20 running VC 4.31 the only LLDP information exposed is the exchange between VC and the ACI leaf node shown below. Currently OneView 1.20 does not support LLDP on the downlinks facing the servers. FlexFabric 20/40 F8 with Virtual Connect Manager Key Integrations and Best Practices with ACI In order to make the FlexFabric 20/40 F8 module with Virtual Connect Manager 4.45 a working solution with ACI, an understanding of LLDP was key as it is important since LLDP from an uplink perspective and downlink perspective provides needed information to take advantage of full advantage of ACI and the VMM integration elements. The topology leveraged for this is depicted in Figure 3: Since Virtual Connect passes VLAN information it is important to extend and configure any VLANS that will be used in regards to ACI encapsulation. The Virtual Connect Module can operate in a couple of modes included (Private Network, Tunneling, or Mapped Mode). Details and information providing these modes of operation can be located in the Virtual Connect Cookbook. In regards to ACI and Virtual Connect we will focus on two modes, Tunnel Mode and Mapped Mode and the caveats and restrictions they may have regarding ACI. Tunnel Mode: Tunnel Mode allows packets with VLAN s tagged to pass through Virtual Connect without modification but more importantly for large scale designs thinking about the number of VLAN s to extend to each VC Domain is and after thought versus the competition as they may need to extend all 4096 vlans. Mapped Mode: In Mapped Mode all VLAN Tags are examined. The big limitation is that 162 virtual networks are allowed to be extend at the server profile layer which is not the case of Tunnel Mode. This mode also requires all of the VLAN that would be required by ACI to be extended down to VC which is not the case in Tunnel Mode.

22 Virtual Connect allows for an optional domain IP address which creates a consistent IP address that is independent of the interconnect module on which it is running. If set, this IP address must be unique within the network and must be different than the IP address of the module itself. If this IP address is not set, the VC Manager can still be reached through the IP address of the host VC-Enet module. To use an optional domain IP address, select the Use Domain IP address check box, and then enter the IP Address, Subnet Mask, and Default Gateway. NOTE: Even if a domain IP address is provided, the normal IP address assigned to the interconnect bay can still be used. In regards to ACI the key information that is leveraged is LLDP and the Management IP Address of VC. If a failover occurs to ensure a timely transition of interfaces and prevent a loss of connectivity it is recommend to set the VC Domain IP address. Virtual Connect CLI tagged LLDP enabled is set equal to true in the testing below. The default option is false. This option can only be set in Virtual Connect Manager 4.45 in CLI mode at this time. Below are the Virtual Connect uplink set definitions for ACI leaf nodes. Encapsulating VLAN 65 was used as a management VLAN and Encapsulating VLAN 63 was extending into the Virtual Machine world for VMM consumption. VLAN 65 was set native for management, PXE etc.

23 In ACI the definitions for the links connecting into VC have been defined as 802.1P Tag with encapsulating vlan-65. This also depicts how and individual interface is mapped which is different than how a VPC is mapped out. In ACI the definitions for the links connecting into VC have been defined as 802.1P Tag with encapsulating vlan-65. This also depicts how a VPC mapping is handled versus the mapping above.

24 The VMM domain was created and the VCenter was populated with a DVS integrated into ACI for consumption of the VMWare Hosts and VM s sitting VC. The VMM Integration with DVS and LLDP Information learned from Virtual Connect downlink ports shows the dynamic learning in ACI which is illustrated below.

25 Cisco Nexus HP B22 Module with Cisco ACI Cisco Nexus HP B22 Overview The Cisco Fabric Extender for HP BladeSystem (Model B22HP) provides an extension of the Cisco Nexus switch fabric to the HP server edge. Logically, it behaves like a remote line card to a parent Cisco Nexus 5000 series switch, with the Fabric Extender and the parent Nexus together forming a distributed modular system. The Cisco Fabric Extender for HP BladeSystem forwards traffic to the parent Cisco Nexus switch over eight 10 Gigabit Ethernet uplinks. Low-cost uplink connections up to 10 meters can be made with copper Twin-ax cable, and longer connections up to 100 meters can use optional Fabric Extender Transceivers. Standard 10Gb SFP+ optics are also supported. Downlinks to each server are auto-negotiating and work with all HP Ethernet and CNA modules allowing a choice of Ethernet, FCoE or iscsi connections. Passing all traffic seamlessly to the Nexus 5000 allows traffic to be shaped according to policies established by the Nexus 5000 Series Switch with a single point of management. Cisco Nexus HP B22 with OneView Key Integrations with ACI In order to make the HP B22 module with OneView a working solution with ACI an understanding of LLDP was key as it is important since LLDP from an uplink perspective and downlink perspective provides needed information to take advantage of full advantage of ACI but the B22 acts linecard extension so the ACI leaf node handle all of LLDP responsibility for the B22. The topology leveraged for this is depicted in Figure 2:

26 The HP B22 is a monitored entity in HP OneView so no configuration was required to make this work in an ACI fabric. This is the CLI verification of the HP B22 appearing on the ACI leaf node. The static mapping for the interfaces going over to the HP B22 from the ACI leaf have been defined and to keep it simple only VLAN 64 was extended and marked as untagged. Cisco Nexus HP B22 Supported Topologies with ACI The only working and supported ACI topologies with the HP B22 are depicted in the diagram below. The diagram is showing what is called a single-homed Fabric Extender (FEX) topology.

27 HP Operations Orchestration with Cisco ACI and OneView HP Operations Orchestration Overview HP Operations Orchestration (OO) is an IT automation software that improves service quality by standardizing on reliable, repeatable, and fully auditable task automation. This software can easily manage installation, update, removal, and reporting to define configuration for proprietary packaging, imported files, object, and scripts. ACI and OneView both share a common REST API architecture which provides the potential for (OO) to extend automation of infrastructure management with OneView and Cisco ACI together. For more information on HP Operations Orchestration follow the link below. HP OneView REST API HP OneView appliance is based on Rest API and the API could be accessed by http web operation, Python and PowerShell language. The API reference material HP OneView API scripting reference is used in tandem with OneView API scripting help. How to use this reference The table of contents links to the REST API specification for each resource type in the HP OneView resource model. Each REST API specification defines the REST APIs provided by that resource, including the URI, method, parameters, request body, and response body. In many cases, these components are displayed as links. These API specifications are intended to provide all the details needed to call the HP OneView REST APIs and to build scripts around these calls. Example: Add a server via the management processor enc-ilo.corp.com using the login "Administrator" and password "mypassword": POST { "hostname" : "enc-ilo.corp.com", "username" : "Administrator", "password" : "mypassword", "force" : false, "licensingintent":"oneview" } Cisco ACI REST API The APIC REST API is a programmatic interface to the Application Policy Infrastructure Controller (APIC) that uses a Representational State Transfer (REST) architecture. The API accepts and returns HTTP or HTTPS messages that contain JavaScript Object Notation (JSON) or Extensible Markup Language (XML) documents. You can use any programming language to generate the messages and the JSON or XML documents that contain the API methods or managed object (MO) descriptions. The API model provides major functionality for application development. Configuration and state information of the Cisco Application Centric Infrastructure (ACI) fabric is stored in a hierarchical tree structure known as the management information tree (MIT), which is accessible through the API. You can make changes on a single object or an object subtree. With an API call, you can make changes to the configuration of switches, adapters, policies, and other hardware and software components. The API operates in forgiving mode, which means that missing attributes are substituted with default values (if applicable) that are maintained in the internal data management engine (DME). The DME validates and rejects incorrect attributes. The API is also atomic. If multiple MOs are being configured (for example, virtual NICs), and any of the MOs cannot be configured, the API stops its operation. It returns the configuration to its prior state, stops the API operation that listens for API requests, and returns an error code. Example:

28 Example: Establishes external route for VMM with port connect to leaf node. <!-- api/policymgr/mo/.xml --> <poluni> <fvtenant name="mgmt"> <l3extout name="vmm"> <l3extinstp name="vmmmgmt"> <l3extsubnet ip=" /16" /> <fvrscons tnvzbrcpname="default" /> </l3extinstp> <l3extlnodep name="bleaf"> <l3extrsnodel3outatt tdn="topology/pod-1/node-101" rtrid=" "> <iproutep ip=" /0"> <ipnexthopp nhaddr=" " /> </iproutep> </l3extrsnodel3outatt> <l3extlifp name="portprofile"> <l3extrspathl3outatt tdn="topology/pod-1/paths-101/pathep-[eth1/1]" ifinstt="l3-port" addr=" /30" /> </l3extlifp> </l3extlnodep> <l3extrsectx tnfvctxname="inb" /> </l3extout> </fvtenant> </poluni>

29 ACI References During the process of building out ACI and testing various HP solutions a number of key reference documents were leveraged. Below is a list of some of the most useful documents to help in regards to understanding ACI. Cisco Application Centric Infrastructure Fundamentals Cisco APIC Getting Started Guide Operating Cisco Application Infrastructure Troubleshooting Cisco Application Centric Infrastructure

30 Conclusion This paper is a technical understanding document that should allow the reader to successfully interpret and demystify an ACI fabric that is leveraged with HP solutions.