BackendSide sFlow Collector & Analyzer

1. Overview

BackendSide sFlow Collector & Analyzer is a Windows desktop application that listens for sFlow v5 datagrams from your network devices and presents the data as a rich, browser-based analytics platform — no cloud required, no agents to deploy on managed hosts, no subscriptions.

The application has two main components running side-by-side:

• UDP Collector — listens on a configurable IP and port (default 0.0.0.0:6343) for sFlow v5 packets from switches, routers, and hypervisors
• Web Server — a built-in server that serves the analytics interface to any browser on your network, over HTTPS on port 8443 by default (with HTTP available on 8080)

All collected flow data is stored in isolated per-agent databases inside your Windows user profile. Data is retained in a rolling 8-hour window and is available for querying across four time horizons: 5 minutes, 15 minutes, 1 hour, and 1 day.

2. Quick Start

3. Server Setup & Configuration

All server settings are managed from the Settings page inside the application. No config files need to be edited manually.

3.1 sFlow Collection — IP & Port

The sFlow collector is a UDP listener that receives sFlow v5 datagrams from your network devices.

• Collection IP — the Settings page lists all IP addresses currently assigned to your Windows machine (all network interfaces). Select the IP that your switches will send sFlow traffic to. Choose 0.0.0.0 to listen on all interfaces simultaneously.
• Collection Port — the UDP port the collector listens on. Default is 6343 (the IANA-assigned sFlow port). Change this only if your devices export to a non-standard port.

3.2 Web Server — IP & Port

The embedded web server delivers the analytics interface to browsers on your network.

• Web Server IP — select from the list of available system IPs, or choose 0.0.0.0 to accept connections on all interfaces. Restricting to a specific IP limits access to clients reachable via that interface only.
• Web Server Port — the TCP port browsers connect to. Choose any available port. Common choices are 8080 (HTTP) or 8443 (HTTPS). If SSL is enabled the browser will connect via HTTPS.

3.3 SSL / HTTPS Setup

HTTPS is on by default. On first run the application generates a self-signed certificate and serves the dashboard over HTTPS on port 8443, with plain HTTP available on 8080 — so you get an encrypted connection with no setup and no external certificate purchase.

Using your own certificate

3.4 Applying Configuration Changes

After changing any IP, port, or SSL setting, click the "Restart Server" button. The application will:

1. Stop the current UDP collector and web server
2. Apply the new configuration
3. Restart both services on the new IP/port

Flow data already collected is not lost during a restart. In-memory buffers are flushed to storage before the restart completes.

4. Logging In

The analytics interface requires authentication. Navigate to https://<ip>:8443 and you will be redirected to the login page if no valid session exists.

• The first login creates the administrator account — no default credentials ship with the application, so set a strong password on first use.
• Enter your username and password and click Log In.
• A session cookie (sessionid) is set on successful login and is valid until you log out or the session expires.
• To log out, click the Logout link in the navigation sidebar.

5. Dashboard

The Dashboard is the home page and provides a real-time overview of all traffic seen from the selected sFlow agent.

Agent Selector

The dropdown at the top of every page lists all sFlow agents (devices) that have sent data to the collector. Select an agent to view analytics for that specific device. The first agent is selected automatically on page load.

Summary Cards

Five cards update in real-time for the selected time window:

Dashboard Charts

• Traffic Over Time — time-series line chart of bytes/packets per interval
• Top Sources — bar chart of the top 10 source IPs by byte volume
• Top Destinations — bar chart of the top 10 destination IPs
• Protocol Distribution — pie chart of TCP vs UDP vs ICMP vs other
• Top Talker Pairs — bar chart of the top source↔destination conversation pairs

Time Window

Use the time selector (5m / 15m / 1h / 1d) to change the analysis window. All cards and charts update immediately. The 5-minute view gives the sharpest picture of current activity; the 1-day view shows long-term trends.

6. Traffic Analytics

The Traffic page has six tabs, each providing a different lens on your network traffic. Select your agent and time window at the top — all tabs respond to the same selection.

Conversations

A ranked table of every unique source IP ↔ destination IP pair observed, sorted by total bytes. Each row shows bytes, packets, flow count, top protocol, and first/last seen timestamps. Click any row to drill into the individual flows that make up that conversation.

Top Sources

Ranks all source IP addresses by outbound byte volume. Click a source IP to see a drill-down showing which destination IPs that host was talking to and on which protocols.

Top Destinations

Ranks all destination IPs by inbound byte volume. Drill down to see which source IPs were sending traffic to each destination.

Top Talkers

A bidirectional view combining sent and received bytes per host — useful for identifying the highest-impact endpoints regardless of direction.

Protocols

Protocol distribution shown as both a pie chart (share of total traffic) and a stacked bar chart (volume over time per protocol). Covers TCP, UDP, ICMP, and other IP protocols.

Applications / Ports

Maps destination port numbers to well-known application names (HTTP/80, HTTPS/443, DNS/53, RDP/3389, SMB/445, SMTP/25, SSH/22, etc.) and ranks them by traffic volume. Identifies what applications are consuming bandwidth on your network.

7. VLAN Intelligence

The VLAN page requires that your sFlow-exporting devices include VLAN tags in their sFlow samples (most managed switches do this by default).

VLAN Summary

A table listing every VLAN ID observed in the sFlow data, with total bytes, packets, flow count, and the top host for each VLAN. Quickly see which VLANs carry the most traffic.

Inter-VLAN Matrix

A colour-coded matrix where each cell shows the traffic volume between a pair of VLANs. Darker cells indicate higher traffic. Use this to:

• Verify that VLAN separation policies are being enforced
• Identify unexpected cross-VLAN flows (possible misrouting or security policy violations)
• Understand inter-VLAN routing load on your core switch or firewall

Priority / QoS

Shows the distribution of 802.1p CoS (Class of Service) priority bits across all observed frames. Priority values range from 0 (best-effort) to 7 (network control). Use this to verify that:

• Voice traffic (typically priority 5–6) is correctly marked
• Video conferencing (typically priority 4–5) is separated from bulk data
• Network control traffic (priority 7) is not being misused

VLAN Heatmap

A time-of-day × VLAN grid showing traffic intensity for each VLAN across 24 hours. Useful for capacity planning — identify which VLANs peak at which times of day and whether peaks overlap in ways that stress your uplinks.

8. Interface Analytics

Interface data is derived from the ifIndex values in sFlow samples. Your switch must be configured to include interface counters in sFlow exports for full utilisation data.

Top Interfaces

Ranks all switch interfaces (by ifIndex) by total bytes, packets, and flow count. Instantly see which ports are busiest and which are idle.

Utilisation

Shows each interface as a percentage of its configured speed, displayed as a horizontal progress bar:

• Green — under 60% utilisation
• Amber — 60–85% utilisation (approaching capacity)
• Red — above 85% utilisation (potential bottleneck)

Use this view to proactively identify congested uplinks before users notice performance problems.

VM Traffic

Separates traffic on virtual interfaces (hypervisor vSwitches, VMware virtual NICs, OVS ports) from physical interfaces. This is especially useful in environments where VMware ESXi or Hyper-V is configured to export sFlow from the virtual switch — you can distinguish east-west VM-to-VM traffic from north-south physical traffic.

9. Security Detection

Security detection is derived entirely from sFlow data — no separate IDS probe or SPAN port required. A Threat Overview page summarises everything currently firing, with dedicated pages per family:

• Flood & DoS — SYN, ICMP, UDP, ACK/RST and HTTP floods, IP fragmentation attacks, and LAND attacks (spoofed identical source/destination). Each indicator lists source→destination, packet counts, last-seen and a severity tier.
• Amplification & Reflection — Memcached, DNS, NTP, SSDP, LDAP, SNMP and CharGen reflectors, with thresholds sized by real-world amplification factor and a reflector→victim table showing response counts and average sizes.
• Port scan / reconnaissance and Layer 2 / ARP threats (ARP scanning, spoofing, flooding, MAC flapping, duplicate IP) — the latter covered in the Layer 2 section below.

Each detector carries three severity tiers (Medium / High / Critical), and you can tune thresholds and email-notification levels per detector on the Alert Settings page.

Port Scan Detection

Identifies hosts that contact an unusually high number of distinct destination ports within the selected time window. This pattern is characteristic of automated port scanners and reconnaissance tools.

• Threshold — configurable on the page. Lower values catch slow scans; higher values reduce false positives for legitimate servers (e.g. load balancers). Default: 100 distinct ports.
• Results table — shows scanner IP, number of distinct ports hit, targeted destination hosts, protocols used, and first/last seen timestamps.
• Action — use the source IP to locate the scanning device on your network and investigate whether it is a legitimate scanner (Nmap, vulnerability scanner) or a compromised host.

SYN Flood Detection

Monitors TCP SYN vs SYN-ACK ratios. A large imbalance (many SYNs, few SYN-ACKs) indicates a SYN flood — either an inbound DDoS or a misconfigured/compromised internal host.

• Results table — shows attacker IP, target IP, SYN rate, SYN:SYN-ACK ratio, severity score, and duration.
• Severity — scored based on SYN rate and ratio; helps prioritise which events need immediate attention.
• Action — for external SYN floods, consider upstream filtering or rate-limiting. For internal sources, isolate the host and investigate for malware.

10. Performance Monitoring

Baseline Deviation

Compares the current traffic rate for each source/destination against a computed rolling baseline. Hosts or flows that deviate significantly from their normal rate are flagged.

• Positive deviation (traffic spike) — possible DDoS ingress, backup job, bulk transfer, or application failure
• Negative deviation (traffic drop) — possible link failure, device down, or application crash

The table shows the host IP, its baseline rate, its current rate, the percentage deviation, and a direction indicator.

Sequence Gaps

sFlow agents include a sequence number in each datagram. This view analyses sequence numbers per agent to detect gaps (missed datagrams). Gaps indicate:

• The network path between agent and collector is dropping UDP packets
• The sFlow agent on the switch is overloaded (high CPU/buffer overflow)
• The collector machine was temporarily unable to process all incoming datagrams

If you see persistent sequence gaps, consider increasing the sFlow sampling interval on the sending device, or moving the collector to a closer network segment.

11. Anomaly Detection & Baselines

Rather than asking you to guess a threshold for every network, the anomaly detector learns what each agent's traffic normally looks like — per hour of the week, with an overall baseline as a fallback — and scores every minute against it.

Learning-only mode

Adaptive baseline detection ships in learning-only mode: from first run it studies live traffic and records what it would have flagged, without raising alerts. Review those findings on the Anomaly Detection page, then switch it to raising alerts under Alert Settings → Adaptive baseline detection when you're ready. The hour-of-week baselines need roughly two weeks to mature, so on networks with a strong day/night rhythm it is worth waiting.

What the page shows

• Adaptive baseline — per-metric table (bytes/minute, flows/minute) with the expected value now, the normal swing, how many minutes have been learned, a ready/learning status, and how many hours of the week have been seen.
• Flow volume per minute — each bar is one minute; bars well above the period's own average are highlighted as a quick visual read.
• IP entropy over time — sudden drops or spikes in source-IP entropy often indicate scanning or DDoS.
• Flow-rate anomaly — flows/min plotted against the rolling expected rate.

12. Alerting, Email & Notifications

One alert, not one per check

A condition that keeps firing updates an occurrence count and a last-seen time on the existing alert, instead of adding a new row on every poll. If the condition worsens, the alert is raised to the new severity and marked unread again, so real escalations aren't buried. The grouping window is configurable (default 15 minutes).

Alert History & the notification bell

• Alert History — a filterable log (severity, type, agent, read/unread) where each alert carries first-seen, last-seen and occurrence counts; open a row for its detail, and mark individual or all alerts read.
• Notification bell — a live bell in the sidebar shows the unread count and previews recent alerts.

Email notifications

On the Alert Settings page, configure how alert emails are delivered:

• Provider — custom SMTP, Gmail, or SendGrid; enter the host/port/encryption and credentials, then use Save & send test email to confirm delivery.
• Cooldowns & digest — a minimum time between repeat emails for the same alert (with a shorter cooldown for critical alerts), and an optional digest mode that batches one summary per interval instead of an email per alert.
• Thresholds — per-detector Medium / High / Critical thresholds and the email-notification level for each, plus poll interval and alert retention.

13. Host Watch

The Host Watch page live-monitors a set of IP and MAC addresses you choose — useful for keeping an eye on critical servers, gateways or suspect devices separately from the general top-talker rankings. Add the addresses you care about and the page tracks their activity as new flow data arrives.

14. Layer 2 & ARP Analytics

The Layer 2 page is the most comprehensive component of BackendSide sFlow Collector, with ten tabs dedicated to ARP and MAC-layer intelligence. ARP data is extracted directly from sFlow-sampled Ethernet frames — no separate ARP inspection or SPAN configuration is needed beyond your standard sFlow export.

ARP Spoof Detection — How It Works

The detector flags two patterns:

• One IP, multiple MACs — two or more different MAC addresses are claiming the same IP address. Typical of ARP poisoning where an attacker is redirecting traffic to their NIC.
• One MAC, multiple IPs — a single MAC address is responding to ARP requests for multiple different IP addresses. Typical of a MITM tool or a misconfigured multi-address interface.

New MAC Detection — Use for Rogue Devices

Every MAC address seen for the first time (within the current data window) is logged with its first-seen timestamp, IP address, and VLAN. You can use this as a lightweight NAC (Network Access Control) visibility tool — any unexpected MAC appearing on a VLAN you don't manage warrants investigation.

Host History — Forensic Investigation

Enter an IP address to retrieve a full timeline of every MAC address that IP has been bound to, with timestamps. This is invaluable when investigating incidents: you can trace exactly when a device moved, changed its MAC, or was replaced.

15. Multi-Agent Management

BackendSide sFlow Collector supports unlimited sFlow agents simultaneously. Every device that sends sFlow datagrams to the collector is automatically discovered and added to the agent list.

• Agent dropdown — available on every analytics page. Select the device you want to analyse.
• Per-agent databases — each agent stores its data in a separate, isolated database named after its IP address, inside your Windows user profile. This prevents data mixing and makes individual backups trivial.
• Rolling retention — each agent database retains 8 hours of flow data. Older records are pruned automatically.
• No configuration needed — as soon as a new device starts sending sFlow to the collector IP:port, it appears in the dropdown.

16. Tips & Best Practices

sFlow Sampling Rate

sFlow works by sampling 1-in-N packets. Common rates are 1:512, 1:1024, or 1:2048. Lower rates (e.g. 1:128) give higher accuracy but increase CPU load on the switch and UDP bandwidth to the collector. Start with 1:512 on a 1 Gbps link and adjust based on collector load.

Polling Interval

Interface counter polling interval (separate from packet sampling) is typically set to 30–60 seconds. Shorter intervals give more precise utilisation data but increase sFlow overhead.

Firewall Rules

Ensure the following ports are open on the Windows machine running the collector:

• UDP inbound on the sFlow collection port (default 6343) — from all sFlow agent IPs
• TCP inbound on the web server port — from all client browser IPs

Browser Compatibility

The analytics interface is tested on current versions of Chrome, Firefox, Edge, and Safari. JavaScript must be enabled. The interface is responsive and works on tablets but is optimised for desktop use.

Dark / Light Theme

Click the theme toggle button in the top-right corner of any page to switch between dark and light mode. Your preference is remembered by your browser and persists across sessions.

Data Not Appearing?

• Verify your switch is configured to export sFlow to the correct collector IP and port
• Check Windows Firewall is not blocking inbound UDP on the collection port
• Confirm the sFlow version on your device is v5 (v1/v2/v4 are not supported)
• Check the collector status indicator in the application — it shows whether the UDP listener is active
• Use a packet capture (Wireshark) on the collector machine to verify sFlow datagrams are arriving on the expected port