!
!Ευχαριστω
Γειά σου Θάνο,
EIGRP
1) Δεν καταλαβαίνω καλά την απορία σου - αν θες στείλε μου το σημείο που διάβασες αυτό που γράφεις. Πάντως "255" είναι η τιμή του αριθμητή στο κλάσμα του reliability και του load του EIGRP.
Θυμήσου στην παρουσίαση της 7ης:
- Δείχνει το reliability σαν ένα κλάσμα του 255, για παράδειγμα (όσο υψηλότερο τόσο το καλύτερο):
rely 190/255 (ή 74% reliability)
rely 234/255 (ή 92% reliability)
rely 255/255 (ή 100% reliability)
- Δείχνει το load σαν ένα κλάσμα του 255, για παράδειγμα (όσο μικρότερο τόσο το καλύτερο):
load 10/255 (ή 3% loaded link)
load 40/255 (ή 16% loaded link)
load 255/255 (ή 100% loaded link)
Επιπλέον αν αναφέρεσαι στο αυτόματο redistribution (δηλ. χωρίς επιπλέον configuration) μεταξύ eigrp<--->igrp, τότε ισχύει αυτό που γράφει το βιβλίο:
If you enable EIGRP on a router with the same autonomous system (AS) number, EIGRP will automatically redistribute IGRP into EIGRP. You will see the IGRP injected routes as external (EX) routes with an EIGRP AD of 170. This is a nice feature that lets you migrate slowly to EIGRP with no extra configuration.
-----------------------------------
2) Όλα τα tables έχουν ένα μέγιστο αριθμό κατχωρήσεων βάση του είδους του δρομολογητή (δηλ ένασ ISR2800 "μικρός" router έχει πολύ μικρότερο table μέγεθος από ένα core router τύπου 7600 ή 12000), της μνήμης του δρομολογητή, και του IOS version που τρέχει. Γενικότερα ο περιορισμός υπάρχει συνολικά στα IPv4 routes που μπορεί να καταχωρήσει ο δρομολογητής και όχι για τα επιμέρους Tables. Επίσης μπορούμε σε κάποια πρωτόκολλα να παραμετροποίησουμε τον μέγιστο αριθμό routes που αφήνουμε να μας κάνει advertise ο συγκεκριμένος "γείτονας" και να μας βγαίνει στο CLI ένα warning αν πιάσει κάποιο ποσοστό (π.χ. το 70% του παραμετροποιημένου ορίου) ώστε να μπορούμε να προβούμε proactively σε ενέργειες. Θύμησε μου να το πούμε στο μάθημα - αν και είναι εκτός ύλης CCNA...
Για να έχουμε ένα feasible route πρέπει να τηρείται το feasible condition. Όποιο route (εκτός βέβαια από τον active successor) τηρεί αυτό το κριτήριο θα χρίζεται αυτόματα Feasible successor. Αυτή είναι η default συμπεριφορά του πρωτοκόλλου και δεν μπορείς να την αλλάξεις μέσω CLI (έτσι και αλλιώς πιο το νόημα να μην έχεις παραπάνω από ένα feasible route στο Topology Table - οχι στο RT όπως λές - για επιπλέον quicκ redundancy).
OSPF
1) To DR/BDR election έχει νόημα πάντα σε ένα Broadcast Multi-Access (e.g. Ethernet LAN) enviroment. Πέρα από αυτό η έννοια του συγκεκριμένου DR/BDR δεν έχει καμία σημασία. Οπότε για ένα LAN που πατάει ένας router (μέσω ενός FE interface) μπορεί να είναι DR, ενώ σε ένα άλλο LAN που πατάει (μέσω GE interface) να είναι BDRκτλ.
2) Το wildcard είναι το Inverse της Subnet-mask Και μας βοηθάει στο να κάνουμε "match" δίκτυα στα interface του router μας και να τα διαφημίζουμε στο OSPF σαν Internal routes. Θα καταλάβεις την έννοια της καλύτερα στο μάθημα.
3) Το OSPF auth (είτε clear-text pwd ή MD5 encrypted) είναι ένα επιλπέον μέσω security για το διαχειριστή ώστε να μην αφήνει δύο routers να σηκώνουν ospf neighborship απευθείας (που είναι η default συμπεριφορά). Όπως ακριβώς και στο RIP. Θα το πούμε και στο μάθημα ξανά (δυστηχώς έλειπες στο επιπλέον Lab που αναφερθήκαμε σε αυτό).
4) Η διαδικασία εκλογής DR και BDR σε ένα BMA segment ( π.χ. Etehrnet LAN) γίνεται προτού έρθει το Neighborship των δρομολογητών που "πατούν" σε αυτό το segment σε "Full" state και άρα να μπορούν να προωθούν πακέτα ο ένας στον άλλο. Η εκλογή γίνεται βάση priority+router-id. Υπάρχει η multicast address 224.0.0.5 όπου κάθε DR-other router ενημερώνει τους DR και BDR για της τοπικές αλλαγές (LSAs) αλλά και η 224.0.0.6 που ΄"απαντούν" DR/BDR και μιλούν και μεταξύ τους. O DR είναι υπεύθυνος στο να ενημερώνει τους άλλους DR-other router με LSUs για της αλλάγες που έμαθε από κάποιον DR-other router συγκεκριμένα. O BDR απλά μαθαίνει σιωπηλά της ενημερώσεις εφόσον μέσω 224.0.0.6 καταλαβαίνει ότι υπάρχει ο DR, και όταν καταλάβει ότι έπεσε αναλαμβάνει απευθείας αυτός σαν νέος DR ενώ εκλέγεται μεταξύ των άλλων καινούργιος BDR. Όταν ο παλιός DR ανέβει ξανά (έστω ότι έκανε cold-start) δεν ξανα-αναλαμβάνει καθήκοντα όπως πριν έστω και αν έχει μεγαλύτερο priority από όλους στο LAN - δηλ. το DR election δεν είναι preemptive. Για να ξαναγίνει DR θα πρέπει να κάνουμε clear to OSPF Process ταυτόχρονα σε όλους τους routers του LAN ή ταυτόχρονο reload.
Άρης
Πιστεύω αυτήν την εβδομάδα να ρεφάρω.