Apple Staff Network Engineer Interview Preparation Guide

Direct answer

Building a multi-team, multi-month roadmap starts with an honest dependency map, not a calendar of dates: find the true critical path across teams, gate each phase on real completion criteria, resource it with a contingency buffer sized to how many cross-team handoffs exist, run a governance cadence that tracks gate health rather than raw activity, and treat re-planning as a pre-defined process that recalculates the whole downstream cascade, not just the one milestone that slipped.

Structured elaboration

1. Map dependencies before sequencing anything. List every workstream and what it genuinely blocks or is blocked by, then identify the critical path: the longest chain of true dependencies. That chain, not the sum of everyone's individual estimates, sets the floor on the roadmap's total duration.
2. Sequence and gate by dependency, not by calendar convenience. Break the roadmap into phases gated by explicit exit criteria, what "done enough to unblock the next phase" actually means, so the plan can be checked against reality at each gate instead of only at the very end.
3. Allocate and track resourcing with a real contingency buffer. Assign FTE time per team per phase against the sequenced plan, and reserve a contingency buffer sized to the number of cross-team handoffs involved, since risk compounds every time work passes from one team to the next, not a flat percentage regardless of structure.
4. Run a governance cadence distinct from each team's own rhythm. A regular cross-team steering review that tracks gate status and leading risk indicators gives executives one roll-up view instead of forcing them to reconcile separate team updates themselves.
5. Define the re-plan trigger in advance. Decide up front what counts as a genuine critical dependency slip, for example a gate missed by more than a stated threshold, so re-planning is a predictable process rather than an ad hoc scramble. When triggered, recompute the full downstream cascade and communicate the true end-to-end impact, not just the one gate that moved.

Worked example

A 12-month, three-team program: Platform, App, and Data, with a strict chain, Platform gates App, App gates Data. Platform's API work runs months 1 to 4, but its contract (the API's interface definition, meaning which fields exist and in what format) is frozen at month 2, letting App start against the frozen contract at month 2 while Platform finishes implementation in parallel; App runs a 5-month build with an integration checkpoint at month 4, once Platform's real API ships, and finishes at month 7. Data's pipeline depends on App's UI emitting stable events, which happens roughly a month before App's own finish, so Data starts at month 6 and needs 4 months, finishing at month 10. A 2-month hardening (stabilizing the fully integrated system under real load and fixing edge cases before go-live) and launch-readiness phase for the fully integrated system follows, bringing the whole program to a 12-month finish, matching the original commitment.

Resourcing: Platform runs 4 people through its months 1 to 4, retaining 1 for integration support afterward. App runs 3 people through months 2 to 7, retaining 1 for support. Data runs 2 people through months 6 to 10, folding into the final hardening phase. Given three sequential cross-team handoffs, the contingency buffer is set at 15% of each team's allocated time, tracked but not spent unless a gate is actually at risk.

Governance: a monthly steering review across the three leads and the program owner tracks whether each gate landed on schedule, specifically whether Platform's contract froze on time at month 2 and whether App's event stream stabilized on time at month 6, with an executive quarterly readout summarizing gate health.

Re-plan trigger: any gate slipping more than three weeks against its planned month. Suppose at month 4, Platform's API isn't fully done and slips to month 5, a full month past the three-week threshold. Recomputing the cascade: App's integration checkpoint shifts from month 4 to month 5, pushing App's finish from month 7 to month 8; Data's start shifts from month 6 to month 7 and its finish from month 10 to month 11; the hardening phase shifts to months 11 to 13. A single one-month slip at the very first gate cascades into a full one-month slip in the program's overall finish date, from month 12 to month 13, because the chain is strictly sequential with no independent slack anywhere to absorb it. That is exactly what gets communicated to stakeholders, the full cascading impact, not just "Platform is a bit late," along with the options: accept the new month-13 date, or compress a later phase, for example cutting non-critical scope from App, to try to recover some of the lost time.

Trade-offs and pitfalls

Building the roadmap as a flat calendar of dates without an explicit dependency graph means nobody notices the true critical path until it's already been blown. Sizing contingency as a flat percentage regardless of how many cross-team handoffs exist understates risk on programs with more handoffs, where risk genuinely compounds. Treating governance reviews as status theater disconnected from concrete gate-exit criteria turns them into meetings that generate discussion without resolving anything. And reacting to a slipped gate by only updating the one milestone that moved, instead of recomputing the full downstream cascade, understates the real impact to executives and erodes trust the next time a gate slips.

Direct answer

The underlay is the physical network that actually forwards packets: routers, switches, cables, and in the cloud, the virtual network fabric behind your VPC (Virtual Private Cloud) or VNet (Azure's Virtual Network). It only needs to route between physical endpoints using plain IP. The overlay is a virtual network built on top of that underlay by wrapping (encapsulating) real traffic inside another packet, so workloads get their own addressing and, in some designs, their own Layer 2 (Ethernet) domain, independent of how the underlay is actually wired. VXLAN (Virtual Extensible LAN), GRE (Generic Routing Encapsulation), and EVPN (Ethernet VPN, a BGP-based control plane usually paired with VXLAN) are the three ways to build that overlay. Use an overlay across cloud and on-prem when you need address space or Layer 2 adjacency that has to survive being physically relocated (workload migration, stretched clusters), or true multi-tenant isolation without burning a real VLAN or subnet per tenant. Skip it when plain Layer 3 routing between on-prem and cloud already satisfies the requirement: the overlay is complexity you should have to justify, not a default.

Underlay and overlay, side by side

VXLAN encapsulates the original Ethernet frame inside UDP/IP (RFC 7348: outer Ethernet, outer IP, outer UDP on destination port 4789, then an 8-byte VXLAN header). GRE just wraps IP-in-IP with a 4-byte minimum header (IP protocol 47) and, unlike VXLAN, was not designed with a multi-tenant segment ID in mind. NVGRE (Network Virtualization using Generic Routing Encapsulation, a Microsoft-originated variant standardized in RFC 7637) bolts one on: it reuses the GRE header's 32-bit key field to carry a 24-bit Virtual Subnet Identifier, giving GRE-based tunnels the same per-tenant segmentation VXLAN gets from its VNI, at a slightly smaller total encapsulation overhead than VXLAN. EVPN is not an encapsulation at all: it is a BGP address family (MP-BGP, Multiprotocol BGP) that VTEPs use to advertise which MAC or IP lives behind them, replacing flood-and-learn with a real control plane: faster convergence, ARP suppression, and predictable behavior when a VTEP restarts.

Worked example: why MTU breaks first

A standard Ethernet MTU (Maximum Transmission Unit, the biggest packet a link will carry) is 1500 bytes. VXLAN's encapsulation overhead is 50 bytes (14-byte outer Ethernet header, 20-byte outer IP header, 8-byte outer UDP header, 8-byte VXLAN header, per RFC 7348), so a 1500-byte tenant frame becomes a 1550-byte packet on the wire. If the underlay path between the on-prem site and the cloud is itself capped at 1500 bytes (true of most internet-routed and many VPN paths), that 1550-byte packet either fragments or, more commonly, gets silently dropped, because VXLAN packets are typically sent with the do-not-fragment bit set and a lot of networks filter the ICMP packet-too-big message that is supposed to trigger Path MTU Discovery. The practical fix is one of two things: raise the underlay MTU to at least 1550 (cloud providers that support jumbo frames on private/dedicated links, such as AWS Direct Connect or Azure ExpressRoute paths, comfortably clear this), or lower the tenant-facing MTU to 1450 and let path MTU discovery, or a manually clamped TCP MSS, keep packets under that ceiling end to end.

Trade-offs and pitfalls

The most common real-world failure looks like an application problem rather than a network problem: small packets (DNS lookups, TCP handshakes) work fine, large packets vanish, because they are the ones that exceed the encapsulated MTU and get silently dropped with no ICMP response to explain why. The second pitfall is assuming the overlay buys something the underlay could not: if the actual requirement is simply reaching a cloud workload from on-prem, a Layer 3 routed underlay with BGP is simpler, easier to troubleshoot, and has no MTU tax at all. Reach for VXLAN/EVPN specifically when preserving MAC or IP addresses across a move matters, or when a single physical fabric has to carry many mutually isolated tenants. Reach for plain GRE only for simple point-to-point IP-in-IP tunneling with no multi-tenant segmentation requirement, since GRE alone gives a tunnel, not a virtual network.

Direct answer

A good game day has a tightly bounded scope, a named set of stakeholders who signed off before the experiment starts, a real-time comparison of the system's behavior against its SLIs (service level indicators: the specific numbers you track, like latency and error rate, that tell you whether the system is healthy) during the run, and a retrospective that turns findings into tracked action items, not just a summary email. The hard part is not running the experiment; it's building the recurring program and organizational trust that lets you run harder ones over time.

Scoping the experiment

Pick a single, realistic failure mode against a bounded slice of traffic: a specific dependency (cache, database replica, a downstream API), a specific service, and ideally a canary or staging slice of load rather than 100% of production on the first run. Define upfront what "done" looks like: which SLIs you'll watch, what the abort condition is, and who has authority to hit the kill switch.

Who to involve

• Service owners and on-call engineers for the system under test, since they know the failure modes and own the runbook being validated.
• A designated incident commander for the exercise itself, separate from whoever is executing the fault injection, so there's a clear decision-maker if things go sideways.
• Product or support stakeholders when the blast radius could touch real users, so they understand what "the recommendations service is intentionally broken for 20 minutes" means for anyone who notices.
• Observability or SRE tooling owners to make sure dashboards and alerting are actually wired up to catch what you're about to do, not just to catch organic incidents.

Measuring impact against SLIs

Capture a baseline of your SLIs (latency percentiles, error rate, saturation) before injecting the fault, then watch the same SLIs in real time during the run and compare against the SLOs (service level objectives: the target values you've committed to for those same indicators, e.g. 99.9% success rate). The goal is not "did it break" (you know it will) but "did it break within the bounds you predicted, and did the defenses (timeouts, circuit breakers, autoscaling) behave the way the runbook assumes they do."

Turning findings into a recurring program

A single successful game day proves one thing worked once. Standing up a recurring practice requires a roadmap: start with low-risk, staging-only experiments to build muscle memory and trust, then progressively widen scope (larger blast radius, real production traffic, less-scripted scenarios) as the team demonstrates it can run these safely. Getting buy-in usually means showing leadership a concrete finding from an early, low-risk drill (a specific gap the exercise surfaced) rather than asking for blanket permission to break production up front. Once a cadence is established (for example, monthly), track a maturity metric across runs, such as the fraction of prior findings that were actually remediated before the next drill, so the program itself is accountable.

Worked example

Consider a payments API game day: inject 200ms of added latency into its database replica for a scoped window, on a canary slice of traffic, with a monthly error budget of 43.2 minutes at a 99.9% SLO:

During the drill, the induced latency causes synchronous retries to queue up, and the service is measurably degraded (error rate above SLO) for 12 minutes before the circuit breaker trips and the fallback path kicks in. That single test consumed:

That is a legitimate, alarming finding on its own: a single scoped drill burning over a quarter of the monthly error budget means either the blast radius needs to be tightened further (smaller canary percentage) or the circuit breaker's failure threshold needs to trip faster. Either way it's a concrete, numeric input for the retrospective and the case for continued investment in the program, rather than a vague "went well."

Trade-offs & pitfalls

Widening scope too fast is the single biggest risk to the program's survival: one game day that causes a real customer-visible incident before the team has built confidence can kill the practice for a year. The opposite failure is scoping every drill so conservatively that it never surfaces anything new, which also erodes stakeholder buy-in because the exercise starts to look like theater. The retrospective is where most of the value is either captured or lost; findings that don't get a tracked owner and a re-test in the next cycle tend to silently repeat.

First pin down what the 3-year requirement actually names. Compliance rules usually name audit evidence (who changed a device configuration, authentication logs, firewall deny logs, flow records for regulated segments) and rarely demand 30-second interface counters for three years. I would ask for the written control text (the exact wording of the compliance requirement) and design tiers around it; counters kept for capacity planning are a separate decision.

Sizing assumptions (stated so the numbers can be checked): 1,000 devices, 48 interfaces each, 8 metric series per interface = 384,000 series. A series is one metric on one interface over time (for example bytes out on port 12 of router A); a scrape is one collection of a device's current values by the monitoring server, here every 30 seconds, and one reading of one series is a sample. That is 12,800 samples per second. Prometheus documentation puts storage at roughly 1 to 2 bytes per sample, so I use 2 bytes as the upper end (ESTIMATE, not measured on this fleet).

Tier 1, hot (30 days): raw 30-second metrics, 7 days of raw flow records, full-text indexed logs. Metrics: 384,000 x 2,880 samples per day x 30 days x 2 bytes = about 66 GB. Prometheus local storage is not clustered or replicated, so send a copy with remote write (a Prometheus feature that forwards every sample to another store as it arrives) to a long-term store.

• Lost vs a longer raw window: nothing yet. This is the incident-response tier.

Tier 2, warm (13 months): 5-minute rollups of average and maximum. About 175 GB (384,000 x 2 aggregates x 288 per day x 395 days x 2 bytes). Flow data becomes hourly aggregates keyed by source prefix, destination prefix, protocol and destination port class.

• Lost: bursts shorter than 5 minutes between the maximum and the average, individual flows, exact 5-tuples (source IP, destination IP, ports, protocol), and anything below the flow sampling rate.

Tier 3, cold (3 years): 1-hour rollups of average, minimum and maximum. About 60 GB (384,000 x 3 x 24 x 1,095 x 2 bytes). Total of the three tiers is about 302 GB against about 2.4 TB if raw 30-second data were kept three years, roughly 12.5%. These sizes count only the two or three aggregates named per tier. Thanos downsampled blocks store more per point (its compactor documentation lists min, max, sum and count aggregates, plus one for counters) and the same documentation says downsampling does not reduce storage, so if Thanos is the store, treat 302 GB as the lower bound of this arithmetic (ESTIMATE) and size the real tiers from a measured block.

• Lost: anything shorter than an hour, so you can answer "was this link saturated in March two years ago" but not "was there a 90-second burst".

As one implementation of the long-term store, Thanos (an open-source system that keeps Prometheus data in object storage) has a compactor, a background job that merges stored blocks of data and builds downsampled copies. Downsampled blocks keep one summary point per 5 minutes or per hour instead of one per scrape. The compactor creates 5-minute downsampled blocks for data older than 40 hours and 1-hour blocks for data older than 10 days. Downsampling alone saves no space (it adds blocks); space is saved by per-resolution retention, for example --retention.resolution-raw=30d --retention.resolution-5m=400d --retention.resolution-1h=1100d: keep full-resolution samples 30 days, the 5-minute points 400 days and the 1-hour points 1,100 days. Retention for each resolution must exceed the age at which the next downsampling pass runs, or data is deleted before it can be downsampled; the values above satisfy that. The 1100 days is 3 years with margin for the leap day.

Device logs. Split by purpose. Security-relevant logs (authentication, configuration change, ACL deny) go to write-once object storage (storage that refuses edits and deletes until the retention period ends) for 3 years, compressed. As an illustration, 1,000 devices each sending 5 such lines a minute at 200 bytes is 1.44 GB a day raw, and about 158 GB over 1,095 days if compression is 10x (ESTIMATE). Keep only 30 days in the searchable index; older logs are retrieved from the archive on request. Debug and informational noise is deleted at 30 days if the control text does not name it.

• Lost: instant search past 30 days (a rehydration job, which restores archived logs into the searchable index, takes minutes to hours) and the noise tier entirely.

High cardinality. Cardinality is the number of distinct series. It explodes when a label has many possible values: adding a client-IP label to one metric on 48,000 interfaces, with 500 distinct clients seen on each, would create 48,000 x 500 = 24,000,000 series, 62.5 times the entire 384,000-series fleet, so labels like IP addresses or flow identifiers do not belong on metrics. Per-interface series are the largest legitimate set, so roll them up first; flow summaries and logs are bounded by the aggregation keys and severity filters you choose, not by device count. For illustration, if hourly flow summaries hold 50,000 rows of 50 bytes, that is 60 MB a day and about 66 GB over 1,095 days (ESTIMATE), so the flow tier mostly costs you detail (individual flows) rather than bytes.

Cold-tier trap. Rolled-up counters must be stored as rates or as average/min/max, never as raw counter values, or a counter reset (device reload) looks like negative traffic in the rollup.

Finally, test restores: pick a date in tier 3, rebuild a monthly utilisation graph, and confirm the result with the compliance owner before the first audit asks for it.

Direct answer
A duplicate ACK is the receiver re-acknowledging the same byte offset it already acknowledged, which happens when a later, out-of-order segment arrives before the one actually missing; three duplicate ACKs in a row is treated as strong enough evidence of real loss to trigger an immediate fast retransmit, without waiting for the slower retransmission timer.

Structured elaboration
Normally, each ACK acknowledges progressively more data as segments arrive in order. If segment N is lost but segment N+1 arrives (out of the expected order relative to what the receiver is still waiting for), the receiver can't advance its cumulative ACK past the end of segment N-1, so it re-sends an ACK for the SAME byte offset it already acknowledged, that's the duplicate ACK. One or two duplicate ACKs are common and unremarkable (ordinary, brief reordering happens on real networks); but THREE duplicate ACKs in a row is treated as a strong enough signal that data is genuinely missing (not just briefly reordered) to justify retransmitting immediately, well before the (much slower) retransmission timeout would otherwise fire.

Distinguishing genuine loss from simple reordering, in practice: sustained duplicate ACKs (three or more, continuing as MORE out-of-order segments keep arriving) point to real loss, since a purely reordering event typically self-resolves within one or two duplicate ACKs once the delayed segment catches up. A pattern of isolated single or double duplicate ACKs that stop on their own, with no retransmission ultimately needed, points to reordering rather than loss; TCP's own reordering-tolerance thresholds (adjacent to, but distinct from, PAWS: Protect Against Wrapped Sequence numbers) exist specifically to avoid triggering a fast retransmit on every minor reordering event.

Worked example
A sender transmits segments carrying bytes 1000-1500, 1500-2000, 2000-2500, and 2500-3000. If the segment carrying 1500-2000 is lost but the other three arrive, the receiver sends: ACK 1500 (for the first segment, normal), then ACK 1500 again upon receiving 2000-2500 (a duplicate, since 1500-2000 is still missing), then ACK 1500 again upon receiving 2500-3000 (a second duplicate). On the THIRD duplicate ACK for 1500, the sender's fast retransmit fires and it resends the 1500-2000 segment immediately, rather than waiting for its retransmission timer (which, per the RTO calculation, could be tens to hundreds of milliseconds longer) to expire.

Trade-offs & pitfalls
The right mitigation depends entirely on which cause is confirmed: if it's genuine loss, the useful levers are addressing the actual loss source (a congested link, a flaky physical connection) or, at the transport layer, ensuring SACK (Selective Acknowledgment) is enabled so only the truly missing segment gets resent. If it's reordering (for instance, from a load balancer or ECMP path hashing packets across multiple physical paths with slightly different latencies), the fix is architectural (favor flow-based hashing that keeps a single connection's packets on one path) rather than anything TCP-level, since TCP is already tolerating ordinary reordering correctly; treating a reordering pattern as loss and "fixing" the transport layer for it addresses the wrong layer.

What each technology is

SNMP (Simple Network Management Protocol) is polling-based: a monitoring system periodically asks network devices for counter values, like interface bytes in/out or error counts, via a defined set of queryable variables. NetFlow/IPFIX (IP Flow Information Export, the standardized, vendor-neutral successor to Cisco's NetFlow) works the opposite way: devices actively export flow records as traffic happens, where a flow record summarizes an individual conversation by source/destination IP, port, protocol, and byte/packet counts.

Different visibility for capacity planning

SNMP answers "how much total traffic is this link or device carrying, and is it approaching its ceiling," which is aggregate utilization, good for coarse link and device capacity trending. NetFlow/IPFIX answers "who or what is generating this traffic," per-flow visibility that tells you which application, tenant, or destination is actually driving a trend, something SNMP's aggregate counters cannot distinguish.

Capacity questions each answers

• SNMP: is this link going to saturate at its current growth rate (a simple trend on an interface counter); is a specific device's CPU or memory approaching its limit.
• NetFlow/IPFIX: which service or customer is responsible for a traffic spike, useful for capacity-cost attribution and deciding where to add capacity; is a growth trend organic, broad-based demand, or one noisy source skewing the aggregate.

Trade-offs in collection frequency and retention

SNMP polling is cheap and lightweight per poll, but only as fine-grained as the poll interval, commonly 1-5 minutes, so a short burst between polls is invisible. Coarse counters are cheap to retain for a long time. Flow export is much higher volume, a record per flow rather than per interval, so it costs more to collect, transport, and store; it's typically kept at full fidelity for a much shorter window (days), then rolled up into aggregates for longer trend retention, since keeping raw flow records for months gets expensive fast.

When to prefer one, or a hybrid

Pure SNMP is enough for basic "is this link or device approaching capacity" trending across a large hybrid fleet where per-flow attribution isn't the question. Add NetFlow/IPFIX when you need to answer "why" a link is trending toward capacity, or need per-tenant or per-application attribution, common at a WAN edge or a shared-tenant boundary. A practical hybrid strategy runs SNMP continuously and cheaply across the whole on-prem and cloud-connected estate for baseline trending, and enables NetFlow/IPFIX selectively only on the links where attribution actually earns its keep, such as a WAN uplink approaching a capacity-upgrade decision, so you get the broad picture cheaply and pay the flow-collection cost only where it matters.

Direct answer

Both policing and shaping hold traffic to a configured rate using a token bucket (a counter that refills at the allowed rate and is spent as packets pass). They differ in what happens to a packet that arrives with no tokens: a policer drops it (or re-marks it), a shaper queues it and sends it later. Queuing is the separate decision of which waiting packet leaves the interface next. Markings (DSCP, Differentiated Services Code Point, a 6-bit value in the IP header) are written once at the edge you trust and read by every queue downstream. On the public internet they are often reset to zero, so they matter only inside networks you or your carrier control.

Policing versus shaping

Cisco's documentation puts it plainly: a policer typically drops traffic, though it can instead change a packet's marking, and a shaper typically delays excess traffic in a buffer. Shaping applies to traffic leaving an interface, while policing can be applied in either direction. The terms in the token bucket:

• CIR (committed information rate): the average rate allowed.
• Bc (committed burst): how many bytes can pass at once, which is the bucket depth.
• Tc (time interval): mean rate = burst size / time interval.

With numbers: CIR = 10 Mbps and Bc = 15,000 bytes (120,000 bits) give Tc = Bc / CIR = 120,000 / 10,000,000 = 0.012 s = 12 ms. The bucket refills completely every 12 ms, and 120,000 bits per 12 ms is the 10 Mbps mean rate. The 15,000 bytes are the same 10 packets of 1,500 bytes used in the example below.

Use shaping when you must stay under a carrier's committed rate without losing packets, and policing when you must enforce a limit on traffic you do not want to buffer, such as untrusted or bulk traffic.

Worked example: 20 Mbps offered to a 10 Mbps limit

167 packets of 1,500 bytes arrive 0.6 ms apart (20 Mbps for about 100 ms). The policer has a 15,000-byte bucket (10 packets); the shaper has a 32-packet queue and drains at 10 Mbps (1.2 ms per packet).

PKT = 1500                      # bytes per packet
BITS = PKT * 8
RATE = 10e6                     # 10 Mbps policer and shaper rate
BURST = 10 * PKT                # bucket depth: 15,000 bytes
arrivals = [i * BITS / 20e6 for i in range(167)]   # 20 Mbps offered for about 100 ms

# Policer: tokens refill at RATE, a packet that finds too few tokens is dropped
tokens, last, passed, dropped = BURST, 0.0, 0, 0
first_drop = None
for i, t in enumerate(arrivals):
    tokens = min(BURST, tokens + (t - last) * RATE / 8)
    last = t
    if tokens >= PKT:
        tokens -= PKT
        passed += 1
    else:
        dropped += 1
        first_drop = i if first_drop is None else first_drop
print(f"policer: {passed} passed, {dropped} dropped (first drop at packet {first_drop}), no packet delayed")

# Shaper: packets wait in a 32-packet queue and leave at exactly RATE
QUEUE = 32
serial = BITS / RATE            # 1.2 ms per packet
free_at, queued_until, sent, dropped, worst = 0.0, [], 0, 0, 0.0
for t in arrivals:
    queued_until = [d for d in queued_until if d > t]
    if len(queued_until) >= QUEUE:
        dropped += 1
        continue
    depart = max(t, free_at) + serial
    free_at = depart
    queued_until.append(depart)
    sent += 1
    worst = max(worst, depart - t - serial)
print(f"shaper: {sent} sent, {dropped} dropped, worst queueing delay {worst * 1000:.1f} ms, last packet leaves at {free_at * 1000:.1f} ms")

Output:

policer: 92 passed, 75 dropped (first drop at packet 19), no packet delayed
shaper: 114 sent, 53 dropped, worst queueing delay 37.2 ms, last packet leaves at 136.8 ms

The policer passes the 10-packet burst plus what the refill allows (92 packets, about 11 Mbps over this window) and drops 75, with no added delay. The shaper delays instead: the queue builds until the worst packet waits behind 31 others, 37.2 ms of delay for the worst packet, and it still drops 53 once the 32-packet queue fills, because the offered load stays at twice the rate for the whole window. A shaper absorbs bursts shorter than its queue and drops when overload outlasts it.

Tracing the first packets by hand. Packets arrive every 0.6 ms (1,500 x 8 bits / 20 Mbps), and the policer's bucket refills 10,000,000 / 8 x 0.0006 = 750 bytes in each gap. Packet 0 finds 15,000 bytes and spends 1,500, leaving 13,500. Packet 1 gets 750 back and spends 1,500, leaving 12,750. Each packet nets minus 750, so the bucket empties after packet 18. Packet 19 finds only 750 bytes and is dropped; packet 20 finds 750 + 750 = 1,500 and passes; from there the policer alternates pass and drop, which is half of 20 Mbps, the 10 Mbps limit. The shaper instead holds packets: packet 0 leaves at 1.2 ms; packet 1 arrives at 0.6 ms, finds the line busy until 1.2 ms, leaves at 2.4 ms and so waited 0.6 ms; every later packet waits 0.6 ms longer than the one before, so packet 62 waits 37.2 ms, and packet 63 finds all 32 queue slots full and is dropped.

How queues decide which packet goes first

Each row below fixes the weakness of the row above it.

Weights in practice: classes weighted 50, 30 and 20 on a congested 10 Mbps link get 5, 3 and 2 Mbps. If the 20 class goes idle, the other two share its capacity in proportion and get 6.25 and 3.75 Mbps. LLQ is the usual enterprise answer: voice in the capped priority queue, other classes by weight. A queue also needs a drop policy for when it fills; plain tail drop (a full queue discards the packet that just arrived) discards new arrivals, while weighted random early detection (WRED) starts dropping packets at random before the queue is full, and does so earlier for lower-priority traffic.

Where to apply markings

First, classification (deciding which class a packet belongs to, by port, address, application signature or existing mark) comes before marking (writing the value). Mark as close to the source as you trust the device, then let every later hop act on the mark.

The same value appears in different notations: EF is 46 in decimal, 101110 in binary, and 0xb8 in the full type-of-service byte (46 x 4 = 184 = 0xb8), because the DSCP occupies the top 6 bits of that byte.

Why markings are often bleached or ignored on the public internet

The public internet has no end-to-end service contract. RFC 8100 notes that many networks re-mark unknown or unexpected DSCPs to zero when traffic enters, so a mark that is valid in your network can arrive as best effort. One reason is that a carrier cannot let customers who mark everything as high priority claim its premium classes. Only agreed interconnections preserve marks, and even then only for the agreed classes. The practical conclusion is that a mark guarantees nothing across the internet: your benefit comes from the queues at your own egress, where the mark is honored.

Pitfalls

• Shaping above the real link rate, so the queue forms in the carrier's device instead of yours.
• Marking from untrusted hosts, which lets any application take priority.
• An unbounded priority queue that starves other classes.
• Policing TCP bulk traffic too tightly: the resulting loss collapses throughput.

Direct answer

Name two to three concrete goals that span a delivery outcome, a relationship or context goal, and a craft improvement, then state one specific milestone you'd check yourself against at the interim mark, not a general feeling of being "on track." The exact goals should shift with the horizon asked, first six months, first year, or two to three years, and with the seniority of the role.

Structured elaboration

• Match scope to horizon. A first-six-months goal set is mostly about ramp-up and one visible first contribution; a first-year set adds one meaningful, largely independent delivery plus established trust with key stakeholders; a two-to-three-year set shifts toward growth in scope, ownership, or a chosen specialization rather than a single deliverable.
• Cover three goal types, not just the technical one: a concrete problem solved or thing shipped, a context and relationship goal (understanding the systems and people whose buy-in you'll need for anything ambitious later), and a craft or process improvement you personally own end to end.
• Attach a leading indicator to each goal, something observable well before the deadline, not just the final outcome. This is what makes a mid-point check-in credible instead of a guess.
• Calibrate ambition to seniority. A candidate for a more senior role should include a scope or influence goal, not only execution goals; someone earlier in their career should show they understand ramp-up comes first.
• The single strongest closing move: state the concrete milestone you'd check yourself against at the interim mark, a specific thing shipped, a decision made, feedback actually received, rather than restating the goals as if listing them again proves progress.

Worked example

When I started a previous role, I set three goals for the year: ship one meaningful improvement to a system that mattered to the team, build real working relationships with the two or three people whose sign-off I'd need for anything ambitious later, and establish one process habit I could point to as mine. At the six-month mark, my checkpoint wasn't "do I feel settled," it was two specific things: had I shipped the first version of that improvement, and could I name the people who'd actually back me if I proposed the next, bigger version of it. Both were true, so instead of starting a new goal from zero, I used the credibility from the first six months to scope a larger version of the same problem for the rest of the year.

Trade-offs & pitfalls

• Vague goals ("learn a lot," "add value") signal you haven't actually thought this through; goals that depend entirely on something outside your control (a launch owned by another team) are the opposite failure.
• Loading up only on technical goals while skipping relationship or context goals tends to stall growth later, once the technical work is good you still need sponsors.
• Skipping the interim checkpoint definition means "on track" becomes something you decide retroactively rather than something you can actually check.
• Answering with only execution goals at a senior level under-signals; answering with only scope-and-influence goals very early on over-signals.

Direct answer

Give public addresses only to what the Internet must reach: the service virtual IP addresses (VIPs, the addresses clients connect to, shared by the load balancers) and a small outbound NAT pool. Everything else in the DMZ (demilitarized zone, the segment between the Internet and the internal network) uses private addresses. Translation happens at the edge firewall (public VIP to private VIP inbound, many-to-few for outbound, where the NAT pool is the small set of public addresses outbound traffic is rewritten to) and at the load balancer (VIP to a pool member). Reserve fixed positions for gateways, device pairs (HA pairs: two devices where one takes over if the other fails) and VIPs in every subnet, and record all of it in an IP address management (IPAM) system so each address has an owner and a purpose.

The example uses 203.0.113.0/26 (a documentation range) as the public block routed to the firewall by the ISP over its own small transit link, and 10.50.0.0/23 for the private DMZ.

Public allocation (64 addresses)

32 + 16 + 16 = 64, the whole /26. No public address is ever put on a web server.

Private allocation

The public VIP and its private VIP use the same offset, so the mapping is a rule you can write down: private = 10.50.0.32 + (public - 203.0.113.0). Public 203.0.113.1 maps to 10.50.0.33, 203.0.113.2 to 10.50.0.34, and 203.0.113.30 to 10.50.0.62. A check in Python confirms every block sits inside its parent and none overlap. Reading the output: the first line shows the three public blocks add up to the whole /26, the next shows the VIP range, and each public VIP <-> private VIP line shows the fixed offset rule at work.

import ipaddress as ip
pub = ip.ip_network("203.0.113.0/26")
vips = ip.ip_network("203.0.113.0/27")
pat = ip.ip_network("203.0.113.32/28")
spare = ip.ip_network("203.0.113.48/28")
assert all(x.subnet_of(pub) for x in (vips, pat, spare))
assert not vips.overlaps(pat) and not vips.overlaps(spare) and not pat.overlaps(spare)
print("public /26:", pub.num_addresses, "= VIPs", vips.num_addresses, "+ egress", pat.num_addresses, "+ spare", spare.num_addresses)
print("VIP /27 range", vips[0], "-", vips[-1])
lb = ip.ip_network("10.50.0.0/24")
infra, vipnet = ip.ip_network("10.50.0.0/28"), ip.ip_network("10.50.0.32/27")
print("LB tier infra", infra[0], "-", infra[-1], "| private VIPs", vipnet[0], "-", vipnet[-1], "inside /24:", vipnet.subnet_of(lb), infra.subnet_of(lb))
for i in (1, 2, 5):
    print(f"public VIP {vips[i]} <-> private VIP {vipnet[i]}")
print("web tier", ip.ip_network("10.50.1.0/24")[10], "-", ip.ip_network("10.50.1.0/24")[250])
print("server addresses .10-.250:", 250 - 10 + 1)

public /26: 64 = VIPs 32 + egress 16 + spare 16
VIP /27 range 203.0.113.0 - 203.0.113.31
LB tier infra 10.50.0.0 - 10.50.0.15 | private VIPs 10.50.0.32 - 10.50.0.63 inside /24: True True
public VIP 203.0.113.1 <-> private VIP 10.50.0.33
public VIP 203.0.113.2 <-> private VIP 10.50.0.34
public VIP 203.0.113.5 <-> private VIP 10.50.0.37
web tier 10.50.1.10 - 10.50.1.250
server addresses .10-.250: 241

Where translation happens

A traced example (client address illustrative, from a documentation range): a client at 198.51.100.25 connects to 203.0.113.5. The firewall rewrites the destination to the private VIP 10.50.0.37. The load balancer picks a web server, say 10.50.1.20, and rewrites the source from 198.51.100.25 to its own address 10.50.0.6, so the server sees a request from 10.50.0.6. The server replies to 10.50.0.6, which is the load balancer, so the reply returns along the same path. The load balancer sends it back to the firewall, which rewrites the source from 10.50.0.37 back to 203.0.113.5, and the client receives a reply from the address it contacted. Without the source rewrite, the server would reply straight to 198.51.100.25 via its default gateway, the firewall would see a reply to a connection it never saw start, and the client would drop an answer from the wrong address.

1. Inbound, at the edge firewall: static destination NAT maps the public VIP to the private VIP. The firewall is where Internet traffic enters, so it is the natural place to translate and to filter.
2. At the load balancer: it receives traffic on the private VIP and picks a pool member. It also source-translates (rewrites the source address of) the client address to its own floating self-IP (.6, an address owned by the pair that moves to whichever load balancer is active), so the server's reply returns through the load balancer instead of going straight out through the firewall. The cost is that servers see the load balancer's address, so the original client address must be passed in a header (X-Forwarded-For) or the PROXY protocol (a small preamble the load balancer sends on the connection carrying the real client address), and web logs and rate limits must use that.
3. Outbound, at the edge firewall: servers that need to reach the Internet (patches, third-party APIs) are source-translated many-to-few into the NAT pool 203.0.113.32/28. A cloud NAT gateway plays only this role; there, the public VIPs are addresses attached to the cloud load balancer rather than firewall mappings.

Firewall rules stay simple because the web tier accepts connections only from the load balancers' addresses (10.50.0.0/28), not from the Internet or the VIP range.

Failover and VIP reservations

• HA pairs share virtual addresses (the two devices exchange heartbeats to detect failure and synchronise connection state, then one answers for the shared address): the gateway (.1) and the LB floating self-IP (.6) belong to no single device. Reserve them in IPAM with status "reserved, HA shared" so nobody hands them to a server.
• VIPs float between the LB pair, so failover needs no extra public addresses. The spare /28 covers a second site or a second ISP.
• Put the HA heartbeat and state-sync links on their own point-to-point link, not in the DMZ subnets, so an attacker in the DMZ cannot interfere with failover.

Documenting it

Hold every allocation in IPAM as a record with: prefix or address, purpose, owner, VLAN, status (allocated, reserved, free), the NAT mapping (public to private), DNS names (forward and reverse), ticket reference and last-verified date. DNS records for VIPs live next to the IPAM record. Treat IPAM as the source of truth and run a scheduled comparison against live ARP tables and the firewall's NAT rules: anything on the network that IPAM does not know about is the defect to chase, and every reserved address with nothing behind it is reviewed.

Trade-offs and pitfalls

Static 1:1 mapping plus a fixed offset makes audits and troubleshooting trivial, but it spends one public address per service, so a /27 limits you to 30 services. If that runs out, use host-header routing (the load balancer reads the website name in the HTTP request) or SNI (Server Name Indication, the website name a client sends in the TLS handshake) routing on the load balancer so many names share one VIP. Do not use the NAT pool addresses as VIPs: a shared outbound address on a mail-sending server can damage reputation for every service using it.

Direct answer

Do not make every edge router carry everything. Split the problem into four jobs and give each its cheapest tool: limit what comes in (inbound filters, maximum-prefix on every session), limit how many sessions an edge holds (route servers at exchange points, route reflectors for iBGP), limit what reaches the forwarding hardware (carry the full table only where exit choice needs it, default route elsewhere), and size hardware for the table you chose to keep. Each option costs routing precision, visibility or operational complexity, so choose per router role.

Terms: an IXP (Internet exchange point) is a shared switching fabric where many networks interconnect; a bogon is an address range that should never appear on the public Internet, such as private or reserved blocks; blast radius is how much damage a single mistake can do; a VRF (virtual routing and forwarding instance) is a separate routing table on one router; RIB (routing information base) is the software table of routes, held in ordinary memory; FIB (forwarding information base) is the table the forwarding hardware uses, often in TCAM (ternary content-addressable memory, fast and expensive hardware memory with a fixed number of entries). The RIB can be sized by buying memory, while the FIB is a hard ceiling set by the chip.

Arithmetic for the problem

• If each of 400 sessions sent a 1,000,000-prefix table, the RIB would hold up to 400 x 1,000,000 = 400,000,000 paths. Real sessions send far less, which is why each session needs a cap.
• A 300-member exchange point: each member needs 299 bilateral sessions to reach everyone, or 2 sessions to a pair of route servers.
• At the scale of the question, 2,000 sessions that each send only 100,000 prefixes already give 2,000 x 100,000 = 200,000,000 paths in the RIB. With 5,000 sessions at a full 1,000,000 prefixes each it would be 5,000,000,000. Session count multiplies table size, which is why sessions are limited as hard as prefixes.
• Across a whole 2,000-member exchange, full bilateral peering would need 2,000 x 1,999 / 2 = 1,999,000 sessions in total, against 2 x 2,000 = 4,000 sessions to a pair of route servers.

Options and what each costs

The rows serve the four jobs above: inbound filters, maximum-prefix and RPKI admission limit what comes in; route servers limit how many sessions an edge holds; partial table plus default and RIB partitioning limit what reaches the RIB and FIB; bigger hardware sizes what you keep.

Configuration excerpt (Cisco IOS XE)

ip prefix-list INTERNET-IN seq 5 deny 0.0.0.0/0
ip prefix-list INTERNET-IN seq 10 permit 0.0.0.0/0 le 24
route-map FROM-TRANSIT permit 10
 match ip address prefix-list INTERNET-IN
route-map FROM-TRANSIT deny 100
router bgp 64500
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map FROM-TRANSIT in
  neighbor 192.0.2.1 maximum-prefix 1300000 90 restart 30
  neighbor 198.51.100.7 maximum-prefix 500 80 warning-only

The first two lines deny the default route and then permit every prefix up to /24. The transit limit sits above the expected table: the IPv4 table was about 1.08 million prefixes on 6 October 2026 (bgp.potaroo.net, measured that day), so 1,300,000 leaves about 20 percent headroom, and a warning at 90 percent (1,170,000) fires only if the table grows well past today's size. An 80 percent threshold on the same 1,300,000 limit would warn at 1,040,000, still below today's table of about 1.08 million, so it would fire permanently. restart 30 brings the session back after 30 minutes. The peer line only logs, so a mistake there does not drop the session while you tune it. Bogon (reserved address) denies would sit before the permit, and a real list also needs IPv6.

Recommendation

For an edge fed by two transits and an IXP: take the full table from the two transits only, filter at /24 and bogons, put maximum-prefix on every session, peer at the IXP through route servers and take bilateral sessions only with the few peers whose traffic justifies per-peer policy, and put internal routes in a separate partition. Flip to a partial table plus default when the FIB ceiling is within a growth cycle and exit precision is not critical for the router's role (for example aggregation or branch edge).

Pitfalls

• Setting maximum-prefix at the current count with no headroom drops the session the next time the neighbor grows.
• Counting only the RIB: the FIB limit is often the one that bites first, because it is a fixed chip capacity, and what happens on overflow depends on the platform, so find out what yours does before relying on it.