Tag: network analytics

Unlocking full network visibility

Red and black logo of Mobicom, featuring a stylized abstract shape and the brand name in lowercase letters.

How Mobicom discovered 50% hidden traffic with BENOCS Analytics

About Mobicom

Mobicom Networks is a group company of Mobicom Corporation and Mongolia’s pioneer and largest mobile network operator, serving over 1.7 million subscribers across one of the world’s least densely populated countries. Established in 1996 as a joint Mongolian Japanese venture, Mobicom has been part of the KDDI Corporation Group since 2016. With network coverage spanning 95% of Mongolia’s territory, Mobicom delivers comprehensive telecommunications services including cellular communications, international connectivity (IEPL, IPLC), IP wholesale, Transmission lease service and datacenter services. Mobicom Networks operates three international PoP routers located in Hong Kong, Frankfurt, and Tokyo, providing transit connectivity between Mongolia, Asia, and Europe.

Red and black logo of Mobicom, featuring a stylized abstract shape and the brand name in lowercase letters.

The Challenge: Operating with blind spots

Operating a nationwide mobile network in Mongolia presents unique challenges, but one critical issue that troubled Mobicom’s network was much closer to home, sitting right inside their own network infrastructure. Like many telecommunication operators, they deployed cache servers from throughout their network to deliver popular content directly to subscribers. These cache servers reduce bandwidth costs and improve user experience by serving content locally rather than through expensive international transit or private network interconnect (PNI) links.

However, their existing network monitoring solution had a significant blind spot. The respective solution is fundamentally built for security monitoring, specifically DDoS detection and mitigation. Because of this, it provides no visibility into traffic served by internal cache servers. These platforms focus on traffic entering and exiting the network at peering and transit points and generally do not collect NetFlow or IPFIX data from internal cache servers, since those servers sit inside the operator’s premises and don’t require the same level of DDoS scrutiny. The reasoning is sound from a security perspective, but this approach had unintended consequences for traffic engineering and business intelligence.

The impact was severe: Mobicom’s network operations team couldn’t see a substantial portion of their network traffic. They had no way to monitor cache performance, identify capacity constraints, understand subscriber behavior, or troubleshoot cache-related issues. Infrastructure investment decisions were being made based on incomplete data, and when subscribers reported streaming problems, the team had no visibility into whether cache servers were functioning properly.

Solution

What Mobicom needed was a solution built for comprehensive network intelligence, not just security monitoring. Enter BENOCS Analytics: Operational within Mobicom’s network since 2025, BENOCS now provides complete end-to-end network visibility, including the previously invisible cache infrastructure. The key differentiator is its ability to collect and analyze a multitude of protocols (Flow, BGP, SNMP, DNS and IGP) from the entire network, including cache servers within internal network infrastructure. It provides a fundamentally different approach to traffic analysis through its multi-dimensional Sankey visualization. The Sankey allows network operators to understand traffic flows across multiple dimensions simultaneously:

  • Source and destination ASNs, including content providers
  • Ingress and Egress routers and interfaces
  • Source and Destination subnets and IP-ports
  • Protocol and Service types
  • Applications and Services
50%
traffic visibility increase
2
caches added

Implementation

BENOCS worked with Mobicom’s team to configure all protocol exports (Flow, BGP and SNMP) from all critical network elements. The key to revealing cache traffic was understanding that content provider caches are deployed in different ways across operator networks, each requiring different identification methods.

Different types of cache deployments:

Caches with BGP Peering Sessions – Some content providers deploy caches that establish full BGP peering sessions with the operator’s network. These caches export BGP routes with their own AS numbers, making them automatically identifiable through standard BGP AS-Path analysis. BENOCS ingests the BGP data and identifies traffic from these caches based on the AS number in the routing table.

Caches without BGP Sessions – Many caches are deployed without establishing BGP sessions, as devices sitting inside the operator’s network. For these deployments, identification relies on interface naming conventions in SNMP descriptions. BENOCS can assign Pseudo-AS numbers based on agreed naming patterns (like “Akamai-Cache-01”) in the interface. This allows operators to track cache traffic even when caches don’t participate in BGP routing.

Private ASN Configuration – Some operators configure Private ASNs (AS64512-AS65534 range) within their own routing infrastructure to break out cache traffic, mobile gateways, or enterprise networks. These Private ASNs are learned automatically through BGP routing just like public ASNs, providing seamless identification without requiring pseudo-AS configuration.

Network analysis visualization showing data flow and volume share across various caches.
All cache traffic (relative in %)

Through these identification methods, BENOCS Analytics successfully revealed cache infrastructure from Facebook within Mobicom’s network. Using BENOCS Analytics’ six-dimensional Sankey visualization, Mobicom could finally see traffic flows from all content provider caches through their network infrastructure to customer segments across different regions and time periods.

Results and benefits

When BENOCS Analytics became fully operational and cache visibility was enabled, comparing the three months before to three months after revealed a stunning discovery.

Network traffic volumes increased by 50% and by 70% during peak hours.

This wasn’t because subscribers suddenly consumed more data, but it was simply invisible in their previous monitoring solution. All this traffic flowing through Mobicom’s network had been completely hidden from operational view.

With complete visibility, Mobicom gained transformative insights:

  • Cache efficiency visibility: Analysis revealed an impressive 1:3 ratio between transit and cache traffic, i.e. for every 100G total traffic, 75G of traffic was served from local caches directly to subscribers. This demonstrated that 75% of content delivery was being handled locally, although some caches required cache-fill traffic of 25%, which lowers the total cache efficiency.
  • Proactive capacity management: The team could identify when cache infrastructure was approaching capacity limits and coordinate with content providers to address utilization bottlenecks. This prevented customer experience issues before they occurred.
  • Data-driven operations: Capacity planning and infrastructure decisions could now be based on complete traffic volumes rather than partial data. Lead time to resolution improved drastically when diagnosing performance issues.
  • Content provider collaboration: Mobicom was able to have data-driven conversations with Facebook about cache performance, traffic localization and capacity planning. These discussions were now supported by precise traffic measurements and utilization metrics.
Graphical representation of network data showing Google cache fill ratio and volume share metrics.
After deploying BENOCS Analytics and adding all the caches, we discovered our traffic volumes grew by 50%. We had been operating with half our network traffic completely invisible. Facebook, Google and other content delivery caches were serving massive amounts of traffic without any visibility. The six-dimensional Sankey along with the time series revealed that cache servers were peaking at very high utilization during certain hours. More importantly, this visibility enabled us to identify high-usage content that wasn’t being cached locally. We requested and installed Valve and CDN77 caches based on this analysis, which significantly reduced our overseas traffic and resulted in substantial cost savings. Now we can monitor cache performance proactively, make informed capacity planning decisions, and work with content providers on optimization. This complete visibility has transformed our operations.
Headshot of a woman with long hair, wearing a dark top, smiling softly against a light background.
Bolortuya Erdenesuren
IP Planning Senior Engineer
Mobicom

Recent improvements

Building on this success, Mobicom is working with BENOCS to implement the Application Identifier module, which analyzes DNS cache misses from their DNS resolvers to identify specific applications delivered through all CDNs. This DNS-based correlation will enable Mobicom to see which CDNs are being used to deliver applications, like Disney+, TikTok, Amazon Prime etc. into their network, providing application-level intelligence that complements their existing network-level visibility.

Conclusion

Mobicom’s journey from having 50% of their network traffic invisible to achieving complete end-to-end visibility demonstrates a fundamental truth: you cannot effectively operate, troubleshoot or optimize infrastructure you cannot see.

With BENOCS Analytics’ intelligent cache identification methods and comprehensive network intelligence, Mobicom now has complete visibility of their network, enabling proactive management, accurate capacity planning, and better service delivery.

For telecommunications operators facing similar challenges surrounding incomplete network visibility, especially concerning content delivery infrastructure, Mobicom’s experience offers a clear lesson: security-focused monitoring tools excel at protecting network perimeters, but comprehensive network intelligence requires purpose-built solutions that reveal the complete picture of your network operations.

APRICOT 2026

Cityscape of Jakarta with modern skyscrapers, featuring the text "APRICOT 2026, 9-11 February, Jakarta" at the bottom.

Third time’s a charm!

For the third year in a row, Hari and Stephan, together with our partner Sean from MarvelTec Ltd, will be on site from 9-11 February in Jakarta. APRICOT has become one of our favourite conferences in the yearly calendar, and the guys are looking forward to good conversations around traffic visibility, network analytics, and the real-world challenges of operating and scaling networks at regional and global scale.

We also can’t wait to see our customers, partners and friends from the APAC region, whom we don’t get to see all that often!

If you’re attending APRICOT, come say hi. We’d love to chat about your network, your data, and what’s top of your priority list right now.

NL-ix Late Summer Drink

In the background a pier at the beach with a ferris wheel at the end of it. The text reads: NL-IX Late Summer Drink, Sep 11, Scheveningen. At the bottom is the BENOCS logo.

Sun, sea, and… networking.

On September 11, Hari and Stephan will be at the beach in Scheveningen, for the annual NL-ix Late Summer Drink. Always a great chance to catch up with peers, exchange ideas, and enjoy the unique mix of seaside vibes and serious conversations about networks.

If you’re around, come say hi and join us for a beer. We’d love to chat about traffic visibility, peering, and what’s next for network analytics.

Why your flow data might be lying to you (and how to fix it)

A graph showing a discrepancy between the flow data (pink) and the green SNMP line

In theory, flow data should give us a nice, accurate view of what’s happening in our network. In reality, there’s a big elephant in the room: you never really know if the data you’re getting is complete. Flow exports are typically sent using UDP, and that means there are no guarantees. If a packet doesn’t make it to your collector – too bad, it’s gone.

For people who depend on flow data for analytics, capacity planning, security, and troubleshooting, that’s not just annoying; it’s dangerous. And most of the time, neither the user nor the collector has a way to detect if something’s missing.

Where the flow can fail

We often hear: “Well, if my collector drops packets, I’ll know about it.” True – most collectors can log packet loss. And while the network in between could theoretically drop packets, in our experience, that’s rarely the bottleneck.

The real troublemaker? The exporter. That’s the router or switch generating the flows in the first place.

If the exporter silently drops flow data due to an internal issue, like a full buffer, nobody notices. Not the user. Not the collector. You just end up working with incomplete data, drawing the wrong conclusions, and maybe even alarming or scaling unnecessarily. The worst part? This often happens gradually as traffic grows, long after the initial configuration was done.

The good news: it’s fixable

There are specific configuration parameters you can tweak to make flow exports more reliable and insightful. Here’s what matters most:

1. Sampling rate

This defines how many packets the router skips before recording one. A lower number means better accuracy.

  • 1:1000 is a solid recommendation from us. It balances visibility into smaller flows with the router’s resource limits. With this, you can spot flows down to 1 Mbps or even less.
  • A 1:1 sampling rate (every packet counted) gives you perfect insight, but comes with a cost: your router needs more memory. And guess what happens if the buffer overflows? Yep – data loss.

2. Inactive timeout

This defines how long the exporter waits without seeing new packets for a flow before it sends it out. We recommend 15 seconds. It keeps the buffers clean and prevents long-hanging flows from clogging up the memory.

2. Active timeout

This is the maximum duration a flow is kept “open” before being sent, even if new packets keep arriving.

If your analytics work in 5-minute buckets, this is crucial. If you use the vendor default (often 1800 seconds or more!), flows will straddle multiple buckets and make your data messy. We recommend 60 seconds to ensure clean aggregation.

How to check for flow generation failures

Most major vendors give you tools to see if you’re dropping flow records at the source:

  • Nokia: show router flow-export statistics
  • Juniper: show services flow-monitoring statistics
  • Cisco: show flow exporter statistics
  • Huawei: display netstream statistics export

Check these regularly, especially if traffic volume has changed recently.

Recommended config summary

Parameter Recommended value Why it matters
Sampling rate 1:1000 Balanced accuracy and router performance
Inactive timeout 15 seconds Flush idle flows quickly to free buffer
Active timeout 60 seconds Clean 5-minute time buckets, avoid overflow

Vendor config quirks

Each vendor has their own flavor of config:

  • Nokia: Look for sampling, active-timeout, inactive-timeout under flow-export
  • Juniper: Uses flow-monitoring and export-profile definitions
  • Cisco: Classic NetFlow or Flexible NetFlow; keep an eye on buffer size
  • Huawei: NetStream config; especially check active/inactive timeouts

Always validate configs against your version’s documentation.

Avoid redundant sampling

If you’re sampling on both ingress and egress interfaces, you’re doing double the work (and seeing double the data!). We recommend ingress-only. It’s the earliest point you can capture a flow, and it prevents duplication.

Ditch the default

Default configurations are not your friend. They are built for generic scenarios and not optimized for the accurate, actionable analytics we all depend on.

Take the time to check, tweak, and validate your exporter configuration. The benefits will ripple through the whole system: from better performance monitoring to more accurate security insights.

How monitoring tools can lead you astray (and why BENOCS won’t)

A graph showing the difference between daily average values and daily traffic peaks

When monitoring your network traffic, you rely on tools to provide precise, actionable data. But what if some tools “lie” – not out of malice, but due to hidden methodologies that mask the truth? Let’s uncover how certain practices can lead to inaccurate traffic analyses.

The pitfall of long time periods, or how bucket size influences data analysis

A common discrepancy arises from how monitoring tools handle data over extended time periods. In order to be analysed, data first needs to be divided into buckets: the volume of traffic flowing through a network, measured in bytes, is collected in groups in order to process it. A bucket size is determined by time, so the size of the bucket is the amount of time in which the traffic data was collected, e.g. 5 minutes, 60 minutes, 24 hours, etc. Generally speaking, the smaller the bucket size, the more accurate the data analysis possible, for reasons which will follow.

Many tools use larger bucket sizes for long-term queries, which aggregate data into broader averages. For example, data might be processed on a daily basis (24 hours). While this might simplify storage and traffic visualization, it often leads to inaccurate, lower traffic values, masking critical peaks and underestimating actual usage. In other words, traffic peaks that would otherwise have been visible are averaged out, leading to smaller average values. 

This perceived accuracy can result in:

  • Bad forecasting of capacity needs: Decisions based on underestimated traffic values can lead to insufficient resources, causing bottlenecks during peak times.
  • Missed critical events: Outages or traffic shifts that create temporary spikes might be hidden, leading to incomplete analyses.
Overcoming these challenges: how BENOCS tells you the whole story

At BENOCS, we’ve designed our system to ensure you always have a clear and accurate picture of your network traffic. Here’s how we address these issues:

  1. User-centric design: We work closely with users to understand their requirements. Long-term queries are often used for capacity management, where maximum utilization is critical. Additionally, in cases of outages, the traffic shifts must also reflect the maximum traffic seen during such events. As a result, BENOCS Analytics shows by default what the user expects: the maximum peak of any given day.
  2. Transparency: BENOCS displays the bucket size and aggregation method directly in the time series. 
  3. You’re in the driver’s seat: We give users full control to adjust the parameters of their network’s traffic collection to suit their specific needs at any particular time. In our close collaboration with our users, we have seen use cases for various aggregation methods, so are dedicated to giving our users the ability to easily adapt their chosen parameters on the fly.
The BENOCS advantage

We want to bring network analytics to everybody – from network engineers to marketing teams. For this reason, we identified the most expected behavior of these graphs as crucial default behavior. At the same time, we ensure transparency by displaying how these values are derived, leaving no room for guesswork, and enable our users to make adjustments to these default settings if necessary. This ensures that BENOCS users:

  1. see what they expect to see,
  2. understand what BENOCS did, and
  3. can customize as needed.

By combining intuitive defaults, transparency, and flexibility, BENOCS delivers the tools you need for accurate and actionable insights into your network.

Interested in a demo? Let us know!

Request a demo of BENOCS Analytics