Cisco offers two different SD WAN product lines through its previous acquisitions of Meraki and Viptela. Both are available as hybrid managed services.
This product page provides an overview of Cisco Meraki and Viptela SD WAN by reviewing product lines and different WAN connectivity options, along with a comparison of failover, security, reporting and miscellaneous features. Meraki and Viptela are positioned to offer businesses the ability to self manage services - Cisco also recognise there is a need to provide managed installation and configuration expertise.
The software and features of the 2017 Viptela acquisition are now starting to be integrated into more general Cisco product lines with the introduction of Viptela-based SD WAN on certain Cisco IOS XE routers such as the ISR 4000 and ASR 1000 series. Viptela completely replaces Cisco’s older IWAN offering. Meraki has remained mostly independent from other Cisco product lines since being acquired in 2012 and is intended to serve a different market.
Cisco provides both physical hardware and virtualised software appliances for both Meraki and Viptela. This is good from a customer perspective because there is a wide range of business needs and use cases, and both product lines have something to offer.
Meraki, in general, is designed with ease of deployment and ongoing operations in mind and provides a baseline feature set that covers that vast majority of traditional business needs. While Meraki offers many different products including switches and wireless access points (WAPs), all Meraki SD WAN capable devices are within the MX series of security appliances.
The hardware appliances come in several different form factors. All models feature dual WAN uplink capability and USB 4G backup. Some models have built-in 4G modems, some have WiFi capabilities, and others include many switch ports to enable “branch in a box” functionality, including Power over Ethernet (PoE) for phones, WAPs and video cameras.
The virtualised vMX product line is available only for deployment within Amazon AWS or Microsoft Azure public clouds. Meraki’s SD WAN controller model is entirely cloud-based, with Cisco always maintaining full responsibility over maintaining controller availability. Meraki can be deployed very easily by people with less technical skills because there are fewer configuration options available and you do not have to configure and deploy a separate controller. With the knowledge that you underlying BT connectivity is backed up with an SLA and one of the best engineered networks in the world, our Cisco platform adds the intelligence.
Viptela, on the other hand, supports a much greater range of features than Meraki. Viptela does make ongoing operations easier by supporting features like Zero Touch Provisioning (ZTP) but requires more initial design and preparation work than Meraki does depending on how specific your network architecture needs are.
Hardware appliances are categorised by their general purpose. The Cisco ISR 1000-series and vEdge 100 routers are designed for small branch offices. The ISR 4000-series and vEdge 1000 routers are intended for medium-size branches and small campus environments. The ASR 1000-series and vEdge 2000 and 5000 models are designed for large campuses and datacentres. Viptela is also available in the ENCS 5100 and 5400 series appliances, which are purpose-built virtualisation hosts intended for virtual network functions (VNF) deployment.
The virtual Viptela edge appliance can also be run in Amazon AWS and Microsoft Azure public clouds, but unlike Meraki, Viptela is also available for your own private cloud in KVM and VMware ESXi formats. This provides maximum flexibility for deployment options as you are no longer tied to physical hardware and can deploy Viptela SD WAN anywhere an x86 hypervisor with enough resources is available.
You could conceivably reply BT WAN circuits and have an entire SD WAN environment in software only without relying on standalone SD WAN appliances.
Above. SD-WAN Services over the Internet.
Meraki supports only two different access types: BT Ethernet leased lines and 4G via BT Mobile through a USB modem, which can be external or internal depending on the appliance model. With Meraki, if your transport does not support a native Ethernet handoff, you will need an intermediary device to terminate the circuit (such as with serial E1/E3 connections). All Meraki MX appliances support dual wired WAN uplinks.
Meraki supports two different BT VPN routing models: full mesh and hub-and-spoke with an automatic full mesh between hubs. Full mesh provides a direct tunnel connection between all of your BT and 3rd party sites but note that this configuration can lead to hardware performance issues. If you have a lot of sites to connect over SD WAN since many site-to-site tunnels must be maintained. The hub-and-spoke model is appropriate if you have many BT SD WAN locations because you can designate a couple of sites as hubs with more powerful hardware and then use less expensive appliances at the spoke sites.
Viptela supports more than two active WAN uplinks and can use a variety of transports in addition to standard Ethernet including PPP interfaces and GRE tunnels, depending on the hardware used. The Cisco ISR and ASR series routers support more transport options than the vEdge appliances due to the rich history physical interface support in Cisco routers. Viptela also supports using native 4G interfaces simultaneously with other active wired uplinks.
Unlike Meraki, Viptela supports creating multiple VPN architectures over the same set of BT WAN uplinks. For example, you can specify that a full mesh is established between all of your sites just for Voice over IP (VoIP) traffic, whereas application traffic destined to your datacentre will reside strictly in a hub-and-spoke VPN. Options are full mesh, partial mesh, hub-and-spoke, and point-to-point.
Meraki supports a maximum of two simultaneous BT SD WAN uplinks plus a backup 4G connection. The USB or internal 4G/LTE modem can only be used if there are no wired links currently available, which means if you require a single active wired link along with a single secondary active 4G data link, you will need to provide wireless data to your MX appliance through an external 4G Ethernet device. Meraki supports an active/passive model for hardware high availability (HA) with failover times taking an average of 30 seconds to complete. From an SD WAN tunnel failover perspective, spoke appliances can be configured with a hub preference so that if the primary hub becomes unavailable, secondary and tertiary hubs can be used instead.
Viptela allows you to use all available transports simultaneously in active/active mode. BT failover in the SD WAN overlay occurs much more rapidly because the Bidirectional Forwarding Detection (BFD) protocol is used to detect failures along the entire SD WAN path. Viptela supports active/active hardware appliances as well, which is important for large campus and datacentre environments where even a few seconds of downtime can be unacceptable.
The result could be an unstable path for your application causing issues we’re all familiar with across networking. While Cisco IP SLA will measure path performance, the actual route remains unmodified.
We think of the Internet as being a mostly inferior network to layer 3 Private MPLS, but the reality is that most public networks are well scaled and utilise the traffic engineering properties of the MPLS protocol. This is especially true
SD-WAN with PfR (Performance Routing) supports intelligent path control based on the application class. If a path becomes unstable, alternative connectivity is selected for the application to improve performance until the original path properties improve.
In scenarios where bandwidth becomes congested, further connectivity (BT or 3rd party) will be used if available to compliment primary connectivity.
This feature should not be understated. With traditional WAN failover, primary circuits often remain up when services become degraded. The failover state is binary - unless the primary is hard down, the failover circuit remains unused.
Above. IPR - Intelligent Path Control
The Meraki MX series product line was marketed from the very beginning as a security appliance. It has Next Generation Firewall (NGFW) features and can act as an Intrusion Detection System / Intrusion Prevention System (IDS/IPS), along with providing content filtering and geo-IP restrictions, which means you can limit connectivity to various parts of the world across BT Global Internet services. Meraki also supports Cisco’s AMP and ThreatGrid technologies and integrates with Cisco Talos security services.
Cisco hardware that supports Viptela SD WAN has the same security-oriented features as Meraki (with AMP and Talos support coming later in 2019). Viptela also supports an interesting VPN security architecture in which segmentation and multitenancy are maintained over the SD WAN service. For an every SD WAN edge appliance, Viptela maintains separate underlay WAN and out of band management VPNs, and then individual LAN-facing VPNs use the SD WAN overlay. This means that just like with interfaces assigned to different Virtual Routing and Forwarding (VRF) instances, you can assign interfaces in the same Viptela edge to different VPNs to maintain security and traffic separation end-to-end. In addition to multitenancy, this can be used to maintain various industry compliance and data privacy standards.
Meraki and Viptela both provide reporting capabilities through web-based dashboards access via secure BT connectivity. Meraki’s dashboard will show you different traffic statistics including link performance and utilisation based on applications. Meraki also supports interaction with a REST API, as well as traditional data collection access methods like SNMP, syslog, and NetFlow. When you are using multiple WAN uplinks, one of the more interesting things the Meraki dashboard will show you is which link was used for a particular data flow and the reason why the link was used. For instance, one link might be selected over another because VoIP traffic was being sent and the chosen link had lower latency.
Whereas Meraki combines all aspects of SD WAN configuration, monitoring and management into a single cloud-based controller, Viptela uses a different architecture that dedicates certain functions to individual appliances. This allows for greater scale and expandability. Viptela vBond is the orchestrator appliance that coordinates everything and vSmart is the control plane which maintains the SD WAN overlays.
The vManage appliance provides both configuration, monitoring and reporting capabilities. Viptela provides real-time alerting along with path performance measurements based on BFD. You can interact with vManage through a REST API, along with SNMP, syslog and NetFlow. Unlike Meraki, Viptela SD WAN also supports NETCONF and command-line interface (CLI) interactions.
Meraki and Viptela share a few miscellaneous features in common. Both support using Open Shortest Path First (OSPF) as a routing protocol. Support for Border Gateway Protocol (BGP) is currently in beta testing for Meraki, whereas Viptela has full BGP functionality. Meraki supports application bandwidth limiting and traffic prioritisation based on a 3-class model. Viptela supports a full range of Quality of Service (QoS) features including recognising and utilising DSCP tagging. Depending on whether your connectivity is based on BT MPLS or BT Internet will dictate whether the end to end QoS is carried end to end.
Meraki has no support for (requested by BT) IPv6 or multicast traffic, whereas Viptela supports both. While multicast may be considered a more niche feature, having full IPv6 support in both the underlay and SD WAN overlay is becoming increasingly important, especially for markets where obtaining public IPv4 address space is becoming increasingly more difficult and expensive.
Meraki and Viptela both support Zero Touch Provisioning (ZTP) through web-based portals. ZTP is part of the allure of SD WAN because it dramatically simplifies deploying both new and replacement SD WAN appliances. Other BT clients leverage 4G connections provided by BT Mobile for fast start scenarios.
With ZTP, the appliance is powered on with a blank configuration and uses DHCP to obtain an IP address to connect to the Internet. After Internet connectivity is established, the SD WAN appliance contacts the SD WAN controller and downloads the configuration designated for that particular appliance (typically based on serial number). In the past, when new sites were deployed or hardware needed to be replaced, the devices had to be configured ahead of time before being shipped to the locations. ZTP makes this unnecessary and appliances can be shipped without preconfiguration which saves time and other resources.
Viptela additionally supports TCP optimisation and WAN acceleration. These features are integrated into the platform and help you achieve better performance from your BT SD WAN uplinks. Viptela also supports service function chaining (SFC) where different NFVs can be configured to process network traffic in a specific order depending on your exact needs. Features like these make Viptela a more versatile platform as compared to Meraki, but likewise need staff with more advanced technical knowledge to properly implement them. For many organisations, these kinds of advanced customisations are unnecessary, which makes Meraki a potentially better fit in those situations.
The two Cisco SD WAN product lines described in this article have several overlapping features, but Cisco has made it clear that Meraki and Viptela are geared toward two different markets and general deployment models. Meraki is designed for simplicity and ease of use above everything else which makes deploying a Meraki SD WAN solution perfect if your business does not have very specific niche requirements or if your support staff is less technical. Viptela has more advanced features available which require a higher level of technical knowledge to achieve a proper network architecture, though if you have specific networking needs like IPv6 or multicast support, the Viptela solution delivers these technologies today with many more configuration options.
You can also opt for a hybrid architecture and use both platforms. Meraki and Viptela will not interact with each other directly, but you could use Meraki if you have many sites that could benefit from the overall simplicity and ease of use Meraki provides, and use Viptela for sites that have more advanced requirements. You can then use a protocol like OSPF or BGP to connect the two separate SD WAN environments together at selected hub “meeting points” such as within your datacentres.
In both respects, Network Union is well positioned to design and propose Cisco Meraki or Viptela across BT connectivity.
Further diversity is available via additional partnerships where needed. 3rd party Internet with 3G, 4G and leased lines are options for integration.
While our primary backbone choice remains BT Global and UK Services, we have a range of other options providing high availability.
WAN / SIP / TRADITIONAL TELEPHONY / LAN / WIRELESS / CALL RECORDING / MERAKI
DATA CENTRE / SERVERS / VIRTUALISATION / STORAGE / DATA MIGRATION / BACKUP / CONTENT FILTERING / SECURITY AND PCI COMPLIANCE
BT COMPUTE IAAS / PRIVATE CLOUD IAAS / OFFICE 365 INTEGRATION / DESKTOP VIRTUALISATION / MICROSOFT AZURE
MPLS / VPLS / ETHERFLOW ETHERNET / BTNET LEASED LINE / CLOUD / SECURITY
24/7 SERVICE DESK / TECHNICAL EXPERTS / ITIL3 PROCESSES / ISO27001 SECURITY / ISO20000 ITSM / EVENT MANAGEMENT / IL3 / GPG13 SERVICES / 3RD PARTY MANAGEMENT
You need the Wide Open Space project.