OTV and LISP are two interesting new data center technologies that are worth examining when you are studying for a Cisco Data Center certification, such as CCNP or CCIE Data Center. Unfortunately, not everybody can afford a couple of Nexus 7000s to play with. As an instructor for Fast Lane I regularly have access to Nexus based labs, but I still thought that it would be nice to have a lab setup of my own to experiment with. Fortunately, there is now a very nice way to get some hands-on experience with these protocols through the Cisco Cloud Services Router (CSR) 1000v, which I blogged about earlier.
The CSR 1000v is based on the same IOS XE code that runs on the ASR 1000, which supports both OTV and LISP. So I decided to try to build a lab to test VM mobility using OTV and LISP in my home lab using a number of CSR 1000v instances. Continue reading
At Cisco Live London I attended a very interesting session about the Cisco Cloud Services Router by Anurag Gurtu (BRKVIR-2016 – Cisco’s Cloud Services Router (CSR 1000v): Extending the Enterprise Network to the Cloud).
The CSR 1000v, which was announced last summer at Cisco Live San Diego, is a router in a VM form-factor, based on the Cisco ASR 1000 platform. It runs a modified version of the same IOS XE software that also runs on the physical ASR routers and has a very similar feature set. Ultimately, it will allow enterprises to run their workloads in a cloud infrastructure and then connect those VMs to their own network based on familiar WAN technologies, using the same CLI that they also use on their physical Cisco routers. In addition, the CSR will support a number of APIs to allow automated provisioning of CSR instances in a cloud infrastructure.
During the Data Center Security Techtorial that I attended on Monday, I had already had a sneak preview of the software running in VMware on the presenter’s laptop. Since the CSR has not officially been released yet, this was a beta version, but as far as I could see it was fully functional. Anurag also had a couple of screenshots of the software in his presentation and he was kind enough to offer the session attendees access to the software if they wanted to evaluate it by themselves. Of course, I jumped on this opportunity. Continue reading
The Internet still can’t beat sneaker net (and most likely never will) according to this excellent XKCD what if?
While I was working on a Nexus lab, I ran into an interesting issue that had me scratching my head for a while before I managed to figure out what was going on. You gotta love those unintentional troubleshooting exercises! This was the situation:
Fabric failover is a unique feature of the Cisco Unified Computing System that provides a “teaming-like” function in hardware . This function is entirely transparent to the operating system running on the server and does not require any configuration inside the OS. I think that this feature is quite useful, because it creates resiliency for UCS blades or rack servers, without depending on any drivers or configuration inside the operating system.
I have often encountered servers that were supposed to be redundantly connected to the network, as they were physically connected to two different switches. However, due to missing or misconfigured teaming, these servers would still lose their connectivity if the primary link failed. Therefore, I think that a feature that offers resiliency against path failures for Ethernet traffic without any need for teaming configuration inside the operating system, is very interesting. This is especially true for bare-metal Windows or Linux servers on UCS blades or rack servers.
In this post I do not intend to cover the basics of Fabric Failover, as this has already been done excellently by other bloggers. So if you need a quick primer or refresher on this feature, then I recommend that you read Brad Hedlund’s classic post “Cisco UCS Fabric Failover: Slam Dunk? or So What?“.
Instead of rehashing the basic principles of fabric failover, I intend to dive a bit deeper into the UCSM GUI, UCSM CLI and NX-OS CLI to examine and illustrate the operation of this feature inside UCS. This serves a dual purpose: Gaining more insight in the actual implementation of the fabric failover feature and getting more familiar with some essential UCS screens and commands.