I was just thinking (dangerous, I know) and wondering how much extra paths to a known prefix affected the size of the routing tables under BGP. More specifically, under Cisco's implementation of BGP. The trend seems to be toward everyone multihoming for 1) stability/fault tolerance (yes, I know it's only really fault tolerant if you have separate paths and etc, but thats not the point - the trend is) and 2) shorter paths (hop counts) to disparate net.places. The hierarchial model of the net with a few big providers at the top with smaller and smaller providers underneath until you get to the the base customer is just not where we're headed (IMHO). I think we're headed more toward a fully connected graph of AS's (though we may never get there, of course - probably an asymptotic approach). So my question is, how will current routers (and routing technology) handle this? well? not well? If all the ASs in existance were to suddenly peer with each other, what would happen? would BGP explode? Massive CPU crunch? What effect would route flaps then have? Stumbling blindly through the fog, --Zachary
Today I multihomed a customer using only two disjoint PA spaces. PA1 PA2 P1---=---Wall---=---P2 | ------ RFC1597 | Server "Wall" speaks GateD and collects full routing from P1's and P2's wires, which in my case are "null hub" 10BaseT cables since both providers are located at DEC PAIX, along with this customer. "Wall" runs a Squid proxy in "accelerator mode". "Wall" and "Server" are on an RFC1597 net. I don't have full routes from both providers at this hour, but that's the easy part (my own firewall collects full routes from 6 providers now and does it in 64MB of RAM with some left over, so far.) "Wall" has to run a DNS server and "Server" has to resolver through it. "Wall" has to run Sendmail in "proxy to Server" mode, and Server has to run Sendmail in "Wall is the smart host" mode. "Wall" uses the "socket" command to make Telnet go straight through to "Server". "Wall" also acts as an NFS server for "Server" so that they can share an FTP "/incoming" area for external content updates. It turns out that Squid's accelerator is observably quicker to come up with the fancy GIFs this site likes to export, than the real Netscape Commerce server is. Even though "Server" has quite a lot more computrons inside of it than "Wall" has. So don't let's talk any longer about multihoming requiring PI space. I did this whole thing with an almost-stock BSD/OS 2.1 system (other than the "socket" command which is off the net from way back.) (I have no idea why I undertook this project, I've got code to write...)
Hi, Paul A Vixie wrote:
So don't let's talk any longer about multihoming requiring PI space. I did this whole thing with an almost-stock BSD/OS 2.1 system (other than the "socket" command which is off the net from way back.)
Yeah, application-level multihoming is great, considering most folks only need a couple of applications. :) Also, it is very applicable for our part of the world, where bandwidth costs are humongous, and BGP- capable routers come at inflated prices. -- miguel a.l. paraz <map@iphil.net> http://www.iphil.net/~map/ PGP: 0x43F0D011 iphil communications: isp/intranet design and implementation, makati city, ph
participants (3)
-
Miguel A.L. Paraz
-
Paul A Vixie
-
Zachary DeAquila