- Get four Apple AirTags for just $73 with this Black Friday deal
- I tested Beats' new Pill speaker and it delivered gloriously smooth sound (and it's on sale for Black Friday)
- These Sony headphones are a fan favorite - and $150 off for Black Friday
- I tested a 'luxury' nugget ice maker, and it's totally worth it - plus it's $150 off for Black Friday
- The Dyson Airwrap is $120 off ahead of Black Friday - finally
A simpler, more flexible SD-WAN design for branches, from Customer Zero. Top five benefits. – Cisco Blogs
In collaboration with Jamie Mcgregor
Like fingerprints and snowflakes, every SD-WAN deployment is different. We originally designed the Cisco IT SD-WAN with dedicated infrastructure for each network and security domain—for example, SD-Access, Cisco SD-WAN or Meraki SD-WAN, next-gen firewall, and telemetry analytics.
But having separate devices for each domain complicates deployment. It increases equipment costs. And it restricts policy, segmentation, and telemetry analytics to a single domain, limiting the value.
The Customer Zero team in Cisco IT overcame those problems with a regional hub design for SD-WAN—in production today. Our existing infrastructure (SD-Access, SD-WAN, next-gen firewall, and telemetry analytics) became the building blocks for a secure access service edge (SASE). The heart of the design is a secure edge fabric that provides transport and services to all branches and campuses in a region. This blog explains how we built the fabric and summarizes the benefits to date. By sharing our experiences deploying new technologies (and existing technologies used in new ways), the Customer Zero team helps to smooth the journey for other companies.
The appeal of a regional hub design
Jamie and I previously worked in Cisco IT Network Services. When we joined the Customer Zero team, we asked, “If we could re-design the WAN from scratch, what would make it simpler and more flexible?”
The result is the regional hub design shown in figure 1. Branches connect to the regional hub. Think of the hub as a flexible routing and switching fabric that aggregates connections from different domains. The hub also “chains in” services when they’re needed, like Cisco Secure Firewall, Cisco ThousandEyes for analyzing user-experience data, and Cisco Catalyst 8000 for connecting to cloud services.
So far, we’ve deployed regional SD-WAN hubs in San Jose, California, London, and Sydney. Research Triangle Park, North Carolina is in progress. The design follows the SASE model, which combines the campus fabric with security. We’re doing the work at the same time we roll out the Cisco Telework solution described in this blog. Note: we started this project before Cisco Umbrella had SASE support. The principles are the same, and later we’ll transition to Cisco Umbrella for SASE.
Five benefits of the Customer Zero regional hub design for Cisco
1 – Branch traffic takes four fewer hops to get to the cloud, reducing latency.
Previously, our SD-WAN transport path went through our DMZ network before arriving at the SD-WAN edge. Many hops were unnecessary, like corporate gateways, DMZ switches, and our corporate firewall, as shown in Figure 2. Sending trusted encrypted traffic through a firewall provides little value, consumes costly resources, and is difficult to scale. We made the SD-WAN transport path more efficient by connecting the ISP edge directly to the SD-WAN edge, using a simple ACL that only allows trusted connections. The outcomes: less latency and fewer points of failure.
2 – Chaining in security and analytics services only when needed conserves bandwidth and improves performance.
Before, all traffic went through that domain’s firewall. Even encrypted traffic, which the firewall doesn’t inspect. Thanks to Cisco SD-WAN’s programmable policy, the secure edge fabric chains in firewall services and telemetry analytics (like Cisco ThousandEyes) only for traffic that needs it.
3 – SD-Access extends across the entire region instead of stopping at the edge of each domain.
Now we don’t have to painstakingly maintain access control lists (ACLs) on each router and switch. Instead, we use SD-Access to control which devices can access which VLANs and applications. The short story: we use Cisco DNA Center to create virtual networks (VNs) and scalable group tags (SGTs) for user groups with different privileges. Every switch, router, or firewall on the path looks at the tag to see which VLANs and applications the device can access. For more detail, check out this blog.
Our first SD-Access deployments at Cisco were like islands. When traffic exited the SD-Access fabric, it lost the SGT. With the new hub design, SGT remains with traffic when it crosses domains. We can preserve segmentation and policy across SD-WAN, SD-Access, and teleworker solutions. That means, for instance, that security personnel can monitor IP security camera feeds in remote locations. Access policies are maintained on a centralized firewall or at the destination switch, eliminating the hassle of ACLs.
4 – We can keep using the management tools we know and like.
For fusion routers and core switches, that’s Cisco DNA Center. For next-gen firewalls, it’s Cisco Firepower Management Center. For Cisco wide-area gateways it’s vManage, and for Meraki it’s the Meraki dashboard, as shown in figure 3.
5 – Telemetry information from multiple domains provide better insights.
We on the Customer Zero team use DNA Traffic Telemetry Appliance to send information from switches and routers to Cisco DNA Center for analytics. Deploying the appliance at the regional hub gives us visibility across multiple domains. That’s especially useful for monitoring the user experience. For example, suppose we’re seeing cases on Webex video quality. Jitter and packet loss are hard to troubleshoot, and previously we could only see the problem on SD-Access sites. Now that the appliance is in our regional hub, we can see telemetry data across a longer path and pinpoint issues across domains, whether it’s SD-Access, SD-WAN, or remote access VPN.
We’re also planning to deploy ThousandEyes at the hub, to better understand the application and user experience. Aggregating data from multiple branches will give us deeper insights. For example, it’s generally accepted that sending branch SaaS traffic directly over the branch’s direct internet link is more efficient than backhauling it to a data center. However, that might not be true if the data center has direct peering connections to major ISPs via an internet exchange point (IXP) fabric, which we have at Cisco. With ThousandEyes deployed on the hub, we’ll be able to compare and choose the most efficient path. Since most IT applications are moving to the cloud – which is a network outside of our control – ThousandEyes helps provide hop-by-hop granular insights into how these external networks are performing.
Next steps for the Customer Zero team include testing the Cisco Telework solution with SD-WAN, as described in this blog, and replacing our internally developed solution with the equivalent solution from Umbrella.
Summing up
With the new Customer Zero hub design, network domains can interconnect whether they use Cisco SD-WAN, Meraki SD-WAN, or SD-Access. Security policies are enforced consistently. Traffic takes fewer hops to its destination, for a better experience. And chaining in services only when needed conserves bandwidth.
Bottom line: we have more flexibility. Instead of making changes at every domain, we can make them centrally, on the secure edge fabric connecting all domains in a region.
Learn more about our journey to an advanced network
architecture by clicking through our interactive journey map
Follow Cisco IT on social!
For more information:
Bringing SD-WAN to Our Branch Offices: Our Journey and Lessons Learned
Share:
