BGP Won't Save You
BGP Won't Save You
If you try to figure out a certain problem using just BGP data, you’re going to be very disappointed. BGP is useful, but it should be included as a larger set of methods.
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
It’s shaping up to be a pleasant Friday afternoon at 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.
If you try to figure out the problem using just BGP data, you’re going to be very disappointed. BGP is useful, and monitoring tools should include it as part of a larger, more complex set of methods. However, BGP is for routing, not monitoring. More routing information can help IT understand route ownership and changes but leaves plenty of missing monitoring pieces.
What Is BGP, Exactly?
BGP, the Border Gateway Protocol, is the good ol’ routing protocol of the internet and has been used for many years. It helps connect separate networks and ISPs together and can carry routes for many types of data, like that of VPNs and IPv6. BGP is a scalable routing protocol and has an important place in today’s network infrastructures, even though it hasn’t been updated in more than a decade. It allows for policy-based routing. While BGP can be used to see basic metrics for latency and packet loss for connected routes or look up Autonomous System (AS) numbers for hop ownership, the protocol itself isn’t meant for monitoring.
To avoid unnecessary chatter along core lines of the internet, BGP looks at data at 15-minute intervals — not exactly real-time information. It also just shows two metrics: latency and loss. These metrics are used to identify what routes traffic takes so that when there is congestion the internet can be self-healing in the way that it routes around detected problems. You may see what seems to be a performance issue but isn’t really since BGP routed around it. BGP also only works over the open internet, not into SaaS providers or your data center, where broadcasting of BGP has likely been turned off.
And What Are the Other Methods?
The protocols we like to use for monitoring are TCP, UDP, and ICMP. Note that we said “monitoring.” These aren’t routing protocols, and so can give us different, more user-focused information. BGP, as a routing protocol, is a layer removed from users and doesn’t give the end-user view of performance.
Each of our preferred protocols has its own particular area of specialization. TCP, as a connection-oriented protocol, does on-the-wire monitoring, which works well for web apps and big SaaS apps like G Suite or Office 365. UDP is particularly good as it is used for voice and video apps, part of many modern enterprise systems. ICMP is a built-in configuration and support protocol that sends a message if a device can’t be reached by packet delivery.
These protocols, working together, are what AppNeta’s TruPath depends on to get the full picture of app 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 only seeing BGP data, you’ll miss the actual hop-by-hop path your data is taking and has been taking during the period of the problem. For example, you’d only see information on latency that appeared as BGP tried to route around the problem network. And since it only checks in every 15 minutes, you might miss that latency altogether.
Published at DZone with permission of Alec Pinkham , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.