Because of the nature of SDN, and specifically the automation available with Cisco’s Application Centric Infrastructure, ACI works really well with cloud orchestration tools such as OpenStack. I was able to be at the OpenStack Summit in Tokyo last week and gave a vBrownBag TechTalk about why Cisco ACI makes OpenStack even better.
So, how does ACI work with OpenStack and perhaps even make it better? First, ACI offers distributed and scalable networking. It supports Floating IP addresses in OpenStack. If you’re not familiar with Floating IPs, they are essentially a pool of publicly routable IP addresses that you purchase from an ISP and assign to instances. This would be especially useful for instances, or VMs, like web servers. It also saves CPU cycles by putting the actual networking in the Nexus 9000 switches that make up the ACI fabric. Since these switches are built to forward packets, and that’s what they’re good at, why not save the CPU cycles for other things like running instances?
OpenStack doesn’t natively work with Layer 4-7 devices like firewalls and load balancers. With ACI we can stitch in these necessary network services in an automated and repeatable way. We do this in a way that doesn’t sacrifice visibility as well. While it’s important that we’re able to automate things, especially in a private or public cloud that is constantly changing and updating, if we lose visibility, we lose the ability to troubleshoot easily. In the demo, shown in the video above, you will see just how easy it is to troubleshoot problems in ACI. We also get the ability to preemptively strike before a problem causes issues on the network by offering easily interpreted health scores for the entire fabric, including hardware and end point groups.
ACI is also a very secure model. Not only does it use a white-list model where traffic is denied by default and only allowed when explicitly configured that way, it will also give more security when it comes to multi-tenancy. In a strict overlay solution, if a hypervisor is attacked or owned the multi-tenancy model could be deemed insecure. In the ACI fabric the security is done at the port level. So even if a hypervisor is attacked the tenants will be safe.
In recent versions of ACI we are able to use OpFlex as a southbound protocol to communicate between OpenStack and ACI. By using OpFlex we get a deeper integration and more visibility into the virtual environment of OpenStack. Instead of attaching hypervisor servers to a physical domain in ACI we can attach them into a VMM (Virtual Machine Manager) domain. This allows us to learn which instances or VMs are on which physical server. It will also automatically learn IP addresses, MAC addresses, states and other information. We can also see which networks or portgroups contain which hypervisors and instances within our OpenStack environments.
For more information on how Cisco ACI works with OpenStack you can go to http://cisco.com/go/aci
Server load balancer (SLB) has become very common in network deployments, as the data & video traffic are expanding at rapid rate. There are various modes of SLB deployments today. Application load balancing with network address translation (NAT) has become a necessity for various benefits.
With our latest NX-OS Software 7.2(1)D1(1) (also known as Gibraltar MR), ITD supports SLB NAT on Nexus 7k series of switches.
In SLB-NAT deployment, client can send traffic to a virtual IP address, and need not know about the IP of the underlying servers. NAT provides additional security in hiding the real server IP from the outside world. In the case of Virtualized server environments, this NAT capability provides increased flexibility in moving the real servers across the different server pools with out being noticed by the their clients. With respect health monitoring and traffic reassignment, SLB NAT helps applications to work seamlessly without client being aware of any IP change.
ITD won the Best of Interop 2015 in Data Center Category.
ITD provides :
Zero latency load-balancing.
CAPEX savings : No service module or external L3/L4 load-balancer needed. Every Nexus port can be used as load-balancer.
Resilient (like resilient ECMP), Consistent hash
Bi-directional flow-coherency. Traffic from A–>B and B–>A goes to same node.
Learning new skills and using new tools to automate your network can appearto be scary if you don’t have a coding background. But that doesn’t need to be the case…
In a previous blog post, I discussed Cisco’s SDN Strategy for the Data Center. I mentioned that it is built on 3 key pillars: Application Centric Infrastructure, Programmable Fabric, and Programmable Network. Regarding the 3rd pillar, I wrote that network programmability has largely been the domain of big Web SP’s, and/or those whose propellers seen to spin faster than others. However, the reality is that tools are available that are useful for networks of pretty much any size, and the tools are within reach of pretty much everybody.
Rather than rattle off a list cool features that are part of Programmable Network (some of which are summarized here), I thought it more useful to consider common things network people actually do on a daily basis, then show how we can apply programmability tools to do those things with, for lack of a better phrase, “the 3 S’s”:
Speed – enabling you to do things much faster;
Scale – enabling you to do things to a much larger group of devices; and
Stability – enabling you to make far fewer errors (thereby also increasing Security…oops, now that’s 4 S’s…)
In upcoming posts, we will consider use cases such as switch provisioning. For example, you need to put a bunch of VLANs on a bunch of switches. Unless you have a battalion of minions to carry out your wishes, this can be a tedious, time consuming task. There is a better way, and we’ll show you how.
What’s that? You say you’re a network geek, but you moonlight as a server admin? You’ve been using Linux tools to monitor and troubleshoot servers and want to use the same tools for the network? Okay, we can cover that too because tools like ifconfig and tcpdump are all part of the party.
If you can’t wait for the future posts and/or you want to dive deep, this recorded webinar should tide you over.
Anyhow, I need to go carve a pumpkin now…Happy Halloween!
*For music aficionados…Yeah, I know – the link was Heavy Metal not Death Metal, but I used one of my own songs…and this is about as close to Death Metal as I get. That whole guttural screaming thing never worked for me…
Next week (3rd-5th November) the Open Networking User Group (ONUG) meets at New York University in New York for its fall conference. For those of you not familiar with ONUG, it is a community of IT business leaders who exchange ideas and best practices for implementing Open Networking and Software-Defined Networking (SDN) designs.
Our enterprise customers continue to show significant interest in simplifying and automating their WAN network infrastructure and datacenter. Our ACI solution has reached over 1000 customers and we continue to see enhancements to Cisco Intelligent WAN (IWAN) with APIC-EM and the IWAN Application. Read More »
You’ve seen the data points: 30 million new devices connected to the Internet each week. A whopping 50 billion connected by 2020. This surge of connectivity – driven largely by the Internet of Everything – is creating vast new opportunities for digitization as industries transform.
This tidal wave of connected devices is also reshaping the data center. Why? Because every single thing connected to the Internet has a MAC and IP address, and this enormous growth will unleash more addresses than anyone can imagine. These addresses need, feed, and breed applications, whether by running an app or providing it data. And as this happens at an exponential scale, the data center becomes the key to making it all work.
We know that the applications will be everywhere, and that’s a good thing. Apps will continue to be in the enterprise data center – the private cloud—where they’ve been running for a long time. And they’ll run in cloud-based data centers. They’ll also run at the edge – whether the edge is a branch office, your home, or even a part of your body.
For applications to perform optimally no matter where they are, the infrastructure has to understand the language of applications. We have to teach it. And this is where policy comes in. For us, policy is teaching the infrastructure the language of the application so that the application can tell the infrastructure, “Here is what I need to run at my best.”
This is an area where Cisco has a lot of skin in the game. After all, no one knows Data Center infrastructure better than we do.