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.

So now that Cisco Live and last week’s training course are out of the way, I finally have some time to play with the software and see for myself how it works. The software is packaged as a VMware OVA template, so pretty simple to deploy. Originally, I planned to deploy the CSR on the Nexus 1000v in my lab, but I quickly find that this does not work. The CSR OVA template is setup for 4 vCPUs, which I don’t have on my virtualized ESXi hosts. Luckily, there is no real need to deploy the CSR 1000v on top of a Nexus 1000v, so I decide to deploy it on my bare-metal ESXi host instead. (Actually, the documentation for the CSR 1000v states that currently it isn’t even supported to run the CSR on top of the Nexus 1000v, but only on the VMware vSwitch.)

This is one of the important things that I picked up during Anurag’s presentation. Because of the 1000v in the name of the product I had always assumed that this product was part of the Nexus 1000v ecosystem, depending on the Nexus 1000v vPath redirection mechanism that is used for other virtual appliances such as the VSG and the ASA 1000v. It turns out that this is actually not the case. The CSR 1000v can be deployed on a standard VMware vSwitch and is simply set up as the default gateway for the VMs in the connected VLANs. Of course this means that all traffic will pass through the CSR VM, but given that this product is positioned as an entry and exit point for the virtual data center this is not a real limitation.

So I start by deploying the OVA template:

I answer the usual set of questions, accept the Cisco EULA, and allow the VM to boot up. It goes through some initialization procedures followed by a reboot and then I get the familiar router console:

I configure the hostname and an IP address for the first interface and proceed to test if I can ping the default gateway. Unfortunately, this doesn’t work:

A quick check of the configuration reveals the problem. The first interface of the CSR is configured as a management interface in a separate management VRF by default. I test again, and now the ping succeeds:

Of course, I could have known this if I had actually read the documentation that Anurag provided with the software, but like most engineers I tend to just jump into it and only start reading the documentation once I have gotten myself in trouble…

I proceed to configure an admin user, set the domain name, generate an RSA key, and enable local authentication and authorization in order to gain access through SSH. At this point my basic configuration consists of the following:

hostname csr1kv
!
aaa new-model
!
aaa authentication login default local
aaa authentication login CONSOLE none
aaa authorization exec default local
!
clock timezone CEST 1 0
clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 2:00
!
ip domain lookup source-interface GigabitEthernet0
ip domain name lab.layerzero.nl
ip name-server vrf Mgmt-intf 192.168.37.2
!
username admin privilege 15 secret 4 ILils0mOI614rA8jp3XNafw4S8TS/LC8I5.hdufdbkI
!         
interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 ip address 192.168.37.65 255.255.255.0
!
ip route vrf Mgmt-intf 0.0.0.0 0.0.0.0 192.168.37.1
!
line con 0
 privilege level 15
 login authentication CONSOLE
!         
ntp server vrf Mgmt-intf 192.168.37.2

Next I want to try to push some traffic through the router. Before you can activate the non-management interfaces on the CSR, it is necessary to activate the license and accept the Cisco EULA.

csr1kv#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
csr1kv(config)#license feature csr
PLEASE  READ THE  FOLLOWING TERMS  CAREFULLY. INSTALLING THE LICENSE OR
LICENSE  KEY  PROVIDED FOR  ANY CISCO  PRODUCT  FEATURE  OR  USING SUCH
PRODUCT  FEATURE  CONSTITUTES  YOUR  FULL ACCEPTANCE  OF  THE FOLLOWING
TERMS. YOU MUST NOT PROCEED FURTHER IF YOU ARE NOT WILLING TO  BE BOUND
BY ALL THE TERMS SET FORTH HEREIN.
Use of this product feature requires an additional license from Cisco,
together with an additional payment. You may use this product feature
on an evaluation basis, without payment to Cisco, for 60 days. Your use
of the product, including during the 60 day evaluation period, is
subject to the Cisco end user license agreement
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html
If you use the product feature beyond the 60 day evaluation period, you
must submit the appropriate payment to Cisco for the license. After the
60 day evaluation period, your use of the product feature will be
governed solely by the Cisco end user license agreement (link above),
together with any supplements relating to such product feature. The
above applies even if the evaluation license is not automatically
terminated and you do not receive any notice of the expiration of the
evaluation period. It is your responsibility to determine when the
evaluation period is complete and you are required to make payment to
Cisco for your use of the product feature beyond the evaluation period.

Your acceptance of this agreement for the software features on one
product shall be deemed your acceptance with respect to all such
software on all Cisco products you purchase which includes the same
software. (The foregoing notwithstanding, you must purchase a license
for each software feature you use past the 60 days evaluation period,
so that if you enable a software feature on 1000 devices, you must
purchase 1000 licenses for use past the 60 day evaluation period.)

Activation of the software command line interface will be evidence of
your acceptance of this agreement.

ACCEPT? (yes/[no]): yes
csr1kv(config)#

Now I should be able to enable the Gigabit 1 and Gigabit 2 interfaces, configure IP and pass some traffic. To make it simple to connect some clients I configure two subnets and corresponding DHCP pools:

!
ip dhcp pool NET-10.4.4.0/24
 network 10.4.4.0 255.255.255.0
 default-router 10.4.4.254 
 dns-server 192.168.37.2 
 domain-name lab.layerzero.nl
!
ip dhcp pool NET-10.5.5.0/24
 network 10.5.5.0 255.255.255.0
 default-router 10.5.5.254 
 dns-server 192.168.37.2 
 domain-name lab.layerzero.nl
!
interface GigabitEthernet1
 no ip address
 negotiation auto
!
interface GigabitEthernet1.4
 encapsulation dot1Q 4
 ip address 10.4.4.254 255.255.255.0
!
interface GigabitEthernet1.5
 encapsulation dot1Q 5
 ip address 10.5.5.254 255.255.255.0

To make my life easy I connected my CSR GigabitEthernet 1 interface to a port-group that is enabled for trunking. This allows me to use sub-interfaces on the CSR to connect to any of my lab VLANs. Alternatively, I could have used two separate physical interfaces on the CSR and put them in different port-groups, one for each VLAN.

To test my connectivity I now move two of my lab VMs onto VLANs 4 and 5 and allow them to grab an IP from the DHCP pools.

csr1kv#sh ip dhcp binding 
Bindings from all pools not associated with VRF:
IP address      Client-ID/ 		Lease expiration 	Type       State      Interface
		Hardware address/
		User name
10.4.4.1        0100.5056.bfc2.65       Feb 12 2013 09:57 PM    Automatic  Active     GigabitEthernet1.4
10.5.5.1        0100.5056.af56.e1       Feb 12 2013 10:13 PM    Automatic  Active     GigabitEthernet1.5

As an encore, I add external routing and NAT to allow my VMs to browse the web through the CSR:

!
interface GigabitEthernet1.4
 ip nat inside
!
interface GigabitEthernet1.5
 ip nat inside
!
interface GigabitEthernet2
 ip address 192.168.37.66 255.255.255.0
 ip nat outside
!
ip route 0.0.0.0 0.0.0.0 192.168.37.1
!
ip access-list extended NAT-SOURCES
 permit ip 10.0.0.0 0.255.255.255 any
!
ip nat inside source list NAT-SOURCES interface GigabitEthernet2 overload

Finally, I decide to use iperf to push some traffic between my VMs and see if I can manage to get up to the 50 Mbps that this version of the CSR should be capable of. Once the product is released Cisco will have licenses that cap the forwarding rate of the CSR at various different levels. The evaluation version that I am using in the lab is capped at 50 Mbps as can be seen from the show license command:

csr1kv#show license detail 
Index: 1 	Feature: csr1kv_50M                        Version: 1.0
	License Type: Evaluation
	License State: Active, In Use
	    Evaluation total period: 8  weeks 4  days 
	    Evaluation period left: 8  weeks 3  days 
	    Period used: 13 hours 50 minutes 
	    Expiry date: Apr 12 2013 22:51:32
	License Count: Non-Counted
	License Priority: Low
	Store Index: 0
	Store Name: Built-In License Storage

To get an idea of the performance, I run iperf between the two VMs. Clearly, using iperf on a pair of Windows XP VMs, which are running on top of a pair of ESXi hosts that are virtualized themselves, doesn’t really make for a very good test setup. But just to get a first impression, I think it is sufficient. Anybody who is interested in deploying this product should clearly run it through some more rigorous tests. My initial test results show the following:

The iperf test shows a throughput of roughly 45 Mbps, which is close enough to the projected 50 Mbps for my taste, especially given the limitations of this testbed.

However, the capping of throughput does raise some interesting questions:  How is the licensed bandwidth actually enforced? Is this through some form of policing? And if so, do I get any visibility into this process? Is this mechanism QoS aware? Would it for example be possible to split the 50 Mbps across several different traffic classes in order to protect interactive high priority traffic from random high bandwidth sessions?

All-in-all, the CSR 1000v looks very interesting. Because it is based on IOS XE it feels like a regular Cisco router, making it very easy to configure. In addition, my basic tests show that it is capable of forwarding a decent traffic load, even in my very suboptimal lab setup. One of the things that I am really looking forward to is the release of an Amazon AMI version of the CSR, which will enable real hybrid cloud scenarios.

Another thing that makes this product very interesting is its potential as a learning and testing tool. Could this be the official Cisco answer to Dynamips and its extended family? As a trainer and consultant I can see great potential in using the CSR to explore new protocols and technologies, test new features, or even to validate network changes. I will have to do some further testing to see how many instances I can run concurrently in my lab, but at first sight it looks like you could easily build some interesting lab scenarios using a couple of CSR instances on ESXi.

So to wrap up this post: My first impressions of the CSR are quite favorable and I look forward to running it through some more complex scenarios!