Sniffer distributed architecture

Distributed Architecture: Client-Server and Mirroring Modes

This guide explains how to deploy VoIPmonitor in distributed architectures using client-server mode, packet mirroring, and hybrid configurations.

Overview

VoIPmonitor sniffers can be deployed in multiple architectural patterns:

• Standalone mode: Single instance capturing and analyzing traffic
• Client-Server mode: Multiple clients sending CDRs to central server
• Mirroring mode: Forwarding raw packets to another instance
• Hybrid mode: Combining mirroring with client-server (workaround)

Architecture Diagrams (PlantUML)

Standard Architectures

Multiple Clients to Single Server (Recommended)

This is the standard and fully supported architecture for distributed deployments.

Configuration:

On each client (A, B, C):

server_destination = central.server.ip
server_destination_port = 60024
server_password = shared_secret

On central server:

server_bind = 0.0.0.0
server_bind_port = 60024
server_password = shared_secret

Important notes:

• All clients and the server must use the same server_password
• Clients do not store CDRs to MySQL (they only send to server)
• Server stores all CDRs to MySQL database
• PCAP files are stored on clients by default

Packet Mirroring

Mirror mode forwards raw network packets from one sniffer to another.

<syntaxhighlight> Sensor A ──(packets)──→ Sensor B </syntaxhighlight>

Configuration:

On source sensor A:

mirror_destination = sensor.b.ip
mirror_destination_port = 5090

On receiving sensor B:

mirror_bind = 0.0.0.0
mirror_bind_port = 5090

Use cases:

• Forwarding packets from appliances without VoIPmonitor
• Port mirroring / SPAN to VoIPmonitor instance
• Distributed packet capture with central analysis

Hybrid Chain Configuration (Workaround)

However, a workaround exists using mirroring combined with client mode:

<syntaxhighlight> A (mirror) ──(packets)──→ B (mirror_bind + server_destination) ──(CDRs/packets)──→ C (server) </syntaxhighlight>

Scenario 1: CDR Forwarding

In this configuration, the intermediate sniffer (B) analyzes packets and forwards only CDRs to the central server.

Sensor A (source):

mirror_destination = sensor.b.ip
mirror_destination_port = 5090

Sensor B (intermediate):

mirror_bind = 0.0.0.0
mirror_bind_port = 5090
server_destination = central.server.ip
server_destination_port = 60024
packetbuffer_sender = no

Central Server C:

server_bind = 0.0.0.0
server_bind_port = 60024

Result:

• B analyzes packets from A
• B stores PCAP files locally
• B sends only CDRs to C
• C stores CDRs in MySQL and knows PCAPs are on B

Scenario 2: Packet Forwarding

The intermediate sniffer forwards raw packets instead of CDRs.

Sensor B (intermediate):

mirror_bind = 0.0.0.0
mirror_bind_port = 5090
server_destination = central.server.ip
server_destination_port = 60024
packetbuffer_sender = yes

Result:

• B forwards raw packets from A+B to C
• C analyzes all packets and stores PCAP files
• C stores CDRs in MySQL

Compression for Mirroring

When using mirror mode, compression can reduce network bandwidth:

packetbuffer_compress = yes
packetbuffer_compress_ratio = 100
max_buffer_mem = 2000

Adjust packetbuffer_compress_ratio if CPU becomes a bottleneck.

GUI Visibility

Automatic visibility:

• Client-server mode: Only the central server appears in GUI
• Hybrid chain: Only the final server (C) and intermediate forwarder (B) appear

Manual sensor registration:

If you want sensor A to appear in GUI (for RRD charts, remote upgrades):

1. Go to GUI → Settings → Sensors
2. Add sensor A manually with its manager_ip:manager_port
3. Ensure manager_aes_key and manager_aes_iv match GUI database values

Performance Optimization

Client-Server Mode for Better Performance

Switching from standalone to client-server architecture can significantly improve MySQL insert performance:

1. Centralized writes: Single server instance handles all MySQL inserts (reduces lock contention)
2. Enable mysql_enable_set_id: Let application handle ID auto-increment instead of MySQL
3. Optimize MySQL configuration: Tune innodb_flush_log_at_trx_commit, innodb_io_capacity, etc.

Migration steps:

1. Configure server: Set server_bind, server_bind_port, server_password
2. Initially set mysql_enable_set_id = no on server
3. Migrate sniffers one by one: Set server_destination, remove mysqlhost
4. After all sniffers migrated: Enable mysql_enable_set_id = yes on server and restart

SRTP/DTLS Decryption in Mirror Mode

When using mirror mode, ensure SSL/TLS decryption is configured correctly:

On source sniffer (with mirror_destination):

sipport = 5060,5061

This ensures TCP packets (including TLS handshakes) are also mirrored.

On receiving sniffer (with mirror_bind):

Configure SSL decryption options here:

ssl_ipport = ...
ssl_sessionkey = ...

Important Limitations

Key limitations:

1. server_bind and server_destination cannot coexist in one instance
2. Hybrid chain architecture is unstable across sniffer versions
3. No per-client authentication (same password for all clients)
4. Recommended: Use standard multiple clients → single server architecture

Future Enhancement (VS-1605)

A future release may support native dual-mode operation with these new options:

# Server mode (receive connections)
server_bind = 0.0.0.0
server_bind_port = 60024
server_bind_password = receive_secret

# Client mode (send to upstream)
server_destination = upstream.ip
server_destination_port = 60025
server_destination_password = send_secret

# Enable both modes
server_dual_mode = yes

This would enable clean multi-tier architectures without workarounds.

AI Summary for RAG

Summary: This guide explains how to deploy VoIPmonitor in distributed architectures using standalone, client-server, packet mirroring, and hybrid chain topologies. It documents how multiple remote sensors can send data to a central server, how mirror mode forwards raw packets between sniffers, and how a workaround combines mirroring with client mode to build multi-tier chains. The article clarifies where CDRs and PCAPs are stored in each scenario, how sensors appear in the GUI, how to manually register sensors, and how to optimize MySQL and VoIPmonitor configuration when migrating to client-server mode for better performance. It also covers SRTP/DTLS decryption in mirror mode, current limitations (such as lack of dual-mode server/client in one process), and a proposed future enhancement (VS-1605) that would enable clean multi-hop deployments without workarounds. Keywords: distributed architecture, client-server mode, mirror mode, hybrid chain, remote sensor, CDR forwarding, packet mirroring, packetbuffer_sender, compression, MySQL performance, SRTP, DTLS, GUI sensors, manager_ip, scalability, multi-site monitoring Key Questions:

• How do I connect multiple VoIPmonitor sensors to a single central server using client-server mode?
• When should I use packet mirroring instead of sending only CDRs from remote sensors?
• How are CDRs and PCAP files stored and accessed in client-server versus hybrid chain configurations?
• What are the limitations of combining server_bind and server_destination in a single sniffer instance?
• How can I optimize MySQL and VoIPmonitor settings when migrating from standalone to client-server architecture?
• How do I ensure that all sensors are visible in the GUI and correctly registered for remote management?
• What are the current constraints and future plans (VS-1605) for native multi-tier VoIPmonitor deployments?