Re: leitungsproblem

From: Otto Kucera <ok(at)72pixel.at>
Date: Tue, 22 Jul 2003 11:20:18 +0200

ok, also also meine zyxel bridge hat zwei interfaces:

           |
-------------------------
dsl: 81.223.0.89
gateway: 81.223.0.81
ethernet: 81.223.12.17
-------------------------
           |
           |
           |
------------------------
          HUB
------------------------
     | | |
     18 21 22
     | | |

das sourch quench kam von aussen und 10.1.0.0/24 ist mein netz zu hause.
zusätzlich muß ich noch was anmerken. wenn ich von meinen ns2 (der
störende host) einen ping losschicke dann geht die leitung für genau 3h.

otto

Olaf Hoyer wrote:

> On Tue, 22 Jul 2003, Otto Kucera wrote:
>
>
>>hi oalf!
>>
>>also bei mir liegt das problem teilweise wo anders. also ich habe einen
>>router (zyxel prestige 782 shdsl bridge/router) der auch als bridge
>>konfiguriert ist. bekommen hab ich von meinen provider ein 248 subnetz
>>wobei der gateway die ip 81.223.12.17 hat. ich selbst habe die ip
>>adressen 18, 22 und eigentlich auch 21 belegt. router und rechner hängen
>>an einer usv.
>
>
>
> Moin!
>
> Dh. der Rechner, der das eigentliche Routing macht, ist die .17
>
> Welcher Rechner verfuegt ueber 10.x.x.x IP's?
>
>
>
> Konstrukt ist also so:
>
> Internet---Zyxel (Bridge, also ohne IP)---Gateway, .17---Switch, an dem
> der Rest haengt?
>
>
> oder anders?
>
>
>
>
>>81.223.12.21 ist mein ns2. das ist ein celeron 500, 128 mb ram, 3 ware
>>raid freebsd 4.8. da läuft bind in einen chroot und täglich ein cron für
>>cvsup. ipsec ist geplant aber soweit bin ich noch nicht bekommen. das
>>letzte make world ist ohne fehlermeldung abgelaufen.
>>
>>und aus welchen grund auch immer schafft es dieses ding meine leitung zu
>>blockieren und mir bei ping einen source quench zurück kommt. ??????
>>
>>36 bytes from 81.223.0.89: Source Quench
>>Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
>> 4 5 00 5400 433e 0 0000 36 01 416c 10.1.0.18 81.223.12.18
>>
>
>
> Source Quench kommt immer dann, wenn die Gegenstelle erkennt, dass die
> Daten zu schnell kommen wuerden und bittet um reduzierung der
> Geschwindigkeit.
> http://www.freesoft.org/CIE/RFC/896/8.htm
>
>
> Was mich stoert, ist die TTL.
> Normalerweise wird mit einer TTL von 64 losgelegt.
> die TTL hier ist 36, das wuerde bedeuten, dass die irgendwie so einiges
> an Weg zurueckgelegt haben muss...
> Wo wird denn NAT gemacht?
>
>
>
>
>>ich hab den router ausgetauscht und und alle wan und vom ns2 auch die
>>lan ethernet karte und die leitung ist ziemlich schnell weg. ich bin mir
>>sicher das alle neuen komponenten in ordnung sind.
>>
>
>
> Den Switch auch ausgetauscht?
> Habe auch mal bei Kunden nen defekten Switch gesehen, der hatte zwar
> noch Link, aber es ging kein Traffic mehr rueber...
>
>
>
>>im router sieht man das die mac adressen am router ständig verschwinden
>>bzw. nur 3,4,5 dort steht. ich bin leider nicht vor ort und das problem
>>hab ich schon seit einer woche da ich der meinung war das es am provider
>>liegt. ganz sicher bin ich mir da zwar immer noch nicht aber die haben
>>schon die router auf beiden seiten der leitung getauscht und die leitung
>>durchgemessen.
>>
>
> Wenn es also ein arp-Problem ist, dann gibt es folgende Moeglichkeiten:
>
> - Immer noch irgendwo matschige Hardware (Switch, Kabel)
> - Firewallrules, die irgendwie fuer ein schnelles expire sorgen
> - Netzwerkcode des FreeBSD irgendwie kaputt
> - Firmware des neuen Routers nicht wirklich ok
>
> Wie ist der Switch beschaltet? Macht der 10/100 Autoneg, oder kann man
> den (sowie die Clients) mal fest auf z.B. 100 MBit/fullduplex
> einstellen?
> Kann durchaus sein, dass autoneg in die Hose geht und folglich arp auch
> Schmerzen hat.
>
>
>
>
> Ansonsten:
>
> gaff 10:48 >traceroute 81.223.12.17
> traceroute to 81.223.12.17 (81.223.12.17), 64 hops max, 44 byte packets
> 1 195.180.9.253 (195.180.9.253) 0.769 ms 0.648 ms 0.627 ms
> 2 ge4-0-15.br1.isham.de.easynet.net (194.163.251.124) 0.514 ms 0.453
> ms 0.457 ms
> 3 so1-0.br2.ixfra.de.easynet.net (194.64.4.102) 9.624 ms 9.680 ms
> 9.578 ms
> 4 ge5-0-0.er1.ixfra.de.easynet.net (195.179.51.101) 10.136 ms 9.933
> ms 9.928 ms
> 5 FFM-FE-0.inode.at (80.81.192.47) 10.496 ms 10.962 ms 10.711 ms
> 6 POS-2-0-0.Vienna-Frankfurt.inode.at (62.99.170.85) 24.971 ms
> 29.972 ms 24.323 ms
> 7 viech-vln-0-002.vie-shut.inode.at (62.99.171.1) 26.939 ms 25.345
> ms 24.052 ms
> 8 81.223.0.89 (81.223.0.89) 183.556 ms 191.708 ms 157.379 ms
>
>
> gaff 10:48 >traceroute 81.223.12.18
> traceroute to 81.223.12.18 (81.223.12.18), 64 hops max, 44 byte packets
> 1 195.180.9.253 (195.180.9.253) 0.897 ms 0.664 ms 0.829 ms
> 2 ge4-0-15.br1.isham.de.easynet.net (194.163.251.124) 0.657 ms 0.441
> ms 0.424 ms
> 3 so1-0.br2.ixfra.de.easynet.net (194.64.4.102) 9.805 ms 10.261 ms
> 9.733 ms
> 4 ge5-0-0.er1.ixfra.de.easynet.net (195.179.51.101) 10.028 ms 10.422
> ms 10.489 ms
> 5 FFM-FE-0.inode.at (80.81.192.47) 10.296 ms 11.214 ms 10.356 ms
> 6 POS-2-0-0.Vienna-Frankfurt.inode.at (62.99.170.85) 164.660 ms
> 169.949 ms 25.499 ms
> 7 viech-vln-0-002.vie-shut.inode.at (62.99.171.1) 25.387 ms 24.523
> ms 25.595 ms
> 8 81.223.0.89 (81.223.0.89) 180.436 ms 174.597 ms 191.678 ms
> 9 81-223-12-18.C-WSechshaus.Xdsl-line.inode.at (81.223.12.18) 178.781
> ms 172.768 ms 178.153 ms
>
>
> Sieht soweit normal aus, wobei mich allerdings die letzte Zeit etwas
> stoeren wuerde. Das koennte auf eine bis aufs brechen volle Leitung
> hindeuten, oder darauf, dass der Router nicht genug Ressourcen frei hat,
> um sauber zu funktionieren.
>
> In meiner aktiven Zeit bei meinem letzten Arbeitgeber hatte ich auch
> viel SDSL zu supporten, und die Strecke zwischen unserem Backbonerouter,
> dem Concentrator vom Anbieter (HW1 oder QSC) und dann dem Endequipment
> des Kunden (meist so 256 kbit-Lines) lag idR bei 50ms, teilweise auch
> mal bei knapp 100ms.
>
> Die Frage ist auch, wie gemessen wurde. Anders als bei einer normales
> leased-line (ISDN oder 2MBit) kann man DSL nicht so ganz einfach
> durchmessen.
> Teilweise schauen die Leute einfach mal auf die Gegenstelle, sehen dort
> keine Errors, und sagen dann bereits: alles ok.
>
>
> Olaf
>

-- 
-----------------------------------
Otto Kucera
A-1020 Wien Engerthstrasse 137/6/7
Tel: +43 699 1 942 30 91 [neue Nummer!]
Email: ok(at)72pixel.at
Icq: 65351173
-----------------------------------
And root said rm -rf /     ......and there was nothing
Your mailserver MUST resolve properly (Fully Qualified Domain Name) or 
the mail will not go through!
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 22 Jul 2003 - 11:20:59 CEST

search this site