- NANOG - lists.nanog.org

How many IPv6 BGP routes are you planning for in DFZ?
by Jeff Wheeler 09 Mar '11

09 Mar '11

On Wed, Mar 9, 2011 at 2:19 AM, George Bonser <gbonser(a)seven.com> wrote: > The ipv4-ipv6-2 CAM profile in 5.1 gives 768K v4 routes and 64k v6 > routes which should be good for quite a while. That is provided you How many IPv6 BGP routes are folks typically planning for in the DFZ before a hardware upgrade is required? Here are some relevant figures (note that my script makes some minor errors but this is good enough for discussion purposes): IPv6: Unique Origin ASes seen: 3287 Examined 4705 active routes IPv4: Unique Origin ASes seen: 36707 Examined 352688 active routes Making some assumptions, let's say every active ASN in DFZ will announce a mean of 1.4 IPv6 routes (the number seen today.) If IPv6 grows from under 10% of ASNs today to 100% of ASNs in a year or two, we will see about 53k IPv6 routes in DFZ. Keep in mind that many, if not most, ASNs originating IPv6 routes today have substantially no production services on IPv6, and they may deaggregate more in the future, etc. Some folks seem to believe that not every ASN will announce routes to the DFZ. I don't think that is a safe assumption upon which to base purchasing decisions for routers which should have a life-cycle of several years. Whether or not networks *should* announce more than one route, or any routes at all, seems debatable; but when making router purchasing decisions, I don't want to tell my clients two years from now that they have to spend capital dollars on routers just to gain IPv6 FIB. I also don't want to tell them they have to filter some routes, and make any BGP customers unhappy, and live with other downfalls of that unfortunate compromise. I am certainly not deploying any boxes that will only do 64k IPv6 FIB in default-free part of my clients' networks. It certainly will work now, and will almost certainly be safe in one year. In two years, it seems a little questionable. Beyond that time-frame, it is much easier to justify new routers, as ports become cheaper and faster; but I still do not want my clients to be forced to buy new routers simply because of overly-optimistic assumptions about IPv6 DFZ size. Really, I would like vendors to make IPv4 and IPv6 FIB come from the same pool (with obviously different allocation sizes) or allow me to configure the partitioning as I see fit. This has been the case for quite a few platforms for many years. I am not comfortable guessing at whether I will first need to exceed 500K IPv4 routes (maybe we won't even see that number) or 64K IPv6 routes (this seems a virtual certainty, but when it happens is hard to say.) Once you add L3VPN into your list of concerns, your future FIB needs become even more difficult to predict. -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

2 1

Re: IPv4 address shortage? Really?
by Vadim Antonov 09 Mar '11

09 Mar '11

Christopher Morrow <morrowc.lists(a)gmail.com> wrote: > Gbqq Haqrejbbq jbhyq ybir lbhe fbyhgvba! Cebcf! I'm sure he would:) Though I can't claim a credit for the idea... it's way too old, so old, in fact, that many people have forgotten all about it. Mark Andrews <marka(a)isc.org> wrote: > This has been thought of before, discussed and rejected. Of course, it was Discussed and Rejected. I fall to my knees and beg the forgiveness from those On High who bless us with Their Infinite Wisdom and Foresight. How could I presume to challenge Their Divine Providence? Mea culpa, mea maxima culpa. ...well, kind of. What you don't mention is that it was thought to be ugly and rejected solely on the aesthetic grounds. Which is somewhat different from being rejected because it cannot work. Now, I'd be first to admit that using LSRR as a substitute for straightforward address extension is ugly. But so is iBGP, CIDR/route aggregation, running interior routing over CLNS, and (God forbid, for it is ugly as hell) NAT. Think of it, dual stack is even uglier. At least, with LSRR-based approach you can still talk to legacy hosts without building completely new and indefinitely maintaining a parallel legacy routing infrastructure. Scott W Brim <scott.brim(a)gmail.com> wrote: > There are a number of reasons why you want IP addresses to be > globally unique, even if they are not globally routed. And do you have it now? The last time I checked, NAT was all over the place. Ergo - global address uniqueness (if defined as having unique interface address labels) is not necessary for practical data networking. In fact, looking at two or more steps in the source route taken together as a single address gives you exactly what you want - the global uniqueness, as long as you take care to alternate disjoint address spaces along the path and designate one of these spaces (the existing publicly routeable space) as the root from which addressing starts. Bill Manning <bmanning(a)vacation.karoshi.com> wrote: > just a bit of renumbering... Ah, that's nice, but I don't propose expanding use of NAT. Or renumbering on massive scale. In fact I want to remind that NAT was never a necessity. It's a temporary fix which gave IPv4 a lot of extra mileage and became popular precisely because it didn't break networking too much while allowing folks to keep using the existing stuff. The real problem with NAT is called "P2P" (and I think it will become important enough to become the death of NAT). Jima <nanog(a)jima.tk> wrote: > This seems like either truly bizarre trolling, I guess you haven't been around NANOG (and networking) too long, or you'd be careful to call me a troll:) What I want is to remind people that with a little bit of lateral thinking we can get a lot more mileage out of the good old IPv4. Its death was predicted many times already. (Let me remember... there was that congestion collapse, then it was the routing table overwhelming the IGPs, and then there was that shortage of class Bs and routing tables outgrowing RAM in ciscos, and then there was a heated battle over IP address ownership, and there was the Big Deal about n^2 growth of iBGP mesh). I don't remember what was the deal with Bob Metcalfe and his (presumably eaten) hat. Something about Moore's Law? > or the misguided idea of someone who's way too invested in IPv4 and > hasn't made any necessary plans or steps to implement IPv6. "Too invested in IPv4"? Like, the Internet and everybody on it? You know, I left the networking soapbox years ago, and I couldn't care less about the religious wars regarding the best ways to shoot themselves in the foot. The reason why I moved to different pastures was sheer boredom. The last interesting development in the networking technology was when some guy figured out that you can shuffle IP packets around faster than you can convert a lambda from photons to electrons - and thus has shown that there's no technological limitation to the bandwidth of Internet backbones. > you'd have to overhaul software on many, many computers, routers, > and other devices. (Wait, why does this sound familiar?) You probably missed the whole point - which is that unlike dual-stack solution using LSRR leverages existing, installed, and paid for, infrastructure. > too bad we don't have a plan that could be put into action sooner The cynical old codgers like yours truly have predicted that the whole IPv6 saga would come precisely to that - when it was beginning. The reason for that is called the Second System Effect of which IPv6 is a classical example. A truly workable and clean solution back then would be to simply add more bits to IPv4 addresses (that's what options are for). Alas, a lot of people thought that it would be very neat to replace the whole piston engine with a turbine powerplant instead of limiting themselves to changing spark plugs and continuing on the way to the real job (namely, making moving bits from place A to place B as cheap and fast as possible). Now, we don't have a problem of running out of IPv4 addresses - NAT takes care of that, and will continue to do so for many years more. We do have a problem of having no way[*] to initiate connections to boxes hidden behind NATs. Which is bad for P2P applications. To solve this problem three things need to be done: 1) to create network infrastructure which can haul packets with extended addresses (be it IPv4 or IPv6) and extend network stacks in the OSes to support this transport; 2) to create a way to map domain names to those addresses; 3) to get applications to work with the extended addresses. You also need a clean migration path from legacy to the new architecture (which IPv6 lacks), just to stay in the realm of practical. 1 and 3 are seriously expensive. 2 is relatively easy as DNS has provisions for expansion which were actually used (instead of reinventing the wheel, thankfully). The issue #1 can be sidestepped by use of LSRR as I suggested. #2 and #3 are, to a considerable extent, already solved by the people implementing IPv6. Now, listen carefully: you don't have to use IPv6 packets to use IPv6 addresses. In fact, all we need to get benefits of extended addressing w/o going to the trouble of implementing native or tunneled IPv6 networks is a simple shim (either within kernels or within language libraries) which takes IPv6 address/socket and translates it into IPv4 socket with appropriate LSRR option information attached. (A small subset of IPv6 addresses could be set aside for the purpose... one /32 or such; just so you can still have IPv6 in all its glory if you wish). The entire amount of development for a Unix-like OS is about 500 lines of code (that's my educated guess based on the gut feeling developed while I was hacking various Unix kernels for living since v6). My question to the community - is it interesting enough? I.e. should I spend my time on writing I-D on IPv4 Extended Addressing, or will I be dismissed as a troll for my trouble? --vadim [*] chownat exceeds even my tolerance for ugliness, though the expoit itself is an elegant use of the quasi-paradox from probability theory.

4 8

OT: What vexes VoIP users?
by Eric Brunner-Williams 09 Mar '11

09 Mar '11

OT, but NANOG is almost always good for quick clue ... For those who have residential VoIP, what provider {features | bugs} are most vexing? For those who provision residential VoIP, what subscriber {expectations | behaviors} are most vexing? Thanks in advance, Eric

27 82

Re: [afnog] Suspicious request for IP address space
by Randy Bush 08 Mar '11

08 Mar '11

> Even more suspicious is the fact that there is no organisational > information attached to the request and the sender used a gmail > address. They supplied an Indian telephone number. it is about this point where i realize that i am overloaded with real work, hit delete, and get back to that work. randy

4 5

Who owns (or is allocated) 208.64.200.0/22?
by mikea 08 Mar '11

08 Mar '11

I rise to expose my ignorance. 208.0.0.0/8 is an ARIN block, and ARIN has allocation data for the blocks immediately adjoining 208.64.200.0/22, but no allocation data for 208.64.200.0/22 itself, either in WHOIS or in the website. Nor does 208.64.200.0/22 appear to be "special" in any way. Is this an oversight? How do I get it corrected, if it is? -- Mike Andrews, W5EGO mikea(a)mikea.ath.cx Tired old sysadmin

4 4

Re: [afnog] Suspicious request for IP address space
by Phil Regnauld 08 Mar '11

08 Mar '11

(Cross posting to nanog, apologies if this is considered not appropriate). Shepherd Magumo (shepherd) writes: > Good day, > > I work for an ISP with own small AfriNIC IP block and ASN number and > recently received a second suspicious request for a huge IP address space > with server hosting solution and we are about to turn it down. > > Below is the exact request and I am sure there is something dodge about this > request. Anybody else in ISP receive this? > > We are looking for an IP address space of /17 and we would like to lease it > > for one complete year. Please quote us the price and if its something in > > our > > range, We will go ahead and purchase, Along with it do you provide > > dedicated > > servers and hosting services. Get back to me soon along with the requested > > details. Hi Shepherd, Without disclosing the sender of this mail, do you know where it's originating from, region wise ? The size looks a bit large to be a legitimate request. They might be probing the market to find a LIR willing to go along with a scam. As I see it, if you consider the ratio of available IPv4 space left in the AfriNIC pool vs. the population in Africa, there is a temptation for IPv4 hungry orgs. to acquire v4 space via front companies in Africa, and announce it elsewhere - where the validation process for the appropriate RIR would be more stringent. Cheers, Phil

6 7

Ethernet circuit testing
by Dustin Swinford 08 Mar '11

08 Mar '11

More often on Ethernet services, we experience a customer wanting to see more than an Ookla based server test from our network. Our hands in the field are limited in the number of Ethernet smart loopback devices that they own. If we do have a tester on site, we can generate traffic from an Exfo purpose built appliance toward the loop and determine results. Too often, we have found things such as ftp downloads to be unreliable based on use of server, windows PC doing the download, etc. What other methods are you guys using for testing these services?

6 5

A BGP issue?
by Greg Ihnen 08 Mar '11

08 Mar '11

I run a small network on a mission base in the Amazon jungle which is fed by a satellite internet connection. We had an outage from Feb 25th to the 28th where we had no connectivity with email, http/s, ftp, Skype would indicate it's connected but even chatting failed, basically everything stopped working except for ICMP. I could ping everywhere just fine. I started doing traceroutes and they all were very odd, all not reaching their destination and some hopping all over creation before dying. But if I did traceroute with ICMP it worked fine. Does this indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed Hughesnet which is the service they resell. I'm wondering what kind of problem would let ping work fine but not any of the other protocols. It also seems odd that I could traceroute via UDP part way to a destination but then it would fail if the problem was my own provider. Thanks. If this is the wrong forum for this post I'm sorry and please just hit delete. If this is the wrong forum but you'd be kind enough to share your expertise please reply off-list. Thanks! Here's some examples of the traceroutes I saved during the outage. Using UDP: Gregs-MacBook-Pro:~ GregIhnen$ traceroute metaconi.com traceroute to metaconi.com (70.32.39.205), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 1541.165 ms 25.665 ms 39.211 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 625.710 ms 860.264 ms 694.238 ms 4 192.168.180.5 (192.168.180.5) 645.666 ms 757.161 ms 664.785 ms 5 10.254.253.158 (10.254.253.158) 738.661 ms 801.487 ms 728.139 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 726.884 ms 733.989 ms 647.736 ms 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 740.233 ms 694.619 ms 685.464 ms 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 639.077 ms 741.495 ms 679.880 ms 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 650.312 ms 612.386 ms 660.452 ms 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 787.079 ms 725.495 ms 685.068 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 760.002 ms 828.076 ms 702.041 ms 12 ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 719.324 ms 641.274 ms 689.997 ms 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 669.613 ms 813.794 ms 737.211 ms 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 729.875 ms 751.481 ms 730.088 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * Now here it is again doing traceroute via ICMP: Gregs-MacBook-Pro:~ GregIhnen$ traceroute -I metaconi.com traceroute to metaconi.com (70.32.39.205), 64 hops max, 72 byte packets 1 192.168.7.1 (192.168.7.1) 5.254 ms 3.059 ms 2.578 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 1511.146 ms 711.304 ms 822.967 ms 4 192.168.180.5 (192.168.180.5) 712.672 ms 821.990 ms 713.009 ms 5 10.254.253.158 (10.254.253.158) 823.244 ms 711.764 ms 823.219 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.640 ms 613.306 ms 614.429 ms 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 823.232 ms 711.881 ms 823.166 ms 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 712.765 ms 822.398 ms 712.531 ms 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 822.809 ms 920.831 ms 712.399 ms 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 823.288 ms 711.478 ms 822.887 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 712.705 ms 822.287 ms 712.713 ms 12 * ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 738.656 ms 919.752 ms 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 921.381 ms 920.884 ms 1228.683 ms 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 921.560 ms 920.482 ms 921.634 ms 15 relativity.mrk.com (70.32.39.205) 880.318 ms 753.150 ms 823.285 ms Gregs-MacBook-Pro:~ GregIhnen$ Here's an example of a UDP traceroute going all over creation: Gregs-MacBook-Pro:~ GregIhnen$ traceroute skype.com traceroute to skype.com (78.141.177.7), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 18.939 ms 4.596 ms 27.124 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 724.034 ms 704.520 ms 823.886 ms 4 192.168.180.5 (192.168.180.5) 711.962 ms 704.606 ms 823.208 ms 5 10.254.253.158 (10.254.253.158) 712.622 ms 912.870 ms 921.471 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.642 ms 822.307 ms 712.720 ms 7 * te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 3692.277 ms 702.345 ms 8 te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 823.172 ms 920.050 ms 921.612 ms 9 te8-2.ccr01.mia01.atlas.cogentco.com (154.54.28.245) 921.681 ms te8-7.ccr02.mia01.atlas.cogentco.com (154.54.1.185) 703.270 ms te8-2.ccr02.mia01.atlas.cogentco.com (154.54.2.153) 730.152 ms 10 te0-0-0-5.ccr21.atl01.atlas.cogentco.com (154.54.30.33) 797.769 ms te2-1.ccr02.atl01.atlas.cogentco.com (154.54.3.25) 913.513 ms te0-1-0-4.ccr21.atl01.atlas.cogentco.com (154.54.24.161) 782.095 ms 11 te0-4-0-7.ccr21.dca01.atlas.cogentco.com (154.54.42.189) 814.870 ms te0-5-0-7.ccr22.dca01.atlas.cogentco.com (154.54.42.201) 815.878 ms te0-2-0-3.ccr21.dca01.atlas.cogentco.com (154.54.24.9) 912.453 ms 12 te0-5-0-6.ccr22.jfk02.atlas.cogentco.com (154.54.42.30) 913.183 ms te0-2-0-2.ccr21.jfk02.atlas.cogentco.com (154.54.26.186) 913.078 ms te0-4-0-7.ccr22.jfk02.atlas.cogentco.com (154.54.41.14) 913.268 ms 13 te2-8.ccr02.lon02.atlas.cogentco.com (154.54.30.22) 833.515 ms te0-4-0-7.mpd22.jfk02.atlas.cogentco.com (154.54.41.30) 702.568 ms te0-4-0-7.ccr22.bos01.atlas.cogentco.com (154.54.44.50) 815.549 ms 14 te0-3-0-2.ccr21.bos01.atlas.cogentco.com (154.54.44.14) 1010.769 ms te0-1-0-5.ccr21.bos01.atlas.cogentco.com (154.54.44.30) 913.070 ms te4-8.ccr01.lon01.atlas.cogentco.com (130.117.0.186) 913.076 ms 15 te7-3.mpd02.lon01.atlas.cogentco.com (154.54.30.130) 913.495 ms te4-4.mpd02.lon01.atlas.cogentco.com (130.117.1.134) 831.442 ms te1-1.mpd02.lon01.atlas.cogentco.com (154.54.5.162) 811.198 ms 16 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.200 ms 912.636 ms te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.496 ms 17 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.344 ms 920.902 ms te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.368 ms 18 149.6.134.86 (149.6.134.86) 920.406 ms 1014.226 ms * 19 213.166.61.194 (213.166.61.194) 959.442 ms 828.583 ms 920.909 ms 20 213.135.247.42 (213.135.247.42) 1019.971 ms 78.141.177.7 (78.141.177.7) 988.848 ms 213.135.247.42 (213.135.247.42) 1011.307 ms Gregs-MacBook-Pro:~ GregIhnen$ UDP traceroute worked to Google though I still couldn't load their pages Gregs-MacBook-Pro:~ GregIhnen$ traceroute google.com traceroute to google.com (74.125.229.114), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 5.023 ms 3.971 ms 6.712 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 1471.985 ms 643.770 ms 785.534 ms 4 192.168.180.5 (192.168.180.5) 712.715 ms 704.409 ms 626.374 ms 5 10.254.253.158 (10.254.253.158) 808.083 ms 647.244 ms 619.878 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 776.534 ms 711.870 ms 640.372 ms 7 * te7-1.miami7.mia.seabone.net (195.22.199.109) 810.819 ms 731.713 ms 8 google.miami7.mia.seabone.net (89.221.41.18) 712.471 ms google.miami7.mia.seabone.net (89.221.41.74) 703.638 ms google.miami7.mia.seabone.net (89.221.41.18) 704.814 ms 9 209.85.253.116 (209.85.253.116) 822.336 ms 761.621 ms 209.85.253.74 (209.85.253.74) 709.705 ms 10 209.85.254.180 (209.85.254.180) 705.062 ms 702.723 ms 824.497 ms 11 74.125.229.114 (74.125.229.114) 712.196 ms 704.509 ms 596.077 ms Gregs-MacBook-Pro:~ GregIhnen$

5 6

RE: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand.
by Henault, Ken 08 Mar '11

08 Mar '11

HP has identified a DNS related issue with HP Virtual Connect that does not impact data traffic but does impair the manageability of Virtual Connect devices. HP is acting promptly to help customers remove this issue in the short term with an interim resolution. A permanent firmware fix will be available in the next three weeks. Customer Advisory Document ID: c02720395, March 7, 2011 is available now at the url below to resolve this issue. If you have questions or need assistance, contact HP Support in your home country. HP is committed to minimizing any impact on customer environments and to resolving the issue as quickly as possible. Download Customer Advisory Document ID: c02720395, March 7, 2011: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c027… Visit the HP Support worldwide contact list: http://welcome.hp.com/country/us/en/wwcontact_us.html

1 0

why hp bladeserver chassis have a sudden interest in thailand.
by Joel Jaeggli 08 Mar '11

08 Mar '11

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=10944762… As a potentially cautionary tale for the squatting on unused pieces of address space either in your network or applications. drive slow (and filter 22 outgoing to 49.48.46.49 until you get new firmware) joel

5 4