Προβληματα packet size στη hol

[netblues]

Απο νωρις το πρωι ουσιαστικα δεν παιζει τιποτε σe vdsl HOL μεσω KV.

Σε επιπεδο vdsl ολα ειναι μια χαρα. Ανυπαρκτα λαθη, attainalbe 107Mbits down/ 41 Mbits up
Παιζει το www.hol.gr ΣΦΑΙΡΑ, παιζει το gmail και το google επισης σφαιρα, και απο κει και περα περιπου τιποτε
Ουτε naftemporiki (που ειναι στη hol).
Σε επιπεδο ping, απαντανε τα παντα,(οσα δλδ δεν το εχουν κομμενο)
πχ cisco.com
PING e144.dscb.akamaiedge.net (2.18.80.170) 56(84) bytes of data.
64 bytes from 2.18.80.170: icmp_seq=1 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=2 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=3 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=4 ttl=59 time=50.1 ms
64 bytes from 2.18.80.170: icmp_seq=5 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=6 ttl=59 time=50.6 ms
64 bytes from 2.18.80.170: icmp_seq=7 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=8 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=9 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=10 ttl=59 time=50.1 ms
64 bytes from 2.18.80.170: icmp_seq=11 ttl=59 time=50.0 ms
64 bytes from 2.18.80.170: icmp_seq=12 ttl=59 time=50.0 ms
64 bytes from 2.18.80.170: icmp_seq=13 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=14 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=15 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=16 ttl=59 time=50.5 ms
64 bytes from 2.18.80.170: icmp_seq=17 ttl=59 time=50.4 ms
64 bytes from 2.18.80.170: icmp_seq=18 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=19 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=20 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=21 ttl=59 time=50.2 ms
64 bytes from 2.18.80.170: icmp_seq=22 ttl=59 time=50.3 ms
64 bytes from 2.18.80.170: icmp_seq=23 ttl=59 time=50.3 ms

--- e144.dscb.akamaiedge.net ping statistics ---
23 packets transmitted, 23 received, 0% packet loss, time 22010ms
rtt min/avg/max/mdev = 50.065/50.293/50.656/0.317 ms


Αλλα στο www.cisco.com δεν προκειται να μπε ποτε
Δοκιμασμενο απο διαφορα pc, tablet κλπ, ενσυρματα και ασυρματα.
Εγινε και γενικο reboot, αλλαξαμε και ip, NADA

Σε ping
ping -s 1464 www.cisco.com
PING e144.dscb.akamaiedge.net (2.18.80.170) 1464(1492) bytes of data.
1472 bytes from 2.18.80.170: icmp_seq=1 ttl=59 time=53.4 ms
1472 bytes from 2.18.80.170: icmp_seq=2 ttl=59 time=53.4 ms
1472 bytes from 2.18.80.170: icmp_seq=3 ttl=59 time=53.6 ms
1472 bytes from 2.18.80.170: icmp_seq=4 ttl=59 time=53.5 ms

--- e144.dscb.akamaiedge.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 53.416/53.513/53.672/0.189 ms


Αν ομως
ping -s 1465 www.cisco.com
PING e144.dscb.akamaiedge.net (2.18.80.170) 1465(1493) bytes of data.

--- e144.dscb.akamaiedge.net ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

Την ιδια στιγμη απο otenet linux vdsl host
ping -s 1465 www.cisco.com
PING e144.dscb.akamaiedge.net (184.24.192.170) 1465(1493) bytes of data.
1473 bytes from a184-24-192-170.deploy.static.akamaitechnologies.com (184.24.192.170): icmp_seq=1 ttl=52 time=78.4 ms
1473 bytes from a184-24-192-170.deploy.static.akamaitechnologies.com (184.24.192.170): icmp_seq=2 ttl=52 time=76.8 ms
1473 bytes from a184-24-192-170.deploy.static.akamaitechnologies.com (184.24.192.170): icmp_seq=3 ttl=52 time=74.9 ms
1473 bytes from a184-24-192-170.deploy.static.akamaitechnologies.com (184.24.192.170): icmp_seq=4 ttl=52 time=73.5 ms
^C
--- e144.dscb.akamaiedge.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3499ms
rtt min/avg/max/mdev = 73.583/75.967/78.454/1.855 ms

αλλα και
ping -s 5000 www.cisco.com
PING e144.dscb.akamaiedge.net (184.50.160.170) 5000(5028) bytes of data.
5008 bytes from a184-50-160-170.deploy.static.akamaitechnologies.com (184.50.160.170): icmp_seq=1 ttl=52 time=93.9 ms
5008 bytes from a184-50-160-170.deploy.static.akamaitechnologies.com (184.50.160.170): icmp_seq=2 ttl=52 time=96.9 ms
^C
--- e144.dscb.akamaiedge.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1914ms
rtt min/avg/max/mdev = 93.920/95.413/96.906/1.493 ms


Τα ιδια γινονται και με διαφορα αλλα hosts.

Ομως, οταν κανω
ping -s 3000 athedsl-344774.home.otenet.gr
PING athedsl-344774.home.otenet.gr (85.72.202.100) 3000(3028) bytes of data.
3008 bytes from athedsl-344774.home.otenet.gr (85.72.202.100): icmp_seq=1 ttl=57 time=44.3 ms
3008 bytes from athedsl-344774.home.otenet.gr (85.72.202.100): icmp_seq=2 ttl=57 time=42.9 ms
3008 bytes from athedsl-344774.home.otenet.gr (85.72.202.100): icmp_seq=3 ttl=57 time=46.2 ms
3008 bytes from athedsl-344774.home.otenet.gr (85.72.202.100): icmp_seq=4 ttl=57 time=46.5 ms
3008 bytes from athedsl-344774.home.otenet.gr (85.72.202.100): icmp_seq=5 ttl=57 time=45.5 ms
3008 bytes from athedsl-344774.home.otenet.gr (85.72.202.100): icmp_seq=6 ttl=57 time=45.1 ms

--- athedsl-344774.home.otenet.gr ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 42.944/45.145/46.547/1.221 ms

απο hol με μεγαλο packet size στον οτενετ vdsl host, μια χαρα δουλευει το ping, (αλλα και ενας mail server που ειναι εκει )
Ολα τα hol pings γινονται απο linux host που τρεχει pppoe χωρις κανενος ειδους nat.
Και βεβαια μεχρι χτες δουλευαν τα παντα ολα, και οχι δεν εγινε καμμια αλλαγη.

Για να γραψω αυτο το ποστ ειμαι με remote desktop σε otenet που δουλευει.
Επισης δουλευει sip (που γενικως εχει μικρα πακετα)
αλλα και openvpn με udp στη hetzner... ( στον ιδιο host με ssh συνδεεται, αλλα μολις ζητησεις κατι μεγαλο, πχ htop, παγωνει και τελος...)
Απο αλλου, μια χαρα και το ssh στον ιδιο host.

Δεν μπορει να το εχω μονο εγω. Οτιδηποτε με μεγαλο packet sizε, μεγαλυτερο απο 1492 bytes, δεν, εκτος απο μερικα sites που παιζει....

Το κακο ειναι οτι στο support δεν ξερουν κατι. Ειτε ειναι θεμα vdsl ειτε θεμα subnet. Το vdsl της hol περνει παντα 91.138.xxx.xxx

Να υποθεσω οτι ειναι και αλλοι απλα δεν μπορουν να μπουν να γραψουν? :worthy::worthy:

[valen_gr]

το ιδιο οταν κανει το ΡΡΡ το hol router?

[netblues]

Αυτος ειναι σφραγισμενος στο κουτι του εδω και 10 μηνες.. :)
Αν ηταν παντου το προβλημα, να τα ριξουμε στο cpe.
Το να εγινε ξαφνικα επιλεκτικο το centos και να κανει drop ορισμενα μεγαλα πακετα ειναι ισως το πιο απιθανο με διαφορα.

- - - Updated - - -

Επανερχομαι.
Κατι τρεχει με το mtu discovery.
Εκανα force το mss με clampmss σε 1452, με το Mtu στο 1492, και συνηλθε το tcp, οποτε παιζουν τα sites μεν, αλλα η ταχυτητα δεν ειναι αυτο που πρεπει
Ξεκιναμε καλα με ftp στα 4,8Μbytes/sec για να σταθεροποιηθει στο 1,6 Mb/sec
Και παλι καλα να λεμε.
Ουσιαστικα μικριναμε τα πακετα ωστε να μην γινονται fragment.
Το ping βεβαια συνεχιζει να μην παιζει με μεγαλο packet size (δλδ fragmented) ΕΚΤΟΣ απο youtube, gmail google και www.hol.gr.
Το support μου ειπε οτι εχουν γενικα ενα θεματακι ταχυτητας στο vdsl...
Λογικο.
To speedtest, καθοτι multi session δεν καταλαβαινει και δειχνει full speed.

Προφανως τα ρουτερακια που δινουν, χαμηλωνουν το mss και γιαυτο δεν τσιριζουν πολλοι.
Ομως το προβλημα υπαρχει, το ping με μεγαλο packet size παραμενει προβληματικο...
Και δεν ειναι προβλημα cpe αυτο.

Καποιος με vdsl συνδεση να κανει ping πχ στο www.cisco.com με packet size πανω απο 1500 bytes και να μας ελεγε αν δουλευει θα ηταν καλο.

[PascM]

Με απλά λόγια κάτι τρέχει και δεν φτάνει ; ...όπως τα βλέπω, δεν θα αποκτήσουμε δύκτιο ποτέ στην Ελλάδα... :(

[SfH]

Το mtu που υποστηρίζουν οι επίσημα πάροχοι για pppoe είναι 1492 ( και ορθά έβαλες το mss σε 1452, για να γλυτώνεις το φόρτο του fragmentation σε tcp όταν δε λειτουργεί ορθά το pmtud ). Μπορεί για διάφορους λόγους να δούλευε πριν το 1500, ή να δουλεύει ακόμα. Δε σημαίνει όμως ότι η χρήση του είναι καλή ιδέα.

ΥΓ: Το pmtud είναι "σπασμένο" σε τεράστιο ποσοστό του internet. Στο ping που κάνεις όμως, δεν έχει ιδιαίτερη σημασία, εφόσον στέλνεις με ορισμένο μέγεθος και DF set.

[netblues]

Παντα το mtu στο pppoe ηταν 1492, αυτο δεν ηταν ποτε προβλημα.
Ομως ετσι ξαφνικα να πρεπει να "χωσω" clampmss ειναι περιεργο
Χωρις clampmss δουλευει σε forthnet, wind και ote (και hol μεχρι χτες τα χαραματα.)
Το θεμα με το ping απλα δειχνει οτι κατι δεν δουλευει σωστα με το fragmentation.
Για παραδειγμα
ping -s 1500 www.cisco.com κσνει αυτη τη στιγμη απο hetzner,wind και οτε, οχι ομως απο Hol vdsl.
Κανειις με adsl hol να το δοκιμαζε?
Τωρα τι μπορει αυτο να σημαινει γενικοτερα στο throughput ειναι κατι που ψαχνω, ομως δεν ειναι και τοσο ευκολα τα συμπερασματα.
Σιγουρα ομως κατι αλλαξε, προς το χειροτερο.

ping -s 1500 -M dont www.cisco.com που ζηταει fragment δεν παιζει, οπως και το -M want
Με -Μ do παιρνω το αναμενομενο
From pppxxx.dsl.hol.gr (91.138.138.xxx) icmp_seq=1 Frag needed and DF set (mtu = 1492)
needed and DF set (mtu = 1492) απο το local ppp interface.

[vforvendetta85]

Επειδή δεν κατάλαβα και πολλά, πες μου τι εντολή θες να δώσω (συνδρομητής adsl είμαι). :)

- - - Updated - - -

Μάλλον κατάλαβα τι εννοείς:

1508 bytes of data 2.18.80.170: icmp_seq=5 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=6 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=7 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=8 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=9 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=10 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=11 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=12 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=13 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=14 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=15 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=16 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=17 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=18 ttl=58 time=90.0 ms
1508 bytes of data 2.18.80.170: icmp_seq=19 ttl=58 time=90.0 ms

--- 2.18.80.170 ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 90.0/90.5/100.0 ms