Keep two route ledgers in an IPsec lab: underlay and protected
Two ledgers: one reaches the peer, one carries the private prefixes. Track both, and treat redistribution as a policy decision rather than a shortcut.
Two questions get tangled in an IPsec lab: how a packet reaches the peer's outside address, and how it reaches the private networks behind that peer. They belong in separate ledgers, because different routing processes answer them and they fail with different symptoms. Keep the underlay ledger for external endpoints and their next hops. Keep the overlay ledger for protected prefixes, their gateways and the intended path through the tunnel. Most lab confusion comes from a route that legitimately exists in one ledger being read as evidence about the other.
Two ledgers, two questions
The ledgers stay short enough to maintain by hand while the lab is small, which is exactly when they are most useful. Two columns are enough: what the entry is, and how it is reached.
| Ledger | What it lists |
|---|---|
| Underlay | Each gateway's external address and the next hop that reaches it |
| Protected | Each private prefix, its local gateway and its intended path through the tunnel |
Write both directions. A prefix that appears in the outbound ledger and not in the return ledger produces a tunnel that carries requests and drops answers. That half-working state is the most common lab outcome, and it is easily mistaken for a policy problem.
Write the destination before the protocol
Start with destinations rather than protocols. For each gateway, record the external address and the next hop that reaches it. Then record each private prefix, its local gateway and the path it should take through the tunnel.
Doing that before choosing a routing protocol keeps the discussion honest. The design arrives with requirements instead of preferences. The argument about which protocol to run then becomes a question about which requirement is actually hard.
Static or dynamic, decided per ledger
Static routing on the transport side is usually right in a lab: two endpoints, one next hop, nothing to converge. The private side may reasonably be dynamic, because prefixes come and go with the exercise. Running one routing protocol on the transport side and another on the private side does not oblige you to redistribute between them, and treating mutual redistribution as a prerequisite for IPsec is where labs start producing results nobody can explain.
Decide the two ledgers separately and note which one is dynamic. One answer for both sides usually means the two questions were never really separated.
Redistribution is a policy boundary
Where routes must cross, make the crossing a policy with named prefixes, direction, metric treatment and a loop guard. Prefix lists and route maps give you all four, and tags keep a redistributed route identifiable after it has lost its original context. Read the semantics carefully, because they are not interchangeable: an ACL deny inside a match clause means the route fails to match and evaluation continues, while a route-map deny sequence stops the route from being redistributed at all. The redistribution route-map guide covers those clauses and the attribute changes that go with them.
Then compare the resulting routing table with both ledgers. A lab that starts forwarding after broad redistribution has demonstrated reachability rather than intent. Any table entry that appears in neither ledger means the export is broader than the design, and every later advertisement inherits that ambiguity.
Keep the security example as current as the routing
Old walkthroughs that rely on weak algorithms or a shared demonstration secret are historical observations. Copying them into a lab you intend to extend is how weak defaults survive into production. Use the platform's supported policy and note the version you tested, because the lab outlives the tutorial.
Accept one approved host-to-host flow, its return traffic, and one destination that must stay outside the protection scope. Save the route source and the negotiated selectors with each result, so the record shows which layer was proven rather than which layer happened to be up.
When something breaks, the ledger tells you which layer to open. No peer reachability is transport, no inner route is private-path, and a route that exists with no matching selector is policy. Three sentences, one diagnosis, no guessing.