Tagged: sdwan
45 posts · browse all tags
-
ENSDWI Part 5: Certificates, Device Lists, and Control-Plane Troubleshooting
Blueprint 2.3 and 2.4: the certificate trust model end to end — root CA options, controller CSRs, the WAN Edge authorized serial list — then the systematic control-connection troubleshooting flow behind most ENSDWI exhibit questions.
-
ENSDWI Part 4: Controller Deployment — Cloud, On-Prem, Scale, and Redundancy
Blueprint 2.1 and 2.2: Cisco-hosted vs on-premises controllers, hosting platform requirements, installing the vManage/vBond/vSmart trio, and the scalability and redundancy rules — clustering, affinity, and how many of each you actually need.
-
ENSDWI Part 3: Edge Platforms and Cloud OnRamp
Finishing blueprint domain 1.0: the cEdge and vEdge platform families and how to pick between them, then all four Cloud OnRamp variants — SaaS, IaaS, Colocation, and Multicloud/Interconnect — at the depth the exam actually tests.
-
ENSDWI Part 2: Architecture — Planes, Components, and Multi-Region Fabric
Blueprint domain 1.1: the four planes and their components, OMP's three route types, TLOCs, IPsec vs GRE encapsulation, BFD's dual role, and Multi-Region Fabric — the v1.2 addition that older study material misses entirely.
-
ENSDWI Part 1: Exam Syllabus & Study Roadmap
Kicking off a twelve-part study series for the Cisco 300-415 ENSDWI exam. Part 1 breaks down the v1.2 blueprint domain by domain, maps every topic to a part of this series, and covers exam logistics, lab options, and how to study for a 90-minute concentration exam.
-
Cisco Catalyst SD-WAN Deep Dive Part 1: Components, Controllers, and the Four Planes
Starting a ten-part deep dive into Cisco Catalyst SD-WAN. Part 1 covers the Viptela lineage, the four controller planes (vManage, vSmart, vBond, WAN Edge), the certificate trust model, and the control-connection bring-up sequence.
-
Cisco Catalyst SD-WAN Deep Dive Part 10: Failure Modes, Scale Limits, and a Vendor Comparison
Part 10, the finale: what actually breaks (vBond, vSmart, vManage) and what doesn't when it does, vManage's documented scale ceiling, and a head-to-head of OMP/TLOC against Fortinet ADVPN, Arista DMPO, and VeloCloud.
-
Cisco Catalyst SD-WAN Deep Dive Part 2: OMP, the Overlay Management Protocol
Part 2 of the Cisco Catalyst SD-WAN series: what OMP actually carries between WAN Edge and vSmart — OMP routes, TLOC routes, and service routes — how best-path selection and multipath differ from BGP, and why the overlay/underlay split is the whole point.
-
Cisco Catalyst SD-WAN Deep Dive Part 3: TLOCs, Color, and Centralized Policy
Part 3 of the Cisco Catalyst SD-WAN series: what TLOC color actually constrains, how restrict/no-restrict shapes which tunnels can form, and how centralized control policy on vSmart turns that into enforced topology — full mesh, hub-and-spoke, or anything between.
-
Cisco Catalyst SD-WAN Deep Dive Part 4: BFD, App-Route SLAs, and cEdge Forwarding
Part 4: how BFD over every data tunnel drives both fast failure detection and continuous SLA measurement, how app-route policy steers on that data, and where cEdge's IOS-XE forwarding pipeline diverges from legacy vEdge.
-
Cisco Catalyst SD-WAN Deep Dive Part 5: Topology Walkthroughs — Dual Transport, DIA, and TLOC Extension
Part 5: VPN segmentation (transport vs. service VPNs), a worked dual-MPLS-plus-Internet branch design, direct internet access for local breakout, and TLOC extension for sites with no WAN circuit of their own.
-
Cisco Catalyst SD-WAN Deep Dive Part 6: Cloud OnRamp for SaaS and IaaS
Part 6: how Cloud OnRamp for SaaS continuously measures per-app, per-transport path quality to pick the best local breakout, and how Cloud OnRamp for IaaS extends the fabric directly into AWS and Azure as cloud-resident sites.
-
Cisco Catalyst SD-WAN Deep Dive Part 7: SIG, Secure Firewall, and Edge Security
Part 7: how DIA traffic gets inspected without a hub backhaul — Cisco Secure Internet Gateway integration, the on-box UTD container on cEdge, and how this converges with the broader SASE shift other vendors are making too.
-
Cisco Catalyst SD-WAN Deep Dive Part 8: Automation — vManage API, Terraform, and Ansible
Part 8: why vManage's API-first design means automating Catalyst SD-WAN looks nothing like CLI-scraping individual boxes, and where Terraform's declarative model and Ansible's procedural model each fit.
-
Cisco Catalyst SD-WAN Deep Dive Part 9: The MPLS-to-SD-WAN Cutover Playbook
Part 9: a phased, coexistence-based migration sequence from legacy MPLS to Catalyst SD-WAN — pilot sites first, hubs last, explicit rollback triggers, and why ripping MPLS out in one weekend is the wrong instinct.
-
SD-WAN Control Plane Showdown: Three Philosophies for Solving the Same Problem
Fortinet collapses control onto the data-plane device. Arista/VeloCloud collocates it on a multi-tenant Gateway. Cisco/Viptela decouples it fully into vSmart and OMP. Three architectures covered on this site, lined up side by side, right before the Cisco series picks up the third one.
-
A Brief History of SD-WAN Controllers: Viptela, VeloCloud, CloudGenix, and Why Cisco Runs Two SD-WAN Stacks
Three startups solved SD-WAN's control-plane problem within a year of each other. Two got bought by exactly the company you'd expect; one brand didn't survive. The acquisition history of Viptela, VeloCloud, and CloudGenix — and why Cisco still runs two unrelated SD-WAN stacks today.
-
The Three Planes: Management, Control, and Data — and Why Every SD-WAN Argument Comes Back to Them
A vendor-neutral primer on the management, control, and data planes — what each actually does, why management-vs-control is the distinction everyone blurs, and a three-question test you can run against any SD-WAN platform regardless of vendor.
-
IPsec Deep Dive Part 1: ESP, AH, and How IKE Phase 1 Actually Brings a Tunnel Up
IPsec underpins every Fortinet SD-WAN overlay this blog has built, and it's never had its own deep dive. Part 1 fixes that: the SA model, ESP vs AH, tunnel vs transport, and a message-by-message walk through IKEv1 main mode, aggressive mode, and IKEv2.
-
IPsec Deep Dive Part 2: Phase 2, Child SAs, and the Anatomy of an ESP Packet
Phase 1 built a control channel and protected nothing. Part 2 covers the negotiation that actually moves data: quick mode and child SAs, traffic selectors, PFS, rekeying, and anti-replay — then dissects an ESP packet field by field, down to the MTU math.
-
IPsec Deep Dive Part 3: NAT vs IPsec — NAT-T, Port Forwarding, and the Fortinet SD-WAN Reality
NAT breaks IPsec three distinct ways — AH's ICV, ESP's missing ports, and IKE's rewritten source port. Part 3 covers each break, how NAT-D detects it and NAT-T's UDP 4500 encapsulation repairs it, when port forwarding is still required, and what it all means for SD-WAN spokes behind CPE NAT.
-
Beyond PSK: PKI for Fortinet SD-WAN IPsec, Part 1 — The Architecture Decision
FortiManager-as-CA vs. a dedicated external CA for certificate-based IPsec on Fortinet SD-WAN: the honest trade-offs, SCEP vs EST, CRL vs OCSP, certificate lifetime philosophy, and why "who is your CA" is the real question hiding inside "switch to certificates."
-
Beyond PSK: PKI for Fortinet SD-WAN IPsec, Part 2 — Standing Up the PKI
Standing up a real PKI for Fortinet SD-WAN IPsec: offline root, online issuing CA, a certificate role scoped to IPsec end entities, an EST front-end, CRL/OCSP placed where the chicken-and-egg overlay problem can't reach it, and FortiManager's much smaller supporting role.
-
Beyond PSK: PKI for Fortinet SD-WAN IPsec, Part 3 — Enrollment, Automation, and the Cutover
Closing the series: solving EST's bootstrap-credential problem on purpose, monitoring certificate renewal at scale before it becomes an outage, and executing the PSK-to-certificate cutover — explicitly diffed against the FMG-as-CA migration path.
-
Cloud On-Ramp Part 1: The Architecture Decision and AWS Transit Gateway
Hub Placement Part 3 said the hub goes where the VPC is. This post answers the question that raises immediately: how does it actually get there? BGP-over-IPsec to AWS Transit Gateway, ASN selection, and mapping on-prem VRFs onto TGW route tables.
-
Cloud On-Ramp Part 2: Azure Virtual WAN and a Dual-Cloud Resilience Design
Azure Virtual WAN looks like AWS Transit Gateway from a distance — a managed hub that attachments plug into. Up close, the BGP mechanics, the route-propagation model, and the failure modes all differ in ways that decide whether a dual-cloud on-ramp actually survives a bad day.
-
Local Internet Breakout in Practice: SD-WAN Zones, Rules, and a Multi-VRF Guest Wi-Fi Walkthrough
How SD-WAN zones, members, and performance-SLA rules actually decide where a session breaks out — and a full walkthrough of giving Guest Wi-Fi its own VRF, its own zone, and a local internet path that never touches the corporate tunnel.
-
Fortinet SD-WAN Hub Placement Part 1: The Traditional Model — Hubs in the DC
Why hubs traditionally sit in the DC, the job they actually do there, how they protect FMG/FAZ, and how BGP on loopback ties it together. Part 1 of a series that goes on to challenge the assumption that the hub belongs in the DC at all.
-
Fortinet SD-WAN Hub Placement Part 2: The MSSP Shift — When the Hub Becomes Customer-Centric
What changes when one FMG/FAZ pair manages many customers through ADOMs: the hub stops being "the DC's hub" and becomes a per-customer design decision, with its own routing domain, AS plan, and placement logic.
-
Fortinet SD-WAN Hub Placement Part 3: Cloud, SASE, and the Death of "The DC" as the Default
Closing out the hub-placement series: what changes about hub design when the destination is Azure, AWS, or GCP rather than a DC, and what changes again for customers migrating from a DC-centric WAN to a SASE-centric one.
-
Fortinet SD-WAN Jinja Orchestrator — Part 1: The Two Template Engines
Part 1 of three. FortiManager hosts two distinct template engines — classic CLI templates and Jinja CLI templates — and they aren't interchangeable. Thesis: Jinja for shape-varying network plumbing, CLI templates for shape-fixed system config, and a real deployment uses both.
-
Fortinet SD-WAN Jinja Orchestrator — Part 2: Anatomy and Patterns
Part 2 of three. We open Fortinet's sdwan-advpn-reference repo and read it end-to-end: the dynamic-bgp-on-lo directory, the four reference Project Templates, the inventory contract that feeds them, and the three Jinja patterns the templates lean on heaviest — loops, ipaddr derivation, and imports.
-
Fortinet SD-WAN Jinja Orchestrator — Part 3: PSK to Cert With FMG as CA
Part 3 of three. We take the single-hub PSK example from the reference repo and migrate it to certificate-based IPSec, with FortiManager as the CA. FMG CA setup, per-device enrolment, Project Template flag flip, what changes in the rendered config and what doesn't.
-
Arista (VMware) SD-WAN Deep Dive — Part 1: Components, Gateways, and the Three Planes
First post in a five-part deep dive on Arista (VMware) SD-WAN. We start with the components — Edges, Cloud Gateways, Partner Gateways, Orchestrator, Controller — and the three planes that bind them. Sets up a UK ISP scenario that the rest of the series will pick apart.
-
Arista (VMware) SD-WAN Deep Dive — Part 2: Routing — Overlay, Underlay, BGP, and the Gateway as Route Reflector
Part 2 of five. How prefixes get into the overlay, how the Gateway redistributes them, the three Cloud VPN modes, BGP at the Edge and the Partner Gateway, and the route-selection logic that decides which underlay a flow ends up on.
-
Arista (VMware) SD-WAN Deep Dive — Part 3: The Data Plane — VCMP, DMPO, and Per-Flow Steering
Part 3 of five. Wire-level look at VCMP encapsulation, the DMPO measurement loop, Business Policy and per-flow steering, and the on-path remediation (FEC, duplication, jitter buffer) that lets the overlay tolerate underlays that misbehave.
-
Arista (VMware) SD-WAN Deep Dive — Part 4: Topology Walkthroughs — MPLS-only meets Internet-only Across Continents
Part 4 of five. The GlobalCo packet-flow walkthroughs — Newcastle to HQ, Bristol to HQ, Chicago to a UK Cloud Gateway (why it fails), and the headline: MPLS-only Chicago talking to Internet-only Shanghai via a Partner Gateway, hop by hop.
-
Arista (VMware) SD-WAN Deep Dive — Part 5: Best Practice, Failure Modes, and a Design Checklist
Part 5 of five. Gateway design rules, Partner Gateway sizing, segmentation, security service insertion, MTU, the failure modes that catch teams the first time, and a one-page design checklist for an Arista (VMware) SD-WAN rollout.
-
SDWAN Resilience Part 1: Design and Assumptions
A multi-part deep dive into building a resilient Fortinet SD-WAN on a real, slightly unfashionable topology — HA FortiManager, dual hubs in active/standby, no DCI, and an independent DCE. Part 1 lays out the topology, the AS plan, and challenges the design choices up front.
-
SDWAN Resilience Part 2: BGP on Loopback
Why we peer BGP on loopbacks instead of tunnel-interface IPs, the FortiOS dynamic-IPsec config that makes it work, the spoke-side reciprocal config, and why hub-to-hub iBGP is the wrong answer in a no-DCI active/standby topology.
-
SDWAN Resilience Part 3: DC to DCE Routing — Static, OSPF, and BGP
The hub FortiGate has to glue the spoke overlay to the data-centre environment that hosts the services. Static, OSPF, and eBGP each work — but only two of them fail correctly when the DCE peering goes down on one DC and not the other.
-
SDWAN Resilience Part 4: BFD and Convergence Tuning
Default BGP timers detect failure in three minutes. That's unacceptable for active/standby SD-WAN. This post is the timer-math: DPD vs BFD on tunnels, BFD-for-BGP, holdtime ratios, the Graceful Restart trade-off, and what convergence numbers each combination actually delivers.
-
SDWAN Resilience Part 5: Performance SLAs and Service Steering
BGP and BFD catch every failure that takes a tunnel or session with it. They don't catch the failure where everything looks healthy at the network layer but the application is gone. That's the gap SD-WAN Performance SLAs fill — and the place where careful health-check design earns its keep.
-
SDWAN Resilience Part 6: Building It Right — Full DCI and Dual-Active ADVPN
The first five parts defended a topology with real constraints. This final post is the version without those constraints — Fortinet's reference design: full DCI, dual-active ADVPN, iBGP between hubs, symmetric routing, ECMP across both paths. The full shebang.
-
Route Leaking Between VRFs on FortiGate: Why It's Trickier Than You Think
VRF route leaking is a daily reality in any multi-tenant or shared-services network design. On FortiGate it's harder to find — and harder to get right — than the equivalent on Cisco or Juniper. Here's how to do it, why it's easy to miss, and the practical pitfalls.