#LinuxGER

Re: relocator

Stephan 'FlirtMan' Hermann (flirtman@love.flirt.de)
Wed, 7 Jan 1998 19:51:13 +0100

Message-ID: <19980107195113.05330@love.flirt.de>
Date: Wed, 7 Jan 1998 19:51:13 +0100
From: "Stephan 'FlirtMan' Hermann" <flirtman@love.flirt.de>
To: Ralph Niere <ralle@mvv.de>
Subject: Re: relocator
In-Reply-To: <Pine.LNX.3.96.980107142612.23817B-100000@saturn.mvv.de>; from Ralph Niere on Wed, Jan 07, 1998 at 02:28:54PM +0100

--ASg3xLB4tUQ4RcSp
Content-Type: text/plain; charset=us-ascii

On Wed, Jan 07, 1998 at 02:28:54PM +0100, Ralph Niere wrote:
: On Wed, 7 Jan 1998 schleife@colossus.dom.de wrote:
:
: > ist es nicht so, dass alle autonomen router im internet saemtliche
: > routen kennen?
: > ich weiss nur, dass man ungefaehr 64 mb ram braucht, damit so ein
: > router alle diese
: > informationen gleichzeitig im speicher halten kann. weiss da
: >jemand genaueres?
: > urls, wo ich informationen dazu finden kann? die sourcen von gated
: >sind so gross. *zitter*
:
: Ich weiss net ob das direkt weiterhilft, aber in den Releasenotes zu Squid
: 1.2 steht drin als new feature:
:
: - Routing requests based on AS numbers.

Well...es ist nicht so das alle autonomen router saemtliche routen
kennen. Das waere auch absolut uebelst fuer die Ciscos ;)

Beispiel (direkt aus unserem Haus hier):

AS6783 == EBN

Unsere Cisco in unserem Backbone announced alle IP-Netze von uns
nach UU.NET.
Der Cisco wird gesagt, alles was nicht irgendwo reinpasst, wird an
uu.net (default originate) geleitet.
Jetzt gibt es da noch unsere DE-CIX Cisco, die mit div. anderen
ISPs peerings aufgebaut hat, und die kennt jetzt alle routen von
den dt. ISPs die ans CIX angeschlossen sind, entweder direkt oder
ueber den borderrouter des de-cix.
Intern gleichen sich die beiden router (de-cix und ebn-backbone
cisco) ab. Jedes Netz wird jetzt mit den AS Nummern verknuepft, und
wenn ich z.B. nach DPN will, dann geh ich ueber CIX...will ich nach
T-Online geht man ueber usaland.
Unsere backbone cisco weiss aber nix von den BGP Tables von UU.NET
(das waere auch ein wenig zuviel, obwohl das ding schon bis oben
hin ausgebaut ist).
Jetzt kommt noch diesen monat (hoffe ich zumindest ;)) eine ebone
strecke dazu. Von denen werde ich wieder bgp tables bekommen, und
alles was in diese routen reinpasst wird ueber ebone geschoben.
Nun....Problem: es gibt doppelte routen...well.
Wie loest man das Problem ? Ganz einfach metrisch
routen...d.h. wenn ich zwei gleiche netze habe, einmal ueber cix
einmal ueber ebone, nehm ich immer die billigste strecke, naemlich
cix. alles andere geht dann ueber ebone oder wenn es in den ebone
tables nicht drin ist, gehts ueber usaland.

Durch solch eine Vorgehensweise beim BGP routen, spart man
konsequent speicher, und verwaltungsaufwand. Was waere wohl, wenn
von UU.NET alle moeglichen AS Nummern kommen wuerden...da haette
ich viele Filterlisten zu schreiben, und viele metriken
einzurichten.

Warum Squid jetzt ein ein AS Based routing einsetzt, ist mir
schleierhaft, weil das wahrscheinlich jeder BGP router besser loesen
kann.
Einen Gated einzusetzen unter linux oder sonstwo ist schwachsinn. das
wuerde die performance des system total runterdruecken (wir haben es
hier mal spasseshalber gemacht).

Lieber wuerde ich mir dann eine kleine 25xx holen oder ne 16xx und
darueber das bgp laufen lassen (bitte nicht diese kleinen eingekauften
ciscos 736 oder sowas...die haben weder nen ios noch koennen die BGP
geschweige denn ospf).

IMHO ist die vernueftigeste Loesung einen solchen Relocator zu
realisieren, diejenige die Korn (war er doch) vorgeschlagen
hat. Anhand der RegExp Moeglichkeit im Apache koennte man redirects
auf den naechst gelegenen server bringen, wenn man alles unter einer
domain haben moechte.

eine weitere moeglichkeit waere ein switching der dns eintraege in
geringen abstaenden, aehnlich wie es uu.net mit ihrem news.uu.net
macht, der ist naehmlich alle 2 minuten ein anderer...aber das ist ja
auch nich sinn und zweck der geschichte, denn es soll ja
laenderspezifisch sein.

*oops* doch soviel ;)
sh

--ASg3xLB4tUQ4RcSp
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
Comment: Waiting for PGP5.0i

iQCVAwUBNLPOoOPPfOiqGZ2ZAQF0mQP/WkA3ewhagxjcaudnF1+bfdqXcPzNJnnA
QoRI87L2xYmt5QtNPCMH1+7bcSnV1kvgnZX851BkXoXt7Ivemfb1yNFwM9yOHHkO
Taf14vr5ublHsTYnwbbqn15xsnUymJ2kqyKnEU044vzl/qaQgvQms/PxDgxpumtZ
4DBz3lrOa5E=
=aS9F
-----END PGP SIGNATURE-----

--ASg3xLB4tUQ4RcSp--


This archive was generated by hypermail 1.02.