Cloud Readiness and WAN Architecture Strategies

December 2017 · Reading time: 10 mins

Introduction

The cloud adoption wave of the late 2010s forced many enterprises to re-evaluate their network architecture, particularly the WAN. Traditional hub-and-spoke topologies struggled to support increasing demands for cloud applications. In this post, we explore WAN architecture strategies that aligned with cloud readiness initiatives during 2017 and beyond.

Legacy WAN Limitations in a Cloud-First World

Many enterprises in 2017 still relied heavily on MPLS backhauling all internet-bound traffic through central data centers. While this provided control and inspection, it introduced latency for cloud services like Office 365, Salesforce, and AWS-hosted apps. Users in branch offices experienced degraded performance, and IT teams wrestled with increasing complexity and cost.

Cloud-Native Traffic Patterns

Cloud services altered traffic patterns fundamentally. Instead of 80% of traffic flowing east-west inside the enterprise, now a significant portion was destined to public internet services. This shift demanded network designs that embraced local internet breakout, distributed security, and flexible transport options.

SD-WAN as a Catalyst

SD-WAN emerged as a powerful enabler of cloud-ready WAN transformation. It decoupled the control plane from hardware and allowed enterprises to leverage multiple underlay transport types: MPLS, broadband, LTE. Key features included:

• Application-aware routing
• Dynamic path selection
• Centralized orchestration
• Policy-based traffic engineering

Vendors like VeloCloud (VMware), Cisco (Viptela, Meraki), and Silver Peak offered solutions that aligned well with hybrid and multi-cloud needs.

Direct-to-Cloud Access Models

Instead of sending all SaaS traffic through HQ firewalls, organizations began deploying secure local internet breakout strategies. DNS-based filtering, cloud-hosted SWGs (e.g., Zscaler), and CASBs provided distributed policy enforcement. This reduced latency, improved user experience, and unburdened core WAN links.

Branch Architecture Adjustments

The branch evolved into a leaner, more agile node. With SD-WAN, firewalls, WAN optimization, and routing functions converged into a single platform. Zero-touch provisioning became a standard deployment requirement. In 2017, this concept—often referred to as the “thin branch”—gained traction across retail, finance, and education verticals.

Cloud Interconnect and WAN Gateways

Organizations with significant IaaS investments explored direct interconnects to public clouds via ExpressRoute (Azure), AWS Direct Connect, or Google Cloud Interconnect. These connections bypassed the internet entirely, offering SLA-backed performance, reduced jitter, and higher security posture.

Security Integration with WAN Strategy

By 2017, security teams worked closely with networking teams to integrate next-gen firewalling, IDS/IPS, and policy enforcement into WAN design. Concepts like SASE (Secure Access Service Edge) were emerging, promising tighter integration between networking and security via cloud-based delivery.

Vendor Landscape and Market Consolidation

The SD-WAN market in 2017 was rapidly consolidating. Cisco’s acquisition of Viptela, VMware’s of VeloCloud, and HPE’s purchase of Silver Peak (later) signaled strong enterprise demand. Selecting the right vendor became a matter of aligning architectural fit, manageability, cost, and security integration.

Best Practices for Cloud-Ready WAN Design

• Start with application traffic analysis to understand flows and priorities.
• Pilot SD-WAN in non-critical sites before full rollout.
• Ensure security controls align with distributed breakouts.
• Plan for cloud on-ramps near major SaaS/IaaS regions.
• Monitor post-deployment performance and user experience actively.

Conclusion

In 2017, the journey toward cloud readiness was no longer optional. WAN architectures had to evolve to support distributed applications, agile provisioning, and enhanced user experience. SD-WAN, direct-to-cloud access, and integrated security stood out as key elements in that transformation.

Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 22 years of experience in IT and consulting, he helps organizations maintain stable and secure environments through proactive auditing, optimization, and strategic guidance.
LinkedIn Profile

Designing Highly Available Enterprise WANs with BGP and IP SLA Tracking

August 2013 • 7 min read

In the world of enterprise networking, reliability is paramount. With business operations depending heavily on internet and inter-office connectivity, designing a resilient WAN has become a top priority. In 2013, many enterprises are looking toward a combination of Border Gateway Protocol (BGP) and Cisco IP SLA to build highly available WAN architectures without depending solely on expensive proprietary failover solutions.

Why WAN Redundancy Matters

As more applications move to the cloud and users become distributed, even brief outages in WAN connectivity can have a cascading impact on productivity. Many businesses operate with multiple service providers to mitigate the risk of an ISP failure, but redundant circuits alone do not guarantee intelligent failover. That’s where dynamic routing and health monitoring come in.

Enter BGP: The Internet's Default Routing Language

BGP remains the protocol of choice for multihomed enterprise networks connecting to two or more ISPs. It allows policy-based routing and gives administrators control over which paths are preferred, advertised, or suppressed.

A typical dual-homed WAN deployment involves connecting the enterprise edge router to two ISPs. Each ISP provides a /30 WAN IP block and possibly a public IP range for NAT. Using BGP, each link can independently announce the enterprise network while using attributes like Local Preference and AS Path to influence incoming and outgoing traffic.

Where IP SLA Comes In

Despite BGP’s flexibility, it has one drawback: it does not inherently test for path availability. If the physical link is up but the path to the Internet is degraded (e.g., due to a remote ISP issue), BGP may continue routing traffic into a black hole.

To fill this gap, Cisco’s IP SLA can monitor key destinations (e.g., public DNS servers, business-critical apps) and use track objects to influence route decisions. When an IP SLA test fails, it can withdraw a static route or trigger a change in BGP behavior.

Example: Dual WAN with BGP and IP SLA Tracking

Here’s a basic configuration to demonstrate the concept:

interface GigabitEthernet0/0
 description Link to ISP1
 ip address 203.0.113.2 255.255.255.252

interface GigabitEthernet0/1
 description Link to ISP2
 ip address 198.51.100.2 255.255.255.252

ip sla 1
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 frequency 5

ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability

ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
ip route 0.0.0.0 0.0.0.0 198.51.100.1 200
  

This configuration prefers ISP1, monitored using IP SLA. If the tracked destination (8.8.8.8) becomes unreachable, the route via ISP1 is withdrawn and the static route to ISP2 takes over due to the higher administrative distance.

Advanced Failover with BGP and Route Maps

In more advanced scenarios, BGP can also react dynamically to changes in IP SLA state. For example, you can use route-maps with 'set local-preference' or 'set metric' based on tracking objects to influence BGP path selection automatically.

Some enterprises also integrate object tracking with HSRP or GLBP to maintain high availability at Layer 3 gateways, especially when there are multiple routers sharing the WAN edge role.

Common Pitfalls and Design Tips

• Ensure IP SLA monitors an external host, not just the next hop.
• Be mindful of asymmetrical routing and return traffic flows.
• Document all BGP peerings, route policies, and failover logic clearly.
• Log tracking events to syslog or SNMP for monitoring.

Ultimately, combining BGP’s powerful policy control with IP SLA’s real-time path awareness results in a robust, cost-effective, and scalable WAN failover architecture.

Conclusion

In 2013, enterprise IT teams are expected to deliver maximum uptime on constrained budgets. By leveraging open standards like BGP along with smart telemetry from IP SLA, network engineers can design WANs that don’t just survive ISP failures—they adapt to them.

Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 18 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Connect on Linkedin

Designing Enterprise WAN Architectures with BGP and Path Control

March 2013 | Reading time: 8 minutes

Understanding the Role of BGP in Enterprise WANs

Border Gateway Protocol (BGP) has long been the cornerstone of internet routing, but in recent years it has gained popularity within enterprise WAN environments as organizations aim to enhance resilience, control, and performance. For large enterprises with multiple sites, leveraging BGP allows granular control of traffic paths, prioritization policies, and redundancy models that exceed the capabilities of simpler protocols like OSPF or static routing.

In a traditional enterprise, multiple MPLS circuits or hybrid MPLS-Internet designs require precise outbound and inbound route engineering. BGP's policy-based model is uniquely suited for this, enabling enterprises to influence route selection through attributes such as Local Preference, MED, and AS Path prepending.

Route Maps and Policy-Based Routing

When designing a WAN using BGP, control is paramount. Route maps become one of the most powerful tools available for matching prefixes, applying actions, and filtering routes based on custom logic. For example, an enterprise might define a route map that sets a higher Local Preference for traffic destined to critical SaaS providers, ensuring those flows prefer the MPLS path while general internet access uses broadband backup links.

Policy-Based Routing (PBR) adds another layer of decision-making by enabling forwarding decisions based on source/destination, application type, or even time-of-day. While BGP controls path advertisement and selection, PBR defines how specific traffic types are forwarded regardless of the routing table—ideal for exception-based scenarios like VoIP or backup replication traffic.

Key Design Considerations

• Redundancy: Ensure dual-homing to multiple ISPs or MPLS providers, with health-checked failover mechanisms using BFD or IP SLA.
• Prefix Aggregation: Use summarization to reduce the routing table size and improve convergence times.
• Loop Prevention: In iBGP scenarios, implement full mesh or route reflectors to maintain consistency.
• AS Path Manipulation: Use AS Path prepending to influence upstream route preferences during failover.
• Routing Security: Filter inbound routes using prefix-lists and implement MD5 authentication for BGP peers.

Sample BGP Configuration Snippet

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.0.2.1 remote-as 65010
 neighbor 192.0.2.1 description MPLS-ISP
 neighbor 192.0.2.1 password secureBGP

 address-family ipv4
  network 10.10.0.0 mask 255.255.0.0
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map PREFER_MPLS out
 exit-address-family

route-map PREFER_MPLS permit 10
 match ip address prefix-list CRITICAL_ROUTES
 set local-preference 200

Conclusion

Designing enterprise WANs with BGP opens the door to powerful traffic control and failover capabilities. However, success lies in a balanced application of policy, redundancy, and best practices. BGP is not a plug-and-play protocol—without proper route filtering and visibility, route leaks or instability may arise. A carefully structured BGP design that includes route maps, prefix lists, and path manipulation techniques ensures predictable behavior and operational clarity.

Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 18 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Connect on Linkedin