Cloud Connectivity

In this lesson, we’ll take a look at different topics related to cloud connectivity:

• Cloud connectivity: the different options to connect to public cloud providers.
• SD-Access: Cisco’s SDN solution for enterprise campus networks.
• SD-WAN: the new software method to configure and manage WAN connections.
• Virtual switching: how we connect virtual machines and containers to the rest of the network.

There is a lot to cover so let’s get started.

Cloud Connectivity

When organizations just start with public cloud services they often use VPNs over the Internet to connect their on-premises applications to the public cloud services.

VPNs over Internet have several advantages:

• Cost: Internet access is cheap compared to private WAN.
• Availability: Internet access is available almost everywhere.
• Migration: easy to switch to another cloud provider because you can reach them all over the Internet.
• Mobile users: if you have many mobile users then they can access cloud services whenever they have an Internet connection.

There are also several disadvantages:

• Bandwidth: depending on your users and applications, your Internet connection might not have enough bandwidth.
• Quality of Service (QoS): the Internet is best-effort. You can prioritize your traffic when it leaves your router but there is no end-to-end QoS.
• SLA: most ISPs don’t offer any SLAs. If they do, your Internet connection could be almost as pricey as a private WAN solution.

If you have applications with certain bandwidth/latency/jitter requirements then VPN over the Internet might not be the best solution.

Fortunately, all large cloud providers offer dedicated connections. We’ll take a look at the top 3 cloud providers: Amazon AWS, Google Cloud, and Microsoft Azure.

Amazon AWS Direct Connect

Amazon AWS offers Direct Connect, a dedicated connection from AWS to your office, datacenter, or co-location.

You can use 802.1Q VLAN tags for multiple virtual interfaces. This allows you to use one VLAN to access public services like S3 with public IP addresses, and another VLAN for private resources like EC2 instances with private IP addresses.

You can get speeds between 1 and 10 Gbps. Lower speeds are available through APN partners that support AWS Direct Connect.

Google Cloud Dedicated Interconnect

Google Cloud Dedicated Interconnect provides a physical connection between the customer and the Google Cloud network through a Google supported co-location. You can get speeds up to 10 Gbps per circuit and there is a maximum of eight circuits per Dedicated Interconnect connection. If you don’t need as much speed, you can use the Partner Interconnect option for speeds between 50 Bps and 10 Gbps.

Microsoft Azure ExpressRoute

With Microsoft Azure ExpressRoute, you connect directly to Azure, Office 365, and Dynamics 365 over a private WAN connection. You get access to all regions within the geopolitical region. With a premium add-on, you get connectivity across all geopolitical regions in the world. You can get speeds up to 10 Gbps.

Multicloud Connectivity

At the beginning of the cloud era, organizations typically had one or a few applications in a single cloud. Later, they started using more services but stuck to the same cloud provider.

Nowadays, there are many different cloud providers and they offer different services. Many organizations are interested to use the best services from each cloud provider so they look into multicloud strategies. This makes sense since each cloud provider offers different services and has its own strengths and weaknesses.

With a multicloud strategy, you are not locked in to one cloud provider and you can build your solution based on the best services from multiple cloud providers.

There are providers like Intercloud who offer a private connection that connects to multiple public cloud providers. This allows you to connect to all cloud providers without using each cloud provider’s own dedicated connection option.

Software Defined Access (SD-Access)

Enterprise networking can get pretty complex. There’s usually a campus, some remote branches, remote workers, and we connect everything together with WAN connections. We have many devices on the physical layer including routers, switches, firewalls, wireless LAN controllers, etc.

There is a lot going on in the logical topology: we have VLANs, VRFs, routing protocols, access-lists, firewall rules, etc. We configure pretty much everything manually with perhaps a bit of network automation to make our lives easier.

Back in 2007/2008, SDN showed up with the promise of automating everything and getting rid of the CLI by defining everything in software.

SDN however, is mostly about datacenters. In the datacenter, everything is about applications. In an enterprise, it’s about (mobile) users and devices. We have users working everywhere using laptops, tablets, and smartphones.

Enterprise networks use a lot of hardware appliances. New firewall? Order a Cisco ASA. Extra wireless LAN controller (WLC)? Order another WLC appliance.

Wouldn’t it be nice if we could spin up new services for our enterprise networks, similar to how cloud services work? If you need a new firewall, just click on a button and it starts a new vASA. Need another WLC? Hit the button, and it starts a virtual WLC.

This is one of the promises of Cisco’s SD-access: complete automation of your enterprise network, similar to how SDN/cloud solutions work. Here’s what it looks like:

There are five main components:

• Fabric
• APIC-EM Controller
• Identity Services Engine (ISE)
• Network Data Platform (NDP)
• DNA center

Fabric

Let’s start with the fabric. This is where you find all hardware components that you are familiar with: routers, switches, wireless LAN controllers, access points, etc. This includes devices that run IOS and IOS XE.

SD-access uses an underlay responsible for forwarding traffic; it’s only job is to provide a transport mechanism. We keep the underlay network simple. We use an overlay network for the different services. The overlay network is flexible and programmable. Why this separation?

You don’t see this separation on most campus enterprise networks but it makes sense. For example, if you want to support a new application on your network then perhaps you have to change an existing access-list. If you change this access-list then it could also affect other applications in your network. You might want to implement the access-list changes during maintenance hours. If you mess up, you can always do a rollback.

With an underlay and overlay network, changes to the overlay network won’t affect your underlay network. It’s similar to using tunneling protocols like GRE or DMVPN. You can mess around with the tunnels, but it won’t affect the underlying network.

We use APIs to configure the hardware devices and to launch new services. It’s still possible to use the CLI for troubleshooting.

The fabric consists of three key components:

• Control plane: based on Locator Identity Separator Protocol (LISP)
• Data plane: based on Virtual Extensibe LAN (VXLAN)
• Policy plane: based on Cisco TrustSec (CTS)

LISP simplifies routing by removing destination information from the routing table and moving it to a centralized mapping system It’s similar to DNS, a router sends a query to a central LISP mapping system and asks where a destination address is. This results in smaller routing tables and requires less CPU cycles.

We could use LISP on the data plane, but it can only tunnel L3 traffic. SD-access uses a modified version of VXLAN on the data plane, one of the reasons is that VXLAN supports L2 encapsulation.

On the policy plane we use Cisco TrustSec, Scalable Group Tags (SGT), and the SGT Exchange Protocol (SXP). We add endpoints that require a similar network policy to a shared group, and we add an SGT to the group. The SGT is a tag that is separate from a network address and you can attach network policies (QoS, PBR, etc.) to it.

This allows you to create network policies without mapping it to IP addresses or subnets. The SGT is added in the VXLAN header.

APIC-EM Controller

The APIC-EM controller is Cisco’s SDN controller for enterprise networks and supports IOS/IOS XE devices. You can use this as a standalone product.

SD-access uses the APIC-EM controller as the SDN controller to control all devices in the fabric. The APIC-EM controller is controlled by DNA center.

DNA Center

DNA center is the portal where you manage everything. It’s web-based, and right now only available as a hardware appliance. If you ask me, that’s strange considering SD-access is all about virtualization. They will probably release a virtual version sometime.

There are four key attributes of DNA center:

• Design
• Policy
• Provision
• Assurance

You can take a look at DNA center for yourself with the Cisco’s Sandboxes. You can log in directly into the DNA center GUI with username “devnetuser” and password “Cisco123!”.

Design

This is where you design your entire network:

• Build the network hierarchy: add sites, buildings, etc.
• IP address management: add the network and subnet addresses you want to use for your networks.
• Network settings: configure DHCP, DNS, SNMP, and Syslog servers. You also create QoS and wireless profiles here.
• Image repository: manage all IOS/IOS XE images of your devices in one place.

Policy

This is where we configure everything that is related to network policies. You create the policies and DNA center translates your policies into configurations for the hardware devices in the fabric.

Provision

This is where we add new devices to the network and where we apply network policies to devices.

Assurance

Assurance is where you monitor the entire network. You can see an overview of all network devices, (wireless) clients, and applications. You can monitor the health status and an overview of all issues in the network.

ISE

ISE is Cisco’s AAA product and has been out for a while now. ISE applies the policies you create through DNA center.

NDP

This is a new Cisco product. NDP is the analytics engine that analyzes all your logging information, NetFlow, SNMP, etc. It collects metrics of everything in the fabric, including devices, users, and “things” (Internet of Things). You can monitor everything that NDP collects through DNA center.

Software Defined WAN (SD-WAN)

Software Defined WAN (SD-WAN) is hot nowadays. Why?

Private WAN connections like MPLS are reliable but also expensive. WAN connections are usually a big chunk of the IT budget, so it’s understandable that organizations are interested in replacing their private WAN connections with regular Internet connections to reduce costs.

To understand SD-WAN, we first have to talk about some “problems” with traditional WAN connections. We can choose between private WAN connections or public Internet connections. Let’s compare these two options:

• Cost: private WAN connections like MPLS are way more expensive than regular Internet connections.
• Time to deploy: it takes longer to deploy a private WAN connection than a regular Internet connection.
• SLA: Service providers offer SLAs for private WAN connections that we don’t have for regular Internet connections. There are providers who offer SLAs for “business” class Internet connections, but these are usually way more expensive than regular (consumer) Internet connections.
• Packet loss: Internet connections have a higher packet loss rate compared to private WAN connections like MPLS.
• QoS: Internet connections don’t offer any QoS. You can prioritize your outgoing traffic but that’s it, the Internet itself is like the wild west. Private WAN connections often support end-to-end QoS.

The way we use our WAN has also changed throughout the years. Most organizations had an HQ, remote users, and perhaps some branch offices. Branch offices were connected to the HQ with private WAN or VPNs over the Internet. Remote users used remote VPN over the Internet to connect.

Nowadays, organizations also run their own applications in the cloud instead of on-premises, and they use applications like Office 365 or Gsuite. Our traffic patterns look different now:

What about network management? Each router has its own control plane, and we use the CLI to manually create our router configurations “box-by-box”. This is time-consuming and prone to errors. We can use network automation tools to make our lives easier, but the control plane remains decentralized.

SD-WAN promises to save money by using a combination of Internet and private WAN connections and make network management much easier.

One problem with SD-WAN is that each vendor has a different idea about what SD-WAN is. I’ll give you a basic overview of what SD-WAN is about. An SD-WAN solution has parts of the control plane centralized and is built with network automation and orchestration in mind. We create network policies globally and push them to all routers from a central location. You could create a QoS policy and push it to all your 500 branch routers with a single mouse click. We don’t use the CLI anymore. Instead, we have a GUI and use APIs to configure and manage our WAN connections. Some vendors still support a CLI if you want to do some troubleshooting.

We use multiple WAN connections and active/active per-application load-balancing. Let’s say we have a site with a fiber, cable, 4G, and DSL connection. SD-WAN monitors all these WAN connections and keeps track of performance metrics like the throughput and delay. It selects the WAN connection with the lowest latency and highest throughput.

When a certain link fails then it can fail over to the next best option. It can also do this on a per-application level. You could use the fiber connection for traffic to the public cloud and the cable connection for low-priority FTP traffic. It protectson traffic over public Internet connections with IPSec.

SD-WAN could be an alternative to an expensive private WAN link with an SLA that promises “five nines” of uptime (99.999%). The idea behind it is that multiple WAN connections are always more reliable than a single WAN connection.

Cisco SD-WAN Solutions

Cisco offers three SD-WAN solutions:

• • Intelligent WAN (IWAN)
  • Meraki SD-WAN
  • Cisco SD-WAN (Viptela)

IWAN is Cisco’s first SD-WAN solution for the ISR platform and intended for hybrid WAN (MPLS and Internet) or Internet-only connections.

Behind the scenes they use some familiar protocols:

• DMVPN with QoS
• Wide Area Application Services (WAAS)
• Application Visibility and Control (AVC)
• Performance Routing (PfR)

Meraki SD-WAN is for existing Meraki customers that are interested in the advantages of SD-WAN. Here are some features that it offers:

• Apply bandwidth, routing, and security policies from a central location to all WAN connections (MPLS, Internet, 4G, etc.)
• Centralized network visibility and control.
• QoS and bandwidth management with Meraki traffic shaping
• Dynamic policy and performance-based path selection with automatic load balancing.
• Secure connectivity with cloud applications, remote offices, or datacenters.

Cisco SD-WAN (Viptela)

Cisco acquired Viptela, a major SD-WAN player, in 2017 and re-branded it to Cisco SD-WAN. This is Cisco’s enterprise SD-WAN solution.

Components

This solution consists of four main components and one optional analytics component:

• vManage (management)
• vSmart (controller)
• vEdge (routers)
• vBond (orchestrator)
• vAnalytics (analytics)

Let me explain these components.

vManage

vManage is the Network Management System (NMS) to configure and manage the entire SD-WAN solution. You can use a GUI or REST API to access it. This is where you create device configurations and network policies. vManage also alerts you when there are events or outages.

vSmart

vSmart is the control plane of the architecture. vSmart controllers advertise routes, security, and policy information. Cisco SD-WAN uses the proprietary Overlay Management Protocol (OMP) for this. vSmart implements the policies that you configure through vManage.

For example, imagine you create a policy through vManage where real-time voice traffic requires a latency of less than 100 ms. The vSmart controller downloads the policy, converts it into a format suitable for the vEdge routers and then implements it on all vEdge routers.

All vEdge routers peer with a vSmart controller, it’s a hub and spoke topology. It’s similar to a BGP route reflector or a DMVPN NHRP server. The vSmart controller only lives in the control plane and is never in the data plane.

vEdge

vEdge is the software or hardware routers at your sites and responsible for the data plane. vEdge routers connect to a vSmart controller through a Datagram Transport Layer Security (DTLS) connection. If you want to use hardware, you have the following options:

• Viptela vEdge: 100, 1000, 2000, or 5000 series routers.
• Cisco ISR and ASR: the IOS XE SD-WAN software image allows you to use Cisco SD-WAN on the ISR 1000, ISR 4000, and ASR 1000 series.
• Cisco ENCS: similar to the ISR series, you can use the IOS XE SD-WAN software images for the ENCS 5000 series platform.

If you want to use software, you have two options for VMs:

• vEdge Cloud
• Cisco Cloud Services Router (CSR)

vBond

vBond is the orchestrator. It authenticates vSmart controllers and vEdge routers and coordinates connectivity between them. It tells vEdge routers where and how to connect to vManage and vSmart controllers. vBond requires a public IP address so that all devices can connect to it. When a vEdge router joins the SD-WAN, the first thing it talks to is the vBond orchestrator.

vAnalytics

vAnalytics is an optional analytics service. It gives you visibility of applications and your infrastructure in the entire SD-WAN. You can use it for forecasting, and it gives you recommendations about your traffic and WAN connections. This can be useful to figure out whether you need to upgrade or downgrade certain WAN connections.

Cloud or on-premises

You can implement Cisco SD-WAN with a combination of cloud and on-premises options:

• The vEdge routers and vBond orchestrator are available as hardware or VMs.
• vManage and vSmart controllers are only available as VMs.

You can run the VMs on-premises on ESXi or KVM, or host them at cloud providers like Amazon AWS or Microsoft Azure.

Cloud onRamp

In the traditional model, you find all on-premises infrastructure and applications in a central HQ site or data center. We connect our branch offices in a hub and spoke topology and route all traffic from the branch offices to the HQ or datacenter.

Organizations nowadays often use cloud SaaS applications like Office 365, Gmail, or Salesforce. Instead of running everything on-premises, we also use IaaS services in the public cloud.

The traditional hub and spoke model where we connect and route all branch traffic to the main site or datacenter doesn’t work anymore. Cisco SD-WAN connects sites directly to these SaaS applications or IaaS services using one or more WAN connections.

There are two options:

• Cloud onRamp SaaS
• Cloud onRamp IaaS

Cloud onRamp SaaS monitors the performance of all WAN connections from a branch office to a SaaS application. Each path gets a “quality of experience” performance score from 0-10, 10 being the highest score. It makes real-time decisions to choose the best performing path between the end users at the branch office and the SaaS application in the cloud. You can monitor this in the vManage GUI.

Cloud onRamp IaaS extends the SD-WAN network into the public cloud. Through vManage, you can automatically create vEdge cloud routers in the public cloud provider infrastructure. This allows you to connect directly from your on-premises vEdge routers to the vEdge cloud routers at the public cloud provider.

Virtual Switching

VMs and containers both require network connectivity. Since they are virtual, we also need virtual networking. In this section, we’ll talk about how VMs and containers connect to the network.

Virtual Machines

VMs have virtual NICs (vNIC) which connect to virtual switches (vSwitch). A vSwitch is similar to a normal layer two switch, but it’s virtual. We use a vSwitch so that a VM on a hypervisor can communicate with other VMs or external networks outside of the physical server through the physical NIC (pNIC). You can create one or more vSwitches on a hypervisor.

One issue with vSwitches is that you have to configure them on every hypervisor. This can become an administrative burden if you have lots of hypervisors. To make our lives easier, we can use distributed virtual switching. This is a feature that aggregates the vSwitches in a cluster of hypervisors and treats them as a single distributed switch.

Distributed virtual switching has advantages:

• Centralized management of all vSwitches in a cluster.
• Configuration consistency.
• Allows network policies and statistics to migrate when a VM migrates from one hypervisor to another.

Here is an overview with examples of native and third-party vSwitches you can use for different hypervisors:

Hypervisor	Native vSwitch	Third party vSwitch
vSphere	Standard vSwitch Distributed Virtual Switch	Cisco Nexus 1000V Cisco VM-FEX IBM DVS 5000V HPE 5900v
Hyper-V	Native Hyper-V Virtual Switch	Cisco Nexus 1000V Cisco VM-FEX NEC Broadcom
KVM	Linux Bridge Open vSwitch (OVS)	Cisco Nexus 1000V Open vSwitch (OVS)
XEN	Open vSwitch (OVS)	Open vSwitch (OVS)

VMWare stopped support for third-party vSwitches since vSphere 6.5U2.

Containers

Containers also require network connectivity. We use virtual bridges instead of virtual switches. Docker is the most popular container engine at the moment so let me give you an example of what Docker networking looks like:

Docker creates a virtual bridge called Docker0 and assigns an RFC1918 private range subnet to it which is not in use on the host machine. Each container connects to the Docker0 bridge with a vEth interface that appears as the eth0 interface in the container. Each eth0 interface receives an IP address from the subnet of the Docker0 virtual bridge.

This allows all containers on the same host to communicate with each other. If you want containers to communicate with the outside world, then Docker uses Iptables and NAT to forward ports from the outside physical interface to the vEth interface.

This setup with the Docker0 virtual bridge and port forwarding is fine for a single host. If you have multiple hosts, lots of containers, require networking between containers, and want to scale containers then it’s best to dive into container orchestration like Docker Swarm or Kubernetes. Kubernetes is the most popular option today, something we will discuss in another lesson.

Conclusion

In this lesson, we talked about quite some items:

• Cloud connectivity:
  • The advantages and disadvantages of VPN over the Internet to access public cloud services.
  • Private WAN connections for the big three cloud providers.
  • Why most organizations look for a multicloud strategy nowadays.
• SD-Access:
  • Cisco’s SDN solution for enterprise campus networks.
  • The different components of the SD-Access architecture.
• SD-WAN:
  • What SD-WAN is and why it is such a hot topic nowadays.
  • The three Cisco SD-WAN solutions:
    • Intelligent WAN (IWAN)
    • Meraki SD-WAN
    • Cisco SD-WAN (Viptela)
      • We took a closer look at Cisco SD-WAN and its different components.
      • We discussed Cloud Onramp so you can connect directly to SaaS applications and IaaS services in the cloud.
• Virtual switching:
  • How VMs use vSwitches to connect to the network.
  • How docker containers use virtual bridges to connect to the network.

I hope you enjoyed this lesson, if you have any questions, please leave a comment.