Cisco Intercloud Fabric Release 2.2.1 is Feature Packed.

I bought a used car this past weekend for my two teenagers to share, for school, work, getting around town, etc. It is a sensible car, four-wheel drive, high safety rating, decent gas mileage, few options and fewer distractions, a big difference from the ’72 TransAm I had as a teenager. Like the car I got for my children the TransAM was 10 years old when I bought it but that’s where the similarities ended.

The ’72 TransAm came in blue with white stripes or white with blue stripes. It was raw power, the new honeycomb grille airflow augmenting the rear facing hood scoop to feed the Rochester Quadrajet 4-bbl carburetor. Every month I scanned my Hot Rod magazine to see if there was some new speed or horsepower tip in one of the columns.

I miss that car; you could do so many things with it. Not only could you service it yourself, there were loads of aftermarket parts and services to take advantage of, I liked that I wasn’t locked into the manufacturer or even have to worry about a specific dealer, it was so easy. And it was my very first hybrid… when I added Nitrous! (I believe that counts as hybrid)

Cisco’s Intercloud Fabric (ICF) reminds me of my TransAm (I’m sure you were wondering how I was going to make the transition to Hybrid Cloud). How so? Well ICF is not locked into a specific cloud provider or their virtual machine format. In the enterprise, ICF can run on Hyper-V, KVM + OpenStack and VMware vSphere. The cloud provider can be running VMware, Hyper-V, OpenStack, CloudStack, ICF works with all those cloud management systems. Plus with the current release 2.2.1, ICF packs in a bunch of new capabilities.

New Features in Release 2.2.1

Release 2.2.1 of Intercloud Fabric contains the following new features and enhancements:

• Intercloud Fabric Firewall (VSG) now supports:
  • Amazon EC2
  • Cisco Intercloud Services – V
  • Microsoft Azure
  • Amazon EC2
  • Cisco Intercloud Services – V
  • Microsoft Azure
  • CCS OpenStack (Nimbus)
  • Cisco Intercloud Services – V
  • Cloudstack
  • Amazon EC2
  • Microsoft Azure
  • Amazon EC2 Classic
  • Amazon EC2 VPC

  That is quite a few items; I want to go over a few briefly and then a couple in detail.

  • Enhanced OS Support
  • Easy to Try
  • ICF Secure Network Extension Options

  Enhanced OS Support

  The ICF 2.2.1 release supported operating systems has more than doubled over the previous release and had added multi-disk support

  • RHEL 6.0 – 6.5: 64-bit versions – supported on all cloud providers
  • CentOS 6.2 – 6.5: 64-bit versions – supported on AWS and Azure
  • Windows 2008 R2 SP1 – supported on all cloud providers
  • Windows 2012 – supported on all cloud providers
  • Windows 2012 R2 – supported on all cloud providers
  • SUSE Linux 11 SP2 and SP3 – supported on all cloud providers

  This is really good news as more OS support is being added with every release, there is sure to be a fit with every enterprise.

  Easy to Try

  With a built in trial license for 60 days and 20 Hybrid Cloud Units (HCUs) ICF 2.2.1 has removed all barriers to Hybird cloud in your enterprise! A built in trial license means that you can immediately connect to a cloud provider and migrate VMs. Each VM migrated to or instantiated at a cloud provider is going to utilize one or two HCUs. AWS and Azure will consume two HCUs, while all other cloud providers will consume one. The built in trial license supports all ICF features and services, e.g. Firewall, Router, Integrated Router, VM Onboarding, Netflow, ERSPAN, etc.

  ICF Secure Network Extension Options

  The ICF secure network extension AKA the site-to-site tunnel allows you extend your Data Center networking out to the provider cloud. In the previous releases of ICF the site-to-site tunnel required ports 6644 and 6646 be open for Internet traffic. Now with HTTPS support for the site-to-site tunnel port 443 is utilized, which is typically open in an enterprise, making demo or proof-of-concept deployments very quick and easy to implement. It is recommended however that when you move your ICF deployment to production that you do utilize ports 6644 and 6646.

  There are really no restrictions on the product utilization, this means that once you’ve deployed with the 60 day license, when you decide to make the deployment permanent all that is required is a license upgrade.

  Now for a deeper dive on a couple new features in ICF Release 2.2.1.

  Network and Security Enhancements

  The Intercloud Fabric Router (Integrated – IR) is now supported on Microsoft Azure. The IR provides routing functionality directly in the ICF Intercloud Switch (ICS). Recall that the ICS is the cloud provider side of the site-to-site tunnel extended from the enterprise ICF Intercloud Extender (ICX). The ICX + ICS pair form the secure network extension referred to as the IcfCloud.

  When deploying an IcfCloud to Azure a Service selection form is presented for the selection of “ICF Firewall (VSG)” and “ICF Router (Integrated)

  

  Selecting the ICF Router (Integrated) will cause an “Edge Router” configuration to be created in the Prime Network Services Controller (PNSC) that is deployed as part of the ICF Infrastructure. Through this “Edge Router” configuration in PNSC you can create configure the following ICF IR scenarios

  • Inter-VLAN routing in the Cloud – This is when all the communicating VMs are in the cloud but on different secure extended enterprise VLANs.

  

  1. Accomplish this by creating sub-interfaces on the IR – One for each VLAN to be routed
  2. Created sub-interfaces are assigned the IP address of the default gateway for each subnet
  3. e.g. VLANs 1352 and 1353 only have VMs in the Cloud
     1. VLAN 1352 – subnet 10.2.0.1/24 – IR gateway – 10.2.0.1
     2. VLAN 1353 – subnet 10.3.0.1/24 – IR gateway – 10.3.0.1

  

  • Inter-VLAN routing in the Cloud and the Enterprise – This is when communicating VMs are in the cloud on but on different secure extended enterprise VLANs and communicating VMs are also on those VLANs in the enterprise.
    1. Accomplish this by creating sub-interfaces on the IR – One for each VLAN to be routed
    2. Created sub-interfaces are assigned an IP address on the subnet but not the existing default gateway IP for the subnet.
    3. IR sub-interface is configured to extend default gateway
    4. e.g. VLANs 1352 and 1353 have VMs in the Cloud and the enterprise
       1. VLAN 1352 – subnet 10.2.0.1/24 – Ent gateway – 10.2.0.1
       2. VLAN 1352 – subnet 10.2.0.1/24 – IR gateway – 10.2.0.99
       3. VLAN 1353 – subnet 10.3.0.1/24 – Ent gateway – 10.3.0.1
       4. VLAN 1353 – subnet 10.3.0.1/24 – IR gateway – 10.3.0.99
  • Inter-VLAN routing in the Cloud and Enterprise including VLAN that only exists in the Cloud
  1. Accomplish this by creating sub-interfaces on the IR – One for each VLAN to be routed. There needs to be at least one VLAN in the Cloud that also exists in the Enterprise.
  2. Created sub-interfaces are assigned an IP address on the subnet but not the existing default gateway IP for the subnet for the routing back to the enterprise. Or sub-interfaces are assigned and IP address of the default gateway for the subnet
  3. Create a static route for cloud only VLAN to be routed back to the enterprise
  4. e.g. VLAN 1352 has VMs in the Cloud and the Enterprise, VLAN 1353 only has VMs in the Cloud and is not a routed VLAN in the Enterprise, VLAN 1354 has VMs in the Enterprise that VMs on VLAN 1353 will communicate with. Use VLAN 1352 as a static route for VLAN 1353
     1. VLAN 1352 – subnet 10.2.0.1/24 – Ent gateway – 10.2.0.1
     2. VLAN 1352 – subnet 10.2.0.1/24 – IR gateway – 10.2.0.99
     3. VLAN 1353 – subnet 10.3.0.1/24 – IR gateway – 10.3.0.1
     4. VLAN 1354 – subnet 10.4.0.1/24 – Ent gateway – 10.4.0.1
     5. Static Route in IR 10.4.0.0 via 10.2.0.1

     

     

     The Integrated Router also supports Static NAT and Dynamic NAT, for a detailed explanation of implementing these NAT types in the IR be sure to attend my Cisco Live San Diego Breakout session, BRKCLD-2003

     • Static NAT – allow access to the ICF VMs via the cloud provider Internet connection
     • Dynamic NAT – allow the ICF VMs access to resources outside the secure ICF shell via the cloud provider Internet connection

     Why do you care about IR?

     Since the IR functionality is built into the ICS that’s one less VM required in the provider cloud to support the routing and NAT features you’ll want to utilize. Initial IR deployment is a clicking a checkbox during a guided workflow, it really couldn’t be simpler!

     Controlling Shadow IT with VM Onboarding

     The other new feature that I wanted to highlight is VM onboarding. For AWS VMs that already exist in either a default VPC or a user defined VPC can now be brought into the secure ICF shell and have the ability to communicate over the secure network extension. This is a huge boon for those customers that wish to connect to and bring shadow IT under control, as well as workloads that are just sitting out in Amazon.

     Prior to release 2.2.1, VMs that have previously been deployed in AWS were not accessible to VMs in the secure ICF shell. The 2.2.1 release introduces the capability to onboard these VMs. VM onboarding is a great new feature and will work well provided the following criteria are met:

     1. VM to be onboarded needs to be in the same region and same AWS VPC as the Intercloud VDC so that ICS can reach them on provider private IP
     2. VM in same VPC but different subnet will work as long as the route table is configured for reachability from ICS to the private IP of the VM to be onboarded
     3. Setup security group for the onboarded VM so that ICF components can reach the VM
     4. Linux VM should have the entries not referred to by partition name, but label or id to allow for migration to enterprise
     5. VM with non-partitioned disk may be onboarded but can not be migrated to the enterprise
     6. The onboarded VM is assigned an enterprise IP, any applications using the provider IP will need to be updated
        • AWS VPC and AWS Classic (that uses default VPC) – ICF will add the security group created by ICF for the IcfCloud (the one assigned to ICS) to the onboarded VM
     7. AWS classic (without default VPC) – user needs to add inbound rules to the security group from the AWS console for – UDP & TCP 6644/6646, TCP 22 – for the same source IPs as in the security group assigned to ICS (Note: this is because AWS doesn’t allow changing security group for AWS EC2 Classic VMs)
     8. Windows Firewall or Linux iptables must be configured, opening the required ICF ports
     • 22
     • 443
     • 6644
     • 6646

     Why do you care about controlling Shadow IT?

     Shadow IT is hidden costs, shadow IT is potential security breeches, shadow IT is loss of control. Shadow IT arises from process and controls put in place to stop the very scenarios just mentioned from taking place. Providing users a way to get the resources they need as quickly as they need them by using hybrid cloud through ICF you’ve taken the first step to controlling shadow IT.

     Cisco Intercloud Fabric 2.2.1, is feature packed with what our customers have asked for to make Hybrid Cloud a reality in their enterprise.

     Cisco Live 2015 in San Diego

     I’ll be presenting several sessions at Cisco Live along with my coworkers be sure to attend one or more.

     PSOCLD1001 – Hybrid Cloud with Intercloud Fabric – Percy Wadia
     TECCLD3001 – Intercloud Fabric Technical Deep dive – Mauricio Arregoces
     DEVNET-2009 – Intercloud Fabric REST APIs for Providers – Paulo Renato DaSilva
     DEVNET-1120 – Intercloud Fabric – AWS and Azure Account Setup and Utilization – John McDonough
     DEVNET-1008 – Private or Public or Hybrid ? Which Cloud Should I choose?
     DEVNET-1009 – Cisco Intercloud Fabric for Business, Helping Enterprises Move to Hybrid Cloud! – Chhavi Nijhawan

     Not and Intercloud session but something I know really well.

     DEVNET-1119 – UCS PowerTool Secrets – Tips and Tricks – John McDonough