xdsl@home MultiUser - ist NAT schneller als VPN (pings)?

Alle technisch orientierten Fragen und Diskussionen rund um Internet-Zugänge via ADSL und xDSL (alle DSL-basierenden Technologien).
Forumsregeln
Alle technisch orientierten Fragen und Diskussionen rund um Internet-Zugänge via ADSL und xDSL (alle DSL-basierenden Technologien).

Diskussionen ĂĽber Provider (deren Produkte und Dienstleistungen) werden im Bereich PROVIDER gefĂĽhrt.

xdsl@home MultiUser - ist NAT schneller als VPN (pings)?

Beitragvon cyborg » Di 12 Okt, 2004 15:15

Hi!

Bis gestern hatten wir noch xdsl@home 1500 NAT, weil es falsch eingerichtet wurde.
Heute morgen wurde es dann korrekterweise auf VPN umgestellt.

Nun habe ich mal CounterStrike um 15-16 Uhr getestet aber die Pings waren extrem sch****

Als wir NAT hatten trat das Problem nur auf, wenn wer was im Netz runter geladen hat.

Bandbreite passt vollkommen: 1.6 MBits im Speedtest von Chello.

Aber die Pings und Zugriffe auf die Seiten waren total im Eimer.

Kann es sein, dass bei VPN das Pingen darunter leidet?
Ist jemandem sowas aufgefallen?

Homepagezugriffe und Counterstrike laggen etwas. wĂĽrd mich interessieren woran das liegt.

mfg
cy
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Beitragvon cyborg » Di 12 Okt, 2004 15:30

Code: Alles auswählen
C:\>ping ping.inode.at -t

Ping ping.inode.at [195.58.160.103] mit 32 Bytes Daten:

Antwort von 195.58.160.103: Bytes=32 Zeit=182ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=77ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=25ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=24ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=151ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=21ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=23ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=27ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=21ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=23ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=23ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=31ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=43ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=33ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=24ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=565ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=23ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=23ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=20ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=24ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=77ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=27ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=21ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=77ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=23ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=24ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=21ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=573ms TTL=62
Antwort von 195.58.160.103: Bytes=32 Zeit=22ms TTL=62

Ping-Statistik fĂĽr 195.58.160.103:
    Pakete: Gesendet = 47, Empfangen = 47, Verloren = 0 (
Ca. Zeitangaben in Millisek.:
    Minimum = 20ms, Maximum = 573ms, Mittelwert = 56ms
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Beitragvon Krieger_79 » Di 12 Okt, 2004 16:11

alter schaut ja aus wie bei mir :D

nur das dein minimum ping auch mal unter 50 gekommen ist :D
und alle pakete angekommen sind :D

*fortschritt* :D :D

GRUSS :ok:
Krieger_79
Profi-User
Profi-User
 
Beiträge: 1861
Registriert: Di 03 Feb, 2004 15:27
Wohnort: Graz - Wetzelsdorf

Beitragvon cyborg » Di 12 Okt, 2004 16:30

Unter Linux erreiche ich einen besseren Durchschnitt, aber manche pings gehen auch ĂĽber 200 hinaus.

42 Packets
rtt min/avg/max/mdev = 22.975/32.955/214.299/29.932 ms

dass linux bessere netzwerkbehaviours hat ist mir schon klar. Liegt es an der Tageszeit oder hab ich einen Trojaner? Puh... muss mal checken.
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Beitragvon cyborg » Di 12 Okt, 2004 17:12

also trojaner scheint es keiner zu sein
und eine average von 30-40 ms unter linux mit zacken rauf auf 200 sind schon ne menge.
fĂĽr einen pingserver beim isp

CS geht mit pings von 30-2000, meist um die 200-500

Also:
(das gilt vor allem fĂĽr inode mods und netzwerk-absolutchecker)
bitte sagt mir ob VPN mehr ping macht als NAT. Weil dann war es ein Fehler VPN zu nehmen, wenn NAT viel schneller ist.

Weil es mit NAT vieeel schneller ging vom Ping her, kann ich es nicht glauben, dass es an etwas anderem liegt!
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Beitragvon jutta » Di 12 Okt, 2004 17:21

ob es in punkto pings einen unterschied zwischen nat und vpn gibt, kann ich dir nicht sagen, aber es duerfte da ein temporaeres problem im 21. bezirk geben - ich hab naemlich heute auch zwischendurch immer wieder hoehere latenzzeiten. sonst ist das nicht der fall.

Code: Alles auswählen
jutta@ASCOT:~$ ping -Rv inode.at
PING inode.at (195.58.161.3): 56 data bytes
64 bytes from 195.58.161.3: icmp_seq=0 ttl=60 time=60.6 ms
RR:    ASCOT.MSHEIMNETZ (192.168.0.4)
   83-64-18-170.dynamic.xdsl-line.inode.at (83.64.18.170)
   83-65-78-45.dynamic.xdsl-line.inode.at (83.65.78.45)
   bord-gb-04-003.shuttle.vien.inode.at (62.99.171.38)
   viec-vl-00-003.shuttle.vien.inode.at (195.58.161.8)
   ns2.inode.at (195.58.161.3)
   ns2.inode.at (195.58.161.3)
   viec-gb-05-004.shuttle.vien.inode.at (62.99.171.37)
   83-65-78-33.dynamic.xdsl-line.inode.at (83.65.78.33)
64 bytes from 195.58.161.3: icmp_seq=1 ttl=60 time=30.4 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=2 ttl=60 time=293.7 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=3 ttl=60 time=25.6 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=4 ttl=60 time=25.3 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=5 ttl=60 time=24.6 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=6 ttl=60 time=25.0 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=7 ttl=60 time=45.2 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=8 ttl=60 time=29.4 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=9 ttl=60 time=25.3 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=10 ttl=60 time=25.9 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=11 ttl=60 time=24.8 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=12 ttl=60 time=34.9 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=13 ttl=60 time=232.8 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=14 ttl=60 time=236.3 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=15 ttl=60 time=69.7 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=16 ttl=60 time=25.6 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=17 ttl=60 time=25.2 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=18 ttl=60 time=26.4 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=19 ttl=60 time=24.5 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=20 ttl=60 time=25.8 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=21 ttl=60 time=24.9 ms   (same route)
64 bytes from 195.58.161.3: icmp_seq=22 ttl=60 time=25.1 ms   (same route)

--- inode.at ping statistics ---
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max = 24.5/60.3/293.7 ms


das hat mich allerdings in keiner weise behindert (die ssh-verbindung hat bombenfest gehalten - ich mach das naemlich remote) und bei einem kontroll-ping eine halbe stunde spaeter war es schon wieder viel besser.
jutta
Administrator
Administrator
 
Beiträge: 30485
Registriert: Do 15 Apr, 2004 10:48
Wohnort: wien

Beitragvon cyborg » Di 12 Okt, 2004 18:38

hast du nat oder vpn
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Beitragvon cyborg » Di 12 Okt, 2004 19:12

was auch immer meinen lag verursacht, es geht ständig rauf und runter.

es kann also nicht rein die leitung sein... immerhin, es geht einige minuten super, dann geht der ping rauf auf unendliche höhen, dann geht es wieder runter.

wenn ich einen konstanten sch****ping hätte wie bei chello, naja, dann würde mich das trösten, aber so...

und das problem war gestern mit nat noch nicht da...

ein königreich für einen techniker!
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Beitragvon jutta » Di 12 Okt, 2004 20:03

> hast du nat oder vpn

ich hab einzelplatz
jutta
Administrator
Administrator
 
Beiträge: 30485
Registriert: Do 15 Apr, 2004 10:48
Wohnort: wien

Beitragvon hannibal218bc » Di 12 Okt, 2004 21:17

So wie ich das sehe,


ist der Unterschied zwischen NAT und VPN der, dass bei VPN *dein* Rechner die VPN-Verbindung herstellt, und bei NAT macht das Kasterl von Inode das VPN.

Eigentlich mĂĽsste also beides gleich schnell sein.


lg
-hannes
hannibal218bc
Senior Board-Mitglied
Senior Board-Mitglied
 
Beiträge: 382
Registriert: Mi 18 Aug, 2004 21:11
Wohnort: Wien

Beitragvon dfx » Mi 13 Okt, 2004 05:45

es gibt ja immer wieder zu lesen, daß es helfen soll, die scheduling priorität des spiels runterzusetzen. das würde drauf hindeuten, daß windows intern ein prioritätenproblem mit der vpn-tunnelung hat. so gesehen kann es schon einen unterschied machen, wenn die einwahl eine andere kiste macht. außerdem kann theoretisch firewall/virenscanner software anderes verhalten bei verwendung eines vpn-devices zeigen (reine vermutung meinerseits).
xDSL unlimited 2.320 kbit/s
Bild
Bild
dfx
Board-User Level 3
Board-User Level 3
 
Beiträge: 1368
Registriert: Do 15 Jan, 2004 19:22
Wohnort: graz

Beitragvon Bruno Ristl » Mi 13 Okt, 2004 06:42

PING ping.inode.at (195.58.160.103) 56(84) bytes of data.
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=1 ttl=62 time=14.5 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=2 ttl=62 time=14.4 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=3 ttl=62 time=14.3 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=4 ttl=62 time=14.3 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=5 ttl=62 time=14.6 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=6 ttl=62 time=15.1 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=7 ttl=62 time=14.1 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=8 ttl=62 time=255 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=9 ttl=62 time=118 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=10 ttl=62 time=14.8 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=11 ttl=62 time=14.3 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=12 ttl=62 time=15.0 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=13 ttl=62 time=14.5 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=14 ttl=62 time=14.6 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=15 ttl=62 time=16.7 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=16 ttl=62 time=15.7 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=17 ttl=62 time=14.7 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=18 ttl=62 time=13.7 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=19 ttl=62 time=14.4 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=20 ttl=62 time=14.3 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=21 ttl=62 time=13.6 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=22 ttl=62 time=14.0 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=23 ttl=62 time=695 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=24 ttl=62 time=14.4 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=25 ttl=62 time=14.8 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=26 ttl=62 time=14.3 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=27 ttl=62 time=14.1 ms
Resultat hier in Leonding (Linz). Ich spiele kein Counterstrike (mehr). Inode Einzelplatz.

PING ping.inode.at (195.58.160.103) 56(84) bytes of data.
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=1 ttl=59 time=9.87 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=2 ttl=59 time=8.46 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=3 ttl=59 time=7.86 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=4 ttl=59 time=7.82 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=5 ttl=59 time=8.02 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=6 ttl=59 time=7.84 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=7 ttl=59 time=7.72 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=8 ttl=59 time=8.00 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=9 ttl=59 time=7.45 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=10 ttl=59 time=7.74 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=11 ttl=59 time=7.79 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=12 ttl=59 time=8.03 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=13 ttl=59 time=7.29 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=14 ttl=59 time=7.82 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=15 ttl=59 time=8.43 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=16 ttl=59 time=7.93 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=17 ttl=59 time=7.80 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=18 ttl=59 time=7.80 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=19 ttl=59 time=8.00 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=20 ttl=59 time=7.69 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=21 ttl=59 time=7.98 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=22 ttl=59 time=7.99 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=23 ttl=59 time=8.08 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=24 ttl=59 time=7.63 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=25 ttl=59 time=7.59 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=26 ttl=59 time=229 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=27 ttl=59 time=7.72 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=28 ttl=59 time=8.01 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=29 ttl=59 time=7.60 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=30 ttl=59 time=7.84 ms
64 bytes from ping.inode.at (195.58.160.103): icmp_seq=31 ttl=59 time=7.80 ms
Resultat in Linz Zentrum.
Bruno Ristl
Junior Board-Mitglied
Junior Board-Mitglied
 
Beiträge: 68
Registriert: Di 24 Jun, 2003 07:46
Wohnort: Linz

Beitragvon cyborg » Mi 13 Okt, 2004 12:21

dfx hat geschrieben:es gibt ja immer wieder zu lesen, daß es helfen soll, die scheduling priorität des spiels runterzusetzen. das würde drauf hindeuten, daß windows intern ein prioritätenproblem mit der vpn-tunnelung hat. so gesehen kann es schon einen unterschied machen, wenn die einwahl eine andere kiste macht. außerdem kann theoretisch firewall/virenscanner software anderes verhalten bei verwendung eines vpn-devices zeigen (reine vermutung meinerseits).


ICh schätze das hängt mit dem mysteriösen QoS zusammen, dass ich nicht aus dem ganzen rauskrieg. Leider finde ich nirgends Einstellungsparameter für diese Dinge. Windows ist ja nicht die Übersicht in Person.

Eine andere Fehlerquelle könnte die MTU sein. Vielleicht würde eine niedrigere MTU höhere Pings erzeugen. Muss ich noch probieren. derzeit ist der grösste Datensatz 1372 Bytes. d.h. die eingestellte MTU von 1400 (1372+28).
Keine Ahnung ob das MTU was nĂĽtzen wĂĽrde, aber ich habe auch keine Ahnung wo ich das bei PPTP umstellen soll. Immerhin PPPoE oder Network ist dokumentiert, aber die WAN Miniport Treiber von PPTP haben in Windows so viel Dokumentation: {}

Auf jeden Fall glaube ich mittlerweile dass di eschlechten Pings von Windows abhängen. Obwohl mein Rechner ja eigentlich gut konfiguriert ist...

Aber auf die Pingwerte unter 12 ms wie die in Linz komm ich nicht. Derzeit ist ping ping.inode.at meist 22-30, hin und wieder aber selten 200 oder mehr fĂĽr ein einzelnes Package...
cyborg
Neu im Board
Neu im Board
 
Beiträge: 22
Registriert: Di 12 Okt, 2004 15:11
Wohnort: Wien

Re: xdsl@home MultiUser - ist NAT schneller als VPN (pings)?

Beitragvon gruber » Mi 13 Okt, 2004 13:23

cyborg hat geschrieben:Kann es sein, dass bei VPN das Pingen darunter leidet?
Ist jemandem sowas aufgefallen?


theoretisch sollte da kein unterschied sein.
entweder hat der router ein bisschen arbeit oder das windows-vpn.

in der praxis zeigt sich jedoch immer wieder, dass es besser ist einen guten router zu verwenden, da insbesondere windows pcs häufig mit dem gleichzeitigen betrieb von vpn und ressourcenintensiven applikationen ein problem haben.

leider hast du dann die ĂĽblichen inode-routerprobleme. :(
inode xdsl - das so viele probleme macht, die ich vorher gar nicht kannte
gruber
Board-Mitglied
Board-Mitglied
 
Beiträge: 1853
Registriert: Do 27 Nov, 2003 22:22
Wohnort: AT

Re: xdsl@home MultiUser - ist NAT schneller als VPN (pings)?

Beitragvon superracer » Mi 13 Okt, 2004 13:34

gruber hat geschrieben:... da insbesondere windows pcs häufig ... ein problem haben.


und wer ist schuld?

natĂĽrlich inode!

und nicht etwa windows...

:rotfl:
superracer
Board-User Level 3
Board-User Level 3
 
Beiträge: 1073
Registriert: So 04 Jul, 2004 11:18

Nächste

ZurĂĽck zu ADSL & xDSL

Wer ist online?

Mitglieder in diesem Forum: Yandex [Crawler] und 151 Gäste