Telemetry Direction Conventions
Before diving into concepts like upload/download, ingress/egress, and inbound/outbound, it helps to understand the four traffic types that can appear in a Netify flow. In flow telemetry, this type classification is recorded in the other_type property and describes the nature of the endpoint on the other side of the conversation. The other_type can have the following values:
- remote
- Traffic exchanged with an endpoint on the Internet.
- local
- Traffic between devices within a private network or local network directly attached to the Netify Agent.
- broadcast
- Traffic sent to the network broadcast address and received by all devices on the local segment.
- multicast
- Traffic sent to a multicast group address and received by devices that have joined that group.
Flow Attribute - other_type
Flow telemetry - and some aggregated telemetry - represents each conversation using two perspectives: local and other . These labels describe network location, not which side initiated the session (that topic is discussed below).
The local side represents an endpoint with an IP address on the local monitored network. The other side represents the peer endpoint, which may be a remote Internet host, a broadcast address, a multicast group, or even another device on the same local network. The following examples illustrate how these designations appear in different types of flows.
With these facts in mind, let's turn back to the topic of the other_type attribute.
Remote
This is a typical remote connection seen on a network behind a NAT gateway. The local_ip is a mobile phone on the network fetching information from a Spotify server on the public other_ip : 35.186.224.38.
This flow record captures a brief HTTPS session between a local client (192.168.88.115) and the remote Spotify service.
Remote Flow
"detected_protocol_name": "HTTP/S",
"host_server_name": "gue1-dealer.g2.spotify.com",
"local_bytes": 1807,
"local_ip": "192.168.88.115",
"local_mac": "c2:54:46:ae:90:ab",
"local_origin": true,
"local_packets": 7,
"local_port": 44750,
"other_bytes": 1906,
"other_ip": "35.186.224.38",
"other_mac": "44:39:c4:8f:0d:92",
"other_packets": 7,
"other_port": 443,
"other_type": "remote",Local
This record captures a DNS request occurring between two devices on the same internal network. A client at 192.168.88.2 queried a caching DNS server at 192.168.4.1 for the domain image-cdn-ak.spotifycdn.com . Because both IPs reside within the private 192.168.0.0/16 range, the designations of local and other are functionally arbitrary.
In this pairing, the DNS server happens to be assigned to the local slot, while the requesting client occupies the other slot. Since the other_type is marked as local , it confirms this dialogue remained entirely within the local network.
Local Flow
"detected_protocol_name": "DNS",
"host_server_name": "image-cdn-ak.spotifycdn.com",
"local_bytes": 299,
"local_ip": "192.168.4.1",
"local_mac": "44:39:c4:8f:0d:92",
"local_origin": false,
"local_packets": 1,
"local_port": 53,
"other_bytes": 87,
"other_ip": "192.168.88.2",
"other_mac": "60:e3:27:4a:a4:30",
"other_packets": 1,
"other_port": 42635,
"other_type": "local",Broadcast
This flow record captures a DHCP Discover request from a Pixel 7 mobile device. Because the device does not yet have an assigned identity, it uses the placeholder 0.0.0.0 address to broadcast a 346-byte request to the universal destination 255.255.255.255 on UDP Port 67.
The use of the ff:ff:ff:ff:ff:ff broadcast MAC ensures every device on the local segment receives the request, searching for an active DHCP server to provide an IP lease. Since this is an initial "shout" into the network, the other_packets count remains at zero until a server responds with an "Offer" packet to complete the handshake.
Broadcast Flow
"detected_protocol_name": "DHCP",
"host_server_name": "pixel-7",
"local_bytes": 346,
"local_ip": "0.0.0.0",
"local_mac": "c2:54:46:ae:90:ab",
"local_origin": true,
"local_packets": 1,
"local_port": 68,
"other_bytes": 0,
"other_ip": "255.255.255.255",
"other_mac": "ff:ff:ff:ff:ff:ff",
"other_packets": 0,
"other_port": 67,
"other_type": "broadcast",Multicast Flow
This flow captures a Multicast DNS (mDNS) service discovery event initiated by a mobile client at 192.168.4.28. The device broadcast a 218-byte payload to the reserved IPv4 multicast group 224.0.0.251 (mapped to the special multicast MAC 01:00:5e:00:00:fb) on UDP port 5353.
The transmission advertises the _spotify-connect._tcp.local pointer, signaling that the device is actively polling the local network segment for compatible Spotify Connect endpoints. Because mDNS operates on a "request-response" model over multicast, this outbound announcement acts as a trigger; any compatible speakers or receivers on the network will respond via independent flows to establish the handoff for media playback.
Multicast Flow
"detected_protocol_name": "MDNS",
"host_server_name": "_spotify-connect._tcp.local",
"local_bytes": 218,
"local_ip": "192.168.4.28",
"local_mac": "e8:61:7e:27:33:ab",
"local_origin": true,
"local_packets": 1,
"local_port": 5353,
"other_bytes": 0,
"other_ip": "224.0.0.251",
"other_mac": "01:00:5e:00:00:fb",
"other_packets": 0,
"other_port": 5353,
"other_type": "multicast",Telemetry Direction
With the knowledge of other vs local , we can now tackle the concept of direction. Of course, different terminology is used in different situations:
- upload/download
- ingress/egress
- inbound/outbound
Some of the aggregator flow telemetry uses upload/download because these are serving a specific type of deployment. For example, Aggregator Type 2 is used to audit uploads and downloads on a network edge deployment.
Upload/Download
This flow was collected on an office network - we're at the edge of the Internet.
It shows a download from local_ip @ 192.168.88.115. 5982 bytes was sent from this IP, while 133457 bytes was sent from other_ip @ 15.235.48.55. From the context of being on the office network:
- local-to-other is an upload to the Internet
- other-to-local is a download from the Internet
Flow Direction: Upload/Download
"detected_protocol_name": "HTTP/S",
"host_server_name": "download.netify.ai",
"local_bytes": 5982,
"local_ip": "192.168.88.115",
"local_mac": "c2:54:46:ae:90:ab",
"local_origin": true,
"local_packets": 53,
"local_port": 51106,
"other_bytes": 133457,
"other_ip": "15.235.48.55",
"other_mac": "44:39:c4:8f:0d:92",
"other_packets": 95,
"other_port": 443,
"other_type": "remote",Inbound/Outbound
This flow was collected on a download.netify.ai mirror - we're on a server that we manage in the cloud. And yes, of course we run Netify on it!
It shows a connection to the download server on local_ip @ 15.235.48.55. 12743 bytes was sent from this IP, while 2532 bytes was sent from other_ip @ 135.23.176.13 - the client downloading a file from the server. In this context:
- local-to-other is outbound from the download server
- other-to-local is inbound to the download server
We don't really use upload/download terminology in this context. And in an environment where AWS charges egregious egress fees, it's important to get things right.
Flow Direction: Inbound/Outbound
"detected_protocol_name": "HTTP/S",
"host_server_name": "download.netify.ai",
"local_bytes": 12743,
"local_ip": "15.235.48.55",
"local_mac": "fa:16:3e:b2:ac:7b",
"local_origin": false,
"local_packets": 15,
"local_port": 443,
"other_bytes": 2532,
"other_ip": "135.23.176.13",
"other_mac": "fa:16:3e:f6:6a:19",
"other_packets": 11,
"other_port": 58291,
"other_type": "remote",Flow Origin
The other_x and local_x designations do not indicate a flow's "client" and "server". To determine which side of a flow started the conversation, consult the local_origin field. When this field is true, it indicates that the local endpoint started transmitting first. When false, the opposite endpoint started the flow.
In this example, the flow originated from 192.168.4.105.
Flow Origin
"local_origin": true
"local_ip": "192.168.4.105",
"local_bytes": 2434,
"other_type": "remote",
"other_ip": "31.13.80.53",
"other_bytes": 6139Configuration Optimization
At the beginning of this document, we defined the other_type to be local when:
Traffic between devices within a private network or local network directly attached to the Netify Agent.
What do we mean by "local network directly attached to the Netify Agent"? If you have the Netify Agent monitoring traffic on a WAN connection with public IP 11.11.11.11/24, any flows to the upstream router at 11.11.11.1 or any neighboring 11.11.11.x IP are still local.
In some scenarios, the Netify agent needs to know what should be considered local. The network configuration provides a way to identify local networks using public IPs. This is recommended when the agent is:
- configured as a network tap
- monitoring traffic in the cloud or at an ISP