View Full Version : Routing Team meeting 4/4/04 : RESULTS
papashark
08/04/2004, 02:11
ΟSPF
Cost reference bandwidth
OSPF Oνομαστική
COST Ταχύτητα link
---------------------------
1000 - 1 mbit
200 - 2
96 - 5.5/6
41 - 9/11/18/22
33 - 36
16 - 44
7 - 54
^ Half Duplex
-----------------------
v Full Duplex
3 - 108
10/100/wire
Lazer/Led
Περαιτέρω σχόλια θα κάνουν οι συμμετέχοντες, εγώ απλά φόρεσα φουστίτσα και ξανθιά περούκα και κράτησα σημειώσεις. :lol:
Και για το linux κάνετε την εξής αλλαγή στο ospfd.conf, εκεί που δηλώνετε τα interfaces σας (ας επιβεβαιώσει κάποιος ότι είναι σωστό!):
interface eth0
ip ospf cost xx
interface eth1
ip ospf cost yy
κλπ, κλπ...
Άντε να δούμε και μια άσπρη μέρα!
Το παραπάνω post του papashark έχει ενημερωτικό χαρακτήρα για τους AWMNίτες και δεν είναι επίσημο ακόμα, καθότι δοκιμάζουμε διάφορα σενάρια για να δούμε πως θα αντιδράσει με αυτές τις ρυθμίσεις.
Κατόπιν δικής μου παράκλησης τα δημοσίευσε, μιας και κράταγε σημειώσεις όταν κάναμε το meeting. (τον ανάγκασα να με πάει, διότι το δικό μου μεταφορικό, αποφάσισε ότι δεν ήθελε να κουνηθεί τη συγκεκριμένη ημέρα)
Επαναλαμβάνω λοιπόν: Τα παραπάνω δεν είναι η επίσημη θέση του routing team ακόμα. Τα δοκιμάζουμε και σύντομα θα υπάρχει ολοκληρωμένη ενημέρωση για τις ρυθμίσεις στους routers σας.
Μπραβο παιδια,ευχαριστουμε για την προσπαθεια.
μετα το Πασχα που θα ειμαστε παλι ολοι ενεργοι,και εσεις θα εχετε βγαλει μια επισημη προταση,προτεινω να ανοικτει ενα thread στο οποιο να γραφει καθε ενας που ακολουθησε την προταση αυτη (και καλο ειναι να την ακολουθησουν ολοι),και οτι παραξενο παρατηρησε απο την αλλαγη αυτην,ειτε καλο ειτε κακο.
ετσι θα μπορεσει το routing team να βγαλει συμπερασματα για την πρακτικη εφαρμογη αυτης της προτασης και να προβει ισως σε τοπικες αλλαγες οπου χρειαζεται.
jabarlee
08/04/2004, 15:12
χμμ....
καλή αρχή, αλλά 1-2 ερωτήσεις:
Η ονομαστική ταχύτητα του Link αν κατάλαβα καλά, είναι στην περίπτωση του 802.11.b τα 11 mbit. Παρ' όλα αυτά, η πραγματική ταχύτητα ενός link που είναι υποθετικά στα 11, είναι από 1,5-3,0 Mbit ανά κατεύθυνση.
Δεν θα ήταν καλύτερα λοιπόν να γίνει μια αναφορά σε σχέση με το μετρημένο throughput του link? Φαντόζομαι βέβαια ότι για να δουλέψει σωστά, θα πρέπει και από τις 2 πλευρές να δηλωθεί το ίδιο cost, άσχετα αν το Link δεν είναι αμφίδρομα καλό...
Γιατί έχουν το ίδιο cost: "41 - 9/11/18/22" links με τόσο μεγάλη διαφορά στην ταχύτητα;
Αυτά τα ρωτάω για να κάνω μια σωστή ρύθμιση του router μου, έστω και προσωρινά
Χωρίς να ήμουνα παρόν και κοιτάζοντας τα κόστη, βλέπω ότι έχει ληφθεί υπ όψιν η περίπτωση υπολειτουργίας ενός wireless link λόγο του ότι ακριβώς είναι wireless. Για παράδειγμα το 11mbit wireless έχει cost 41 ενώ το 10mbit ethernet έχει 3 ! :)
Οι διαφορές μεγέθους μειώνουνε την πιθανότητα να κάνει ο router λάθος εκτίμηση, ακόμα και αν οι πραγματικές ταχύτητες είναι πολύ μικρότερες των ονοματικών, για παράδειγμα:
.----- ethernet 10mbit ------ router ---- ethernet 10mbit -------.
/ \
node1 node2
\ /
'-------------------------wireless 11Mbit-------------------------'
Υποθέτουμε ότι η 'κάτω' διαδρομή στο σχήμα έχει πραγματική ταχύτητα 4Mbit. Η 'πάνω' διαδρομή θα έχει cost 7 ενώ η 'κάτω' θα έχει 41!
Εμένα πάντος μου κάνει εντύπωση γιατί δεν δόθηκάν πιο αναλυτικά, ότι βάζουμε στο ίδιο καζάνι τα links των 9 αλλά και των 22Mbit. Προφανώς κάποιος λόγος θα υπάρχει που δεν φαντάζομαι τώρα ...
Παιδιά καλησπέρα, έχω δύο μέρες που παρακολουθώ τα fora και φυσικά
δεν έχω έρθει στην εν λόγο συνάντηση αλλά θα ήθελα να σας παραθέσω τις σκέψεις μου.
Χαζή ερώτηση!
Υπάρχει τρόπος να γνωρίζει το OSPF την ταχύτητα που είναι ενεργή σε κάποιο από τα links που έχει επάνω του? Φυσικά αυτό πάντα στην περίπτωση που είναι *nix με κάρτες PCI κτλ.
Κατά την γνώμη μου είναι πολύ δύσκολο να το γνωρίζει ειδικά στις περιπτώσεις που μιλάμε για !*nix πλατφόρμα η/και external AP/Bridges (μακάρι να το γνώριζε!!) οπότε στις περιπτώσεις που υπάρχουν links με μεγάλη αστάθεια τότε τι cost θα μπει εκεί? Το μεγαλύτερο?
(Βέβαια θα μπορούσα να σκεφτώ έναν τρόπο να είναι δυναμικό το κόστος αλλά θέλει δοκιμές.)
Κάτι τελευταίο, έχετε κάπου τα minutes της συνάντησης?
Racer σου άφησα ένα μήνυμα δεν ξέρω αν το πήρες.
-Γιάννης
Η ονομαστική ταχύτητα του Link αν κατάλαβα καλά, είναι στην περίπτωση του 802.11.b τα 11 mbit. Παρ' όλα αυτά, η πραγματική ταχύτητα ενός link που είναι υποθετικά στα 11, είναι από 1,5-3,0 Mbit ανά κατεύθυνση.
Δεν θα ήταν καλύτερα λοιπόν να γίνει μια αναφορά σε σχέση με το μετρημένο throughput του link? Φαντόζομαι βέβαια ότι για να δουλέψει σωστά, θα πρέπει και από τις 2 πλευρές να δηλωθεί το ίδιο cost, άσχετα αν το Link δεν είναι αμφίδρομα καλό...
Σωστό, αλλά πρέπει να λάβουμε υπόψην μας και άλλα γεγονότα.
1ον: Υπάρχουν τόσες πολλές διαφορετικές ταχύτητες όσον αφορά το πραγματικό bandwidth, που δε θα γινόταν ποτέ να κατασταλάξουμε σε κάποιους αριθμούς.
2ον: Σκοπός είναι να βάλουμε κάποιο configuration το οποίο θα μπορούμε να κάνουμε εύκολα troubleshooting και δε θα πάθουμε τενοντίτιδα μέχρι να το πληκτρολογήσουμε στο μηχάνημα
3ον: Αν η ταχύτητα (πραγματική) παίζει συνέχεια, ποια θα είναι η σωστή τιμή για να βάλουμε; Αναγκαστικά χρειαζόμαστε ένα σημείο αναφοράς. Και δεν υπάρχει καλύτερο από την ονομαστική ταχύτητα, την οποία φυσικά λαμβάνουμε υπόψην μας σε σχέση με την ποιότητα (γι αυτό και οι διαφορές σε σχέση με το "b", "g" και ethernet.
Εμένα πάντος μου κάνει εντύπωση γιατί δεν δόθηκάν πιο αναλυτικά, ότι βάζουμε στο ίδιο καζάνι τα links των 9 αλλά και των 22Mbit. Προφανώς κάποιος λόγος θα υπάρχει που δεν φαντάζομαι τώρα ...
Ο λόγος είναι διότι οι παραπάνω ταχύτητες είναι ονομαστικές για το "g" και είναι γνωστό ότι το "g" δεν έχει τις ίδιες αναλογίες ονομαστικού/πραγματικού bandwidth όπως το "b". Επί του παρόντος δεν υπάρχουν "a" link, καθότι δεν είναι ελεύθερη ακόμα η μπάντα και είναι παράνομα. Πρέπει όμως ταυτόχρονα, να καλύψουμε τις τωρινές άμεσες ανάγκες μας και όσο πιο απλά μπορούμε. Γι αυτό και στηριχτήκαμε στην εμπειρία των μελών του forum που την έχουν αποτυπώσει σε διάφορα posts εδώ.
Άλλωστε, μη ξεχνάμε ότι προσπαθούμε ξεφεύγοντας από τα επίσημα drafts, να κάνουμε ένα dynamic routing protocol που δεν προβλέπει σκαμπανεβάσματα στην ταχύτητα των συνδέσεων (aka: flapping) και δεν πραγματοποιεί μετρήσεις bandwidth, να το κάνουμε να συμπεριφερθεί σαν να το έκανε.
Γι αυτό και είπα ότι δεν είναι επίσημο και το δοκιμάζουμε σε lab περιβάλλον.
Άρα, παρακαλείστε όλοι να μην πραγματοποιήσετε καμία αλλαγή πριν σας ενημερώσουμε επίσημα για τις τελικές ρυθμίσεις.
Υπάρχει τρόπος να γνωρίζει το OSPF την ταχύτητα που είναι ενεργή σε κάποιο από τα links που έχει επάνω του? Φυσικά αυτό πάντα στην περίπτωση που είναι *nix με κάρτες PCI κτλ.
Όχι, αν και το ανακάλυψα αργά, το OSPF δεν μετράει ταχύτητα (και δεν είναι θέμα πλατφόρμας που τρέχει, είναι θέμα design
Κατά την γνώμη μου είναι πολύ δύσκολο να το γνωρίζει ειδικά στις περιπτώσεις που μιλάμε για !*nix πλατφόρμα η/και external AP/Bridges (μακάρι να το γνώριζε!!) οπότε στις περιπτώσεις που υπάρχουν links με μεγάλη αστάθεια τότε τι cost θα μπει εκεί? Το μεγαλύτερο?
Αν το link δεν είναι σταθερό, καλύτερα να μη γίνει. Ή αν είναι να γίνει, θα πρέπει να έχει μεγάλο κόστος (ας πούμε του 1 mbit) για να είναι και η τελευταία "λύση ανάγκης" για δρομολόγηση πακέτων από αυτή τη διαδρομή
Κάτι τελευταίο, έχετε κάπου τα minutes της συνάντησης?
Δυστυχώς επειδή η γραμματέας μας είχε άδεια (φυσικά κάνω πλάκα) δεν κρατήσαμε minutes. Άλλωστε σε ένα καθαρά τεχνικό meeting, δεν υπάρχουν minutes, υπάρχει πίνακας, ιδέες και σκέψεις που ζωγραφίζονται και σημειώσεις που αφορούν τα προς αξιολόγηση θέματα που προκύπτουν.
Ελπίζω να σας κάλυψα όλους
papashark
09/04/2004, 00:08
Eγώ έχω κρατήσει και σημειώσεις και από άλλα πράγματα που είχατε σημειώσει στον πίνακα, καθώς και τις κρεμάλες που παίζατε, αλλά δεν θα τα δημοσιεύσω μην κάνω πάλι κοτσάνα, αντ' αυτού θα τα στείλω στους συμμετέσχοντες να δουν τι από όλα χρειάζετε να δημοσιεύσουν.
VTB κράτησα και το τηλέφωνο της φοιτήτριας που πέρασε, να το δημοσιεύσω και αυτό ? :P
Όχι, αν και το ανακάλυψα αργά, το OSPF δεν μετράει ταχύτητα (και δεν είναι θέμα πλατφόρμας που τρέχει, είναι θέμα design
Όχι δεν εννοούσα φυσικά το OSPF σαν routing protocol αλλά σαν *nix Box.
Η ιδέα είναι με κάποιο tool να μπορεί το "κουτί" να ανακαλύπτει την ονομαστική τουλάχιστον ταχύτητα και να ρυθμίζει μόνο του το configuration file του Gated/Zebra ?? (με ποιό παίζετε ? ).
Φυσικά πάντα υπάρχουν τo αυξημένο ενδεχόμενο για routing flaps αλλά αυτό είναι θέμα δοκιμών.
Έχετε σκευτεί καθόλου για Areas ? Θα γίνει κάποιο groupάρισμα, γεωγραφικό ίσως, ή κάτι άλλο?
-Γιάννης
Δυστυχώς, η τοπολογία του δικτύου μας είναι meshed-mesh (που σημαίνει καρα-mesh του κ*ρ@τ@) και μάλιστα σε καμία περίπτωση δεν είναι στατική.
Το "Σήμερα το link υπάρχει - αύριο δεν υπάρχει και υπάρχει κάπου αλλού" σενάριο, καθώς και η μη δομημένη διασύνδεση μεταξύ μας (που δε θα μπορούσε να υπάρχει ούτως ή άλλως λόγω της άναρχα πολεοδομημένης - ή μάλλον πολεο-αδόμητης Αθήνας) δεν υπάρχει δυνατότητα διαχωρισμού σε ζώνες.
Η μόνη πιθανότητα που δε βλέπω εφικτή (τουλάχιστον με την υπάρχουσα κατάσταση) θα ήταν η δημιουργία ενός backbone-ring που θα έκανε τον κύκλο της αθήνας, με δυνατότητα πρόσβασης σε αυτό μόνο BB κόμβων, οι οποίοι με τη σειρά τους θα μετέφεραν το routing info. Έτσι, ο σχηματισμός areas (έστω και 3-4) θα ήταν εφικτός, κάνοντας πιο απλή και λιγότερο "φλύαρη" τη δουλειά του OSPF.
Από την άλλη, η δημιουργία virtual συνδέσεων δεν είναι προτινόμενη και μάλιστα υπάρχουν FYI που προτιμούν αλλαγή dynamic routing protocol, παρά τη χρήση αυτής της λύσης έστω και ως τελευταίας. Και είναι ευκολονόητο γιατί...
Μπραβο ρε παιδια!
Τετοια "φυλλαδια" να βγουνε για εσωτερικη χρηση και ενημερωση...ετσι απλα οπως τα λετε και σε μορφη ερωτησεων - απαντησεων...αρχιζω και εγω ο βλακας και καταλαβαινω σιγα σιγα....
Υπάρχει τρόπος να γνωρίζει το OSPF την ταχύτητα που είναι ενεργή σε κάποιο από τα links που έχει επάνω του? Φυσικά αυτό πάντα στην περίπτωση που είναι *nix με κάρτες PCI κτλ.
Υπάρχει, χρησιμοποιώντας κάποιο είδος 'agent. Δεν είναι νέα ιδέα, η BT το χρησιμοποιεί εδώ και καιρό και υπάρχουνε διάφορα papers και πρωτόκολλα επί του θέματος, όπως π.χ. το AntNet.
Η λογική είναι στην χρίση agents για την συνεχή μέτρηση της κατάστασης του δίκτυο και κατά συνέπεια και των links. Κλεμμένη φυσικά από τα αγαπητά μας μυρμηγκάκια και τις φερομόνες τους :)
Κάνω attach το paper του AntNet 1.1 (2001) για όποιον έχει όρεξη για διάβασμα και αναφέρω και τα βασικά του references (δεν τα έχω για να τα κάνω attach, εάν τα έχει κάποιος please share the knowledge:))
Dorigo M., Maniezzo V. & Colorni A., "The Ant System: Optimization by a colony of cooperating agents," IEEE Trans. Systems, Man, and Cybernetics- Vol. 26, N 1, pp. l--13, 1996.
Dorigo M. & Gambardella L., "Ant Colony System: A Cooperative Learning Approach to the Traveling Salesman Problem," IEEE Trans. on Evol. Computation, Vol. 1, N 1, pp. 53--66, 1997.
Dorigo M. & Di Caro G., "AntNet: A Mobile Agents Approach to Adaptive Routing," Tech. Report, IRIDIA- Free Brussels University, Belgium, 1997. <u>http://iridia.ulb.ac.be/dorigo/ACO</u>.
Dorigo M. & Di Caro G., "Ant Colonies for Adaptive Routing in Packet-switched Comm. Networks," Technical Report, IRIDIA-Free Brussels University, Belgium, 1998.
Η μόνη πιθανότητα που δε βλέπω εφικτή (τουλάχιστον με την υπάρχουσα κατάσταση) θα ήταν η δημιουργία ενός backbone-ring που θα έκανε τον κύκλο της αθήνας, με δυνατότητα πρόσβασης σε αυτό μόνο BB κόμβων, οι οποίοι με τη σειρά τους θα μετέφεραν το routing info. Έτσι, ο σχηματισμός areas (έστω και 3-4) θα ήταν εφικτός, κάνοντας πιο απλή και λιγότερο "φλύαρη" τη δουλειά του OSPF.
Είναι μια πολύ καλή ιδέα, ίσως αυτό που λες συνδιασμένο με κόμβους A/B/C. Εννοώ ότι εφόσον ένας κόμβος έχει multiple links τότε θα μπορούσε να είναι BB Router για άλλο area και ενδεχομένος να πρέπει να έχει μεγαλύτερο preference η μικρότερο κόστος κτλ. ανάλογα πάντα και με την τοπολογία και άν έχει και νόημα.
Πάντος η παρουσία ενός routing protocol θεωρώ ότι είναι απαραίτητη και σε περίπτωση που τα flaps είναι πολλά τότε θα μπορούσε να βοηθήσει πολύ το BGP λόγο πολύ καλής διαχείρησης με penalties στο dampening των routes. Αυτό φυσικά σε μεγάλους κόμβους και πάντα άν έχει νόημα η ύπαρξή του. Το κακό είναι ότι το BGP είναι πολύ αργό για interior οπότε αναγκαστικά πρέπει να ηπάρχει κάποια δομή όπως αυτό που είπες αλλά φαντάσου το με πολλά rings και όχι μόνο ένα, οπότε να υπάρχουν κάποια alternate paths από πλευράς routing.
-Γιάννης
@ysam: χώρις να το καταλάβεις ξύνεις μεγάλες πληγές του AWMN μιάς και η μάχη OSPF/BGP κρατεί εδώ και καιρό...
@ysam: χώρις να το καταλάβεις ξύνεις μεγάλες πληγές του AWMN μιάς και η μάχη OSPF/BGP κρατεί εδώ και καιρό...
Ουπς, sorry δεν το είχα ξέρει ¨) :shock: αλλά δεν θα μπορούσα να φανταστώ να παίζει μόνο του το BGP! (Πολύ αργό)
-Γιάννης
Mick Flemm
10/04/2004, 15:36
Παίδες όταν καταλήξετε κάπου (ενοώ σε συγκεκρημένες τιμές cost κλπ) πείτε το για να μπει και στο node configurator και στον οδηγό κλπ...
Υ.Γ. Ακόμα θυμάμαι το ΜΕΓΑΛΟ φυλάδιο που είχε φέρει τότε ο DiGi, μήπως πρέπει να του ρίξετε μιά ματιά ? just in case :wink:
Υ.Γ. Ακόμα θυμάμαι το ΜΕΓΑΛΟ φυλάδιο που είχε φέρει τότε ο DiGi, μήπως πρέπει να του ρίξετε μιά ματιά ? just in case :wink:
Μπορώ να το βρω κάπου να του ρίξω μια ματιά?
Χρόνια Πολλά σε όλους.
-Γιάννης
ΟSPF
Cost reference bandwidth
OSPF Oνομαστική
COST Ταχύτητα link
---------------------------
1000 - 1 mbit
200 - 2
96 - 5.5/6
41 - 9/11/18/22
33 - 36
16 - 44
7 - 54
^ Half Duplex
-----------------------
v Full Duplex
3 - 108
10/100/wire
Lazer/Led
Περαιτέρω σχόλια θα κάνουν οι συμμετέχοντες, εγώ απλά φόρεσα φουστίτσα και ξανθιά περούκα και κράτησα σημειώσεις. :lol:
η ιστορια επαναλαμβανεται και...
εφτιαξα ενα πινακακι με τα κοστη που μαλλον μας ενδιαφερουν πλεον.
επειδη δεν ειμαι και ο πιο καταληλος για αυτη τη δουλεια διορθωστε με.
Cost Half Duplex Throughput
----------------------------------
41 9-18 4-9
33 36 18
16 48 22
7 54 27
Cost Full Duplex Throughput
----------------------------------
28 10 20
3 100 200
AWMN 2010
Powered by vBulletin™ Version 4.1.4 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.