BGP Is for Routing, Not Monitoring
by January 4, 2017

Filed under: Networking Technology

BGP, the border gateway protocol, is a creaky old network routing protocol. It was updated last in 2006, but it still serves a useful purpose. Almost every packet that traverses the internet finds its way from source to destination via BGP routing. This is what BGP was designed for, and while it’s not always the fastest route, it can divert around problems automatically. Using OSPF (open shortest path first) methods, packets are moved like rail cars across the internet, avoiding sections of track that aren’t currently passable.

The Wrong Tool for the Job

But where problems arise is that some network performance tools have been using BGP for monitoring purposes. BGP is and always has been a routing protocol, not a monitoring one. Monitoring via BGP only makes sense for ISPs or CDNs, since they are concerned about the internet as a whole—or at least the part they are responsible for. But for those of us at companies not dealing with autonomous systems, then BGP isn’t enough for your monitoring needs. More importantly, if your users are layers of network abstraction away from core internet routing, then using core internet routing protocols like BGP to determine end-user experience is a fundamentally flawed idea. Monitoring G-Suite, Office 365, Salesforce or even internal web apps requires on-the-wire monitoring using TCP. Monitoring voice or video apps requires monitoring via UDP. Actual path route monitoring requires a combination of TCP, UDP and ICMP.

Monitoring via BGP is a periodic glimpse into the internet black box. It tells you what’s going on around the internet, but not specifically where your data is going. If there is an issue that BGP is reporting, your data is already routing around that issue. You can correlate route changes to identify the cause of intermittent issues, but this is inherently reactive. Modern monitoring needs to be proactive.

Tackling Modern Complexity

With modern networks, complexity is assumed. Between network virtualization and the increasing complexity of apps and transport mechanisms, performance monitoring has to evolve to match. Testing from the inside out—a la SNMP—fails to take into account the role the internet plays in performance. Testing via BGP is misusing a protocol built for routing. Neither work well when you introduce common technologies like SD-WAN, MPLS, VPN (SSL or IPSec) and wireless.

There’s a Better Way

BGP is still a part of modern monitoring, but it’s insufficient for modern apps. Here at AppNeta, we take a different approach to monitor end-user experience and performance. The resulting technology is TruPath. TruPath is an active on-the-wire methodology that utilizes packet trains of data and voice packets to analyze the response of a destination. If an issue is detected in any of the core network metrics (not just latency and loss), then TruPath will re-assess the delivery path by targeting every hop along the way, providing the user with an in-depth diagnostic report. Our expert system will then analyze the data to identify the probable cause and provide info to the user.

TruPath visualizes end-to-end connections from end user, through the LAN, WAN and last mile to the destination, which is awesome. It’s also happening actively, every minute, allowing the system to identify issues up to 15 times faster than passive polling of SNMP and BGP. If an issue is detected AppNeta will auto-escalate to confirm and then alert the user through emails and reports.

True outside-in monitoring can be accomplished by actively putting packets on the wire to follow the actual application delivery path from source to destination. That’s the better way to see how users are experiencing their apps.