Q: Redesign the datacenter for <100us east-west latency with no Layer 2 loops and no FHRP protocols.

I redesign using a **Clos topology (leaf-spine)** with **eBGP as the routing protocol** and **VXLAN-EVPN as the overlay**. In a Clos fabric, every leaf connects to every spine in a full mesh. There are no Layer 2 loops because there is no Layer 2 switching — everything is routed at Layer 3. East-west traffic between servers in different racks takes exactly 3 hops: source leaf → spine → destination leaf. With 10/25/100Gbps links and cut-through switching, latency is <100us per hop, totaling <300us end-to-end. I eliminate HSRP/VRRP by using **anycast gateway** — every leaf switch advertises the same virtual gateway IP (/32) via BGP, so the default gateway is always one hop away. The overlay uses **VXLAN with EVPN control plane**: leaf switches learn MAC addresses locally and advertise them via BGP EVPN Type-2 routes. For BUM traffic (broadcast, unknown unicast, multicast), I use **ingress replication** or **EVPN core multicast** (PIM-SSM) instead of flooding. For the underlay, I use **unnumbered BGP** (RFC 5549) so I do not need to allocate /31s to every leaf-spine link — this scales to thousands of links without IP exhaustion. I verify with `show bgp l2vpn evpn summary` and `show vxlan vni`. For the interview, I also mention **BGP maximum-paths ebgp 64** so leaf switches use ECMP across all spines for perfect load balancing.

Q: What three architectural changes scale the RR beyond 2M routes without simply upgrading hardware?

First, **split the RR function by address family**. Instead of one RR handling IPv4, VPNv4, and EVPN, I deploy dedicated RRs: one cluster for VPNv4, one for EVPN, and one for IPv4 unicast. This partitions the load and allows each RR to optimize its RIB for one AF. Second, **deploy RR federation or hierarchical RRs**. I create regional RR clusters (e.g., Americas, EMEA, APAC) with **inter-cluster BGP sessions**. Each PE peers only with its regional RR, reducing the number of peers per RR from 500 to ~170. The regional RRs peer with each other to exchange best paths. Third, **enable BGP ORR (Optimal Route Reflection)**. Traditional RRs advertise their own best path, which may not be optimal for all PEs. ORR allows the RR to compute and advertise the best path **from each PE's perspective**, eliminating suboptimal routing without increasing scale. For software optimization, I enable **BGP labeled unicast (LU)** with **segment routing** so the RR only reflects prefixes and labels, not full VPNv4 paths, reducing memory by ~40%. I also implement **BGP prefix limit filters** so the RR rejects routes with /32 masks from PEs unless they are loopbacks. I verify with `show bgp all summary` and `show processes cpu`. For the ultimate scale, I mention moving to **BGP on the host (BGP unnumbered)** with **SRv6** so the RR function is distributed and no single node carries all routes.

Q: What is the migration path to post-quantum cryptography in the network layer, and what Cisco or IETF standards apply?

The migration path is **hybrid post-quantum key exchange** combined with traditional encryption. The IETF is standardizing this in **draft-ietf-ipsecme-ikev2-quantum-resistant** and **RFC 8784 (Mixing PSK into IKEv2)**. Cisco implements this via **Suite-B / CNSA (Commercial National Security Algorithm)** transitions and support for ** CRYSTALS-Kyber** key encapsulation in IKEv2. The practical approach is a phased migration: Phase 1: Enable **hybrid key exchange** in IKEv2 where both classical ECDH and post-quantum Kyber are used simultaneously. If one is broken, the other protects the session. Phase 2: Upgrade IPsec transforms to **AES-256-GCM-16** with **SHA-384** (CNSA 2.0) as an interim step. Phase 3: Deploy **quantum key distribution (QKD)** for the most critical links, though this requires dedicated fiber and is not yet practical for WAN. For the network layer specifically, I implement **MACsec with post-quantum algorithms** on campus links and **DMVPN/GETVPN with quantum-resistant IKEv2** for WAN. I also mention that Cisco is working on **SRv6 with HMAC-SHA256 integrity checks** as a control-plane protection mechanism. For the interview, I emphasize that quantum computers capable of breaking RSA/ECC do not yet exist at scale, but **harvest now, decrypt later** threats mandate immediate migration to hybrid schemes.

Q: What OSPF design flaw causes frequent SPF, and how do you re-architect to stabilize the backbone?

The flaw is likely **too many routers in Area 0** or **excessive LSA type 5 (external) flooding**. OSPF requires every area to connect to Area 0, and all ABRs flood summary LSAs (Type 3) into Area 0. With 1,000 routers, even a small link flap triggers a full SPF run across all routers. The re-architecture is to create **hierarchical areas** and move routers out of Area 0. I design **stub areas** for remote sites (no external LSAs), **totally stubby areas** for simple branches (only default route), and **NSSA** for areas that need limited external redistribution. I also deploy **OSPF fast convergence features**: **Incremental SPF (iSPF)** which only recalculates the affected part of the SPT, and **partial route calculation (PRC)** for external LSAs. For the backbone specifically, I limit Area 0 to **core routers only** (backbone P routers and ABRs) — all other routers go into non-backbone areas. I also use **OSPF prefix suppression** on point-to-point links so /30 and /31 transit networks are not advertised as Type 1 LSAs, reducing LSA database size by ~30%. If the network is large enough (> 500 routers), I consider migrating the IGP to **IS-IS** which scales better due to its two-level hierarchy and support for **multi-topology** and **segment routing**.

Question 1

Design the routing architecture, including IGP, BGP policies, and path enforcement mechanisms.

Accepted Answer

I design a **multi-plane MPLS backbone** with **Segment Routing (SR-MPLS or SRv6)** as the forwarding plane and **IS-IS as the IGP** with **multi-topology extensions** for administrative separation. Each continent runs its own IS-IS level with a dedicated **transport plane** (Plane A for unrestricted traffic, Plane B for GDPR-compliant traffic). BGP LU (Labeled Unicast) or BGP-LU carries loopback labels across ASBRs. For path enforcement, I use **SR explicit paths** with **affinity constraints** (colors). Links traversing restricted countries are tagged with color `RED` and excluded from GDPR paths using `segment-routing traffic-eng policy` with `exclude affinity RED`. For sub-50ms failover, I deploy **TI-LFA (Topology-Independent Loop-Free Alternate)** on every node, providing guaranteed sub-50ms protection for any single link or node failure without waiting for BGP convergence. BGP itself uses **BGP-PIC (Prefix Independent Convergence)** edge and core for multi-homed prefixes. For intercontinental paths, I use **BGP LU with ADD-PATH** so each node has multiple backup paths pre-computed. The control plane runs **BGP RR clusters** per continent with **ORR (Optimal Route Reflection)** to prevent suboptimal hot-potato routing. I also implement **BFD with 3x3 ms timers** on all critical links.

Question 2

Replace STP with a modern loop-free campus architecture. What protocol do you use, and how does it eliminate both loops and root bridge flapping?

Accepted Answer

I replace STP with **Cisco SD-Access (DNA Center)** using **LISP for control plane** and **VXLAN for data plane** with **IS-IS underlay**. In SD-Access, there is no STP at all. The fabric uses **anycast gateway** on every edge node, and traffic is routed from the first hop — no Layer 2 domains large enough to cause broadcast storms. Loop prevention is inherent because VXLAN encapsulates all traffic with a VNI, and the fabric control plane (LISP MS/MR) ensures that only valid endpoint-to-endpoint tunnels are established. For root bridge flapping specifically, SD-Access eliminates the concept because there is no spanning tree — every edge node is a Layer 3 router running IS-IS. The anycast gateway (using **Distributed Anycast Gateway** or **Virtual Network** in DNA Center) provides the same default gateway IP on every edge, so endpoints never need to ARP across the fabric. For multicast, SD-Access uses **underlay multicast (PIM-SSM)** or **ingress replication** instead of flood-and-learn. I verify with `show fabric summary` and `show lisp session`. For non-Cisco environments, I mention **EVPN-VXLAN** on Arista/Cumulus/Juniper as the equivalent architecture — EVPN provides the BGP-based control plane for MAC/IP advertisement, and VXLAN provides the encapsulation, eliminating STP entirely.

Question 3

What MPLS Traffic Engineering solution guarantees bandwidth for premium customers while maximizing utilization of non-premium traffic on the same link?

Accepted Answer

I implement **MPLS-TE with DiffServ-Aware TE (DS-TE)**. DS-TE allows me to create multiple **class types (CT)** — CT0 for best-effort, CT1 for premium, CT2 for platinum — each with its own bandwidth pool on every link. I configure **RSVP-TE** tunnels with bandwidth reservations per class type. For premium customers, I establish explicit-path TE tunnels that reserve CT1 bandwidth end-to-end. The IGP (IS-IS) advertises available bandwidth per CT using **extended IS-TE sub-TLVs**. For non-premium traffic, I use **Class-Based Tunnel Selection (CBTS)** so that best-effort traffic uses the default IGP path or a separate TE tunnel with no bandwidth guarantee. To maximize utilization, I enable **Auto-Bandwidth** on TE tunnels, which periodically adjusts the reserved bandwidth based on actual traffic volume. For the congested link specifically, I also implement **MPLS-TE FRR (Fast Reroute)** with **one-to-one backup (Detour)** or **facility backup** so that if the link fails, premium traffic is rerouted to a pre-signaled backup path in under 50ms. I verify with `show mpls traffic-eng tunnels` and `show ip rsvp reservation`. For even finer granularity, I mention **Segment Routing Traffic Engineering (SR-TE)** with **per-flow stateless traffic engineering** as the modern replacement for RSVP-TE, using SR policies with bandwidth constraints.

Question 4

What migration architecture allows SD-WAN overlay on existing MPLS underlay, and how do you handle routing between migrated and non-migrated sites during the transition?

Accepted Answer

The architecture is **SD-WAN over MPLS using a dual-transport design**. At each site, I deploy a Cisco SD-WAN vEdge or cEdge with two WAN transports: **TLOC color MPLS** (existing CE router connection) and **TLOC color INET** (local broadband). The vEdge forms OMP sessions to vSmart over both transports. Initially, all traffic uses the MPLS transport with the existing BGP/OSPF routing. As sites migrate, I shift application policies to prefer INET for trusted traffic while keeping MPLS for latency-sensitive traffic. For routing between migrated and non-migrated sites, I use **SD-WAN TLOC extension into the MPLS VPN**. The vEdge at migrated sites redistributes OMP routes into the existing MPLS PE-CE BGP session, and conversely redistributes MPLS BGP routes into OMP. This allows a migrated site (SD-WAN) to reach a non-migrated site (legacy MPLS CE) seamlessly because the vEdge acts as a **routing gateway** between the two worlds. For zero-touch deployment, I use **PnP (Plug-and-Play)** or **ZTP** where the vEdge ships pre-configured with the organization name and vbond address. It auto-provisions over the internet or MPLS and downloads its config from vManage. I verify with `show omp tlocs` and `show ip bgp vpnv4 all`. For the interview, the key phrase is: "I run both networks in parallel with controlled traffic shifting via application-aware policies, not a flash cut."

Question 5

Redesign the datacenter for <100us east-west latency with no Layer 2 loops and no FHRP protocols.

Accepted Answer

I redesign using a **Clos topology (leaf-spine)** with **eBGP as the routing protocol** and **VXLAN-EVPN as the overlay**. In a Clos fabric, every leaf connects to every spine in a full mesh. There are no Layer 2 loops because there is no Layer 2 switching — everything is routed at Layer 3. East-west traffic between servers in different racks takes exactly 3 hops: source leaf → spine → destination leaf. With 10/25/100Gbps links and cut-through switching, latency is <100us per hop, totaling <300us end-to-end. I eliminate HSRP/VRRP by using **anycast gateway** — every leaf switch advertises the same virtual gateway IP (/32) via BGP, so the default gateway is always one hop away. The overlay uses **VXLAN with EVPN control plane**: leaf switches learn MAC addresses locally and advertise them via BGP EVPN Type-2 routes. For BUM traffic (broadcast, unknown unicast, multicast), I use **ingress replication** or **EVPN core multicast** (PIM-SSM) instead of flooding. For the underlay, I use **unnumbered BGP** (RFC 5549) so I do not need to allocate /31s to every leaf-spine link — this scales to thousands of links without IP exhaustion. I verify with `show bgp l2vpn evpn summary` and `show vxlan vni`. For the interview, I also mention **BGP maximum-paths ebgp 64** so leaf switches use ECMP across all spines for perfect load balancing.

Question 6

What three architectural changes scale the RR beyond 2M routes without simply upgrading hardware?

Accepted Answer

First, **split the RR function by address family**. Instead of one RR handling IPv4, VPNv4, and EVPN, I deploy dedicated RRs: one cluster for VPNv4, one for EVPN, and one for IPv4 unicast. This partitions the load and allows each RR to optimize its RIB for one AF. Second, **deploy RR federation or hierarchical RRs**. I create regional RR clusters (e.g., Americas, EMEA, APAC) with **inter-cluster BGP sessions**. Each PE peers only with its regional RR, reducing the number of peers per RR from 500 to ~170. The regional RRs peer with each other to exchange best paths. Third, **enable BGP ORR (Optimal Route Reflection)**. Traditional RRs advertise their own best path, which may not be optimal for all PEs. ORR allows the RR to compute and advertise the best path **from each PE's perspective**, eliminating suboptimal routing without increasing scale. For software optimization, I enable **BGP labeled unicast (LU)** with **segment routing** so the RR only reflects prefixes and labels, not full VPNv4 paths, reducing memory by ~40%. I also implement **BGP prefix limit filters** so the RR rejects routes with /32 masks from PEs unless they are loopbacks. I verify with `show bgp all summary` and `show processes cpu`. For the ultimate scale, I mention moving to **BGP on the host (BGP unnumbered)** with **SRv6** so the RR function is distributed and no single node carries all routes.

Question 7

What is the migration path to post-quantum cryptography in the network layer, and what Cisco or IETF standards apply?

Accepted Answer

The migration path is **hybrid post-quantum key exchange** combined with traditional encryption. The IETF is standardizing this in **draft-ietf-ipsecme-ikev2-quantum-resistant** and **RFC 8784 (Mixing PSK into IKEv2)**. Cisco implements this via **Suite-B / CNSA (Commercial National Security Algorithm)** transitions and support for ** CRYSTALS-Kyber** key encapsulation in IKEv2. The practical approach is a phased migration: Phase 1: Enable **hybrid key exchange** in IKEv2 where both classical ECDH and post-quantum Kyber are used simultaneously. If one is broken, the other protects the session. Phase 2: Upgrade IPsec transforms to **AES-256-GCM-16** with **SHA-384** (CNSA 2.0) as an interim step. Phase 3: Deploy **quantum key distribution (QKD)** for the most critical links, though this requires dedicated fiber and is not yet practical for WAN. For the network layer specifically, I implement **MACsec with post-quantum algorithms** on campus links and **DMVPN/GETVPN with quantum-resistant IKEv2** for WAN. I also mention that Cisco is working on **SRv6 with HMAC-SHA256 integrity checks** as a control-plane protection mechanism. For the interview, I emphasize that quantum computers capable of breaking RSA/ECC do not yet exist at scale, but **harvest now, decrypt later** threats mandate immediate migration to hybrid schemes.

Question 8

What OSPF design flaw causes frequent SPF, and how do you re-architect to stabilize the backbone?

Accepted Answer

The flaw is likely **too many routers in Area 0** or **excessive LSA type 5 (external) flooding**. OSPF requires every area to connect to Area 0, and all ABRs flood summary LSAs (Type 3) into Area 0. With 1,000 routers, even a small link flap triggers a full SPF run across all routers. The re-architecture is to create **hierarchical areas** and move routers out of Area 0. I design **stub areas** for remote sites (no external LSAs), **totally stubby areas** for simple branches (only default route), and **NSSA** for areas that need limited external redistribution. I also deploy **OSPF fast convergence features**: **Incremental SPF (iSPF)** which only recalculates the affected part of the SPT, and **partial route calculation (PRC)** for external LSAs. For the backbone specifically, I limit Area 0 to **core routers only** (backbone P routers and ABRs) — all other routers go into non-backbone areas. I also use **OSPF prefix suppression** on point-to-point links so /30 and /31 transit networks are not advertised as Type 1 LSAs, reducing LSA database size by ~30%. If the network is large enough (> 500 routers), I consider migrating the IGP to **IS-IS** which scales better due to its two-level hierarchy and support for **multi-topology** and **segment routing**.

Question 9

What addressing architecture reduces waste while maintaining manageability, and how does DHCP fit in?

Accepted Answer

The architecture is **hierarchical DHCP with shared subnets and dynamic prefix allocation**. Instead of static /28s, I use **DHCPv6 PD (Prefix Delegation)** or **DHCPv4 shared networks** where each store receives a /29 (6 usable) or even a /30 for very small sites, with the ability to request a larger prefix via DHCP. For stores with only 2-3 IoT devices, a /30 eliminates waste. For stores that grow, the DHCP server assigns a /27 on renewal. The central IPAM (NetBox/Infoblox) tracks actual utilization and reclaims unused prefixes after a lease expires. I also implement **RFC 1918 summarization** at the regional aggregation layer so the core routing table only sees /20 or /18 summaries per region, not 1,000 /28s. For the interview, I mention **IPv6 as the preferred IoT addressing scheme** because IPv6 /64 per subnet is standard and SLAAC ( Stateless Address Auto Configuration) eliminates DHCP server load. With IPv6, each store gets a /56 from the regional /48, providing 256 subnets per store with zero waste. If IPv4 is mandatory, I use **CGNAT (Carrier-Grade NAT)** at the regional hub so stores can use overlapping RFC 1918 space, drastically reducing the need for globally unique IPv4.

Question 10

Under what three conditions does EVPN-VXLAN win, and when is MPLS L3VPN still the better choice?

Accepted Answer

EVPN-VXLAN wins when: (1) **Multi-tenancy with overlapping MAC addresses** is required — EVPN carries MAC addresses in the control plane (BGP Type-2), preventing duplicate MAC conflicts that MPLS L3VPN cannot handle because it only routes IP. (2) **Layer 2 extension across datacenters** is needed — EVPN natively supports stretched VLANs (MAC-VRF) with split-horizon and aliasing, while MPLS L3VPN requires VPLS or pseudowires for L2, which are obsolete. (3) **Modern automation and programmability** — EVPN uses standard YANG models and is supported by Ansible/Terraform/NetBox natively. MPLS L3VPN wins when: (1) **Established WAN with legacy PE routers** — if the SP already has thousands of MPLS-enabled PEs, migrating to VXLAN is prohibitively expensive. (2) **Traffic engineering with RSVP-TE** is required for strict SLA guarantees — EVPN over IP underlay lacks mature TE compared to MPLS-TE. (3) **Inter-provider option B/C peering** — MPLS has well-established inter-AS options (A, B, C) for multi-provider VPNs, while EVPN inter-provider is still evolving. For a greenfield DC, I recommend EVPN-VXLAN. For WAN expansion, I keep MPLS L3VPN and use **BGP-LU (Labeled Unicast)** as the migration bridge.

Question 11

What three control-plane protection mechanisms prevent this, and how do you apply them without breaking legitimate ARP?

Accepted Answer

First, **Control Plane Policing (CoPP)**. I configure a CoPP policy that limits ARP packets to 10,000 pps to the control plane, dropping excess ARP while preserving routing protocol traffic. On Cisco IOS-XR, this is `control-plane management-plane inband` with `police` under `class arp`. Second, **Dynamic ARP Inspection (DAI)** on switches. DAI validates ARP packets against the DHCP snooping binding table, dropping invalid ARP responses before they reach the router. This offloads ARP validation from the router to the switch. Third, **ARP rate limiting per interface** — `ip arp inspection limit rate 15` on access ports prevents a single compromised host from flooding ARP. For legitimate ARP, I ensure **DHCP snooping** is enabled so DAI has a valid binding table to check against. I also configure **static ARP entries** for critical infrastructure (default gateways, servers) so they are not subject to dynamic limits. On the router itself, I enable **ARP caching** with long timeouts for known hosts and **proxy ARP disabled** to prevent the router from responding on behalf of subnets it does not own. For very large subnets, I use **private VLANs (PVLAN)** to isolate hosts so they do not need to ARP each other — they only ARP the gateway.

Question 12

What switching technology achieves sub-10us latency, and what trade-offs does it introduce?

Accepted Answer

The technology is **cut-through switching** with **FPGA-based network adapters** and **kernel bypass** (DPDK, RDMA/RoCE). Standard store-and-forward switches add 2–5us of latency. Cut-through switches begin forwarding after reading only the destination MAC (first 14 bytes), reducing latency to <1us. For the absolute lowest latency, I use **Arista 7130 or Cisco Nexus 3548** switches which support cut-through and even **FPGA-based programmable pipelines** for custom forwarding logic. On the host side, I use **DPDK (Data Plane Development Kit)** to bypass the Linux kernel networking stack entirely — packets go directly from the NIC to the application in user space, eliminating context switches and IRQ overhead. For even lower latency, **RDMA over Converged Ethernet (RoCEv2)** allows one server to read/write another server's memory directly without CPU involvement, achieving <2us end-to-end. The trade-offs are: (1) **No deep packet inspection** — cut-through cannot inspect the full packet for security. (2) **Fragmentation intolerance** — cut-through requires fixed-size frames or jumbo frames; fragmented packets cause issues. (3) **Cost** — FPGA switches and RDMA NICs (Mellanox ConnectX-6) are 5–10x more expensive than standard gear. (4) **Complexity** — DPDK and RDMA require specialized application development. For the interview, I mention that most "low-latency" financial networks actually use **cut-through + jumbo frames + tuned bufferbloat settings** rather than full DPDK, because the application stack is the real bottleneck below 10us.

Question 13

What technology provides this, and how do you prevent Layer 2 loops across the provider backbone?

Accepted Answer

The technology is **EVPN Ethernet Segment (ES) with All-Active multi-homing** or **PBB-EVPN** for traditional deployments. EVPN provides a BGP-based control plane for MAC learning across the provider backbone, replacing the flood-and-learn behavior of VPLS. For VLAN preservation, EVPN uses ** VLAN-aware bundling** where multiple customer VLANs are mapped to a single EVI (EVPN Instance) or separate EVIs per VLAN. To prevent loops, EVPN uses **Designated Forwarder (DF) election** per Ethernet Segment. In a multi-homed site with two PEs, only the DF forwards BUM traffic; the non-DF blocks it. For split-horizon, EVPN uses **ESI (Ethernet Segment Identifier) labels** — when a PE receives a BUM frame from the customer, it adds an ESI label before sending to other PEs. If a receiving PE sees its own ESI label, it knows the frame came from the same ES and drops it, preventing loops. For the interview, I also mention **BGP EVPN route types**: Type 1 (Auto-Discovery) for ES membership, Type 2 (MAC/IP advertisement), Type 3 (Inclusive Multicast Ethernet Tag for BUM), and Type 4 (Segment ES route for DF election). I verify with `show evpn es` and `show evpn df-election`. If the customer needs pure transparency without MAC learning in the provider network, I use **VPWS (Virtual Private Wire Service)** with EVPN signaling, which is a point-to-point Layer 2 pseudowire.

Question 14

What three automation/AI technologies achieve this, and what is the human role after implementation?

Accepted Answer

First, **Intent-Based Networking (IBN)** with Cisco DNA Center or Juniper Mist. The network is defined by business intent ("all IoT devices must be isolated") and the controller automatically provisions VLANs, ACLs, and SGTs. DNA Center's **AI Endpoint Analytics** automatically classifies 95% of devices without manual MAC OUIs. Second, **AIOps with predictive analytics** — tools like Cisco ThousandEyes, Aruba NetInsight, or Moogsoft analyze telemetry patterns to predict failures before they happen. For example, if a switch fan shows increasing RPM over 2 weeks, the system predicts failure in 5 days and schedules replacement. Third, **closed-loop remediation** — Ansible/Terraform playbooks triggered by SNMP traps or streaming telemetry events. If BGP flaps 3 times in 10 minutes, the playbook automatically collects `show tech-support`, opens a ticket, and applies a pre-approved mitigation (e.g., dampening). After implementation, the human role shifts from **reactive troubleshooting to intent definition and exception handling**. Engineers write the automation playbooks, validate AI predictions, and handle edge cases that automation cannot resolve (e.g., multi-vendor interoperability bugs). The NOC becomes a **Network Reliability Engineering (NRE)** team focused on improving the automation rather than executing repetitive tasks.

Question 15

What architectural principles apply, and what Earth technologies are completely unsuitable?

Accepted Answer

This is a thought experiment testing **first principles thinking**. The 4–20 minute RTT makes any Earth protocol requiring real-time acknowledgments unusable. TCP is unsuitable because its congestion control and retransmission timers assume sub-second RTTs — on Mars, TCP would timeout constantly. I replace TCP with **DTN (Delay/Disruption Tolerant Networking)** using the **Bundle Protocol (RFC 5050)**, which stores and forwards data at intermediate nodes and handles multi-minute delays. For routing, BGP is unsuitable because it assumes relatively stable, low-latency peering. I use **scheduled contact graph routing** where paths are computed based on orbital mechanics — when Mars and Earth are aligned, direct communication; otherwise, relay via satellites or the Moon. For the colony itself, I deploy a **fully autonomous network** with local DNS, DHCP, and authentication — no dependency on Earth services. The colony runs **Kubernetes clusters** with **etcd quorum** on Mars only, and **asynchronous Git replication** to Earth for code updates. Security uses **post-quantum cryptography** because classical key exchange over 20-minute delays is impractical. For the interview, the key is not the specific technology but demonstrating that you can **decompose constraints** (latency, autonomy, intermittency) and select protocols designed for those constraints. I also mention that SpaceX and NASA are already testing DTN on the ISS.