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
• DNA Center Appliance
• Identity Services Engine (ISE)
• Network Data Platform (NDP)
• DNA Center Dashboard

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

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.