nettools

English | 中文

A suite of network diagnostic tools developed by Baidu's physical network black-box monitoring team, including: - bitflip: Detects packet loss and bit-flip errors in large-scale physical networks. - bitflip6: IPv6 variant of bitflip for IPv6 network diagnostics. - baize: Configuration-driven continuous network quality monitoring tool for long-term deployment. - kuiniu: GPU NIC interconnect probing tool for AI training clusters — symmetric RoCEv2/UDP probing across GPU pairs, with role=both single-process dual-role deployment. - lidar: TCP SYN probing tool for network reachability detection — no server-side deployment required. - mping: Multi-target ICMP Echo ping tool with CIDR expansion, DNS resolution, hardware timestamping, and packet corruption detection. - mping6: IPv6 variant of mping for ICMPv6 Echo probing with packet corruption detection. - evr: VXLAN-based EVR device probing tool — embeds the real EVR src IP in the payload so reflected probes can be matched back without a 5-tuple key. - traceroute: Hop-by-hop path probing tool with ICMP/UDP/TCP probes, concurrent multi-TTL and multi-target probing, and per-hop RTT/loss stats — no server-side deployment required. All packet encode/decode goes through goscapy.

Produced by Baidu System Department

Installation

curl -fsSL https://nettools.rpcx.io/install.sh | sh

Or install to a specific directory:

BINDIR=~/.local/bin curl -fsSL https://nettools.rpcx.io/install.sh | sh

Or build from source:

make build

bitflip

A high-frequency UDP probing tool for network bit-flip (packet corruption) and packet loss detection. Supports unidirectional loss and corruption detection — both client-side (round-trip) and server-side (one-way from client to server).

How it works: The client sends a large volume of UDP packets per second to the server, which echoes them back unchanged. Both sides independently detect issues:

• Client side (round-trip): Detects packet loss and bit-flip on the full round-trip path. If a packet was dropped in either direction, it is counted as loss. If bit-flip is detected in the returned payload, the five-tuple is logged.
• Server side (one-way): Detects packet loss and bit-flip on the client-to-server direction only. Each packet carries the client's actual send count and starting port pair for the previous time window; the server uses these to compute one-way loss and reconstruct the complete set of expected port pairs — enabling per-five-tuple loss identification without tracking client state. The server auto-registers unknown clients on first packet — no pre-configuration required.

By comparing client-side and server-side loss, you can determine whether loss occurs on the forward path (client → server) or the return path (server → client).

Quick Start

Build:

make build

Run server (on the remote host):

# Simplest — auto-detects local IP
./bitflip

# With explicit IP
./bitflip -r server -s <server_ip> -c <client_ip>

Run client (on the local host):

# -c auto-detected if empty, -s is required
./bitflip -r client -s <server_ip>

# With explicit IPs
./bitflip -r client -c <client_ip> -s <server_ip>

Command-line Flags

Examples

# Server side — auto-detect, no need to specify -c
# Server auto-registers unknown clients on first packet
./bitflip

# Client side
sudo ./bitflip -r client -s 10.0.0.2

# Client with custom rate and duration
sudo ./bitflip --role client --server-addr 10.0.0.2 --rate 10000 --duration 60s

# Client with verbose loss port details
sudo ./bitflip -r client -s 10.0.0.2 --verbose

# Server with verbose loss port details (per-five-tuple loss)
./bitflip -s 10.0.0.1 --verbose

Bit-flip Detection

The client sends packets padded with 4 salt patterns, selected by seq % 4:

The server uses the same 4 salt patterns to validate packets, ensuring accurate identification of which bytes have been flipped.

Packet Format

+----------+----------+-----------+---------------+------------------+------------------+----------+
| Magic(8) | Seq(8)   | Ts(8)     | LastSent(4)   | LastSrcPort(2)   | LastDstPort(2)   | Salt(N)  |
+----------+----------+-----------+---------------+------------------+------------------+----------+

• Magic: 8-byte magic flag identifier
• Seq: 8-byte sequence number
• Ts: 8-byte nanosecond timestamp
• LastSent: 4-byte previous span send count
• LastSrcPort: 2-byte previous span starting source port
• LastDstPort: 2-byte previous span starting destination port
• Salt: N-byte padding data (for bit-flip detection)

Through this compact protocol design, the server can reconstruct every port pair from the previous span using (LastSrcPort, LastDstPort, LastSent) and the deterministic GetNextPorts algorithm — enabling server-side unidirectional loss detection with per-five-tuple granularity, without the server needing to track client-side send state.

bitflip6

IPv6 variant of bitflip. Usage is identical to bitflip, with IPv6 addresses:

# Server side
./bitflip6

# Client side
sudo ./bitflip6 -r client -s fd00::2

mping

A multi-target ICMP Echo ping tool for batch network quality inspection. Supports CIDR range expansion, DNS hostname resolution, hardware timestamping (Linux), high-rate probing, and packet corruption detection. mping6 is the IPv6 variant.

Key features: - CIDR expansion: Pass a network prefix (e.g. 10.0.1.0/24) and mping automatically expands to all host addresses. IPv6 supports /112–/128 prefixes with a --max-targets safety cap. - DNS resolution: Pass hostnames and mping resolves them automatically (A records for mping, AAAA for mping6). - Hardware timestamps: Enabled by default on Linux via SO_TIMESTAMPING for nanosecond latency accuracy. Falls back to software timestamps on macOS. - Rate control: Built-in token bucket rate limiter for precise per-target pps control. - Multi-target: Comma-separated IPs, CIDR ranges, and DNS hostnames can be mixed freely. - Packet corruption detection: Detects bit-flip errors in ICMP reply payloads by embedding known salt patterns in each probe packet.

Quick Start

Build:

make compile

Run:

# Single target (default 100 pps)
sudo ./mping -T 10.0.0.2

# Multiple targets
sudo ./mping -T 10.0.0.2,10.0.0.3,10.0.0.4

# CIDR range — probe entire /24
sudo ./mping -T 10.0.1.0/24

# DNS hostname
sudo ./mping -T www.example.com

# High rate for 30 seconds
sudo ./mping -T 10.0.0.2 -r 1000 -d 30s

# IPv6
sudo ./mping6 -T fd00::2

Command-line Flags (mping)

mping6 has the same flags with IPv6 equivalents (e.g. --tc instead of --tos, --hlim instead of --ttl).

See mping usage guide for more details.

baize

A configuration-driven continuous network quality monitoring tool for long-term deployment. Unlike bitflip's command-line flag approach, baize uses a JSON config file and supports running both Client and Server in a single process.

Key features: - Config-driven: All parameters managed via JSON config file, easy for automated deployment. - Single-process dual-role: Run Client and Server together in one process. - Log rotation: Built-in daily log rotation with automatic cleanup of expired files and symlink to the latest log. - pprof integration: Built-in Go pprof HTTP server for runtime profiling. - Graceful shutdown: Listens for SIGINT/SIGTERM and gracefully shuts down all goroutines.

The internal version of baize used in Baidu's physical network also supports periodically pulling configuration from a database and pushing data to Kafka for aggregation. The open-source version is simplified to use config files only and output to logs by default, but provides interfaces for custom implementations.

Use Cases

• Inter-cluster high-frequency probing: Continuous monitoring between large-scale clusters; high-frequency probing (default 5000 pps) quickly exposes intermittent packet loss; multi-port coverage of ECMP paths for pinpointing faulty links.
• LCC datacenter probing: Cross-LCC datacenter network quality monitoring; configuration-driven deployment across multiple datacenter nodes.
• ADC/DC network migration monitoring: Continuous monitoring during network equipment cutover and upgrades; before/after quality comparison to quantify migration impact; automatic detection of packet loss and corruption introduced by changes.
• Dedicated line monitoring: Carrier dedicated line quality monitoring; real-time alerts for loss and latency anomalies; data support for SLA evaluation.
• Failback verification: Network quality verification after traffic failback from disaster recovery; confirming no packet loss or bit-flip on the failback path.
• Ad-hoc point-to-point monitoring: Temporary end-to-end probing for troubleshooting; minimal configuration to get started (only requires both IPs); easy to stop after verification.

Quick Start

Build:

go build -o baize ./cmd/baize/

Create a config file (e.g., baize.json):

{
  "pprof_addr": ":6060",
  "log_dir": "/var/log/baize",
  "log_max_age_days": 7,
  "client": {
    "client_addr": "10.0.0.1",
    "server_addrs": "10.0.0.2",
    "rate_in_span": 5000,
    "span": "1s",
    "delay": "3s",
    "msg_len": 1024,
    "tos": 64
  },
  "server": {
    "server_addr": "10.0.0.2",
    "client_addrs": "10.0.0.1",
    "rate_in_span": 5000,
    "span": "1s",
    "delay": "3s",
    "msg_len": 1024,
    "tos": 64
  }
}

Run:

# Use default config file (baize.json)
sudo ./baize

# Specify config file path
sudo ./baize -c /etc/baize/baize.json

Config Reference

Top-level fields:

Client/Server fields:

See baize usage guide for more details.

kuiniu

A GPU NIC interconnect probing tool for AI training clusters. Probes RoCEv2/UDP