London’s Big Ben at Night
Last week I had the opportunity to attend the Gartner Data Center conference in London. I attended 3 different sessions on SDN-related topics. Here are some of my observations from what was a very good conference. Also, since the Gartner Data Center conference runs this week (w/c 1 December 2014) in the US, if you are going, here are some questions to think about when you attend the SDN sessions.
(1) What does “lack of visibility” in Virtual Overlays really mean?
(2) In multi-layer SDN, will SDN be cheaper than our current networking approach?
(3) Are Vendors Guilty of Using NFV for SDN “Washing”?
(4) If OpenStack is part of your SDN solution, can you help us on OpenStack?
(5) What is the best hardware server platform for NFV/virtualised workloads?
(6) How exactly does SDN deliver better network management?
I’ll cover a few questions today and some tomorrow.
Read More »
Tags: ACI, cisco_services, Gartner Data Center, NFV, Overlay Networks, SDN, SDN Overlays, VMware
In the past, we have pointed out that configuring network services and security policies into an application network has traditionally been the most complex, tedious and time-consuming aspect of deploying new applications. For a data center or cloud provider to stand up applications in minutes and not days, easily configuring the right service nodes (e.g. a load balancer or firewall), with the right application and security policies, to support the specific workload requirements, independent of location in the network is a clear obstacle that has to be overcome.
Let’s say, for example, you have a world-beating best-in-class firewall positioned in some rack of your data center. You also have two workloads that need to be separated according to security policies implemented on this firewall on other servers a few hops away. The network and security teams have traditionally had a few challenges to address:
- If traffic from workload1 to workload2 needs to go through a firewall, how do you route traffic properly, considering the workloads don’t themselves have visibility to the specifics of the firewalls they need to work with. Traffic routing of this nature can be implemented in the network through the use of VLAN’s and policy-based routing techniques, but this is not scalable to hundreds or thousands of applications, is tedious to manage, limits workload mobility, and makes the whole infrastructure more error-prone and brittle.
- The physical location of the firewall or network service largely determines the topology of the network, and have historically restricted where workloads could be placed. But modern data center and cloud networks need to be able to provide required services and policies independent of where the workloads are placed, on this rack or that, on-premises or in the cloud.
Whereas physical firewalls might have been incorporated into an application network through VLAN stitching, there are a number of other protocols and techniques that generally have to be used with other network services to include them in an application deployment, such as Source NAT for application delivery controllers, or WCCP for WAN optimization. The complexity of configuring services for a single application deployment thus increases measurably.
Read More »
Tags: ACI, ietf, Network Services Header, Nexus 1000v, NSH, SDN, vPath
Over the past several years, I’ve been lucky enough to be a part of two important trends in the networking industry -- the evolution of open standards and open APIs, and the definition of policy as the key interface to the network.
Open is an extremely important word to the future of networking. The simple dictionary definition for open means not closed or locked, allowing access to inside, and freely accessible.
The ultimate networking environment will allow a user the freedom to connect anything together in the cloud and to an existing environment. In order for this vision to happen, companies must work together to create a common language.
OpenStack has garnered a lot of interest in the development community and among our customers. We at Cisco have been actively helping to shape the discussion around policy. Working collaboratively with our partners and competitors, we helped create Group-Based Policy (GBP), an intent-driven policy API for OpenStack.
The Group-Based Policy initiative represents a significant innovation in how users conceive, manage, deploy, and scale their applications in OpenStack clouds. And its now available as a 100% open source solution available to any vendor. When coupled with Cisco Application Centric Infrastructure, we are able to offer our customers a completely policy-driven network.
Read More »
Tags: ACI, API, APIs, application centric infrastructure, Cisco, Cisco Application Centric Infrastructure, cloud, data center, group-based policy, network, networking, Open, open APIs, open source, open standards
As a Gold Sponsor of AWS re:Invent this year, Cisco will be showcasing hybrid cloud solutions that enable you to combine the control, security, and performance of private clouds with the scale, economics, and speed that public clouds can offer.
Cisco cloud portfolio, including Intercloud Fabric, ApplicationCentric Infrastructure, Cloud Services Routers, and Adaptive Security Appliances, gives you the power of choice and agility.
Learn more about how your business can unleash hybrid IT, and be sure not to miss the following Cisco solution demos at re:Invent 2014. We will be raffling many exciting prizes on all days during the event. You’re automatically entered when you visit the Cisco booth and have your badge scanned.
Cisco Intercloud Fabric is a highly secure, open, and flexible solution that provides complete freedom in workload placement. It is hypervisor and cloud provider independent, giving you the desired flexibility. All the traffic between your data center and cloud provider as well as traffic inside the public cloud is cryptographically encrypted. Your network and security policies are migrated consistently and transparently over Layer 2 extension. A unified management portal gives you a single interface for workload management and automation across heterogeneous cloud environments.
Get a free 90 days evaluation license for Cisco Intercloud Fabric when you visit Cisco Intercloud Fabric booth.
Application Centric Infrastructure
Cisco Application Centric Infrastructure (ACI), the Cisco software-defined networking (SDN) architecture, brings agility, reduces TCO, automates IT tasks, and accelerates data center application deployments.
It supports a business-relevant application policy language, greater scalability through a distributed enforcement system, and greater network visibility through the integration of physical and virtual environments across networks, servers, storage, security, and services. For more details, check out a special edition of Unleashing IT.
Cloud Services Router
Cisco Cloud Services Router (CSR1000V) sets the standard for enterprise-class networking and security services in a virtual form factor. The CSR1000V is the first platform to deliver multigigabit IPSec performance in Amazon Web Services cloud.
It helps enterprises transparently extend their private networks to the public cloud using the familiar Cisco IOS XE Software CLI and RESTful API, which make sure of easy deployment, monitoring, troubleshooting, and service orchestration.
Security continues to be a top concern for organizations looking to expand their network into the cloud. It needs to be a transparent extension of local network and data center policies, allowing data to move securely between those environments. To address this need, Cisco has engineered new versions of our market-leading Cisco Adaptive Security Appliance Next-Generation Firewall (ASA NGFW) and FirePOWER NGIPS solutions specifically for AWS environments.
Now you can create dynamically encrypted tunnels between your local or distributed networks and the cloud; apply consistent security for physical, virtual, and cloud environments; make sure local policies are understood and enforced in the cloud; and deploy a single security strategy across traditional, NFV, SDN, ACI, and cloud architectures.
See you in Vegas!
Stop by Cisco Booth #112 to have 1:1 meetings with Cisco product experts and discuss your use cases. We look forward to seeing you at re:Invent.
Tags: ACI, AWS re:Invent, Cisco, CSR1000v, Hybrid Cloud, intercloud fabric
Cisco, in its quest to embrace programmability, has created what is called the ACI Toolkit, which is basically a combination of an NX-OS like CLI and some custom python scripts. Although this toolkit doesn’t allow you to do all configurations within ACI, it can be used to create and show the common configuration and administrative actions that may be used daily. It’s also great for someone who is just starting to migrate to a more programmatic way of doing things, as it’s easily understandable to folks used to common networking commands.
If you’re not familiar with ACI, check out this short video to get a brief understanding of some of the basic constructs used and for a deeper dive go to www.cisco.com/go/aci. These concepts will help you to understand some of the configuration options available with the ACI Toolkit.
The toolkit’s python libraries are all available on GitHub.com and it’s fairly simple to access. All you need to do is open a terminal window on your computer and enter the following command:
git clone https://github.com/datacenter/Simple-ACI-Toolkit
This command will download the necessary libraries to use the ACI Toolkit syntax. Then to run CLI commands from your APIC type:
python acitoolkitcli.py -l admin -p password -u https://APIC_IP
This will connect you to your APIC so you may run commands that will help you build your application network profiles as shown in the three tier application in the picture above. We can do things such as switching tenants, creating contexts, creating bridge domains, and creating end point groups (EPGs).
Here are some examples of the common commands we might use to create these logical objects.
Switch to a tenant configuration mode:
- fabric# switchto tenant <tenant-name>
- fabric-tenant# switchback
Create a Context and don’t enforce contracts on it:
- fabric-tenant(config)# [no] context <context-name>
- fabric-tenant(config-ctx)# [no] allow-all
Create a bridge domain and assign it to a context:
- fabric-tenant(config)# [no] bridgedomain <bd-name>
- fabric-tenant(config-bd)# [no] context <context-name>
Create a subnet under the bridge domain:
- fabric-tenant(config-bd)# [no] ip address <ip-address>/<masklength> [name <subnet-name>]
As you can see from these examples the syntax will be very familiar to network engineers. We can also use the ACI Toolkit combined with the Python SDK to actually script these things. It makes scripting a little easier because we’re again using simpler syntax. Below is an example of configuring a tenant using Python in conjunction with the toolkit:
from acitoolkit import *
from credentials import *
tenant = Tenant (‘Customer1’)
context = Context (‘customer1-router’, tenant)
bd = BridgeDomain(‘BD1’, tenant)
app = AppProfile(‘web-and-ordering’, tenant)
vlan10 = EPG(‘VLAN10’, app )
vlan20 = EPG(‘VLAN20’, app )
Currently the ACI Toolkit may not be used to create service graphs, VMM Domains, SPAN, Atomic Counters, and or to see most telemetry and health score information. However, the toolkit still gives us a lot to work with and automate as far as basic configurations go. For more information please see the guide found here (http://datacenter.github.io/acitoolkit/).
Tags: ACI, Cisco, python, toolkit