Performance Monitoring Utilizing BGP Won’t Save You
It’s shaping up to be a pleasant afternoon around the office, with no user complaints coming in and the weekend beckoning. Then you get a call from the office manager at one of your company’s remote offices, several hours’ drive from where you are. Their weekly site backup, which should take about 45 minutes, now says it will take 45 hours. Uh oh. Time to troubleshoot, but what are the available approaches to diagnosing a problem that involves a remote office, the public internet and a SaaS provider?
A few monitoring companies are promoting an outside-in approach utilizing a combination of protocols including BGP, but they fail to provide the end-to-end metrics needed to measure end-user experience. When dealing with performance one of the core metrics you’ll look for is latency, but BGP can’t tell you that. BGP also won’t be able to tell you anything about packet loss at the higher layers because BGP is focused on the AS path level. Relying on access to BGP data, in part or as a whole, isn’t a good foundation for monitoring. To gather even basic metrics like latency and loss monitoring tools rely on an ICMP or TCP-based traceroute. And while BGP updates constantly, monitoring via BGP polling techniques typically limits requests to longer intervals.
What Is BGP, Exactly?
BGP, the Border Gateway Protocol, is a scalable routing protocol and has an important place in today’s network infrastructures by connecting disparate networks together across the world and can carry routes for many types of data, like that of VPNs and IPv6. Routers use BGP to issue updates about its status and whether or not the router is ready to accept traffic. Nodes affected with excess congestion updates all of its neighbors to signal that it's not available for traffic. This method informs what routes traffic takes so that the internet can be self-healing–and route around problems.
And What Are the Other Methods?
BGP, as a routing protocol, is a layer removed from users and doesn’t give the end-user view of performance. The protocols AppNeta uses to measure end user experience with our active monitoring are ICMP, TCP and UDP.
- ICMP (OSI Layer 3): ICMP provides the lowest level of information and is used for diagnostic testing, route determination and metric measurement at all levels. ICMP is a built-in configuration and support protocol that sends a message if a device can’t be reached by packet delivery.
- TCP (OSI Layer 4): Monitoring via TCP mimics actual web app traffic like G Suite and Office 365 by sending full MTU packets in a dispersed train. The reception and subsequent return will alter the packets in order, delay variation or number allowing AppNeta to measure metrics like Jitter, Loss, Latency and TCP Retransmissions every minute for all of your locations.
- UDP (OSI Layer 4): UDP is the primary transport mechanism for voice and video traffic due to the low overhead that results from its connectionless nature. AppNeta’s UDP monitoring is primarily used for dual-ended testing where AppNeta Monitoring Points act as both endpoints of a connection.
These protocols, working together, are what AppNeta’s TruPath depends on to get the full picture of application and network performance. So you get a variety of metrics with TruPath, including capacity, link latency and round-trip time, application response time and throughput, plus filters for location and users.
If you’re using AppNeta on this afternoon, you’d see that your backup had slowed dramatically due to an ISP rate limiting issue right away. Give your ISP a call and let them know if they are violating an SLA and exactly when performance slowed down. You might even send a screenshot of what the user saw. We’re pretty sure your weekend will go off without a hitch—and so will the IT processes that run all weekend.
Filed Under: networking technology