View Full Version : BGP προβληματισμοί
Μετά την ενεργοποίηση του link του ysam2 με τον achille, η κίνηση που φαίνεται να περνάει από το interface μου με τον ysam2 είναι περίπου η ίδια όπως και παλιά στο απευθείας link που είχα με τον achille, MONO όταν δεν λειτουργεί το άλλο link μου με τον nvak.
Σε όλες σχεδόν τις άλλες περιπτώσεις το link μου με τον nvak έχει 3πλάσια τουλάχιστον κίνηση.
Αυτό σημαίνει οτι η κίνηση των Βριλισίων, Αγ. Παρασκευής και αρκετή κίνηση από τον bliz κλπ. βρίσκει καλύτερη διέξοδο μέσω nvak παρά μέσω xtreme-->achille ή bliz-->achille
Δυστυχώς είναι κάτω ο HdKiLLeR κάμποσες μέρες, οπότε δεν υπάρχει διέξοδος για τα Βριλίσια μέσω ablaz3r-->HdKiLLeR-->dti.
Το ενδιαφέρον πάντως είναι οτι με το που κολλάει η quagga σε μένα ή στον nvak, το ysam2 αναλαμβάνει να μεταφέρει όλη την κίνηση, όπως φαίνεται και στη συνημμένη εικόνα.
Τελικά το link με τον nvak αποδείχθηκε πολύ καλό σαν κίνηση, αφού πέρα από την ανέλπιστα καλή συμπεριφορά του (απόσταση 6,2 χλμ. με νόμιμη ισχύ) προσφέρει redudancy στο δίκτυο.
lambrosk
27/05/2004, 01:17
XExe τι λειτουργικό έχεις στήσει Γιάννη ysam? και με τι OSPF software? 8)
Λάμπρο δεν ξέρω, θα σε προλάβω αν σου πω ότι έτσι είναι το routing αυτην την στιγμή?
Δεν είναι θέμα software αλλά που δρομολογούνται τα πακέτα όταν ένα λινκ δεν παίζει. Εδώ πρέπει να παίξουμε με route-maps και costs για να κάνουμε load balance ta links του Δαμιανού Η να δημιουργηθούν εναλλακτικές διαδρομές (φυσικές, όχι virtual) προς κάποια άλλα κομβικά σημεία.
Είμαι δε σε αυτό το σημείο, 100% σίγουρος ότι αν το routing protocol ήταν BGP τότε θα μπορούσαμε να κάνουμε αρκετά περισσότερα πράγματα με την υπάρχουσα φυσική δομή του δικτύου.
Πάντος γνωρίζοντας ότι ανοίγω μεγάλο θέμα, κοιτάζοντας την nodeDB και το routing table μπορεί κανεις να δει ποιά είναι κάποια μεγάλα κομβικά σημεία και η ομάδα δρομολόγισης θα μπορούσε να κάνει μια μελέτη για network summarizations και δημιουργία areas η και ακόμα με την βοήθεια του bgp να παίζουν ibgp αυτοί οι κόμβοι μεταξύ τους και ospf οι μικρότεροι.
Το full-καραfull-mesh δεν υπάρχει αν κοπούν/υπολειτουργούν 3 Links από μεγάλα κομβικά σημεία και κάποιοι κλένε!! :)
Off-topic το ξέρω αλλά με έχει προβληματίσει πολύ η τοπολογία. :)
Για να σου λύσω και την απορία, ο κόμβος ysam2 παίζει με Fedora Core 2 και Quagga CVS (Τελευταία development version κατά την στιγμή που το κατέβασα πάντα).
Επίσης είμαι σίγουρος ότι με την σωστή αξιοποίηση του λινκ LimaH - Bliz θα φίγει πολύ traffic προς τα εκεί.
Φιλικά,
-Γιάννης
Πάντως το παρατήρησα και έγώ. Με ότι cost και να παίξεις δεν μοιράζει το trafic προς bliz, απλά διαλέγει τον ένα η τον άλλο δρόμο οπότε ένα ή δέκα δρόμους να έχεις μόνο τον ένα αξιοποιείς. Κάτι πρέπει να γίνει μ' αυτό ειδικά τώρα που αρχίζουν να πυκνώνουν οι εναλλακτικές διαδρομές.
paravoid
27/05/2004, 09:06
Πάντως το παρατήρησα και έγώ. Με ότι cost και να παίξεις δεν μοιράζει το trafic προς bliz, απλά διαλέγει τον ένα η τον άλλο δρόμο οπότε ένα ή δέκα δρόμους να έχεις μόνο τον ένα αξιοποιείς. Κάτι πρέπει να γίνει μ' αυτό ειδικά τώρα που αρχίζουν να πυκνώνουν οι εναλλακτικές διαδρομές.
O MAuVE και ο spirosco είχαν δοκιμάσει Equal Cost MultiPath και ασύμμετρο routing. Δυστυχώς δεν έπαιξε καλά... Όταν γίνεται load-balancing, ένας από τους 2 δρόμους να χαλάσει (δεν εννοώ να πέσει, εννοώ να πάει στα 500Kbps ή/και να χάνει πακέτα) χαλάει και ο άλλος. Και το wireless είναι φοβερά ασταθές.
Γιάννη (ysam) το (i)BGP έχει προταθεί από πολλούς και πολλές φορές. Οι λόγοι που δεν έχει εφαρμοστεί είναι ότι θα είναι (φαντάζομαι - δεν ξέρω) πιο δύσκολο στο setup, και υπάρχουν πάρα πολλοί routers στο AWMN... Επίσης δεν υπάρχουν αρκετοί που να το ξέρουν, οπότε είναι δύσκολη μια σχεδίαση από λίγα άτομα. Πάντως, μπορείς να βάλεις και εσύ το λιθαράκι σου (εύχομαι να αντέχει πολλά λιθαράκια η πλάτη σου) και να εφαρμοστεί :P
Αν γίνει μία συζήτηση - εκπαίδευση και γραφεί και ένα tutorial για το (i)ΒGP, μπορούν μερικοι εκπαιδευμένοι διαχειριστές να αναλάβουν την υποστήριξη του routing σε 3-4 γειτονικούς τους κόμβους.
Παιδιά εννοείτε ότι πρέπει να ενεργοποιηθεί και στον kernel το equal cost multipath.
Πάντος λόγο μεγάλης εμπειρίας σε BGP θα σας έλεγα να κάνουμε μια προσπάθεια και είναι πολύ πιο εύκολο το setup.
Από την άλλη το να έχουμε 100 linux boxes με ospf router και ενα network 10.0.0.0/8 area 0 δεν λέει τίποτα. Κάνει την δουλειά του και σωστα αποφασίζει οταν εάν λινκ δεν παίζει να δρομολογίσει τα πακέτα σε κάποιο άλλο αλλά είναι σαφός πολύ πιο δύσκολο να το επιρρεάσεις. Ειδικά στην περίπτωσή μας. Αναρωτιέμαι άν έχει βάλει κανείς κάποιο route map στο config του.
Σε κάθε περίπτωση μπορούμε να αρχίσουμε κάποιο pilot με 2-3 κόμβους και να δούμε πως πάει. Αναλλόγος μετά συνεχίζουμε.΄
Όλα αυτά όμως μετά από κάποια μελέτη και σχεδιασμό βλέποντας την nodedb και κάποιο nagios όπως αυτό του spirosco που όμως θέλει ενημέρωση.
Επίσης προτείνω να αναλάβει η routing ομαδα να φτιάχνει (configure) το routing στα linux boxes συνολικά στους μεγάλους και συμαντικούς κόμβους η τουλάχιστον να υπάρχει πρόσβαση από την ομάδα μέχρι να μάθουν οι κάτοχοι να παίζουν με αυτό μόνοι τους.
Πάντος μπορώ να βοηθήσω γενικός.
-Γιάννης
PS. Τελικά δεν είμαστε off-topic?
lambrosk
27/05/2004, 12:29
Έχω έτοιμο ένα quick-tutorial για internal - external routing protocols.
Είμαι δε σε αυτό το σημείο, 100% σίγουρος ότι αν το routing protocol ήταν BGP τότε θα μπορούσαμε να κάνουμε αρκετά περισσότερα πράγματα με την υπάρχουσα φυσική δομή του δικτύου.
Πιστεύω μια απο τα ίδια...
:lol: Έχεις τα cd για fedore core 2? να περάσω να τα πάρω να το βάλω το βραδάκι?
Τα έχει ο Σωκράτης και θα τα έκανε copy.
Μπορείς να τα πάρεις από αυτόν.
Το scan θα το κάνεις? ;)
-Γιάννης
paravoid
27/05/2004, 12:49
Παιδιά εννοείτε ότι πρέπει να ενεργοποιηθεί και στον kernel το equal cost multipath.
Και στον πυρήνα είχε ενεργοποιηθεί και στην Quagga και ΔΟΥΛΕΥΕ. Το πρόβλημα ήταν ότι αν ενα εκ των δύο links υπολειτουργούσε, αναγκαστικά υπολειτουργούσε και ο άλλος δρόμος.
Καλύτερα όμως να μιλήσουν οι ίδιοι...
Billgout
27/05/2004, 13:07
Δεν είμαι και ο guru του routing, πάντως από ένα πρόχειρο διάβασμα που έκανα, μάλλον το BGP(4), κάνει για τη δουλεία μας ...... αν θέλετε εθελοντές - κόμβους προσφέρομαι μόλις ανεβάσω και το 2ο ΒΒ link... (πολύ σύντομα)
Πάντως νομίζω ότι αξίζει να το δοκιμάσουμε έστω τοπικά*....... 8) και μετά αν δουμε ότι δουλεύει, βουρ στον πατσά για tutorials και configuration files...
Spirosco τι λές; :?: :)
* Διευκρίνηση για να μην ξαναpostaρω...... σε τοπικο επίπεδο π.χ 3-4 κόμβοι στη Δ. Αθήνα
lambrosk
27/05/2004, 13:27
Τα έχει ο Σωκράτης και θα τα έκανε copy.
Μπορείς να τα πάρεις από αυτόν.
Το scan θα το κάνεις? ;)
-Γιάννης
Μόλις το στήσω...σήμερα ευελπιστώ δηλαδή μετά τις 9 να είμαι σπίτι...
EDIT: (...δεν έχω λαπτοπ για να το κάνω και θα πρέπει να χρησιμοποιήσω κάποιο ταρατσοpc....)
Δεν μπορεί να γίνει τοπικά έτσι απλά, πρέπει να συνδεθούν με BGP 3-4 κόμβοι για να δουλέψει και μάλιστα θέλει και redistribution από OSPF.
-Γιάννης
Tracing route to jabarlee.jabarlee.awmn [10.37.57.250]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms bakolinux.bakolaz.awmn [10.37.58.249]
2 10 ms 6 ms 4 ms gw-bakolaz.dermanis.awmn [10.37.58.68]
3 9 ms 20 ms 16 ms gw-dermanis.dti.awmn [10.37.56.81]
4 40 ms 15 ms 27 ms gw-dti.ysam.awmn [10.37.56.66]
5 26 ms 30 ms 28 ms gw-ysam2.achille.awmn [10.47.130.113]
6 39 ms 57 ms 59 ms gw-achille.drinet.awmn [10.47.130.82]
7 25 ms 47 ms 31 ms bbr.drinet.awmn [10.2.13.132]
8 72 ms 66 ms 47 ms gw-drinet.winner.awmn [10.2.13.141]
9 51 ms 46 ms 88 ms gw-winner.john70.awmn [10.2.12.85]
10 77 ms 74 ms 196 ms gw-john70.ee.awmn [10.2.15.165]
11 93 ms 198 ms 173 ms gw-ee.stelios.awmn [10.80.185.101]
12 105 ms 91 ms 92 ms 10.80.182.50
13 131 ms 193 ms 91 ms 10.80.182.200
14 * * * Request timed out.
15 * * * Request timed out.
16 35 ms 36 ms 52 ms gw-dermanis.jabarlee.awmn [10.37.57.65]
17 * * 219 ms jabarlee.jabarlee.awmn [10.37.57.250]
Trace complete.
O jabarlee είναι 2 hops από εμένα. Μάλλον συμβαίνει επειδή κάτι έχει κολλήσει στον κόμβο dermanis. Εκτός αν συμβαίνει κάτι άλλο....
Δεν μπορεί να γίνει τοπικά έτσι απλά, πρέπει να συνδεθούν με BGP 3-4 κόμβοι για να δουλέψει και μάλιστα θέλει και redistribution από OSPF.
-Γιάννης
Τί απαιτήσεις έχει από θέμα hardware του linux box;
Τί απαιτήσεις έχει από θέμα hardware του linux box;
Τίποτα, όπως δουλεύουν όλα σήμερα απλά θα ενεργοποιήσουμε και BGPD.
Αν θέλουμε και multipath τότε απλά θα compilaρουμε τον πυρήνα.
-Γιάννης
paravoid
27/05/2004, 14:00
O 2.4.25-awmn έχει ενεργοποιημένο equal cost multipath.
Billgout
27/05/2004, 14:30
.....Τίποτα, όπως δουλεύουν όλα σήμερα απλά θα ενεργοποιήσουμε και BGPD...........
Δεν φτιάχνουμε και ένα sample από conf αρχείο κτλ? γιατι θέλει και άλλα στοιχεία πέραν των γνωστών απ' ότι ειδα (AS etc.)
ΥΓ.Σφυρίξτε ότι χρειαστείτε..... απλά θα λείπω από 30/5 - 2/6 εξωτερικό
...........αν και νομίζω ότι οι δοκιμές μπορούν να γίνουν σχετικά άμεσα.
Πάντος το προβλημά μας δεν είναι το multipath και γενικός το equal cost load balancing αλλά το balancing γενικός στις διάφορες γραμμές.
Πολύ δύσκολα θα βρει κανείς ίδια διαδρομή σε αριθμό links. Ομώς θα θέλανε πολλοί να στέλνουν traffic από διαφορετικούς δρόμους για να balancαρουν την κατάσταση ακόμα και αν δεν είναι τελικά ο πιο κοντινός δρόμος αλλά λόγο B/W η αστάθειας τελικά είναι καλήτερα.
Αυτό πιστεύω είναι και το σωστό concept γιατί είτε έχουμε ασταθή BB llinks είτε τα BB Links δεν είναι μεγαλύτερα από τα client links. Αρα αναγκαζόμαστε να μοιράζουμε από το ένα και από το άλλο (οι κόμβοι με περισσότερα από 2) για να κάνουμε offload την κατάσταση.
Αλήθεια με εκείνο το 5Ghz τι θα γίνει? :)
-Γιάννης
Πάντως το παρατήρησα και έγώ. Με ότι cost και να παίξεις δεν μοιράζει το trafic προς bliz, απλά διαλέγει τον ένα η τον άλλο δρόμο οπότε ένα ή δέκα δρόμους να έχεις μόνο τον ένα αξιοποιείς. Κάτι πρέπει να γίνει μ' αυτό ειδικά τώρα που αρχίζουν να πυκνώνουν οι εναλλακτικές διαδρομές.
Ναι, δεν μας φτάνει το flickering από τη μοναδική διαδρομή που δεν μπορούμε να εξασφαλίσουμε, θέλουμε να χρησιμοποιήσουμε και πολλές ταυτόχρονα.
Δεν είναι στο bandwidth το πρόβλημά μας, στη σταθερότητα είναι.
Αυτά που ζητάτε γίνονται δύσκολα σε καλωδιακά δίκτυα. Σε ασύρματα δίκτυα είναι απλά υπερβολή.
spirosco
27/05/2004, 16:22
Οπως εγραψε κι ο Φαιδωνας, το load balancing οντως δουλεψε, αλλα απαιτει ΤΕΛΕΙΑ LINKS.
Τελεια links στο 802.11b δεν υπαρχουν.
Στο load balancing η μιση δουλεια γινεται απο το routing software το οποιο ανακοινωνει στον πυρηνα τις οποιες διαθεσιμες εναλλακτικες διαδρομες και η αλλη μιση απο τον ιδιο τον πυρηνα ο οποιος αποφασιζει ποια διαδρομη θα χρησιμοποιησει καθε φορα. Ο πυρηνας λοιπον εναλλασει τις διαδρομες για καθε νεα συνδεση που προερχεται απο την ιδια IP.
Με τον MAuVE το δοκιμασαμε σε ασυμμετρες διαδρομες ρυθμιζοντας καταλληλα το cost στους εμπλεκομενους routers. Οταν ξεκιναγαμε λοιπον ενα δοκιμαστικα downloads, παρακαλοθουσαμε τα πακετα να μοιραζονται αναμμεσα στις δυο διαδρομες για να φτασουν στον παραληπτη. Μεχρι εκει ολα καλα. Απο εκει και περα ομως, ριχνοντας εσκεμενα την ισχυ ενος link για να επηρεασουμε την ποιοτητα της μιας εκ των δυο διαδρομων, ειχαμε μεγαλη απωλεια σε throughput, ως και διακοπη του download (κυριως λογω packet loss).
Αν το OSPF βεβαια μπορουσε να αντιληφθει την κατασταση μιας διαδρομης ισως να ηταν διαφορετικο το αποτελεσμα, αλλα και η γιαγια μου αν ειχε πατινια αντι για ποδια ισως και να ηταν τρολλευ...
H ταπεινη μου αποψη ειναι οτι μεθοδοι και πρωτοκολλα που σχεδιαστηκαν για να αποδωσουν πανω σε σταθερες διαδρομες (π.χ. ενσυρματες) δεν μπορουν ν'αποδωσουν τα μεγιστα στις δικες μας συνθηκες. Δεν εχω αποψη για το BGP αλλα τουλαχιστον οσο παιζουμε με το OSPF δεν θα πρεπει να εχουμε την ψευδαισθηση οτι βγαζοντας ετσι απλα μια εναλλακτικη διαδρομη, το super-duper routing protocol που χρησιμοποιουμε θα μας λυσει ολα τα προβληματα. Οπως εχει αποδειχθει μπορει να μας κανει ακομη πιο δυσκολη τη ζωη.
Επίσης προτείνω να αναλάβει η routing ομαδα να φτιάχνει (configure) το routing στα linux boxes συνολικά στους μεγάλους και συμαντικούς κόμβους η τουλάχιστον να υπάρχει πρόσβαση από την ομάδα μέχρι να μάθουν οι κάτοχοι να παίζουν με αυτό μόνοι τους.
Όπως καταλαβαίνεις, τα προβλήματα τα δημιουργούν αυτοί που νομίζουν ότι ξέρουν, και πειράζουν πράγματα που δεν πρέπει.
Αν όλοι είχαν το default configuration χωρίς να το σκαλίζουν με static routes, αλλαγές στα costs, ασύμμετρα costs, multipaths και τέτοια, το δίκτυο θα δούλευε πολύ καλύτερα.
Είναι προτιμότερο να έχεις ένα αυτοματοποιημένο σύστημα που καμιά φορά κάνει λάθη, παρά ένα σύστημα ρυθμισμένο από δεκάδες ανθρώπους, που σίγουρα έχουν κάνει πολλά λάθη.
Μακάρι να μπορούσε να αναλάβει μια ομάδα ειδικών να ρυθμίζει το routing σε όλους τους κόμβους υποχρεωτικά, και οι κάτοχοί τους να μην βάζανε το χεράκι τους καθόλου.
Με την πληθώρα των λειτουργικών και διανομών που επικρατεί όμως, και με την όρεξη όλων να παίξουν και να μάθουν πάνω στο backbone, δεν νομίζω ότι πρόκειτε να γίνει ποτέ αυτό που λες.
Και για να μην νομίζετε ότι μηδενίζω τη συζήτηση, να σας πω εγώ με τι πιστεύω ότι πρέπει να ασχοληθούμε:
Με routing protocols που λειτουργούν απολύτως αυτοματοποιημένα. Που εκτελούν μετρήσεις πάνω στην ποιότητα της γραμμής. Που μπορούν να αντέξουν μεγάλες μεταπτώσεις στην ποιότητα της γραμμής χωρίς να καταρρέουν.
Μιλάω για ένα mesh τύπου δίκτυο, με κατευθυντικές όμως ζεύξεις, δηλαδή αυτόματη έυρεση διαδρομών με σταθερούς όμως γείτονες.
Κάτι τέτοιο δεν υπάρχει, και πρέπει να το δημιουργήσουμε μόνοι μας, παντρεύοντας δυο ειδών προτόκολλα
Αυτός είναι ο σωστός δρόμος για την έρευνά μας. Προϋποθέτει όμως ότι θα απαλλαγούμε από Hardware και Windows routers, και θα ήταν απείρως πιο εύκολο να έχουμε συμφωνήσει σε ένα unix-type λειτουργικό, και ακόμα καλύτερο σε ένα distribution του.
Αν προσπαθήσουμε να εφαρμόσουμε προηγμένες τεχνικές ενσυρμάτων δικτύων, απλά θα αποτύχουμε, γιατί τα links μας σε φυσικό επίπεδο θα χειροτερεύουν μάλλον με το χρόνο, παρά θα καλυτερεύουν.
Το να αναλάβει μια ομάδα να ρυθμίζει μόνο το routing με κάποιους κανόνες είναι η καλλίτερη λύση. Ας έχει ο κάθε ένας 4 - 5 κόμβους στην ευθύνη του, και την ευθύνη της ενημέρωσης του nagios.
Οποιος θέλει να παίξει μόνον κάτω απο επίβλεψη και εκπαίδευση.
Στο σύστημα θα εντάσσεται όποιος κόμβος έχει πάνω απο 1 link με το awmn. Δεν πιστεύω ότι πετύχαμε το τέλειο. Χρειάζεται να γίνουν δοκιμές απο όσους ξέρουν ( δεν ανήκω σ' αυτούς). Όταν υπάρχει πρόβλημα δεν γίνεται να μην προσπαθήσεις να βρείς μία λύση. Να βάλουμε και πανεπιστημιακούς μέσα στο παιχνίδι. Το AWMN είναι ένα καλό πεδίο έρευνας στα δίκτυα.
Υπάρχουν κάποια πρωτόκολλα και implementations σε βρεφικό στάδιο ακόμα. Χωρίς να είμαι σχετικός με αυτά απλά σας δίνω κάποια links που είχα σημειώσει:
http://qolsr.lri.fr/desc/intro.html
http://www.monarch.cs.cmu.edu/dsr-impl.html
http://rspf.sourceforge.net/
Δημήτρης
Τα συμπέρασματα στα οποία έχω καταλήξει είναι :
1) Mesh δεν πρόκειται να δουλέψει με το παρών πρωτόκολο.
2) Αξιόπιστα πρωτόκολα για mesh δεν υπάρχουν σε επίπεδο ελευθερου λογισμικού.
3) Ο μόνος τρόπος να συμμαζέψουμε λίγο τα πράγματα, είναι να χωρίσουμε τις διαδρομές σε κατηγορίες ανάλογα με την διαθεσιμότητα τους και να αποδόσουμε ανάλογα κόστη. Δηλαδή μία δευτερεύουσα διαδρομή θα αντικαθιστά μία πρωτεύσα μόνο όταν η δεύτερη πέσει τελείως.
Μέγα προβλημα εδώ είναι ότι οι περισσότεροι θεωρούν ότι τα λινκς τους είναι οι στυλοβάτες του δικτύου και δύσκολα θα δεχθούν να χαρακτηρισθούν δευτερεύοντες.
Άλλο πρωτόκολλο να γράψουμε δεν το βλέπω σαν εφικτή λύση.
Να κάνουμε όμως μικροδιορθωσούλες είναι δυνατό..
. Διαδρομές που δεν παίζουν σταθερά στα 11Mbps, πρέπει αυστηρά να έχουν δυσανάλογα μεγάλο βάρος, ώστε να λειτουργήσουν σαν εφεδρείες. Εξαίρεση βέβαια, όταν δεν υπάρχει εναλλακτική διαδρομή.
. Θα μπορούσε να σπάσει το δίκτυο σε περισσότερα areas. Σε ενσύρματα δίκτυα οπου η πληροφορία δρομολόγησης που ανταλλάσεται είναι λιγότερη, βάζουν 50 το πολύ δρομολογητές ανά area. Κάτι τέτοιο θα μείωνε πολύ την πληροφορία δρομολόγησης που ανταλάσσεται. Για παράδειγμα αν τραμπαλίζει το δικό μου Link ποιος ο λόγος να διαδίδω την πληροφορία σε μια άλλη area, πολύ πιο μακρινή μου; Μέχρι να διαδωθεί η πληροφορία, το λινκ έχει ξανάρθει, με αποτέλεσμα η εικόνα που έχει ο μακρινός μου να μην είναι η αληθινή.
. Οι ασύρματες κάρτες όταν πέσει η ζεύξη, αμέσως ενημερώνουν το πρωτόκολλο και αυτό αμέσως στέλνει την πληροφορία ότι η ζεύξη δεν υφίσταται σε όλο τον κόσμο. Το ίδιο και όταν η ξεύξη αποκατασταθεί.
Όταν όμως έχουμε ασύρματη εξωτερική συσκευή και να πέσει η ζεύξη, επειδή η ethernet σύνδεση παραμένει το πρωτόκολλο δεν αντιλαμβάνεται τη διακοπή. Θα την αντιληφθεί μετά από 40 δεύτερόλεπτα, όπου δεν θα έχει λάβει σημείο ζωής από το γείτονα (hello μήνυμα).
Στα 40 αυτά δεύτερα όλος ο κόσμος θα νομίζει ότι η ζεύξη υφίσταται. (έχω την εντύπωση ότι πολλά τραμπαλίσματα οφείλονται σε αυτό).
Έτσι καλό θα ήταν σε ζεύξεις στις οποίες η ποιότητα δεν είναι άριστη, να μπουν και στους δύο δρομολογητές, μόνο στις αντίστοιχες θύρες hello intervals πολύ μικρά, της τάξεως του δευτερολέπτου.
Έτσι κάθε ένα δευτερόλεπτο το πρωτόκολλο θα δειγματοληπτεί την κατάσταση της ζεύξης.
Η προτασή μου είναι να δοκιμάσουμε και να δούμε τα αποτελέσματα. Έτσι και αλλιώς δεν θα καταργηθεί το ospf σαν IGP. Θα κόψουμε κάποια κομμάτια (πχ 4) και θα τα βάλουμε να ανταλλάσουν BGP4 σαν τεσσερεις μεγάλες περιοχές. Μετά από αυτό βλέποντας και κάνοντας.
Δεν είπα για καλύτερο multipath (αν και θα είναι γιατι έχουμε dampening και flap stats με penalties κτλ)
Είπα για καλύτερο χειρισμό του routing table.
Κάτι άλλο που δεν ξέρω αν έχετε σκευτεί είναι ότι το ospf έχει limitation στους Maximum Routers per Area. ΄
Ας μην το κάνουμε όμως θέμα, εγώ για καλό το είπα και έγινε χαμός. Από την άλλη αν δεν θέτε τα αφήνουμε και έτσι.. Fine by me. Εγώ απλά στα links που έχω η θα έχω θα ψάχνω πρώτα την σταθερότητα ακόμα και αν το Link θα παίζει στο 1Mb (αν πρέπει να γίνει αλλιώς δεν θα το κάνω καθόλου) και μετά το οτιδείποτε άλλο.
Δεν καταλαβαίνω γιατί πρέπει να είναι στα 11 ασταθές και όχι στα 5.5 σταθερό, αυτό να το σκευτούν όλοι όσοι έχουν ασταθή Links και μετά να κλαίνε για το routing.
Κάποια στιγμή πρέπει να έχει νόημα και το bandwidth στους BB κόμβους γιατί όπως και να το κάνουμε 4-5Mb δεν χωράνε σε ένα link μόνο και ή θα αναγκαζόμαστε να γκρινιάζουμε για το utilization και να βάζουμε traffic shapers η να ξυπνήσουμε και να δρομολογούμε τα πακετάκια μας από διαφορετικά links όχι αναγκαστικά SPF!
Αρα λοιπόν OSPF για IGP σε κοντίνά areas και BGP στα borders προς πιο μακρινά και μην μου πει κανείς για full-mesh γιατί θα κάνουμε test schenario με κομμένα/ασταθή Links προς ΠΧ #1, #38, #72 και να δούμε ποιός θα κλαίει μετά.
Τέλος πάντων όπως είπα, αν θέτε, αν δεν θέτε δεν πειράζει καλά να'μαστε.
Φιλικά και χωρίς flame-οκατάσταση,
-Γιάννης
Η προτασή μου είναι να δοκιμάσουμε και να δούμε τα αποτελέσματα.
Υπάρχει εδώ ένα ωραίο τετράπλευρο spirosco - GRGS - Koem - MAuVE - spirosco.
Αν ξέρεις να το κάνεις και συμφωνούν και οι υπόλοιποι 3, από εμένα έχεις το ok.
Billgout
28/05/2004, 11:48
Νίκο, ysam
Επαναλαμβάνω ότι αν χρειαστείτε κάποια βοήθεια, χαμαλίκι, ψυχολογική υποστήριξη κτλ.(χώρις απαραιτητη συμμετοχή του κόμβου μου αν αυτό δεν εξυπηρετει - θα λείπω μόνο από Κυρ. εως Τετάρτη στη Αυστρία) είμαι στη διαθεσή σας. :D
Πιστέυω ότι αξίζει να δοκιμάσουμε κάτι καινούργιο που ίσως μας κάνει περισσότερο, γι' αυτό που θέλουμε, από δοκιμασμένες λύσεις που μπορούν να μας πάνε κάπου, άλλα όχι πολύ μακρυά απ' ότι φαίνεται, για πολλούς λόγους (Αναφέρθηκαν μεταξύ αλλων ανομοιομορφία λειτουργικών, έλειψη εφαρμογής πολιτικών - αν υπάρχουν ξεκάθαρες, με τους οποίους δεν διαφωνώ)
Απλά σκέφτομαι ότι ίσως δεν χρειάζεται να ξανα-ανακαλύψουμε τον τροχό
για να φτιάξουμε άμαξα......
Φιλικά,
Βασίλης
Υπάρχει εδώ ένα ωραίο τετράπλευρο spirosco - GRGS - Koem - MAuVE - spirosco.
Αν ξέρεις να το κάνεις και συμφωνούν και οι υπόλοιποι 3, από εμένα έχεις το ok.
Να το μελετήσω και θα σου πω. Ελπίζω να έιναι όλα Linux για να μην έχουμε θέματα.
-Γιάννης
Ελπίζω να έιναι όλα Linux για να μην έχουμε θέματα.
-Γιάννης
3 slack by spirosco & 1 1711 by cisco
Το 1711 τι IOS έχει και πόση μνήμη και πόση flash?
Μπορούμε να έχουμε ένα show ver και ένα show run?
-Γιάννης
Το 1711 τι IOS έχει και πόση μνήμη και πόση flash?
Μπορούμε να έχουμε ένα show ver και ένα show run?
-Γιάννης
Cisco Internetwork Operating System Software
IOS (tm) C1700 Software (C1700-K9O3SY7-M), Version 12.2(15)ZL, EARLY DEPLOYMENT
RELEASE SOFTWARE (fc1)
Synched to version 12.3(0.1)
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Fri 13-Jun-03 06:31 by ealyon
Image text-base: 0x80008120, data-base: 0x811F7FD8
ROM: System Bootstrap, Version 12.2(7r)XM4, RELEASE SOFTWARE (fc1)
ROM: C1700 Software (C1700-K9O3SY7-M), Version 12.2(15)ZL, EARLY DEPLOYMENT RELE
ASE SOFTWARE (fc1)
Cisco_1711_@_MAuVE uptime is 6 weeks, 2 days, 20 hours, 19 minutes
System returned to ROM by power-on
System image file is "flash:c1700-k9o3sy7-mz.122-15.ZL.bin"
cisco 1712 (MPC862P) processor (revision 0x100) with 84167K/14137K bytes of memo
ry.
Processor board ID FOC07350WLE (2014571916), with hardware revision 0000
MPC862P processor: part number 7, mask 0
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 Ethernet/IEEE 802.3 interface(s)
5 FastEthernet/IEEE 802.3 interface(s)
1 ISDN Basic Rate interface(s)
1 Virtual Private Network (VPN) Module(s)
32K bytes of non-volatile configuration memory.
32768K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
Για περισσότερα, σου στέλνω με pm οδηγίες πρόσβασης
Πριν αρχισουμε να αλλαζουμε το ενα IP routing protocol μετα το αλλο, δεν κοιταμε λιγο πιο προσεκτικα στις απαιτησεις που εχουν το καθε ενα?
Το OSPF απαιτουσε να υπαρχει σωστο IP Summarization ωστε να μπορει να λειτουργησει σωστα. Επιπλεον, θα μας εδινε δυνατοτητες να φτιαξουμε αρκετα Autonomous Systems (AS) και στους Border Routers (ASBR) θα μπορουσαμε να τρεξουμε και BGP αν το κριναμε αναγκαιο.
Δυστηχως ομως, προσπαθουμε να στησουμε χωρις τα θεμελια να ειναι σωστα και ως γνωστο, παλατια στην αμμο δεν χτιζονται.
5 FastEthernet/IEEE 802.3 interface(s)
1 ISDN Basic Rate interface(s)
1 Virtual Private Network (VPN) Module(s)
Μαμάαααα!!! :lol:
Μην τρελιέν.. έχει μια switch κάρτα επάνω του..
μα περνει ο 1712 Module για εξτρα πορτες?
εαν περνει ειναι η λυση στο προβλημα μου....
Στους 1711/12 έχεις επάνω το WIC-4ESW οπότε μπορείς μα παίξεις με vlans.
Βασικό του πρόβλημα είναι το bw του slot που δεν μπορεί να περάσει τα 12Κpps άμα θυμάμε καλά. Οπότε με 2-3 loaded links το έχεις σκίσει.
Εμ 17χχ είναι τι περιμένεις να τον βάλεις για core routing? :lol: :lol:
΄
χεχε
απο οτι βλεπω στο δικο μου 1712 εχει 1 fast ethernet και 4 vlan...και δεν βλεπω τροπο (εμφανη) ή χωρο (απο πισω) να μπουν εξτρα fast ethernet ή εξτρα vlan.
οσο αφορα το BW ,εαν σηκωνει εστω και στα ορια 3 ΒΒ λινκ ειναι οτι πρεπει...μ'αρεσει να δουλευουν τα μηχανηματα στα ορια τους...αυτο που δεν μ'αρεσει ειναι να αγοραζω κατι και να χρησιμοποιω μονο το 20-30% των δυνατοτητων του...πως να το πω με θεωρω βλακα...
απο οτι βλεπω στο δικο μου 1712 εχει 1 fast ethernet και 4 vlan...και δεν βλεπω τροπο (εμφανη) ή χωρο (απο πισω) να μπουν εξτρα fast ethernet ή εξτρα vlan.
οσο αφορα το BW ,εαν σηκωνει εστω και στα ορια 3 ΒΒ λινκ ειναι οτι πρεπει...μ'αρεσει να δουλευουν τα μηχανηματα στα ορια τους...αυτο που δεν μ'αρεσει ειναι να αγοραζω κατι και να χρησιμοποιω μονο το 20-30% των δυνατοτητων του...πως να το πω με θεωρω βλακα...
Εκεί που οι άλλοι 17χχ έχουν modules slots εσένα τα έχει καρφωμένα πόσες φορές θα το πώ;
Και δεν έχει 4 vlans αλλά 4 port switching module L2 τα οποία μπορούν να έχουν 16 διαφορετικά id.
Ένα μηχάνημα φτίαχνετε για κάποιο σκοπό. Τα 17χχ είναι SOHO routers , να σηκώσουν καμία 2Μbit fast serial και ένα c-class.
καλα ρε Γιαννη ,μην βαρας...μια ερωτηση εκανα...(δεν τα πιανω και ευκολα...αλτσχαιμερ γαρ)
Εκεί που οι άλλοι 17χχ έχουν modules slots εσένα τα έχει καρφωμένα πόσες φορές θα το πώ;
Οταν παραλάβω την 4SW, θα πάρω τρυπάνι, θα ξεπριτσινώσω την ISDN modem και θα του φορέσω δεύτερη τετράπορτη.
Πιθανότητες να την δεί πολύ λίγες, γιατί δεν θα είχαν φαντασθεί κανένα μανιακό να επιχειρεί κάτι τέτοιο.
Σαν δεύτερο σημείο επίθεσης, με πολύ περισσότερες πιθανότητες επιτυχίας, να του βάλω μία ENET.
Δεν ξέρεις τι μπορεί να βγεί. Και το misco κάπως έτσι προέκυψε.
Πριν κάνεις οτιδήποτε πολύ δραστικό καλό θα ήταν να δεις το hardware support του IOS που έχεις.. Για να σου δώσω να καταλάβεις εδώ έχουμε routers που με το λάθος IOS δεν βλέπουν κάρτες που κανονικά θα έπρεπε να βλέπουν..
-Γιάννης
Οταν παραλάβω την 4SW, θα πάρω τρυπάνι, θα ξεπριτσινώσω την ISDN modem και θα του φορέσω δεύτερη τετράπορτη.
Πιθανότητες να την δεί πολύ λίγες, γιατί δεν θα είχαν φαντασθεί κανένα μανιακό να επιχειρεί κάτι τέτοιο.
Σαν δεύτερο σημείο επίθεσης, με πολύ περισσότερες πιθανότητες επιτυχίας, να του βάλω μία ENET.
ειχα στειλει πριν κανα μηνα email στην cisco και τους ειχα ρωτησει εαν γινετε αυτο που λες...να βγαλω το isdn Modem που μου ειναι αχρηστο και να βαλω αλλο ενα 4-πορτο module που μου λειπει.
η απαντηση ηταν αρνητικη,οτι δεν θα το δει (μαλλον δεν θα εχει που να πατησει το Module)...αλλα δεν μπορουμε να περιμενουμε και καταφατικη απαντηση σε τετοια ερωτηματα απο την ιδια την κατασκευαστρια εταιρια...
(υπαρχουν και αλλοι τρελλοι στην γυρα...)
το ΕΝΕΤ τι ειναι?
ENET = 1 port Ethernet (10Mb)
ysam,υποθετω οτι ειναι αυτο ε?
http://cgi.ebay.co.uk/ws/eBayISAPI.dll? ... 90116&rd=1 (http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&category=3706&item=5710690116&rd=1)
Καλησπέρα,
Είμαι νέο μέλος στο φόρουμ και διαβάζοντας όλα αυτά που έχουν γραφτεί στο παρελθόν για πρωτόκολλα δρομολόγησης και λοιπά είπα να γράψω και γω την άποψη μου(μιας και διαθέτω κάποια εμπειρία επί του θέματος).
1ο Βασικό θέμα: Link stability και quality
Σε ένα δίκτυο της μορφής του AWMN είναι πάρα πολύ σημαντικό οι μεταπτώσεις της ποιότητας αλλά και της διαθεσιμότητας μιας σύνδεσης να μην χρειάζετε να διαφημίζετε σε όλους τους δρομολογητές του δικτύου παρά μόνο σε αυτούς που πρέπει. Σε άλλη περίπτωση και με την τοπολογία του OSPF που υπάρχει σήμερα το δίκτυο δεν μπορεί να λειτουργεί σωστά. Ιδιαίτερα με την "επίπεδη" λογική, του όλα μπαίνουν στο area 0.
2ο Βασικό θέμα: scalability
Η φύση του δικτύου δημιουργεί την ανάγκη να μπορεί το δίκτυο να αντέξει ανά πάσα στιγμή σε μεγάλες αλλαγές στην τοπολογία και λόγω των συχνών προβλημάτων αλλά και λόγω της αύξησης των δρομολογητών/συνδέσεων(εναλλακτικών αλλά και κύριων).
3o Βασικότατο θέμα: ασφάλεια
Σε ένα τόσο διεσπαρμένο όσον αφορά την διαχείριση του(από τόσους πολλούς και διαφορετικούς ανθρώπους) είναι άκρως επιτακτική η προστασία από λάθη που μπορούν υπό ορισμένες προύποθέσεις να "κατεβάσουν" το δίκτυο ή απλά να "εξαφανίσουν" περιοχές του. Με λίγα λόγια θα πρέπει να φιλτράρονται πάντα τα διαφημιζόμενα δίκτυα, έτσι ώστε να μην είναι δυνατόν κάποιος να διαφημίσει δίκτυο το οποίο δεν έχει καμία σχέση και ανήκει σε κάποιον άλλο. Η plug and play(ή μήπως pray) λύση που έχει καθιερωθεί στο AWMN δεν είναι ότι καλύτερο. Το να μπεί ένας δρομολογητής σε σημαντική θέση στο δίκτυο γρήγορα, μπορεί κάλιστα να σημαίνει ότι το ίδιο γρήγορα κάποιο μικρό ή μεγάλο κομμάτι του δικτύου εξαφανίζεται λόγω λάθους. Σε αντίθεση με αυτό αν πρέπει να παραμετροποιηθεί και στον κάθε ένα γειτονικό δρομολογητή για να δουλέψει(μπορεί να ακούγετε λίγο δυσκοίλιο αλλά έτσι είναι το σωστό), οι πιθανότητες για τέτοια κρούσματα θα μειωθούν σημαντικά.
4ο Βασικότατο Θέμα: Πολιτικές δρομολόγησης
Πολύ σημαντικό είναι κάποιος ο οποίος διαθέτει ένα "σημαντικό" κομβικό σημείο στο δίκτυο, να μπορεί να "επιβάλλει" μια πολιτική για την δρομολόγηση της κίνησης στις διάφορες συνδέσεις του.
Πρωτόκολλο για να υποστηρίξει επαρκώς όλα τα παραπάνω από μόνο του, δεν είναι το OSPF.
Η λύση που καλύπτει επαρκώς(μέχρι ενός σημείου πάντα) τα παραπάνω, για τέτοια άναρχα δομημένα δίκτυα(όπως σαφώς είναι και το AWMN αλλά και το Internet) είναι στο Core η χρήση BGP και στην άκρη(στα ASes που θα δημιουργηθούν αναγκαστικα) οποιοδήποτε IGP θέλει κανείς, ή ακόμα και στατική δρομολόγηση εφόσον υπάρχει μόνο ένας δρόμος. Λόγω του Linux κυρίως το OSPF μπορεί εκεί πλέον να δουλέψει μια χαρά.
Αυτά ήθελα να επισημάνω για αρχή και είμαι στην διάθεσή σας για οτιδήποτε.
-ΤιΟ
Όλα αυτά ειναι ωραιά και γνωστά αλλά ξεχνάτε το βασικότερο ... Δεν μπορείς να πεις ότι κάποιο είναι core γιατί μπορεί να στραβώσει ένα πρωί να κατεβάσει τον κόμβο του και μετά θα ψάχνουμε new area στο OSPF.
Δεν υπάρχει τίποτα σταθερό στο awmn εκτός από τα flames οπότε μην ελπίζετε για "φοβερές" λύσεις που τρέχουν σε ενσύρματα δύκτια με μόνο cisco routers (κατά 87-90%)
Στο awmn οι περισσότεροι routers τρέχουν quagga οπότε το bgpd της θα μας πετάξει πολλαπλάσια probs από το ospfd. Λύσεις windows για router και άμα έχουν BGP δεν τις σχολιάζω.
Για να αλλάξουμε το ΟSPF area 0 σε κάτι άλλο θέλω να γίνονται τα παρακάτω:
1. Setup 3 γραμμών
2. Δεν αλλάζει κανένας το setup του αν ο διπλανός του παει φαντάρος , τα παρατήσει
3. Είναι συμβατό και δοκιμασμένο με τα βασικά reqs των rfc του protocol.
4. Υπάρχει σε routers cisco με IOS 12.2 (ip/plus) και πάνω.
4. Υπάρχει σε routers cisco με IOS 12.2 (ip/plus) και πάνω.
Αυτό μας έκοψε λίγο την φόρα ... :)
Γιατι σκεφτόμουν αυτά που λέει το παλικάρι εδώ:
http://peertech.org/WirelessMeshRoutingProtocols
Και εδώ:
http://portal.acm.org/citation.cfm?id=2 ... oll=portal (http://portal.acm.org/citation.cfm?id=272250&dl=ACM&coll=portal)
Και εδώ:
http://www.pdos.lcs.mit.edu/grid/software.html
Όλα αυτά ειναι ωραιά και γνωστά αλλά ξεχνάτε το βασικότερο ... Δεν μπορείς να πεις ότι κάποιο είναι core γιατί μπορεί να στραβώσει ένα πρωί να κατεβάσει τον κόμβο του και μετά θα ψάχνουμε new area στο OSPF.
Δεν υπάρχει τίποτα σταθερό στο awmn εκτός από τα flames οπότε μην ελπίζετε για "φοβερές" λύσεις που τρέχουν σε ενσύρματα δύκτια με μόνο cisco routers (κατά 87-90%)
Στο awmn οι περισσότεροι routers τρέχουν quagga οπότε το bgpd της θα μας πετάξει πολλαπλάσια probs από το ospfd. Λύσεις windows για router και άμα έχουν BGP δεν τις σχολιάζω.
Για να αλλάξουμε το ΟSPF area 0 σε κάτι άλλο θέλω να γίνονται τα παρακάτω:
1. Setup 3 γραμμών
2. Δεν αλλάζει κανένας το setup του αν ο διπλανός του παει φαντάρος , τα παρατήσει
3. Είναι συμβατό και δοκιμασμένο με τα βασικά reqs των rfc του protocol.
4. Υπάρχει σε routers cisco με IOS 12.2 (ip/plus) και πάνω.
1> και 13 άμα θέλεις..
2> Ε να βγάλει και κανένα entry ο απέναντη για να μην εχει στο config του settings για link που δεν υπάρχει..
3> quagga σαφώς πολύ πιο stable από παλιά (zebra) και mrtd σε windows.
4> αυτό από 10.3 θα το βρείς.. 12.2 είναι πολύ new και με ip plus κιόλας ακόμα καλήτερα.
Παρακαλώ καποιον admin να μεταφέρει τα post στο thread που έφτιαξα γιατί έχουν άμεση σχέση και πολύ ενδιαφέρον.(επιτέλους) "Συζήτηση για νέο Πρωτόκολλο Δρομολόγησης".
-Γιάννης
4. Υπάρχει σε routers cisco με IOS 12.2 (ip/plus) και πάνω.
Αυτό μας έκοψε λίγο την φόρα ... :)
Γιατι σκεφτόμουν αυτά που λέει το παλικάρι εδώ:
http://peertech.org/WirelessMeshRoutingProtocols
Και εδώ:
http://portal.acm.org/citation.cfm?id=2 ... oll=portal (http://portal.acm.org/citation.cfm?id=272250&dl=ACM&coll=portal)
Και εδώ:
http://www.pdos.lcs.mit.edu/grid/software.html
Τα cisca δεν τα σκεύτηκε κανείς όμως, ούτε καν τα winblowz.
-Γιάννης
4. Υπάρχει σε routers cisco με IOS 12.2 (ip/plus) και πάνω.
Αυτό μας έκοψε λίγο την φόρα ... :)
Γιατι σκεφτόμουν αυτά που λέει το παλικάρι εδώ:
http://peertech.org/WirelessMeshRoutingProtocols
Και εδώ:
http://portal.acm.org/citation.cfm?id=2 ... oll=portal (http://portal.acm.org/citation.cfm?id=272250&dl=ACM&coll=portal)
Και εδώ:
http://www.pdos.lcs.mit.edu/grid/software.html
Τα cisca δεν τα σκεύτηκε κανείς όμως, ούτε καν τα winblowz.
-Γιάννης
Πολύ για cisca μας λες...ρε μπας και είσαι πλασιέ της cisca και μας το κρύβεις? :lol: Τόσο η cisca όσο και η winblowz είναι μεγάλες εταιρίες, πρέπει αυτές να σκεφτούνε τον εαυτό τους, όχι να περιμένουν άλλους να σκεφτούν για αυτές... :wink:
Δεδομένου ότι το OSPF-area0 δεν μπορεί να σηκώσει πολλά άτομα και δεδομένου ότι ο συνδιασμός BGP-OSPF αντικειμενικά κρινόμενος δεν έχει πολλές ελπίδες να παίξει λόγω των παρεμβολών (αν και θα ήθελα πολύ κάποιος να το δοκιμάσει και αυτό στην πράξη) ποιό είναι το προτόκολλο που νομίζετε ότι θα επικρατήσει?
Βλέπω αρκετό software να κυκλοφορεί για το AODV. Αλήθεια το δοκίμασε τελικά κανείς στην πράξη στο awmn? Βρήκα ότι έχει (http://www.awmn.gr/forum/viewtopic.php?p=5305&highlight=aodv&sid=a4978dd1eb0a00be8965b91b6bce06d1#5305) προταθεί (http://www.awmn.gr/forum/viewtopic.php?p=17003&highlight=aodv&sid=ab07779920465626675453da9a9fe092#17003) εδώ και πολύ καιρό, αλλά δεν βρήκα κάποιον να ανέφερε ότι το δοκίμασε εκτός εργαστηρίου (http://www.awmn.gr/forum/viewtopic.php?p=34441&highlight=aodv#34441). Νομίζω πάντως ότι κυκλοφορεί αρκετό software για το AODV απλά γιατί είναι το εύκολοτερο στην υλοποίηση του και όχι γιατί είναι το καλύτερο.
Έχω την διαίσθηση ότι καλύτερο προτόκολλο πρέπει να είναι κάποιο που να παίζει κάτω από το tcp-layer, και να λαμβάνει υπόψη το πόσο καλό είναι το σήμα πριν αποφασίσει που θα δρομολογήσει (σαν το SSR ή το SrcRR (http://www.pdos.lcs.mit.edu/roofnet/design/) για παράδειγμα).
nikrep,
κατ' αρχήν, από που άκουσες ότι το area 0 δε σηκώνει πολλά άτομα (routers μάλλον θα εννοείς);
Επίσης, οι διάφορες υλοποιήσεις που υπάρχουν και δεν υποστηρίζονται από πολλούς, θα αναλάβεις εσύ να τις υποστηρίξεις;
Εδώ για BGP και το σκεφτόμαστε άγρια, λόγω ανομοιογένειας γνώσεων και μηχανημάτων στο δίκτυο.
... λόγω ανομοιογένειας γνώσεων και μηχανημάτων στο δίκτυο.
Έτσι είναι, εεέτσι, υπάρχει ανομοιογένεια στα πάντα. Στις γνώσεις, στα μηχανήματα, στους χαρακτήρες, στα ενδιαφέροντα, στο ύψος, στο μήκος, στο πάχος, στην τριχοφυία. Δεν είναι άδικο να αφήσουμε το routing προτόκολλο να είναι ομοιογενές και ένα για όλους? Όλα τα καλά routing προτόκολλα χωράνε, κάλιστα μπορούν τα επιμέρους routing clusters να επικοινωνούν μεταξύ τους με κατάληλλους border routers. :D
Δεν είναι ανάγκη όλοι να αλλάξουν routing προτόκολλο. Αυτό που λέω είναι όσοι θέλουν και μπορούν να ακολουθήσουν ας το δηλώσουν για να δοκιμάστει και κάτι καινούργιο, και να μην μένουν όλοι στο τετριμμένο ospf.
Όσοι πιστοί, ικανοί και χομπίστες του δικτύου λοιπόν ας προσέλθουν στις δοκιμές, οι υπόλοιποι ας μείνουν με το ospf και ας ασχολούνται με αυτό που ξέρουν καλύτερα να κάνουν (leeching αρχείων, chat, flaming, leeching γνώσεων από αυτούς που τους κάνουν support κλπ κλπ κλπ :P :wink:)
Από το Σεπτέμβριο υπολογίζω να έχω φτιάξει τον κόμβο μου, να περάσει και η μπόρα των Ολυμπιακών αγώνων. Θα εκπέμπω σαν awmn_nikrep_my_routing_protocol και ελπίζω να βρέθουν άτομα που θα θελήσουν να ακολουθήσουν στους πειραματισμούς αυτούς. Θα ήθελα να δοκιμάστει για αρχή κάτι εύκολο-έτοιμο, όπως το AODV ή το SrcRR ή το DSDV ή οτιδήποτε άλλο ετοιματζίδικο, και μετά βλέπουμε...
....leeching γνώσεων από αυτούς που τους κάνουν support....
Χμ.. κύριε κύριε.. πόσο πρέπει να πλερώ?
Θα εκπέμπω σαν awmn_nikrep_my_routing_protocol και ελπίζω να βρέθουν άτομα που θα θελήσουν να ακολουθήσουν στους πειραματισμούς αυτούς. Θα ήθελα να δοκιμάστει για αρχή κάτι εύκολο-έτοιμο, όπως το AODV ή το SrcRR ή το DSDV ή οτιδήποτε άλλο ετοιματζίδικο, και μετά βλέπουμε...
Κατάλαβες τι εννοούσα Γιάννη;
Και ο nikrep, έχει το θάρρος να το λέει κι όλας. Όσοι είναι κρυφά ποταμάκια;
@nikrep: Φίλε μου, δεν είμαστε μπάτε σκύλοι εδώ μέσα. Τι παει να πει, όσι πιστοί και πειραματισμοί; Αν θες να κάνεις πειραματισμούς, φτιάξε ένα lab (αν δεν έχεις μηχανήματα, να σου φέρω εγώ να τους κάνουμε μαζί - μπας και leechάρουμε τις γνώσεις σου δηλαδή :lol: :lol: ) και άσε το δίκτυο να παίζει όπως παίζει, μέχρι να έχεις συγκεκριμένα αποτελέσματα από αυτό που προσπαθείς να κάνεις.
Είναι τόσο δύσκολο βρε παιδιά να σεβόμαστε τα links των άλλων; Δηλαδή, ότι μας κατεβάσει η "γκλάβα μας" θα πάμε να το εφαρμόσουμε στην πλάτη των άλλων; Εδώ βρήκαμε να βγάλουμε τον "Ντα βίντσι" των routers;
Άντε μην πω πια... Άντε...
@mindfox
Κωστα,εγω καταλαβα οτι ο nikrep αυτο ακριβως θα κανει...θα αρχισει δοκιμες απο Σεπτεμβριο,και ζητησε οποιος αλλος θελει να πειραματιστει μαζι του...δεν νομιζω να εννοουσε να αρχισουμε να δοκιμαζουμε πρωτοκολλα,ετσι απλα, στο ΒΒ για να δουμε ποιο ειναι καλυτερο...
"ρε παιδια ξερετε γιατι δεν περναω προς το νοτο;...ε,ναι σημερα δοκιμαζουμε το SLR McLAREN....αυριο το CL55 MKB..."
Δεν πιστευω δηλαδη καποιος να θελει να αρχισει τα πειραματα πανω στο δικτυο και με οτι στραβο συμβαινει να κοβετε αυτο στην μεση ή να βγαινουν εξω απο το δικτυο ολοκληρες περιοχες...μπορει πολυ ωραια να γινει σε ελεγχομενο περιβαλλον,οπως εκανε ο ysam με το Χαλανδρι (ή τα Βριλλησια) νομιζω.
Μολις σταθεροποιηθει μια λυση σε τοπικο και ελεγχομενο επιπεδο,τοτε μπορει να εφαρμοστει και σε μια αλλη κλειστη και ελεγχομενη περιοχη και να συνδεθουν οι δυο περιοχες μεταξυ τους.
Εαν δουμε οτι και ετσι συνεχιζεται η καλη λειτουργια,το δοκιμαζουμε σε πιο μεγαλη κλιμακα και σε πιο κεντρικους κομβους.
Ειναι πολυ ανωριμο και ανευθυνο καποιος να θελει να κανει πειραματοζωο το δικτυο,που καλως ή κακως σημερα παιζει με το ospf,και οτι προβληματα βγαινουν,αντιμετωπιζονται σε λιγο χρονο.
pargyrak
04/08/2004, 14:58
Εκεί που οι άλλοι 17χχ έχουν modules slots εσένα τα έχει καρφωμένα πόσες φορές θα το πώ;
Οταν παραλάβω την 4SW, θα πάρω τρυπάνι, θα ξεπριτσινώσω την ISDN modem και θα του φορέσω δεύτερη τετράπορτη.
Πιθανότητες να την δεί πολύ λίγες, γιατί δεν θα είχαν φαντασθεί κανένα μανιακό να επιχειρεί κάτι τέτοιο.
Σαν δεύτερο σημείο επίθεσης, με πολύ περισσότερες πιθανότητες επιτυχίας, να του βάλω μία ENET.
Δεν θα τη δει. Εγώ έχω έναν 1721 με το 4SW και μια Enet επάνω. Χρησιμοποιώ ουσιατικά τρία interfaces συνολικά γιατί άν βάλεις vlans στην 4SW η μία πόρτα για να μιλήσει στην άλλη θα πρέπει να περάσει από τη CPU στα 10Mbit.
Βασικά ο 1721 χρησιμοποιείται στο node μου για firewall ανάμεσα στο εσωτερικό μου δίκτυο, την DMZ μου και το TWMN-WTHESS-SWN-KoutsimariaWN.
Για routing ένας 4500 με μια 6άρα 10Mbit και δύο 100άρες (χωρισμένες σε VLAN). Ο 1721 δεν αντέχει.
pargy
Καλά.. όταν έλθω να φτιάξω ένα συμβατικό τροφοδοτικό DC για το PC με battery backup και να κανονίσω ένα ramdisk με linux να φορτώνει από flash. Σόρυ, αλλά το να πάρει κάποιος μεγαλύτερο μηχάνημα από 1720 series για ερασιτεχνική χρήση, σημαίνει άσκοπα $$$ (εκτός και να έχει κερδίσει πρόσφατα κανά λαχείο :D )
PC!
Το έχω πει ξανά αλλά άμα δεν θες voip, βρήσκεις 4500/4700 με μια 100αρα ή με 1 6αρα 10Mbps στο ebay με 200-250 εuro τελική σπιτι σου.
papashark
04/08/2004, 22:15
Το έχω πει ξανά αλλά άμα δεν θες voip, βρήσκεις 4500/4700 με μια 100αρα ή με 1 6αρα 10Mbps στο ebay με 200-250 εuro τελική σπιτι σου.
Σύντομα μπορεί να έχουμε λινκς με 20mbit πραγματική ταχύτητα (δοκιμαστικά έπαιξαν), θα περιοριστούμε σε 10Mbit πόρτες ?
Για αυτό είπα και 100αρα για vlans. Αλλα άμα είναι περιορισμένης ο άλλος και πάει να πάρει 10αρα τι να του κάνω ?
AWMN 2010
Powered by vBulletin™ Version 4.1.4 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.