<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-html" lang="x-unicode"> Bernd Petrovitsch schrieb:
<blockquote cite="mid1137666343.17545.60.camel@tara.firmix.at"
type="cite">
<pre wrap="">On Wed, 2006-01-18 at 18:18 +0100, Markus Kittenberger wrote:
[...]
</pre>
<blockquote type="cite">
<pre wrap="">Um das Netz stabiler zu machen sollten wir uns eine sowieso etwas kluges
bzgl. nating etc überlegen
</pre>
</blockquote>
<pre wrap=""><!---->
Es ist ein Ziel "echte" IP-Adressen am Ende zu haben (wenn man das
will). Damit müssen die mal erhalten bleiben.
"Uplink Sponsoren" kann dann (IP-technisch) im einfachen Fall 2 Formen
annehmen - siehe andere Mail.
"Alles über den VPN" Tunnel hat den (mbMn gravierenden) Nachteil, daß
wenn ich z.B. im Inode Netz häng und der Server, von dem ich sauge auch,
daß der Traffic halt am jetzigen 0xFF-Uplink rein und rausgeht, obwohl
Source und Destination beim gleichen Provider sind.
Da ist "NAT lokal" raus mbMn das kleinere Übel.
</pre>
</blockquote>
Ja, Echte IP Adressen sollten weiterhin möglich sein<br>
<br>
Alles über VPN ist macht nichts stabiler denn wenn der uplink z.B.:
abbrennt oder etwas harmloseres mit gleichen auswirkungen (-; dann
"brennen" alle VPN-Uplinks mit ab, nebenbei kostet es den Uplinks in
Summe die 3 fache Bandbreite (und höhere Latenz).<br>
gegen das "abbrennen" hilft BGP4 natürlich am besten<br>
<blockquote cite="mid1137666343.17545.60.camel@tara.firmix.at"
type="cite">
<pre wrap="">3. Möglichkeit: Mit 0xFF-IP-Adressen über einen Uplink direkt
rauszugehen (so wie am Vivi) erfordert zwingend, daß Du (bzw. eigentlich
0xFF) BGP4 mit dem Uplink-Provider bei Dir spricht (und ich es gibt mWn
noch keine Erfahrungsberichte, ob und wie verschiedene Provider
reagieren, wenn man am Helldesk mit "Ich würde gerne BGP4 mit euch
sprechen." deponiert). Ob der dann 0xFF-Netze auch nach außen announcet
(und damit Transit zuläßt oder nur rein/rausläßt) oder nicht, ist dann
schon das kleinere Problem.
</pre>
</blockquote>
Was passiert aber dann in der Praxis?<br>
Wenn A,B, und C 0xFF announcen (es gibt auch VPN Tunnels AC und AB)<br>
Wenn jetzt User 1 über B rausgeht, kommt dan der Traffic zu ihm auch
immer über A zurück oder gleichmässig verteilt (A,B,C)?<br>
<br>
Ist das zweite der Fall dann könnte diese Lösung den VPN Traffic sogar
trastisch erhöhen falls User 1 nur selten/schlecht/langsam über WLAN zu
erreichen ist, dann muss der Response im worst Case durch 2 Tunnel zu B
und von dort dann zu User 1<br>
<br>
Oder anderes Beispiel<br>
<br>
Und bei den Uplinks der (Halb-)Funkinseln trifft ungefähr folgendes zu <br>
10% der oxFF Adressen sind von ihnen direkt zu erreichen 90% meist nur
(gut) über Tunnel<br>
<br>
Wenn so eine Insel nun aber 0xFF announct und folgedessen dann 30% der
Requests/Responses nach 0xFF bekommt wird ziemlich viel davon erst
recht wieder durch den Tunnel müssen<br>
<br>
(Falls obiges unnachvollziehbar ist kann ich notfalls auch ne Skizze
davon machen)<br>
<br>
Oder seh ich da jetzt schwarz und auch ausserhalb 0xFF wird dynamisch
genug gerouted so das sich intelligente Routen (zu einzelnen Hosts
innerhalb des 0xFF subnets) von selber laufend ergeben ???<br>
<blockquote cite="mid1137666343.17545.60.camel@tara.firmix.at"
type="cite">
<blockquote type="cite">
<pre wrap="">Ist halt seltsam wenn man manchmal hinter ner Firewall hängt und
manchmal ne offizielle IP hat (je nachdem über welchen uplink man
rausgeht)
</pre>
</blockquote>
<pre wrap=""><!---->
Ja, aber mbMn sollte man das so gut wie selten bis nie merken. Mit SIP
o.ä. komplexen Prokollen wird es zwar mehr Probleme geben können wie mit
http, aber man kann nicht alles haben.
</pre>
</blockquote>
Für mich selber hab ich keine Bedenken, nur für die Nodes in der mitte
zweier uplinks, deren IP kann sich dank des dynamischen routings
schnell mal ändern (je nachdem welchen Uplink sie verwenden)<br>
<br>
Alternativ könnte man http und andere unhagliche Protokolle/ports naten
und ssh, ftp, und weitere Problemfälle via VPN abwickeln, es sei denn
der VPN Tunnel reisst ab, dann sollte man idealerweise sofort auch
diesen Traffic naten.<br>
Das würde dann auch obiges Problem nicht aufkommen lassen, weil die
Responses zu den genaten request ihren Weg schön sauber zurückfinden<br>
Auch ein "abbrennen" des jetzigen Uplinks würde zumindest Teile des
0xFF Netzes nur teilweise treffen (internet ist noch da, über seine
offizielle IP ist man nicht aber mehr erreichbar)<br>
<br>
Ob teilweises naten bei den Reponses von Servern innerhalb 0xFF auch
immer hinhaut ist eine anderes Problem, evt. wärs besser http responses
nicht zu naten sondern nur die requests.<br>
<br>
Allerdings wird das Routing dieser VPN+NAT Hybridlösung an den
(Halbinsel-)Uplinks dann schon etwas sofisticated, während die VPN
ueberall lösung überzeugend simpel ist<br>
<br>
Aber wer simple Lösungen will wo man selber nicht drüber nachdenken
muss, ist bei chello et al eh bestens aufgehoben<br>
<br>
Interressant wäre jetzt wieviel Traffic die einzelnen Protokolle/Ports
zurzeit verbrauchen<br>
Gibts darüber schon statistiken?<br>
<br>
</div>
</body>
</html>