BGP Tools for the DFZ (1)
Why isn’t inbound load balancing working the way I expect? Why are users having a hard time reaching my web site? What is that strange advertisement I see in my local routing table, and where does it lead? The Default Free Zone (DFZ), the land where there is no default route from the edge of the Internet to the core, can seem like an intimidating place to work. There are, however, a number of tools that can help you discover what is going on with your routes, where routes are coming from, and other information. This short series of posts will provide an overview of these tools, and some use cases along the way to help you understand how and where to use them.
Note: throughout this series, I’m going to be using the LinkedIn AS number and routes, as well as the AS numbers of other public companies for illustration. I’m deviating from my normal practice of using addresses and AS numbers reserved for documentation in order to make it possible for readers to perform the same actions and get something like the same results. Do not use these addresses or AS numbers in your network!
Let’s start by setting the stage a little: You’ve been given an AS number, and a route. Now you need to make certain this information is actually advertised through three different providers, and to try to get to some semblance of inbound load sharing over the three links. Before you even start with the “first step” you’re probably thinking of—configuring BGP—you actually need to check on the registration information in several different places to make certain it is correct. The best place to begin is whois, which is just going to verify domain name ownership.
There are several places you can go to check the whois database on the Internet, but the ones I use most often are at ICANN and Verisign.
Since we’re using LinkedIn as an example, we can look up LinkedIn.com, the domain we intend to point this new route to, to make certain the registration information looks correct.
There are other things you can use whois results for, of course, than just checking your own domain information for correctness. Let’s say you suddenly notice a lot of spam coming from a particular domain name. You can just fuss about it and reset your filters, of course. Another option—one that might be more effective, and help stop spam on the entire Internet—would be to use whois to find the owner and registrar of the domain name and lodge a complaint about the spam with them. It’s always helpful to include a sample or two of the emails in question, and of course—be courteous, rather than angry. See if you can find a spam reporting system for the domain in question (many providers and domain name registrars have these on their web sites) before sending an email to the administrative account shown in the whois record, as well.
Now it’s time to pick up the BGP configuration manual and start peering, right? Wrong. There are a couple of other places you should check for correct information before you start building those configs—but I’m out of time for now, so they’ll need to wait ’til the next post.