How a Router's Missed Range Check Nearly Crashed the Internet | Hacker News Reader

How a Router's Missed Range Check Nearly Crashed the Internet

renesys.com

21 pointstmilewski8 comments

This might be a good post to ask this particular question: I am very unfamiliar with the nuts and bolts of how the Internet actually works. I understand DNS resolution, ports, HTTP protocol - all of the higher-level abstracted stuff that you need to know to program within the environment. However - route-maps? BGP? ASN? Whatever else is under the hood that makes it tick - no idea. What's a good book to learn all this stuff?

the first tcp/ip illustrated volume provides a very solid foundation for the low-level protocols, though there is probably some newer stuff and best-practices not covered in it (it was published in 94).

i've never read any books on the stuff, but i used to work at an isp and learned about larger-scale routing concepts just by gleaning it from cow-orkers. unless you're going to work at an isp or do network administration for a large network, you're probably not going to interact with bgp, eigrp, asn's and other concepts much, if any.

that said, you can subscribe to the nanog mailing list (be prepared for lots of boring "can someone from xyz network contact me off-list" threads), play around with the various public route servers available, and if you're really interested, setup a test network with openbgpd or quagga.

These two books are a good introduction:

CCENT/CCNA ICND1 Official Exam Certification Guide

CCNA ICND2 Official Exam Certification Guide

Both are on Cisco Press.

It doesn't go up to BGP but does provide a solid introduction to other routing protocols like RIP, RIPv2, OSPF, and EIGRP.

I will try to give you a quick recap, the books other have suggested are good.

Your connection to the Internet is probably single-homed, that is, one connection going to one upstream provider. Simple enough to understand - "send all packets not meant for the LAN to this address".

Consider that a large company, or a datacenter with hundreds to thousands of servers, will have multiple connections to multiple providers, such as ATT, Level3, Sprint, Cogent, etc.

BGP is the border gateway protocol - it lets you load sets of prefixes (eg. 207.89.0.0 if that range were all owned by one provider) and then given the connections you have and what prefixes are connected to that connection, it will try to use the least number of hops to get your traffic to the destination.

ASN is autonomous system number - basically a "site location" that represents an organization that has some number of IP addresses (represented by prefixes as above).

You use the ASN in conjunction with the other information you give BGP, so that you don't have to store ALL the routes for ALL the locations and compute the path for each packet.

Big routers like the larger Ciscos have custom RAM chips and do most of the routing in hardware, in order to be fast enough. They are called TCAMs : http://www.enterprisenetworkingplanet.com/nethub/article.php...

Thank you for that. Now, let me ask you this: so, let's say we are talking about that large datacenter with hundreds to thousands of servers. What are the possible reasons for why you would have multiple providers as opposed to just pumping everything through one?

Is it:

1) A provider might not have enough bandwidth available for your needs, so you need to diversify?

2) You would get multiple providers so that you try to reach as many destinations as possible directly? IOW, if I only have ATT, then in order to get to destination X that's on Level3 there's an extra hop wherever the hell ATT connects to Level3, and you also have Level3 yourself then the fastest route to that is through the Level3 network?

3) All/None of the above/something else?

1. Redundancy - although failures are rare, they do occur. So if one provider has a problem, traffic to all other points is not interrupted.

2. Pricing - you buy from multiple providers and thus are not locked in.

3. Latency - your customers want the lowest latency.

3a. Often times, companies will run an application in the data center and have remote offices connect over a VPN to the servers. Those remote offices will be in different geographic areas and will be using different local providers, all of which will have different network paths to reach you.

Peering - if you are large enough to provide say 100Mb/s or more of traffic continuously to one provider's network, they may choose to peer with you at little or no cost. This means that they give you the connection because the traffic is going to them directly and they don't have to maintain other high speed connections to some third party that they may have to pay. There is a lot of negotiation and at least 3 separate pricing strategies that each side can follow.

The simplest is "bill and keep" which is that each side provides no-cost access to the other's network, and they each bill their own customers and keep the proceeds.

If you are large enough (say, you are a large national access or hosting provider), there is no single, even larger "The Internet, Inc." upstream provider you can use as your single link. You have to negotiate peering agreements with the other large actors so that you have reliable and affordable routes to all parts of the net. At this level you need things like BGP to know where to send traffic for a destination outside of your own net, because you could have several possible routes with different performance and/or price.

Unlike most LANs wich are either physically or logically (via the spanning tree protocol) structured like a tree, the core internet is a weighted graph.

Interesting little fact, the BGP protocol and other bits related to propagating routing information will not converge to an answer in general, but will under certain conditions such as "no dispute wheel" (which can happen if the routing distances don't satisfy a triangle inequality[by which I mean some geometric notion of distance], though thats too strong an assumption about routing choices to be reasonable).

Reply on news.ycombinator.com