AVM FRITZ!Box 7530

[dpap76]

Δοκίμασε το, το MTU/MRU το συνεννοούνται ο BRAS (οχι τα dslam) με το modem σου.

Ο/οι BRAS του οτε υποστηρίζουν RFC4638 και όπως ειπώθηκε σε fiber δουλεύει τέλεια, δεν βλέπω λόγο να μην δουλεύει και στο vdsl (στο adsl/ATM είναι άλλη ιστορία και δεν υπάρχει κάποιο αντίστοιχο RFC για PPPoA)

Αν δουλέψει το ping -4 -f -l 1472 ftp.grnet.gr είσαι οκ στο IPv4 με MTU 1500.

στο 1473 θα παίρνεις μήνυμα Packet needs to be fragmented but DF set.

αν είστε πίσω από DS-Lite RFC 6333 τότε λόγo 4in6 encapsulation θα πρέπει να βγάλουμε άλλα 20 byte απο τους headers και το νούμερο για το ping test πάει στα 1452

[kadronarxis]

Σας ευχαριστώ παιδιά.
Το 7530 έχει την παραπάνω επιλογή και την τίκαρα.
Άρα τώρα επικοινωνεί ο ρούτερ με BRAS στα 1500.

Στα windows τώρα αν δώσω σε cmd, netsh interface ipv4 show subinterface, μου δίνει σε Ethernet 1500.

Άρα το 7530 όπως κατάλαβα δε μπορεί να αλλάξει σε 1473 ή 1472.
Αν δώσω στα windows netsh interface ipv4 set subinterface “Ethernet” mtu=1473 store=persistent
θα αλλάξουν τα windows σε 1473 αλλά ο ρούτερ θα παίζει στα 1500. Χάνω πακέτα έτσι;

[dpap76]

Άρα το 7530 όπως κατάλαβα δε μπορεί να αλλάξει σε 1473 ή 1472.
Αν δώσω στα windows netsh interface ipv4 set subinterface “Ethernet” mtu=1473 store=persistent
θα αλλάξουν τα windows σε 1473 αλλά ο ρούτερ θα παίζει στα 1500. Χάνω πακέτα έτσι;

ωπ, ωπ, ωπ, μισό, για να μην μπερδευτούμε: καταρχήν δεν χρειάζεται/δεν πρέπει να δωσεις την εντολη netsh για να αλλάξεις στα windows το mtu του ethernet. το MTU του ethernet interface είναι 1500 και αυτό θέλουμε. αν το άλλαξες ήδη επανάφερε το στα 1500 αμέσως. αυτο που συζητάμε είναι να αλλάξει και του pppoe interface σε 1500 αντί για 1492. το όλο παιχνίδι αφορά μόνο την επικοινωνία modem <-> bras, οι σταθμοί απο πίσω δεν έχουν ίδέα/δεν τους νοιαζει τι MTU θα έχουμε στο Pppoe μας.

το 1472/1473 που γράφουμε πάνω αφορούν στο PAYLOAD ενός ICMP πακέτου (ping) που είναι μέσα σε IPv4 πακέτο, που είναι μέσα σε PPP πακέτο, που είναι μέσα σε ένα PPPoE πακέτο. To σύνολο όλων αυτών (payload + headers) μας κανει 1500.

Και επειδή δεν θα δείς στην πράξη κάτι διαφορετικό ή θα αλλάξει κάτι, ουτε θα ανάψει κανενα λαμπάκι που λεει τώρα έχεις PPPoE MTU 1500 ή 1492 παρα μόνο αν εχεις προβλήματα, ενας τρόπος για να επιβεβαιώσεις εαν το ppp σου περνάει πλέον τα ελαφρώς μεγαλύτερα πακέτα είναι αυτός με το ping. thats all

[Morx]

ωπ, ωπ, ωπ, μισό, για να μην μπερδευτούμε: καταρχήν δεν χρειάζεται/δεν πρέπει να δωσεις την εντολη netsh για να αλλάξεις στα windows το mtu του ethernet. το MTU του ethernet interface είναι 1500 και αυτό θέλουμε. αν το άλλαξες ήδη επανάφερε το στα 1500 αμέσως. αυτο που συζητάμε είναι να αλλάξει και του pppoe interface σε 1500 αντί για 1492. το όλο παιχνίδι αφορά μόνο την επικοινωνία modem <-> bras, οι σταθμοί απο πίσω δεν έχουν ίδέα/δεν τους νοιαζει τι MTU θα έχουμε στο Pppoe μας.

το 1472/1473 που γράφουμε πάνω αφορούν στο PAYLOAD ενός ICMP πακέτου (ping) που είναι μέσα σε IPv4 πακέτο, που είναι μέσα σε PPP πακέτο, που είναι μέσα σε ένα PPPoE πακέτο. To σύνολο όλων αυτών (payload + headers) μας κανει 1500.

Και επειδή δεν θα δείς στην πράξη κάτι διαφορετικό ή θα αλλάξει κάτι, ουτε θα ανάψει κανενα λαμπάκι που λεει τώρα έχεις PPPoE MTU 1500 ή 1492 παρα μόνο αν εχεις προβλήματα, ενας τρόπος για να επιβεβαιώσεις εαν το ppp σου περνάει πλέον τα ελαφρώς μεγαλύτερα πακέτα είναι αυτός με το ping. thats all

Με 1492 σε Nova, παιρνω "Packet needs to be fragmented but DF set."

Παει κατι λαθος;

[dpap76]

Με 1492 σε Nova, παιρνω "Packet needs to be fragmented but DF set."

Παει κατι λαθος;

Όχι, εκεί -στο κλασσικό pppoe με 1492 bytes MTU/MRU δηλαδή καθώς απ' ότι φαίνεται οι BRAS της nova δεν υποστηρίζουν RFC4638- το maximum payload που μπορεί να περάσει το ping χωρίς να γίνει fragment το πακέτο (παράμετρος -f) είναι 8 bytes λιγότερο, δηλαδή 1472-8=1464.

Στα 1465 bytes και παραπάνω θα δούμε μήνυμα "Packet needs to be fragmented but DF set."

Κανένα πρόβλημα και αναμενόμενο. To συγκεκριμένο τεστ (παράμετρος -f) το κάνουμε για δοκιμή. Υπο κανονικές συνθήκες, τα πακέτα μας (πχ οταν κάνουμε browsing) είναι ελεύθερα να γίνουν fragment απο τον router μας και αυτό θα κάνει αν είναι μεγάλα. Δώστε πχ -l 5000 (χωρίς -f) και μια χαρά θα δουλέψει το ping καθώς "απο κάτω" και χωρίς να καταλάβουμε τίποτα, το CPE μας θα το σπάσει σε 3-4 πακέτα προκειμένου να το μεταδώσει. Το ίδιο και στην επιστροφή των πακέτων απο τον router του παρόχου (bras).

Όπως καταλαβαίνουμε είναι μια προβλεπόμενη "αγγαρεία" που βαραίνει το CPE & τον BRAS. Έχουμε ξαναπεί σε διπλανό thread ότι αν μπορούμε να το έχουμε καλώς ας το έχουμε. Αν όχι δεν πειράζει, 20 χρόνια στο vdsl εξάλου έτσι δουλεύαμε

ps) τα παραπάνω όλα ισχύουν για το ipv4. Στο ipv6 η αγγαρεία του fragmentation και η εύρεση του μέγιστου επιτρεπόμενου MTU στην διαδρομή μεταξύ του υπολογιστή μας και του server (path mtu discovery) είναι δουλειά των host (source & destintation) και όχι των ενδιάμεσων routers. Ξεκούραστα τα πράματα εκεί για τους routers και περισσότερος χρόνος και cpu cycles στη διάθεση τους να κάνουν αυτό που πρέπει να κάνουν: προώθηση των πακέτων και όχι κοπτοραπτική

[Morx]

Όχι, εκεί -στο κλασσικό pppoe με 1492 bytes MTU/MRU δηλαδή καθώς απ' ότι φαίνεται οι BRAS της nova δεν υποστηρίζουν RFC4638- το maximum payload που μπορεί να περάσει το ping χωρίς να γίνει fragment το πακέτο (παράμετρος -f) είναι 8 bytes λιγότερο, δηλαδή 1472-8=1464.

Στα 1465 bytes και παραπάνω θα δούμε μήνυμα "Packet needs to be fragmented but DF set."

Κανένα πρόβλημα και αναμενόμενο. To συγκεκριμένο τεστ (παράμετρος -f) το κάνουμε για δοκιμή. Υπο κανονικές συνθήκες, τα πακέτα μας (πχ οταν κάνουμε browsing) είναι ελεύθερα να γίνουν fragment απο τον router μας και αυτό θα κάνει αν είναι μεγάλα. Δώστε πχ -l 5000 (χωρίς -f) και μια χαρά θα δουλέψει το ping καθώς "απο κάτω" και χωρίς να καταλάβουμε τίποτα, το CPE μας θα το σπάσει σε 3-4 πακέτα προκειμένου να το μεταδώσει. Το ίδιο και στην επιστροφή των πακέτων απο τον router του παρόχου (bras).

Όπως καταλαβαίνουμε είναι μια προβλεπόμενη "αγγαρεία" που βαραίνει το CPE & τον BRAS. Έχουμε ξαναπεί σε διπλανό thread ότι αν μπορούμε να το έχουμε καλώς ας το έχουμε. Αν όχι δεν πειράζει, 20 χρόνια στο vdsl εξάλου έτσι δουλεύαμε

ps) τα παραπάνω όλα ισχύουν για το ipv4. Στο ipv6 η αγγαρεία του fragmentation και η εύρεση του μέγιστου επιτρεπόμενου MTU στην διαδρομή μεταξύ του υπολογιστή μας και του server (path mtu discovery) είναι δουλειά των host (source & destintation) και όχι των ενδιάμεσων routers. Ξεκούραστα τα πράματα εκεί για τους routers και περισσότερος χρόνος και cpu cycles στη διάθεση τους να κάνουν αυτό που πρέπει να κάνουν: προώθηση των πακέτων και όχι κοπτοραπτική

Ενα μεγαλο ευχαριστω για τις επεξηγησεις!!

[kadronarxis]

Ένα μεγάλο ευχαριστώ και απο μένα.

[netblues]

Δοκίμασε το, το MTU/MRU το συνεννοούνται ο BRAS (οχι τα dslam) με το modem σου.



Αν δουλέψει το ping -4 -f -l 1472 ftp.grnet.gr είσαι οκ στο IPv4 με MTU 1500.

Εχεις ιδεα τι κανει αυτο που εγραψες σε linux cli ?

[dpap76]

Εχεις ιδεα τι κανει αυτο που εγραψες σε linux cli ?

η αλήθεια είναι ότι όταν το έγραφα είχα ένα μειδίαμα στα χείλη μου και άφησα στον αναγνώστη να λύσει την άσκηση γιατί έπεσε/έκανε timeout το PPPoE του όταν έδωσε αυτή την εντολή από linux
Ας πρόσεχε και ας διάβαζε το man ping

Σοβαρά μιλώντας, ποιος φωστήρας στην MS σκέφτηκε ότι η κατάλληλη παράμετρος για να μαρκάρει με το DF flag τα πακέτα είναι το -f?

για όσους έχουν την απορία, στο linux η εντολή αυτή κάνει ένα μικρό DoS στο destination host στέλνοντας κατά ριπάς (-f = flood) δεκάδες χιλιάδες πακέτα ανα δευτερόλεπτο

το έτρεξα για δοκιμή/για πλάκα/for science στο linuxακι μου για ~28 secs:

[root@shuttle-dh410:~]# ping -4 -f -l 1472 ftp.grnet.gr
ping: WARNING: probably, rcvbuf is not enough to hold preload
PING (147.102.222.211) 56(84) bytes of data.
^C
--- ping statistics ---
607872 packets transmitted, 522541 received, 14.0377% packet loss, time 28184ms
rtt min/avg/max/mdev = 11.231/67.728/103.533/6.726 ms, pipe 1472, ipg/ewma 0.046/87.757 ms

εντάξει, άντεξε ο ftp.grnet.gr, αμα δείτε κανα spike στα γραφήματα του grix εγώ ήμουνα, sorry grnet

Μόνο 30Mbit/s το transmit. Έβγαλε τα λεφτά της η 1000αρα FTTH


και μόνο ~28.000 πακέτα το δευτερόλεπτο. Καλό το shuttle DH410 με τον 2Core x 2Threads Pentium Gold G6400 @ 4.00GHz. δεν του τόχα

[andresalonika]

@dpap76 καθηγητής!

Να μας ειδοποιήσεις αν κάνεις κάποιο workshop - σεμινάριο επάνω στα δίκτυα! Θα ήθελα πολύ να παρευρεθώ!

[mondeo]

Παιδιά κάπου εδώ μέσα υπάρχει οδηγός FritzBox και Vodafone One Net.
Μπορεί κάποιος να μας τον υποδείξει;

[AlexT544]

Παιδιά κάπου εδώ μέσα υπάρχει οδηγός FritzBox και Vodafone One Net.
Μπορεί κάποιος να μας τον υποδείξει;

Αυτόν εδώ λες;
https://www.adslgr.com/forum/threads...?ε-fritz-7490

[mondeo]

Ναι ευχαριστώ πολύ.

[mondeo]

60 μέρες up ο Φρίτζουλας πάνω σε καμπίνα Vodafone - Nokia.
Πρώτη φορά βλέπω λάθη, μάλλον επειδή έξω γίνεται της καταιγίδας το κάγκελο.

[matelas]

60 μέρες up ο Φρίτζουλας πάνω σε καμπίνα Vodafone - Nokia.
Πρώτη φορά βλέπω λάθη, μάλλον επειδή έξω γίνεται της καταιγίδας το κάγκελο.

Κ εδώ το ίδιο με 6 ώρες uptime, καμπίνα οτε nokia.

Από τον καιρό είναι.

Υπάρχουν φορές που όταν αστράφτει έξω αποσυγχρονίζει.

Spoiler:

Seconds with
Errors (ES)
20
0
Errors (SES)
0
0
Not Remediable Errors (CRC)
per minute
0.2
0
last 15 minutes
25
0
corrected DTU
per minute
11.3
0
last 15 minutes
1559
0
uncorrected DTU
per minute
5.6
0
last 15 minutes
490
0