Tagged: Cloud
10 posts · browse all tags
-
SDWSCS Part 13: Monitoring with vManage & vAnalytics
The SDWSCS finale — module 13: operating everything the series deployed. vManage's security and Cloud OnRamp dashboards, the UTD and tunnel health signals worth alerting on, vAnalytics/Cisco SDWAN Analytics for trends and forecasting, and a day-2 runbook.
-
SDWSCS Part 12: Cloud Interconnect & OnRamp for Colocation
Modules 11–12 of SDWSCS: software-defined cloud interconnect with Megaport and Equinix — virtual routers and private cross-connects provisioned from vManage — and Cloud OnRamp for Colocation: CSP clusters, NFVIS, and vManage-orchestrated VNF service chains.
-
SDWSCS Part 11: Cloud OnRamp Multicloud — AWS, Azure & GCP
Module 10 of SDWSCS: extending the fabric into public cloud with Cloud OnRamp for Multicloud — cloud gateways built from Catalyst 8000Vs, AWS Transit Gateway and Cloud WAN, Azure vWAN, GCP NCC, and the tag-based intent mapping that connects VPCs to service VPNs.
-
SDWSCS Part 10: Cloud OnRamp for SaaS
Module 9 of SDWSCS: Cloud OnRamp for SaaS in deployment detail — vQoE probing and scoring, DIA vs gateway vs client access exits, the Microsoft 365 telemetry integration, Webex/Office/custom app lists, and verifying the path decisions it makes.
-
Lab Environments Part 6: Cloud-Hosted Labs, and Picking One
Closing the overview: renting the compute layer instead of owning it, a comparison across all five categories, and a plain decision framework. Proxmox is next, with the deep dives to follow.
-
Juniper Session Smart SD-WAN Deep Dive Part 6: Cloud Onramp and Multicloud
Extending Secure Vector Routing into AWS and Azure: virtual SSR instances, cloud regions treated as ordinary sites in the tenant/service model, and how that compares to the tunnel-based cloud onramp patterns already covered on this site.
-
Palo Alto Prisma SDWAN Deep Dive Part 6: Cloud Onramp and Multicloud
Prisma SDWAN treats a VPC or VNet as just another data centre: a pair of virtual IONs joins the fabric, and a CloudBlade automates the cloud-native plumbing around them — Transit VNETs and vWAN Hub association on Azure, Transit Gateway attachment on AWS. How that compares to Cisco's and Fortinet's cloud onramp designs already on this site.
-
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.
-
Fortinet SDWAN 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.