Οδηγός χρήσης του Greek ISP Latency Graphs Tool (Smokeping)

[SfH]

ΕΙΣΑΓΩΓΗ

Το παρακάτω άρθρο έχει ως σκοπό να σας ενημερώσει για το πώς να κάνετε σχετικά ακριβείς βάσιμες υποθέσεις για την απόδοση των δικτύων των παρόχων με δεδομένα από το Greek ISP Latency Graphs Tool . Αν και επικεντρώνεται γύρω από το συγκεκριμένο εργαλείο, αυτά που θα διαβάσετε θα σας βοηθήσουν να ερμηνεύετε σωστά αποτελέσματα κι άπο άλλα δικτυακά εργαλεία, smokeping και μη, ενώ το άρθρο συμπεριλαμβάνει και μια μικρή δόση θεωρίας όσον αφορά τη δρομολόγηση. Θα ξεκινήσουμε με μερικές βασικές ερωταπαντήσεις και σιγά σιγά θα εμβαθύνουμε στο θέμα μας.

Τι είναι το Smokeping;

Ένα δικτυακό εργαλείο που μετράει, εκτός των άλλων, πόσος χρόνος χρειάζεται ( latency ) για να πάει ένα πακέτο από ένα αρχικό σημείο ( smokeping node ) σε ένα άλλο ( target ) και να επιστρέψει. Εάν αυτό το χρονικό διάστημα είναι μεγαλύτερο από ένα ρυθμισμένο όριο ( 2500ms στην περίπτωσή μας ) θεωρούμε ότι το πακέτο χάθηκε κι έχουμε απώλεια πακέτων ( packet loss ).

Γιατι στήθηκε το Greek ISP Latency Graphs Tool ?

Θέλαμε ένα εργαλείο μέτρησης ποιότητας των παρόχων, όσον αφορά τη διασύνδεση τους με το εξωτερικό, που να μας δίνει πιο πρακτικά αποτελέσματα από τους δείκτες ποιότητας της ΕΕΤΤ. Φυσικά και το latency που μετράμε στην προκειμένη περίπτωση είναι ένας από τους πολλούς παράγοντες που επηρεάζουν την αντιλαμβανόμενη ποιότητα ενός παρόχου.

Το στήσιμο μου φαίνεται διαφορετικό από τα smokeping που έχω δει στο παρελθόν. Γιατι ?

Η λογική είναι να ελέγχουμε όπου μπορούμε τα άκρα των κυκλωμάτων που βρίσκονται εντός της χώρας από nodes που βρίσκονται εκτός. Θα εξηγήσω αργότερα γιατί θεωρώ αυτή τη λύση καλύτερη. Υπάρχουν όμως και γραφήματα με πηγή nodes στη χώρα και targets εξωτερικού για όσους προτιμούν κλασσικά πατροπαράδοτα γραφήματα "από μέσα προς τα έξω".

Ας πάμε στις μετρήσεις.

[BREAK=Ερμηνεία μετρήσεων]

Πριν μπούμε στο "ψητό" , ας θέσουμε μερικούς κανόνες/παραδοχές στη μεθοδολογία μας.

• Καμία μέτρηση δε μας δίνει την πλήρη εικόνα από μόνη της. Ο μόνος που έχει πλήρη εικόνα για το δίκτυο του είναι ο ίδιος ο πάροχος.
• Οι δρομολογητές ( routers ) συνήθως δε χειρίζονται τα icmp πακέτα που έχουν στόχο τους ίδιους με τον ίδιο τρόπο που χειρίζονται τα πακέτα που είναι προς προώθηση. Σε οριακές περιπτώσεις τα γραφήματα ίσως δείξουν "προβλήματα-φαντάσματα".
• Για να είμαστε όσο γίνεται σίγουροι ότι δε μας επηρεάζουν άλλοι παράγοντες, όταν παρατηρούμε συμφόρηση ( congestion ) ή πλήρη απώλεια πακέτων ( 100% packet loss ) , για να βγάλουμε κάποιο πόρισμα, πρέπει να συμφωνούν όλοι οι nodes εξωτερικού ανεξαιρέτως.
• Όταν υπάρχει congestion, το latency graph δεν είναι ποτέ σταθερή ευθεία.
• Σε περιπτώσεις που οι στόχοι δεν απαντάνε σε icmp πακέτα εκτός δικτύου, στοχεύονται τα άκρα των κυκλωμάτων στο εξωτερικό από nodes εντός χώρας. Οι μετρήσεις αυτές και σε επίπεδο latency αλλά και packet loss, αν και είναι καλύτερες από την πλήρη απώλεια μετρήσεων, θα πρέπει να θεωρούνται πιθανώς ανακριβείς.
• Για τον ίδιο λόγο, δηλαδή επειδή γίνονται "από μέσα προς τα έξω", οι μετρήσεις στην κατηγορία Gameservers θα πρέπει επίσης να θεωρούνται πιθανώς ανακριβείς.

Ας πάμε στο "ψητό" λοιπόν. Κάθε γράφημα αναφέρει στο πάνω μέρος το στόχο ενώ κάθε γραμμή αντιπροσωπεύει τα αποτελέσματα από κάθε node. Εάν κάνουμε κλικ πάνω στο γράφημα, παίρνουμε αναλυτικά γραφήματα από κάθε node στο στόχο ξεχωριστά. Εάν κάνουμε κλικ σε κάποιο από τα αναλυτικά αυτα γραφήματα, μας δίνεται η δυνατότητα να επιλέξουμε το χρονικό διάστημα της μέτρησης, είτε με τη χρήση των κουτιών κάτω από το γράφημα, ή κλικάρωντας και "τραβώντας" τον cursor του ποντικιού μέχρι να επιλεγεί η χρονική περιοχή που θέλουμε.

Το παρακάτω είναι ένα τυπικό παράδειγμα congestion τις ώρες αιχμής.



Εδώ βλέπουμε ένα μικρότερης διάρκειας μπούκωμα, εφόσον φυσικά συμφωνούν και οι άλλοι nodes εξωτερικού.



Εδώ βλέπουμε την πτώση ενός κυκλώματος, εφόσον βλέπουμε και packet loss αλλά και συμφωνούν οι υπόλοιποι nodes εξωτερικού. Στην περίπτωση που δε συμφωνούσαν και δε φαινόταν packet loss, πιο πιθανό θα ήταν να είχε πέσει κάποιος node παρά το κύκλωμα.



Εδώ δεν βλέπουμε congestion καθώς ή γραμμή ήταν και είναι ευθεία. Η γωνία είναι μάλλον αποτέλεσμα αναδρομολόγησης ή κάποιας άλλης ενέργειας.



Φαντάζομαι ήταν ευκολότερο από ότι περιμένατε, δεδομένου του κουραστικού/τεχνικού προλόγου. Όποιος έχει όρεξη για παραπάνω, ας μας ακολουθήσει στην επόμενη σελίδα που, αφού εξηγήσαμε το "τι", ασχολείται με το "γιατί" ενώ εξηγεί και τη λογική του "από έξω προς τα μέσα" που πιθανώς μου ρίχνετε γελαδίσιες ματίες όταν το βλέπετε
[BREAK=Δυό κουταλιές ζάχαρη κι ένα κουταλάκι δρομολόγηση]

Σε αυτή τη σελίδα θα μιλήσουμε για την ασύμμετρη δρομολόγηση ( asymmetric routing ) , πώς προκαλείται και τι επιπτώσεις έχει στις μετρήσεις μας.

Ας πάρουμε την υποθετική sfhnet που έχει 8.000 πελάτες και κύκλωμα 1gbps με την sprint. Η εταιρία λοιπόν πάει καλά και ανεβάζει το πελατολόγιο της στους 15.000 . Επειδή η πλειοψηφία των χρήστων έχουν υπηρεσίες adsl, το κύκλωμα γεμίζει στην κατεύθυνση από έξω προς τα μέσα ( download ). Αγοράζει άλλο ένα κύκλωμα λοιπόν, με την AT&T αυτή τη φορά και "πετάει" 7.000 πελάτες εκεί, ή μήπως όχι ακριβώς ?

Να δούμε λίγο πως λειτουργεί η δρομολόγηση σε τεχνικό επίπεδο. Το πρωτόκολλο που είναι αρμόδιο για αυτή τη δουλειά ονομάζεται bgp, και η πλήρης ανάλυση του ξεφεύγει πολύ από τους στόχους αυτού του άρθου. Τα παρακάτω είναι σχετικά υπεραπλουστευμένα, αλλά σκοπός μου είναι να καταλάβετε τη φιλοσοφία του χωρίς να κουραστείτε πολύ.

Έχουμε τρεις οντότητες στο παράδειγμα, sfhnet, sprint και AT&T . Η κάθε οντότητα έχει ένα σύνολο ip διευθύνσεων ( δίκτυα ) από την αρμόδια αρχή. Οι 2 τελευταίες οντότητες δίνουν και transit, δηλαδή πρόσβαση και σε δίκτυα που δεν τους ανήκουν μεν, αλλά μπορούν μέσω των υποδομών τους να τα δουν ( πρακτικά μιλάμε για όλο το υπόλοιπο internet ). Με το bgp, ή κάθε οντότητα διαφημίζει τα δίκτυά της ( ή τη σύλλογη δικτύων που έχει λάβει από άλλες οντότητες ) σε άλλες οντότητες. Στη συγκεκριμένη περίπτωση, ας υποθέσουμε ότι η sfhnet διαφημίζει στις άλλες τα δίκτυα που της ανήκουν ( ips των πελατών της ) και οι άλλες διαφημίζουν "το υπόλοιπο internet" προς αυτή.

Χωρίς κάποια επιπλέον ρύθμιση, στο υποθετικό σενάριο μας, το bgp σε κάθε άκρο θα διαλέγει την πιο μικρή διαδρομή οσόν αφορά τις εμπλεκόμενες οντότητες. Υπεραπλουστευμένα, οι πελάτες της sprint θα βλέπουν όλους τους πελάτες μου ( download από τη δική μου οπτική γωνία ) από το κύκλωμα της sprint και όλοι οι πελάτες μου θα βλέπουν τους πελάτες της sprint ( upload ) πάλι από το ίδιο. Εγώ όμως δεν ήθελα να κάνω αυτό. Δε με νοιάζει τόσο η πιθανή διαφορά στην απόδωση που θα έχω ακολουθώντας την μικρότερη διαδρομή, όσο με νοιάζει να χωρίσω την κίνηση προς εμένα ( download ) στα 2 για να μη γεμίζει κανένα κύκλωμα. Οπότε, θα κάνω το εξης: θα διαφημίσω τους 7.000 νέους πελάτες μόνο από την AT&T. Το upload τους θα "βγαίνει" από το μικρότερο μονοπάτι, αλλά το download θα περνάει μόνο από την AT&T. Έτσι, ο φόρτος στα κυκλώματά μου θα είναι μοιρασμένος σωστά. Πώς γίνεται πρακτικά η δρομολόγηση εάν κάποιος από τους "νέους χρήστες" θέλει να κατεβάσει από ενα server της sprint ? Πελάτης->sfhnet->sprint->server->sprint->AT&T->sfhnet->πελάτης. Ας το δούμε και σε εικόνα για να το εμπεδώσουμε.



Το παραπάνω παράδειγμα είναι υπερβολικά απλό και αποτελεί μόνο μια από τις πιθανές λύσεις, άλλα αναφέρει μια λύση που όντως χρησιμοποιείται από αρκετούς ελληνικούς παρόχους και όχι μόνο. Ας δούμε το ασύμμετρο routing στην πράξη.

Traceroute από τον HOL GR node μου προς την telia στο amsterdam.

traceroute to 146.188.112.66 (146.188.112.66), 30 hops max, 40 byte packets
 1 x
 2 x
 3 x
 4  tengigaeth00-07-05-00.adr00.brd.hol.gr (62.38.97.26)  2.968 ms  2.664 ms  2.663 ms
 5  GigabitEthernet2-0-164.ipcolo1.frankfurt1.level3.net (62.67.38.17)  49.383 ms  64.709 ms  61.422 ms
 6  ae-22-79.car2.Frankfurt1.Level3.net (4.68.23.68)  65.614 ms ae-12-69.car2.Frankfurt1.Level3.net (4.68.23.4)  50.177 ms ae-42-99.car2.Frankfurt1.Level3.net (4.68.23.196)  64.832 ms
 7  mci-level3-ge.frankfurt1.Level3.net (4.68.63.78)  55.180 ms  47.359 ms  47.135 ms
 8  so-1-0-0.XT2.AMS2.ALTER.NET (146.188.14.206)  56.548 ms  56.151 ms  56.501 ms
 9  xe-11-0-0.BR2.AMS3.ALTER.NET (146.188.4.58)  53.335 ms  53.090 ms  53.637 ms
10  AMS-ge.telia.net (146.188.112.66)  53.270 ms  53.366 ms  53.508 ms

Traceroute από τον ίδιο router της telia στο amsterdam προς τον HOL GR node μου.

traceroute to x, 30 hops max, 40 byte packets
 1  GE6-3.BR1.AMS3.alter.net (146.188.112.65) [AS  702]  0.358 ms  0.354 ms  0.323 ms
 2  so-0-0-0.XT1.FFT1.ALTER.NET (146.188.14.193) [AS  702]  20.956 ms  11.198 ms  11.901 ms
 3  GigabitEthernet0-0-0.GW6.FFT4.ALTER.NET (149.227.18.98) [AS  702]  11.140 ms  11.224 ms  11.134 ms
 4  * 139.4.13.50 (139.4.13.50) [AS  702]  62.525 ms  56.305 ms
 5  tengigaeth00-01-00-02.adr00.ccr.hol.gr (62.38.96.29) [AS  3329]  58.543 ms  69.115 ms  58.323 ms
     MPLS Label=26030 CoS=0 TTL=255 S=1
 6  x
 7  x
 8  x  58.214 ms

Ώπα ? Τι έγινε? Γιατί βγαίνω από level3 κι έρχομαι από verizon ? Κι αν μπουκώσει κάτι πώς θα το καταλάβω ? Αφού και στα 2 traceroutes θα φαίνεται μπουκωμένο το κύκλωμα εξωτερικό-Ελλάδα. Μάλλον δε θα το καταλάβω και θα κατηγορώ άδικα.

Εδώ λοιπόν έχει νόημα το "από έξω προς τα μέσα". Θεωρούμε ( αυθαίρετα ) ότι η κατεύθυνση που έχει μεγαλύτερες πιθανότητες να μπουκώσει είναι από έξω προς τα μέσα ( download από τη μεριά του χρήστη ). Αν μέτραγα λοιπόν latency βάση του προηγούμενου παραδείγματος στο κύκλωμα με level3 και είχε γεμίσει προς την κατεύθυνση του download από τη μεριά του χρήστη τι θα γινόταν ? Χρήστης->hol->level3 ( που το κύκλωμα πιθανώς δεν είναι γεμάτο στην άλλη κατεύθυνση ) ->verizon->hol->χρήστης. Το πιθανώς μπουκωμένο κομμάτι ούτε που το μετρήσαμε. Αν το κύκλωμα από το οποίο με διαφημιζε ο isp ήταν μπουκωμένο, τότε θα έβγαινε μπουκωμένο ότι και να μέτραγα.

Στην περίπτωση του συγκεκριμένου smokeping όμως, ξέρουμε ότι από έξω προς τα μέσα, που είναι και η πιο πιθανή κατεύθυνση να βρούμε μπούκωμα , θα δρομολογηθεί όπως πρέπει. Μπορεί να επιστρέψει από άλλο, μπορεί κύκλωμα κάποιο του isp του node να είναι μπουκωμένο, δε μας ενδιαφέρει όμως γιατί έχουμε πολλά nodes. Για αυτό το λόγο θεωρώ και πιο ακριβή τη συγκεκριμένη σαν μεθοδολογία μέτρησης.

[BREAK=FAQ μέρος δεύτερο - Επίλογος]

Γιατί μερικά γραφήματα δεν ακολουθούν το "από έξω προς τα μέσα" ?

Ο ISP κόβει τα icmp εκτώς δικτύου, άρα δεν είναι δυνατή αλλιώς η μέτρηση.

Γιατί δεν υπάρχει node στον Χ ISP ?

Για να αποφεύγονται αστάθειες, τα nodes είναι όλα στημένα σε μισθωμένα κυκλώματα. Εάν κάποιος θέλει να στήσει node σε μισθωμένο κάποιου isp που λείπει, ευχαρίστως να τον προσθέσω.

Τι είναι τα Ethernet/SONET/SDH/κτλ ?

Σε κάθε κύκλωμα έχω βάλει τον τύπο interface που πιστεύω ότι έχει , ανάλογα με το reverse dns των άκρων του. Εικασία είναι, όχι δεδομένο. Τα SONET/SDH συνήθως είναι χωρητικότητας 620mbps/2.5gbps/10gbps.

Μπορώ να χρησιμοποιήσω τα γραφήματα για να παραπονεθώ σε κάποιον πάροχο/κάνω καταγγελία/κτλ ?

Όχι, δεν τα θεωρώ αρκετά ακριβή για κάτι τέτοιο.

Μπορώ να έχω τη λίστα με τους στόχους ?

Ναι, αν μου στείλεις π.μ. Δεν είναι δα και κάτι σημαντικό, αλλά δε θέλω να την κάνουν index search engines.


Ελπίζω να μη σας κούρασα πολύ, οποιαδήποτε σχόλια ευπρόσδεκτα

[treli@ris]

Ωραιος οδηγος. Μπραβο που τα εξηγησες για να καταλαβουμε κι εμεις που δεν ειμαστε του αντικειμενου

[karavagos]

Off Topic

Τα SONET/SDH συνήθως είναι χωρητικότητας 620mbps/2.5gbps/10gbps , αν και δε νομίζω να υπάρχει 10gbps SONET/SDH στη χώρα μας.

Υπάρχει (συνήθως προτιμάται σε σχέση με το Ethernet, γιατί το SDH παρέχει -εδώ σηκώνει πολύ συζήτηση- καλύτερους μηχανισμούς διάγνωσης σφαλμάτων).

[SfH]

Off Topic

Υπάρχει (συνήθως προτιμάται σε σχέση με το Ethernet, γιατί το SDH παρέχει -εδώ σηκώνει πολύ συζήτηση- καλύτερους μηχανισμούς διάγνωσης σφαλμάτων).

Off Topic

Μάλιστα. Ευχαριστώ για τις πληροφορίες, έκανα edit και τον οδηγό

Βέβαια, εγώ είχα ακούσει την άποψη που έλεγε ότι συνήθως προτιμάται το ethernet λόγω κόστους

[andreyas]

Πολύ κατατοπιστικό! Πάντα είχα απορίες πάνω σε αυτό το θέμα

[Georgevtr]

Πολύ καλή δουλειά.Σ ευχαριστώ.Ήδη λύθηκαν κάτι απορίες που είχα.

[AVoice]

Πραγματικά πολύ καλή δουλειά και εξήγηση.