400-007 — Frequently Asked Questions

OSPF is often preferred over EIGRP in large enterprise designs because it is an open standard (vendor-agnostic), supports hierarchical multi-area design that limits SPF computation scope, and scales better in environments with 1000+ nodes. Key design considerations include: (1) placing the backbone (Area 0) strategically to minimize transit areas, (2) summarizing at ABRs to reduce routing table size, (3) using stub/NSSA areas to limit LSA flooding into access layers, (4) ensuring no more than 50 routers per area to control SPF convergence time, and (5) avoiding virtual links as they create fragile dependencies. The common debate online centers on whether OSPF's strict hierarchical requirements are worth the complexity versus EIGRP's simpler flat design with automatic summarization.

To handle overlapping address spaces in MPLS L3VPN: (1) Assign unique Route Distinguishers (RD) to each VRF on every PE router—RDs make overlapping prefixes unique in the global BGP table by prepending the RD to create VPNv4 routes (e.g., 65001:100:10.0.0.0/24). (2) Use Route Targets (RT) for import/export policies—export RTs are attached to routes when injected into the VPN, and import RTs on receiving PEs determine which VPN routes are accepted into a VRF. (3) For shared services (e.g., common DNS or AD servers), create separate RT values to selectively share specific prefixes between VPNs without full overlap. The online debate often focuses on whether to use ASN:nn or IP:nn format for RD/RT values and the operational implications of each in multi-AS environments.

For multi-building campus multicast design: (1) PIM Sparse Mode (PIM-SM) is the default recommendation—it requires a Rendezvous Point (RP) and builds source-specific trees only when receivers join, conserving bandwidth. Use Anycast RP or Auto-RP/BSR for RP redundancy. (2) PIM Bi-Directional (BiDir) is preferred for many-to-many applications (e.g., video conferencing) because it builds shared trees without requiring source registration, reducing RP load. (3) PIM Dense Mode should be avoided in large designs due to its flood-and-prune behavior consuming bandwidth. Key design principles include: placing RPs centrally, ensuring RP failover within 5 seconds, using IGMP snooping at L2 to prevent multicast flooding, and separating multicast traffic classes for QoS. The debate centers on whether BiDir-PIM truly eliminates RP bottlenecks in environments with 50+ multicast groups.

QoS design for converged networks should follow: (1) Classification and marking at the trust boundary (typically access switch ports), marking voice with EF (DSCP 46), interactive video with AF41, streaming video with AF31, and best-effort data with DSCP 0. (2) At L2 (switch-to-switch), use 802.1p CoS bits in the VLAN tag for queuing; at L3 (routers), use DSCP in the IP header. The mapping between CoS and DSCP must be consistent (e.g., CoS 5 = DSCP EF). (3) Apply strict priority queuing for voice, weighted fair queuing for video, and WFQ/CBWFQ for data. The popular debate is whether to trust DSCP from endpoints (risky due to user manipulation) versus re-marking at every hop, and whether 5-class or 8-class QoS models are appropriate for modern networks carrying WebRTC and Teams/Zoom traffic alongside traditional voice.

A spine-leaf (Clos) architecture is strongly preferred for low-latency financial services because: (1) It provides uniform latency—every server-to-server path traverses exactly one spine hop (2 hops total), unlike 3-tier where paths vary. (2) It eliminates STP by using ECMP (Equal-Cost Multi-Path) with all links active, providing predictable bandwidth. (3) It scales linearly by adding spine switches. (4) It supports VXLAN/EVPN overlays for multi-tenancy without traditional VLAN limitations. The 3-tier design (access-aggregation-core) introduces variable latency and relies on STP which blocks redundant links. The online debate focuses on whether the operational complexity of BGP-based spine-leaf (vs. traditional spanning tree) justifies the benefits for networks with fewer than 200 servers, and whether hardware-based VXLAN offload is necessary for sub-microsecond requirements.

Critical BGP multi-homing design considerations: (1) Use BGP AS numbers carefully—use a private ASN (64512-65534) if you don't need global advertisement, or a public ASN if announcing your own prefixes. (2) Prevent transit by: advertising only your own prefixes to ISPs (strict prefix filters), not advertising ISP-learned routes to other ISPs, and using 'maximum-prefix' limits on BGP sessions. (3) Inbound traffic engineering: use AS-Path prepending to make one ISP less preferred, or use BGP communities to signal preferences. (4) Outbound: use LOCAL_PREF to prefer one exit path, and use BGP communities or MED for granular control. (5) Ensure BGP graceful restart and fast external failover (BFD with 50ms timers). The most debated topic online is whether full Internet table (900K+ routes) is needed on CE routers versus default/partial routes, and the memory/CPU implications for router selection.

The recommended segmentation strategy follows: (1) Macro-segmentation using VRFs or separate routing instances for major trust zones (corporate, guest, IoT, DMZ, data center). (2) Micro-segmentation within zones using ACLs, 802.1X port-based authentication, and software-defined approaches (Cisco TrustSec/SXP or VXLAN with group-based policies). (3) East-west traffic inspection between segments using firewalls or IDS/IPS at strategic choke points. (4) Zero-trust principles for critical assets—never trust based solely on network location. The balance debate centers on: too many VLANs/VRFs create operational overhead (management, troubleshooting), while too few reduce security. Best practice is to segment by business function and risk level rather than per-department. The community frequently debates whether traditional ACL-based segmentation can be replaced entirely by identity-based micro-segmentation without introducing vendor lock-in.

IPv6 greenfield design principles: (1) Use a structured /48 per site, /64 per subnet allocation from a /32 or /36 global block. (2) Deploy OSPFv3 or IS-IS (protocol-agnostic, cleaner than OSPFv2) for IGP, and MP-BGP for inter-site. (3) Enable SLAAC for endpoint addressing with DHCPv6 for DNS options, or use DHCPv6-only for stricter control. (4) Design for IPv6-first with IPv4 as fallback where needed. Key debates: (a) Dual-stack doubles operational burden (two routing tables, two ACL sets, two monitoring planes) but provides compatibility; (b) IPv6-only with NAT64/DNS64 eliminates IPv4 but breaks legacy applications; (c) Most enterprises still choose dual-stack for 3-5 more years despite the overhead. The discussion also covers whether to enable IPv6 RAs on all access ports or restrict them to prevent rogue RA attacks.

Design trade-offs: (1) SD-WAN advantages: application-aware routing (steers traffic based on application type and link quality), centralized policy management, support for any transport (MPLS, Internet, LTE/5G), built-in encryption, and faster provisioning. (2) Traditional MPLS+DMVPN advantages: proven stability, predictable SLAs from MPLS provider, simpler troubleshooting for experienced teams, no dependency on controller availability. (3) Cost: SD-WAN reduces MPLS bandwidth needs (offloading to broadband), but adds controller infrastructure and licensing costs. (4) For 500+ branches: SD-WAN scales better due to centralized orchestration; DMVPN hub-and-spoke creates hub bottleneck unless multi-hub with complex routing. The hot debate is whether SD-WAN controller failure creates a single point of failure that traditional designs don't have, and whether application-aware routing truly delivers measurable QoE improvements over static policy-based routing.

Traditional approach: Deploy HSRP (Cisco) or VRRP (standards-based) on paired core switches with preemption and tracking. Modern alternatives: (1) MLAG/vPC (Multi-chassis LAG): both core switches appear as a single LAG peer to downstream devices, eliminating HSRP entirely—both switches actively forward, and the gateway IP is anycast on both. (2) Anycast Gateway with VXLAN/EVPN: the same gateway IP/MAC exists on multiple leaf switches, providing local breakout without hairpinning. Design considerations: convergence time (HSRP: 3-10s vs. MLAG: <1s), failure domains (MLAG peer-link failure causes split-brain), and operational complexity. The current debate focuses on whether vPC/MLAG's split-brain scenarios are adequately handled by modern implementations, and whether anycast gateway in fabric designs truly eliminates all FHRP issues or introduces new challenges with ARP suppression and BUM traffic handling.