|
|
|
Home · BGP Expert Test · What is BGP? · BGP Vendors · Links · Archives · Books · My BGP Book
Table of contents (for this page):
BGP for ISPs courseThis course is intended for people who recently connected to an internet exchange, or are planning to do so in the near future. It consists of a theory part in the morning and a practical part in the afternoon where the participants implement several assignments on a BGP router (in groups of two participants per router).Sign up here. The course is organized in association with the NL-ix. The location will be The Hague, Netherlands. Dates for 2007: june 13th (English), september 12th (Dutch) and december 12th (English). Interdomain Routing & IPv6 News
In january, Geoff Huston wrote to the NANOG list: George Michaelson, Randy Bush and myself have successfully tested the implementation of 4Byte AS BGP on a public Internet transit. The above BGP RIB snapshot was taken at a 4Byte BGP speaker in North America, showing a transit path across AS 1221, AS 4637, AS 1239 and AS 3130 , with correct reconstruction of the originating AS at the other (4Byte AS) end.At the time of this writing, their prefix is no longer visible in the global BGP table, but telnet to route-views.oregon-ix.net and type: show ip bgp regexp _23456_Until the Route Views server is upgraded to support 32-bit ASes, this will give you all the prefixes/AS paths with a 32-bit AS number in them. Currently, those are:
There are now patches to make OpenBGPD 32-bit AS capable and also patches for Quagga. For more information on 32-bit ASes, have a look at an earlier article on BGPexpert.com. Warning: spoiler. Last week's episode (#74) of MythBusters showed that, in fact, old dogs can learn new tricks. That's a good thing, because securing inter-domain routing requires a whole bag of them. After lots of talk about S-BGP and soBGP over the past years, more recently, work in the IETF on making inter-domain routing more secure has shifted to a different approach. The relatively new secure inter-domain routing (sidr) working group is now working on providing a public key infrastructure that makes it possible to link an IP prefix to an origin AS with certificates. In the future, this mechanism may be used in S-BGP, soBGP or a similar mechanism, but in the mean time, it allows generating and validating filters. Although it's possible to choose arbitrary trust anchors, the idea is that IANA and the RIRs will serve as certificate authorities as they are the ones giving out the address space and AS numbers. Although the basic idea is simple enough, I'm slightly worried about how this is going to work in practice, because the underlying mechanisms are very complex, and not something "BGP people" are likely to be familiar with. Have a look at the sidr page on the IETF website and the links to the current drafts to get an idea. A good one to start with is draft-ietf-sidr-arch-00.txt or "An Infrastructure to Support Secure Internet Routing". (temporary link) 2006 was another busy year for the five Regional Internet Registries: together, they gave out 161.48 million IPv4 addresses, just shy of the 165.45 million given out in 2005 as measured on january first 2006. Lots more information in the 2006 IPv4 Address Use Report. If you want to use the BGP routing protocol, you need an Autonomous System number. These AS numbers were 16 bits in size until now, allowing for around 64000 ASes, and more than half of those have been given out already. To avoid problems when we run out of AS numbers, the IETF came up with modifications to BGP to allow for 32-bit AS numbers, as I explained in a posting about a year ago. Obviously, at some point someone has to bite the bullet and start using one of these new AS numbers. This bullet biting may happen fairly soon, as the five Regional Internet Registries have all adopted, or are in the process of adopting, the following policy:
So what does this mean for people who run BGP today? Not all that much, really, because the changes to BGP to support the longer AS numbers are completely backward compatible. The only change is that you'll see the AS number 23456 appear in more and more places. In routers that don't yet support 32-bit ASes, the special 16-bit AS number 23456 shows up as a placeholder in places where a 32-bit AS is supposed to appear. If you have scripts that perform AS-related operations on the Routing Registries (such as the RIPE database), you'll have to adjust your software to parse the new format for 32-bit AS numbers. They are written down as <16bits>.<16bits>, for instance, 3.1099 is a new 32-bit AS number and 0.23456 is the 32-bit version of AS 23456. However, this format isn't standardized so 32-bit AS numbers may show up differently in your router. Have a look at the RIPE announcement. As soon as the first 32-bit AS number appears in the wild I'll report it here so you can check whether it shows up in its full 32-bit glory or as 23456. In the mean time, you may want to ask your router vendor for 32-bit AS support. At least one of the big vendors isn't implementing it in all of their lines just yet because they claim there is no customer demand for it. Archives of all articles - RSS feed My Books: "BGP" and "Running IPv6"On this page you can find more information about my book "BGP". Or you can jump immediately to chapter 6, "Traffic Engineering", (approx. 150kB) that O'Reilly has put online as a sample chapter. Information about the Japanese translation can be found here.More information about my second book, "Running IPv6", is available here. Apress, my new publisher, also has a sample chapter available: Chapter 5, The DNS. "no synchronization"When you run BGP on two or more routers, you need to configure internal BGP (iBGP) between all of them. If those routers are Cisco routers, they won't work very well unless you configure them with no synchronization.The no synchronization configuration command tells the routers that you don't want them to "synchronize" iBGP and the internal routing protocol such as OSPF. The idea behind synchronizing is that when you have two iBGP speaking routers with another router in between that doesn't speak BGP, the non-BGP router in the middle needs to have the same routing information as the BGP routers, or there could be routing loops. The way to make sure that the non-BGP router is aware of the routing information in BGP, is to redistribute the BGP routing information into the internal routing protocol. By default, Cisco routers expect you to do this, and wait for the BGP routing information to show up in an internal routing protocol before they'll use any routes learned through iBGP. However, these days redistributing full BGP routing into another protocol isn't really done any more, because it's easier to simply run BGP on any routers in the middle. But if you don't redistribute BGP into internal routing, the router will still wait for the BGP routes to show up in an internal routing protocol, which will never happen, so the iBGP routes are never used. The "no synchronization" configuration command tells the routers they shouldn't wait for this synchronization, but just go ahead and use the iBGP routes. BGP SecurityBGP has some security holes. This sounds very bad, and of course it isn't good, but don't be overly alarmed. There are basically two problems: sessions can be hijacked, and it is possible to inject incorrect information into the BGP tables for someone who can either hijack a session or someone who has a legitimate BGP session.Session hijacking is hard to do for someone who can't see the TCP sequence number for the TCP session the BGP protocol runs over, and if there are good anti-spoofing filters it is even impossible. And of course using the TCP MD5 password option (RFC 2385) makes all of this nearly impossible even for someone who can sniff the BGP traffic. Nearly all ISPs filter BGP information from customers, so in most cases it isn't possible to successfully inject false information. However, filtering on peering sessions between ISPs isn't as widespread, although some networks do this. A rogue ISP could do some real damage here. There are now two efforts underway to better secure BGP:
The IETF RPSEC (routing protocol security) working group is active in this area. IPv6BGPexpert is available over IPv6 as well as IPv4. www.bgpexpert.com has both an IPv4 and an IPv6 address. You can see which one you're connected to at the bottom of the page. Alternatively, you can click on www.ipv6.bgpexpert.com to see if you can connect over IPv6. This URL only has an IPv6 address.What is BGPexpert.com?BGPexpert.com is a website dedicated to Internet routing issues. What we want is for packets to find their way from one end of the globe to another, and make the jobs of the people that make this happen a little easier.Your host is Iljitsch van Beijnum. Feedback, comments, link requests... everything is welcome. You can read more about me here or email me through here. Ok, but what is BGP?Have a look at the "what is BGP" page. There is also a list of BGP and interdomain routing terms on this page.BGP and MultihomingIf you are not an ISP, your main reason to be interested in BGP will probably be to multihome. By connecting to two or more ISPs at the same time, you are "multihomed" and you no longer have to depend on a single ISP for your network connectivity.This sounds simple enough, but as always, there is a catch. For regular customers, it's the Internet Service Provider who makes sure the rest of the Internet knows where packets have to be sent to reach their customer. If you are multihomed, you can't let your ISP do this, because then you would have to depend on a single ISP again. This is where the BGP protocol comes in: this is the protocol used to carry this information from ISP to ISP. By announcing reachability information for your network to two ISPs, you can make sure everybody still knows how to reach you if one of those ISPs has an outage. Want to know more? Read A Look at Multihoming and BGP, an article about multihoming I wrote for the O'Reilly Network. For those of you interested in multihoming in IPv6 (which is pretty much impossible at the moment), have a look at the "IPv6 multihoming solutions" page. Are you a BGP expert? Take the test to find out!These questions are somewhat Cisco-centric. We now also have another set of questions and answers for self-study purposes. You are visiting bgpexpert.com over IPv4. Your address is 38.103.63.18. |