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


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Antwort per Email an