Όγκος routing table

[v.t.b.]

Καλημέρα και από μέρους μου.
Αυτό το οποίο θέλω να αναφέρω (καλά, καλά να γκρινιάξω) είναι ο όγκος, και ο τρόπος, που διακεινίτε η routing πληροφορία (όχι το προτόκολο, αλλα ρυθμίσεις).
αυτή την στιγμή, με κάποια nodes ?? πεσμένα, το route table στον nikolas έχει ως εξείς:
awmn-nikolas:~# route -n |grep -v ^192|grep -v ^0.|grep -v ^10.21.121|wc -l
112
Με μεγάλο αριθμό εγγραφών της μορφής: (Οι πρώτες που έκανε clopy paste ο αρουραίος μου)

10.87.183.216 10.21.122.209 255.255.255.248 UG 92 0 0 eth3
10.87.183.208 10.21.122.209 255.255.255.248 UG 92 0 0 eth3
10.87.183.200 10.21.122.209 255.255.255.248 UG 92 0 0 eth3
10.87.183.192 10.21.122.209 255.255.255.248 UG 92 0 0 eth3
10.87.183.224 10.21.122.209 255.255.255.248 UG 82 0 0 eth3

Μήπως λέω πρέπει να γίνει μια σιζήτιηση σχετικά με την διαμόρφωση του routing ( ή καλύτερα την ύπαρξη για αρχή route aggregation) ?

[paravoid]

Αφού θες συζήτηση γιατί δεν το κάνεις νέο topic; Το έκανα split εγώ.

Όταν συζητάγαμε για OSPF θυμάμαι που έλεγαν κάποιοι γνωρίζοντες για route summarization. Αυτό μπορεί να γίνει έστω και σε επίπεδο AP; Δηλαδή το AP να στέλνει προς τα έξω ένα route /24 και όχι πολλά 8αράκια των clients του (που φαίνεται πως είναι και αυτό που κυρίως σε ενοχλεί -δικαίως- v.t.b).
Το μήνυμα είναι σε μορφή ερώτησης καθώς δεν έχω ιδέα για το παραπάνω θέμα. Θα μπορούσε να μας διαφωτίσει κάποιος που γνωρίζει από OSPF & route summarization;

[v.t.b.]

Εισε άψογος ( για αρχή για το split ...)

Η αλήθεια είναι ότι δεν με ενοχλεί μόνο το να μην υπάρχει route aggregation, αλλά από καπου πρέπει να ξεκινίσουμε :)
Δυστηχώς, και ανασύροντας πράγματα από παλεές μνήμες (άρα και με μεγάλες πιθανότιτες λάθους ...) το ospf λόγο του ότι έχει σχεδιαστεί σαν IGP προτόκολο δεν διαθέτει τέτιες λογικές και δεν είναι και οικονομικό στην χρήση του bandwidth και της CPU (θέμα [2]). Ο ποιό γρήγορος τρόπος για να γίνει route summarization (όπως μου έρχεται) είναι να κάνεις στον ospf daemon ένα static route και να ενεργοποιήσεις το redistribute των static routes και όχι των connected, αυτό αν δεν με απατά η μνήμη μου το είχα δοκιμασει και είχε παίξει, αλλά better safe than sory . Τώρα αναφορικά με το [2] θέλει δουλίτσα, καφεδάκια, πίνακα και μαρκαδόρους :)

[Achille]

Ο ποιό γρήγορος τρόπος για να γίνει route summarisation (όπως μου έρχεται) είναι να κάνεις στον ospf daemon ένα static route και να ενεργοποιήσεις το redistribute των static routes και όχι των connected,

Αυτό είναι λάθος πρακτική, γιατί δεν είναι καθαρή λύση. Επίσης τα static routes στο OSPF έρχονται σαν external links και όχι σαν backbone links.

Αν υπάρχει δυνατότητα οι routers να κάνουν summary στα routes, εξαρτάται από την υλοποίηση, νομίζω πως σε Cisco γίνεται, σε zebra δεν γνωρίζω, ας διαβάσει κάποιος το info να μας πει.

Πιο σοβαρό θέμα είναι ο υπολογισμός του κόστους των links (ανάλογα με την κατάστασή τους), παρά το summarisation, από εκεί να ξεκινήσουμε.

[HdkiLLeR]

Πιο σοβαρό θέμα είναι ο υπολογισμός του κόστους των links (ανάλογα με την κατάστασή τους), παρά το summarisation, από εκεί να ξεκινήσουμε.

Συμφωνώ και εγώ με το παραπάνω μιας και οπως έχω πει σε διάφορους κατά καιρούς ας βάλουμε ένα σωστό cost επιτέλους και μετά τα υπόλοιπα.Μάνι μάνι θα λύσουμε ένα κάρο προβλήματα και θα έχουμε και κατα ένα βαθμό πιο σταθερό δίκτυο(καλά αυτό ένας λόγος είναι γιατί έτσι όπως είναι μερικά bb στα 2.4 φέξε μου και γλύστρησα):)