How to Monitor Bond CNI with Vigilmon (HTTP + TCP + Alerts)

Bond CNI is a Kubernetes CNI plugin that aggregates two or more network interfaces inside a pod into a single logical bonded interface — providing link redundancy through active-backup failover, increased aggregate bandwidth through link aggregation (LACP / 802.3ad), or load balancing across multiple physical paths. It is typically paired with Multus CNI to attach secondary bonded interfaces to pods running network-intensive workloads. When Bond CNI is working correctly, the pod can sustain a link-level failure without any traffic disruption. When bonding configuration breaks or a slave interface drops without detection, the pod silently loses redundancy and the next physical link failure causes a complete pod network outage with no warning. Vigilmon adds the external perspective that Bond CNI cannot provide for itself: continuous uptime and latency checks from outside your infrastructure that keep watching even when the network bonding layer is the component that has failed. You can add your first monitor for free, no credit card required.

Why Bond CNI needs external monitoring

Bond CNI binary absence on a node causes secondary interface attachment to fail silently. Bond CNI installs as a binary in /opt/cni/bin/ on each node. After a node OS upgrade, a node re-image, or a misconfigured node provisioning pipeline, the Bond CNI binary may be absent or have incorrect permissions on one or more nodes. Pods scheduled on affected nodes receive their primary network interface from the default CNI but fail to attach the bonded secondary interface — Multus logs a CNI error but the pod starts anyway with single-interface networking. There is no Kubernetes node condition that reflects a missing CNI binary, and the pod appears healthy to Kubernetes health checks while silently running without network redundancy. An external HTTP monitor targeting a pod endpoint reachable only via the bonded secondary interface detects this attachment failure.
Single slave link failure degrades redundancy without crashing the bond. In active-backup mode, Bond CNI creates a bonded interface that remains up as long as at least one slave is active. If one physical slave interface loses link — due to a NIC firmware update, a switch port failure, or a cable issue — the bond fails over to the remaining slave and continues passing traffic. From Kubernetes' perspective, the pod is healthy, the service endpoints are populated, and all application health checks pass. However, redundancy is completely lost: the next failure of the remaining slave will cause a full pod network outage. An external HTTP monitor with a response time baseline can detect increased latency that often accompanies single-slave operation, but more importantly, a heartbeat-based bond health check can directly observe the slave count.
LACP negotiation failure in 802.3ad mode causes the bond to operate on a single link. In 802.3ad (LACP) mode, Bond CNI requires the connected switch to participate in Link Aggregation Control Protocol negotiation. If the switch LACP partner fails to respond — due to a switch configuration change, a firmware update, or an MLAG peer failure — the bond fails to aggregate and falls back to single-link operation. All traffic continues to flow on one link, but the aggregate bandwidth drops in half and the bond no longer provides the expected throughput for the workload. There is no Kubernetes event for this degradation, and application-level health checks may continue to pass until the workload's traffic load exceeds the single-link capacity. An external HTTP monitor with a throughput-sensitive response time threshold detects the capacity reduction before it causes application-level errors.
Bond mode mismatch after NetworkAttachmentDefinition update causes traffic black holes. Bond CNI reads its bonding mode (e.g. active-backup, balance-rr, 802.3ad) from the NetworkAttachmentDefinition at pod creation time. If the NetworkAttachmentDefinition is updated to change the bonding mode while existing pods are running, the running pods retain their original bonding configuration but any newly scheduled pods receive the new mode. In a mixed cluster where some pods are using active-backup and others are using balance-rr, cross-pod traffic patterns can become unpredictable and some traffic flows may be black-holed by ARP table inconsistencies. An external HTTP monitor that probes a pod reachable only via the bonded interface detects this class of traffic black hole because the response from the affected pod drops.
MII monitoring interval misconfiguration delays failover beyond application timeout. Bond CNI configures an MII (Media Independent Interface) link monitoring interval that determines how quickly the bond detects a slave link failure. The default interval in many configurations is 100ms, but if it is misconfigured to a longer interval (1000ms or more), the bond takes proportionally longer to detect a slave link failure and initiate failover. During the detection window, all traffic on the bond is lost. If the application's connection timeout is shorter than the MII detection interval, connections will be dropped before failover completes, causing application errors even in active-backup mode. An external HTTP monitor with a strict response time threshold detects this window of traffic loss as a momentary outage.

What you'll need

A running Bond CNI installation with its pods accessible via bonded network interfaces
The public hostname or IP for a Bond CNI workload endpoint, for example https://bond-cni-workload.example.com
A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose Bond CNI workload health endpoints

Verify Bond CNI is creating bonded interfaces correctly and that a workload endpoint is reachable before configuring Vigilmon monitors.

# Check that the Bond CNI binary is installed on all nodes
kubectl get nodes -o wide | awk '{print $1}' | tail -n +2 | while read NODE; do
  echo -n "Node $NODE: "
  kubectl debug node/$NODE -it --image=busybox -- ls /opt/cni/bin/bond 2>/dev/null \
    && echo "bond binary found" || echo "MISSING bond binary"
done

# Check a pod using Bond CNI has the expected bonded interface
kubectl exec -n <namespace> <bond-cni-pod> -- ip link show bond0

# Sample output:
# 5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
#     link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff

# Check bonding details including slave status
kubectl exec -n <namespace> <bond-cni-pod> -- cat /proc/net/bonding/bond0

# Sample output:
# Ethernet Channel Bonding Driver: v3.7.1
# Bonding Mode: active-backup
# Active Slave: net1
# MII Status: up
# MII Polling Interval (ms): 100
# Slave Interface: net1
#   MII Status: up
#   Speed: 10000 Mbps
# Slave Interface: net2
#   MII Status: up
#   Speed: 10000 Mbps

# Verify both slaves are in 'up' state
kubectl exec -n <namespace> <bond-cni-pod> -- \
  grep -A2 "Slave Interface" /proc/net/bonding/bond0 | grep "MII Status"

If a Bond CNI workload is exposed via NodePort or Ingress:

# Find the service endpoint for a Bond CNI workload
kubectl get svc -A | grep NodePort

# Test the HTTP endpoint
curl -I http://bond-cni-workload.example.com/health

# Expected:
# HTTP/1.1 200 OK
# content-type: application/json

# Check the bond interface from the node side
ssh <node-ip> "ip link show bond*; cat /proc/net/bonding/bond* 2>/dev/null"

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the Bond CNI workload health endpoint:

Log in to vigilmon.online and click Add Monitor.
Set Monitor type to HTTP.
Enter the URL: http://bond-cni-workload.example.com/health
Set Check interval to 60 seconds and Expected status code to 200.
Click Save Monitor — Vigilmon will run the first check within a minute.

Add a monitor with a response time threshold for throughput degradation

Bond CNI's key failure mode — single slave operation — causes latency increases before it causes outright failure. A monitor with a tight response time threshold detects this:

Click Add Monitor again.
Set Monitor type to HTTP.
Enter the URL: http://bond-cni-workload.example.com/health
Set Expected status code to 200 and Timeout to 5 seconds.
Set a Response time threshold of 1000ms — significantly below your application's expected response time in normal dual-slave operation. A sudden increase in response times relative to the established baseline indicates bond degradation.
Click Save Monitor.

Why external monitoring catches what internal checks miss

Bond CNI failures are invisible to Kubernetes until they are catastrophic. A single slave failure leaves the bond running on one link with no redundancy — Kubernetes health probes continue to pass, pod events show nothing unusual, and the operator has no indication that the next link failure will cause a complete outage. Vigilmon operates entirely outside your infrastructure, probing Bond CNI workload endpoints from external network vantage points on a fixed interval. It surfaces the traffic impact of bonding degradation — increased latency, reduced throughput, brief packet loss during failover — that application-internal checks always miss because they run on the same host and bypass the failed network path.

Step 3: Monitor Bond CNI's TCP port

A TCP monitor confirms that the Bond CNI workload is accepting connections at the network layer independent of application-level health check processing.

In Vigilmon, click Add Monitor.
Set Monitor type to TCP.
Enter Host: bond-cni-workload.example.com and Port: 80 (or the appropriate application port).
Set Check interval to 60 seconds.
Click Save Monitor.

For workloads exposed on non-standard ports via bonded interfaces, find the active ports first:

# Find services exposed by Bond CNI workloads
kubectl get svc -A -o wide | grep NodePort

# Check what the workload is listening on
kubectl exec -n <namespace> <bond-cni-pod> -- ss -tlnp

# Sample output:
# State  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port
# LISTEN 0       128     0.0.0.0:8080        0.0.0.0:*       users:(("nginx",pid=1,fd=6))
# LISTEN 0       128     0.0.0.0:9090        0.0.0.0:*       users:(("exporter",pid=12,fd=3))

Add a TCP monitor for each exposed port to independently verify connectivity to the Bond CNI workload beyond the primary monitored service port.

Step 4: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels and click Add Channel.
Choose Email and enter the address that should receive notifications (for example, network-team@example.com or an on-call distribution list).
Assign this channel to all Bond CNI monitors created in Steps 2 and 3.
Click Save — Vigilmon will send a test email to confirm delivery.

Webhook alerts

For Slack, PagerDuty, or an internal incident management system, add a webhook channel:

In Alert Channels, click Add Channel and choose Webhook.
Paste your endpoint URL (a Slack incoming webhook, PagerDuty Events API v2 endpoint, or custom URL).
Vigilmon will POST the following JSON payload when a monitor transitions to down:

{
  "monitor_id": "mon_bond_cni_health",
  "monitor_name": "Bond CNI workload /health",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T09:14:22Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "http://bond-cni-workload.example.com/health"
}

Assign all Bond CNI monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

#!/bin/bash
# Bond CNI alert runbook — run these in order when Vigilmon fires

echo "=== Pod status ==="
kubectl get pods -A | grep -i bond

echo "=== Recent events ==="
kubectl get events -A --sort-by='.lastTimestamp' | grep -i "bond\|cni\|network\|attach" | tail -20

echo "=== HTTP endpoint response ==="
curl -sv http://bond-cni-workload.example.com/health 2>&1 | tail -20

echo "=== Bond interface status (from pod) ==="
kubectl exec -n <namespace> <bond-cni-pod> -- cat /proc/net/bonding/bond0 2>/dev/null || \
  echo "Cannot read bond status — pod may be down"

echo "=== Slave interface count ==="
kubectl exec -n <namespace> <bond-cni-pod> -- \
  grep "MII Status:" /proc/net/bonding/bond0 2>/dev/null | \
  sort | uniq -c

echo "=== Network interfaces in pod ==="
kubectl exec -n <namespace> <bond-cni-pod> -- ip -s link show

echo "=== Bond CNI binary on nodes ==="
kubectl get nodes -o wide | awk 'NR>1 {print $1}' | while read NODE; do
  kubectl debug node/$NODE -it --image=busybox \
    -- ls -la /opt/cni/bin/bond 2>/dev/null && echo "OK: $NODE" || echo "MISSING: $NODE"
done

echo "=== Port connectivity ==="
nc -zv bond-cni-workload.example.com 80

echo "=== Multus attach logs ==="
kubectl logs -n kube-system -l app=multus --tail=50 | grep -i "bond\|error\|fail" | tail -20

echo "=== Node link status ==="
for NODE in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
  echo "=== $NODE ==="
  kubectl debug node/$NODE -it --image=busybox -- ip link show 2>/dev/null | grep -E "bond|net[0-9]"
done

Step 5: Create a public status page

A Vigilmon status page gives your platform engineering team and application developers a single URL to check Bond CNI workload health during incidents — no cluster access required.

In Vigilmon, navigate to Status Pages and click New Status Page.
Give it a name such as Bond CNI Network and choose a subdomain like bond-cni-status.vigilmon.page.
Add all monitors created in this tutorial: the /health HTTP monitor, the response time threshold HTTP monitor, and the TCP port monitor.
Optionally add a description explaining that Bond CNI provides link redundancy for network-intensive workloads and that a monitor alert may indicate degraded redundancy before a complete outage.
Click Publish — the page is immediately accessible and updates in real time.

Share this URL in your team's incident response runbook and link it from your NFV or high-throughput application documentation. When engineers see unexplained latency increases or packet loss in bonded pod workloads, the status page is the first place to check whether Bond CNI bonding is operating with full redundancy.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | http://bond-cni-workload.example.com/health | HTTP | Bond failure, both slaves down, pod not-ready, CNI attachment failure | | http://bond-cni-workload.example.com/health (response time) | HTTP | Single slave degradation, LACP fallback, throughput reduction | | bond-cni-workload.example.com:80 | TCP | Network-level connectivity loss, port-level bond failure |

# Quick-reference diagnostic one-liners when a Vigilmon alert fires

# 1. Is the workload pod running?
kubectl get pods -A | grep <bond-cni-workload>

# 2. Is the health endpoint responding?
curl -sf http://bond-cni-workload.example.com/health || echo "Health check FAILED"

# 3. How many bond slaves are active?
kubectl exec -n <namespace> <bond-cni-pod> -- \
  grep -c "MII Status: up" /proc/net/bonding/bond0 2>/dev/null

# 4. What is the active slave?
kubectl exec -n <namespace> <bond-cni-pod> -- \
  grep "Active Slave:" /proc/net/bonding/bond0 2>/dev/null

# 5. What bonding mode is configured?
kubectl exec -n <namespace> <bond-cni-pod> -- \
  grep "Bonding Mode:" /proc/net/bonding/bond0 2>/dev/null

# 6. Is port 80 open?
nc -zv bond-cni-workload.example.com 80 && echo "Port open" || echo "Port CLOSED"

# 7. Are there any CNI attachment errors in recent events?
kubectl get events -A | grep -i "cni\|attach\|bond" | tail -10

# 8. Is the Bond CNI binary present on the node hosting this pod?
NODE=$(kubectl get pod -n <namespace> <bond-cni-pod> \
  -o jsonpath='{.spec.nodeName}')
kubectl debug node/$NODE -it --image=busybox -- ls /opt/cni/bin/bond 2>/dev/null

What's next

Heartbeat monitoring for bond slave health — Configure a Kubernetes CronJob that reads /proc/net/bonding/bond0 in the target pod and verifies that all expected slave interfaces are in MII Status: up state, then POSTs a heartbeat to a Vigilmon dead-man's-switch endpoint. If the slave count drops below the expected value, the heartbeat stops and Vigilmon fires an alert — catching the single-slave-down scenario before the next link failure causes a complete outage.
SSL certificate monitoring — If your Bond CNI workload exposes an HTTPS endpoint, Vigilmon can alert you days before the TLS certificate expires. Add an SSL monitor pointing at the same hostname to avoid unexpected TLS failures that disconnect clients before the bond itself has a chance to fail.
Latency trend monitoring — Use Vigilmon's response time history to establish a latency baseline for your Bond CNI workload endpoint. An abrupt doubling of response time — consistent with a failover from dual-link aggregate bandwidth to single-link operation — is often the first detectable signal of bond degradation, appearing before any traffic loss and well before an alert from a threshold-based monitor would fire.

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.