Cisco Routing¶
Scope¶
This file covers Cisco routing architecture including ISR (Integrated Services Router) 1000/4000 series for branch routing, ASR (Aggregation Services Router) 1000 series for WAN edge aggregation, Catalyst 8000 series (8200/8300/8500) as the next-generation edge platform, SD-WAN architecture (formerly Viptela, now Catalyst SD-WAN) with vManage/vSmart/vBond controllers and cEdge/vEdge routers, OSPF design (single-area vs multi-area, stub areas, NSSA), BGP design (eBGP for internet/WAN peering, iBGP for internal route distribution, route reflectors, community-based policy), EIGRP for legacy campus/branch routing, DMVPN and FlexVPN for WAN overlay tunnels, and MPLS/VRF for multi-tenant routing.
Checklist¶
- [Critical] Is the WAN architecture defined -- traditional MPLS with hub-and-spoke or full-mesh, IPSec VPN overlay (DMVPN/FlexVPN), or Cisco SD-WAN (Catalyst SD-WAN) -- with clear justification for the choice based on site count, bandwidth requirements, application SLA needs, and operational maturity?
- [Critical] For SD-WAN deployments, is the controller architecture designed -- vManage (management plane, minimum 3 nodes for HA in production), vSmart (control plane, minimum 2 for redundancy, each supports up to 5400 connections), vBond (orchestration, minimum 2) -- with controllers hosted on-premises, in Cisco cloud, or hybrid, and is the overlay/underlay network separation clearly documented?
- [Critical] Is the BGP design documented -- AS number allocation (private AS 64512-65534 for internal, or 4-byte ASN), iBGP mesh or route reflector topology, eBGP peering for internet and WAN circuits, route filtering with prefix lists and route maps, and community tagging for policy enforcement?
- [Critical] Is the OSPF area design defined -- backbone area 0 with proper ABR placement, stub/totally-stubby/NSSA areas for branch sites to limit LSA flooding, router-ID assignment, reference bandwidth adjustment (auto-cost reference-bandwidth matched to fastest link), and authentication (MD5 or keychain) on all OSPF adjacencies?
- [Critical] For SD-WAN, are application-aware routing policies configured -- defining SLA classes (latency, jitter, loss thresholds) per application, mapping applications to preferred/backup transport (MPLS, internet, LTE), and enabling BFD (Bidirectional Forwarding Detection) probes on all tunnels for real-time path quality measurement?
- [Recommended] Is the router platform lifecycle assessed -- ISR 4000 and ASR 1000 are in various stages of end-of-sale/end-of-life, with Catalyst 8000 series as the replacement platform; confirm hardware support timelines and plan migration for platforms approaching EoL?
- [Recommended] For SD-WAN, is the transport design planned -- number and type of WAN links per site (MPLS, DIA, broadband, LTE/5G), tunnel configuration (full-mesh vs hub-and-spoke vs regional hub), and TLOC (Transport Locator) extension for sites sharing a transport across multiple routers?
- [Recommended] Is route summarization configured at area boundaries (OSPF ABR) and at redistribution points to minimize routing table size and LSA/update propagation, with specific attention to preventing suboptimal routing caused by aggressive summarization?
- [Recommended] Is mutual redistribution between routing protocols (e.g., OSPF-BGP, EIGRP-OSPF) designed with route maps, tags, and administrative distance tuning to prevent routing loops and suboptimal paths, with redistribution points documented and limited to two for redundancy?
- [Recommended] For SD-WAN, is the migration strategy defined -- parallel overlay (run SD-WAN alongside existing WAN), phased site migration (hub sites first, then branches in waves), or big-bang cutover -- with rollback procedures for each phase and validation criteria before proceeding?
- [Recommended] Is the internet edge design defined -- dual ISP with BGP (AS-path prepending or MED for primary/backup), default route injection into IGP, DNS-based failover for sites without BGP, and DDoS mitigation strategy (upstream provider scrubbing, on-premises appliance, or cloud-based)?
- [Optional] Is Cisco Performance Routing (PfR) or SD-WAN application-aware routing used to dynamically select WAN paths based on real-time performance metrics rather than static routing metrics?
- [Optional] Are VRF-Lite or MPLS L3VPN configured for multi-tenant or segmented routing on shared infrastructure, with route distinguisher and route target design documented, and inter-VRF route leaking configured only where explicitly required?
- [Optional] Is IPv6 routing designed alongside IPv4 -- dual-stack, NAT64/DNS64, or IPv6 overlay -- with OSPFv3 or BGP address families for IPv6 route distribution?
Why This Matters¶
Routing architecture determines how traffic flows between sites, to the internet, and to cloud services -- a poorly designed routing topology creates suboptimal paths, single points of failure, and convergence delays that directly impact application performance. Cisco SD-WAN (Catalyst SD-WAN) has become the dominant enterprise WAN technology, but it introduces a controller dependency that fundamentally changes WAN operations: vSmart controller failure prevents new tunnel establishment and policy changes, vManage outages prevent monitoring and configuration, and the overlay/underlay separation means troubleshooting requires understanding both layers simultaneously. OSPF and BGP design errors are among the most common causes of network instability -- misconfigured area boundaries cause full LSA flooding across the backbone, missing route summarization bloats routing tables and slows convergence, and redistribution loops between protocols can cause network-wide outages that are extremely difficult to diagnose under pressure. The transition from ISR/ASR to Catalyst 8000 series changes licensing (DNA subscription required), management (Catalyst Center integration), and feature availability, making platform selection a critical long-term decision.
Common Decisions (ADR Triggers)¶
- SD-WAN vs traditional WAN (DMVPN/MPLS) -- SD-WAN provides application-aware routing, centralized policy, transport independence, and simplified branch deployment but requires controller infrastructure and ongoing subscription licensing. Traditional DMVPN/MPLS is well-understood, has no controller dependency, and uses perpetual licensing but lacks application-level SLA enforcement and centralized management. Choose SD-WAN for 20+ sites with mixed transports and application SLA requirements; traditional for small deployments or where controller dependency is unacceptable.
- Cisco SD-WAN cloud-hosted vs on-premises controllers -- Cloud-hosted controllers (Cisco-managed) reduce operational overhead and provide global PoP access but introduce internet dependency for management plane and may not meet data sovereignty requirements. On-premises controllers provide full control and no internet dependency but require infrastructure, patching, and capacity planning. Choose cloud for standard deployments without strict data residency; on-premises for government, regulated industries, or air-gapped networks.
- OSPF vs BGP for internal routing -- OSPF converges faster for small to medium networks, is simpler to configure, and is the standard campus/branch IGP, but struggles to scale beyond 500-1000 routers without careful area design. BGP scales to thousands of routers, provides rich policy control, and is required for internet peering, but has slower convergence (tunable with BFD) and higher configuration complexity. Choose OSPF for campus/branch IGP; BGP for WAN/internet edge and large-scale or multi-tenant networks.
- EIGRP vs OSPF -- EIGRP is Cisco-proprietary (with an IETF informational RFC), converges faster than OSPF for topology changes, uses less CPU for large networks, and supports unequal-cost load balancing, but limits vendor diversity. OSPF is standards-based, supported by all vendors, and understood by more engineers. Choose OSPF for multi-vendor or greenfield environments; tolerate EIGRP in existing Cisco-only networks where migration cost outweighs benefit.
- Single transport vs multi-transport WAN -- Single transport (MPLS-only or internet-only) is simpler but provides no failover and ties performance to one provider. Multi-transport (MPLS + internet, or dual internet + LTE) with SD-WAN or DMVPN provides resilience and cost optimization but adds complexity. Choose multi-transport for any site where availability matters; single transport only for low-priority or temporary sites.
- Catalyst 8000 vs ISR 4000/ASR 1000 -- Catalyst 8000 is the strategic platform with DNA licensing, Catalyst Center integration, and the latest IOS-XE features. ISR 4000 and ASR 1000 continue to receive security patches but no new features and are approaching end-of-life. Choose Catalyst 8000 for new deployments; ISR/ASR only for short-term replacements where existing spares are available.
Reference Links¶
- Cisco SD-WAN (Catalyst SD-WAN) documentation -- SD-WAN controller deployment, policy configuration, and cEdge/vEdge setup
- Cisco Catalyst 8000 series -- Catalyst 8200/8300/8500 platform overview and migration from ISR/ASR
- Cisco OSPF design guide -- OSPF area design, route summarization, and stub area configuration
- Cisco BGP best practices -- BGP configuration, route filtering, community design, and route reflectors
- SD-WAN design guide -- Cisco Validated Design for SD-WAN controller placement, transport design, and migration
- DMVPN design guide -- DMVPN Phase 2/3 design and FlexVPN migration
See Also¶
general/networking.md-- general networking architecture patternsproviders/cisco/switching.md-- Cisco switching platforms and campus/DC fabricproviders/cisco/meraki.md-- Cisco Meraki SD-WAN (cloud-managed alternative)general/wan-design.md-- general WAN architecture patterns