Is the Internet Shutting Out Independent Players? 357
"ISPs aren't advertizing routes for competing ISPs, and since IP blocks are heavily filtered upstream, this won't do much good anyway. The reasons for this are clear (Routing table growth was getting way out of hand), hence the introduction of CIDR ? , and the allocation of IPs to ISPs, with a resulting lockout on availability of routable IP space to individuals or smaller groups.
With the availabilty of IPv6, and the cost of RAM, I find it somewhat hard to believe that either IP address blocks are scarce, or that the size of routing tables are unmanageable any more. This might have been true with an 8MB Cisco 10 years ago, but surely it would be a negligible cost to put 1-2GB of RAM on even a reasonably budget router at todays prices.
Obviously, IPV6 isn't really here yet, but i would like to think that when (if) it arrives, we will see a more open routing system.
Is anybody working on returning some kind of equal standing to 'the little guys' when it comes to internet routing infrastructure, and how a more 'open' system could work in practice on tomorrow's (or today's) internet?"
Re:You can buy multi-homed connections. (Score:2, Informative)
jorge
Old routers? (Score:5, Informative)
Here in the US there is similar requirments, BackBone providers often filter routes at a
IPv6 a problem for many routers (Score:3, Informative)
for prime time.
There are many high-end routers that cannot deal
with IPv6 and will not be able to without a hardware upgrade, as they use ASICs to store tables of IP addresses and those ASICS expect four bytes.
IPs for the elite? (Score:5, Informative)
It's true, you can't get portable IPs of your own anymore. The advent of CIDR and the segregation of netblocks were in an effort to reduce global routing tables.
Putting in 1-2Gb of memory in a router is still incredibly prohibitive. It just can't be done in the mainstream (common) routers.
You can still be multi-homed with netblocks from one ISP to be received by another. This happens this way in the US, and I'm sure it happens with APNIC and RIPE-issued blocks. You get the same effect, without all of the hassles of truly having your own blocks. At least we don't have the /19 barrier for advertising that used to be prevalent in larger ISPs. There is some give and take. The give on that is that the larger ISPs have gone to regional aggregates.
For instance, I don't want to have to pay for my addresses in the US now thanks to ARIN. (Don't get me started.) My ISP takes care of that. The justification process of getting addresses isn't fun, but it's a lot better than the Inquisition your provider has to go through. I'm not saying that economy is bad, but it's a fact of life with IPv4.
It's possible that controls will be loosened in an IPv6 world, but I don't think so. We've been down that path before. With tiny fragmented blocks of IPv6, we're creating a nightmare of routing tables the likes of which we've only imagined with IPv4. Aggregation is here to stay, and I beleive the days of the portable netblock are long gone.
Of course, if you can justify your need for your own blocks, you can go directly to your registry. If not, isn't it enough to have your networks SWIPed to you?
The days for "vanity" addresses are long gone. Maybe you should think up a clever .com domain name instead while you still can.
Re:You've hit the nail on the head ! (Score:1, Informative)
Use a WAN (Score:3, Informative)
Why waist an entire set of IPs when you can NAT off your network and pay the local phone company o connect bothe sites over a leased line then you can have access to the 10.x.y.z reserved IPs. then you can have as big a network as yuou want. you could also put another NAT at the other end so as not to over load the first.
Sounds a bit silly (Score:2, Informative)
I've just had some first-hand experience of this with Worldcom, ESpire and AT&T. Worldcom were more than happy to allocate us a 'class C' so we could run BGP without getting filtered upstream. (This appears to be the smallest block that gets routed these days.)
Each and every one of these ISPs sold us dedicated connections boasting how many peering arrangements they had with each other and when it came time to route, no problem.
Maybe that's the cutthroat ISP biz in the US, I'm quite surprised that it's not the case in NZ.
The size of routing tables is quite big. In fact you generally require the entire use of a T1 just to manage the updates of a full table. That's why it's typically ISPs that do this kind of thing.
One other solution they all put forward was to purchase connectivity from each of them and let them do the BGP over the lines. I thought this was quite cooperative of them, to send your traffic via another provider if their link went down.
Hmmm.
Routers, Upgradability, Etc. (Score:4, Informative)
First of all, one should note that IPv6, while supported in newer versions of Cisco IOS, has the slight problem that in BFRs, the hardware accelerated routing hardware has four times more work to do to look up a 128 bit IP address making performance somewhat of a problem. Add to the fact that a lot of the routers out there simply can not be upgraded past 128 MB of RAM and you run into a slight problem when you go to make your $150k router IPv6 capable.
Then there is the little problem of client operating systems and the "migration" to IPv6. As there are only a handful of people on this planet who use IPv6 exclusively, routers will have to support both until all the client software of the world moves over. Now, it is bad enough getting full IPv4 BGP updates, but getting them *AND* IPv6 updates?
Of course, next comes all the little hardware out there. From the terminal servers people dial up to, to the layer 4 load balancers, there is a lot of hardware that doesn't support IPv6.
So, as a large network service provider, one would have to justify the costs associated with IPv6 against the benefits. The benefits are pretty slim right now unfortunately. Ideas like a single roaming IP (pipe dream if you ask me), mandatory multicast/anycast support, fixed sized headers and IP level security are all fine and dandy, but when you are talking about replacing (or at least suplementing) millions of dollars in infrastructure to allow a handful of people to use IPv6 for years until the REST of the world follows, it starts becoming hard to justify.
Don't get me wrong, IPv6 has some lovely attributes, but until Cisco enables IPv6 by default on all the hardware they make, everyone upgrades their copies of Windows and MacOS to support it and all of a sudden the terminal servers of the world (remember dialup still exists) all start learning how to route IPv6 packets, it is an uphill battle.
So the question really becomes, how long will it all take? IPv6 really needs a killer application to the general public aware that they *need* it and ask their providers to provide it. Once enough demand is generated, ISPs will start asking their upstreams for it and the ball will start rolling.
The same problems have plagued multicast for some time and still, very few providers support it and even fewer have customers who use it.
Of course, that's just my opinion, I could be wrong.
multihoming defined (Score:5, Informative)
multihoming involves connecting to 2 or more isps and BGP publishing your ip space through both of them. this (ideally) involves having your own ARIN assigned ip space & AS number.
the point of multihoming is to address redunancy for inbound as well as outbound connections. you can use 2 isps + nat + creative outbound routing to handle outbound traffic, but that does nothing for a potential web server you're trying give multiple inbound paths to.
read the multihoming faq :
http://www.netaxs.com/~freedman/multi.html
Where all the IP's have gone... (Score:4, Informative)
Oversimplified (& a better way) (Score:5, Informative)
There are many issues at work:
a) Assignment of PI (Provider-Independent) addresses:
Back in '94, as an end user, you were able to get a netblock directly from ARIN. Then, this block could be advertised (by BGP4) by your upstream[s], and thus you got connectivity. The problem here lays that these IP addresses were nonaggregatable and led to exponential growth in routing table size. (see http://www.telstra.net/ops/bgptable.html up to 1994). Thus, CIDR was born, and hierarchical assignment became the rule. Your upstream (call it foo) gets the IPs from their upstream (call it bar), and the whole internet sees needs only one routing table entry to reach all of bar's customers.
b) ingress filtering (filtering of traffic from customers to make sure only the source IP that are assigned to them are used). Yes, most ISPs do ingress filtering now, and it is now considered a BCP (best current practice) to do this (there's an RFC on that). Again, this is for a damn good reason: Without filtering, DoS attacks cannot be traced to their source, if one is spoofing the source addresses. With filtering, at least you know that the source IP address is likely to be the one attack is launched from (or one of 0wned machines attacking you).
Its well known that ingress filtering makes multihoming harder, as your upstream has to open up their ingress filter for the IPs that are assigned to you by entities OTHER than your upstream (say, your other upstream).
Since apparently you intend to advertise your network via BGP4, all ISPs who will talk BGP4 to you will have no problem relaxing their ingress filters. If all you have is a DSL line, you'll have fat chance of getting your upstream to talk BGP4 in the first place. See below for strategies to do this without BGP.
c) Even if you managed to get your upstreams to turn off ingress filtering and advertise your network via BGP4, you still may run into problems because many ISPs do not listen to network announcements less than
Bottom line is: if you want to have your "own" IP address range, you must advertise it via BGP4. If you can get your upstream to do that, you can get them to relax their ingress filters, thus your original complaint is silly.
Now, if all you have is two DSL lines and no cooperation with your upstream you can do the following (sometimes called DNS-based multihoming), _for inbound traffic_:
You set up two nameservers (A and B), one on each of the IP ranges that you have (range_a and range_b). Make all of the entries given out by nameservers have TTL of 5 minutes.
Make each nameserver have a DIFFERENT zone, containing only IP addresses on that range. (Ex, nameserver A will have an entry for www pointing to an IP from range_a, nameserver B will point to an IP from range_b.(both nameservers can actually run on same machine, bound to different interfaces).
Then, whenever someone tries to reach www.yourdomain.com, they'll hit one of the nameservers. If the one they hit first is down, they'll hit the other one, and get an IP address from the _working_ network. Voila, you are still reachable when one connection goes down.
Then, if you don't want your servers to actually have two IP addresses (one on each net), you can do some trickery with iptables/ipchains to redirect traffic to a single IP (probably on private network).
For the outbound traffic: All you have to do is to NAT your traffic to the correct interface/IP range (the one that's currently working). That is not very hard to do with a bit of shell scripting.
Actually, things are a bit more complicated because of this: Your machine (main firewall or whatever) that contains all these interfaces, normally has one routing table. Choosing of the correct interface is done by lookup of DESTINATION IP. Now, assume a packet comes over to IP_B. You _must_ make sure that it will go out BACK on interface B (if you send a return packet with an IP_B source address over ISP_A, it'll discard it because of ingress filtering). This is hard: again, remember, routing does not depend on your _source_ address, it depends only on destination address.
So, how do you solve it?
Luckily, Linux has policy routing, which allows you to have multiple routing tables and choose between them based on some criteria, in your case, it will be source IP. You'll set up two routing tables, one with default route pointing to ISP A, one to ISP B, and a rule saying "If a packet has a source on IP_A, use routing table A, if not, use routing table B"
(see iproute2 documentation for details)
Well, I think I should write a HOWTO on that...I glossed over quite a lot of details here.
Router Memory II (Score:3, Informative)
Re:IPv6 a problem for many routers (Score:2, Informative)
Re:uhm... (Score:2, Informative)
holy crap! have you guys ever heard of http1.1? the reason you have such a hard time getting ips is that arin wants to cut down on webhosting companies that do not use http1.1.
i have to agree with arin on that too, with correct dns handling, http1.1 is a very viable method for webhosting and reduces both need and use of ip addesses.
btw, ipv4 is not exactly running out of ips soon. the ips are still there. they are running out of _allocatable_blocks_ of ips. if you look at the lower networks (4.0.0.0/8 is one) the utilization of ips is horrendous. older companies and organizations have been camped on huge amounts of ip addresses for the last 10-15 years. if arin bit the bullet and forced these internet first-comers (and heavy wallets) to relinquish ip space we would see the 'ipv4 crisis' go away.
like you said, "Research before whining to
More Memory Does NOT equal better routing... (Score:1, Informative)
This particular router happens to be advertising only a 22 bit summary to it's BGP neighbors, so that's it's not being used as a transit device by any of the three different ISP's to which it's connected.
103595 network entries and 103629 paths using 13779359 bytes of memory
18103 BGP path attribute entries using 943332 bytes of memory
15624 BGP AS-PATH entries using 404444 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP activity 12591567/28215562 prefixes, 16206716/16103087 paths, scan interval
15 secs
As you can see, even 128M is more than enough for route tables using a basic BGP configuration such as the one on this router.
However, route table size can be an issue, especially with slower routers. A router can only hold a packet in queue for so long before it has to drop the packet from the queue. During this packet hold time, the router must find the destination address in the packet, match that against the longest prefix in the routing table, apply any policy routing decisions, decide which interface to forward the packet to, then forward the packet out of the router to the next hop.
Obviously, the longer this process takes, the fewer packets make it through the router in any given time period, decreasing overall performance.
Yep. For example... (Score:2, Informative)
I'll say...
arachne:ckloote {101} whois -a 40.0.0.0
Eli Lilly and Company (NET-LILLY-NET)
Lilly Corporate Center
Indianapolis, Indiana 46285
US
Netname: LILLY-NET
Netblock: 40.0.0.0 - 40.255.255.255
Coordinator:
Eli Lilly and Company (ZE16-ARIN) hostmaster@lilly.com
317-277-7000
Domain System inverse mapping provided by:
DNS1I.XH1.LILLY.COM 40.255.22.1
NS1.IQUEST.NET 198.70.36.70
AUTH40.NS.UU.NET 198.6.1.18
AUTH62.NS.UU.NET 198.6.1.19
Record last updated on 17-Jul-2001.
Database last updated on 29-Nov-2001 19:56:47 EDT.
Yeah, Eli-Lilly is a big company, but please tell me why they need their own class A? They don't, but they managed to get it back in the early days, and won't give it up. I'm sure there are many more cases like this.
Re:You've got to pay to play (Score:1, Informative)
Our corporations comprise the greatest portion of the internet, and nearly all of the world's news and content comes from the US.
Our universities are the best in the world. MIT, Stanford, Cal Tech, etc are unequaled outside the US.
In the US you can get a residential highspeed internet connection just about anywhere, thanks to satellite.
The US SOCIETY has given more in the order of technology to the world than Norway, or any other country. Take your anti-americanism and shove it, its nothing but bullshit.
Re:uhm... (Score:3, Informative)
High-end routers do not use DRAM due to its high latency. DRAM works well for localized access, but is terrible for random access. In this case, SRAM is used. Now for routers, it is likely that Content Addressable Memory will be used. The largest CAMs I am aware of are 9Mb (megaBITS) and the largest ZBT SRAMS currently available are 36Mb (4MB). Granted, multiple chips can be used, but only so many chips can be placed on a memory bus before loading becomes a factor. A 133MHz bus can only have so many chips connected to it.
A high-end router today should be able to store upwards of 1,000,000 routes. With IPv6 this becomes far more difficult due to the 128 bit length of the IP addresses.
Also note that a router does a longest match lookup. Some use a hash table and populate entries when there's a miss by using the slow path, but even that becomes difficult since you don't want too many collisions.
Not that simple... (Score:5, Informative)
To be multihomed correctly you will generally need:
-a decent router that can do BGP.
-more than one connection to providers who will talk BGP with you.
-your own AS number and an allocated block of IP addresses
The expensive part is not really "paying the fees" of (ARIN, RIPE, APNIC), or complying with their conditions, but in fact having someone tech enough that also understands the POLITICS (yes POLITICS) involved in running BGP, and the ongoing cost of keeping your network in fact running in this type of situation.
You are just looking at the tip of the iceberg and saying "wow that's expensive JUST for a block of IP's", which on the surface might look correct, however:
-just about anyone can say "gimme a block please" (cheap).
-checking on who can actually utilise them or not is expensive.
Memory in routers is easily scalable (it isn't but lets pretend it is), but the problem is not lack of memory, but actually wading through all those blocks of IP addresses.
Most of the main tier 1 providers have serious filters in place to avoid filling their routing tables up with junk due to mistakes or due to people who just haven't made a transit deal with them, so even if you were "given" a block of addresses, it wouldn't always be that easy for you to get it routed.
My advice: as you are "small" (compared to a Tier 1 provider), my guess is that there are ISPs down there that will do a better job than you for getting redundancy. Spend a bit more money on linking up to one of these, and backup your link to them somehow, and trust THEM for your link instead of trying to do it yourself. It will probably cost you just about the same, but your uptime will probably be HIGHER, because when you do BGP yourself, you are adding in extra weak spots that you may at this moment not be thinking of (your internal routing policies and how they get propagated, the people you will need to make sure this runs, etc...).
Just my own opinion. Add salt.
Re:NAT? (Score:3, Informative)
Linux can do this, it has the ability to "shotgun" ethernet connections into a larger one.
However, this is not what this person wants. The problem is IP addresses and routing. In your configuration, if one of your connections die you use an IP address. If one of the connections in a multi-homed environment dies, you still want the traffic for the ips on the 2nd line to be routed to your network.
What this means is, you need cooperation by your ISPs if you wish to be multihomed. Sure, for a home-connection where you are just looking for speed, shotgunning your data is fine.. but it just isn't the solution this person needs.
Provider Independant IP Space not requiered (Score:5, Informative)
However, it's not required to multihome. Really what you require to multihome is an Autonomous System Number (ASN [arin.net]) and a
The biggest downside to using your upstream providers IP space is that it pins you to a single ISP as you must use their IP space, and leaving them requires renumbering (but can be done without downtime within a reasonable transition timeframe of a few days). What we did was pick the largest ISP out there (UUNET [uunet.com]), and then one of the top 10 (Sprint [sprintlink.net]) and use both IP space (although we could have chosen to only use UUNET's). We use both provider's IP space on any important box (email, mainly) so that if we were to disconnect from one ISP (not likely), we only have to remove their IPs from our DNS, and the other IPS's IPs are already there and live (plus it gets around odd local routing problems outside of our control, where one remote site can reach one ISP but not the other).
We announce both blocks out both ISPs (to announce UUNET's blocks out Sprint and have them come back the shortest route, we had to get UUNET to "punch a hole" in their larger block and announce the smaller block we had so that both UUNET and Sprint would be announcing equally specific blocks for us... same is true of Sprint announcing their own assignment to us more specifically so they'll route to Sprint or UUNET, as if we only announcing the smaller block out UUNET, then all traffic would go that way unless our UUNET connection was down).
Anyway, not to write a HOW-TO (see Halibi's Internet Routing Architectures [bookpool.com] ISBN: 157870233X), but that's how to do it.
You don't need a huge router to be multihomed. Even a 2501 would work (as you just take default routes announcements from both ISPs, with the point being to advertise out your own blocks). If you want to take full routes from two ISPs, a 2650 with 128mb of RAM will work fine. If you want to take defaults + ISP-direct-customers, a 2610 with 64mb of RAM will work (it handles ISP-direct-customers from Sprint and UUNET just fine for us).
Lastly, never forget that site redundancy is just as important as internet redundancy. If a backhoe takes out the fiber or copper pairs going to your neck of the woods, more than likely it'll be both ISPs.
Normally I'd never mention my certs, but here they're relevent:
I'm a CCNP (next step past CCNA) and CCDP (next step past CCDA). I've been working for an IT Consulting/Integrater firm for 4 years (help desk positions 3 years before), and we also have our own little ISP [switch.ch] on the side. I've worked with all the top 10 ISPs (and plenty of the Tier2/Tier3 folks), and set up a couple hundred of multihomed sites, so I'm not just quoting what I read in a book somewhere.
Re:IPs for the elite? (Score:4, Informative)
Again, just as he said:
You can still be multi-homed with netblocks from one ISP to be received by another.
PI-space only makes it a bit easier in transition, but it doesn't make it anywhere near as impossible as the question implys.
Re:Not that simple... (Score:2, Informative)
Re:You've got to pay to play (Score:2, Informative)
What are you basing this on? Did you make those facts up?
In the 80's Australia had the world's most advanced phone system. Even today there is better coverage with copper lines than there is with mobile phones. Cell phones (actually we got rid of cells years ago, its all GSM and some CDMA now) aren't a solution at all in most parts of the country, specifically because of the low population density.
Australians like Mobile phones because they're convenient, and they work well because that's what we've come to expect from our phone system. There used to even be advertising on Australian TV where an aussie Tourist in the US finds the mobile phone system there so appalling when compared to home.