In 2026, robust cybersecurity has become indispensable as AI-powered attacks, expanding cloud and IoT footprints, and increasingly sophisticated ransomware make protecting data, infrastructure, and digital trust a foundational requirement for businesses and individuals alike.
Tomorrow on 28 May, Stephan Schroeder will attend RISEx in Frankfurt am Main to discuss the most pressing topics with other analysts and practitioners in the sector.
This week, Hari Jayaraman is on the road again, on his way to participate in MORE-IP 2026 in Amsterdam. Looking forward to meeting up with other members of the IP interconnection industry!
It’s RIPE time!
Next week, from 18-22 May, Péter Veréb-György and Ingmar Poese will be in Bonnie Scotland to attend RIPE 92. Let us know if you’d like to arrange a meeting with either (or both) of them for a wee dram and a chat about the latest developments in internet networking.
In the world of connectivity, visibility matters. Networks shift, routes change, and the effects often go unnoticed – until they don’t. That’s exactly the gap that the Connectivity Insight Initiative is setting out to close.
Inter.link and BENOCS are joining forces to publish free, practical insights about internet events, traffic patterns, and routing behaviour – all from a European perspective. The goal is simple: give the network community the intelligence it needs to make smarter networking decisions.
What does that look like in practice? Think topology changes that quietly reshape traffic flows, peering shifts between Tier 1 providers, and congestion events that degrade quality before anyone even notices. By combining Inter.link’s global IP infrastructure with BENOCS Analytics, these events become visible – and useful.
The initiative is about curating data and sharing it so the community can make better decisions. In today’s geopolitical climate, a Europen source of internet intelligence isn’t just useful; it’s essential for data sovereignty.
No paid subscription required. Just better insight for everyone.
Follow the Connectivity Insight Initiative on Substack to stay informed.
For the first time ever, BENOCS is sponsoring Peering Days!
From 23-25 March, Sales & Strategy Manager Hari Jayaraman, Interconnection Product Specialist Péter György and BENOCS Co-Founder and CTO Ingmar Poese are excited to get into discussions about peering and network visibility within the European peering community.
Psssst! There might also be some interesting news they have to tell, so pop on over to the BENOCS booth to find out. Just in case.
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.
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.
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:
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.
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.
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:
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.
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.
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.
“We would like to test BENOCS Analytics tomorrow with our live data. Is that possible?”
That’s a question we’ve often heard from interested customers who want to understand how our analytics performs on live network data, not in a generic demo.
Until now, that wasn’t easy to deliver. Our proof-of-concept deployments used the full BENOCS architecture, and while that ensured accurate results, it also meant setup times of six to eight weeks. It also required hardware procurement, exporter configuration, security configuration, and coordination between multiple teams. The outcome was reliable, but the waiting time slowed evaluation and engagement.
Now, that’s changing. We’ve built a new Kubernetes-based trial environment that allows customers to test BENOCS Analytics with their own NetFlow, BGP, SNMP, and DNS data in a standardized environment within two weeks. Each trial runs in a dedicated namespace with its own set of BENOCS pods. Rest assured, each namespace is separated from all other, keeping your data fully within the space of your test environment.
By using Kubernetes pods, BENOCS to keeps the integrity of a full deployment at a smaller scale but considerable reduces time to see results in Analytics. It’s still your data, your network, your insights but available much faster through a smarter and automated setup.
Over the past years, BENOCS Analytics has grown into a comprehensive visibility platform used by operators worldwide. But as our deployments matured, we noticed that the proof-of-concept stage became a bottleneck. Customers wanted to explore analytics capabilities sooner, while our team needed to maintain the quality and accuracy of a full deployment. We couldn’t compromise on either.
So, the question became:
“How do we make trials faster without compromising on accuracy?“
The answer came through containerization and automation. By moving the trial architecture into Kubernetes, we removed the dependency on manually provisioned systems, reduce complexity for the customer and made trials far faster to set up.
The customer connects their network via an encrypted IPsec connection. Through this all data can be exported directly via the Internet to the trial setup.
All incoming data flows into our backend structure just like any production environment, which powers BENOCS Analytics. Within a few days of setting up the data feeds, most customers see live analytics in their environment.
Kubernetes gives us the flexibility to create, move, update and decommission trial environments quickly while keeping them isolated and predictable. Each customer trial is effectively a self-contained version of BENOCS Analytics that runs on shared compute but with strict network and data separation.
By combining containerization and infrastructure-as-code, we now spin up customer trials in days instead of weeks with no compromise on security or stability.
To start a trial, here’s what we require:
NOTE: The trial is limited to certain routers. A full deployment does not need this information anymore as will pick up the entire network via IGP/BGP-LS.
Once these details are shared, our DevOps team uses automated infrastructure code to generate the customer configuration and deploy the stack. When the IPsec tunnel is up and the sufficient data has arrived to draw statisticial conclusion (usually around 48 hours), dashboards start populating automatically.
Each trial is designed to balance performance and resource efficiency. As such, trials are limited to:
This ensures consistency across customers while keeping the experience close to production quality.
The Kubernetes trial program is now ready for onboarding. Our goal is to make it effortless for you to experience BENOCS Analytics in a fast, secure, and reliable environment.
If your team has been curious about BENOCS but waiting for the right window to try it, that window just opened. Reach out to sales@benocs.com or any one of the BENOCS team to get started.
BENOCS Analytics shows where a flow leaves a network on a router (Egress Router dimension) and peer (Nexthop AS dimension) level mainly from BGP information. Our customers kept asking for one thing:
“Can we filter by the exact interface and see traffic flows?”
Yes, now you can!
Our new interface dimension lets you see both in-interface and out-interface per flow automatically, so you don’t have to trace packets manually.
This post covers why it matters, what has changed, and how BENOCS’ new interface dimension works.
In many networks, bundled/aggregated links create a neat and easy 1 Interface ↔ 1 Nexthop AS mapping. From Egress Router and Nexthop AS, you can often deduce the interface, but that’s not always the case. Take for example:
In these cases, the exact in-interface and out-interface makes a difference.
With this new feature you can:
There is a whole new interface dimension in Flow Explorer!
You can now:
This is part of the overall BENOCS Flow Analytics improvement. It is free for all our customers and users!
Interface description is now live in Border Planner, and soon support will be extended to Raw Network Analyzer (RNA).
Is this a paid add on?
No, it’s completely free.
Where else will I see it?
Interface descriptions are live in Border Planner. Support will be extended to RNA
Will it work for IXPs?
Yes, when multiple nexthop AS values share the same physical interface (common at IXPs), the feature reports the actual interface used.
The networks of ISPs change frequently: new peers are added, fresh POPs are built, migration to new hardware is undertaken, and more. Ever changing networks sometimes brings changes to the teams too like NOC shifts, peering, security and capacity planning. A network observability tool is integral to network operations to monitor and make sure traffic is flowing uninterrupted, irrespective of the changes. If the pricing of the solution changes per flow, per router, per peer or per user, then it turns normal engineering work into budget surprises and access bottlenecks.
That is why we at BENOCS adopted an alternative approach to pricing: one service fee aligned to your committed peak traffic levels, a nominal traffic fee only when traffic levels grow beyond that commitment, and, last but not least, unlimited user licenses for your organization. Another added bonus: your favourite sampling rate does not affect the price.
Cool, huh?
We provide customized pricing for each network and the pricing is determined by the complexity of your network. We collect the following network KPIs to evaluate network complexity.
Now you might wonder: how does this help us calculate network complexity? Each KPI above constitutes a dimension in our post-processed data and allow us to calculate the number of unique flows in your network. We measure traffic on the incoming side of the ingress interface on your full-table BGP router. This router could either be an edge router facing the internet or a customer-facing router. These routers are displayed in the Ingress Router dimension in the Sankey diagram of our Flow Explorer.
BGP provides us with the complete AS path of the traffic and that AS path also includes the IP address of the router from which traffic egresses (even if they don’t export flow). These routers are the total number of routers in the network and are displayed in the Egress Router dimension of the Sankey.
On either side of Ingress and Egress Router dimensions, we display both Handover and Nexthop ASes which comprise BGP-peers (usually Transit, PNIs, Peerings, CDNs and caches) and downstream networks.
When you combine these dimensions with Source ASes sending traffic to your network and Destination ASes, where traffic terminates after leaving your network, the 6-dimensional Sankey is complete.
Now the goal is to find number of unique flows and it can be best explained with an example. Using filters across different dimensions, you are able to see below a path of Netflix traffic entering via Tata as Handover and terminating into Turk Telekom via NTT.
Similarly, we are able to calculate the total number of unique flows in each network and add that to the peak traffic levels to determine complexity. Once the complexity is determined, a service fee is now provided for a peak traffic commit. Traffic fee appears on the invoice only if sustained peaks exceed the traffic commitment, because higher sustained peaks generate more flow records to ingest, enrich and store, that means: more data to process and analyze. This fee simply covers that incremental processing load when utilization genuinely grows.
You commit to 1.4 Tbps of peak traffic at the start of the contract and add two new routers in two different PoPs for resilience. If peaks stay at 1.4 Tbps, your invoice doesn’t change. If peaks sustainably move to 1.55 Tbps, you will see a small transparent traffic fee. We will recommend lifting the commitment at renewal if that level persists.
Do you want an estimate of our Analytics solution for your network?
Reach out to us at sales@benocs.com for a customized quote.
