TELESPHERA

FlowSphera 1.7.0 release notes

sFlow v5. (+9 more changes)

14 October 2026
  • sFlow v5. Switches, firewalls and Linux hosts that send sFlow are received on UDP 6343 (FT_SFLOW_PORT; sFlow sent to the NetFlow port is recognised as well). The compiled core 1.4.0 decodes the sampled packet headers (Ethernet with VLAN tags, IPv4, IPv6 with extension headers, TCP / UDP / ICMP), sums the samples per minute and interfaces into flows and scales them by the sampling rate; lost datagrams are counted from their sequence numbers. Tested against pmacct's sFlow probe: within 0.5 % of the bytes actually transferred at 1:20 sampling.
  • Interface counters. The counters an sFlow agent sends are kept (90 days). Settings → Devices → Interfaces shows each port's in / out load with its share of the speed, the speed, the state, errors and discards — ports without sampled traffic included.
  • Connect a device: sFlow instructions for Fortinet, Cisco Nexus, Juniper, Huawei, Arista, HPE Aruba (new), VyOS / EdgeOS, Linux (hsflowd, pmacct) and Other, on the sFlow port: switches sample incoming traffic on every port; a router or firewall doing NAT samples its LAN side in both directions, not the WAN (checked on a FortiGate: on the WAN sFlow sees the public address, not the inside host). On a FortiGate with FortiAPs in tunnel mode sFlow sees Wi-Fi only as the access point's CAPWAP traffic, so the form recommends NetFlow v9 there for per-host traffic.
  • Detections that count sessions (port scans, password guessing) see only the sampled part of sFlow traffic; floods, bursts and IP reputation work as with NetFlow. A device should send either NetFlow / IPFIX or sFlow to FlowTrack, not both (the traffic would count twice).
  • Installer: the sFlow port when free, opened in ufw / firewalld with the others, in the summary and the configuration; an upgrade prints how to open it.
  • Path analysis: a device that sends data without a description no longer breaks the page (it is named by its address).
  • Who connects to whom inside the network. Traffic between inside hosts is kept client -> server: the host that started the session (by the ports: the server is on a well-known port, otherwise on the lower one) and the server with its service port, both directions of the session in one conversation. Upload = what the client sent to the server, download = what the server answered — before, every inside record counted as upload of its sender, so the Internal view showed no download at all, and a server's answers were named by the client's random port ("TCP other" instead of SSH, SMB …). Flows → Internal: clients on the left, the servers they connect to on the right, both directions in the ribbons; Top conversations show client, server, sent and answered.
  • Connections per host. Top hosts → Internal: what each host sent and received, how many inside hosts it connected to (→) and how many connected to it (←) — a host that suddenly reaches many others is how malware spreads (also in the CSV export).
  • Records stored before the upgrade are turned client -> server once, after the first full hour on the new version (the collector log says when; the per-hour usage and pre-aggregated tables are summed again for that period). The lateral-scan detection is unchanged: it still judges each probe by its own packets.
  • Charts: the sparklines of the Internal view no longer count inside traffic twice; Unique hosts counts both ends.