Purpose

When you run tcpdump inside a routing-instance namespace on a Versa VOS appliance (ip netns exec <VRF-name> tcpdump ...), you will see only a subset of that VRF's traffic. This is expected behavior, not a fault or a misconfiguration. This note explains why, so captures are interpreted correctly.

The key concept: two planes per VRF

Every routing instance (VRF) on a VOS appliance exists in two separate planes that share the same name:

Plane	What it is	What is forwarded here
Control plane	The Linux network namespace (ip netns)	Routing protocols and host-terminated traffic: BGP, OSPF, BFD, ARP/ND, management sockets
Data plane	The VOS dataplane forwarding table (show vunet route summary, FIB id)	All transit and forwarded data traffic

tcpdump attaches to the Linux (control-plane) side only. It captures packets the kernel stack in that namespace actually processes. It cannot see packets that VOS forwards inside the dataplane, because those packets never enter the kernel.

The VRF name is identical in both planes, but they are two different forwarding contexts. A namespace capture and a dataplane forwarding table can carry the same VRF name and still show different traffic.

What you WILL see in a namespace capture

Traffic that terminates on, or is generated by, the appliance's own control plane in that VRF:

• Routing-protocol sessions to and from the appliance (BGP, OSPF, BFD)
• ARP / ND on that VRF's interfaces
• Host-originated and host-bound traffic (for example, a ping to the appliance's own address in that VRF)
• Management sockets that terminate locally in that namespace

Rule of thumb: if the packet talks to a process running on the appliance, it rides the kernel and the capture shows it.

What you will NOT see in a namespace capture

Traffic that VOS forwards in the dataplane and never hands to the kernel:

• Transit / forwarded data traffic — a packet routed through the VRF, not to the appliance
• Tunnel-encapsulated flows — traffic encapsulated into IPsec/ESP, MPLS-over-GRE, or VXLAN and sent out an SD-WAN tunnel
• Punted-then-forwarded flows — packets handled by the dataplane control-data thread and re-injected into the dataplane FIB rather than the kernel
• Controller / management sessions that reach the appliance over the management path or in-band over a tunnel, because those terminate in the management context, not a tenant VRF namespace

None of these are missing or dropped. They are in the dataplane, where a namespace tcpdump has no visibility.

Why "tcpdump -nli any" sees more

tcpdump -nli any is a machine-wide capture. It spans every namespace plus the copies the dataplane injects to the host. That is why it can show a flow a per-namespace capture cannot. It is the widest view, but it does not tell you which plane or which VRF the packet is in.

The right tool for each plane

To see...	Use
Routing / control-plane traffic in a VRF	ip netns exec <VRF> tcpdump
The actual forwarding table a VRF uses	show vunet route summary, then show vunet route table <id>
Transit / dataplane-forwarded / tunneled inner packets	VOS dataplane packet trace (packet-trace debug)
The encapsulated outer leg of a tunnel	tcpdump on the transport VRF namespace, filtered to the tunnel outer (for example UDP 4790); note the payload is encrypted

One-line summary

A namespace tcpdump shows only the control-plane traffic that terminates on the appliance in that VRF, such as BGP. Forwarded data traffic, tunneled flows, and controller management sessions live in the VOS dataplane and are invisible to a namespace capture by design. Use the dataplane packet trace for those, and capture the transport VRF for the encapsulated tunnel leg.