Why can two private networks that each peer with a shared middle network not reach each other?
answer
- links join two, never a chain
- the middle is not a router
- reachability is routing, not filtering
- no valid target for the far range
- hub attachment replaces the second hop
basics
~20 sPeering is non-transitive: a point-to-point link carries traffic only between the two ranges that are party to it, and the middle network will not relay for a third. Reaching the far network needs its own link, or a hub all three attach to.
solid answer
~50 sA point-to-point peering link is a relationship between exactly two private networks, and it is non-transitive. The platform forwards between the two ranges that own the link and nothing else, so the middle network never relays for the far end, and the far range is not a usable target on that link in either end's route table. Three honest fixes exist: give the two ends their own direct link; attach all three networks to a transit hub and make sure the hub route table serving them carries all three ranges; or run your own forwarding workload inside the middle network and point routes at it, which means you now operate a router and own its capacity and failure modes. Changing boundary filtering rules never helps, because this is a routing property rather than a permission one.
code
json · 13 lines{
"network": "A",
"ownRange": "10.10.0.0/16",
"routeTable": [
{ "destination": "10.10.0.0/16", "target": "local" },
{ "destination": "10.20.0.0/16", "target": "peering-link-to-B" }
],
"attemptedEntry": {
"destination": "10.30.0.0/16",
"target": "peering-link-to-B",
"effect": "no path: C is not party to this link"
}
}go deeper
Remember the shape: a peering link joins two networks, not a chain. If three networks all have to talk, count the links that implies before you draw the diagram.
Explain the mechanism: the platform forwards only between the two ranges party to the link, and the far range is not a usable target on it. Name the hub as the alternative to more links.
Diagnose from the symptom: partial reachability that survives every filtering change is a routing problem. Say which route table you would read first and what entry you expect to be missing.
Own the trade-off: a chain of links somebody will inevitably ask you to make transitive is the signal the estate needed a hub, plus a standard for how a new network joins, before the third request arrives.
## What a point-to-point link actually is When you join two private address ranges on a cloud platform with a **peering link**, you are not installing a router and you are not joining a routing domain. You are declaring a relationship between exactly **two** networks. The platform's job afterwards is narrow: it will carry a packet whose source is in one of the two ranges and whose destination is in the other, provided both sides have installed a route for it. That is the whole contract. The word that matters is **non-transitive**. Transitivity would mean that if A can reach B and B can reach C, then A can reach C. Peering deliberately does not give you that. Each link stands on its own. ## Why the third network stays unreachable Two separate mechanisms have to fail for the chain to work, and both do: - **Forwarding.** The middle network is not acting as a router. It has no forwarding role on the link, so a packet from the first network addressed to the third is not something it will pass along, even though it holds a link to each. - **Routing.** The far network's range is not a valid target on a link it is not party to. Depending on the platform, the route entry is either refused outright or accepted and then silently black-holes; either way nothing arrives. Writing the entry is therefore not a fix, it is a way of hiding the problem behind a route that looks present. This produces a characteristic symptom that gets misdiagnosed for hours: | What you observe | The wrong diagnosis | What is actually true | |---|---|---| | One range reachable, another not, from the same workload | A boundary filtering rule is dropping it | There is no path at all for the second range | | Opening every filter changes nothing | The rules are applied somewhere else | Filtering is downstream of a route that does not exist | | The middle network reaches both ends fine | The middle is "already routing" | The middle terminates two links; it relays for neither | | Traffic works in a test from the middle network | The link is proven good | You tested the two ranges that are party to that link | ## The three ways to genuinely connect the far network 1. **Add a direct link between the two ends.** Simple, and the data path stays independent of anything else. The cost is that the number of links grows with the number of pairs, not the number of networks, so this stops being the cheap option quickly. 2. **Attach all three to a transit hub.** Every network holds one **hub attachment**, and the hub route table that serves those attachments carries all three ranges. This is the design that scales, and it is what an estate ends up with once more than a handful of networks must interconnect. 3. **Run a forwarding workload in the middle network** and point explicit routes at it. It works, and it is sometimes the only option when a platform constraint rules the other two out, but you have just taken ownership of a router: its throughput, its patching, its redundancy and its place in every incident. ## A hub is not automatically transitive either The most common follow-on mistake is to assume that attaching everything to a hub makes everything mutually reachable. What a hub gives you is a **place** where routes can be shared. Which attachments actually reach which is decided by the hub's route tables: attachments associated with the same route table, holding each other's ranges, reach each other; attachments deliberately segregated into separate route tables do not. That segregation is a feature — it is how you let many networks reach shared services without letting them all reach one another — but it means a new attachment is not connected merely by existing. ## Why this shows up during a merger The chain topology is almost never designed. It grows: one estate peers with a partner network, the partner is later peered with a third, and somebody assumes the graph is now connected. The moment two estates are joined, three or four networks that were each individually linked are expected to behave like one, and the non-transitivity surfaces as a wave of "can't reach" tickets that look like filtering problems. The practical discipline is to draw the graph before you promise reachability: list every pair that genuinely must talk, count the links that implies, and check each end's route table for an entry naming the far range with a target that is actually party to it. If the pair count is climbing, that is the signal to stop adding links and design the hub instead.
- If you write a route in the first network sending the far range down the existing link, what happens?Nothing useful. The link carries traffic only between the two ranges that are party to it, so the packet has no path beyond the peer. The entry makes the route table look complete while reachability stays broken, which is worse than leaving it absent — the next person to debug it sees a route and moves on to blaming filtering.
- Does attaching a network to a transit hub make it reachable from everything else attached?Only from the attachments that share a hub route table carrying its ranges. The hub is a place where routes can be shared, not a guarantee that they are. Segregating attachments into separate hub route tables is how you let many networks reach a shared services network without letting them reach each other.
- The middle network's owner offers to 'turn on forwarding' for you. What are you actually agreeing to?To a routing workload that somebody operates: its throughput becomes your ceiling, its maintenance becomes your outage, and its failure becomes a partial-reachability incident across three estates. It is a legitimate answer when a platform constraint rules out a direct link or a hub, but it should be a deliberate choice, not a favour.
Two people who each have your phone number cannot call each other through you unless you actually pick up and relay. A peering link is the number, not the relay.
saying these in an interview costs you the question
- Assumes peering chains like the internet, so two links connect three networks
- Thinks adding a route entry alone creates the missing path
- Blames a boundary filtering rule for what is an absent route
- Says a hub makes every attachment reach every other regardless of its route tables
- Believes the middle network is already forwarding because it reaches both ends