Frage
Antwort
Lösung
Hallo,
Grade absenden gedrückt und alles war weg, nochmal von neuem Schreiben wow.
Ich mach es kurz.
Ich hatte ein Störungsticket Telefonisch eröffnet was heute geschlossen wurde am Sonntag.
Folgende Störung
Ping-Spikes und hohen Jitter-Wert von den ersten 1-2 Hops von Vodafone.
Ein Screenshot:
Fehleranalyse/Fehlerquelle (PingPlotter):
1. HOP
ipservice-092-218-208-001.092.218.pools.vodafone-ip.de
2. HOP
ipservice-092-218-208-001.092.218.pools.vodafone-ip.de
Problem ist wie unten Dauerhaft habe das Endergebniss gespeichert und ein ganzen Tag durchlaufen lassen.
Ausschnitt_5_Minuten_Timeline:
Was gemacht wurde:
- TAE Dose wurde erneuert vom Techniker.
- Neuer Router zum Einsatz gebracht
- Router Restart
- Störung gemeldet am Freitag
Hier ist der komplette Ausschnitt -> Final Destination.
Das hatte ich heute erst gelesen, deswegen entschuldigung das ich nur die 1-2 Hops Fixiert hatte.
Some routers just don't prioritize timed out ICMP requests very high (ICMP requests where the TTL equals 0 after reaching them). If the hop right after consistently performs well, just don't factor this hop into your troubleshooting equation (i.e. ignore it).
In the screenshot above, hop 4 is a great example of this - hop 4 shows packet loss and high latency, but downstream hops (5- 11) look great. Since data getting to hop 5 needs to go through hop 4, this is normal and it's not anything that needs to be chased as a problem. Hop 2 is another example of this.
Another possibility here is that an intermediate hop might use a return route that is different than the hop following (or the final destination). This can mean there is a problem with one return route but not another. Since each hop makes its own decisions about routing, this can definitely happen.
The important thing to remember is that the only thing that really matters is the final destination. If the final hop is showing 0% packet loss and acceptable latency, then all the hops before that can show all kinds of errors and as long as the final destination isn't affected, then this is an artifact of router configuration, and there is no problem.
The only hop that really matters is the final destination - the rest of the data at intermediate hops is only useful when there is problems at the final destination - then you can look at intermediate hops to determine the cause of the problem.
If a particular hop is showing 100% packet loss, it might just not be configured to return packets to the sender when TTL=0 (we rely on this to get information about intermediate hops).
Having one or more non-responding intermediate hops is very normal and doesn't indicate there is a problem. If everything else looks good, just ignore those hops.
Wie man aber hier auf dem Bild sieht war zwischen 00:00 - 7:00 Uhr keine extremen Spikes dabei.
