Check out Part 1 and Part 2 where we put together a scalable foundation and connect cloud networks from AWS, Azure, and GCP. For Part 3, we will bring on-premises back into the spotlight and connect some sites over Cisco SD-WAN and IPSEC.

On-premises remains a strong focus for many enterprises through 2021 going into 2022. Some workloads, as noted by Amazon CEO Andy Jassy, may never move to the cloud. While this may seem like a shocker, if continuing to run specific workloads on-premises makes sense from a cost or compliance standpoint, why should they move?

Scenario

Let’s expand on our network design layout from Part 2 and add some requirements for our on-premises networks. For this example, my SD-WAN fabric consists of two data centers + HQ in the East region which, will have connectivity extended to my East CXP. Three smaller sites will get connected directly via IPSEC.

  • Sites with <= 10 users will connect into Alkira’s CXP over IPSEC
  • All other sites are on Cisco’s SD-WAN fabric and get extended into the CXP

In the enterprise space, connectivity can be handled in numerous ways. For instance, many enterprises may want or already have AWS Direct Connect, specifically for its bandwidth and performance. Alkira makes it simple to leverage existing options to connect data centers and sites to Cloud Exchange Points meeting enterprise networking where it lives today and providing a path forward to elastic networks of the future.

Topology

Resources

Name Type Description
alkira_credential_cisco_sdwan resource Provision Cisco SD-WAN Credential
alkira_connector_cisco_sdwan resource Provision Cisco SD-WAN Connector
alkira_connector_ipsec resource Provision IPSEC Connector

Connecting On-Premises

A great deal of focus has been placed on the cloud over the past five years. However, for large enterprises, migrating and modernizing applications using the public cloud isn’t as simple as a project, program, or throwing lots of cash down to get it done in a year exercise. Playing the long-game is critical, and on-premises shouldn’t be ignored.

Terraform Cloud

Like Part 1 and Part 2, I used Terraform Cloud for provisioning. I’m going to forgo explanation in this post to minimize repetition. To get a better understanding of how I organized things, check this out.

IPSEC Connectors

IPSEC can be set up with static or dynamic routing via route based VPN mode. Connecting sites to Alkira consists of defining the connector along with each endpoint that should be associated with it.

ipsec_connector.tf

Provision IPSEC

SD-WAN Connectors

Extending the Cisco SD-WAN fabric into Alkira consists of defining the connector, endpoints, and the bootstrap file from Cisco vManage. The SD-WAN fabric will then be extended into one or more Cloud Exchange Points, enabling regional hand-offs between the two.

cisco_sdwan_connector.tf

Provision SD-WAN

I used Cisco SD-WAN for this post. Today, all three node types (CSR, vEdge, and CAT8000v) are supported. Alkira continually adds new partner integrations, like Aruba EdgeConnect so keep a lookout for new product announcements

Conclusion

In Part 1, we built a scalable foundation, and in Part 2, we connected networks to that foundation from AWS, Azure, and GCP. This post brought data centers and remote offices into the picture over IPSEC and SD-WAN.

Now that we have all of these networks connected, what about policy and service insertion? To be helpful to enterprises adopting cloud, limiting communication to and across clouds and on-premises is a given. Also, selectively steering specific traffic through VM-Series Firewalls should be a trivial task. In Part 4, we will define policies in code and use Alkira’s design canvas to validate.