<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bernd Petrovitsch schrieb:
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">Was passiert aber dann in der Praxis?
Wenn A,B, und C 0xFF announcen (es gibt auch VPN Tunnels AC und AB)
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)?
</pre>
</blockquote>
<pre wrap=""><!---->
Das hängt von den Routern ab (angefangen beim Sender), wo die Pakete
vorbeikommen.
Es kann also durchaus sein, daß User 1 (d.h. die IP Pakete von ihm) über
B rausgehen und die Antworten alle über C zurückkommen, weil auf der
anderen Seite ein Router entscheidet, daß über C zu schicken (weil es am
billigsten, unbelastesten, etc. ist).
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
Dafür bleibt aber alles (logisch und IP-Routning technisch) im
0xFF-AS/Netz.
Kein Vorteil ohne Nachteil;-)
</pre>
</blockquote>
Somit ist aber das Argument des sparsameren Umgangs mit der Bandbreite
der Uplinks eigentlich recht vage bis falsch?<br>
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Oder anderes Beispiel
Und bei den Uplinks der (Halb-)Funkinseln trifft ungefähr folgendes
zu
10% der oxFF Adressen sind von ihnen direkt zu erreichen 90% meist nur
(gut) über Tunnel
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
</pre>
</blockquote>
<pre wrap=""><!---->
Ja, kann auch passieren.
Wie die Rounting-Policies tatsächlich ausschauen und wie das im
wirklichen Leben wirklich funktioniert, müssen andere erzählen - ich
kenn' nur die Theorie.
[...]
</pre>
<blockquote type="cite">
<pre wrap="">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 ???
</pre>
</blockquote>
<pre wrap=""><!---->
Nein. Zwischen AS (ist BTW d. Abk. f. "Autonomous System") wird idR
nichts automatisch geroutet. Ein AS ist eine administrative Einheit
(z.B. ein ISP oder eine Uni oder ...) und die macht Verträge mit anderen
ASes über "welcher Verkehr geht, rein, welcher geht raus und welcher
geht durch und mit welchen Bandbreiten über welche Leitungen".
Und das wird idR händisch/semi-automatisch in Konfig-files geschrieben,
weil ja idR Geld dranhängt. Und ein anderes AS kann (und will) nicht die
Border-Routing-Policy dynamisch vom inneren Zustand der/des Target-AS
ändern (zum einen gibt es mWn keine Protokolle für diesen Zweck und
Fehler suchen wird noch lustiger, wenn noch mehr dynamisch geht).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<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>
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap=""><!---->
Yup, das ist ja Sinn und Zweck von dynamischen Rotuing (daß idR
innerhalb eines AS geschieht und das vollautomatisch mit
Routingprotkollen wie RIP/OSPF/OLSR/... passiert. Und das geht "relativ"
einfach, weil da nur technische Fakten ausschlaggebend sind und keine
administrativen).
</pre>
</blockquote>
Die Funkinselen sind aber eigentlich eigene AS, und darum sollten sie
nicht das gesamte AS oxFF announcen da sie es ja autonom nicht
erreichen können<br>
Meine Schlussfolgerung ist also das funkinselen <b>bestenfalls naten</b>
dürfen, aber das oxFF AS <b>keinesfalls</b> announcen ansonsten wird
die Qulaität/Bandenbreiteneffizienz eher schlechter als besser, aber
auf jeden Fall wirds komplizierter.<br>
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
"Diesen Traffic" gibt es dann so nicht mehr. Wenn du ein Kabel abziehst
verschwinden die Verbindungen (nach den entsprechenden Timeouts). Viele
Services/Daemons machen automatisch ein reconnect und probieren noch mal
- aber dann ist es neuer/anderer Traffic, weil es ganz neue
TCP-Verbindungen sind.
</pre>
</blockquote>
Klar, aber wenn am Uplink ausnahmen für naten gelten, muessten diese
dann inaktiv werden falls der Tunnel weg ist.<br>
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Das würde dann auch obiges Problem nicht aufkommen lassen, weil die
Responses zu den genaten request ihren Weg schön sauber zurückfinden
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)
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.
</pre>
</blockquote>
<pre wrap=""><!---->
Das geht nicht - entweder du NATest eine Verbindung/Port/IP-Adresse oder
nicht.
Tatsächlich wird eine TCP-Verbindung über <protcol, src-ip, src-port,
dst-ip, dst-port> eindeutig identifiziert. Wenn du NATtest, dann steht
in obigem am Internet die IP-Adresse der Firewall drin (und der Rest des
Internets muß im Prinzip raten, ob du überhaupt NATtest oder nicht - die
Verbindung könnte ja auch der Webproxy *auf* der Firewall sein).
</pre>
</blockquote>
Was geht nicht?<br>
Ich meinte folgendes 2 Szenarien<br>
A: Wenn ein Browser auf port 80 ne tcp verbindung nach draussen
aufbauen will soll er genated werden<br>
B: Wenn von draussen eine Verbindung zu nem WEbserver aufgebaut wird
kommt diese durch den Tunnel herein aber die Antworten (innerhalb der
gleichen TCP Connection) sollten mbMn auch wieder über den Tunnel
zurück, ansonsten könnt das verwirrung stiften<br>
<br>
Kann man NAT so konfigurieren das es B TRaffic in Ruhe lässt, oder
gibts das problem dank der bestehenden TCP Verbindung sowieso nicht<br>
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
So ist es. Deshalb muß da mbMn jeder Interessierte selber lernen und
machen - weil er muß es auch reparieren und dazu muß man wissen, wie es
geht.
</pre>
</blockquote>
rigtig, aber oxFF-globale vorgaben wären nicht schlecht denn sonst
macht wer was und stört damit einige andere die dann erst langwierig
rausfinden müssen was /wer eigntlich schuld ist
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Interressant wäre jetzt wieviel Traffic die einzelnen Protokolle/Ports
zurzeit verbrauchen
</pre>
</blockquote>
<pre wrap=""><!---->
Wer? Ich bei mir oder ein Klischee-Sauger?</pre>
</blockquote>
Am jetzigen Uplink wär ein guter Punkt, denn wenn nur 1% gefahrlos
genated werden kann, dann kann man sich getrost sparen weiter darüber
nachzudenken<br>
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
Und warum sollten mich Probleme von Protkoll X interessieren, daß ich
gar nicht brauch?
</pre>
</blockquote>
<br>
Wenn ich oder andere nen Uplink zur Verfügung stellen will sollt man
drüber nachdenken.<br>
<br>
Wenn ich nicht nachdenken will mach ich ein VPN und es ist klip und
klar das dies KEINE Bandbreitenspende ist. (aber natürlich trotzdem
eine nützliche Funkinsel)<br>
<br>
Wenn ich aber auch Bandbreite spenden will dann sollt ich eine Lösung
finden/haben die auch wirklich einen Bandbreitengewinn darstellt ohne
dabei allzuviele Nutzungen einzuschränken!!<br>
<br>
Noch genauer nachdenken sollt ich wenn ich <b>keine</b> funkinsel bin
sondern eine Halbinsel oder innerhalb der Kernzone Bandbreite sponsern
will, denn bei ner Funkinsel können nur die an mich angeschlossenen
Nodes Probleme haben, in anderen Fällen kann ich anderen Nodes Features
wegnehmen die sie bis jetzt hatten und auch nutzten!!!<br>
<br>
Und da inzwischen einige Uplinks vorhanden bzw. im Gespräch sind wäre
nun ein guter Zeitpunkt darüber nachzudenken was am sinnvollsten ist.<br>
<br>
Darum sollte das ne Lösung sein die auch wirklich funktinoiert und nur
weil ich nur im web surf sollt ich halt nicht einfach alles naten, oder
meinen Provider Fragen ob er BGP4 zulässt obwohl ich damit im worst
case alles nur schlechter machen würd.<br>
<blockquote cite="mid1137673176.17545.123.camel@tara.firmix.at"
type="cite">
<pre wrap="">
Bernd
</pre>
</blockquote>
<br>
</body>
</html>