View Full Version : Μετάβαση απο RIPv2 σε OSPF
Πιστευω οτι ειναι καιρος να κανουμε τις πρωτες σκεψεις και σχεδιασμους για τα βηματα της μεταβασης απο το RIPv2 σε OSPF.
Αυτο που θελω να ρωτησω και ειναι βασικο για να δουλεψει σωστα το OSPF ειναι αν εχει γινει IP Sumarization ή αν απλα τα ΙΡ εχουν δωθει με βαση αλλα κριτηρια.
middle_EAST_WEST
11/09/2003, 14:38
Elpizw na exeis katalavei me afto to thema anoigeis tous askous tou aiolou!!!
Endexomenos zeis se fanastiko kosmo pou ola pigainoun roloi. To OSPF den mas kanei gia tin wra giati ta link pou iparxoun einai 1:1, dld o idios dromos gia olous, den iparxoun epikaliptomena link pou na dinoun enalaktikes diadromes.
Ara to OSPF se ti tha mporouse na exipiretei? mallon, milwntas gia ton diko mou kombo, tha dimiourgouse TROMERA problimata. :twisted:
MEW μιλαω για μεταβατικα σταδια. Δεν θα παμε απο την μια στιγμη στην αλλη σε OSPF.
Σκεφτομουν σε 5-6 κεντρικους κομβους απο τους οποιους επεκτεινονται τα links προς διαφορες περιοχες να και οι οποιοι συνδεονται με καλα και σταθερα links να μπει OSPF.
MEW κανεις λάθος, υπάρχουνε εναλακτικές διαδρομές και μεσα στο AWMN και φυσικά υπαρχουνε περισοτερες απο μια internet gateways.
Τα Internet gatways ισως θα επρπε να τα χειριστουμε αλλιως. Βλεπω τον Achille που προσπαθει να βρει εναν τροπο δυναμικα να αλλαζουν τα GW αλλα δεν ειναι οτι ποιο ευκολο.
Κανεις δεν σκεφτεται πλεον να προμηθευτουμε εναν αριθμο DSL και να μοιραστουν αυτες οπως και το κοστος στα APs που εξυπηρετουν πελατες?
Achille, θα ηθελα αν μπορεις να τα πουμε στο Σαββατο στο meeting. Ελπιζω να τα καταφερεις να ερθεις.
Κανεις δεν σκεφτεται πλεον να προμηθευτουμε εναν αριθμο DSL και να μοιραστουν αυτες οπως και το κοστος στα APs που εξυπηρετουν πελατες
Πάντα αυτό σκέφτομαι, αλλά στην πράξη θα πάρει αρκετό διάστημα απ΄ ότι φαίνεται, καθώς ο πΟΤΕ κινείται σε ρυθμούς χελώνας. Από την άλλη βέβαια απαιτείται καλός συντονισμός και συνεννοήσεις μεταξύ μας που λόγω καλοκαιριού δεν ήταν εύκολο να γίνουν. Πέρα από όποια σύνδεση γίνεται ελεύθερα shared στο awmn, καλό είναι να υπάρχουν και εναλλακτικές συνδέσεις, ώστε κανείς ποτέ να μη ξεμείνει από πρόσβαση στο Internet αν πέσει ένα internet gateway.
O OTE κινειτε με ρυθμους χελωνας αλλα αυτο δεν σημαινει οτι εμεις θα πρεπει να κατσουμε και να περιμενουμε ποτε θα αποφασισει να κανει κατι για να ξεκινησουμε και εμεις τις διαδικασιες. Μπορουμε να ξεκινησουμε να σχεδιαζουμε το πως θα οργανωθουμε, να προετοιμασουμε τις "γειτονιες" που θα μοιραζονται την DSL μεταξυ τους και να κανουμε μια ερευνα αγορας για να καταληξουμε που θα απευθυνθουμε. Ετσι εμεις εχουμε κανει ενα βημα μπροστα και θα ειμστε ετοιμοι να ξεκινησουμε οταν διατεθουν σε ολες τις περιοχες.
Στην περιπτωση που "πεσει" καποιο link με το Internet τοτε μπορουν να εφαρμοστουν τα σεναρια που σκεφτετα ο Achille.
Ρένο, εγώ έχω μπροστά μου 3 γραμμές ADSL τις οποίες οι κάτοχοί τους δίνουν ελεύθερα, και ψάχνω τρόπο να τις χρησιμοποιήσουμε όλοι, με το λιγότερο δυνατό κόπο και όσο πιο αυτόματα γίνεται.
Στις γραμμές επί πληρωμή υπάρχουν και πιο απλοί τρόποι να ρυθμίσεις το default gw (tunneling).
Το θέμα είναι τι θα κάνουμε με τις γραμμές που μας προσφέρονται, ή θα μας προσφερθούν στο μέλλον δωρεάν.
Επειδή το 3ο κομμάτι του AWMN Β52-Ηοok-Macrx-Nasos-Mew και ΣΙΑ :wink: ετοιμάζεται να εισέλθει δυναμικά... το rip δε μας σώζει... μέχρι και static routes έχω σκεφτεί να χρησιμοποιήσουμε....
Σε δοκιμαστικό link με Β52 και Mauve ,όταν έβλεπα Mauve δεν έβλεπα Β52 (προσπαθούσε να τον δει μέσο Mauve) δεν μπορώ να καταλάβω γιατί...
middle_EAST_WEST
20/09/2003, 11:03
Επειδή το 3ο κομμάτι του AWMN Β52-Ηοok-Macrx-Nasos και ΣΙΑ ετοιμάζεται να εισέλθει δυναμικά... το rip δε μας σώζει... μέχρι και static routes έχω σκεφτεί να χρησιμοποιήσουμε....
...Απο middle_EAST_WEST έγινα mew και απο mew, ΣΙΑ??
Μετά από την στιγμή που καταφέραμε να συνδεθούμε, έστω και για μια μέρα με τους βόριους κατάλαβα ΠΡΑΓΜΑΤΙΚΑ ότι το rip δεν μας κάνει και χρειάζεται να αλλάξει άμεσα!
ένα τρελό παράδειγμα ήταν μια IP 10.14.117.χ αν θυμάμαι καλά που την έκανε μπαλάκι του ping πονγ μεταξύ εμένα και του shock. !?! με αποτέλεσμα το traceroute να μην την φτάσει ποτέ!
Πράγματι ο Renos έχει δίκιο!Νομίζω ότι υπάρχει ανάγκη για ένα σεμινάριο για OSPF.Δεν συμφωνείτε?
middle_EAST_WEST
20/09/2003, 11:10
Ρένο, εγώ έχω μπροστά μου 3 γραμμές ADSL τις οποίες οι κάτοχοί τους δίνουν ελεύθερα, και ψάχνω τρόπο να τις χρησιμοποιήσουμε όλοι, με το λιγότερο δυνατό κόπο και όσο πιο αυτόματα γίνεται.
Στις γραμμές επί πληρωμή υπάρχουν και πιο απλοί τρόποι να ρυθμίσεις το default gw (tunneling).
Το θέμα είναι τι θα κάνουμε με τις γραμμές που μας προσφέρονται, ή θα μας προσφερθούν στο μέλλον δωρεάν.
Αυτό το ερώτημα με βασανίζει καιρό. Η μόνη λύση που έχω μέχρι τώρα για να μπορέσει να φτάσει η σύνδεση μέχρι τον τελευταίο κόμβο είναι η χρήση του squid σε μοντέλο "φάρμας" και ως transparent proxy.
Δυστηχώς δεν το έχω δοκιμάσει ακόμα αν και έχω αρκετό configuration για να το φτιάξω. Αν κάποιος ενδιαφερθεί για δοκιμές ας στείλει ενα pm.
Δοκιμάστε να φιλτράρετε τη συγκεκριμένη στο rip και να τη βγάλετε static...
Μιας και τελείωσα με τα άλλα που έκανα, πιστεύω ότι πρέπει να επαναφέρουμε το θέμα του OSPF.
Στην ερώτηση του Renou να πω ότι τα IPs δίνονται με γεωγραφικά κριτήρια (ανά περιοχή).
Ας προτείνει κάποιος που να ξέρει πως πρέπει να χωρίσουμε τα Areas, αν μας συμφέρει να έχουμε μεγάλο ή μικρό Area 0, τι πλεονεκτήματα-μειονεκτήματα υπάρχουν κλπ.
papashark
04/10/2003, 21:12
Μήπως να κανονίζαμε μία συνάντηση με πίνακα, γραφείο και σημειώσεις (και όχι καφέ μουσική και αιθέριες θηλυκές υπάρξεις) ?
Να κανονίσουμε, αν και δεν είναι εύκολο να βρεθούμε όλοι...εγώ ειδικά είμαι πνιγμένος αυτόν τον καιρό...
Μιας και τελείωσα με τα άλλα που έκανα, πιστεύω ότι πρέπει να επαναφέρουμε το θέμα του OSPF.
Στην ερώτηση του Renou να πω ότι τα IPs δίνονται με γεωγραφικά κριτήρια (ανά περιοχή).
Ας προτείνει κάποιος που να ξέρει πως πρέπει να χωρίσουμε τα Areas, αν μας συμφέρει να έχουμε μεγάλο ή μικρό Area 0, τι πλεονεκτήματα-μειονεκτήματα υπάρχουν κλπ.
Λοιπον, κοιτα να δεις τι περιορισμους και τι προυποθεσεις εχεις:
Τα ΙΡ πρεπει να δινονται βαση συνδεσεων πλεον και να ακολουθουν μια δενδροειδη δομη. Ετσι καταφερνουν να ειναι summarazed και δεν γεμιζουν τους routers με entries για το καθε subnet.
Πρεπει να εχεις μικρο Area 0 με γρηγορα και σταθερα links. Ολο το traffic απο ενα area σε ενα αλλο περναει μεσα απο το Area 0 οποτε καταλαβαινεις τι απαιτησεις εχει.
Πολυ πιο απλα, η σχεδαση για το OSPF μοιαζει με το σχεδιο της μαργαριτας. Ολα τα areas εποικοινωνουν με το κεντρο.
Λοιπον, κοιτα να δεις τι περιορισμους και τι προυποθεσεις εχεις:
Τα ΙΡ πρεπει να δινονται βαση συνδεσεων πλεον και να ακολουθουν μια δενδροειδη δομη. Ετσι καταφερνουν να ειναι summarazed και δεν γεμιζουν τους routers με entries για το καθε subnet.
Αυτό δεν νομίζω ότι είναι δυνατό, είδαμε και πάθαμε να κάνουν αιτήσεις για να πάρουν IPs, αποκλείεται να τις αλλάξουν.
Θα αναγκαστούμε να σχεδιάσουμε με το δεδομένο ότι δεν θα έχουμε καλό summarization.
Πρεπει να εχεις μικρο Area 0 με γρηγορα και σταθερα links. Ολο το traffic απο ενα area σε ενα αλλο περναει μεσα απο το Area 0 οποτε καταλαβαινεις τι απαιτησεις εχει.
Αν λοιπόν κοπεί στη μέση το Area 0 για κάποιο λόγο, αλλά συνδέονται τα άκρα του μέσω του Area 1 ας πούμε, δεν θα δρομολογηθούν τα πακέτα μέσω του Area 1?
H χρήση κεντρικού backbone δεν νομίζω ότι μας βολέβει ιδιαίτερα, θέλουμε να είναι όσο πιο mesh γίνεται.
Αν δουλέψουμε με μηδενικό Area 0? (Πχ 1 host) Αν βάλουμε όλους τους routers στο Area 0 ? Δενδρική δομή χωρίς ένα κεντρικό Area δεν μπορούμε να υλοποιήσουμε;
Μόλις θίξατε το πιο δύσκολο θέμα στη σωστή εφαρμογή του OSPF.
Για να λειτουργήσει σωστά και χωρίς πολλές απαιτήσεις σε μνήμη και επεξεργαστική ισχύ, όντως πρέπει να χωριστεί σε αυτόνομες ζώνες, όπου ένας από τους routers είναι ο BR που επικοινωνεί με τη ζώνη 0.0.0.0
Επίσης κατόπιν ellection μεταξύ τους αποφασίζουν ποιος είναι ο Master και ποιος ο Backup router της ζώνης και αυτός αναλαμβάνει να κάνει τους υπολογισμούς για το routing tree (άρα ο ισχυρότερος router). Αυτός έπειτα κάνει διανομή του routing table στους εντός της ζώνης του routers.
Τώρα, αν σπάει αυτή η συνέχεια στην backbone ζώνη, μπορούμε να δημιουργήσουμε Virtual links μεταξύ των routers που χρειάζεται, αλλά δεν είναι ιδανική συνθήκη (όλα τα whitepapers που έχω δει μέχρι τώρα το αποφεύγουν)
Εύλογα, το σπάσιμο του δικτύου μας σε ζώνες δεν είναι εφικτό, μιας και δεν έχουμε λογική συνέχεια στα links μας, αλλά βασιζόμαστε σε άναρχη (mesh) τοπολογία.
Άρα, μάλλον θα παίξουμε όλοι στη ζώνη backbone. Αυτό όμως σημαίνει ότι τα ταρατσο-PCs ίσως να μη μπορούν να ανταπεξέλθουν στις αυξημένες απαιτήσεις σε μνήμη και επεξεργαστή και να δημιουργούνται όλων των ειδών τα παλαβά (λάθος summarizations, time outs κλπ)
Αν είμαστε έτοιμοι να κάνουμε αναβάθμιση σε μνήμη με ίσως ισχυρότερους επεξεργαστές (Celeron πιστεύω ότι αρκούν) τότε θα δουλέψει.
Το θέμα έχει ήδη συζητηθεί και με JS και Harisk. Θα κάνουμε ένα μικρό test-lab όπου θα δοκιμάσουμε το OSPF σε διάφορα σενάρεια και μάλιστα και σε συνεργασία με RIP. Να δούμε τι αποτελέσματα έχουμε από κάτι τέτοιο.
Φυσικά, θα ενημερωθείτε όλοι για αυτά τα αποτελέσματα.
Για το θέμα επεξεργαστικής ισχύος, βρήκαμε με το jabarlee κάποια ενδιαφέροντα mini-ITX με 600Mhz CPU, 2 Ethernet και 6USB 2.0
Θα ελένξουμε τις παραμέτρους κόστους, αν μπορούμε να βρούμε φτηνές USB->Ethernet που να δουλεύουν σε Linux κλπ και θα επανέλθουμε.
Επίσης αν μπορεί να μπει PCI Riser και να πάρουν 2 NetGear PCI που χρησιμοποιούν DMA.
Ίσως είναι καιρός να ξεχάσουμε τα Pentium I και να πάμε σε πιο σοβαρές, δυνατές και αξιόπιστες λύσεις.
wiresounds
07/10/2003, 14:37
Για το θέμα επεξεργαστικής ισχύος, βρήκαμε με το jabarlee κάποια ενδιαφέροντα mini-ITX με 600Mhz CPU, 2 Ethernet και 6USB 2.0
Σκέφτομαι και εγώ κανένα τέτοιο, τα έλεγα εχθές στον mindfox. Παρακαλώ στείλε pm αν αγοράσετε ή άνοιξε ομαδική.
Για το θέμα επεξεργαστικής ισχύος, βρήκαμε με το jabarlee κάποια ενδιαφέροντα mini-ITX με 600Mhz CPU, 2 Ethernet και 6USB 2.0
Θα ελένξουμε τις παραμέτρους κόστους, αν μπορούμε να βρούμε φτηνές USB->Ethernet που να δουλεύουν σε Linux κλπ και θα επανέλθουμε.
Επίσης αν μπορεί να μπει PCI Riser και να πάρουν 2 NetGear PCI που χρησιμοποιούν DMA.
Ίσως είναι καιρός να ξεχάσουμε τα Pentium I και να πάμε σε πιο σοβαρές, δυνατές και αξιόπιστες λύσεις.
Αχιλλέα, πολύ ωραίο το hardware, αλλά κολλάω στο θέμα USB. Πολλά τα resources που θα απασχολούν οι USB συσκευές (καρατσεκαρισμένο και χιλιοειπωμένο) και το φοβάμαι το θέμα...
Τι λέτε;
pargyrak
07/10/2003, 17:05
Αχιλλέα, πολύ ωραίο το hardware, αλλά κολλάω στο θέμα USB. Πολλά τα resources που θα απασχολούν οι USB συσκευές (καρατσεκαρισμένο και χιλιοειπωμένο) και το φοβάμαι το θέμα...
Τι λέτε;
Θα συμφωνήσω μαζί σου. Ίσως θα είναι καλύτερα μια λύση με τετραπλές κάρτες δικτύου αλλά και σε δυνατότερα μηχανάκια. Το OSPF είναι αδηφάγο πρωτόκολλο.
Σκεφτείτε επίσης τη λύση ενός πραγματικού router (πχ Cisco). Το κόστος είναι μεγάλο βέβαια αλλά στο ebay έχει πολλές ευκαίρίες. Για παράδειγμα ένας 1720 με 3 ethernet, 48Mb Ram και 8 Flash μου βγήκε κάτω από 500 ευρώπουλα και πλήρωσα και δασμούς.
Λύσεις με περισσότερα interfaces βέβαια ξεφεύγουν αλλά ένας τέτοιος router που να συνδέει τα backbone links ενός κόμβου είναι συνήθως αρκετός. Εξάλλου πάντα υπάρχει και η δυνατότητα δεύτερης IP (και τρίτης και τέταρτης).
pargy@kosovo
LowRider
07/10/2003, 17:09
Θα ελένξουμε τις παραμέτρους κόστους, αν μπορούμε να βρούμε φτηνές USB->Ethernet που να δουλεύουν σε Linux κλπ και θα επανέλθουμε.
.
Αγόρασα ψιλοπρόσφατα μία USB 10/100 κάρτα δικτύου (δεν θυμάμαι μάρκα/chipset, είμαι στη δουλειά τώρα) νομίζω γύρω στα 30euro από το Multinet Στουρνάρη χωρίς ιδιαίτερο ψάξιμο. Εάν ενδιαφέρεστε την διαθέτω για δοκιμές και μπορώ να την δώσω σχεδόν άμεσα στον φίλο jabarlee.
Αχιλλέα, πολύ ωραίο το hardware, αλλά κολλάω στο θέμα USB. Πολλά τα resources που θα απασχολούν οι USB συσκευές (καρατσεκαρισμένο και χιλιοειπωμένο) και το φοβάμαι το θέμα...
Τι λέτε;
Θα δοκιμάσουμε και θα δούμε. 600Mhz είναι πολλά ;) Και η μνήμη δεν συγκρίνεται με Pentium ούτε σε μέγεθος, ούτε σε ταχύτητα.
Οι USB θα είναι λύσεις ανάγκης, όταν τα interfaces είναι πολλά (Το μηχάνημα μπορεί άνετα να έχει 2 On-board + 2 PCI Ethernet (3 Ifaces + LAN), ή 2 On-board Ethernet και 2 PCI Prism2.5 bus-mastering (3 Ifaces + LAN), ή ακόμα και 2πλές ή 4πλές Ethernet(>4 Interfaces + LAN). Και μια USB Ethernet σίγουρα δεν θα γονατίσει το μηχάνημα δουλεύοντας στα 5.5Mbit...
Χειρότερα από τις PCMCIA κάρτες που χρησιμοποιούμε τώρα αποκλείεται να είναι πάντως, στο εγγυώμαι ;)
pargyrak με 500e αγοράζεις 2 τέτοια μηχανήματα, με δυνατότερη CPU και περισσότερη μνήμη, θα δέχονται εσωτερικές ασύρματες κάρτες με ρυθμιζόμενη ισχύ και τιμή κοντά στα 50e (σε αντίθεση με τα εξωτερικά Cisco bridges που είναι δυσεύρετα και πανάκριβα) και θα έχεις και τη δυνατότητα να παίξεις και με εξωτερικές και με εσωτερικές συσκευές.
Τα Cisco είναι καταπληκτικά, αλλά δεν είναι cost effective. Και μιας και εμείς ψάχνουμε μια φτηνή, λειτουργική και με διαθεσιμότητα σε καινούργια εξαρτήματα λύση, δεν μπορούμε να τα χρησιμοποιήσουμε.
Ας μετακινήσει κάποιος τις δημοσιεύσεις σε νέα ενότητα...
Αν δουλέψουμε με μηδενικό Area 0? (Πχ 1 host) Αν βάλουμε όλους τους routers στο Area 0 ? Δενδρική δομή χωρίς ένα κεντρικό Area δεν μπορούμε να υλοποιήσουμε;
Αν δουλεψεις με αυτον τον τροπο, θα αναγκασεις ολους τους routers να κανουν υπολογισμους συνεχεια για ολα τα πιθανα routes και για ολα τα sybnets. Ειδικα αν λαβουμε υποψη οτι δεν υπαρχει IP Sumarization.
Σπαζοντας το δικτυο σε μικροτερα οι υπολογισμοι ειναι σαφως μικροτεροι και εφαρμοζοντας και ΙΡ Sum.. ακομα ποιο μικροι.
Τωρα αν προχωρησουμε σε υλοποιηση "ολοι στο area 0" και αντεξουν οι routers, για καθε link που θα αλλαζει state (up/down) θα γινεται flood σε ολο το δικτυο το status αυτου του links. Οποτε με τον ρυθμο που ανεβοκατεβαινουν τα links θα υπαρξει πολυ flood.
papashark
07/10/2003, 20:01
Τα Cisco είναι καταπληκτικά, αλλά δεν είναι cost effective. Και μιας και εμείς ψάχνουμε μια φτηνή, λειτουργική και με διαθεσιμότητα σε καινούργια εξαρτήματα λύση, δεν μπορούμε να τα χρησιμοποιήσουμε.
Για να μην ξαναρχίσουμε ατελείωτα flames μεταξύ cisco fans vs linux fan, θα μου επιτρέψεις να επαναδιατυπόσω την πρόταση σου λέγοντας τα cisco δεν είναι cost effective εάν έχεις ευχαίρεια σε linux
Μπορείτε να κάνετε δοκιμές προς το παρόν στα
10.19.140.254 kai 10.19.140.153(password awmn).
Στο πρώτο έχουμε :
ethernet 0 ----> Local Lan
ethernet 1 ----> AP
ethernet 2 ----> gw to awmn
ethernet 3 ----> back2back με τον άλλο router (10.19.142.254)
Στο δευτερο :
ethernet 0 ----> Local Lan
ethernet 1 ----> back2back με τον άλλο router (10.19.142.253)
Και τα 2 έχουν IP/PLUS τουλάχιστον IOS.
Στο δευτερο αλλαξτε του τα φωτα και αμα με πετύχετε στο irc το κανω reload.Σε 2 βδομάδες περίπου θα υπάρχει άλλος ενας με 6 ethernet οπότε θα έχουμε πιο πολλες επιλογές και 2 serials connections.
Alexandros
07/10/2003, 20:51
Αν κάποιος επιλέξει (και προσωπική εκτίμηση δεν νομίζω ότι αυτό αφορά πάνω από 5-10% τών κόμβων) να βάλει cisco με τα πολλά καλά τους αλλά και τους περιορισμούς που αναφέρει ο Αχιλλέας, η πιο cost effective λύση είναι μεταχειρισμένα.
Routers κατηγορίας 4500/4700 με 4 ethernet μπορούν να αγοραστούν με 150-250 USD και πιστέψτε με αξίζουν τα λεφτά τους. Πριν λίγα χρόνια έκαναν πάνω από 10.000 USD και η απόδοσή τους αρκεί και με το παραπάνω για 3-4 Ethernet Interfaces, πράγμα που δεν ισχύει για τους περισσότερους δρομολογητές της κατηγορίας 1700.
Κάνουν θόρυβο όμως (fan overengineering :D) και αν εκεί που τους βάζετε αυτό ενοχλεί ακολουθείστε τη μέθοδο του DiGi και αλλάξτε ανεμιστήρες.
Αλέξανδρος
Αν κάποιος επιλέξει (και προσωπική εκτίμηση δεν νομίζω ότι αυτό αφορά πάνω από 5-10% τών κόμβων) να βάλει cisco με τα πολλά καλά τους αλλά και τους περιορισμούς που αναφέρει ο Αχιλλέας, η πιο cost effective λύση είναι μεταχειρισμένα.
Routers κατηγορίας 4500/4700 με 4 ethernet μπορούν να αγοραστούν με 150-250 USD και πιστέψτε με αξίζουν τα λεφτά τους. Πριν λίγα χρόνια έκαναν πάνω από 10.000 USD και η απόδοσή τους αρκεί και με το παραπάνω για 3-4 Ethernet Interfaces, πράγμα που δεν ισχύει για τους περισσότερους δρομολογητές της κατηγορίας 1700.
Κάνουν θόρυβο όμως (fan overengineering :D) και αν εκεί που τους βάζετε αυτό ενοχλεί ακολουθείστε τη μέθοδο του DiGi και αλλάξτε ανεμιστήρες.
Αλέξανδρος
Συμφωνώ απολύτως με τον Αλέξανδρο. Αν έχετε μόνο εξωτερικά interfaces και μπορείτε να βρείτε κάποιον μεταχειρισμένο Cisco router, χρησιμοποιήστε τον.
Το project που θέλουμε να φτιάξουμε εμείς όμως θέλουμε να είναι χαμηλής τιμής με off the shelf μηχανήματα, δυνατότητα για εσωτερικά interfaces, χαμηλή κατανάλωση, σχετικά αθόρυβη λειτουργία, δυνατότητα τροφοδοσίας με DC, δυνατότητα λειτουργίας σε ταράτσα, και τα μεταχειρισμένα Cisco δεν εμπίπτουν στις κατηγορίες off the shelf και εσωτερικά interfaces.
Αν δουλέψουμε με μηδενικό Area 0? (Πχ 1 host) Αν βάλουμε όλους τους routers στο Area 0 ? Δενδρική δομή χωρίς ένα κεντρικό Area δεν μπορούμε να υλοποιήσουμε;
Αν δουλεψεις με αυτον τον τροπο, θα αναγκασεις ολους τους routers να κανουν υπολογισμους συνεχεια για ολα τα πιθανα routes και για ολα τα sybnets. Ειδικα αν λαβουμε υποψη οτι δεν υπαρχει IP Sumarization.
Σπαζοντας το δικτυο σε μικροτερα οι υπολογισμοι ειναι σαφως μικροτεροι και εφαρμοζοντας και ΙΡ Sum.. ακομα ποιο μικροι.
Τωρα αν προχωρησουμε σε υλοποιηση "ολοι στο area 0" και αντεξουν οι routers, για καθε link που θα αλλαζει state (up/down) θα γινεται flood σε ολο το δικτυο το status αυτου του links. Οποτε με τον ρυθμο που ανεβοκατεβαινουν τα links θα υπαρξει πολυ flood.
Διαβάζοντας συνεχώς τα μηνύματα, μου καρφώθηκε μια σκέψη στο μυαλό που είναι και πάρα πολύ απλή, αλλά και τελικά θα τσεκαριστεί στο test-lab.
Το OSPF θα κάνει summarization εκεί που μπορεί και όπως μπορεί. Αλλα και να μη γινότανε, μιλάμε ότι τουλάχιστον σε επίπεδο C-class θα γινόταν το summary μια χαρά.
Οπότε, έχουμε 255^2 routes για υπολογισμό. Σιγά τα αυγά βρε παιδιά. Δεν είναι δα και τόσο τρομερό. Και για την ακρίβεια δεν είναι καν 255^2 μιας και το AWMN δεν έχει όλο το 10άρι για ίδια χρήση...
Άρα, έχουμε και λέμε...
Flood δεν θα γίνεται τόσο πολύ όσο με το Rip (σαφώς βέβαια θα μπορούσε να μειωθεί δραματικά με τη σωστή χρήση ζωνών)
Το θέμα είναι ΠΩΣ θα χωρίσουμε τις συνδέσεις μας σε ζώνες;
Και ας πούμε πως καταφέρνουμε και φέρνουμε εις πέρας το "γιγάντιο" (και δεν αστειεύομαι) αυτό έργο.
Με κάθε αλλαγή link (δηλ, πιάνω άλλον καλύτερα, στρέφω αλλού την κεραία μου) οι ζώνες θα είναι λάθος σε χρόνο ημερών...
Τι γίνεται τότε; Ποιος θα κάνει ξανά το σχεδιασμό και κατά πόσο θα είναι εφικτό να πραγματοποιηθεί άμεσα για να μην υπάρχει downtime;
Έχεις κάτι να προτείνεις γι αυτό reno; Γιατί αυτός είναι ο πονοκέφαλός μου τους τελευταίους 3 μήνες που ειπώθηκε για πρώτη φορά το OSPF σοβαρά στο forum.
Και ας πούμε πως καταφέρνουμε και φέρνουμε εις πέρας το "γιγάντιο" (και δεν αστειεύομαι) αυτό έργο.
Με κάθε αλλαγή link (δηλ, πιάνω άλλον καλύτερα, στρέφω αλλού την κεραία μου) οι ζώνες θα είναι λάθος σε χρόνο ημερών...
Τι γίνεται τότε; Ποιος θα κάνει ξανά το σχεδιασμό και κατά πόσο θα είναι εφικτό να πραγματοποιηθεί άμεσα για να μην υπάρχει downtime;
Εγώ το προσλαμβάνω σαν να επιχειρούμε να εφαρμόσουμε αρχές μέσων σταθερής τροχιάς (τραμ, μετρό, σιδηρόδρομος) με παπάκια.
Το OSPF θα κάνει summarization εκεί που μπορεί και όπως μπορεί. Αλλα και να μη γινότανε, μιλάμε ότι τουλάχιστον σε επίπεδο C-class θα γινόταν το summary μια χαρά.
Δεν είμαι και τόσο σίγουρος. Αν κάποιος έχει κομμάτια από ένα Class-C που κάνει broadcast, δεν θα κάνει summary το OSPF, γιατί μπορεί το κομμάτι που είναι κενό στο Class-C να χρησιμοποιείται οπουδήποτε αλλού.
Εκτός αν υπάρχει τρόπος να του πούμε ότι το 10.x δεν το έχει κανείς άλλος, και αν δεν ζητάει κάποιος explicitly κάποιο subnet, μπορεί να το στείλει όπου το βολεύει.
Παράδειγμα: Έχουμε το 10.0.0.0/8 network, και τα μοναδικά subnets είναι από 10.0.0.0/24 μέχρι 10.0.255.0/24. Όταν το OSPF κάνει summary, θα στείλει σε κάποιον στο 192.168.0.1 σαν summary το 10.0.0.0/8 ή το 10.0.0.0/16 ? Αν στείλει το δεύτερο, τότε δεν πρόκειται να κάνουμε summarization της προκοπής αν δεν αλλάζουμε όλοι IPs (και πάλι, όταν αλλάζουν τα links, θα πρέπει να ξαναλάζουμε για να τα κάνουμε γειτονικά)
Οπότε, έχουμε 255^2 routes για υπολογισμό. Σιγά τα αυγά βρε παιδιά. Δεν είναι δα και τόσο τρομερό. Και για την ακρίβεια δεν είναι καν 255^2 μιας και το AWMN δεν έχει όλο το 10άρι για ίδια χρήση...
Κάθε κεντρικός κόμβος έχει: 1 subnet για το lan, 1 για το AP (αν υπάρχει), 1 για κάθε κατευθυντικό (αυτά μετριούνται διπλά οπότε πρέπει να διαιρέσουμε το σύνολο δια 2).
Κάθε πελάτης με subnet έχει επίσης 1 subnet για το LAN του.
Επομένως, για x κόμβους δικτύου με y interfaces ο καθένας (AP + κατευθυντικά) και z πελάτες συνολικά, έχουμε:
x * (1+y/2) + z
Για y πεπερασμένο (κανένας δε θα στήσει πάνω απο 4-5 ifaces) έχουμε γραμμική πολυπλοκότητα στον αλγόριθμο αύξησης των hosts.
Αριθμητικό παράδειγμα: Για 500 κόμβους, 2000 πελάτες με subnet και μέσο όρο 3if άνα κόμβο, έχουμε 3250 routes
Εσείς θα μου πείτε αν είναι πολλά ή λίγα για χρήση σε ένα Area και πόσο υπολογιστική ισχύ - μνήμη χρειάζεται ένα μηχάνημα για να τα υπολογίζει σε εύλογο χρονικό διάστημα.
Μπορούμε να μειώσουμε το παραπάνω, αν ξεχάσουμε τα connected routes και κάνει ο καθένας broadcast το Class-C του. Τότε θα πρέπει να λύσουμε το πρόβλημα των πελατών και πως θα μιλήσουν με τον κόμβο που τους εξυπηρετεί (μπορούν αυτοί να στέλνουν το μικρότερό τους subnet στον κόμβο τους και μετά να χάνεται λόγω του summarization, ή να τους θεωρήσουμε ξεχωριστό Area για κάθε AP, αφού έτσι και αλλιώς δεν θα έχουν σύνδεση από αλλού) και με τα subnets των backbone links (Αλλά μάλλον δεν μας ενδιαφέρει και τόσο αν χάθηκε το backbone subnet κάποιου που χρησιμοποιεί address space από τον απέναντι, αφού έτσι και αλλιώς δεν θα βλέπει τον απέναντι για να το χρησιμοποιήσουμε)
Δεν λαμβάνουμε υπόψιν μας τη διασύνδεση με άλλα WNs, καθώς αφού έχουμε καθορίσει τις IPs που δίνονται στο κάθε WN, μπορούμε να τις κάνουμε summary με το χέρι και να χρησιμοποιήσουμε στατικά entries στους border routers που θα τα κάνουν broadcast στο υπόλοιπο δίκτυο.
paravoid
08/10/2003, 00:37
...
Έχεις κάτι να προτείνεις γι αυτό reno; Γιατί αυτός είναι ο πονοκέφαλός μου τους τελευταίους 3 μήνες που ειπώθηκε για πρώτη φορά το OSPF σοβαρά στο forum.
Από όσο το είχαμε συζητήσει στο IRC με το Ρένο το θέμα:
Οι IPs στους Δήμους είναι summarized. Αφού η σχεδίαση του OSPF απαιτεί δομή μαργαρίτας και δεν υπάρχει ένας δήμος που να συνορεύει με όλους, η λύση στο πρόβλημα είναι η δημιουργία ενός Area 0 για το backbone (το οποίο θα πρέπει να συγκεκριμενοποιηθεί).
Σημ: Οι γνώσεις μου στο OSPF είναι μηδαμινές :oops:
Από όσο το είχαμε συζητήσει στο IRC με το Ρένο το θέμα:
Οι IPs στους Δήμους είναι summarized. Αφού η σχεδίαση του OSPF απαιτεί δομή μαργαρίτας και δεν υπάρχει ένας δήμος που να συνορεύει με όλους, η λύση στο πρόβλημα είναι η δημιουργία ενός Area 0 για το backbone (το οποίο θα πρέπει να συγκεκριμενοποιηθεί).
Σημ: Οι γνώσεις μου στο OSPF είναι μηδαμινές :oops:
Οι δήμοι δεν έχουν σχέση με το network pattern μας. Υπάρχουν συνδέσεις που μετακινούνται από τον ένα δήμο στον άλλο και πάλι πίσω, πχ η σύνδεση dti-jabarlee (Ν Ιωνία) που γινόταν μέχρι σήμερα μέσω Αλέξανδρου (Καματερό)
paravoid
08/10/2003, 01:12
Από όσο το είχαμε συζητήσει στο IRC με το Ρένο το θέμα:
Οι IPs στους Δήμους είναι summarized. Αφού η σχεδίαση του OSPF απαιτεί δομή μαργαρίτας και δεν υπάρχει ένας δήμος που να συνορεύει με όλους, η λύση στο πρόβλημα είναι η δημιουργία ενός Area 0 για το backbone (το οποίο θα πρέπει να συγκεκριμενοποιηθεί).
Σημ: Οι γνώσεις μου στο OSPF είναι μηδαμινές :oops:
Οι δήμοι δεν έχουν σχέση με το network pattern μας. Υπάρχουν συνδέσεις που μετακινούνται από τον ένα δήμο στον άλλο και πάλι πίσω, πχ η σύνδεση dti-jabarlee (Ν Ιωνία) που γινόταν μέχρι σήμερα μέσω Αλέξανδρου (Καματερό)
Ακριβώς για αυτό είπαμε για δημιουργία ενός εικονικού Area 0 που θα "συνορεύει" με όλους τους Δημούς και στο οποίο θα δοθούν διαφορετικές IPs.
Μάλλον θα μιλούσατε για διαφορετικά πράγματα στο IRC.
Τι πάει να πει εικονικό area 0; Δεν υπάρχει εικονικό area. Μόνο εικονικά links μεταξύ των routers που δεν μιλάνε απευθείας μεταξύ τους.
Και βασικά είναι 0.0.0.0, το ξαναλέω...
Δεν υπάρχει (μπορεί, αλλά δε σημαίνει ότι είναι και σωστό) area με 1 αριθμό.
Τα areas ονομάζονται όπως και οι IPs (δηλαδή έχουν το ίδιο στυλ, δεν είναι απαραίτητο τα areas να είναι ίδια με τις IPs τους, αν και είναι σύνηθες φαινόμενο για προφανείς λόγους).
Για να καταλάβουμε όλοι πως δουλέυει το OSPF με διάφορα areas συν το Backbone area (0.0.0.0).
Θυμάστε όλοι το σχεδιαγραμματάκι με την τοπολογία πολλών APs στον ίδιο χώρο διαταγμένα με τέτοιο τρόπο ώστε να μην αλληλοκαλύπτονται τα κανάλια; Ε, φανταστείτε το ίδιο πράγμα με τα areas. Κάθε area είναι και ένας κύκλος, με το backbone area να είναι ο κεντρικός. Πρέπει κάθε περιμετρικός κύκλος να εφάπτεται με το backbone. Τι σημαίνει αυτό;
Αυτό σημαίνει πως τουλάχιστον ένας router από κάθε ζώνη πρέπει να είναι και στην backbone area (0.0.0.0)
Αυτό όμως ταυτόχρονα σημαίνει και πως μπορεί να μιλήσει απευθείας και με άλλο router που να είναι και αυτός στη ζώνη backbone κοκ.
Με λίγα λόγια, οι routers που μιλάνε στη ζώνη backbone πρέπει να μιλάνε "άμεσα" και μεταξύ τους (σειριακά με PtP ή PtMP τοπολογία). Πάντως πρέπει να υπάρχει "λογική" συνέχεια στην επικοινωνία τους.
Σημειώστε τη λέξη "λογική" που ανέφερα. Αν δεν είναι εφικτή η φυσική συνέχεια, μπορούν να δημιουργηθούν "εικονικές συνδέσεις" με router της backbone που δεν υπάρχει άμεση επαφή και να γεφυρωθεί το χάσμα.
Αυτό όμως δημιουργεί διάφορα πρόσθετα προβλήματα στον ήδη πολύπλοκο τρόπο που λειτουργεί το OSPF και ίσως να μην είμαστε σε θέση να τα αντιμετωπίσουμε αν χρειαστεί.
Επίσης να επαναλάβω και το θέμα της μη σταθερότητας των συνδέσεών μας.
Άρα, καλή η χρήση multi-zoned OSPF, αλλά δεν κάνει για εμάς.
Ή πάμε στο OSPF σαν μια ζώνη, ή φτιάχνουμε σταθερά και αμετακίνητα links τα οποία θα μιλάνε απευθείας μεταξύ τους, θα κάνουν τον κύκλο της Αθήνας και πάνω τους θα μπορούν να πέσουν άλλοι routers όπου ο καθένας τους θα κουβαλάει και μια ζώνη.
Καλως ή κακως το OSPF απαιτει τα μαλιοκεφαλα του! Επιπλεον ειναι πολυ εκδικητικο οταν ΔΕΝ σχεδιασεις το δικτυο σου με το OSPF στο μυαλο.
Θα μπορουσαμε για αρχη να υλοποιησουμε OSPF σε ορισμενους (ναι, καλα ακουσατε - θα το χρησιμοποιησουμε σαν BGP) routers οι οποιοι εχουν πανω απο 2 ΒΒ Links (δεν πιανονται τα ΑΡ). Θα βρουμε μεσα απο την υπαρχουσα διαδρομη τις πιθανες διαδρομες που μπορει να ακολουθησει ενα πακετο και θα συμπεριλαβουμε τους δρομολογητες που περναει μεσα στο Area 0.
Το ζητουμενο ειναι:
α) να εκμεταλευομαστε την καλυτερη διαδρομη - Αυτην την στιγμη δρομολογητες που θα επρεπε να αποφασισουν το καλυτερο μονοπατι για τα πακετα δεν εχουν ιδεα και το στελνουν σε αυτο με τα λιγοτερα hops.
β) να γινει bandwidth balancing στα links - Επισης οι δρομολογητες που θα επρεπε να το κανουν αυτο δεν εχουν ιδεα...
Εν ολιγοις, υπαρχουν καποιοι δρομολογητες που θα μπορουσαν να δρομολογησουν διαφορετικα τα πακετα αν ειχαν αλλα κριτηρια. Σε αυτους δοκιμαστικα μπορουμε να εφαρμοσουμε OSPF και να τους βαλουμε στο ιδιο area.
Βλεπουμε πως παιζει και κινουμαστε αναλογως.
chatasos
10/10/2003, 17:03
Έχετε σκεφτεί να φτιάξετε διαφορετικά OSPF proccesses ανά "περιοχή", το καθένα με το δικό του backbone area και να τα ενώσετε μετά όλα μαζί με BGP?
Βρε παιδιά...
Ωραία όλα αυτά που λέμε. Και το BGP καλό είναι (θα ήθελα κάποιος να μου πει αν υπάρχει υποστήριξη στο Zebra ή γενικότερα στο Linux), και το OSPF καλό είναι να χωριστεί σε ζώνες...
Το Administration όλων αυτών, μπορεί να μου πει ποιος θα το κάνει;
Εννοώ, ποιος θα είναι υπεύθυνος όταν για κάποιο λόγο κάτι πάει στραβά; Ποιος θα τα φτιάχνει όλα αυτά;
Εκτός αν νομίζουμε ότι όλοι μας είμαστε στο ίδιο επίπεδο γνώσεων, ειδικά στο κομμάτι routing...
Ας προσγειωθούμε λιγάκι στην πραγματικότητα.
Και δεν είναι μόνο αυτό...
Τι resources χρειάζονται για OSPF και BGP μαζί;
Και ποιος θα έχει το BGP; Γιατί πάλι ερχόμαστε στο πρόβλημα σχεδιασμού...
Νομίζω πως δεν είναι τυχαίο το γεγονός ότι και σε άλλα Wireless networks όταν στήσαν OSPF, όλοι οι routers στήθηκαν σαν ASBR.
Πρόβλημα δομής, ιεράρχησης, σχεδιασμού, administration, maintenance κλπ κλπ.
chatasos
10/10/2003, 18:13
Πάντως το Zebra υποστηρίζει BGP και θα μπορούσαν να το τρέχουν μόνο οι πολύ κεντρικοί κόμβοι. Εφόσον έχουν και αρκετή μνήμη.
Πάντως μπορούμε να συμφωνήσουμε στο ότι τα κύρια bb-links δεν αλλάζουν κάθε μέρα... οπότε μπορεί να αρχίσει κάποια α σχεδίαση. Παράλληλα υπάρχουν πολύ συγκεκριμένα σημεία που το OSPF είναι χρήσιμο (σε άλλα η λύση είναι μονόδρομος). Οπότε ας ξεκινήσουμε με τη χαρτογράφηση του δικτύου να δούμε που έχουμε πρόβλημα με το RIP και μετά αποφασίζουμε τι θα κάνουμε με το OSPF
Θα διαφωνήσω με τον capvar.
Το θέμα δεν είναι σε πόσο τακτά χρονικά διαστήματα αλλάζουν τα BB Links, αλλά ότι αλλάζουν.
Και να σου πω και κάτι; Το ότι αλλάζουν δεν θα ήταν πρόβλημα αν ήξερα ότι στο 100% το χρόνου μου (και άλλων που μπορούν και γνωρίζουν) θα ασχολιόμασταν με το administration του δικτύου, κάτι που φυσικά δε γίνεται.
Άρα, όταν μιλάμε για σχεδιασμό, πολύ φοβάμαι πως όλες οι προσπάθειες και ο κόπος θα πάει στράφι, μιας και μέσα σε μια νύχτα θα μπορούσαν όλα να αλλάξουν (αυτό άλλωστε δεν έλεγε και ο Νικος-Mauve και τον πήραμε στο κυνήγι; ή κάνω λάθος;)
Νομίζω πως αρχίζουμε να βλέπουμε ότι η απόλυτη ελευθερία χωρίς κεντρικό συντονισμό και διαχείριση έχει και τα αρνητικά του, σωστά; :wink:
Απλά θέλω να τονίσω το γεγονός ότι ελλείψη κεντρικής διαχείρισης, συντονισμού, ομάδας δικτυακής υποστήριξης κλπ, δεν είναι δυνατό να χρησιμοποιήσουμε το OSPF με άλλες ζώνες εκτός από τη backbone.
Αφού μπορεί να δουλέψει έτσι, που κολλάμε; Στο ότι πρέπει να βάλουμε ισχυρότερα μηχανάκια στην ταράτσα; Ούτως ή άλλως, η ουτοπία των 486 κάποτε θα πέρναγε στο παρελθόν σαν μια καλή εμπειρία και θα προχωρούσαμε σε άλλες εφαρμογές.
Αν θέλουμε OSPF, θέλουμε και μηχανήματα να ανταποκριθούν.
Σε αυτό το σημείο να θυμίσω και την πολύ καλή πρόταση του Alexandrou (το έχω συζητήσει και με τον DiGi) για dedicated Cisco Router (45xx-47xx) με πολύ καλή τιμή, αποδέσμευση από τα PCάκια και μικρότερο κόστος ιδιοκτησίας (βλ ρεύμα, θόρυβο, ζημιές από μηχανικά μέρη κλπ)
Το μόνο μειωνέκτημα είναι ότι θέλει εξωτερικά interfaces για να δουλέψει ή μια μικρή σπατάλη στις IPs για να γίνεται gateway (αυτό θέλει μάλλον πειραματισμό) για το linux, να κάνει το routing και να το στέλνει πίσω στο linux στην κατάλληλη καρτούλα... Μπέρδεμα, αλλά ας το εξετάσουμε κι αυτό.
Σε αυτό το σημείο να θυμίσω και την πολύ καλή πρόταση του Alexandrou (το έχω συζητήσει και με τον DiGi) για dedicated Cisco Router (45xx-47xx) με πολύ καλή τιμή, αποδέσμευση από τα PCάκια και μικρότερο κόστος ιδιοκτησίας (βλ ρεύμα, θόρυβο, ζημιές από μηχανικά μέρη κλπ)
.
Πέστα Χρισόστομε
Αλλη μια φορα το γνωστο λινκ...
Κανενα σχολιο για το τροπο που χρησιμοποιει OSPF το SOWN?
Η τοπολογια του WLAN δεν διαφερει και πολυ απο τα γνωστα -
http://www.sown.org.uk/index.php/Topology
αλλα η λυση φαινεται να ειναι πολυ απλη
http://www.sown.org.uk/index.php/Routing
Ο ευκολος(?) τροπος ειναι να μεταφερουμε οτι ξερουμε απο τα ενσυρματα δικτυα στα ασυρματα (μαζι με Cisco routers και ολα τα παρελκομενα) ---αλλα ας γινει και μια συζητηση για εναλλακτικες λυσεις
και μερικα ακομα που ισως ειναι διαφωτιστικα...
------------------------------------------
"...The routing only changes when you add/remove a node from the mesh, so there might be a slight blip then - I've not really tested too much.
I don't expect it should be too much of an issue.
The mobility itself doesn't rely on routing updates though, to try and
clarify it works roughly like this:
Each client has its own /30 network, this is taken out of the address
space of the home node (where the client first connected).
When the client migrates to a different access point (which has a
different subnet) this is detected and the new access point will act as
the clients gateway, it sends a few arp "is-at" messages to update the
clients arp table.
An IP in IP tunnel is also setup from the new access point to the original
one. Outgoing packets are routed as normally but the routing on the
mesh means that reply packets will go back to the original access point.
This knows the client has migrated and so routes these packets to the
current AP via the tunnel.
So whilst it's not exactly a clean solution what with asymmetric routing
etc we think it's the best way whilst avoiding other nasties .."
------------------------------------
SDD, η πρόταση για Backbone zone only που έκανα σε προηγούμενο post μου, και η αναφορά μου ότι και άλλα Wireless communities το έχουν υλοποιήσει έτσι, αναφέρεται στο SOWN.
Οπότε, επανερχόμαστε στα λεγόμενά μου, σωστά;
Σε αυτό το σημείο να θυμίσω και την πολύ καλή πρόταση του Alexandrou (το έχω συζητήσει και με τον DiGi) για dedicated Cisco Router (45xx-47xx) με πολύ καλή τιμή, αποδέσμευση από τα PCάκια και μικρότερο κόστος ιδιοκτησίας (βλ ρεύμα, θόρυβο, ζημιές από μηχανικά μέρη κλπ)
.
Πέστα Χρισόστομε
Μήπως είναι επιτακτική η ανάγκη να αλλάξω nickname; :lol: :lol: :lol:
:D Θα ήθελα και εγώ να διαφωνήσω με τον εαυτό μου αλλά... δε γίνεται :D
Τα BB Links είπα δεν αλλάζουν συχνά, δηλαδή μπορεί να δουλεύουν για 1 μήνα για 6 κλπ
Οπότε σχεδιάζοντας το routing με διάρκεια ζωής 1 μήνα ή 6 μήνες δεν έχει νόημα..... Επίσης αν κάποιος αποφασίσει πχ ότι το συγκεκριμένο link θα το κατεβάσει (δικαιωμά του είναι) εμείς θα πρέπει να σχεδάσουμε τα πάντα από την αρχή...
Μακάρι να είχαμε καλώδια και να ξέραμε ότι δεν χαλάνε με τον αέρα ή να ξέραμε ότι τα links θα δουλεύαν για πάντα ώστε τα πάντα να δουλεύαν τέλεια, αλλά δε γίνεται...
Αυτό που πρέπει να σχεδιάσουμε είναι κάτι ευέλικτο πάνω απ' όλα γιατί απλά δεν έχει νόημα να πέφτει ένα κομματάκι και να καταρρέει το routing σε μια περιοχή ή σε όλο το δίκτυο... Το rip αυτό το πετυχαίνει... και στο κάτω κάτω ίσως υπάρχει και άλλη λύση εκτός του OSPF... Δε μπορούμε να αναζητούμε λύσεις όταν δεν έχουμε βρει και αναλύσει τα προβλήματα σε πραγματικές συνθήκες...
Καθομαι και σκεφτομαι αν αξιζει να χρησιμοποιησουμε καποιο αλλο προτοκολο για την δρομολογηση στο AWMN. Σε αυτο το link http://en.wikipedia.org/wiki/Ad_hoc_protocol_list θα δειτε και εσεις οτι υπαρχει μια πληθωρα εναλλακτικων προτοκολων για δυναμικη δρομολογηση, δρομολογηση on-demand και εχουν ολα να κανουν με τοπολογια mesh οπως ακριβως στο AWMN.
Απο την μια ισως καταφερουμε να εκμεταλλευτουμε καλυτερα τα links με ενα αλλο προτοκολο απο την αλλη ομως ισως απλα χασουμε τον χρονο μας.
Το θεμα ειναι οτι το Rip μπορει να ειναι dynamic αλλα δεν ειναι εξυπνο αρκετα. Ισως να μπορεσουμε να περιορισουμε τον αριθμο των subnets και να μειωσουμε τους timers. Ισως να καταφερουμε να μπλοκαρουμε ορισμενες διαδρομες με την χρηση route maps αλλα δεν θα μπορεσουμε ποτε να καταφαερουμε αυτο που θα εκανε ενα προτοκολο σαν το OSPF που ελεγχει την ποιοτητα των links.
chatasos
13/10/2003, 14:15
Μήπως έχετε κάπου καταγεγραμμένα τα προβλήματα του αντιμετωπίζετε με την υλοποίηση του OSPF μέχρι τώρα?
chataso, δεν εχουμε περασει ακομα σε υλοποιηση ωστε να εχουν βγει προβληματα. Υπαρχουν ομως θεματα τα οποια τα γνωριζουμε ηδη και εμποδιζουν την ευκολη μεταβαση απο Rip σε OSPF.
Σου αναφερω επιγραμματικα οτι δεν υπαρχει IP sumarization και το -πιθανο- Area 0 δεν εχει τα πλεον σταθερα και γρηγορα links για να ανταπεξελθει στις απαιτησεις.
chatasos
13/10/2003, 14:35
Summarization γιατί δεν υπάρχει?
Νομίζω ότι μπορείτε πολύ εύκολα να βάλετε όλα τα δίκτυα, και από εκεί και πέρα να αφήσετε το most specific route ανάλογα με το prefix length (subnet mask) να κάνει την δουλειά του.
Επίσης μπορείτε να χρησιμοποιήσετε και το NSSA option του OSPF (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1587.html) αν θέλετε να γλυτώσετε αρκετά routes (=μνήμη/cpu/κλπ.), αρκεί να το υποστηρίζει το zebra.
Ρίχτε και μια ματιά σε αυτό: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1793.html
Δεν υπαρχει. Τα ΙΡ εχουν μοιραστει αναλογα τον δημο που ανηκει καποιος και οχι τις συνδεσεις.
Τι εννοεις να βαλουμε ολα τα δικτυα? Ολα στο "0"? Εχεις ιδεα τι θα γινει αν αρχισουν 2-3 ασταθη links να ανεβοκατεβαινουν? Το OSPF κανει flood για το propagation.
Δεν υπαρχει. Τα ΙΡ εχουν μοιραστει αναλογα τον δημο που ανηκει καποιος και οχι τις συνδεσεις.
Διεγράφη το μήνυμα σύμφωνα με εκφρασθείσα επιθυμία του χρήστη Jason. MAuVE
Alexandros
13/10/2003, 14:58
[Διεγράφη μια και το post-αιτία για την αντίδρασή μου τροποποιήθηκε]
Αλέξανδρος
chatasos
13/10/2003, 15:01
Δεν υπαρχει. Τα ΙΡ εχουν μοιραστει αναλογα τον δημο που ανηκει καποιος και οχι τις συνδεσεις.
Τι εννοεις να βαλουμε ολα τα δικτυα? Ολα στο "0"? Εχεις ιδεα τι θα γινει αν αρχισουν 2-3 ασταθη links να ανεβοκατεβαινουν? Το OSPF κανει flood για το propagation.
Δεν μπορείτε να κάνετε summarization ανά δήμο?
Για το όλα τα δίκτυα, αναφέρομαι να τα βάλετε όλα στα summarization.
Εννοείται πως δεν πρέπει να τα βάλετε στο area 0!!!
Πάντως για το flooding, υπάρχουν και timers που μπορείτε να τους ρυθμίσετε σε μεγάλες τιμές όπου έχετε προβλήματα up/down για να γλυτώνετε το συνεχές flooding.
Οπα ρε συ, τι sumarization να δημο? Αντε και στις εντος δημου συνδεσεις κατι κανεις, για αυτες που ειναι διαδημοτικες τι κανεις?
Αλλαζεις τους timers αλλα η 2η μαγκια του OSPF ειναι το γρηγορο propagation που κανει.
chatasos
13/10/2003, 15:49
Οπα ρε συ, τι sumarization να δημο? Αντε και στις εντος δημου συνδεσεις κατι κανεις, για αυτες που ειναι διαδημοτικες τι κανεις?
Μπορείς να το εξηγήσεις λίγο καλύτερα αυτό?
Αλλαζεις τους timers αλλα η 2η μαγκια του OSPF ειναι το γρηγορο propagation που κανει.
Εκεί πρέπει να βρείτε την χρυσή τομή.
Εγώ πάντως υποθέτω πως αν κάποιο link έχει συνεχή προβλήματα, δεν θα βλάψει κάποιον αν μείνει εκτός routing για λίγα λεπτά. Επίσης υποθέτω πως τα bb links δεν θα ανήκουν σε αυτή την κατηγορία.
Εκτός αν έχετε τα super-duper μηχανήματα και το mega-bandwidth οπότε δεν σας απασχολεί κάτι τέτοιο..
Για τα διαδημοτικα links παραδειγμα:
Εσυ εισαι περιστερι εγω Αιγαλεω. Κανουμε BB link μεταξυ μας. Για τα BB Interfaces χρησιμοποιουμε καποιο subnet υστερα απο συννενοηση. Eσυ εισαι Περιστερι και χρησιμοποιεις το 10.12.100.0/24 για το δικο σου subnet το οποιο σπας σε subnets για να το μοιρασεις σε AP, LAN, κτλ. Εγω επειδη ειμαι Αιγαλεω χρησιμοποιω το 10.50.20.0/24.
Καταλαβες τι γινεται?
chatasos
13/10/2003, 16:34
Για τα διαδημοτικα links παραδειγμα:
Εσυ εισαι περιστερι εγω Αιγαλεω. Κανουμε BB link μεταξυ μας. Για τα BB Interfaces χρησιμοποιουμε καποιο subnet υστερα απο συννενοηση. Eσυ εισαι Περιστερι και χρησιμοποιεις το 10.12.100.0/24 για το δικο σου subnet το οποιο σπας σε subnets για να το μοιρασεις σε AP, LAN, κτλ. Εγω επειδη ειμαι Αιγαλεω χρησιμοποιω το 10.50.20.0/24.
Καταλαβες τι γινεται?
Για αρχή (εφόσον είσαστε λίγοι) μπορεί να ανακοινώνει ο καθένας το δικό του δίκτυο.
Αργότερα (αφού μαζευτούν πολλά class c) ανακοινώνεις και του "διπλανού" σου και το αντίστροφο.
Όσοι έχουν Linux box κοιτάξτε λιίγο το iproute2
http://lartc.org/howto/lartc.rpdb.multiple-links.html
rikste mia matia s'auto.
http://moment.cs.ucsb.edu/AODV/aodv.html
Diabazontas ta sxetika papers to brisko too good to be true.
Alla opos kai ola ta protokola i theoria apexei poli apo tin ilopoiisi.
Edo sto swn, milontas kai dokimazontas efarmoges tou ospf gia parapano apo ena xrono (isos thimounte kapoioi tin istoriki sinantisi stin aerolesxi me tin protasi mas gia ospf.), kataligoume sto oti gia mikro arithmo links to ospf leitourgei poli kala. Poli fobame omos oti den isxiei to idio gia ena megalo mesh. (edit: koitaksa auto to sown pou anaferthike, einai akribos i periptosi pou anafero. 6 nodes online...)
Auti ti stigmi koitao ligo kai tin theoritiki iloipoiisi tou aodv kai ta ofelei pou mporei na kribei auto.
na me sigxorate alla den eixa to kouragio na diabaso olo to thread. molis tora to anakalipsa.
harisis
p.s. erotisi... dynamic routing kanete kai stous pelates ton ap?
rikste mia matia s'auto.
p.s. erotisi... dynamic routing kanete kai stous pelates ton ap?
Ναι, για λόγους ευκολίας και αποφυγή λαθών (όσοι έχουν βάλει static routes, τα έχουν βάλει λάθος...). Επίσης υπάρχουν συνδέσεις backbone που βγαίνουν σαν πελάτες σε AP από την μια πλευρά (οι περισσότερες μετατρέπονται σε point to point όταν σταθεροποιηθούν).
http://moment.cs.ucsb.edu/AODV/aodv.html
Diabazontas ta sxetika papers to brisko too good to be true.
Alla opos kai ola ta protokola i theoria apexei poli apo tin ilopoiisi.
Το αντικειμενο ειναι αρκετα γνωστο σε οσους ασχολουνται με adhoc P2P δικτυα, ενσυρματα και ασυρματα - o αλγοριθμος (Linux) χρησιμοποιειται σε αρκετες υπαρχουσες εφαρμογες
Μιλαμε για δικτυα που βασιζονται σε πυκνη δικτυωση me AP και ομνι κεραιες - οπου με το που δινεις παροχη σε ενα "κουτι" με κεραια (παρομοιο συστημα με το Nokia RoofNet) συνδεεσαι αυτοματα στο δικτυο χωρις αλλες ενεργειες
Οπως και στο SOWN - που η τοπολογια του πλησιαζει περισσοτερο αυτη του υπαρχοντος δικτυου στο λεκανοπεδιο - φαινεται να απαiτουνται και καποια επιπλεον utilities
Oπως λενε καποιοι Σουηδοι:
"...Ad hoc networks with multihopping has been around
since the 70's.
Within IETF-MANET there are about 30 different protocols
beeing evaluated right know. One (ABR) has been around in a few commercial products for a couple of years.
We have built a small linuxdist for evaluation of ad hoc protocols and it's available for download:
http://apetestbed.sourceforge.net/
If you're only interested in trying multihop with our own implementation
of AODV (Ad-hoc On-demand Distance Vector Routing) it's avaible with
following features:
* Runs on Linux 2.4.x kernels.
* Complies with AODV Draft v.10
* Implemented as a user-space daemon and requires NO kernel modifications.
* Easy to compile, install and run.
* Optional uni-directional link detection and avoidance (not specified in draft).
http://www.docs.uu.se/%7Ehenrikl/aodv/
We have also a little hack of our own called LUNAR (Lightweight Underlay Network Ad hoc Routing) that makes a laptop into a ad hoc node with maximum hops set to 10 for usable reasons. LUNAR is a simple and robust self-configuring wireless ad-hoc routing system that creates an IP subnet illusion. A single command line of the form:
./lunar
allows you to join a wireless ad-hoc group and use all Internet
applications as if the nodes were tethered: no parameters required
http://www.docs.uu.se/docs/research/pro ... net/lunar/ (http://www.docs.uu.se/docs/research/projects/selnet/lunar/) ..."
Το Lunar κανει automatic on-demand route discovery, για μεχρι 10-12 κομβους και μεχρι 3 hops ενος "spontaneous ad hoc network"
Απο οτι φαινεται, τρεχει και απο floppy
Me Orinoco cards
http://www.docs.uu.se/docs/research/pro ... ar/floppy/ (http://www.docs.uu.se/docs/research/projects/selnet/lunar/floppy/)
Για οσους θελουν να πειραματιστουν με adhoc P2P δικτυα...
Καλημερα.
Ψαχνωντας να βρω πληροφοριες σχετικα με το θεμα της δρομολογησης στο AWMN παρατηρησα οτι αρκετα απο τα Wireless δικτυα απο αλλες χωρες/πολεις χρησιμοποιουν εναν απο τους 2 παρακατω τροπους:
1. OSFP Routing Protocol (Tοποθετουν ολους τους routers στο Area 0)
2. AODV Routing Protocol
Το ADOV το δοκιμασα στο Lan σπιτι (οχι οτι εβγαλα και τα τρομερα συμπερασματα...) και ειναι πολυ απλο στo compile και στην λειτουργια του. Αποτελειται απο 1 kernel module και ενα user space application. Δεν απαιτει configuration. Η "μαγκια" αυτου του πρωτοκολου ειναι οτι "ανακαλυπτει" τα routes οταν του ζητηθουν. Καπου ειδα οτι υπαρχει και version για windows.
Οπως και να 'χει το θεμα, πιστευω οτι θα πρεπει να προχωρησουμε σε δοκιμες καποια στιγμη ωστε να δουμε τι μας συμφερει τελικα. Το Rip εχει αρχισει να δειχνει οτι δεν τα παει καθολου καλα με μια mesh διαταξη δικτυου.
Τί θα λέγατε λοιπόν για μία "routing team" συνάντηση αυτό το Σάββατο;
paravoid
30/10/2003, 12:17
Καλημερα.
Ψαχνωντας να βρω πληροφοριες σχετικα με το θεμα της δρομολογησης στο AWMN παρατηρησα οτι αρκετα απο τα Wireless δικτυα απο αλλες χωρες/πολεις χρησιμοποιουν εναν απο τους 2 παρακατω τροπους:
1. OSFP Routing Protocol (Tοποθετουν ολους τους routers στο Area 0)
2. AODV Routing Protocol
Το ADOV το δοκιμασα στο Lan σπιτι (οχι οτι εβγαλα και τα τρομερα συμπερασματα...) και ειναι πολυ απλο στo compile και στην λειτουργια του. Αποτελειται απο 1 kernel module και ενα user space application. Δεν απαιτει configuration. Η "μαγκια" αυτου του πρωτοκολου ειναι οτι "ανακαλυπτει" τα routes οταν του ζητηθουν. Καπου ειδα οτι υπαρχει και version για windows.
Οπως και να 'χει το θεμα, πιστευω οτι θα πρεπει να προχωρησουμε σε δοκιμες καποια στιγμη ωστε να δουμε τι μας συμφερει τελικα. Το Rip εχει αρχισει να δειχνει οτι δεν τα παει καθολου καλα με μια mesh διαταξη δικτυου.
Μην ξεχνάς ότι εκτός από Linux (ή BSD) και Windows routers έχουμε και Cisco routers στο δίκτυο (βλ. MAuVE, DiGi, nkladakis, Alexandros)
Τί θα λέγατε λοιπόν για μία "routing team" συνάντηση αυτό το Σάββατο;
Αν μπορεί ο Αλέξανδρος, εγώ είμαι μέσα.
Αν δεν μπορεί, καλύτερα να περιμένουμε μέχρι να μπορέσει ;)
Paravoid δεν το ξεχναω, αλλα αυτο δεν πιστευω οτι πρεπει να ειναι καταλυτικος παραγοντας για την επιλογη του Routing Protocol.
Η επιλογη θα πρεπει να γινει με κριτηρια, περα απο την αποδοση, την ευκολια στην διαχειρηση, την ευελιξια, την αξιοπιστια και την εξοικονομηση bandwidth.
Ναι αλλά μην ξεχνάμε και τη συμβατότητα με τα υπάρχοντα υλικά...
Ναι βρε Capvar δεν την ξεχναμε. Αν δεν βρουμε τωρα λυση στο θεμα οταν οι κομβοι διπλασιαστουν θα ειναι πλεον αδυνατον να εφαρμοσουμε οποιαδηποτε αλλαγη σε οτι αφορα το routing.
Εγω εχω προτεινει 2 τροπους να δοκιμασουμε για να αλλαξουμε την δρομολογηση. Ο ενας απο αυτους (OSPF) δουλευει μια χαρα με τον ηδη υπαρχον εξοπλισμο (Linux/*BSD/Cisco/(Win32?)).
Ποιο απλα, μπορουμε να ξεκινησουμε με OSPF και με ολους τους routers στο Area 0 και να παρατηρησουμε πως θα "δουλεψει". Θα μελετησουμε καλυτερα τις επιλογες διαδρομης που κανει το OSPF και το πως συμπεριφερεται οταν καποιο link παρουσιασει ασταθιες.
Θελω να τονισω οτι πρεπει να ειναι πρωτη προτεραιοτητα η αλλαγη του Routing Protocol πριν οι κομβοι πολλαπλασιαστουν και μετα ειναι αδυνατον να τους ελεγξουμε ολους.
Αλεξανδρε, τελικα το Σαββατο μπορεις? Πες σε παρακαλω με Post στο Forum ή εστω ΡΜ ωστε να ξερω τι θα κανω και εγω.
phronidis
31/10/2003, 12:51
Μέσα για routing meeting
Alexandros
31/10/2003, 17:33
Παιδιά δεν μπορώ αυτό το ΣΚ. Λυπάμαι. Αν θέλετε να τα πείτε μαζευτείτε φυσικά. Από την πλευρά μου θα προσπαθήσω να μαζευτούμε σε μια άλλη ημερομηνία και ενδεχομένως να έχω μαζί και έναν ακόμα φίλο να ανταλλάξουμε ιδέες.
Αλέξανδρος
5 σελίδες το έχουμε ζαλίσει ... Σάββατο meeting 16:00 στο cafe 1534 στο Μαρουσι ... είναι 100 μέτρα από το σταθμό.
(Από την άνοδο του σταθμου δεξιά , στο δρομάκι που θα δείτε κατεβαίνετε και στα 20 μέτρα ειναι φατσα κάρτα)
Όποιος έχει να πει κατί ΟΥΣΙΑΣΤΙΚΟ για το routing ερχετε
Ripper_gr
01/11/2003, 04:07
simera to savato?
#####edited από Xaotikos######
Offtopic σε αρκετά σοβαρό θέμα...
#######################
papashark
01/11/2003, 21:45
Φοβερή ανταπόκριση !!!
Είμαστα 4, δηλαδή 3, στην ουσία 2......
Ο Mindfox μας συμπαραστάθηκε τηλεφωνικά.
Είμαστα οι :
Papashark * Δρ. Δικτύωση Γαλαχιακών Συστημάτων
Paravoid * Πτ. Οι Η/Υ και πως θα τους κατακτήσετε
Digi * Newbie
Achille * Newbie
Αποφασήστηκε κάποιο routers να γυρίσουν σε ospf και ο Θεός βοηθός :P
apo do meria pantos to ospf moiazei na pigenei kala mexri stigmis.
Good luck.
harisis
p.s. pls enimeronete gia tin poreia tou pramatos :)
Σε εμένα και στον κλαδάκη έχει μπει πλέον OSPF.
Ας αλλάξουν και οι υπόλοιποι
Ωραία δουλεύει... αλλά γράψτε πάνω κάτω τί πρέπει να κάνουμε κι εμείς... να βάλουμε όλους τους router στο Area 0? :D
Ναι μόνο η παρακατω γραμμές χρειάζονται στο ospfd.conf
router ospf
network 10.0.0.0/8 area 0
spirosco
02/11/2003, 13:03
Και σε εμενα λειτουργει εδω και λιγη ωρα το OSPF.
Αντε κι οτι βρεξει ας κατεβασει.... :?
Σε εμένα και στον κλαδάκη έχει μπει πλέον OSPF.
Ας αλλάξουν και οι υπόλοιποι
Πες μου και εμένα τα cisco configuration steps.
Είναι το παρακάτω σωστό ;
router ospf 1
log-adjacency-changes
area 0 range 10.0.0.0 255.0.0.0
network 10.0.0.0 0.255.255.255 area 0
Στο 1711 που έχει το WGB με spirosco, έχω μόνο ospf.
Sτο ταρατσοpc από τη μεριά PCI με KeyMan & ΕΕ έχω μόνο rip και από τη μεριά 1711 ospf.
Και ο Θεός βοηθός που λέει ο Σπύρος
Mick Flemm
02/11/2003, 15:03
Ας μπει κάποιος να το φτιάξει και στην ταράτσα μου...
Gia to cisco exw ta eksis (alla kati den mou aresei akoma)
router ospf 1
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.0.0.0 255.0.0.0 area 0
To redistribute static και redistribute connected πρέπει να φύγει, το OSPF βρίσκει μόνο του ποια από τα connected interfaces πρέπει να στείλει, αν ανήκουν στη δήλωση "network 10.0.0.0/8 area 0"
Για να λειτουργήσει σωστά το OSPF στη zebra, πρέπει να έχετε δηλώσει με IP τα interfaces στο /etc/zebra/zebra.conf. Δίνω παράδειγμα από το δικό μου:
/etc/zebra/zebra.conf
!
! Zebra configuration saved from vty
! 2003/01/26 21:04:47
!
hostname aias.achille.awmn
password userpass
enable password adminpass
log file /var/log/zebra/zebra.log
interface eth0
description link with sfera
ip address 10.47.130.105/29
interface eth1
description link with sam
ip address 10.47.130.67/29
interface wlan0
description link with dti
ip address 10.37.56.66/29
interface wlan1
description link with drinet
ip address 10.47.130.83/29
interface wlan2
description link with xtreme
ip address 10.47.130.97/29
!
line vty
!
Network Calculator για να υπολογίσετε τα bits της μάσκας από subnet mask (κοιτάξτε κάτω κάτω)
http://www.telusplanet.net/public/sparkman/netcalc.htm
Στο ospfd.conf είναι πιο απλό, αρκεί μόνο να βάλετε σωστό id στο router σας, και το σωστό network.
/etc/zebra/ospfd.conf
! -*- ospf -*-
!
! OSPFd sample configuration file
!
!
hostname aias.achille.awmn
password userpass
enable password adminpass
!
router ospf
ospf router-id 10.47.130.105
network 10.0.0.0/8 area 0
! log stdout
log file /var/log/zebra/ospfd.log
Στο router-id πρέπει να βάλετε το IP που έχετε στο εσωτερικό σας interface κατά προτίμιση, από αυτό φαίνεται σε ολόκληρο το δίκτυο ποια subnets έχετε και μπορεί κάποιος εύκολα να βρει πιθανά λάθη στο configuration σας.
Μην ξεχάσετε να απενεργοποιήσετε τον ripd και να ενεργοποιήσετε τον ospfd στο /etc/zebra/daemons (Debian) και να κάνετε restart τη zebra.
MHN KANETE REDISTRIBUTE CONNECTED, δεν χρειάζεται στο OSPF, θα τα βάλει σαν external routes και θα γίνει πανικός
MHN KANETE REDISTRIBUTE STATIC, δεν μας ενδιαφέρουν τα στατικά routes που μπορεί να έχετε, και ΔΕΝ γίνεται να τα φιλτράρουν οι άλλοι routers στην πορεία (τουλάχιστον όχι εύκολα)
ΜΗΝ ΚΑΝΕΤΕ REDISTRIBUTE RIP, εκτός αν το interface στο οποίο τρέχει το RIP είναι η μοναδική διέξοδος για κάποια subnets του AWMN, δεν υπάρχει άλλη διέξοδος που να τρέχει OSPF, γιατί θα μπλεχτούνε τα metrics και θα γίνει πανικός. Προτιμήστε να ενημερώσετε τους υπολοίπους κόμβους και να γυρίσουν και αυτοί σε OSPF το συντομότερο δυνατό.
Περιμένω feedback γιατί δεν είναι 100% σίγουρο ότι αυτά που λέω είναι σωστά.
spirosco
02/11/2003, 21:01
Το πρωτο προβλημα που προεκυψε απο την μεταβαση σε OSPF ειναι οτι στα subnets που θα επρεπε να εχω 1 hop εγω εβλεπα 11 hops.
Μετα απο πειραματισμους διαπιστωσα οτι λυθηκε αυτο οριζοντας ως ip cost για καθε interface του router το 1.
Το ιδιο ισχυει και για Windows router.
Βεβαια αυτο δεν σημαινει οτι ειναι και σωστο.
Γι'αυτο αν καποιος ξερει ας μιλησει/γραψει κατι, εκτος κι αν το πετυχα στην τυχη...που πολυ θα το'θελα :twisted: .
Σπύρο άσε το default, με τα costs θα ασχοληθούμε αργότερα, το cost βγαίνει από το bandwidth και είναι δυνατόν να βγαίνει και αυτόματα (να του λες το bandwidth και να το υπολογίζει)
spirosco
02/11/2003, 21:15
Συμφωνω μαζι σου Αχιλλεα, αλλα δεν συμβαινει μονο σ'εμενα.
Τα subnets του Alexandrou τα παιρνω με 11 hops, του Δαμιανου με 20 και παει λεγοντας...
Δεν είναι hops αυτά Σπύρο, είναι costs. Δεν είναι cost=hop όπως στο RIP.
Άστο όπως είναι και μόλις γυρίσουμε αρκετοί σε OSPF, θα σας πω πως βάζουμε costs ;)
Αυτή τη στιγμή μιλάνε μόνο OSPF οι routers:
digi, xtreme, achille, dti, dermanis, jabarlee, jacobs, bakolaz, alexandros, drinet
Οι routers των sam, jankos, airspace, cslab ρυθμίζονται σε ospf.
Οι clients με subnet προσωρινά θα παίξουν στη backbone ζώνη, θα δούμε μελοντικά πως θα το κάνουμε...
Τελικα εγινε η μεταβαση βλεπω αυτο το Σ/Κ που ελειπα απο το Rip στο OSPF.
Καλο ειναι να μην βαλουμε χερι και πειραξουμε το bandwidth Achille γιατι αυτο το κανεις μονο οταν θελεις να "πειραξεις" εσυ τα cοsts manualy για ασχετους λογους. Το OSPF μπορει να βρει μονο του το bandwidth ανα πασα στιγμη στα connected links και φυσκα (αυτο που θελαμε ολοι) στα αλλα.
Αντε, καλες μετρησεις.
Επιπλεον α ηθελα να προτεινω το εξης:
Οι κομβοι που εχουν ενα (1) μονο link (ασχετα αν εχουν και lan παραλληλα) να μην χρησιμοποιησουν routing protocols στο configuration και να θεσουν ενα default gw μονο που θα ειναι ο router του ΑΡ που συδνεονται. Ετσι θα μειωσουμε στο ελαχιστο καποιες ενεργειες του OSPF τις οποιες και θελουμε να αποφυγουμε στο μεγαλυτερο βαθμο που μπορουμε (flooding για το route propagation (ο γραφων εξαιρειται...)
spirosco
02/11/2003, 23:45
Αφου ξεμπλεξα τα hops με τα metrics κλπ :oops: κατεβασα και το RIP.
Μενει μια ρυθμιση και απο τη μερια του Νικου (MAuVE) για να αρχισουμε να βλεπουμε τι εστι OSPF.
pargyrak
03/11/2003, 00:40
Gia to cisco exw ta eksis (alla kati den mou aresei akoma)
router ospf 1
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.0.0.0 255.0.0.0 area 0
Δεν ξέρω αν έχετε authentication αλλά αν ναι τότε πρέπει να ορίσεις τύπο authentication (md5 ή plain text) και το password σε κάθε intraface.
O 1720 μου έχει αντικατασταθεί από MIKROTIK και δεν θυμαμαι τις εντολές απ'έξω.
pargy
Περίεργο μήνυμα σφάλματος.
Ενας hardware router στέλνει σε ένα software router που τρέχει σε ένα pc πακέττα OSPF, τα οποία ο τελευταίος τα απορρίπτει για τον ακόλουθο λόγο :
Rejected an OSPF packet from 10.2.8.190 to 224.0.0.5 because the OSPF data length in the OSPF header was 48 but the length calculated from the IP Header fields was 60.
stardust
03/11/2003, 03:27
Kαλησπέρα. Ενεργοποίησα και εγώ το OSPF στο linux μου.Θα ακολουθήσει το zebra.conf και το ospfd.conf που έφτιαξα με βάση τα λεγόμενα του Αchille.Μια διευκρίνηση:στo ip address βάζουμε την IP που έχουμε δηλώσει σε κάποιο από τα eth?
zebra.conf
!
interface eth0
description eth0: AP
ip address 10.21.122.2/26
!
interface eth1
description eth1: lan
ip address 10.21.122.113/29
interface eth3
description eth3: digi
ip address 10.21.122.65/29
interface eth2
description eth2: Airspace
ip address 10.14.141.86/29
ospfd.conf
router ospf
ospf router-id 10.21.122.2
ospf router-id 10.21.122.113
ospf router-id 10.21.122.65
ospf router-id 10.14.141.86
network 10.0.0.0/8 area 0
Μακάρι να τα έχω γράψει σωστά.Πήρα και routes από τον Digi.Από τον Αirspace θα ενημέρωσω από άυριο.Αν έχω λάθη ας μιλήσει κάποιος...
Kαλησπέρα. Ενεργοποίησα και εγώ το OSPF στο linux μου.Θα ακολουθήσει το zebra.conf και το ospfd.conf που έφτιαξα με βάση τα λεγόμενα του Αchille.Μια διευκρίνηση:στo ip address βάζουμε την IP που έχουμε δηλώσει σε κάποιο από τα eth?
Στο ip address βάζεις την IP που έχεις δώσει στο interface από το λειτουργικό (/etc/network/interfaces)
Στο ospf router-id βάζεις μόνο ένα, σβήσε τα υπόλοιπα, άσε μόνο αυτό που δείχνει στο εσωτερικό σου δίκτυο ή στο Access point (να ανήκει δηλαδή στο δικό σου Class-C για να είναι εύκολο να σε βρούμε αν κάτι δεν πάει καλά)
stardust
03/11/2003, 03:38
router ospf
ospf router-id 10.21.122.2
network 10.0.0.0/8 area 0
Πιστεύω να είναι οκ τώρα.Αλήθεια με sam έχεις ενεργοποιήσει OSPF ή ακόμα?
Πιστεύω να είναι οκ τώρα.Αλήθεια με sam έχεις ενεργοποιήσει OSPF ή ακόμα?
Ακόμα. Μου έστειλε το conf του router του γιατί δεν τα κατάφερε να το γυρίσει σε OSPF, θα το κοιτάξω αύριο κάποια στιγμή...
jabarlee
03/11/2003, 11:11
φαντάζομαι το γεγονός ότι από σήμερα δεν βλέπουμε ntua over wireless οφείλεται στην αλλαγή σε OSPF?
Όχι. Ο router στο NTUA ξανακόλλησε (μόνο μνήμη και σκληρό δεν έχω αλλάξει, θα το κάνω σήμερα ή αύριο) και ο router του enaon (drinet) έφαγε κάποια φρίκη η μπαταρία του και έχασε τις ρυθμίσεις στο BIOS (και μέχρι να τις ξαναβρούμε...θα είναι down)
herouvim
04/11/2003, 01:59
Καλησπέρα... μιας και ξέρω ελάχιστα πράγματα απο Linux, υπάρχει κανείς που να μπορεί να μου κανει την αλλαγή σε OSPF μέσο δυκτίου;
Οι ρυθμίσεις μου ειναι οι εξής:
# The loopback interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.2.8.65
netmask 255.255.255.248
broadcast 10.2.8.64
network 10.2.8.71
iface wlan0 inet static
address 10.2.8.56
netmask 255.255.255.192
broadcast 10.2.8.63
network 10.2.8.0
gateway 10.2.8.62
Ευχαριστώ ,
John :)
Για τους υποστηρικτές των windows:
Ανοίξτε τον rras, double click στο Interfaces, δεξί click στο general, new routing protocol, ospf.
Δεξί click στο ospf properties, στο tab General βαλτέ την ip του router σας και κάντε check στο «enable aut…router», στο Areas, πατήστε edit και βγάλτε το check από το enable plaintext password, στο External routing πατήστε «Accept routes…except..selected», και στα route sources βαλτέ check σε όλα, εκτός του rip. Τα win έχουν βάλει το area 0 με την εγκατάσταση του ospf.
Δεξί click στο ospf, New interface, επιλογή των ifaces που κοιτάνε στο bb. Καμία αλλαγή δεν είναι απαραίτητη εδώ. Σημειώστε ότι για να μπορούν τυχόν Pc που βρίσκονται σε private network να δουν awmn, θα πρέπει το Iface που τα συνδέει στον router, να μπει και αυτό στο ospf.
Θα πρότεινα συνδέσεις με άλλους servers, οι οποίες τερματίζουν σε 1-2 hops και δεν ενώνονται πάλι στο bb, να συνεχίσουν να εξυπηρετούνται από το rip2.
enaon
σε ευχαριστώ πολύ για τις οδηγίες αυτές.
(βλέπεις είναι μειονότητα εδώ τα windows)
Καλημέρα,
Κατ' αρχήν να πω ένα μεγάλο μπράβο / συγχαρητήρια για την απόφαση αλλαγής πρωτοκόλλου δρομολόγησης και από μέρους μου.
Και τώρα κατευθείαν στα προβλήματα / απορίες:
A. Είμαστε σίγουροι ότι πρέπει όλοι να είναι στο area 0 (Κάποιοι παλαιότεροι μου έχουν διηγηθεί μια καταπληκτική ιστορία ...);;;
Β. Ο κόμβος Nikola γύρισε εχθές βράδυ σε ospf όμως μετά από κάνα δίωρο κάποιος router, πιθανότερο ο cisco.xtreme.awmn αποφάσισε (παρέα με το κόμβο του ocean ???) ότι για κάποιο λόγο είναι αυτός το path για δίκτυα απ' ευθείας συνδεδεμένα στο nikolas.
Αποτέλεσμα: Να μένω εγώ απέξω (και καλά για μένα ποιος χ....), αλλά και περισσότερο τα services που σήκωσα (DNS και ένα ωραιότατο ftp -- 400+ GB -- )
Ακολουθούν τμήμα του ospfd.conf και ένα traceroute από το router του ocean προς ρο edge μου ...
!
router ospf
router-id 10.21.121.62
log-adjacency-changes
redistribute connected subnets
network 10.0.0.0 255.0.0.0 area 0
!
traceroute 10.21.121.150
traceroute to 10.21.121.150 (10.21.121.150), 64 hops max, 44 byte packets
1 cisco.xtreme.awmn (10.19.141.1) 3.081 ms 3.254 ms 2.888 ms
2 192.168.2.21 (192.168.2.21) 12.832 ms 5.026 ms 5.012 ms
3 192.168.2.22 (192.168.2.22) 5.576 ms 5.890 ms 5.762 ms
4 192.168.2.21 (192.168.2.21) 7.866 ms 8.344 ms 9.348 ms
5 192.168.2.22 (192.168.2.22) 8.401 ms 8.513 ms 8.588 ms
6 192.168.2.21 (192.168.2.21) 20.567 ms 10.406 ms 10.336 ms
7 192.168.2.22 (192.168.2.22) 10.838 ms 11.025 ms 11.063 ms
8 192.168.2.21 (192.168.2.21) 13.289 ms 13.008 ms 12.918 ms
9 192.168.2.22 (192.168.2.22) 13.551 ms 13.476 ms 13.587 ms
10 192.168.2.21 (192.168.2.21) 15.538 ms 15.454 ms 15.660 ms
11 192.168.2.22 (192.168.2.22) 24.072 ms 16.060 ms 16.166 ms
12 192.168.2.21 (192.168.2.21) 19.317 ms 25.549 ms 18.183 ms
13 192.168.2.22 (192.168.2.22) 19.014 ms 18.662 ms 18.621 ms
14 192.168.2.21 (192.168.2.21) 20.653 ms 21.165 ms 20.630 ms
15 192.168.2.22 (192.168.2.22) 21.885 ms 28.716 ms 21.749 ms
16 192.168.2.21 (192.168.2.21) 23.123 ms 23.785 ms 29.291 ms
17 192.168.2.22 (192.168.2.22) 29.784 ms 23.214 ms 22.402 ms
18 192.168.2.21 (192.168.2.21) 24.965 ms 26.784 ms 24.447 ms
19 192.168.2.22 (192.168.2.22) 25.144 ms 25.673 ms 25.007 ms
20 192.168.2.21 (192.168.2.21) 26.947 ms 35.016 ms 28.350 ms
21 192.168.2.22 (192.168.2.22) 35.237 ms 31.482 ms 31.451 ms
22 192.168.2.21 (192.168.2.21) 33.093 ms 33.417 ms 33.151 ms
23 192.168.2.22 (192.168.2.22) 34.084 ms 33.986 ms 48.164 ms
24 192.168.2.21 (192.168.2.21) 35.904 ms 35.845 ms 35.766 ms
25 192.168.2.22 (192.168.2.22) 36.831 ms 43.347 ms 39.620 ms
26 192.168.2.21 (192.168.2.21) 49.732 ms 38.648 ms 38.396 ms
27 192.168.2.22 (192.168.2.22) 39.130 ms 42.176 ms 43.391 ms
28 192.168.2.21 (192.168.2.21) 43.422 ms 41.185 ms 52.619 ms
29 192.168.2.22 (192.168.2.22) 41.938 ms 42.607 ms 43.277 ms
30 192.168.2.21 (192.168.2.21) 44.524 ms 58.354 ms 44.326 ms
31 192.168.2.22 (192.168.2.22) 52.749 ms 44.895 ms 44.592 ms
32 192.168.2.21 (192.168.2.21) 47.976 ms 54.273 ms 46.593 ms
33 192.168.2.22 (192.168.2.22) 47.444 ms 47.302 ms 47.397 ms
34 192.168.2.21 (192.168.2.21) 51.668 ms 50.738 ms 49.270 ms
35 192.168.2.22 (192.168.2.22) 55.035 ms 63.901 ms 49.657 ms
36 192.168.2.21 (192.168.2.21) 64.823 ms 50.668 ms 49.881 ms
37 192.168.2.22 (192.168.2.22) 51.400 ms 50.192 ms 58.302 ms
38 192.168.2.21 (192.168.2.21) 68.214 ms 52.085 ms 63.878 ms
39 192.168.2.22 (192.168.2.22) 54.176 ms 74.745 ms 72.838 ms
40 192.168.2.21 (192.168.2.21) 54.084 ms 54.289 ms 53.983 ms
41 192.168.2.22 (192.168.2.22) 73.724 ms 55.252 ms 54.708 ms
42 192.168.2.21 (192.168.2.21) 56.769 ms 56.782 ms 78.470 ms
43 192.168.2.22 (192.168.2.22) 57.245 ms 57.250 ms 57.312 ms
44 192.168.2.21 (192.168.2.21) 59.975 ms 73.651 ms 62.469 ms
45 192.168.2.22 (192.168.2.22) 63.524 ms 60.940 ms 59.824 ms
46 192.168.2.21 (192.168.2.21) 74.011 ms 63.037 ms 67.934 ms
47 192.168.2.22 (192.168.2.22) 65.963 ms 66.516 ms 67.681 ms
48 192.168.2.21 (192.168.2.21) 68.933 ms 71.361 ms 69.754 ms
49 192.168.2.22 (192.168.2.22) 70.013 ms 69.398 ms 76.371 ms
50 192.168.2.21 (192.168.2.21) 75.316 ms 71.647 ms 79.312 ms
51 192.168.2.22 (192.168.2.22) 72.902 ms 72.309 ms 72.050 ms
52 192.168.2.21 (192.168.2.21) 74.186 ms 74.456 ms 73.893 ms
53 192.168.2.22 (192.168.2.22) 74.995 ms 74.752 ms 74.632 ms
54 192.168.2.21 (192.168.2.21) 76.194 ms 82.244 ms 73.453 ms
55 192.168.2.22 (192.168.2.22) 80.529 ms 74.234 ms 73.440 ms
56 192.168.2.21 (192.168.2.21) 75.659 ms 75.563 ms 80.973 ms
57 192.168.2.22 (192.168.2.22) 75.422 ms 75.313 ms 75.585 ms
58 192.168.2.21 (192.168.2.21) 77.346 ms 80.376 ms 80.029 ms
59 192.168.2.22 (192.168.2.22) 78.216 ms 92.849 ms 78.349 ms
60 192.168.2.21 (192.168.2.21) 79.997 ms 80.492 ms 94.991 ms
61 192.168.2.22 (192.168.2.22) 89.865 ms 86.340 ms 93.105 ms
62 192.168.2.21 (192.168.2.21) 96.769 ms 88.546 ms 84.129 ms
63 192.168.2.22 (192.168.2.22) 89.421 ms 84.282 ms 95.800 ms
64 192.168.2.21 (192.168.2.21) 97.104 ms 91.237 ms 106.703 ms
Για τους υποστηρικτές των windows:
Ανοίξτε τον rras, .....
Ακολούθησα πιστά τις οδηγίες σου, αλλά πάλι στο ίδιο πρόβλημα κατέληξα.
Τα windows δεν συνεργάζονται με τον γειτονικό τους cisco, γιατί σκοντάφτουν στο παρακάτω πρόβλημα :
Rejected an OSPF packet from 10.2.8.190 to 224.0.0.5 because the OSPF data length in the OSPF header was 48 but the length calculated from the IP Header fields was 60.
Υπάρχει κανένας με ospf σε windows που να είναι γείτονας με τον DiGi ή τον nkladakis για να δούμε αν το πρόβλημα είναι γενικό ή ειδικό σε εμένα;
A. Είμαστε σίγουροι ότι πρέπει όλοι να είναι στο area 0 (Κάποιοι παλαιότεροι μου έχουν διηγηθεί μια καταπληκτική ιστορία ...);;;
Ήταν για να γίνει το πρώτο βήμα για να φύγουμε από τις φιλολογικές συζητήσεις .Τώρα έχουμε μία βάση για να προτείνουμε αλλαγές - σχεδιασμό που είναι εφικτό να υλοποιηθεί.
Ακολουθούν τμήμα του ospfd.conf και ένα traceroute από το router του ocean προς ρο edge μου ...
!
router ospf
router-id 10.21.121.62
log-adjacency-changes
redistribute connected subnets
network 10.0.0.0 255.0.0.0 area 0
!
Δοκίμασε να βγάλεις το redistribute (Είχα πει στην αρχή να τα έχουμε για να αποφύγουμε μεγάλο downtime οταν θα έτρεχε OSPF και RIP2 μαζί)
Ήταν για να γίνει το πρώτο βήμα για να φύγουμε από τις φιλολογικές συζητήσεις .Τώρα έχουμε μία βάση για να προτείνουμε αλλαγές - σχεδιασμό που είναι εφικτό να υλοποιηθεί.
ΟΚ ! οπότε λογικά θέλουμε μάζοξη χαρτί/πίνακα και "ταλέντο" στην ζογραφική :D
Δοκίμασε να βγάλεις το redistribute (Είχα πει στην αρχή να τα έχουμε για να αποφύγουμε μεγάλο downtime οταν θα έτρεχε OSPF και RIP2 μαζί)[/quote]
Διορθωσεμε αν λέω μπαρούφες αλλά έτσι πως θα μαθένει ο κόσμος τα δίκτυα "μου" ; :?:
Διορθωσεμε αν λέω μπαρούφες αλλά έτσι πως θα μαθένει ο κόσμος τα δίκτυα "μου" ; :?:
Θα τα βλέπει, γιατί το OSPF τα βάζει μόνο του στο area 0 με την εντολή network ...
Αν βάλεις redistribute connected τα βάζει σαν external routes, δεν είναι αυτό που θέλεις.
OSPF != RIP ;)
LowRider
04/11/2003, 11:46
Για τους υποστηρικτές των windows:
Ανοίξτε τον rras, .....
Ακολούθησα πιστά τις οδηγίες σου, αλλά πάλι στο ίδιο πρόβλημα κατέληξα...
Disclaimer: ¨Εχω δουλέψει ελάχιστα με RRAS και καθόλου με OSFP και RRAS.
MauVe, υποθέτωντας ότι το παραπάνω μύνημα λάθους εμφανίζεται στο Event Log σου θα πρότινα μία ματιά στο http://www.eventid.net και ένα search για το συγκεκριμένο event id που βλέπεις στο log. Μήπως και βρεθεί τίποτα. Δυστυχώς ένα σύντομο ψάξιμο στο Technet δεν απέδωσε αποτέλεσμα.
End of asxetos_injection mode. 8)
Θα τα βλέπει, γιατί το OSPF τα βάζει μόνο του στο area 0 με την εντολή network ...
Αν βάλεις redistribute connected τα βάζει σαν external routes, δεν είναι αυτό που θέλεις.
OSPF != RIP ;)
OK!!!
Filos tou bgp edw :wink:
herouvim
04/11/2003, 12:02
Πολλα προβληματα βρε παιδια αυτο το OSFP , αλλοι μενουν απεξω , οι πιο πολλοι δυσκολευοντε να το γυρισουν ,
μιας και μερικοι αποφασισαν να το γυρισουν γιατι δεν βοηθανε και εμας που δεν ξερουμε να κανουμε το ιδιο ;
δινω παλι τα IP μου.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.2.8.65
netmask 255.255.255.248
broadcast 10.2.8.64
network 10.2.8.71
iface wlan0 inet static
address 10.2.8.56
netmask 255.255.255.192
broadcast 10.2.8.63
network 10.2.8.0
gateway 10.2.8.62
Herouvim, ποιο ειναι το προβλημα σου? Το να κανεις post οτι πληροφορια πιστευεις δεν βγαζουμε ακρη. Πες απλα τι θελεις να κανεις, πως προσπαθεις να το κανεις και τι δεν δουλευει.
Φανταζομαι οτι θελεις να βαλεις OSPF, σωστα? σε καποιο router θα το κανεις αυτο? Τι router ειναι? Τι τρεχει?...
Το ξερω οτι σου ζηταω πολλα, αλλα εφυγα βιαστηκα σημερα απο το σπιτι και ξεχασα την κρυσταλινη σφαιρα...
Achille, τα ΑΡ με πελατες που εχουν δικτυα, θα πρεπει να ΜΗΝ επιττρεψουν στους πελατες τους να τρεξουν OSPF. Τα ΑΡ με τους πελατες θα πρεπει να τρεχουν RIP, το ΑΡ θα εχει την δωλωση passive στο WAN interface για το ΒΒ link και θα κανει redistribute rip.
MAuVE, μπορω να εχω προσβαση στον router σου να στησω το configuration και να το κανω post?
v.t.b. για μεσαια δικτυα το OSPF μπορει να δουλεψει μια χαρα σαν EGP.
Λοιπόν μια ματιά και απο εμένα:
1. Τρέχω και RIP και OSPF (μια και όπως είπα σε άλλο post (http://www.awmn.gr/forum/viewtopic.php?t=3534&start=15), πρέπει τουλάχιστον προσωρινά να υποστηρίξουμε τους clients που έχουν subnets και δεν έχουν γυρίσει σε OSPF).
Ετσι λοιπόν σύμφωνα με την cisco (http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs001.htm) εχω βάλει στο ospfd.conf:
router ospf
ospf router-id 10.21.120.62
network 10.0.0.0/8 area 0
redistribute rip
και στο ripd.conf:
router rip
network 10.0.0.0/8
network xl0
network ep0
!neighbor 10.19.141.1
neighbor 10.21.120.73
redistribute connected
redistribute ospf
τώρα μερικά περίεργα που βλέπω στο netstat -nr:
147.102.3.38 10.19.141.1 UGH1 0 0 ep0
147.102.222.210 10.19.141.1 UGH1 0 0 ep0
147.102.222.211 10.19.141.1 UGH1 0 0 ep0
169.254 10.19.141.1 UG1c 0 0 ep0
192.168.1 10.19.141.1 UGSc 0 520585 ep0
192.168.32 10.21.120.73 UG1c 0 0 xl0
Ποιός ειναι το 147.102 ? - πάντος έρχεται απο τον κλαδάκη και περα.
Ποιός ειναι το 169.254 ? - πάντος έρχεται απο τον κλαδάκη και περα.
Ποιός έχει το 192.168.1 ? - πάντος έρχεται απο τον κλαδάκη και περα.
Ποιός έχει το 192.168.32 ? - πάντος έρχεται απο τον Νικόλα και πέρα
Αλλες παρατηρήσεις:
2.Μου φαίνεται οτι η φασαρία περι του "βάρους" του OSPF και το οτι θέλει πολλή μνήμη και επεξεργαστή ειναι μούσια.... είδα ΕΛΑΧΙΣΤΗ ως ΚΑΜΜΙΑ διαφορά στο load του μηχανήματος μου αφού έβαλα το OSPF
3. Τώρα που έχουμε πλέον "κλειστούς κύκλους" ( του είδους NodeA->NodeB->NodeC->NodeA) θα είναι πιο δύσκολο να κάνουμε debug και να βρούμε απο πού προέρχονται "κακά" routes οπως τα παραπάνω.
Αυτά και απο έμενα
herouvim
04/11/2003, 12:27
Μα δεν εγραψα τιποτα συγκεκριμενο γιατι περιμενω να μπει καποιος να μου το φτιαξει , γι αυτο εδωσα και τα IP μου...
Εγω που προσπαθησα να το φτιαξω μονος μου χαθηκα απο τα μη συγκεκριμενα forum , τα οποια απαντανε σε αποριες αλλων και δεν εξηγουν ακριβως ετσι ωστε ενας αρχαριος να μπορεσει να το φτιαξει μονος του.
Μου εχουν βαλει το Debian, αν δεν γινεται καποιος να το φτιαξει μεσο δυκτιου ας μου πει ποια αρχεια πρεπει να κανω edit και τι πρεπει να αλλαξω ωστε να δουλεψει.
Eυχαριστω, και οσο για την γυαλινη σφαιρα , δεν την χρειαζομαστε , κανουμε τα θαυματα και απο μονοι μας .. τοσες κεραιες στησαμε δεν βλεπεις ;;
:)
ocean, βαλε αν θελεις και το passive-interface <BB-interface> στο configuration του Rip ωστε να εισαι σιγουρος οτι δεν στελνει rip updates προς το BB link ο router sou.
Τα "κακα" routes θα κοπουν μεσα απο access lists. Το καθε ΑΡ θα πρεπει να εχει access list που θα επιτρεπουν updates απο συγκεκριμενα subnets και που θα περιοριζουν τα subnets των πελατων τους σε αυτα που πρεπει να εχουν. Οποτε αν καποιος καταλαθος αρχιζει να μοιραζει λαθος routes θα "κοπει" σε καποιο σημειο.
Herouvim μπορω να σε βοηθησω εγω οταν παω σπιτι μου. Το οποιο σημαινει 7-8 το απογευμα. Στο μεταξυ, προσπαθησε να βρεις καποιον με router που να τρεχει το debian και ζητησε του να σου πει εκεινος τι εχει κανει και να σου δωσει το ospfd.conf αρχειο.
herouvim
04/11/2003, 12:48
οκ σε ευχαριστω , θα περιμενω μηνυμα σου οταν μπορεσεις , εχεις MSN;
Να δοκιμάσω μια συγκέντρωση - σύνοψη:
Α. Τα BackBone links ΘΑ τρέχουν OSPF (το "θέμα" του area το συζητάμε), για αρχή στο area 0 (το οποίο είναι λίγο άκομψο ) με passive if το/α if που είναι τα clients.
Β. Τα Clients ΔΕΝ τρέχουν ospf ή καλύτερα ΔΕΝ τρέχουν ospf στο area 0 (στο area που είναι τα Backbone links ) πως θα γίνει routing εδώ το βλέπουμε ...
Τολμάω και ένα δείγμα από ospfd.conf
!
router ospf
router-id aaa.bbb.ccc.ddd
log-adjacency-changes
network 10.0.0.0 255.0.0.0 area 0
passive interface <client-if>
distribute-list awmn-routes out <bb-if>
!
access-list awmn-routes permit 10.0.0.0/8
access-list awmn-routes deny any
!
και ripd.conf (clients αν χρειαστεί ...)
!
router rip
network <client-if>
redistribute connected
redistribute ospf
distribute-list awmn-routes out <client-if>
distribute-list awmn-routes in <client-if>
passive interface <bb-if>
!
...βαλε και ενα passive στο RIP configuration στο ΒΒ link interface και νομιζω πως εχουμε ενα configuration πανω στο οποιο μπορουμε να ξεκινησουμε.
Εγω προτεινω οι πελατες με lan να κρατησουν το RIP ωστε να ενημερωνεται ο router του AP για τα subnets απο "κατω" του.
οκ σε ευχαριστω , θα περιμενω μηνυμα σου οταν μπορεσεις , εχεις MSN;
Οχι, αν εννοεις τον MSN για exchange. Μηπως εχεις εσυ email να μου στειλεις να συνενοηθουμε?
το δικο μου ειναι αυτο: renos at webhosting.awmn
...βαλε και ενα passive στο RIP configuration στο ΒΒ link interface και νομιζω πως εχουμε ενα configuration πανω στο οποιο μπορουμε να ξεκινησουμε.
Εγω προτεινω οι πελατες με lan να κρατησουν το RIP ωστε να ενημερωνεται ο router του AP για τα subnets απο "κατω" του.
Το έβαλα με εδιτ (που μάλλον δεν σε πρόλαβε 8) )
Πάντως οι clients, λογικά αν δεν έχουν δικό τους routable address space ( δηλαδή παίζει {SNAT ή και DNAT) θα την βγάλουν μια χαρά και με ενα default gateway.
Πριν πάντως κόπσουμε την Αθήνα σε περιοχές (οι οποίες θα κάνουν aggregate την πληροφορία μεταξή τους ) καλό θα είταν να βάλουμε κάτω κάτι σε GIS (περίπου ...) -- Geogrfical Information System -- για να δούμε τι και πώς βολεύει. Στο debian (τουλάχιστων το unstable ) υπάρχει το grass.
chatasos
04/11/2003, 18:23
Να δοκιμάσω μια συγκέντρωση - σύνοψη:
Α. Τα BackBone links ΘΑ τρέχουν OSPF (το "θέμα" του area το συζητάμε), για αρχή στο area 0 (το οποίο είναι λίγο άκομψο ) με passive if το/α if που είναι τα clients.
Β. Τα Clients ΔΕΝ τρέχουν ospf ή καλύτερα ΔΕΝ τρέχουν ospf στο area 0 (στο area που είναι τα Backbone links ) πως θα γίνει routing εδώ το βλέπουμε ...
Τολμάω και ένα δείγμα από ospfd.conf
!
router ospf
router-id aaa.bbb.ccc.ddd
log-adjacency-changes
network 10.0.0.0 255.0.0.0 area 0
passive interface <client-if>
distribute-list awmn-routes out <bb-if>
!
access-list awmn-routes permit 10.0.0.0/8
access-list awmn-routes deny any
!
και ripd.conf (clients αν χρειαστεί ...)
!
router rip
network <client-if>
redistribute connected
redistribute ospf
distribute-list awmn-routes out <client-if>
distribute-list awmn-routes in <client-if>
passive interface <bb-if>
!
To rip (με subnets) δεν θα το κάνετε redistribute στο ospf?
Επίσης στις distribute-lists του rip, μήπως πρέπει να κάνετε deny τα routes που έρχονται από το ospf όταν αυτά έχουν "τραβηχτεί" από το rip?
Μάζεψα τις ιδέες του καθενός και έβγαλα νέα configuration files που να λειτουργούν (τουλάχιστον με την quagga).
Έλυσα το πρόβλημα με την zebra που δεν έπαιρνε στοιχεία για τα interfaces και έπρεπε να τους δηλώσεις τις IP στο zebra.conf. Πρέπει να βγάλετε τις δηλώσεις interface που είχατε κάνει στo zebra.conf και να το αφήσετε σχεδόν άδειο όπως παλιά.
Τα παρακάτω configuration files μιλάνε RIP και OSPF με τους πελάτες του AP (πχ αν υπάρχει backbone μέσω του AP θα λειτουργήσει κανονικά αν μιλήσει OSPF ο πελάτης στον router του AP)
Ας ελπίσουμε ότι δεν έχω κάνει κανένα λάθος.
Ότι είναι σε κεφαλαία, πρέπει να αντικατασταθεί με ότι παριστάνει.
zebra.conf
hostname MY.ROUTER.HOSTNAME.AWMN
log file /var/log/zebra/zebra.log
line vty
ripd.conf
hostname MY.ROUTER.HOSTNAME.AWMN
log file /var/log/zebra/ripd.log
router rip
network MYAPINTERFACENAME
redistribute ospf
distribute-list awmn in MYAPINTERFACENAME
distribute-list awmn out MYAPINTERFACENAME
access-list awmn permit 10.0.0.0/8
access-list awmn permit 147.102.0.0/16
access-list awmn deny any
ospfd.conf
hostname MY.ROUTER.HOSTNAME.AWMN
interface MYINTERFACE1
interface MYINTERFACE2
interface MYINTERFACE3 (klp klp)
router ospf
ospf router-id MY.ROUTER.IP.ADDRESS
network 10.0.0.0/8 area 0
redistribute rip
log file /var/log/zebra/ospfd.log
daemons
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=yes
ripngd=no
----------------
Όσοι δεν έχουν AP, δεν χρειάζεται να τρέχουν RIP, και δεν χρειάζονται τη γραμμή redistribute rip στο ospfd.conf
Oι πελάτες με subnet δεν τρέχουν OSPF, μόνο RIP, με το ίδιο configuration.
Όσοι είναι clients σε AP και περνάνε backbone από εκεί ΔΕΝ τρέχουν RIP στο client interface, αλλά OSPF.
Επίσης η zebra φαίνεται να έχει προβλήματα και πρέπει να μεταπηδήσουμε σε quagga, που φαίνεται να λειτουργεί πιο σωστά. Ελπίζω να έχω σύντομα έτοιμο το apt repository και οδηγίες.
Και ο θεός βοηθός...
-----------
Reno δεν κατάλαβα για ποιο λόγο θέλεις να είναι passive το interface. Αφού δεν το έχεις δηλώσει στο "network" στο ripd.conf, δεν θα μιλάει από εκεί. To OSPF δεν θέλεις να είναι passive, γιατί αν κάποιος κάνει bb link μέσα από το AP, δεν θα μπορεί.
ocean: 147.102 είναι το πολυτεχνείο (ftp.ntua.gr κλπ) τα υπόλοιπα βρίσκονται εύκολα ποιος τα στέλνει, με "sh ip ospf data"
chatasos
04/11/2003, 20:57
Έχετε ενεργοποιήσει rip v2?
Έχετε ενεργοποιήσει rip v2?
Τι εννοείς; Μέχρι τώρα Ripv2 τρέχαμε.
chatasos
04/11/2003, 21:29
Έχετε ενεργοποιήσει rip v2?
Τι εννοείς; Μέχρι τώρα Ripv2 τρέχαμε.
Αυτό με το passive interface (renos) έχω την εντύπωση πως έχει έννοια sto rip, αν τρέχεις rip v1 και το network που δηλώνεις "περιέχει" και άλλα interfaces μέσα.
Επίσης στο rip, στο redistribution του ospf μήπως πρέπει να του βάλετε και το κατάλληλο metric ?
π.χ.
για να ανακοινώνεται σε λιγότερους routers με κίνδυνο όμως να μην φτάσει εκεί που πρέπει βάζετε κάποιο μεγάλο metric,
για να νακοινώνεται σε περισσότερους routers με κίνδυνο όμως για routing loops (ιδίως αν έχετε redundant links και πολλά redistributions) βάζετε κάποιο μικρό metric.
Αυτό με το passive interface (renos) έχω την εντύπωση πως έχει έννοια sto rip, αν τρέχεις rip v1 και το network που δηλώνεις "περιέχει" και άλλα interfaces μέσα.
Rip v1 δεν τρέχαμε ποτέ, ούτε πρόκειτε. Υπάρχει λόγος να έχουμε passive σε Rip v2?
Επίσης στο rip, στο redistribution του ospf μήπως πρέπει να του βάλετε και το κατάλληλο metric ?
π.χ.
για να ανακοινώνεται σε λιγότερους routers με κίνδυνο όμως να μην φτάσει εκεί που πρέπει βάζετε κάποιο μεγάλο metric,
για να νακοινώνεται σε περισσότερους routers με κίνδυνο όμως για routing loops (ιδίως αν έχετε redundant links και πολλά redistributions) βάζετε κάποιο μικρό metric.
RIP θα μιλάει μόνο το AP με τους clients του που έχουν subnet (1 hop).
Επομένως δεν έχει και τόσο σημασία τι metric θα στείλει, αφού έτσι και αλλιώς μιλάμε για μοναδική διαδρομή, και μόνο 1 hop routers.
Το redistribute rip στο OSPF νομίζω φροντίζει μόνο του για το metric (να είναι μεγαλύτερο από κάθε πιθανό OSPF path).
Συμφωνείς;
Αχιλλέα στο ospfd.conf εκεί που γράφεις ΜΥΙΝΤΕRFACE1 , 2 κλπ εννοείς το eth0, 1 κλπ αντίστοιχα ή την ip address του κάθε interface ?
Εννοώ όνομα. Όπως είπες, eth0, eth1 κλπ.
Achille αν δινεις το interface στο ripd.conf τοτε, σωστα ειπες, δεν χρειαζεται η δηλωση passive. Εγω ομως πιστευα οτι θα δηλωναμε το network σαν 10.0.0.0/8 γιατι ετσι δεν θα μπερδευαμε τον κοσμο.
Συνοψιζοντας, αυτην την στιγμη το ασυρματο δικτυο εχει μοιραστει σε μικρα areas. Το ΑΡ με τους πελατες του οριζει ενα τετοιο. Υπαρχει φυσικα το κεντρικο area 0. Στα μικρα areas τρεχουμε RIP και στο area 0 τρεχουμε OSPF. Γινεται (προς το παρον χωρις ελεγχο) ενα re-distribute απο το OSFP στο RIP και αναποδα. Τα ΑΡ με τους clients και τα ΒΒ links πλεον μπορουν να ονομαστουν ASBR (Autonomous Routers Boundary Routers).
Μπορουμε αν θελουμε στα areas αυτα να ενεργοποιησουμε OSPF αργοτερα. Δεν ειναι πρωτης προτεραιοτητας θεμα, αλλα υπαρχει πλεον η δυνατοτητα.
Υπαρχει ενα θεμα που εχει να κανει με route loop. Αυτο ξεκιναει ως εξης:
Ενας client σε ενα ΑP εχει link και με αλλο AP ή εχει ενα BB link. Το αποτελεσμα ειναι οι ASBR (αυτοι ειναι τα ΑΡ με τα BB links) οταν διαφημιζουν τα routes προς τα subnets που υπαρχουν απο κατω τους να διαφημιζουν και τα routes προς τα subnets του 2ου link που εχει αυτος ο client. Οποτε αυτοματα απο 2 σημεια διαφημιζονται στο area 0 τα ιδια subnets.
Η Cisco χρησιμοποιει access lists σε καθε ASBR ωστε να περιορισει τα routes που θα διαφημιζονται προς το Backbone σε αυτα που ειναι πραγματικα "κατω" απο τον ASBR.
Το ζητημα ειναι το εξης: Εμεις θα ακολουθησουμε την ιδια νοοτροπια? Δεδομενου οτι καποια στιγμη ενας ASBR μπορει να "χασει" το BB link του η μονη του διεξοδος, αν δεν εχει αλλο BB link, ειναι μεσα απο το link με τον πελατη του αλλου ASBR.
Εγω πιστευω πως θα πρεπει να λαβουμε υποψη μας οτι μιλαμε για mesh διαταξη δικτυου οποτε τα πολλαπλα paths στο idio destination, τωρα πλεον με σωστη μετρηση του costs, θα πρεπει να παραμεινουν.
chatasos
05/11/2003, 14:18
Αυτό με το passive interface (renos) έχω την εντύπωση πως έχει έννοια sto rip, αν τρέχεις rip v1 και το network που δηλώνεις "περιέχει" και άλλα interfaces μέσα.
Rip v1 δεν τρέχαμε ποτέ, ούτε πρόκειτε. Υπάρχει λόγος να έχουμε passive σε Rip v2?
Από την στιγμή που δηλώνετε interface και όχι network, ένας λόγος λιγότερος. :wink:
Επίσης στο rip, στο redistribution του ospf μήπως πρέπει να του βάλετε και το κατάλληλο metric ?
π.χ.
για να ανακοινώνεται σε λιγότερους routers με κίνδυνο όμως να μην φτάσει εκεί που πρέπει βάζετε κάποιο μεγάλο metric,
για να νακοινώνεται σε περισσότερους routers με κίνδυνο όμως για routing loops (ιδίως αν έχετε redundant links και πολλά redistributions) βάζετε κάποιο μικρό metric.
RIP θα μιλάει μόνο το AP με τους clients του που έχουν subnet (1 hop).
Επομένως δεν έχει και τόσο σημασία τι metric θα στείλει, αφού έτσι και αλλιώς μιλάμε για μοναδική διαδρομή, και μόνο 1 hop routers.
Το redistribute rip στο OSPF νομίζω φροντίζει μόνο του για το metric (να είναι μεγαλύτερο από κάθε πιθανό OSPF path).
Συμφωνείς;
Βάζει 20, οπότε δεν ξέρω αν σας καλύπτει....μιας και το metric του ospf είναι το cost που ορίζεται από το bw των interfaces (10^8/bw , bw=bits/sec).
chatasos, συμφωνα με το manual της Zebra, Section 5.5 το default metric για τα redistributed routes ειναι 1. Οποτε μας βολευει μια χαρα. Νομιζω οτι εχεις μπερδευτει με το default metric value για το IOS.
chatasos
05/11/2003, 15:13
chatasos, συμφωνα με το manual της Zebra, Section 5.5 το default metric για τα redistributed routes ειναι 1. Οποτε μας βολευει μια χαρα. Νομιζω οτι εχεις μπερδευτει με το default metric value για το IOS.
ok then :wink: :wink: αλλά δεν θα έπρεπε να γίνει μεγαλύτερο?
Η τιμη 1 στο metric ειναιπιστευω η σωστη, γιατι οι clients δεν απεχουν σε hops απο τον router πανω απο 1 hop.
Μην ξεχνας οτι απο την μια μεν πρεπει να σεβαστεις τα metrics του routing protocol στο οποιο κανεις redistribute τα routes απο ενα αλλο, απο την αλλη τα metrics σε καθε routing protocol ειναι διαφορετικα. Το RIP παιζει με hop count (1-16).
Παιδιά, συγνώμη για την μεγάλη απουσία μου από αυτή τη συζήτηση, αλλά ο επαγγελματικός μου χρόνος πιέζει βιαστικά και βάναυσα τον προσωπικό... (όλοι το έχουμε νοιώσει αυτό, σωστά;)
Λοιπόν, το θέμα των clients είναι ένα άλλο μεγάλο κομμάτι.
Τι γίνεται με τους clients που έχουν 2 ή και παραπάνω interfaces;
Αν δεν τρέχουμε κι εκεί OSPF, τότε δεν κάνουμε τίποτα... Χάνουμε πιθανόν καλύτερες διαδρομές για τον προορισμό των πακέτων...
Μήπως να το κάναμε πιο συγκεκριμένο ότι μιλάμε μόνο για clients του ενός interface;
Και σε αυτή τη περίπτωση, δεν είναι καν αναγκαία η εγκατάσταση router... Ένα απλό static route για το 10.0.0.0/8 είναι αρκετό, δε νομίζετε;
mindfox αυτο το προβλημα το αναφερω εγω λιγο πιο πανω οταν κανω την αναφορα για τα route loops.
Αν ενας client εχει 2 συνδεσεις σε ΑΡ και δεν εχει αλλους clients απο κατω(ασχετως αν εχει lan δικο του), τοτε ειναι προτιμοτερο να τρεχει RIP. Τα 2 APs που θα συνδεεται θα φροντισουν να "διοχετευσουν" τα routes μεσα απο OSPF στο backbone.
Αν η μια συνδεση του ειναι σε dedicated intterface (BB link) τοτε ακολουθει τον κανονα και τρεχει OSPF πανω σε αυτο το Link και RIP στο αλλο.
Θα προτεινα το OSPF να το περιορισουμε σε ΒΒ Links που γινονται σε dedicated interfaces με εξαιρεσεις οταν ο client του AP εχει και αυτος δικο του AP με πελατες.
Για αρχή αν ο client πέφτει σε 2 BB nodes είναι ιδική περίπτωση, αν το rip θα δουλέψει για την απλή περίπτωση. Η λύση είναι πάντως μία (σε αυτή την φάση ...) Ο χωρισμός σε areas ...
phronidis
06/11/2003, 11:19
Δεν καταλαβαίνω άν το Link του Πολυτεχνείου περνάει απο το OSPF όταν ο router προς το Πολυτεχνείο παίζει OSPF.
Δηλαδή όποιο interface δεν θέλεις να παίζει rip ή ospf το αφαιρείς απο το αντίστοιχο conf.
v.t.b. ο χωρισμος σε areas εχει σχεδον γινει. Οπως εχω πει, ενα ΑΡ με τους πελατες του οριζει πλεον ενα τετοιο area. Το θεμα εδω δεν ειναι να ενεργοποιησουμε OSPF πανω στο area ειδικα την στιγμη που βλεπεις οτι υπαρχουν αλλα προβληματα και θεματα που πρεπει να λυθουν.
Υπαρχουν, για παραδειγμα, πελατες με συνδεσεις σε δυο ΑΡ ή backbones Links τα οποια υλοποιουνατι με ΑΡs.
Το βασικο ειναι να βγαλουμε ενα μοτιβο για το ποιοι κομβοι θα τρεχουν ποιο routing protocol.
phronidis, το interface σου με το AP πανω στο οποιο πεφτουν πελατες θελεις να τρεχει RIP σιγουρα και σε εξαιρεσεις OSPF οταν καποιος εχει κανει ΒΒ link με το ΑΡ σου. Τα interfaces που κανεις ΒΒ links θελεις να τρεχουν OSPF.
chatasos
06/11/2003, 14:33
Η τιμη 1 στο metric ειναιπιστευω η σωστη, γιατι οι clients δεν απεχουν σε hops απο τον router πανω απο 1 hop.
Μην ξεχνας οτι απο την μια μεν πρεπει να σεβαστεις τα metrics του routing protocol στο οποιο κανεις redistribute τα routes απο ενα αλλο, απο την αλλη τα metrics σε καθε routing protocol ειναι διαφορετικα. Το RIP παιζει με hop count (1-16).
Νομίζω ότι αναφερόμαστε στο redistribute rip κάτω από το ospf για την συγκεκριμένη περίπτωση. Δηλαδή πως θα τα ανακοινώνει το ospf στο υπόλοιπο backbone.
Η τιμη 1 στο metric ειναιπιστευω η σωστη, γιατι οι clients δεν απεχουν σε hops απο τον router πανω απο 1 hop.
Μην ξεχνας οτι απο την μια μεν πρεπει να σεβαστεις τα metrics του routing protocol στο οποιο κανεις redistribute τα routes απο ενα αλλο, απο την αλλη τα metrics σε καθε routing protocol ειναι διαφορετικα. Το RIP παιζει με hop count (1-16).
Νομίζω ότι αναφερόμαστε στο redistribute rip κάτω από το ospf για την συγκεκριμένη περίπτωση. Δηλαδή πως θα τα ανακοινώνει το ospf στο υπόλοιπο backbone.
OK, το επιασα τωρα.
Το OSPF τα ανακοινωνει σαν Type 2 external routes στο υπολοιπο backbone (metric-type 2 στην Zebra) οποτε δεν ειναι αναγκη να κανεις αλλαγες με το χερι.
Ανακεφαλαιώνω:
1) Όλοι οι backbone κόμβοι τρέχουν OSPF σε όλα τους τα interfaces
2) Οι πελάτες με subnet τρέχουν MONO RIP
3) Οι backbone συνδέσεις μέσω AP γίνοναι MONO ME OSPF
4) Οι κόμβοι με AP τρέχουν στο AP Interface ΚΑΙ OSPF KAI RIP (το πρώτο για το 3, το δεύτερο για το 2)
5) Στο 4 μπορείτε να μην τρέξετε το ένα από τα δυο αν δεν έχετε τέτοιου τύπου συνδέσεις
Κατανοητό;
Ανακεφαλαιώνω:
...
3) Οι backbone συνδέσεις μέσω AP γίνοναι MONO ME OSPF
...
Εδω καλο ειναι να κανουμε εναν διαχωρισμο και να πουμε οτι οι συδνεσεις Backbone σε ΑΡ θα τρεχουν OSPF ΜΟΝΟ αν εχουν ΑΡ με πελατες.
Ετσι καποιος που εχει πχ. 2 backbone conenctions σε 2 APs αλλα δεν εχει clients θα εκμεταλλευεται το RIΡ που τρεχει το καθε AP.
Εδω καλο ειναι να κανουμε εναν διαχωρισμο και να πουμε οτι οι συδνεσεις Backbone σε ΑΡ θα τρεχουν OSPF ΜΟΝΟ αν εχουν ΑΡ με πελατες.
Ετσι καποιος που εχει πχ. 2 backbone conenctions σε 2 APs αλλα δεν εχει clients θα εκμεταλλευεται το RIΡ που τρεχει το καθε AP.
ΟΧΙ. Θα τρέχει OSPF. Δεν μπορεί να βγάλει αποφάσεις βασιζόμενος στο RIP, γιατί κανένας δεν θα τον θεωρεί κομμάτι του backbone.
Μόνος σου είπες ότι τα RIP routes θεωρούνται external και τους δίνεται ελάχιστη προτεραιότητα. Επομένως θα προτιμήσει το backbone να πάει από το OSPF Path, ακόμα και αν έχει μεγαλύτερο κόστος τελικά.
Achille, ο χρηστης που δεν εχει πελατες σε ΑΡ δεν εχει κανενα λογο να τρεχει OSPF. Ο ρολος του στην ουσια ειναι πελατης 2 ΑΡ και δημιουργει μια εξωτερικη συνδεση με το 2ο που συνδεεται.
Σχετικα με τετοιου ειδους links ειχα πει οτι υπαρχουν 2 δρομοι:
α) ειτε φιλτραρουμε τα RIP routes που περνανε
β) ειτε τα αφηνουμε να περνανε οριζοντας ετσι 2 διαδρομες προς τον ιδιο προορισμο.
Για πείτε και σ'εμένα καμιά ιδέα για το setup της zebra. Εκανα copy-paste το τελευταίο setup που έκανε post ο Αχιλλέας, αλλά δεν μου έπαιξε (δεν έπαιρνα από πουθενά routes, ούτε rip). Η σειρά που τα έτρεξα είναι zebra-ripd-ospfd με -d -f και τα τρία. Το daemons το βάζουμε στον κατάλογο που είναι τα υπόλοιπα .conf?
1) eth0 local
2) eth1 ap
3) eth2 b/b #1
4) eth3/ppp0 dsl
5) wlan0 b/b test #3
6) wlan1 b/b #2
[zebra.conf]
hostname talos.home.nasos.awmn
log file /var/log/zebra/zebra.log
line vty
[ripd.conf]
hostname talos.home.nasos.awmn
log file /var/log/zebra/ripd.log
router rip
network eth1
redistribute ospf
distribute-list awmn in eth1
distribute-list awmn out eth1
access-list awmn permit 10.0.0.0/8
access-list awmn permit 147.102.0.0/16
access-list awmn deny any
[ospfd.conf]
hostname talos.home.nasos.awmn
interface eth0
interface eth1
interface eth2
interface eth3
interface wlan0
interface wlan1
router ospf
ospf router-id 10.80.181.65
network 10.0.0.0/8 area 0
redistribute rip
log file /var/log/zebra/ospfd.log
Τι έγινε βρε παιδιά; Το αμίλητο νερό; :x :x :x
AWMN 2010
Powered by vBulletin™ Version 4.1.4 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.