|
|
|
Home · BGP Expert Test · What is BGP? · BGP Vendors · Links · Archives · Books · My BGP Book
Table of contents (for this page):
BGP and IPv6 coursesThis course teaches you the basics of running BGP and IPv6. The BGP course 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). The IPv6 course has mostly theory but we provide IPv6 connectivity so you can try out the IPv6 capabilities of your favorite operating system on your laptop.Go to the NL-ix website to find more information and sign up. The location will be The Hague, Netherlands. Dates for upcoming courses are for the BGP course may 31 (English) and for the IPv6 course june 1 (English). Interdomain Routing & IPv6 News
For the fifth time now, I wrote an IPv4 address use report over the previous year for this site. And, for the first time, an IPv6 address use report. In addition, I wrote an article for Ars Technica about the IPv4 address use the past year and the past decade. From the Ars article:
Today, ten years later, 2,985 million addresses (81 percent) are in use, and 722 million are still free. In that time, the number of addresses used per year increased from 79 million in 2000 to 203 million in 2009. So it's a near certainty that before Barack Obama vacates the White House, we'll be out of IPv4 address. (Even if he doesn't get re-elected.) comment here.
A while ago, Geoff Huston wrote a column titled A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation. Why didn't I read it earlier? Apart from normal busy-ness, I guess I suspected I wouldn't like this column. I was right. In case you don't have half an hour to read all the details, let me summerize the problem: at some point, Geoff couldn't load a page from the RFC Editor website with Safari but it worked with Firefox. Safari uses IPv6 by default (if the system has IPv6 connectivity). Firefox does this too, on any system other than a Mac. Under MacOS, however, Firefox won't use IPv6 by default. So the problem was with IPv6. Specifically, there was a path MTU discovery (PMTUD) black hole between Geoff and the RFC Editor. This is when small packets make it through, but large ones don't, and the requisite "packet too big" messages generated by routers that allow the sender to learn that it needs to send smaller don't make it back, so the sender keeps sending packets that are too large. Apparently Geoff isn't aware of the fact that PMTUD black holes are extremely common on the IPv4 internet. For instance, try requesting a page from www.microsoft.com when going through a network link that as a maximum packet size (maximum transmission unit / MTU) of less than 1500 bytes somewhere in the middle of the path. It won't work. And Microsoft doesn't care: they keep filtering out "too big" messages and they keep setting the "don't fragment" bit to 1 on their packets. I can't understand why, because the combination of those two actions makes no sense. If they don't want to see the ICMP messages, they should turn off PMTUD so the DF bit is set to 0 and routers can fragment the packets that are too large. The reason that most users never see these problems is that those evil NAT boxes that we IPv6 proponents hate so much rewrite the maximum segment size (MSS) option in the TCP three-way handshake to indicate that the remote TCP should limit its packet sizes. Anyway, back to IPv6. Geoff suggests that the solution is to set your interface MTU to 1400. This reduced MTU and therefore MSS will be conveyed to remote servers in the TCP MSS option so it does help. However, other local systems still have the normal ethernet MTU of 1500 so they may try sending your system (non-TCP) packets larger than 1400 bytes, which won't work. The local router also won't send back a "too big" message because it thinks your system can handle 1500 bytes. This is going to be especially problematic once DNSSEC becomes common, because DNSSEC needs to transmit large pieces of data in DNS responses, which are usually UDP. So what is the solution? First of all, the good thing about IPv6 is that it is still being rolled out. So if you complain, the complaint is likely to arrive somewhere where IPv6 was recently enabled, and the problem may still be fixable, unlike in the case of www.microsoft.com for IPv4. Originally, I wanted to suggest only changing the MTU for IPv6 for those of you who want to follow Geoff's advice. However, there doesn't appear to be a way to do that. But you may be able to have your local router send out an MTU option in its router advertisements that makes all the hosts use a reduced IPv6 MTU while leaving the IPv4 MTU alone. On a Cisco, simply do this:
! interface ethernet0 ipv6 mtu 1480 !You need to do this on all the routers, though. And if you want to avoid all possible MTU issues, use an MTU of 1280, which is the minimum MTU that all IPv6 systems are required to support. Type ndp -i If the black hole happens when you send large packets, you can add MTU information for a destination to the routing table. For instance, this changes the MTU associated with the IPv6 default route on a MacOS system (FreeBSD without the "sudo") and then displays the default route:
sudo route change -inet6 default -mtu 1280 sudo route get -inet6 defaultAs for the real solution: RFC 4821 describes a solution (for TCP, at least) to the PMTUD black hole issue, so push your OS vendor to implement it.
For some time, I've maintained a number of pages that show address and AS number statistics generated from the delegation reports published by the five regional internet registries on their FTP servers. Time to make a list. See the yearly address use reports for descriptions of the details and caveats. Totals:
Per country:(Note that this uses outdated population statistics.) Other:
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.comment here. 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.107.191.90. |