info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
KabelBW sooo laaannngssaaamm
10 views
Skip to first unread message
Alexander Burger
Sep 6, 2014, 4:46:49 PM9/6/14
to
KabelBW ist oft unerträglich langsam.
Ist das nur bei mir so oder auch bei anderen?
Haben Leute bei anderen Providern auch solche Probleme,
oder ist das nur ein Problem von KabelBW?
Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
KabelBW nur noch.
Das sind fast schon Modem-Geschwindigkeiten.
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.
KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben. So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
nicht alle Provider haben.
Ist das nur bei mir so oder auch bei anderen?
Haben Leute bei anderen Providern auch solche Probleme,
oder ist das nur ein Problem von KabelBW?
Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
KabelBW nur noch.
Das sind fast schon Modem-Geschwindigkeiten.
Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.
KabelBW macht so groß Werbung mit 50 MBit/s usw.
Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
haben. So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
nicht alle Provider haben.
Marc Haber
Sep 7, 2014, 2:52:30 AM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
>KabelBW ist oft unerträglich langsam.
>Ist das nur bei mir so oder auch bei anderen?
>Haben Leute bei anderen Providern auch solche Probleme,
>oder ist das nur ein Problem von KabelBW?
Ich habe einen KabelBW Businessanschluß. Die erreichte Datenrate ist
>KabelBW ist oft unerträglich langsam.
>Ist das nur bei mir so oder auch bei anderen?
>Haben Leute bei anderen Providern auch solche Probleme,
>oder ist das nur ein Problem von KabelBW?
ungefähr das einzige, an dem ich nichts auszusetzen habe.
Den (zugenagelten) Router muss man so etwa einmal in der Woche
resetten, wenn Latenzen in der Größenordnung von 2 Sekunden auftreten.
Es gibt nur IPv4, kein IPv6, und der Service ist unterirdisch
mieserabel.
Gäbe es eine Alternative, die an meinem Standort mehr als 1 Mbit
Upstream liefern kann, hätte ich spätestens nach dem unangekündigten
Werksreset des Routers, der mit Verlust sämtlicher lokaler
Konfiguration einher ging, längst gekündigt.
>Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) tröpfelt es bei
>KabelBW nur noch.
>Das sind fast schon Modem-Geschwindigkeiten.
>Das war ich früher bei meinem DSL-Anschluss nicht gewohnt.
Realisierung von Kabel-Internet regional extrem unterschiedlich sein
kann. Hier[tm] ist die Performance jedenfalls in Ordnung.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ulrich F. Heidenreich
Sep 7, 2014, 4:56:28 AM9/7/14
to
Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>KabelBW macht so groß Werbung mit 50 MBit/s usw.
>Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
>haben.
Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.
CU!
Ulrich
--
Bei Amazon kauft man via http://u-heidenreich.de/Amazon
In 3 Monaten und 18 Tagen ist Weihnachten.
H3RTL WMIBD RFRB0 CECOX LWJSE VXIYI JCTK3 G5V52 TO61X
Stellt euch vor, es ist Sonntag und keiner geht hin!
>KabelBW macht so groß Werbung mit 50 MBit/s usw.
>Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
>haben.
Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.
CU!
Ulrich
--
Bei Amazon kauft man via http://u-heidenreich.de/Amazon
In 3 Monaten und 18 Tagen ist Weihnachten.
H3RTL WMIBD RFRB0 CECOX LWJSE VXIYI JCTK3 G5V52 TO61X
Stellt euch vor, es ist Sonntag und keiner geht hin!
Sven Hartge
Sep 7, 2014, 7:40:05 AM9/7/14
to
Ulrich F. Heidenreich <from!not-fo...@tremornet.de> wrote:
> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>> KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
>> alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.
> Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
> Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
> Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
> Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.
Du hast im Kabel ja nicht nur ausschließlich 50MBit für alle.
> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>> KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
>> alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.
> Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
> Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
> Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
> Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.
Pro _Kanal_ sind da bei EuroDOCSIS-2.0/3.0 50MBit möglich, und es gibt
mehr wie einen Kanal für Daten im Kabel.
<http://en.wikipedia.org/wiki/DOCSIS>
Bei EuroDOCSIS-3.0 werden Kanal auch gebündelt, um die höheren
Datenraten über 50MBit zu erreichen.
Eigentlich sollte das CMTS die Modems auf einen anderen Kanal schieben,
wenn einer voll sein sollte, aber nicht immer haben die Provider das so
eingestellt.
Was Alexander helfen könnte, wäre einmal sein
Kabelmodem/FritzBox/Whatever zu resetten, wenn es wieder tröpfelt, in
der Hoffnung auf einen anderen Kanal zugewiesen zu werden.
Falls der direkte Netzanschluss und nicht der Backbone das Problem ist.
S
--
Sigmentation fault. Core dumped.
Alexander Burger
Sep 7, 2014, 8:28:59 AM9/7/14
to
Ulrich F. Heidenreich wrote:
> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>
>>KabelBW macht so groß Werbung mit 50 MBit/s usw.
>>Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
>>haben.
>
> Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
> Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
> Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
> Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.
Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur für das Haus zur
> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>
>>KabelBW macht so groß Werbung mit 50 MBit/s usw.
>>Das nützt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
>>haben.
>
> Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
> Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
> Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40 Mieteinheiten.
> Gerade am Wochenende/Abend könnten da 50 MBit schon knapp werden.
Verfügung. Aber das gilt natürlich nur für die letzten Meter. Danach könnte
das dann mit den Nachbarhäusern geteilt werden. Aber KabelBW hat Glasfaser-
Kabel. Da sollten doch keine Engpässe auftreten, oder?
Ich vermute eher, dass der Anschluss von KabelBW dann ans Internet sehr
klein dimensioniert ist, was für KabelBW günstiger ist, als sich an eine
fette Leitung einzumieten. In Stoßzeiten wird das aber dann zum Nadelöhr.
Gerade in Zeiten mit geringem Internetverkehr z. B. nachts, sind die
Geschwindigkeiten dann auch wirklich hoch. Große downloads laufen dann
wirklich flott.
Gruß
Alex
Alexander Burger
Sep 7, 2014, 8:49:30 AM9/7/14
to
Modem und Router zu resetten. Vielleicht hilft das ja wirklich.
Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
Internet-backbones angeschlossen wird, oder?
Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
ausgelegt sein.
Das fände ich aber sehr ärgerlich, weil KabelBW mit Bandbreiten von 50
Mbit/s und 100 Mbit/s und 150 Mbit/s Werbung macht. Was nützt es dann, wenn
man zwar direkt am Haus diesen Netzanschluss hat, die backbones aber einen
solchen Traffic nicht hergeben?
Klar schauen immer mehr Leute video über das Internet. Ich selbst habe auch
eine set-top-box für den Fernseher, mit der ich über den Fernseher ins
Internet gehen kann. In den Mediatheken von ARD, arte usw. liegen ja sehr
viele Filme herum, die man anschauen kann. Was ich bislang wenig tue. Aber
ich kann mir schon vorstellen, dass viele Leute gerade am samstagabend so
das Internet belagern.
Gruß
Alex
Sven Hartge
Sep 7, 2014, 8:49:38 AM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> Ulrich F. Heidenreich wrote:
>> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>>> KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
>>> alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.
>> Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
>> Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
>> Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40
>> Mieteinheiten. Gerade am Wochenende/Abend könnten da 50 MBit schon
>> knapp werden.
> Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur für das
> Haus zur Verfügung. Aber das gilt natürlich nur für die letzten Meter.
> Danach könnte das dann mit den Nachbarhäusern geteilt werden. Aber
> KabelBW hat Glasfaser- Kabel. Da sollten doch keine Engpässe
> auftreten, oder?
Kabel ist ein Shared-Medium. Bei dir könnte der halbe Ort am gleichen
> Ulrich F. Heidenreich wrote:
>> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>>> KabelBW macht so groß Werbung mit 50 MBit/s usw. Das nützt aber
>>> alles nichts, wenn die Leitungen dahinter immer wieder Stau haben.
>> Ist es nicht so, daß sich im Gegensatz zu DSL alle am gleichen Kabel
>> Hängenden die Bandbreite teilen müssen? Meine Kristallkugel sieht bei
>> Dir gerade ein Wohnsilo mit an einem Kabel hängenden 40
>> Mieteinheiten. Gerade am Wochenende/Abend könnten da 50 MBit schon
>> knapp werden.
> Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur für das
> Haus zur Verfügung. Aber das gilt natürlich nur für die letzten Meter.
> Danach könnte das dann mit den Nachbarhäusern geteilt werden. Aber
> KabelBW hat Glasfaser- Kabel. Da sollten doch keine Engpässe
> auftreten, oder?
Kabelverzweiger hänngen und sich die x Mal 50 MBit/s teilen müssen, die
DOCSIS2 dem Medium erlaubt.
Sven Hartge
Sep 7, 2014, 9:12:46 AM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
> Internet-backbones angeschlossen wird, oder?
Das hängt auch wieder vom Provider ab.
Manche peeren mit anderen Providern nur an einer Stelle (z.B. dem DECIX
in Frankfurt), andere wiederum haben recht viele Peering-Punkte.
> Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
> backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
> ausgelegt sein.
Auch möglich.
Die (werbewirksame) mögliche Bandbreite an den Endanschlüssen ist
schneller und stärker gewachsen wie die Bandbreite im Backbone.
> Das fände ich aber sehr ärgerlich, weil KabelBW mit Bandbreiten von 50
> Mbit/s und 100 Mbit/s und 150 Mbit/s Werbung macht. Was nützt es dann, wenn
> man zwar direkt am Haus diesen Netzanschluss hat, die backbones aber einen
> solchen Traffic nicht hergeben?
Tja. Willkommen in der Wirklichkeit,
Teste doch einfach mal folgendes:
Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
um festzustellen, wie es mit der Strecke im Ziel aussieht:
z.B.:
tracert www.heise.de
Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
> Sven Hartge wrote:
>> Was Alexander helfen könnte, wäre einmal sein
>> Kabelmodem/FritzBox/Whatever zu resetten, wenn es wieder tröpfelt, in
>> der Hoffnung auf einen anderen Kanal zugewiesen zu werden.
>> Was Alexander helfen könnte, wäre einmal sein
>> Kabelmodem/FritzBox/Whatever zu resetten, wenn es wieder tröpfelt, in
>> der Hoffnung auf einen anderen Kanal zugewiesen zu werden.
> ok, vielen Dank. Beim nächsten Stau im Kabel werde ich mal versuchen, mein
> Modem und Router zu resetten. Vielleicht hilft das ja wirklich.
> Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
> in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
Möglich. Aber von aussen schwer zu erkennen.
> Modem und Router zu resetten. Vielleicht hilft das ja wirklich.
> Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
> in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
> Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
> Internet-backbones angeschlossen wird, oder?
Manche peeren mit anderen Providern nur an einer Stelle (z.B. dem DECIX
in Frankfurt), andere wiederum haben recht viele Peering-Punkte.
> Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
> backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
> ausgelegt sein.
Die (werbewirksame) mögliche Bandbreite an den Endanschlüssen ist
schneller und stärker gewachsen wie die Bandbreite im Backbone.
> Das fände ich aber sehr ärgerlich, weil KabelBW mit Bandbreiten von 50
> Mbit/s und 100 Mbit/s und 150 Mbit/s Werbung macht. Was nützt es dann, wenn
> man zwar direkt am Haus diesen Netzanschluss hat, die backbones aber einen
> solchen Traffic nicht hergeben?
Teste doch einfach mal folgendes:
Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
um festzustellen, wie es mit der Strecke im Ziel aussieht:
z.B.:
tracert www.heise.de
Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
Juergen Ilse
Sep 7, 2014, 10:15:40 AM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> KabelBW ist oft unertrï¿œglich langsam.
ob es sich um ein Kabel handelt, mit dem ganze Strassenzuege mit Internet
versorgt werden sollen, oder um einen WLAN-Kanal, auf dem sich Dutzende
von Nachbarn mit ihrem "SOHO-Equipment" draengeln) ...
> Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) trï¿œpfelt es bei
> KabelBW nur noch.
Das Kabel har nur eine gewisse "Gesamtkapazitaet", die sich nun mal alle
daran angeschlossenen Kunden teilen (eine gewisse "Ueberbuchung" ist auch
kein Problem, solange nicht gerade alle auf einmal die Leistung nutzen
wollen, aber falls das doch passiert ...).
> Das war ich frï¿œher bei meinem DSL-Anschluss nicht gewohnt.
Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen stoeranfaellige)
dedizierte Kupferdoppelader, die du mit niemandem teilen musst ...
> KabelBW macht so groￜ Werbung mit 50 MBit/s usw.
Falsch, sie machen Werbung mit "bis zu 50 MBit/s", und sie wissen auch
ganz genau, warum ... Das machen andere Provider uebrigens auch, weil
kein Provider sich "nicht Einhaltung des Vertrags" vorwerfen lassen
will, wenn es mal einen Engpass im Netz gibt.
> Das nï¿œtzt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
> haben.
Bei Internet via Fernsehkabel duerfte der Engpass oefters schon weit
vor dem Uebergang in andere Providernetze liegen ... Es ist nicht un-
ueblich, die Kapazitaeten zu ueberbuchen.
> So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
> nicht alle Provider haben.
Bei DSL kann so etwas auch passieren, wenn der Uplink vom DSLAM
"zu duenn" ist. Wie oft das vorkommt, weiss ich nicht, wenn es
vorkommt, hast du dann aber das selbe Problem. Bei Internet via
Mobilfunk kommen zu diesem Problem (dass da natuerlich wegen
"shared Medium" auch vorkommen kann: da teilt man sich die Frequenz
auch nicht nur mit anderen Internet-Teilnehmern sondern auch mit
Telefongespraechen und SMS) auch noch die eher "kundenunfreundlichen
Tarife" dazu. Eigentlich muesste man fast den Rarschlag geben "Nimm
den Provider, den kein anderer hat, dann hast du zumindest vermutlich
kein Problem mit Ueberbuchung ...".
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
> KabelBW ist oft unertrï¿œglich langsam.
> Ist das nur bei mir so oder auch bei anderen?
> Haben Leute bei anderen Providern auch solche Probleme,
> oder ist das nur ein Problem von KabelBW?
Das ist ein Problem dessen, was man als "shared medium" bezeichnet (egal,
> Haben Leute bei anderen Providern auch solche Probleme,
> oder ist das nur ein Problem von KabelBW?
ob es sich um ein Kabel handelt, mit dem ganze Strassenzuege mit Internet
versorgt werden sollen, oder um einen WLAN-Kanal, auf dem sich Dutzende
von Nachbarn mit ihrem "SOHO-Equipment" draengeln) ...
> Zu Zeiten mit starkem Internetverkehr (z.B. samstagabend) trï¿œpfelt es bei
> KabelBW nur noch.
Das Kabel har nur eine gewisse "Gesamtkapazitaet", die sich nun mal alle
daran angeschlossenen Kunden teilen (eine gewisse "Ueberbuchung" ist auch
kein Problem, solange nicht gerade alle auf einmal die Leistung nutzen
wollen, aber falls das doch passiert ...).
> Das war ich frï¿œher bei meinem DSL-Anschluss nicht gewohnt.
Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen stoeranfaellige)
dedizierte Kupferdoppelader, die du mit niemandem teilen musst ...
> KabelBW macht so groￜ Werbung mit 50 MBit/s usw.
Falsch, sie machen Werbung mit "bis zu 50 MBit/s", und sie wissen auch
ganz genau, warum ... Das machen andere Provider uebrigens auch, weil
kein Provider sich "nicht Einhaltung des Vertrags" vorwerfen lassen
will, wenn es mal einen Engpass im Netz gibt.
> Das nï¿œtzt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
> haben.
Bei Internet via Fernsehkabel duerfte der Engpass oefters schon weit
vor dem Uebergang in andere Providernetze liegen ... Es ist nicht un-
ueblich, die Kapazitaeten zu ueberbuchen.
> So ist KabelBW niemandem zu empfehlen, sofern das Problem derzeit
> nicht alle Provider haben.
"zu duenn" ist. Wie oft das vorkommt, weiss ich nicht, wenn es
vorkommt, hast du dann aber das selbe Problem. Bei Internet via
Mobilfunk kommen zu diesem Problem (dass da natuerlich wegen
"shared Medium" auch vorkommen kann: da teilt man sich die Frequenz
auch nicht nur mit anderen Internet-Teilnehmern sondern auch mit
Telefongespraechen und SMS) auch noch die eher "kundenunfreundlichen
Tarife" dazu. Eigentlich muesste man fast den Rarschlag geben "Nimm
den Provider, den kein anderer hat, dann hast du zumindest vermutlich
kein Problem mit Ueberbuchung ...".
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen Ilse
Sep 7, 2014, 10:42:46 AM9/7/14
to
Hallo,
Alexander Burger <alexande...@yahoo.de> wrote:
> Ulrich F. Heidenreich wrote:
>> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>>>KabelBW macht so groￜ Werbung mit 50 MBit/s usw.
>>>Das nï¿œtzt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
>>>haben.
>> Ist es nicht so, daￜ sich im Gegensatz zu DSL alle am gleichen Kabel
>> Hï¿œngenden die Bandbreite teilen mï¿œssen? Meine Kristallkugel sieht bei
>> Dir gerade ein Wohnsilo mit an einem Kabel hï¿œngenden 40 Mieteinheiten.
>> Gerade am Wochenende/Abend kï¿œnnten da 50 MBit schon knapp werden.
> Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur fï¿œr das Haus zur
> Verfï¿œgung. Aber das gilt natï¿œrlich nur fï¿œr die letzten Meter. Danach kï¿œnnte
> das dann mit den Nachbarhï¿œusern geteilt werden. Aber KabelBW hat Glasfaser-
> Kabel. Da sollten doch keine Engpï¿œsse auftreten, oder?
Wieso sollte auf Glasfaserkabeln kein Kapazitaetsengpass moeglich sein?
Wie jemand anders erwaehnte, kann ein Kanal auf dem Kabel bis zu 50 MBit/s
uebertragen. Wie viele Kanaele werden fuer wie viele Kunden verwendet?
Es wuerde mich *sehr* wundern, wenn nicht bereits dort ueberbucht wird.
Alle Kunden, die an dem selben Kabelabschnitt bis zu dem Punkt, an dem
der "Internet-Traffic ausgeleitet und auf anderem Wege weitergeleitet"
wird, haengen, teilen sich die fuer Internet reservierten Kanaele im
Kabel (und damit die fuer Internet in diesem Abschnitt reservierte
Gesamtuebertragungskapazitaet). Das kann u.U. auch schon einmal ein
ganzer Strassenzug sein ...
Alexander Burger <alexande...@yahoo.de> wrote:
> Ulrich F. Heidenreich wrote:
>> Alexander Burger in <news:540b7444$0$24386$4c5e...@fastusenet.org>:
>>>Das nï¿œtzt aber alles nichts, wenn die Leitungen dahinter immer wieder Stau
>>>haben.
>> Ist es nicht so, daￜ sich im Gegensatz zu DSL alle am gleichen Kabel
>> Hï¿œngenden die Bandbreite teilen mï¿œssen? Meine Kristallkugel sieht bei
>> Dir gerade ein Wohnsilo mit an einem Kabel hï¿œngenden 40 Mieteinheiten.
>> Gerade am Wochenende/Abend kï¿œnnten da 50 MBit schon knapp werden.
> Nein, das ist ein Einfamilienhaus. Die 50 Mbit/s stehen nur fï¿œr das Haus zur
> Verfï¿œgung. Aber das gilt natï¿œrlich nur fï¿œr die letzten Meter. Danach kï¿œnnte
> das dann mit den Nachbarhï¿œusern geteilt werden. Aber KabelBW hat Glasfaser-
> Kabel. Da sollten doch keine Engpï¿œsse auftreten, oder?
Wieso sollte auf Glasfaserkabeln kein Kapazitaetsengpass moeglich sein?
Wie jemand anders erwaehnte, kann ein Kanal auf dem Kabel bis zu 50 MBit/s
uebertragen. Wie viele Kanaele werden fuer wie viele Kunden verwendet?
Es wuerde mich *sehr* wundern, wenn nicht bereits dort ueberbucht wird.
Alle Kunden, die an dem selben Kabelabschnitt bis zu dem Punkt, an dem
der "Internet-Traffic ausgeleitet und auf anderem Wege weitergeleitet"
wird, haengen, teilen sich die fuer Internet reservierten Kanaele im
Kabel (und damit die fuer Internet in diesem Abschnitt reservierte
Gesamtuebertragungskapazitaet). Das kann u.U. auch schon einmal ein
ganzer Strassenzug sein ...
Alexander Burger
Sep 7, 2014, 11:24:06 AM9/7/14
to
Sven Hartge wrote:
>
> Teste doch einfach mal folgendes:
>
> Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
> um festzustellen, wie es mit der Strecke im Ziel aussieht:
>
> z.B.:
>
> tracert www.heise.de
>
> Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
>
> Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
>
ah, danke. dass ich da nicht früher darauf gekommen bin.
>
> Teste doch einfach mal folgendes:
>
> Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
> um festzustellen, wie es mit der Strecke im Ziel aussieht:
>
> z.B.:
>
> tracert www.heise.de
>
> Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
>
> Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
>
ich habe zwar Linux, aber da geht das dann mit traceroute:
/usr/sbin/traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * 84.116.132.169 (84.116.132.169) 13.779 ms de-fra01a-ri2-
xe-5-1-1.aorta.net (84.116.133.114) 30.492 ms
7 de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 21.285 ms * *
8 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 21.736 ms * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 212.19.61.13 (212.19.61.13) 121.970 ms !X * *
das sieht ziemlich übel aus, oder?
Der ping selbst liegt unter 30 ms.
Hat aber 53prozent paketverlust :-(
ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=244 time=14.7 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=244 time=14.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=3 ttl=244 time=14.6 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=6 ttl=244 time=17.9 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=7 ttl=244 time=15.2 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=12 ttl=244 time=12.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=13 ttl=244 time=15.3 ms
(...)
64 bytes from www.heise.de (193.99.144.85): icmp_seq=203 ttl=244 time=13.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=204 ttl=244 time=14.3
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=207 ttl=244 time=24.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=210 ttl=244 time=18.2
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=211 ttl=244 time=14.6
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=213 ttl=244 time=15.8
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=214 ttl=244 time=16.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=219 ttl=244 time=16.7
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=221 ttl=244 time=11.1
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=222 ttl=244 time=17.6
ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=223 ttl=244 time=14.4
ms
^C
--- www.heise.de ping statistics ---
223 packets transmitted, 103 received, 53% packet loss, time 222139ms
rtt min/avg/max/mdev = 11.193/16.756/100.554/8.968 ms
kann man daraus etwas ablesen?
Gruß
Alex
Alexander Burger
Sep 7, 2014, 11:35:46 AM9/7/14
to
http://www.computerbase.de/forum/showthread.php?t=1052288
Gruß
Alex
Marc Haber
Sep 7, 2014, 11:45:50 AM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
>Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
>in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
>Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
>Internet-backbones angeschlossen wird, oder?
>Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
>backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
>ausgelegt sein.
Ohne Überbuchung im Backbone wären auch im DSL-Bereich die Preise
>Aber ich habe da eher den Verdacht, dass es am backbone liegt, dass KabelBW
>in meiner Region einfach beim backbone zu wenig Bandbreite angemietet hat.
>Ich nehme an, dass jede Stadt bzw. Region für sich vom Kabel direkt an
>Internet-backbones angeschlossen wird, oder?
>Und wenn KabelBW hier ein bischen sparen möchte, werden die Bandbreiten der
>backbones, die KabelBW anmietet, vielleicht nicht auf die Spitzenzeiten
>ausgelegt sein.
nicht haltbar.
Sven Hartge
Sep 7, 2014, 1:03:58 PM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> Sven Hartge wrote:
>> Teste doch einfach mal folgendes:
>>
>> Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
>> um festzustellen, wie es mit der Strecke im Ziel aussieht:
>>
>> z.B.:
>>
>> tracert www.heise.de
>>
>> Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
>>
>> Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
>>
> ah, danke. dass ich da nicht früher darauf gekommen bin.
> ich habe zwar Linux, aber da geht das dann mit traceroute:
Wenn du Linux hast, dann nimm mal mtr (Paket mtr-tiny in Debian z.B.)
> Sven Hartge wrote:
>> Teste doch einfach mal folgendes:
>>
>> Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
>> um festzustellen, wie es mit der Strecke im Ziel aussieht:
>>
>> z.B.:
>>
>> tracert www.heise.de
>>
>> Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
>>
>> Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
>>
> ah, danke. dass ich da nicht früher darauf gekommen bin.
> ich habe zwar Linux, aber da geht das dann mit traceroute:
> das sieht ziemlich übel aus, oder?
Es gibt z.B. in Debian diverse Pakete, die traceroute bereitstellen.
Versuche mal inetutils-traceroute.
Ich persönlich mag mtr lieber, weil man es z.B. dauerhaft laufen lassen
kann oder mit
mtr -r 100 heise.de
einen Report über 100 Zyklen anzeigen lassen kann, welcher
Aufschlussreicher ist wie nur einen Momentaufnahme.
Sieht bei mir z.B. so aus:
oweh@ds9:~$ mtr -4 -r 100 heise.de
Start: Sun Sep 7 19:02:35 2014
HOST: ds9 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.40.64.1 0.0% 10 7.7 7.7 6.4 9.2 0.6
2.|-- 7211a-mx960-01-ae10-1020. 0.0% 10 7.0 10.1 5.6 34.4 8.7
3.|-- 7211a-mx960-02-ae0.gie.un 0.0% 10 6.4 11.6 6.1 37.7 10.0
4.|-- 1211f-mx960-01-ae5.dtm.un 0.0% 10 10.8 12.7 8.3 38.6 9.1
5.|-- 1411g-mx960-01-ae8.nss.un 0.0% 10 10.6 12.0 10.4 15.8 1.5
6.|-- gi1-15.c1.d.de.plusline.n 0.0% 10 12.4 12.2 11.2 13.8 0.7
7.|-- 212.19.61.13 0.0% 10 15.7 12.6 11.2 15.7 1.4
8.|-- redirector.heise.de 0.0% 10 11.4 11.9 10.6 12.5 0.3
(Das -4 bewirkt die Nutzung von IPv4.)
Juergen Ilse
Sep 7, 2014, 7:48:11 PM9/7/14
to
> ah, danke. dass ich da nicht frï¿œher darauf gekommen bin.
konfiguriert, dass sie keine ICMP Time-exceeded Meldungen generieren ...
Ueber die Qualitaet der Verbindung laesst sich bis hierher *gar* *keine*
Aussage machen (solange man das droￜￜen von ICMP nicht bereits als
"mangelnde Qualitaet des Netzes" wertet).
> 6 * 84.116.132.169 (84.116.132.169) 13.779 ms de-fra01a-ri2-
> xe-5-1-1.aorta.net (84.116.133.114) 30.492 ms
Ob hier das gedropte Paket auf ein wirkliches Problem hinweist, ist
IMHO nicht wirklich klar. Dass hier die 2 beantworteten Pakete an
verschiedene Router gingen, muss kein Problem sein. Die Antwortzeiten
weisen hier auch noch nicht unbedingt auf ein Problem hin, auch wenn
der Unterschied (13,8 zu 30.5 ms) etwas auffaellig ist.
> 7 de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 21.285 ms * *
> 8 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 21.736 ms * *
Hier koennten die Paketverluste auch durch aggresives ICMP-Rate-Limiting
hervorgerufen worden sein. Die Paketverluste *koennten* ein Indiz fuer
ein Problem sein, das muss aber nicht der Fall sein. Hohe Antwortzeiten
waeren da schon eher ein Indiz ... 21 ms sind aber fuer die Verbindung
nach Frankfurt (vermutlich zum DE-CIX, wenn ich mir den Rest der Ausgabe
ansehe) nicht so schlecht).
> 9 * * *
> 10 * * *
> 11 * * *
> 12 * * *
> 13 * * *
> 14 * * *
> 15 * * *
> 16 * * *
> 17 * * *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
Hier wieder droppen von ICMP (siehe oben), eine Aussage darueber, ob ein
Netzwerkproblem vorliegt, ist aufgrund dessen nicht moeglich.
> 23 212.19.61.13 (212.19.61.13) 121.970 ms !X * *
Das duerfte eine IP-Adresse des Loadbalancers von Heise zu sein,
die Paketverluste duerften auf ICMP-Rate-Limiting und abweisen
des traceroutes beruhen. Da die Antwortzeiten bis zum 8.Hop nicht
sonderlich hoch waren und der Heise-Server im Netz von Plusline
steht, duerften hier die etwas hoeheren Antwortzeiten kein Indiz
fuer ein Problem im Netz deines Providers sein.
> das sieht ziemlich ï¿œbel aus, oder?
Daraus laesst sich IMHO gar keine Aussage ueber evt. Probleme im Netz
deines Providers treffen.
> Der ping selbst liegt unter 30 ms.
> Hat aber 53prozent paketverlust :-(
Die mehr als 50% Paketverluste beim ping auf www.heise.de sind schon
eher ein Hinweis auf "Ueberlast-Probleme", und das dann vermutlich
(den anderen Informationen im Thread nach zu schliessen) bei deinem
Provider, evt. auch auf der "last mile".
[ ping-Ausgabe gesnippt ]
> kann man daraus etwas ablesen?
Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ... Allerdings habe ich keinerlei Er-
fahrung mit "Internet ueber TV-Kabel".
> ich habe zwar Linux, aber da geht das dann mit traceroute:
> /usr/sbin/traceroute www.heise.de
> traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
> 1 * * *
> 2 * * *
> 3 * * *
> 4 * * *
> 5 * * *
Bis hierhin anscheinend nur Hops mit ICMP-Paketfiltern und/oder so
> /usr/sbin/traceroute www.heise.de
> traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
> 1 * * *
> 2 * * *
> 3 * * *
> 4 * * *
> 5 * * *
konfiguriert, dass sie keine ICMP Time-exceeded Meldungen generieren ...
Ueber die Qualitaet der Verbindung laesst sich bis hierher *gar* *keine*
Aussage machen (solange man das droￜￜen von ICMP nicht bereits als
"mangelnde Qualitaet des Netzes" wertet).
> 6 * 84.116.132.169 (84.116.132.169) 13.779 ms de-fra01a-ri2-
> xe-5-1-1.aorta.net (84.116.133.114) 30.492 ms
IMHO nicht wirklich klar. Dass hier die 2 beantworteten Pakete an
verschiedene Router gingen, muss kein Problem sein. Die Antwortzeiten
weisen hier auch noch nicht unbedingt auf ein Problem hin, auch wenn
der Unterschied (13,8 zu 30.5 ms) etwas auffaellig ist.
> 7 de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 21.285 ms * *
> 8 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 21.736 ms * *
hervorgerufen worden sein. Die Paketverluste *koennten* ein Indiz fuer
ein Problem sein, das muss aber nicht der Fall sein. Hohe Antwortzeiten
waeren da schon eher ein Indiz ... 21 ms sind aber fuer die Verbindung
nach Frankfurt (vermutlich zum DE-CIX, wenn ich mir den Rest der Ausgabe
ansehe) nicht so schlecht).
> 9 * * *
> 10 * * *
> 11 * * *
> 12 * * *
> 13 * * *
> 14 * * *
> 15 * * *
> 16 * * *
> 17 * * *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
Netzwerkproblem vorliegt, ist aufgrund dessen nicht moeglich.
> 23 212.19.61.13 (212.19.61.13) 121.970 ms !X * *
die Paketverluste duerften auf ICMP-Rate-Limiting und abweisen
des traceroutes beruhen. Da die Antwortzeiten bis zum 8.Hop nicht
sonderlich hoch waren und der Heise-Server im Netz von Plusline
steht, duerften hier die etwas hoeheren Antwortzeiten kein Indiz
fuer ein Problem im Netz deines Providers sein.
> das sieht ziemlich ï¿œbel aus, oder?
Daraus laesst sich IMHO gar keine Aussage ueber evt. Probleme im Netz
deines Providers treffen.
> Der ping selbst liegt unter 30 ms.
> Hat aber 53prozent paketverlust :-(
eher ein Hinweis auf "Ueberlast-Probleme", und das dann vermutlich
(den anderen Informationen im Thread nach zu schliessen) bei deinem
Provider, evt. auch auf der "last mile".
[ ping-Ausgabe gesnippt ]
> kann man daraus etwas ablesen?
Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
oder sehr hohen Antwortzeiten ... Allerdings habe ich keinerlei Er-
fahrung mit "Internet ueber TV-Kabel".
Sven Hartge
Sep 7, 2014, 8:29:16 PM9/7/14
to
Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
> Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
> Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
> von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
> oder sehr hohen Antwortzeiten ...
Dito. Die Kombi "geringe Latenz, hohe Verluste" deuten meist auf ein
> Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
> Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
> von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
> oder sehr hohen Antwortzeiten ...
ICMP-Rate-Limit hin, meiner Erfahrung nach. (OK, einmal hatte ich einen
defekten SFP, der ca. 10% der Pakete zerstörte, so dass der empfangene
Switch sie wegwarf. Das äußerte sich an TCP-Verbindungen mit
Modem-Geschwindigkeit und eben 10% Paket-Verlust beim ICMP.)
Überlastete Leitungen zeigen sich meist zuerst durch eine hohe Latenz
und _dann_ erst durch verlorene Pakete.
In meinem anderen Artikelt sagte ich ja schon, dass er einmal andere
Tools benutzen soll, weil ich die von ihm gepostete Ausgabe von einer
mistigen Implementierung von traceroute schon kenne.
> Allerdings habe ich keinerlei Er- fahrung mit "Internet ueber
> TV-Kabel".
DSL überlegen.
Wenn der Anbieter den Coax-Strang bis zum Kabelverzweiger nicht
gnadenlos überbucht.
Sven Hartge
Sep 7, 2014, 8:44:02 PM9/7/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> Sven Hartge wrote:
>> Teste doch einfach mal folgendes:
>>
>> Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
>> um festzustellen, wie es mit der Strecke im Ziel aussieht:
>>
>> z.B.:
>>
>> tracert www.heise.de
>>
>> Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
>>
>> Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
>>
> ah, danke. dass ich da nicht früher darauf gekommen bin.
> ich habe zwar Linux, aber da geht das dann mit traceroute:
> Sven Hartge wrote:
>> Teste doch einfach mal folgendes:
>>
>> Wenn es wieder mal lahm ist, nutze unter Windows "tracert" und "ping"
>> um festzustellen, wie es mit der Strecke im Ziel aussieht:
>>
>> z.B.:
>>
>> tracert www.heise.de
>>
>> Die Zahlen sollten bei Kabel unter 50ms bei innerdeutschen Zielen sein.
>>
>> Wenn sie stark abweichen, dann gibt dies Aufschluss auf evtl. Probleme.
>>
> ah, danke. dass ich da nicht früher darauf gekommen bin.
> ich habe zwar Linux, aber da geht das dann mit traceroute:
Wenn du Linux hast, dann nimm mal mtr (Paket mtr-tiny in Debian z.B.)
> das sieht ziemlich übel aus, oder?
Nein, du hast nur eine kaputte Implementierung von traceroute erwischt.
Es gibt z.B. in Debian diverse Pakete, die traceroute bereitstellen.
Versuche mal inetutils-traceroute.
Ich persönlich mag mtr lieber, weil man es z.B. dauerhaft laufen lassen
kann oder mit
mtr -r 100 heise.de
einen Report über 100 Zyklen anzeigen lassen kann, welcher
Aufschlussreicher ist wie nur einen Momentaufnahme.
Sieht bei mir z.B. so aus:
oweh@ds9:~$ time mtr -4 -s 1476 -r -c 100 heise.de
Es gibt z.B. in Debian diverse Pakete, die traceroute bereitstellen.
Versuche mal inetutils-traceroute.
Ich persönlich mag mtr lieber, weil man es z.B. dauerhaft laufen lassen
kann oder mit
mtr -r 100 heise.de
einen Report über 100 Zyklen anzeigen lassen kann, welcher
Aufschlussreicher ist wie nur einen Momentaufnahme.
Sieht bei mir z.B. so aus:
Start: Mon Sep 8 02:39:22 2014
HOST: ds9 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.40.64.1 0.0% 100 6.8 7.5 5.6 12.8 1.1
2.|-- 7211a-mx960-01-ae10-1020. 0.0% 100 7.4 11.1 6.2 93.9 13.1
3.|-- 7211a-mx960-02-ae0.gie.un 0.0% 100 6.6 10.9 6.2 60.2 8.2
4.|-- 1211f-mx960-01-ae5.dtm.un 0.0% 100 10.0 10.6 8.5 25.9 2.3
5.|-- 1411g-mx960-01-ae8.nss.un 0.0% 100 12.7 12.3 10.3 35.6 2.5
6.|-- gi1-15.c1.d.de.plusline.n 0.0% 100 12.5 18.1 11.5 180.2 25.0
7.|-- 212.19.61.13 0.0% 100 13.5 12.9 11.0 22.0 1.5
8.|-- redirector.heise.de 0.0% 100 12.2 12.9 11.3 17.1 0.7
-s 1476 nutzt größere ICMP-Pakete anstelle der 64 Byte beim Default.
-r erstellt einen Report anstelle einer interaktiven Curses-Oberfläche.
-c 100 sorgt dafür, dass jeder Hop 100 Mal angelaufen wird.
-4 bewirkt die Nutzung von IPv4, da ich auch einen IPv6-Link habe.
Alexander Burger
Sep 8, 2014, 5:33:31 PM9/8/14
to
>> ah, danke. dass ich da nicht früher darauf gekommen bin.
>> das sieht ziemlich übel aus, oder?
Das hilft mir sehr, diese Ergebnisse zu lesen.
Besten Dank.
Ich habe auch mtr probiert. Siehe anderes posting.
Und es scheint so, dass die Antwortzeiten fast immer sehr kurz sind,
aber es teilweise Verlustraten von über 95 Prozent gibt.
Danke nochmals
Gruß
Alex
>> ich habe zwar Linux, aber da geht das dann mit traceroute:
>
>> /usr/sbin/traceroute www.heise.de
>> traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
>> 1 * * *
>> 2 * * *
>> 3 * * *
>> 4 * * *
>> 5 * * *
>
> Bis hierhin anscheinend nur Hops mit ICMP-Paketfiltern und/oder so
> konfiguriert, dass sie keine ICMP Time-exceeded Meldungen generieren ...
> Ueber die Qualitaet der Verbindung laesst sich bis hierher *gar* *keine*
> Aussage machen (solange man das droüüen von ICMP nicht bereits als
>
>> /usr/sbin/traceroute www.heise.de
>> traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
>> 1 * * *
>> 2 * * *
>> 3 * * *
>> 4 * * *
>> 5 * * *
>
> Bis hierhin anscheinend nur Hops mit ICMP-Paketfiltern und/oder so
> konfiguriert, dass sie keine ICMP Time-exceeded Meldungen generieren ...
> Ueber die Qualitaet der Verbindung laesst sich bis hierher *gar* *keine*
>
> Daraus laesst sich IMHO gar keine Aussage ueber evt. Probleme im Netz
> deines Providers treffen.
>
>> Der ping selbst liegt unter 30 ms.
>> Hat aber 53prozent paketverlust :-(
>
> Die mehr als 50% Paketverluste beim ping auf www.heise.de sind schon
> eher ein Hinweis auf "Ueberlast-Probleme", und das dann vermutlich
> (den anderen Informationen im Thread nach zu schliessen) bei deinem
> Provider, evt. auch auf der "last mile".
>
> [ ping-Ausgabe gesnippt ]
>
>> kann man daraus etwas ablesen?
>
> Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
> Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
> von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
> oder sehr hohen Antwortzeiten ... Allerdings habe ich keinerlei Er-
> fahrung mit "Internet ueber TV-Kabel".
>
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
super, vielen Dank.
> Daraus laesst sich IMHO gar keine Aussage ueber evt. Probleme im Netz
> deines Providers treffen.
>
>> Der ping selbst liegt unter 30 ms.
>> Hat aber 53prozent paketverlust :-(
>
> Die mehr als 50% Paketverluste beim ping auf www.heise.de sind schon
> eher ein Hinweis auf "Ueberlast-Probleme", und das dann vermutlich
> (den anderen Informationen im Thread nach zu schliessen) bei deinem
> Provider, evt. auch auf der "last mile".
>
> [ ping-Ausgabe gesnippt ]
>
>> kann man daraus etwas ablesen?
>
> Ich finde hier die Kombination von "lurzen Antwortzeiten" und "hohen
> Paketverlusten" etwas irritierend: meistens sehe ich bei Ueberlastung
> von Netzwerkverbindungen eher Paketverluste in Kombination mit hohen
> oder sehr hohen Antwortzeiten ... Allerdings habe ich keinerlei Er-
> fahrung mit "Internet ueber TV-Kabel".
>
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
Das hilft mir sehr, diese Ergebnisse zu lesen.
Besten Dank.
Ich habe auch mtr probiert. Siehe anderes posting.
Und es scheint so, dass die Antwortzeiten fast immer sehr kurz sind,
aber es teilweise Verlustraten von über 95 Prozent gibt.
Danke nochmals
Gruß
Alex
Alexander Burger
Sep 8, 2014, 5:39:06 PM9/8/14
to
ok, hier habe ich mal noch ein Beispiel mit mtr:
/usr/sbin/mtr --report -c 100 hetzner.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.6 0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.30.20.41 0.0% 100 11.2 11.8 7.9 30.5 4.2
4.|-- 84.116.191.25 0.0% 100 9.6 11.9 8.3 32.4 3.9
5.|-- 84.116.191.2 0.0% 100 13.7 14.2 10.4 32.2 3.9
6.|-- 84.116.132.193 0.0% 100 13.7 16.1 11.7 34.7 4.4
7.|-- 84.116.132.145 0.0% 100 14.8 15.0 9.6 33.5 4.4
8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- ae-1-19.bar1.Munich1.Leve 0.0% 100 22.5 25.6 17.9 84.9 13.0
12.|-- ae-0-11.bar2.Munich1.Leve 0.0% 100 21.3 24.6 18.0 84.6 10.2
13.|-- 62.140.25.102 0.0% 100 20.2 26.3 18.3 109.5 13.1
14.|-- core11.hetzner.de 29.0% 100 21.3 24.2 21.3 40.7 3.9
15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%
ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.
Gruß
Alex
Jörg Tewes
Sep 8, 2014, 8:01:00 PM9/8/14
to
Marc Haber schrub
> Den (zugenagelten) Router muss man so etwa einmal in der Woche
> resetten, wenn Latenzen in der Gr��enordnung von 2 Sekunden
> auftreten.
Zu einer Domain die in D gehostet wird, oder au�erhalb?
Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
welcher Firmware?
Wenn du eine Fritzbox 6360 hast, und es innerhalb von D ist, siehst du
mich massiv erstaunt.
Ich dachte die Fritzboxen werden bei den Kabelbetreibern gr��tenteils
gleich konfiguriert, und meine 6360 mit 6.05 braucht nicht resettet zu
werden, um die Latenz wieder in normale Gr��enordnungen zu bringen.
Meine 6360 l�uft jetzt seit Anfang des Jahres durchgehen, und hat zu
heise.de unter 30ms, was ich mit dem Entertainanschlu� auch bei der
Telekom hatte. Mit einem Telekom Businessanschlu� k�nntest du da auf
weniger kommen, aber alle Privatkundenanschl�sse kommen auf �hnliche
Werte. Zumindest das was aktuell geschaltet wird.
Bye J�rg
--
"I don't trust telepaths. Never have, never will."
(Garibaldi, "The Gathering")
> Den (zugenagelten) Router muss man so etwa einmal in der Woche
> auftreten.
Zu einer Domain die in D gehostet wird, oder au�erhalb?
Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
welcher Firmware?
Wenn du eine Fritzbox 6360 hast, und es innerhalb von D ist, siehst du
mich massiv erstaunt.
Ich dachte die Fritzboxen werden bei den Kabelbetreibern gr��tenteils
gleich konfiguriert, und meine 6360 mit 6.05 braucht nicht resettet zu
werden, um die Latenz wieder in normale Gr��enordnungen zu bringen.
Meine 6360 l�uft jetzt seit Anfang des Jahres durchgehen, und hat zu
heise.de unter 30ms, was ich mit dem Entertainanschlu� auch bei der
Telekom hatte. Mit einem Telekom Businessanschlu� k�nntest du da auf
weniger kommen, aber alle Privatkundenanschl�sse kommen auf �hnliche
Werte. Zumindest das was aktuell geschaltet wird.
Bye J�rg
--
"I don't trust telepaths. Never have, never will."
(Garibaldi, "The Gathering")
Jörg Tewes
Sep 8, 2014, 8:07:00 PM9/8/14
to
Juergen Ilse schrub
> Alexander Burger <alexande...@yahoo.de> wrote:
>> Das war ich fr�her bei meinem DSL-Anschluss nicht gewohnt.
> Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen
> stoeranfaellige) dedizierte Kupferdoppelader, die du mit niemandem
> teilen musst ...
Bis zur Vst oder zum Outdoor. Ab da gehts dann auch f�r alle auf einer
Glasfaser weiter. Das M�rchen vom Shared Medium und der daraus
resultierenden geteilten Datenrate wird man auch nie wieder los scheint
mir. Ist wohl �hnlich wie mit dem angeblichen Spruch von Bill Gates von
wegen der 640 Kbyte.
>> KabelBW macht so gro� Werbung mit 50 MBit/s usw.
> Falsch, sie machen Werbung mit "bis zu 50 MBit/s", und sie wissen
> auch ganz genau, warum ... Das machen andere Provider uebrigens auch,
> weil kein Provider sich "nicht Einhaltung des Vertrags" vorwerfen
> lassen will, wenn es mal einen Engpass im Netz gibt.
Nein, weil wenn sie es nicht reinschreiben w�rden, sich jemand
beschweren w�rde, sobald er von seinem Kumpel, der mit einem 16 Mbit/s
Anschlu� ans Netz angeschlossen ist, nicht mit 16 MBit/s runter laden
kann. Obwohl dieser nur einen Upload von 1 MBit/s hat.
Bye J�rg
--
Eine Studie bescheinigt Linux mit Kernel 2.4 deutlich verbesserte
Server-Funktionen, die teilweise mit kommerziellen Unix-Varianten
mithalten k�nnten.
> Alexander Burger <alexande...@yahoo.de> wrote:
>> Das war ich fr�her bei meinem DSL-Anschluss nicht gewohnt.
> Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen
> stoeranfaellige) dedizierte Kupferdoppelader, die du mit niemandem
> teilen musst ...
Glasfaser weiter. Das M�rchen vom Shared Medium und der daraus
resultierenden geteilten Datenrate wird man auch nie wieder los scheint
mir. Ist wohl �hnlich wie mit dem angeblichen Spruch von Bill Gates von
wegen der 640 Kbyte.
>> KabelBW macht so gro� Werbung mit 50 MBit/s usw.
> Falsch, sie machen Werbung mit "bis zu 50 MBit/s", und sie wissen
> auch ganz genau, warum ... Das machen andere Provider uebrigens auch,
> weil kein Provider sich "nicht Einhaltung des Vertrags" vorwerfen
> lassen will, wenn es mal einen Engpass im Netz gibt.
beschweren w�rde, sobald er von seinem Kumpel, der mit einem 16 Mbit/s
Anschlu� ans Netz angeschlossen ist, nicht mit 16 MBit/s runter laden
kann. Obwohl dieser nur einen Upload von 1 MBit/s hat.
Bye J�rg
--
Eine Studie bescheinigt Linux mit Kernel 2.4 deutlich verbesserte
Server-Funktionen, die teilweise mit kommerziellen Unix-Varianten
mithalten k�nnten.
Juergen Ilse
Sep 8, 2014, 10:13:53 PM9/8/14
to
Hallo,
Jï¿œrg Tewes <jogi...@gmx.net> wrote:
> Juergen Ilse schrub
>> Alexander Burger <alexande...@yahoo.de> wrote:
>>> Das war ich frï¿œher bei meinem DSL-Anschluss nicht gewohnt.
> Glasfaser weiter.
Das ist richtig. Das selbe gilt auch bei Kabel: ab dem Punkt, wo alles
"gebuendelt" wird, hat man ein "shared Medium", bei Kabel ist *zusaetzlich*
die "Last Mile" ein "sjared Medium". Das "shared Medium" kann immer dann
zu einem Problem bei hoher Auslastung werden, wenn der Provider es erheb-
lich ueberbucht, und zumindest bei Internet via Kabel wurde das wohl in
der Vergangenheit auf der "last mile" nur allzu gern getan. Ob immer noch
gnadenlos ueberbucht wird, weiss ich nicht, aber das waere eine moegliche
Erklaerung fuer "zu den Zeiten wo alle surfen wird es grausam langsam,
ansonsten geht es".
> Das Mï¿œrchen vom Shared Medium
Es ist kein Maerchen. Ob das ein Problem ist, haengt davon ab, ob und
wenn ja wie sehr der Provider ueberbucht (und das muss nicht an jedem
von diesem Provider versorgten Ort gleich sein) ...
Jï¿œrg Tewes <jogi...@gmx.net> wrote:
> Juergen Ilse schrub
>> Alexander Burger <alexande...@yahoo.de> wrote:
>> Bei DSL hast du eine (wenn auch ggfs. durch uebersprechen
>> stoeranfaellige) dedizierte Kupferdoppelader, die du mit niemandem
>> teilen musst ...
> Bis zur Vst oder zum Outdoor. Ab da gehts dann auch fï¿œr alle auf einer
>> stoeranfaellige) dedizierte Kupferdoppelader, die du mit niemandem
>> teilen musst ...
> Glasfaser weiter.
Das ist richtig. Das selbe gilt auch bei Kabel: ab dem Punkt, wo alles
"gebuendelt" wird, hat man ein "shared Medium", bei Kabel ist *zusaetzlich*
die "Last Mile" ein "sjared Medium". Das "shared Medium" kann immer dann
zu einem Problem bei hoher Auslastung werden, wenn der Provider es erheb-
lich ueberbucht, und zumindest bei Internet via Kabel wurde das wohl in
der Vergangenheit auf der "last mile" nur allzu gern getan. Ob immer noch
gnadenlos ueberbucht wird, weiss ich nicht, aber das waere eine moegliche
Erklaerung fuer "zu den Zeiten wo alle surfen wird es grausam langsam,
ansonsten geht es".
> Das Mï¿œrchen vom Shared Medium
Es ist kein Maerchen. Ob das ein Problem ist, haengt davon ab, ob und
wenn ja wie sehr der Provider ueberbucht (und das muss nicht an jedem
von diesem Provider versorgten Ort gleich sein) ...
Rupert Haselbeck
Sep 9, 2014, 1:00:09 AM9/9/14
to
Alexander Burger schrieb:
> ok, hier habe ich mal noch ein Beispiel mit mtr:
>
> /usr/sbin/mtr --report -c 100 hetzner.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst
einfach weg, statt sie zu beantworten. Das sagt also nichts aus
> ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.
Dann solltest du aber besser UDP verwenden statt ICMP
MfG
Rupert
> ok, hier habe ich mal noch ein Beispiel mit mtr:
>
> /usr/sbin/mtr --report -c 100 hetzner.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst
> 8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899.
> 258.7
> 9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
> 0.0
> 10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
> [...]
> 258.7
> 9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
> 0.0
> 10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0
> Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
> insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%
Der Router dort ist vermutlich gut ausgelastet und wirft daher ICMP-Pakete
> insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%
einfach weg, statt sie zu beantworten. Das sagt also nichts aus
> ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis hier.
MfG
Rupert
Marc Haber
Sep 9, 2014, 2:52:29 AM9/9/14
to
Jörg Tewes <jogi...@gmx.net> wrote:
>Marc Haber schrub
>> Den (zugenagelten) Router muss man so etwa einmal in der Woche
>> resetten, wenn Latenzen in der Größenordnung von 2 Sekunden
>Marc Haber schrub
>> Den (zugenagelten) Router muss man so etwa einmal in der Woche
>> auftreten.
>
>Zu einer Domain die in D gehostet wird, oder außerhalb?
Zu einer Domain hat man keine Latenzen.
Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
Fritzbox auf. Wenn ich mich richtig erinnere, lässt sich die Fritzbox
noch im Rahmen der Erwartungen anpingen. Das ist jetzt aber lange
nicht mehr aufgetreten.
Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
in den USA aber mit überdimensional hoher Latenz, dann ist der Fehler
im allgemeinen nicht im CPE zu suchen.
>Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
>welcher Firmware?
Heiko Schlichting
Sep 9, 2014, 3:04:16 AM9/9/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
>
> /usr/sbin/mtr --report -c 100 hetzner.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.6 0.0
> 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 3.|-- 172.30.20.41 0.0% 100 11.2 11.8 7.9 30.5 4.2
> 4.|-- 84.116.191.25 0.0% 100 9.6 11.9 8.3 32.4 3.9
> 5.|-- 84.116.191.2 0.0% 100 13.7 14.2 10.4 32.2 3.9
> 6.|-- 84.116.132.193 0.0% 100 13.7 16.1 11.7 34.7 4.4
> 7.|-- 84.116.132.145 0.0% 100 14.8 15.0 9.6 33.5 4.4
> 8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
> 9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 11.|-- ae-1-19.bar1.Munich1.Leve 0.0% 100 22.5 25.6 17.9 84.9 13.0
> 12.|-- ae-0-11.bar2.Munich1.Leve 0.0% 100 21.3 24.6 18.0 84.6 10.2
> 13.|-- 62.140.25.102 0.0% 100 20.2 26.3 18.3 109.5 13.1
> 14.|-- core11.hetzner.de 29.0% 100 21.3 24.2 21.3 40.7 3.9
> 15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
> 16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
> 17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
>
>
> Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
> insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%
Das sieht alles richtig und vï¿œllig normal aus. Zum Ziel (www.hetzner.de)
>
> /usr/sbin/mtr --report -c 100 hetzner.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 0.6 0.0
> 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 3.|-- 172.30.20.41 0.0% 100 11.2 11.8 7.9 30.5 4.2
> 4.|-- 84.116.191.25 0.0% 100 9.6 11.9 8.3 32.4 3.9
> 5.|-- 84.116.191.2 0.0% 100 13.7 14.2 10.4 32.2 3.9
> 6.|-- 84.116.132.193 0.0% 100 13.7 16.1 11.7 34.7 4.4
> 7.|-- 84.116.132.145 0.0% 100 14.8 15.0 9.6 33.5 4.4
> 8.|-- lag-10.ear1.Frankfurt.Lev 47.0% 100 13.7 51.6 11.2 1899. 258.7
> 9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 11.|-- ae-1-19.bar1.Munich1.Leve 0.0% 100 22.5 25.6 17.9 84.9 13.0
> 12.|-- ae-0-11.bar2.Munich1.Leve 0.0% 100 21.3 24.6 18.0 84.6 10.2
> 13.|-- 62.140.25.102 0.0% 100 20.2 26.3 18.3 109.5 13.1
> 14.|-- core11.hetzner.de 29.0% 100 21.3 24.2 21.3 40.7 3.9
> 15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
> 16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
> 17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
>
>
> Die Latenz scheint ok zu sein. Aber es gehen viele Pakete verloren,
> insbesondere bei Punkt 8: lag-10.ear1.Frankfurt.Lev 47.0%
hast Du weder Paketverluste noch unï¿œbliche Laufzeiten --> alles ist in
Ordnung.
Dass es auf dem Weg dorthin Router gibt, die besseres zu tun haben, als
Deine traceroute-Pakete zu beantworten, ist nicht ungewï¿œhnlich und kein
Fehler. Wenn es Paketverluste aufgrund von Engpￜￜen gￜbe, dann hￜtten auch
*alle* folgenden Hops Verluste, insb. auch das Ziel.
Da in diesem Fall offenbar alles richtig ist, kann man daraus nicht
ablesen, wo die Ursache sein kann. Zum Zeitpunkt der Messung wirst Du auch
selbst festgestellt haben, dass es (zu www.hetzner.de) gar kein Problem
gab. Du musst also die Messung nochmal wiederholen, wenn es Probleme gibt
(Dein ping mit hohen Verlusten war sicherlich ein solcher Zeitpunkt) und
das Ergebnis hier posten.
Dass es am Backbone Deines Providers liegt, kann ich zwar auch nicht ganz
ausschlieï¿œen, aber in mindestens 9 von 10 Fï¿œllen, wo das jemand als Ursache
behauptet hat, stellte es sich als falsch heraus. Das liegt daran, dass die
Erweiterung von Bandbreite im eigenen Backbone fï¿œr einen Provider eher
kostengￜnstigￜ ist, er die Auslastung leicht messen sowie ￜberwachen kann
und dort oft die besten Techniker einer Firma das Sagen haben, die sich bei
Paketverlusten im Backbone auf Lebenszeit Gespï¿œtt anhï¿œren mï¿œssen.
Heiko
ￜ verglichen mit Erweiterungen an anderen Stellen der Infrastruktur
Heiko Schlichting
Sep 9, 2014, 3:16:28 AM9/9/14
to
Die Paketverluste hattest Du zu www.heise.de, hier testest Du mit
hetzner.de, wo alles ok ist. Wie sieht es denn zu www.heise.de aus (am
besten zu einem Zeitpunkt, wo ping auch Verluste hat)?
Ohne Probleme (von Kabel Deutschland) sieht das so aus:
[heiko@ech] 121 (~): mtr -w -c 100 www.heise.de
HOST: ech Loss% Snt Last Avg Best Wrst StDev
1.|-- DD-WRT 0.0% 100 0.6 0.7 0.6 1.0 0.0
4.|-- ip5886c154.dynamic.kabel-deutschland.de 0.0% 100 9.4 10.1 8.0 23.8 2.5
5.|-- ip5886cb0a.dynamic.kabel-deutschland.de 0.0% 100 10.0 11.3 8.4 26.0 2.3
6.|-- ip5886ca47.dynamic.kabel-deutschland.de 0.0% 100 15.2 15.4 13.8 30.9 2.2
7.|-- plusline.ber.ecix.net 0.0% 100 14.5 23.2 13.8 181.0 27.5
8.|-- 212.19.61.13 0.0% 100 22.2 24.2 21.1 77.8 7.3
9.|-- www.heise.de 0.0% 100 21.3 23.7 21.2 61.5 4.9
Heiko
hetzner.de, wo alles ok ist. Wie sieht es denn zu www.heise.de aus (am
besten zu einem Zeitpunkt, wo ping auch Verluste hat)?
Ohne Probleme (von Kabel Deutschland) sieht das so aus:
[heiko@ech] 121 (~): mtr -w -c 100 www.heise.de
HOST: ech Loss% Snt Last Avg Best Wrst StDev
1.|-- DD-WRT 0.0% 100 0.6 0.7 0.6 1.0 0.0
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 83-169-180-62-isp.superkabel.de 0.0% 100 7.7 9.2 7.0 30.4 3.2
4.|-- ip5886c154.dynamic.kabel-deutschland.de 0.0% 100 9.4 10.1 8.0 23.8 2.5
5.|-- ip5886cb0a.dynamic.kabel-deutschland.de 0.0% 100 10.0 11.3 8.4 26.0 2.3
6.|-- ip5886ca47.dynamic.kabel-deutschland.de 0.0% 100 15.2 15.4 13.8 30.9 2.2
7.|-- plusline.ber.ecix.net 0.0% 100 14.5 23.2 13.8 181.0 27.5
8.|-- 212.19.61.13 0.0% 100 22.2 24.2 21.1 77.8 7.3
9.|-- www.heise.de 0.0% 100 21.3 23.7 21.2 61.5 4.9
Heiko
Marc Haber
Sep 9, 2014, 5:07:27 AM9/9/14
to
gemessen):
|[1/501]mh@fan:~$ mtr -4 -w -c 100 www.heise.de
|Start: Tue Sep 9 11:01:12 2014
|HOST: fan Loss% Snt Last Avg Best Wrst StDev
| 1.|-- 192.168.251.254 0.0% 100 0.6 0.4 0.3 1.2 0.0
| 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
| 3.|-- 172.30.22.101 0.0% 100 9.1 12.5 9.1 29.4 3.9
| 4.|-- 84.116.190.81 0.0% 100 13.3 15.5 10.3 69.8 7.8
| 5.|-- 84.116.190.6 0.0% 100 14.6 15.9 12.2 29.1 2.8
| 6.|-- te0-0-2-3.c350.f.de.plusline.net 0.0% 100 14.5 17.6 13.4 45.7 4.6
| 7.|-- 82.98.102.5 0.0% 100 16.7 19.6 14.8 71.3 7.3
| 8.|-- 212.19.61.13 0.0% 100 14.6 17.4 13.0 45.4 5.3
| 9.|-- www.heise.de 0.0% 100 16.8 18.3 14.9 31.5 3.5
Ja, für Reverse DNS scheinen sich sowohl KabelBW, Plusline als auch
Heise zu fein zu sein in diesen Tagen.
Sven Hartge
Sep 9, 2014, 4:18:34 PM9/9/14
to
Rupert Haselbeck <mein-re...@gmx.de> wrote:
> Alexander Burger schrieb:
>> ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
>> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
>> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis
>> hier.
> Dann solltest du aber besser UDP verwenden statt ICMP
Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
ICMP-basierten.
Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.
> Alexander Burger schrieb:
>> ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
>> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
>> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis
>> hier.
> Dann solltest du aber besser UDP verwenden statt ICMP
traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
ICMP-basierten.
Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.
Sven Hartge
Sep 9, 2014, 4:20:35 PM9/9/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> 15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
> 16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
> 17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
> 15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
> 16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
> 17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
> ich hatte auch schon Verluste von über 95Prozent, die ich aber nicht
> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis
> hier.
Interessant ist die Anzeige nur und ausschließlich dann, wenn beim
> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpässe.
> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis
> hier.
_letzten_ Hop diese Verluste auftreten. Alles vorher ist gerne
ICMP-Ratelimiting.
Nur wenn die Paketverluste sich ab einem Hop und dann bis zum letzten
Hop durchgehend zeigen, dann ist es interessant zu schauen, was zwischen
dem letzten guten und dem ersten schlechten Hop los ist und wo dieser
liegt.
Juergen Ilse
Sep 9, 2014, 5:12:26 PM9/9/14
to
Hallo,
Sven Hartge <sh-...@svenhartge.de> wrote:
> Alexander Burger <alexande...@yahoo.de> wrote:
>> 15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
>> 16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
>> 17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
>> ich hatte auch schon Verluste von ï¿œber 95Prozent, die ich aber nicht
>> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpï¿œsse.
hueten, dennasymmetrisches Routing ist zwischen verschiedenen Providern
nichts ungewoehnliches und bei traceroute und Konsorten sieht man immer
nur die Route "fuer den Hinweg" aber niemals die "fuer den Rueckweg"
der Pakete.
Vor etlichen Jahren hat mal ein Kunde behauptet, der erste Backbone-
Router im Netz meines Arbeitgebers muesse ein Problem haben, weil ein
traceroute bis zum letzten Hop vor diesem Router kurze Latenzen und
keine Paketverluste zeigten, aber an dem Hop tauchten Paketverluste
und hohe delays auf (der Kunde hatte einen Server bei meinem Arbeit-
geber gemietet und stellte fest, dass sein Zugriff auf diesen Server
unangenehm langsam war) ...
Die Schlussfolgerung war voreilig und falsch. Ab diesem Host verlief
der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
ueber einen anderen Provider als der Hinweg, und bei jenem anderen
Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
richtung ansehen muessen ...
Sven Hartge <sh-...@svenhartge.de> wrote:
> Alexander Burger <alexande...@yahoo.de> wrote:
>> 15.|-- juniper3.rz1.hetzner.de 0.0% 100 22.8 24.3 19.3 38.5 3.6
>> 16.|-- hos-tr1.ms-ex3k2.rz1.hetz 0.0% 100 24.6 24.7 19.0 41.7 3.9
>> 17.|-- www.hetzner.de 0.0% 100 22.6 23.0 19.2 40.3 3.3
>> aufgezeichnet hatte. Im Moment gibt es auch nicht wirklich Engpï¿œsse.
>> Wenn das wieder auftritt, messe ich nochmals und poste das Ergebnis
>> hier.
> Interessant ist die Anzeige nur und ausschlieï¿œlich dann, wenn beim
>> hier.
> _letzten_ Hop diese Verluste auftreten. Alles vorher ist gerne
> ICMP-Ratelimiting.
> Nur wenn die Paketverluste sich ab einem Hop und dann bis zum letzten
> Hop durchgehend zeigen, dann ist es interessant zu schauen, was zwischen
> dem letzten guten und dem ersten schlechten Hop los ist und wo dieser
> liegt.
... und man sollte sich vor falschen und/oder voreiligen Schluessen
> ICMP-Ratelimiting.
> Nur wenn die Paketverluste sich ab einem Hop und dann bis zum letzten
> Hop durchgehend zeigen, dann ist es interessant zu schauen, was zwischen
> dem letzten guten und dem ersten schlechten Hop los ist und wo dieser
> liegt.
hueten, dennasymmetrisches Routing ist zwischen verschiedenen Providern
nichts ungewoehnliches und bei traceroute und Konsorten sieht man immer
nur die Route "fuer den Hinweg" aber niemals die "fuer den Rueckweg"
der Pakete.
Vor etlichen Jahren hat mal ein Kunde behauptet, der erste Backbone-
Router im Netz meines Arbeitgebers muesse ein Problem haben, weil ein
traceroute bis zum letzten Hop vor diesem Router kurze Latenzen und
keine Paketverluste zeigten, aber an dem Hop tauchten Paketverluste
und hohe delays auf (der Kunde hatte einen Server bei meinem Arbeit-
geber gemietet und stellte fest, dass sein Zugriff auf diesen Server
unangenehm langsam war) ...
Die Schlussfolgerung war voreilig und falsch. Ab diesem Host verlief
der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
ueber einen anderen Provider als der Hinweg, und bei jenem anderen
Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
richtung ansehen muessen ...
Rupert Haselbeck
Sep 9, 2014, 5:20:11 PM9/9/14
to
Sven Hartge schrieb:
> Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
> traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
> ICMP-basierten.
Die Lücken in der Hop-Liste sind doch nicht von Interesse, solange der
jeweils darauffolgende Hop keine Paketverluste zetgt
> Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
> Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
> durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.
Das ist natürlich richtig. Aber damit ist man ja immerhin schonmal an die
Grenzen des Zielsystems gekommen und das mit Paketen, welche unterwegs als
Nutzlast behandelt werden
MfG
Rupert
> Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
> traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
> ICMP-basierten.
jeweils darauffolgende Hop keine Paketverluste zetgt
> Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
> Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
> durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.
Grenzen des Zielsystems gekommen und das mit Paketen, welche unterwegs als
Nutzlast behandelt werden
MfG
Rupert
Rupert Haselbeck
Sep 9, 2014, 5:30:07 PM9/9/14
to
Juergen Ilse schrieb:
> Die Schlussfolgerung war voreilig und falsch.
Das kann dem Kunden völlig egal sein
> Ab diesem Host verlief
> der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
> ueber einen anderen Provider als der Hinweg, und bei jenem anderen
> Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
> Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
> unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
> meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
> allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
> richtung ansehen muessen ...
Das ist Sache des Hosters. Wenn dieser schon suboptimale Massnahmen
unternimmt, um seine Kosten zu senken, so ist es seine Aufgabe, die dabei
unweigerlich auftretenden zusätzlichen Probleme in den Griff zu bekommen
MfG
Rupert
> Die Schlussfolgerung war voreilig und falsch.
> Ab diesem Host verlief
> der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
> ueber einen anderen Provider als der Hinweg, und bei jenem anderen
> Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
> Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
> unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
> meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
> allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
> richtung ansehen muessen ...
unternimmt, um seine Kosten zu senken, so ist es seine Aufgabe, die dabei
unweigerlich auftretenden zusätzlichen Probleme in den Griff zu bekommen
MfG
Rupert
Juergen Ilse
Sep 9, 2014, 6:01:04 PM9/9/14
to
Hallo,
Rupert Haselbeck <mein-re...@gmx.de> wrote:
> Juergen Ilse schrieb:
>> Die Schlussfolgerung war voreilig und falsch.
> Das kann dem Kunden vï¿œllig egal sein
Eine falsche Schlussfolgerung als Tatsache vorgetragen kann ggfs.
die Zeit bis zur Fehlerbehebung erhoehen, weil der zustaendige
Techniker auf die falsche Faehrte gelockt werden koennte.
>> Ab diesem Host verlief
>> der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
>> ueber einen anderen Provider als der Hinweg, und bei jenem anderen
>> Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
>> Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
>> unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
>> meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
>> allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
>> richtung ansehen muessen ...
> Das ist Sache des Hosters.
Um das Problem zu beheben, ist aber eine vom Kunden vorgetragene
falsche Diagnose nicht hilfreich.
> Wenn dieser schon suboptimale Massnahmen unternimmt, um seine Kosten
> zu senken,
Es ging nicht um "suboptimale Massnahmen um Kosten zu senken". Es gab
genau zu jenem Zeitpunkt eine Situation im Netz, wo der (ansonsten
einwabdfrei funktionierende) Weg vom Netz meines Arbeitgebers in das
Netz des Providers unseres Kunden mal nicht opzimal funktionierte
bzw. ueberlastet war. Das war eine nicht vorgerzusehende Ausnahme-
situation. Wie kommst du hier auf "suboptimale Massnahmen um Kosten
zu senken"? Es ist nun mal so, dass die meisten Kunden aus ihren
Heimnetzen nur "symmetrisches Routing" kennen, dass "symmetrisches
Routing" im weltweiten Routing zwischen verschiedensten autonomen
Systemen eher die Ausnahme als die Regel ist, und das Schlussfol-
gerungen, die stillschweigend symmetrisches Routing implizit voraus-
setzen, nur allzu oft voellig falsch sind. Die Geschichte war nur
ein Beispiel dafuer ...
> so ist es seine Aufgabe, die dabei unweigerlich auftretenden
> zusï¿œtzlichen Probleme in den Griff zu bekommen
Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
Ahnung hast?
Rupert Haselbeck <mein-re...@gmx.de> wrote:
> Juergen Ilse schrieb:
>> Die Schlussfolgerung war voreilig und falsch.
Eine falsche Schlussfolgerung als Tatsache vorgetragen kann ggfs.
die Zeit bis zur Fehlerbehebung erhoehen, weil der zustaendige
Techniker auf die falsche Faehrte gelockt werden koennte.
>> Ab diesem Host verlief
>> der "Rueckweg der Pakete" erstmalig (dank anderer Routing-Policy)
>> ueber einen anderen Provider als der Hinweg, und bei jenem anderen
>> Provider war zu dem Zeitpunkt das peering mit dem Provider unseres
>> Kunden ueberlastet. Der Fehler lag gar nicht bei dem Router, bei dem
>> unser Kunde das Problem vermutete, er lag noch nicht einmal im Netz
>> meines Arbeitgebers. Um dafuer Indizien zu finden, haette man sich
>> allerdings *zusaetzlich* noch mindestens den traceroute in der Gegen-
>> richtung ansehen muessen ...
> Das ist Sache des Hosters.
falsche Diagnose nicht hilfreich.
> Wenn dieser schon suboptimale Massnahmen unternimmt, um seine Kosten
> zu senken,
genau zu jenem Zeitpunkt eine Situation im Netz, wo der (ansonsten
einwabdfrei funktionierende) Weg vom Netz meines Arbeitgebers in das
Netz des Providers unseres Kunden mal nicht opzimal funktionierte
bzw. ueberlastet war. Das war eine nicht vorgerzusehende Ausnahme-
situation. Wie kommst du hier auf "suboptimale Massnahmen um Kosten
zu senken"? Es ist nun mal so, dass die meisten Kunden aus ihren
Heimnetzen nur "symmetrisches Routing" kennen, dass "symmetrisches
Routing" im weltweiten Routing zwischen verschiedensten autonomen
Systemen eher die Ausnahme als die Regel ist, und das Schlussfol-
gerungen, die stillschweigend symmetrisches Routing implizit voraus-
setzen, nur allzu oft voellig falsch sind. Die Geschichte war nur
ein Beispiel dafuer ...
> so ist es seine Aufgabe, die dabei unweigerlich auftretenden
Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
Ahnung hast?
Sven Hartge
Sep 9, 2014, 6:01:03 PM9/9/14
to
Rupert Haselbeck <mein-re...@gmx.de> wrote:
> Sven Hartge schrieb:
>> Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
>> Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
>> durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.
> Das ist natürlich richtig. Aber damit ist man ja immerhin schonmal an
> die Grenzen des Zielsystems gekommen und das mit Paketen, welche
> unterwegs als Nutzlast behandelt werden
Ich würde eher ein TCP-basiertes traceroute auf dem intendierten
Zielport machen, z.B. mit tcptraceroute oder "mtr -T -P 80"
> Sven Hartge schrieb:
>> Vor allem prallt man nahe zu immer an der ersten Firewall vor dem
>> Zielsystem ab, die nur Pakete auf genehmen Ports (TCP 80, 443 z.B.)
>> durchläßt und auf deine UDP-Pakete auf Port 35300++ pfeifft.
> Das ist natürlich richtig. Aber damit ist man ja immerhin schonmal an
> die Grenzen des Zielsystems gekommen und das mit Paketen, welche
> unterwegs als Nutzlast behandelt werden
Zielport machen, z.B. mit tcptraceroute oder "mtr -T -P 80"
Rupert Haselbeck
Sep 10, 2014, 1:00:18 AM9/10/14
to
Juergen Ilse schrieb:
> Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
> identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
> denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
> timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
> lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
> Ahnung hast?
Hoppala, da hat wohl einer ein grösseres Problem, wenn man den Finger in die
Wunde legt. Aber du hast ja Recht, warum sachlich bleiben, wenn man auch
persönlich "argumentieren" kann...
Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des Kunden
das Problem nicht identifizieren kann, sollte man für Aufgaben einsetzen,
welche seinen Fähigkeiten angemessener sind
MfG
Rupert
> Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
> identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
> denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
> timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
> lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
> Ahnung hast?
Wunde legt. Aber du hast ja Recht, warum sachlich bleiben, wenn man auch
persönlich "argumentieren" kann...
Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des Kunden
das Problem nicht identifizieren kann, sollte man für Aufgaben einsetzen,
welche seinen Fähigkeiten angemessener sind
MfG
Rupert
Marc Haber
Sep 10, 2014, 2:19:42 AM9/10/14
to
Rupert Haselbeck <mein-re...@gmx.de> wrote:
>Sven Hartge schrieb:
>> Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
>> traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
>> ICMP-basierten.
>
>Die Lücken in der Hop-Liste sind doch nicht von Interesse, solange der
>jeweils darauffolgende Hop keine Paketverluste zetgt
Es verwirrt Leute, die sich nicht auskennen, und erhöht die Dauer des
>Sven Hartge schrieb:
>> Meine Erfahrungen zeigen mir, dass man mit dem klassichen UDP-basierten
>> traceroute noch mehr Lücken in der Hop-Liste hat wie mit einem
>> ICMP-basierten.
>
>Die Lücken in der Hop-Liste sind doch nicht von Interesse, solange der
>jeweils darauffolgende Hop keine Paketverluste zetgt
Traces.
Juergen Ilse
Sep 10, 2014, 2:30:45 AM9/10/14
to
> Juergen Ilse schrieb:
>> Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
>> identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
>> denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
>> timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
>> lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
>> Ahnung hast?
> Hoppala, da hat wohl einer ein grï¿œsseres Problem, wenn man den Finger in die
>> Natuerlich wurde das Problem beseitigt, nachdem es erst einmal einwandfrei
>> identifiziert wurde. Du hast anscheinend nicht die geringste Ahnung, wie
>> denn das Routing im Internet funktioniert. Du faselst etwas von "subop-
>> timalen Massnahmen" ohne auch nur im Ansatz zu wissen, worum es eigent-
>> lich geht. Warum aeusserst du dzch ueberhaupt dazu, wenn du davon keine
>> Ahnung hast?
> Wunde legt.
Nein.
> Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des Kunden
> das Problem nicht identifizieren kann,
auf die falsche Faehrte fuehren lassen", und das kann passieren (insbeson-
dere, wenn $KUNDE bevorzugt seine Schlussfolgerungen und erst auf mehr-
fachesa nachfragen die Fakten, die in zu dieser Schlussfolgerung gebracht
haben, anfuehrt ... So etwas merkst du spaetestens dann, wenn du als der-
jenige, der solche Probleme beseitigen soll, mit solchen Kundeninforma-
tionen beliefert wirst (schlimmstenfalls noch als "stille Post" via 1st-
Level-Support).
So ein Gelaber wie von dir hoere ich dirchaus oefter von Leuten, die nicht
die geringste Vorstellung haben, wie denn das Internet wirklich aussieht:
ein Konglomerat von mehr als einer halben Million IPv4-Netzbloecken, deren
Erreichbarkeit via BGP ausgetauscht und bei dem das routing (beeinflusst
von *allen* daran beteiligten Providern) sich staendig aendern kann, wo
niemand wirklich auch nur zu irgend einem Zeitpunkt einen annaehernden
Gesamtueberblick ueber alle daran beteiligten Routen hat und wo so gut
wie alle Aenderungen automatisiert ohne manuelles eingreifen passieren.
Manchmal denkt man sich da schon "es ist fast ein Wunder, dass das ganze
Zeug ueberhaupt noch so gut funktioniert".
Helmut Hullen
Sep 10, 2014, 10:23:00 AM9/10/14
to
Hallo, Juergen,
Du meintest am 10.09.14:
[...]
>> Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des
>> Kunden das Problem nicht identifizieren kann,
> Es geht nicht um "nicht identifizieren kann" sondern um "sich erst
> einmal auf die falsche Faehrte fuehren lassen", und das kann
> passieren (insbeson- dere, wenn $KUNDE bevorzugt seine
> Schlussfolgerungen und erst auf mehr- fachesa nachfragen die Fakten,
> die in zu dieser Schlussfolgerung gebracht haben, anfuehrt ...
Lass mich raten:
a) Du arbeitest im Kundendienst,
b) Deine Kunden sind allesamt IT-Fachleute und diagnostizieren stets
korrekt und umfassend?
Viele Gruesse!
Helmut
Du meintest am 10.09.14:
[...]
>> Einen Techniker, der wegen einer unzutreffenden Schlussfolgerung des
>> Kunden das Problem nicht identifizieren kann,
> Es geht nicht um "nicht identifizieren kann" sondern um "sich erst
> einmal auf die falsche Faehrte fuehren lassen", und das kann
> passieren (insbeson- dere, wenn $KUNDE bevorzugt seine
> Schlussfolgerungen und erst auf mehr- fachesa nachfragen die Fakten,
> die in zu dieser Schlussfolgerung gebracht haben, anfuehrt ...
a) Du arbeitest im Kundendienst,
b) Deine Kunden sind allesamt IT-Fachleute und diagnostizieren stets
korrekt und umfassend?
Viele Gruesse!
Helmut
Jörg Tewes
Sep 9, 2014, 9:54:00 PM9/9/14
to
Marc Haber schrub
> J锟絩g Tewes <jogi...@gmx.net> wrote:
>> Marc Haber schrub
>>> Den (zugenagelten) Router muss man so etwa einmal in der Woche
>>> resetten, wenn Latenzen in der Gr锟斤拷enordnung von 2 Sekunden
>>> auftreten.
>> Zu einer Domain die in D gehostet wird, oder au锟絜rhalb?
> Zu einer Domain hat man keine Latenzen.
Naja dann eben zum Zeil. :-)
> Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
> Fritzbox auf.
Schon klar. Ich meinte halt ob es bei dir z.B. zu heise.de auftritt,
oder zu asus.com
> Wenn ich mich richtig erinnere, l锟絪st sich die Fritzbox
ihr liegen, warum also einen Reset? W锟絩e f锟絩 mich unlogisch. Oder bin
ich da irgendwie auf dem Holzweg?
> Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
> in den USA aber mit 锟絙erdimensional hoher Latenz, dann ist der Fehler
>> Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
>> welcher Firmware?
> FRITZ!Box 6360 Cable (kbw), fritz-6360-kbw FRITZ!OS 06.04
Hier genau dieselbe. Keinerlei Probleme, seit 锟絙er 2 Jahren. Hmmm.
Bye J锟絩g
--
"I am the right hand of vengeance. And the boot that is gonna kick your sorry
ass all the way back to earth. I'm death incarnate and the last living thing
that you are ever going to see. God sent me!!"
(Ivanova in "Between the Darkness and the Light")
> J锟絩g Tewes <jogi...@gmx.net> wrote:
>> Marc Haber schrub
>>> Den (zugenagelten) Router muss man so etwa einmal in der Woche
>>> auftreten.
>> Zu einer Domain die in D gehostet wird, oder au锟絜rhalb?
> Zu einer Domain hat man keine Latenzen.
> Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
> Fritzbox auf.
oder zu asus.com
> Wenn ich mich richtig erinnere, l锟絪st sich die Fritzbox
> noch im Rahmen der Erwartungen anpingen. Das ist jetzt aber lange
> nicht mehr aufgetreten.
Wenn sich die Fritzbox noch normal anpingen l锟斤拷t, kann es doch kaum an
> nicht mehr aufgetreten.
ihr liegen, warum also einen Reset? W锟絩e f锟絩 mich unlogisch. Oder bin
ich da irgendwie auf dem Holzweg?
> Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
> im allgemeinen nicht im CPE zu suchen.
Das dachte ich mir auch. Aber warum dann resetten?
>> Hattest du eigentlich eine Fritzbox 6360 oder was anderes, und mit
>> welcher Firmware?
> FRITZ!Box 6360 Cable (kbw), fritz-6360-kbw FRITZ!OS 06.04
Bye J锟絩g
--
"I am the right hand of vengeance. And the boot that is gonna kick your sorry
ass all the way back to earth. I'm death incarnate and the last living thing
that you are ever going to see. God sent me!!"
(Ivanova in "Between the Darkness and the Light")
Marc Haber
Sep 11, 2014, 2:49:39 AM9/11/14
to
>> Die Latenzen treten im Traceroute ab dem ersten IP-Hop hinter der
>> Fritzbox auf.
>
>Schon klar. Ich meinte halt ob es bei dir z.B. zu heise.de auftritt,
>oder zu asus.com
Egal wohin.
>> Fritzbox auf.
>
>Schon klar. Ich meinte halt ob es bei dir z.B. zu heise.de auftritt,
>oder zu asus.com
>> Wenn ich mich richtig erinnere, lässt sich die Fritzbox
>> noch im Rahmen der Erwartungen anpingen. Das ist jetzt aber lange
>> nicht mehr aufgetreten.
>
>Wenn sich die Fritzbox noch normal anpingen läßt, kann es doch kaum an
>> nicht mehr aufgetreten.
>
>ihr liegen, warum also einen Reset? Wäre für mich unlogisch. Oder bin
>ich da irgendwie auf dem Holzweg?
Ich könnte mir vorstellen, dass da irgendwas auf der Kabelseite "aus
dem Sync" geraten ist, das muss den Prozessor der Fritzbox selbst
nicht notwendigerweise betreffen.
>> Wenn ein Host in Deutschland mit normaler Latenz anpingbar ist, einer
>> im allgemeinen nicht im CPE zu suchen.
>
>Das dachte ich mir auch. Aber warum dann resetten?
Weil hohe Latenz überall hin durchaus am CPE liegen kann.
>
>Das dachte ich mir auch. Aber warum dann resetten?
Alexander Burger
Sep 13, 2014, 8:50:41 PM9/13/14
to
hier ein Beispiel:
/usr/sbin/mtr --report -c 100 spiegel.de
HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.30.20.41 19.0% 100 19.9 28.5 7.7 396.0 65.6
4.|-- 84.116.191.25 22.0% 100 10.9 22.9 8.5 284.6 44.5
5.|-- 84.116.191.2 21.0% 100 26.8 21.1 11.1 175.5 28.5
6.|-- xe-0.de-cix.frnkge03.de.b 21.0% 100 25.8 18.6 12.6 65.4 11.1
7.|-- 212.119.27.190 23.0% 100 14.3 40.5 12.7 463.8 90.5
8.|-- unknown.prolexic.com 20.0% 100 14.3 35.3 11.9 352.4 67.5
9.|-- unknown.prolexic.com 23.0% 100 13.9 27.0 11.7 257.9 43.6
die Verluste liegen bei 20 Prozent.
Das ist aber nur gemittelt.
Wenn ich das live anschaue, können die Verluste für einige Sekunden auch mal
bei 100 Prozent auf der ganzen Strecke liegen. Danach klappt es wieder, dann
wieder nicht usw.
Gruß
Alex
Sven Hartge
Sep 13, 2014, 10:43:33 PM9/13/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
> /usr/sbin/mtr --report -c 100 spiegel.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
> 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 3.|-- 172.30.20.41 19.0% 100 19.9 28.5 7.7 396.0 65.6
> 4.|-- 84.116.191.25 22.0% 100 10.9 22.9 8.5 284.6 44.5
> 5.|-- 84.116.191.2 21.0% 100 26.8 21.1 11.1 175.5 28.5
> 6.|-- xe-0.de-cix.frnkge03.de.b 21.0% 100 25.8 18.6 12.6 65.4 11.1
> 7.|-- 212.119.27.190 23.0% 100 14.3 40.5 12.7 463.8 90.5
> 8.|-- unknown.prolexic.com 20.0% 100 14.3 35.3 11.9 352.4 67.5
> 9.|-- unknown.prolexic.com 23.0% 100 13.9 27.0 11.7 257.9 43.6
> die Verluste liegen bei 20 Prozent.
> Das ist aber nur gemittelt.
> Wenn ich das live anschaue, können die Verluste für einige Sekunden auch mal
> bei 100 Prozent auf der ganzen Strecke liegen. Danach klappt es wieder, dann
> wieder nicht usw.
Da die Verluste schon ab deinem lokalen Router auftreten, ist entweder
> /usr/sbin/mtr --report -c 100 spiegel.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
> 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
> 3.|-- 172.30.20.41 19.0% 100 19.9 28.5 7.7 396.0 65.6
> 4.|-- 84.116.191.25 22.0% 100 10.9 22.9 8.5 284.6 44.5
> 5.|-- 84.116.191.2 21.0% 100 26.8 21.1 11.1 175.5 28.5
> 6.|-- xe-0.de-cix.frnkge03.de.b 21.0% 100 25.8 18.6 12.6 65.4 11.1
> 7.|-- 212.119.27.190 23.0% 100 14.3 40.5 12.7 463.8 90.5
> 8.|-- unknown.prolexic.com 20.0% 100 14.3 35.3 11.9 352.4 67.5
> 9.|-- unknown.prolexic.com 23.0% 100 13.9 27.0 11.7 257.9 43.6
> die Verluste liegen bei 20 Prozent.
> Das ist aber nur gemittelt.
> Wenn ich das live anschaue, können die Verluste für einige Sekunden auch mal
> bei 100 Prozent auf der ganzen Strecke liegen. Danach klappt es wieder, dann
> wieder nicht usw.
der defekt, oder, wenn du WLAN benutzt, das gestört.
Oder natürlich das Gerät, von dem du den Test aus machst, hat ein
Problem, da die Verluste scheinbar bei dir lokal entstehen.
Hast du ein zweites Gerät neben dem solchen, von dem du die Tests
gemacht hast, zur Hand?
Zeigt das zur gleichen Zeit die gleichen Probleme? Dann würde ich den
Router mal resetten, wenn die Probleme bestehen und schauen, was
passiert.
Was passiert, wenn du, während die Probleme bestehen, nur deinen Router
direkt anpingst, also "ping 192.168.1.1"?
Heiko Schlichting
Sep 14, 2014, 1:56:39 PM9/14/14
to
Alexander Burger <alexande...@yahoo.de> wrote:
>
> es gab wieder Probleme am samstagabend, wie immer eigentlich:
>
> hier ein Beispiel:
>
> /usr/sbin/mtr --report -c 100 spiegel.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
Paketverluste bereits zum Router --> Das Problem liegt aber in Deinem
>
> es gab wieder Probleme am samstagabend, wie immer eigentlich:
>
> hier ein Beispiel:
>
> /usr/sbin/mtr --report -c 100 spiegel.de
> HOST: linux-3pla Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.1.1 23.0% 100 0.6 0.6 0.4 2.8 0.3
lokalen Netzwerk (einschl. des Routers). Wie ich schon vermutet habe, ist
*nicht* der Backbone des Providers Schuldￜ.
Schliess einen Rechner mit einem Kabelￜ direkt am Router an und probiere es
damit aus. Falls es besser wird, ist Dein WLAN Schuld. Falls nicht,
rebooteￜ den Router
Heiko
ￜ Die Grￜnde nannte ich ja im vorherigen Posting
ￜ Ja, wir kennen alle die Ausreden mit "habe mit WLAN direkt neben dem
Router probiert". Nur Kabel ist Kabel!
ￜ in der Reihenfolge, sonst bist Du hinterher so schlau wie vorher
0 new messages