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
I recently deployed the new Cisco UCS platform emulator (UCSPE) 2.1 to get a first impression of the changes in the new UCSM 2.1 software. I ran it without problems in VMware Fusion on my MacBook Pro, but couldn’t get it to run properly on the ESXi 5.0 host in my home lab. Continue reading
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.
Now that Cisco has finally released the software for the Cisco ASA 1000v virtual security appliance, I am eager to install it and get a feel for its capabilities. However, before I can get to the fun part and start playing with the virtual ASA, I will have to upgrade the virtual infrastructure in my lab to the correct versions to support it. Primarily, this means that I will have to upgrade both the Nexus 1000v and the VNMC that I have running in my lab.
In a lab situation, the simplest way to accomplish this would be to just deploy a completely new instance of the Nexus 1000v and then restore its configuration from a backup, but I decided that it would be more educational to actually perform an upgrade from my current Nexus 1000v version 4.2(1)SV1(5.1a) to the version 4.2(1)SV1(5.2) that is required to support the ASA 1000v. According to the Cisco documentation it should be possible to perform this procedure as a hitless In-Service Software Update (ISSU), so I decide to put that to the test and see if there are any gotchas in this process.