Cisco’s Cloud Services Router (CSR) running IOS-XE is a very popular network appliance used in a variety of scenarios – as a VPN gateway, as a MPLS termination, to connect DCs, to provide an internet split-out for branches, to connect branches to HQ. Coupled with LISP, CSR can also be used to extend the DC with hybrid cloud infrastructure. There are numerous ‘how-to’ articles on the web that articulate how CSR can be used to connect cloud infrastructure to DC or HQ to secure hub-to-spoke or spoke-to-spoke traffic with DMVPN and IPSEC. To create topologies for these use-cases, however, one requires infrastructure to run the CSR routers and networking interconnect to connect them.
In most organizations, it takes weeks to months to procure and deploy new hardware – servers, racks, switches, and it is expensive. CSR’s Amazon Machine Image (AMI) offers an alternative to try out some of CSR features without having to invest in physical hardware. However, due to networking limitations on AWS (e.g. broadcast and multicast packets are heavily filtered, L2 unavailable), many CSR features are unsupported without tunneling on the AMI (e.g. OSPF, IGMP, PIM, OTV, VxLAN, WCCPv2, MPLS, EoMPLS, VRF, VPLS, HSRP). Further, only one network interface can be configured as DHCP. This presents a difficulty in creating full-featured CSR environments that I need as a CCIE to play with different features, and mock-up PoC environments.
This is where Ravello helps. Ravello is a SaaS solution powered by nested virtualization and software defined networking overlay. Ravello enables networking professionals like me to create full-featured networking labs with a multitude of networking & security of VMware or KVM appliances (including Cisco’s CSR 1000v!) on top of public cloud (AWS or Google Cloud), and benefit from unlimited capacity and usage based pricing. Ravello’s software defined networking overlay exposes a clean L2 network – just like a DC environment – and offers built-in network services such as DNS, DHCP, Firewall, Virtual Switch and Virtual Router – should I need it. Further, it allows me to bring in my own router (CSR 1000v in this case), if I want specialized network functionality as a part of my environment.
A little skeptical of the tall claims made by Ravello, I decided to put Ravello’s Network Smart Lab to test. (Data-center functionality – running VMware & KVM VMs with L2 access – at public cloud prices and flexibility just seemed too good to be true!) I embarked on creating a CSR deployment connecting two different data-centers through VPN tunnel on Ravello. To emulate a DC, I added some LAMP servers and pointed CSR to be their Gateway on Ravello. With a click, I made two copies of this setup and associated public IPs to CSR’s external network interfaces. Using Ravello’s ability to run VMs in multiple clouds, I published one of the copies of my setup to run on AWS and another in Google. Once both environments were up and running, I configured each CSR instance in AWS and Google cloud to point to the other’s public IP, and voila – my two DCs running on AWS and Google were securely connected!
The rest of this article details configuration to get my multi-DC environment connected through CSR 1000v on Ravello.
Getting this environment set up on Ravello involved 4 simple steps –
I used the Ravello Import Tool to upload all 3 of my VMs. Ravello’s VM uploader gave me multiple options - ranging from directly uploading my multi-VM environment from vSphere/vCenter to uploading OVFs or VMDKs or QCOW or ISOs individually. I uploaded my CSR1000v as an QCOW image.
Upon uploading the CSR 1000v, Ravello asked to confirm the resources (CPU, Memory, Storage) for my VM. Since Ravello had already identified the resources, it was more of a verification exercise.
Clicking on the Network tab, I added two network interfaces to the CSR – one each for internal and external networks. I configured a static IPs on the interfaces and chose “VirtIO” as the device type. I also associated ‘Elastic IP’ to the external interface so that I could access it from anywhere.
To enable SSH access to my VMs, I opened port 22 in the “Services” tab.
Next, I created an ‘Application’ on Ravello. An ‘Application’ in Ravello’s terms is essentially a multi-VM environment. To create my DC, I dragged and dropped my CSR and LAMP VMs on the application canvas.
Next, I saved my application as a ‘Blueprint’ – which was similar to taking a snapshot of the entire multi-VM setup. Blueprint enabled me to make additional copies of this ‘application’ environment.
With blueprint of this environment in hand, I was able to create two application copies. I modified the IPs on the second copy so that it didn’t conflict with the first copy. Next, I published an instance of each to run in Google Cloud and AWS respectively. Publishing the application was a piece of cake – a one-click action.
With my DC environments set up in AWS and Google cloud, the next step was to configure the CSR to connect the two environments through a VPN tunnel. Here is how I configured the CSR for this environment using CLI.
Defined the hostname first
For convenience’s sake if I mistype something, I disabled domain lookup.
no ip domain lookup
To get SSH access, I needed a domain name, so I set one up.
ip domain name ravellosystems.com
Next, I generated SSH key pair
crypto key generate rsa
Then configured a username & password for CSR
username admin privilege 15 password 0 XXXXXX
Next I allowed SSH on the incoming lines
line vty 0 4 login local transport input ssh
To give out IPs to my client VMs, I also set up a local DHCP Server
ip dhcp excluded-address 10.0.2.0 10.0.2.9
ip dhcp pool DHCP
network 10.0.2.0 255.255.255.0
And here comes the tricky part – how to get the IPSEC tunnel to fly. Here is the full config required for this. Details for each command can be found in the Cisco config guides.
crypto isakmp policy 1 encr aes authentication pre-share group 2 crypto isakmp key PASSWORD address 0.0.0.0 crypto ipsec transform-set TRANSFORM_SET esp-aes 256 esp-md5-hmac mode tunnel crypto ipsec profile 1 set transform-set TRANSFORM_SET interface Tunnel0 ip address 192.168.255.2 255.255.255.252 tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 ! The tunnel destination is the elastic IP of the other side! tunnel destination 184.108.40.206 tunnel protection ipsec profile 1
Here is the simple IP interface configuration, nothing fancy...
interface GigabitEthernet1 description EXTERNAL ip address 192.168.0.3 255.255.255.0 negotiation auto interface GigabitEthernet2 description LAN ip address 10.0.2.1 255.255.255.0 negotiation auto
My default route points to the internet (required to find the other Elastic IP) and my inter DC traffic (just traffic going to 10.0.1.0/24) points to the other side of the tunnel:
ip route 0.0.0.0 0.0.0.0 192.168.0.1 ip route 10.0.1.0 255.255.255.0 192.168.255.1
The tunnels are on-demand tunnels so they only come up once traffic is present. Also to see some counters increase, I created 2 SLAs – one that works just in the tunnel and one that pings end-to-end from one LAN to the other.
ip sla 1 icmp-echo 10.0.1.1 source-ip 10.0.2.1 frequency 10 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo 192.168.255.1 source-ip 192.168.255.2 frequency 10 ip sla schedule 2 life forever start-time now
To check if my CSR sees the right interfaces I have to type this tedious long command. So, I made an alias for it –
alias exec sps show platform software vnic-if interface-mapping
Upon doing a similar configuration on the CSR running in Google Cloud (and pointing it its peer in Amazon), the two DCs were securely connected through a VPN tunnel.
To verify that this setup works, I typed in sh ip sla stat. Increase in the number of successes for the counters confirmed that my VPN was setup and active (hurrah!).
Ravello’s Network Smart Lab offers an unique and simple way for networking professionals to create full-featured CSR environments for PoCs and network design (without needing hardware investments) on AWS & Google. Drop me a line if you would like to play with my CSR Blueprint setup.