skip to content

In a VRF-lite campus, how do you leak a shared-services VRF's DNS and DHCP routes into each zone VRF without merging the zones?

level: seniorimportance: should knowfreq 22%

answer

  1. both directions or nothing
  2. leak prefixes, not tables
  3. overlap breaks the return path
  4. a leak skips the firewall
  5. never let shared become transit

basics

~20 s

Copy only the shared-services prefix into each zone VRF and only each zone's own prefix back into the shared VRF, filtered so nothing passes onward. Overlapping zone prefixes need translation or renumbering, and leaked paths bypass any firewall.

solid answer

~50 s

A **route leak** copies chosen routes from one VRF's table into another's; RFC 4364 section 4.3.6 describes this as distributing routes among VRFs in a single router by import policy, and in a VRF-lite campus it is an implementation feature (import and export policy, or a per-VRF static route whose next hop is in another VRF). For shared services you leak **two directions**: the `SHARED` prefix, say `10.99.0.0/24`, into each zone VRF, and each zone's own prefix into `SHARED` so replies can return. Leak **specific prefixes**, never a default route and never everything a VRF holds, and filter what `SHARED` exports so a zone's routes are never passed on to another zone. Two zones reusing one prefix cannot both be reached from `SHARED`, so translate or renumber. And remember that a leak is routed by the router with no inspection.

go deeper

for a junior

Recall that VRFs block everything by default, so shared DNS and DHCP need routes copied between tables on purpose.

for a middle

Explain the round trip: the service prefix into the zone and the zone prefix back into the shared VRF. Give the DNS timeout as the symptom of a one-way leak.

for a senior

Show how a careless export turns the shared VRF into a transit, why overlapping zones cannot share one return table, and how a leak bypasses the firewall.

for a principal

Decide which zones may lean on shared services at all, which get their own copies, and what translation or renumbering costs over the campus's lifetime.

## Why leaking exists A VRF-lite campus with `CORP`, `GUEST`, `IOT` and `PAY` zones keeps each zone in its own routing table, so by default no zone reaches any other. But every zone needs **shared services**: DNS to resolve names and DHCP to hand out addresses, and often time and logging too. Duplicating those servers per zone is costly, so the usual design puts them in a `SHARED` VRF (here `10.99.0.0/24`, with DNS at `10.99.0.53` and DHCP at `10.99.0.67`) and **leaks** routes so each zone can reach that one subnet and nothing else. A **route leak** copies a route from one VRF's table into another's. RFC 4364 section 4.3.6 covers the case inside one router: routes may be distributed from one VRF to another on the same device, decided by the same import policy that would apply between routers. VRF-lite has no route targets of its own, so implementations expose this as import and export policy between VRFs, or as a static route in one VRF whose next hop resolves in another. ## Two directions, every time Reachability is a round trip. For an IoT sensor at `10.30.2.15` to resolve a name: 1. The sensor's query is looked up in `IOT`, which needs a route to `10.99.0.0/24`. 2. The DNS server's reply is looked up in `SHARED`, which needs a route to `10.30.0.0/16`. Leak only the first and the query arrives while the reply has no route: DNS times out, and from the zone side it looks like the server is down. DHCP adds a twist: a DHCP relay on the zone's gateway forwards the client's request to the server, and the server answers the relay's address in the zone, so that address must be reachable from `SHARED` too. ## Leak narrowly | Leak | Effect | Verdict | |---|---|---| | `10.99.0.0/24` into each zone; each zone's prefix into `SHARED` | Each zone reaches services; services reply | The intended design | | A default route from `SHARED` into a zone | The zone follows `SHARED` for every unknown destination | Too broad | | Everything `SHARED` holds, exported to every zone | Zone A's leaked prefix is exported onward to zone B | Turns `SHARED` into a transit between zones | | Host routes for the DNS and DHCP servers only | Even tighter than the /24 | Fine, at the cost of more entries | Whether a route leaked into `SHARED` is exported again to other VRFs is an implementation behaviour; do not rely on a default. Write the export policy so `SHARED` advertises only its own prefix. Otherwise `CORP` learns `10.20.0.0/16` through `SHARED`, and guest-to-corporate traffic is routed with no firewall in the path. ## Overlap breaks the return path VRFs let zones reuse address space. RFC 4364 section 1.3 puts the limit exactly: VPNs that share a site may overlap "as long as there is no need for any communication between systems with such addresses and systems in the common sites". `SHARED` is that common site. If `GUEST` and `IOT` both use `172.16.0.0/16`, `SHARED` can hold only one route for that prefix, so replies reach only one zone. The fixes are: - **Renumber** so every zone that uses shared services has unique space (the cheapest fix if done early). - **Translate** one or both zones' source addresses into unique space at the boundary (source NAT), so `SHARED` sees distinct addresses. - **Duplicate** the service inside the overlapping zone. ## What a leak does not give you - **No inspection.** A leak is a route; the router forwards between VRFs directly. If a zone's access to shared services must pass a firewall, do not leak: route through the firewall instead. - **No port restriction.** Leaking `10.99.0.0/24` exposes every port on every host in it; narrow it with a filter if only DNS and DHCP should be reachable. - **A new common target.** Every zone now reaches the same few servers. What an attacker gains from owning one of them is a security question in its own right, and it is the reason the payment zone often gets its own DNS rather than a leak. The interview answer: leak specific prefixes both ways, filter exports so shared never becomes transit, solve overlap by translation or renumbering, and know that every leak is an uninspected path.

  • The leak is in place in both directions, yet IoT DHCP clients still get no address. What do you check?
    The relay path. The zone gateway relays the request with its own address in the IoT VRF as the relay address, and the server replies to that address. If `SHARED` has a route for the IoT client subnet but not for the gateway's relay address, or the relay is sending from an interface in the wrong VRF, replies never return.
  • Why not simply put the DNS and DHCP servers in every VRF with one interface each?
    A multi-homed server with an interface in every zone is itself a bridge between zones: anything that compromises it reaches all of them, and its own routing may forward between its interfaces. It also needs per-interface addressing that breaks if zones overlap. Leaking narrow routes keeps the server single-homed and the policy on the routers.

saying these in an interview costs you the question

  • Leaking the shared-services prefix into a zone is enough for DNS to work.
  • Overlapping zone prefixes are fine because the shared VRF picks the right zone.
  • A route leak between VRFs is inspected like traffic through a firewall.
  • Leaking a default route into each zone is the simplest safe leak.
  • Routes leaked into the shared VRF are never passed on to other zones.