Learning objectives
- Trace a specific flow across clouds
- Choose discriminating network evidence
- Connect packet behavior to application symptoms
The mental model
A multi-cloud diagram is easy to draw and hard to operate when ownership is unclear. Each boundary adds routing, identity, policy, DNS, and observability questions. A service in one cloud may depend on a database in another, so application latency can contain several network round trips. A network incident can be directional: requests leave successfully while responses take an invalid return path. Useful troubleshooting starts with a specific flow and compares it with one that works. Gather source, destination, protocol, port, timestamp, and expected behavior. This small amount of precision is more valuable than asking every team whether their dashboard looks green.
How it works
Define a flow as a source and destination address, transport protocol, source and destination ports, and direction. Add hostname and application identity where relevant, because policy may use information beyond the packet tuple. Trace DNS resolution, route selection, tunnel or connector state, firewall decisions, translation, and return routing. Compare packet captures at successive boundaries when authorized, using synchronized timestamps and avoiding unnecessary sensitive payload collection.
Common hidden failures include overlapping prefixes, asymmetric paths through stateful devices, MTU problems after encapsulation, and private DNS resolving to an unreachable address. Small probes can succeed while larger application transfers stall if path MTU discovery is broken. Ping may be blocked or treated differently from the application protocol; its failure is not conclusive, and its success is not a full transaction test. Build observability with flow logs, interface counters, tunnel metrics, synthetic application checks, and application traces. Correlate these views rather than promoting one to universal truth. For business relevance, describe which user journey or operational process is affected and how long the organization can tolerate the outage. The diagnosis should conclude with a verified repair and prevention, such as an address-allocation check or a tested route-change procedure.
Applied example · hypothetical
Hypothetical example: a cloud-to-cloud report works for small results but stalls when exporting a large file. DNS and authentication succeed. Packet evidence shows repeated retransmission after a tunnel migration, and the larger encapsulated packets exceed the viable path size while necessary feedback is filtered. A controlled smaller-packet test supports the MTU hypothesis. The repair adjusts the network path and validates normal-size transfers. Adding application servers would have increased cost without addressing the failure. The prevention is a migration test that includes representative payload sizes and both directions.
In a customer engagement
In a Cloudflare connectivity engagement, collect the exact failing flow and identify which customer and provider teams own each boundary. Verify connector health but continue through routing, policy, DNS, and application checks. A useful escalation includes a working comparison, timestamps, and sanitized evidence. Explain the next diagnostic action in terms of what hypothesis it can eliminate.
Interview relevance
For troubleshooting interviews, narrate a small decision tree rather than a list of commands. Start with scope and a known-good comparison, identify the first divergence, and choose a test that separates causes. Mention return paths and payload size when the symptoms support them, showing practical network judgment.
Common mistakes
- Stopping at a green tunnel indicator
- Ignoring return-path state
- Treating ping as a complete application test
Key terminology
MTU — The maximum packet size a link or interface can carry without fragmentation at the relevant layer.
Asymmetric routing — Forward and return traffic taking different network paths.
Flow log — Metadata describing observed network traffic, often including endpoints, ports, direction, and policy outcome.
Explain it without the page
- What exact information belongs in a network escalation?
- Which symptoms make MTU more plausible than DNS?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.