Sniffer distributed architecture: Difference between revisions

From VoIPmonitor.org
(Update to modern Client-Server architecture with packetbuffer_sender, mark mirror_destination as legacy)
(Add compression (server_type_compress) and failover documentation, link to Sniffer_configuration, improve diagram, streamline AI Summary)
Line 35: Line 35:
rectangle "Remote Sensor A" as A
rectangle "Remote Sensor A" as A
rectangle "Remote Sensor B" as B
rectangle "Remote Sensor B" as B
rectangle "Central Server" as S
rectangle "Central Server\n(server_bind)" as S
database "MySQL" as DB
database "MySQL" as DB


A -down-> S : encrypted TCP/60024
A -down-> S : encrypted TCP/60024\n(zstd compressed)
B -down-> S : encrypted TCP/60024
B -down-> S : encrypted TCP/60024\n(zstd compressed)
S -right-> DB : CDRs
S -right-> DB : CDRs


Line 82: Line 82:
# ... other sniffer options
# ... other sniffer options
</syntaxhighlight>
</syntaxhighlight>
=== Connection Compression ===
The client-server channel supports compression to reduce bandwidth usage:
<syntaxhighlight lang="ini">
# On both client and server (default: zstd)
server_type_compress = zstd
</syntaxhighlight>
Available options: <code>zstd</code> (default, recommended), <code>gzip</code>, <code>lzo</code>, <code>none</code>
=== High Availability (Failover) ===
Remote sensors can specify multiple central server IPs for automatic failover:
<syntaxhighlight lang="ini">
# Remote sensor configuration with failover
server_destination = 192.168.0.1, 192.168.0.2
</syntaxhighlight>
If the primary server becomes unavailable, the sensor automatically connects to the next server in the list.


== Local Processing vs Packet Mirroring ==
== Local Processing vs Packet Mirroring ==
Line 133: Line 155:
* Each sensor requires a unique <code>id_sensor</code> (< 65536)
* Each sensor requires a unique <code>id_sensor</code> (< 65536)
* Time synchronization (NTP) is critical for correlating calls across sensors
* Time synchronization (NTP) is critical for correlating calls across sensors
* Maximum allowed time difference between client and server: 2 seconds (configurable via <code>client_server_connect_maximum_time_diff_s</code>)
For a complete reference of all client-server parameters, see [[Sniffer_configuration#Distributed_Operation:_Client/Server_&_Mirroring|Sniffer Configuration: Distributed Operation]].


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' VoIPmonitor v20+ uses Client-Server architecture for distributed deployments. Remote sensors connect to a central server via encrypted TCP (port 60024). Two modes are available: Local Processing (<code>packetbuffer_sender=no</code>) where sensors analyze packets locally and send only CDRs, or Packet Mirroring (<code>packetbuffer_sender=yes</code>) where sensors forward raw packets to the central server for processing. CDRs are always stored centrally; PCAPs are stored on remote sensors in Local Processing mode or centrally in Packet Mirroring mode. The legacy <code>mirror_destination</code>/<code>mirror_bind</code> approach is superseded by the modern Client-Server mode.
'''Summary:''' VoIPmonitor v20+ uses Client-Server architecture for distributed deployments with encrypted TCP connections (port 60024, zstd compression). Two modes: Local Processing (<code>packetbuffer_sender=no</code>) analyzes locally and sends CDRs, Packet Mirroring (<code>packetbuffer_sender=yes</code>) forwards raw packets. Supports failover with multiple server IPs. CDRs stored centrally; PCAPs on sensors (Local Processing) or centrally (Packet Mirroring).
'''Keywords:''' distributed architecture, client-server, server_destination, server_bind, packetbuffer_sender, local processing, packet mirroring, remote sensors, central server, multi-site, encrypted channel
'''Keywords:''' distributed architecture, client-server, server_destination, server_bind, packetbuffer_sender, local processing, packet mirroring, remote sensors, failover, encrypted channel, zstd compression
'''Key Questions:'''
'''Key Questions:'''
* How do I connect multiple VoIPmonitor sensors to a central server?
* How do I connect multiple VoIPmonitor sensors to a central server?
Line 142: Line 167:
* Where are CDRs and PCAP files stored in distributed mode?
* Where are CDRs and PCAP files stored in distributed mode?
* What is packetbuffer_sender and when should I use it?
* What is packetbuffer_sender and when should I use it?
* How do I configure remote sensors to send raw packets to central server?
* How do I configure failover for remote sensors?

Revision as of 22:48, 4 January 2026


This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture using the modern Client-Server mode.

Overview

VoIPmonitor v20+ uses a Client-Server architecture for distributed deployments. Remote sensors connect to a central server via encrypted TCP channel.

Mode What is sent Processing location Use case
Local Processing CDRs only Remote sensor Multiple sites, low bandwidth
Packet Mirroring Raw packets Central server Centralized analysis, low-resource remotes

The mode is controlled by a single option: packetbuffer_sender

For comprehensive deployment options including on-host vs dedicated sensors, traffic forwarding methods (SPAN, GRE, TZSP, VXLAN), and NFS/SSHFS alternatives, see VoIPmonitor Deployment & Topology Guide.

Client-Server Mode

Architecture

Configuration

Remote Sensor (client): 

id_sensor               = 2                    # unique per sensor
server_destination      = central.server.ip
server_destination_port = 60024
server_password         = your_strong_password

# Choose one:
packetbuffer_sender     = no     # Local Processing: analyze locally, send CDRs
# packetbuffer_sender   = yes    # Packet Mirroring: send raw packets

interface               = eth0
sipport                 = 5060
# No MySQL credentials needed on remote sensors

Central Server: 

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

mysqlhost               = localhost
mysqldb                 = voipmonitor
mysqluser               = voipmonitor
mysqlpassword           = db_password

# If receiving raw packets (packetbuffer_sender=yes on clients):
sipport                 = 5060
# ... other sniffer options

Connection Compression

The client-server channel supports compression to reduce bandwidth usage: 

# On both client and server (default: zstd)
server_type_compress = zstd

Available options: zstd (default, recommended), gzip, lzo, none

High Availability (Failover)

Remote sensors can specify multiple central server IPs for automatic failover: 

# Remote sensor configuration with failover
server_destination = 192.168.0.1, 192.168.0.2

If the primary server becomes unavailable, the sensor automatically connects to the next server in the list.

Local Processing vs Packet Mirroring

Local Processing Packet Mirroring
packetbuffer_sender no (default) yes
Packet analysis On remote sensor On central server
PCAP storage On remote sensor On central server
WAN bandwidth Low (CDRs only) High (full packets)
Remote CPU load Higher Minimal
Use case Standard multi-site Low-resource remotes

PCAP Access in Local Processing Mode

When using Local Processing, PCAPs are stored on remote sensors. The GUI retrieves them via the central server, which proxies requests to each sensor's management port (TCP/5029).

Firewall requirements:

  • Central server must reach remote sensors on TCP/5029
  • Remote sensors must reach central server on TCP/60024

Data Storage Summary

  • CDRs: Always stored in MySQL on central server
  • PCAPs:
    • Local Processing → stored on each remote sensor
    • Packet Mirroring → stored on central server

GUI Visibility

Remote sensors appear automatically when connected. To customize names or configure additional settings:

  1. Go to GUI → Settings → Sensors
  2. Sensors are identified by their id_sensor value

Legacy: Mirror Mode

Note: The older mirror_destination/mirror_bind options still exist but the modern Client-Server approach with packetbuffer_sender=yes is preferred as it provides encryption and simpler management.

Limitations

  • All sensors must use the same server_password
  • A single sniffer cannot be both server and client simultaneously
  • Each sensor requires a unique id_sensor (< 65536)
  • Time synchronization (NTP) is critical for correlating calls across sensors
  • Maximum allowed time difference between client and server: 2 seconds (configurable via client_server_connect_maximum_time_diff_s)

For a complete reference of all client-server parameters, see Sniffer Configuration: Distributed Operation.

AI Summary for RAG

Summary: VoIPmonitor v20+ uses Client-Server architecture for distributed deployments with encrypted TCP connections (port 60024, zstd compression). Two modes: Local Processing (packetbuffer_sender=no) analyzes locally and sends CDRs, Packet Mirroring (packetbuffer_sender=yes) forwards raw packets. Supports failover with multiple server IPs. CDRs stored centrally; PCAPs on sensors (Local Processing) or centrally (Packet Mirroring). Keywords: distributed architecture, client-server, server_destination, server_bind, packetbuffer_sender, local processing, packet mirroring, remote sensors, failover, encrypted channel, zstd compression Key Questions:

  • How do I connect multiple VoIPmonitor sensors to a central server?
  • What is the difference between Local Processing and Packet Mirroring?
  • Where are CDRs and PCAP files stored in distributed mode?
  • What is packetbuffer_sender and when should I use it?
  • How do I configure failover for remote sensors?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Sniffer_distributed_architecture&oldid=6628"