Modern infrastructure networking has a visibility problem.
We can usually answer questions like:
- Which IP talked to which IP?
- Which port was used?
- How many bytes were transferred?
- Which Kubernetes service received traffic?
Those answers are useful.
But when something goes wrong, infrastructure teams usually need much more context.
They need to know:
Which workload initiated the connection?
Which process caused it?
Was that communication expected?
Which policy allowed it?
Should this flow exist at all?
That is the problem we're working on with PacketWolf at Zyvor AI Labs.
What is PacketWolf?
PacketWolf is a network intelligence and policy platform designed around modern Linux networking technologies including:
- eBPF
- Cilium
- Hubble
- Kubernetes
- KubeVirt
- Linux networking
The objective is to move infrastructure visibility beyond raw packets and IP addresses.
We want to connect:
```text id="7jv7ec"
Process
↓
Workload
↓
Network connection
↓
Destination
↓
Policy
That context changes how networking can be operated.
## Traditional network visibility stops too early
Consider a flow:
```text id="c1oq4j"
10.20.3.14:49218
↓
10.20.8.22:5432
Traditional tooling might tell us:
```text id="l09e65"
Source: 10.20.3.14
Destination: 10.20.8.22
Port: 5432
Protocol: TCP
But an engineer still needs to determine:
```text id="xry3ti"
What is 10.20.3.14?
Which application owns it?
Which process created the connection?
Why is it talking to PostgreSQL?
Is this expected behavior?
In a dynamic Kubernetes environment, even the IP address itself may be temporary.
Network intelligence therefore needs workload context.
Kubernetes changed network identity
Traditional infrastructure often treated IP addresses as relatively stable identities.
Kubernetes changed that assumption.
Pods are created and destroyed continuously.
An application might move from:
```text id="eey6h2"
10.0.1.18
to:
```text id="o2vzto"
10.0.7.43
without the application logically changing at all.
The meaningful identity isn't necessarily:
```text id="5rtylz"
10.0.7.43
It may be:
```text id="hwje0e"
namespace: payments
service: checkout
workload: checkout-api
pod: checkout-api-7f7c8
This is one reason identity-aware networking becomes so important in Kubernetes.
Cilium and eBPF
Cilium uses eBPF to provide networking, observability, and security capabilities in Linux and Kubernetes environments.
eBPF allows programs to run safely inside the Linux kernel at strategic points.
That creates powerful possibilities for observing network behavior without relying entirely on traditional packet capture.
Conceptually:
```text id="e78wsp"
Application
│
▼
Linux socket
│
▼
eBPF
│
▼
Network stack
│
▼
Network
Instead of only observing packets after the fact, we can gain context much closer to where communication originates.
## Hubble provides flow visibility
Hubble adds network observability on top of Cilium.
It can provide visibility into flows such as:
```text id="aavkxc"
frontend
│
▼
checkout-api
│
▼
payment-service
│
▼
database
This is extremely valuable.
But we think there is another layer of intelligence that can be built on top.
PacketWolf focuses on turning observed network behavior into operational answers.
From flows to relationships
A raw network flow is an event.
Infrastructure teams need relationships.
Instead of displaying thousands of entries like:
```text id="nzec31"
A → B
A → C
B → D
A → B
C → D
we want to build a model like:
```text id="meuv2z"
frontend
│
▼
checkout-api
/ \
▼ ▼
payment-api inventory
│
▼
postgres
Now the network becomes understandable as an application system rather than a stream of packet metadata.
Service maps
One of PacketWolf's core ideas is automatically building service relationships from observed communication.
A useful service map should help answer:
- Which services communicate?
- Which dependencies are new?
- Which workloads are unexpectedly exposed?
- Which destinations are external?
- Which communications disappeared?
- Which flows violate the expected architecture?
The map becomes particularly useful during incidents.
Instead of manually correlating logs across multiple systems, an operator can begin from the communication graph.
Process-to-network attribution
One of the areas we're particularly interested in is connecting network flows back to processes.
Imagine observing:
```text id="15mfvg"
VM: finance-app-04
Process: java
PID: 4821
Destination: 172.20.8.15
Port: 5432
Protocol: TCP
That is significantly more useful than:
```text id="cf3pi1"
172.20.2.41 → 172.20.8.15:5432
Now an operator has immediate application context.
This becomes valuable for:
- Incident investigation
- Security analysis
- Dependency discovery
- Migration validation
- Network policy generation
- Application modernization
What about virtual machines?
Network intelligence shouldn't stop at Kubernetes pods.
Enterprise environments contain both:
```text id="3ypdjf"
Containers
+
Virtual Machines
KubeVirt makes this especially interesting because VMs can operate alongside container workloads inside Kubernetes-managed infrastructure.
A topology could look like:
```text id="3nvl1m"
Kubernetes
│
┌───────────┴───────────┐
│ │
Pods VMs
│ │
└───────────┬───────────┘
│
Cilium
│
eBPF
│
Network fabric
The operational challenge is creating a consistent network view across both workload types.
That is one of PacketWolf's goals.
Why this matters for VM migration
Imagine migrating a VMware VM to KVM or KubeVirt.
The disk conversion succeeds.
The VM boots.
The network interface is online.
Is the migration successful?
Not necessarily.
The application might depend on:
```text id="ftzq40"
Database
LDAP
DNS
NTP
License server
Internal APIs
Message queue
External SaaS endpoint
If even one dependency is broken, the VM may be technically alive but operationally unusable.
Network intelligence can make post-migration validation much stronger.
Instead of checking only:
```text id="b8lo3m"
VM booted ✓
we can check:
```text id="vmtzbf"
VM booted ✓
Expected services reached ✓
Database dependency ✓
DNS ✓
External endpoint ✓
Unexpected traffic none
This turns networking into part of migration assurance.
## Observe first, then create policy
Network policy is powerful.
But writing policies before understanding application behavior can be dangerous.
A better workflow is:
```text id="4el8wa"
Observe
↓
Learn
↓
Model dependencies
↓
Recommend policy
↓
Review
↓
Enforce
That is much safer than immediately denying traffic based on assumptions.
AutoPolicy
PacketWolf's AutoPolicy concept is based on observed communication.
Suppose an application consistently communicates only with:
```text id="a01yb5"
frontend → api
api → postgres
api → redis
PacketWolf can use those relationships as input for a proposed network policy.
Conceptually:
```yaml id="4t9ynp"
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-policy
spec:
endpointSelector:
matchLabels:
app: api
egress:
- toEndpoints:
- matchLabels:
app: postgres
- toEndpoints:
- matchLabels:
app: redis
The important point isn't automatically generating YAML.
The useful part is understanding why those rules should exist.
Policy should be based on observed workload behavior and explicit operator review.
Unexpected communication is often the interesting communication
Suppose a service normally communicates with:
```text id="f1wfer"
database
redis
internal-api
Then suddenly it starts communicating with:
```text id="cbow0j"
unknown external IP
That difference can be more useful than another dashboard showing total network throughput.
PacketWolf can conceptually compare:
```text id="9jds8b"
Expected graph
vs
Observed graph
and surface deviations.
This becomes useful for both reliability and security.
## Network health
Network troubleshooting often begins with a vague symptom:
> The application is slow.
The cause might be:
* Packet loss
* DNS failures
* Policy drops
* Connection retries
* Service availability
* Latency
* Routing changes
* Backend instability
A network intelligence platform should connect infrastructure signals together rather than force engineers to inspect them individually.
For example:
```text id="yp5v3w"
checkout-api degraded
│
├── latency increased
│
├── postgres retries increased
│
└── network policy unchanged
That is closer to an operational answer.
Policy visibility matters too
Having a network policy does not automatically mean operators understand it.
A workload may be affected by multiple layers of policy.
What infrastructure teams often want to know is:
```text id="95csh9"
Can workload A talk to workload B?
And if not:
```text id="0xy6s1"
Why not?
The answer should ideally explain:
```text id="p4ehxz"
checkout-api
│
▼
payment-api
│
✕
Blocked by:
CiliumNetworkPolicy/payment-restricted
That is more useful than simply reporting a dropped packet.
## Infrastructure needs explainability
As infrastructure becomes more automated, explainability becomes increasingly important.
Automation shouldn't just say:
```text id="68swl6"
Denied.
It should say:
```text id="k3ma5h"
Connection denied because workload
"checkout-api" attempted TCP/5432 toward
"analytics-db", but the active egress policy
permits only "payments-db".
That turns policy into something operators can reason about.
## Security and operations are converging
Network observability used to be largely an operations concern.
Network security was handled separately.
eBPF makes that boundary much less clear.
The same network context can help answer:
### Operations
Why is the application slow?
### Security
Why is this workload communicating externally?
### Platform engineering
Which services depend on this database?
### Migration
Did the migrated VM restore all required connections?
### Architecture
What does the actual application dependency graph look like?
One source of network intelligence can support all of these workflows.
## PacketWolf and Zeus OS
PacketWolf is designed to complement **Zeus OS**.
Zeus OS answers:
```text id="1gzjgp"
What infrastructure is running?
PacketWolf answers:
```text id="mdsg4u"
How is that infrastructure communicating?
Together, the model becomes:
```text id="y5trzt"
Zeus OS
│
Infrastructure topology
│
▼
PacketWolf
│
Network topology
│
▼
eBPF + Cilium + Hubble
The combination gives infrastructure operators both resource and communication context.
The broader Zyvor stack
PacketWolf is one part of the HyperSDK platform.
```text id="prm6pa"
HyperSDK
│
┌─────────────┼─────────────┐
│ │ │
Migration Operations Network
│ │ │
hyper2kvm Zeus OS PacketWolf
GuestKit Machina
│ │ │
└─────────────┼─────────────┘
│
Kubernetes / KVM
The idea is that migration, operations, and networking shouldn't live in completely disconnected systems.
## The network should tell a story
Infrastructure produces enormous amounts of telemetry.
The challenge isn't collecting more data.
The challenge is converting it into answers.
Instead of:
```text id="zvsl3g"
2.4 million flows observed
we want infrastructure teams to see:
```text id="fakfne"
Payment service created a new external dependency.
Three migrated VMs lost connectivity to DNS.
One production workload is communicating outside its expected policy.
Database latency increased after a network path change.
That is the direction we're taking with PacketWolf.
## What's next?
We're interested in the intersection between:
* eBPF
* Cilium
* Hubble
* Kubernetes
* KubeVirt
* Virtual machines
* Network policy
* Service topology
* Process attribution
* Migration validation
because we think enterprise networking needs to become much more workload-aware.
Packets are useful.
Flows are better.
But the real goal is understanding:
> **Who communicated, why they communicated, whether they should have communicated, and what changed.**
That's the problem **PacketWolf** is being built to solve.
If you're operating Cilium, KubeVirt, or mixed VM/container infrastructure, we'd be interested in hearing what network visibility is still missing for your team.
**What is harder today: discovering dependencies, troubleshooting flows, or building correct network policies?**
**Zyvor AI Labs**
https://zyvor.dev
**HyperSDK Platform**
https://zyvor.dev
Top comments (0)