iWANT CloudGenix Challenge – tech under the hood

By Aaron Edwards
Director, Technical Marketing for CloudGenix

Attendees of CiscoLive in Las Vegas verified that compared to Cisco IWAN, CloudGenix SD-WAN uniquely delivers a cloud-ready WAN, is orders of magnitude faster to deploy, and uniquely provides native application-SLA monitoring. Attendees tested hands-on the power of CloudGenix’ application-defined approach compared to the packet-based approaches of hybrid WAN products such as Cisco IWAN.

It was a simple test, and one that is important in real-life for most customers:

  1. Set up and configure a basic SD-WAN configuration
  2. Enable direct-to-cloud over Internet selectively for cloud based applications (ex. SalesForce and Microsoft Office365)
  3. Monitor/Manage the solution to collect IT & business relevant analytics

Seems simple, right? But what was going on under the covers? How is a pure-play startup able to so completely blow away a solution from a multi-product vendor like Cisco?

Getting to the starting line.

With CloudGenix, all of your Configuration, Orchestration, and Analytics are provided via the CloudGenix Cloud Controller. Zero setup required.

During planning of the challenge, we quickly realized if we wanted to have the audience get to the testing tasks, we’d have to handicap Cisco – we’d need to provide already installed running, and configured copies of APIC-EM 1.2 with IWAN App and Cisco Prime Infrastructure 3.1.

Assuming we were ready for the task, we enlisted the help of certified partners and began the Cisco management layer install. Sure enough, 36 hours later – after several restarts/reinstalls/failed attempts/Hiring the best APIC-EM expert out there (Tech Note: APIC-EM needs WAY MORE than the minimum specs), we had a functional factory install running in the lab.

Essentially, IWAN’s management and visibility needs two days + several CCIE hours just to get to where you are with CloudGenix the minute you pick up the phone and order.

No Legacy Cruft

CloudGenix’s ION was designed from day one to drive applications, not packets. Policy, configuration and API’s were designed from the ground up to focus on enabling application centric policies and workflows. This results in the leanest, best, purpose built system that can build a SD-WAN at essentially the touch of a button.

Since the 90s, IOS has been the gold-standard of network configuration and operating systems for packet routed systems.  Cisco’s IWAN is built on top of a layer 3 packet routed architecture.

Great! … Until you want to do something innovative and different like manage to applications rather than packets

Under the covers, IOS (and its successor, IOS-XE) severely limit the agility and capability of any solution built with it. These OS’s were built, tweaked, and optimized to “forward packets” – but everything else is a bolt-on.

Q1. Why does NBAR2 bring your router to its knees?
Q2. Why is it that PfR cannot re-route traffic direct to the Internet at the branch?
Q3. Why does APIC-EM take 10 minutes to push a simple configuration to a brand new router?

The main answer is – “These features are all afterthoughts to IOS’s core.” In more detail:

A1. NBAR2 has to maintain a separate application table in addition to the RIB/FIB forwarding table in the router, which can exponentially increases usage for the same load.
A2. PfRv3 was designed with a focus on the legacy Enterprise WAN where the assumption is your applications reside within your Enterprise DC. As such, it operates only on traffic flowing via DMVPN overlays.  It can NOT control, and has no understanding of traffic sent outside this DMVPN overlay – whether that’s a direct to Internet path, or your provider’s MPLS network.
A3. APIC-EM still speaks SSH/SNMP and IOS CLI commands, instead of a lightweight, purpose-built WAN-focused API. Sending an automated command, and verify it does not break every possible other legacy CLI is truly hard work.

This small sample of features illustrates why IOS requires herculean efforts in engineering (On both Cisco’s and the customer’s side) to ever possibly work together. Ultimately, this results in small things to take 2-5x the time and system resources they ever should.

CloudGenix: “Take ownership of IONs, send Basic address and network info, activate.” – Test 1 done in 5 minutes.

Cisco IWAN: “Sync APIC-EM and Prime, adjust refresh timers, set usernames, enter SNMP values, Enter addresses to MC and headend, set up routing protocols, assign address pools, verify, wait 10 minutes for APIC-EM to SSH to routers and push config, have push fail, rollback and retry, beat head against keyboard repeatedly and give up… and this was just for the first device on the first site.”

3 steps and five minutes vs. 30+ steps and days? No contest.

Application Defined

“First thing I do when I get online is open up a web browser to, then move on and check my messages at What? You don’t do this?” – Welcome to life as a Router.

While the rest of the world goes to “Salesforce” and “Office365”, routers are stuck. They see everything as packets, dutifully forwarding them day and night. Try to send traffic to “Office365” using an IOS command. If it isn’t a 20-page Access List  + PBR + fVRF spaghetti nightmare (that still misses things), you’re not even close.

CloudGenix’s IONs were designed from the ground up to deliver Applications. This means that you tell us where you want “Salesforce” to go, not some massive-IP construct.

“Salesforce, go directly out the Internet.” – Challenge 2 done for CloudGenix – a cloud-ready network built with a simple application policy statement.

Cisco IWAN? Still trying to update the ACL…
Also, by now if you guessed that the third test with native application and network visibility demonstrates capabilities unique to CloudGenix, you are correct!

Surprised? Don’t be. When you design a system from the ground up to work on Applications in a powerful manner, things just work.

Don’t take my word for it though – try it yourself! Email