This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
Tag Archives: bgp
Unlock with PatreonFor Patreon Subscribers: Access to Mikrotik Speedtest servers
I am happy to announce a special new tier for my Patreon subscribers. I have now installed a network of speedtest servers in 15 locations in the United States and one overseas as part of stage 1. Patreon subscribers who subscribe to this extra tier of service will be presented with a members-only username and password for testing to each of these.
Stage two will be a looking glass so you can test how your BGP routes look in various spots on the Internet. You will know what Upstreams each location has to better assist you in diagnosing BGP or just getting a view of how your network interacts with the Internet.
Visit my Patreon Page for more details.
How does BGP select routes?
This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
Printing Mikrotik BGP received routes
This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
Another BGP blunder.but not THAT one
Recently, there has been much talk about the Cloudflare BGP blunder and others. The Network Collective even did a video about such things. But did you know there was one involving the entire /12 of IPV6 space? Airtel AS9498 announced the entire IPv6 block 2400::/12 for a week and no-one noticed. Someone typed a /12 instead of a /127.
So why did no one notice? I think part of it is due to the low usage of v6 space. Sure, all kinds of people claim stats on IPV6 usage. They talk about X number of traffic is v6, etc. There is a difference between users and connections. A connection may not actually represent unique users.
Secondly, people are used to IPV6 being buggy. I know many ISPs who disabled v6 as part of their troubleshooting steps.
I know there will be several folks who jump all over me about IPV6 being the wave of the future and we all should be using it. Yes, we should, but there is no huge hurry when it comes to business cases.
Cisco IOS BGP Commands
This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
Noction: BGP in Large Networks
Are you running a large scale BGP network? Need some tips and help on what to optimize and what your next steps to optimize your setup?
Using iBGP with loopback addresses
Making sure all routers know next hop and loopback addresses
Whether to use route reflectors rather than an iBGP full mesh
Where to originate prefixes
Where and how to filter announcements
Using BGP in large scale networks and how to get the most out of it. Paper by Noction
FD-IX Explainer video on Internet Peering and exchanges
Explainer video about what an Internet exchange point (IXP) is and how peering works. Making the internet better through peering. https://www.fd-ix.com #keeptrafficlocql #routinglight #peering #ixp
Remote Peering
Martin J. Levy from Cloudflare did a presentation about remote peering possibly being a bad thing. In this presentation, he brings up several valid points.
Some thoughts of my own.
Yes, remote peering is happening. One thing touched upon is the layer3 vs layer2 traffic. We at MidWest-IX only allow remote peering at a layer2 level unless it is groups like routeviews.org or other non-customer traffic situations.
Many providers are overselling their backbone and transit links. This oversubscription means access to content networks in places that do not have an exchange or places that do have the content locally can suffer through no fault of the ISP or the content provider. We have situations with content folks like Netflix who do not join for-profit IXes at the moment, keeping the content further away from customers. These customers are reaching Netflix through the same transit connections many other providers are. The can result in congested ports and poor quality for the customer. The ISP is left trying to find creative ways to offload that traffic. An Internet Exchange is ideal for these companies because cross-connect charges within data centers are on the rise.
When we first turned up MidWest-IX, now known as FD-IX, in Indianapolis we used a layer2 connection to Chicago to bring some of the most needed peers down to our members. This connection allowed us to kick-start our IX. We had one member, who after peering with their top talkers, actually saw an increase in bandwidth. The data gained told the member that their upstream providers were having a bottleneck issue. They had suspected this for a while, but this confirmed it. Either the upstream provider had a congested link, or their peering ports were getting full.
As content makes it way closer remote peering becomes less and less of an issue. There are many rural broadband companies just now getting layer2 transport back to carrier hotels. These links may stretch a hundred miles or more to reach the data center. The rural broadband provider will probably never get a carrier hotel close to them. As they grow, they might be able to afford to host caching boxes. The additional cost and pipe size to fill the caches is also a determining factor. The tradeoff of hosting and filling multiple cache boxes outweighs the latency of a layer2 circuit back to a carrier hotel.
I think remote peering is necessary to by-pass full links which give the ISP more control over their bandwidth. In today’s race to cut corners to improve the bottom line having more control over your own network is a good thing. By doing a layer2 remote peer you might actually cut down on your latency, even if your upstream ISP is peered or has cache boxes.
BGP Monitoring RFC 7854
https://tools.ietf.org/html/rfc7854
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.