Lukas Beeler wrote: [..]
I understand that routers use ASICs and probably faster memory than servers, but i can't really imagine it to be a problem to pop 4GB memory into a router that's connected directly to the internet.
Now, where am i mistaken?
The fact that you then also have to handle 1.000.000 updates... or can you do a Shortest-Path calculation faster than some of the bright minds on this planet? (I heared both J and C are hiring those folks with really good pay :)
See the e2e list and various other "new internet" style lists for a lot of reasons why huge routing tables will one day be an issue, unless we can keep the silicon much faster.
Reza Kordi wrote:
Hi F,
Can you define the "BGP over xDSL will flap way more"
What shall I expect here? Did you ever test this as redundancy scenario for existing BGP environments?
Depends on the stability of the DSL link, which in my case at home is pretty good (thank you Swisscom ;) If your DSL link is not stable though you will loose TCP sessions and thus BGP sessions and flapperdyflap.
But just test it in your lab: take a couple of full feeds from another box that you hook for real onto the Internet (or something which sents a similar amount of updates), then hook up another box to that and just introduce packet loss on that link: Both routers will be trying to resend packets in both directions, doing SP all the time (see above :) and of course when the session finally breaks it needs to send the full table over the link. Not even talking on how much it will affect the upstreams when you are retracting the prefix all the time...
Most DSL is then of course also asymetric (20/1 or so) which will give some nice effects too...
Fortunately one can filter BGP on ASNs and just exclude those annoying ones...
The big question of course is: WHY!? There are other better protocols for hooking up end-sites that do not affect the global routing tables.
Greets, Jeroen