Run a Cilium connectivity test

When a network path is in doubt, do not guess: Cilium provides a connectivity test that exercises the real datapath (the actual path packets take between pods) and reports exactly which scenario fails. It deploys a set of test pods, runs traffic between them, and reports pass or fail per case. Pair it with Hubble, Cilium's tool for watching live network flows, to see why a case failed.

Run the test#

Install the Cilium CLI⁠, then:

		$ cilium connectivity test
	

The command creates a cilium-test namespace, runs pod-to-pod, pod-to-Service, and egress-to-the-internet checks across nodes, and prints a summary. It cleans up after itself; if it is interrupted, delete the cilium-test namespace manually.

Read the summary by scenario:

• Pod-to-pod across nodes failing points at the node-to-node datapath, the VXLAN overlay path covered in MTU and the VXLAN tunnel .
• Pod-to-Service failing but pod-to-pod passing points at Service or NodePort handling.
• Egress to the internet failing points at outbound routing or an egress policy.
• DNS checks failing point at CoreDNS or a port-53 block, covered in Diagnose pod DNS resolution .

Distinguish a policy drop from a datapath failure#

A failed scenario has two very different causes, and Hubble separates them. Watch flows while the test runs, or right after:

		$ hubble observe --verdict DROPPED --last 100
	

• A policy drop shows a DROPPED verdict with a policy-related reason. Something a NetworkPolicy or CiliumNetworkPolicy is denying; fix the policy.
• A datapath failure shows no policy verdict at all: the packet never reaches the far side, or drops without a policy reason. That is a node or overlay problem, not a policy one; start at Debug node networking .

For reading flows in general, see See flows with Hubble .

When to escalate#

Cilium is installed and managed by Syself Autopilot, so you do not patch or reconfigure it. If the connectivity test shows a datapath failure that is not a policy drop and not an MTU or DNS issue you can explain, collect the failing scenario name and the Hubble drop output and open a support case. A policy drop, on the other hand, is yours to fix in your own NetworkPolicy objects.