Il 20 gennaio 2011 20:46, Francesco Crippa <[email protected]> ha scritto: > Marco, mi sa che hai centrato esattamente il problema. > >> secondo il mio parere, si tratta di un comportamento nella norma per un >> protocollo distance vector >> {[(senza aprire annose polemiche tra "hybrid" ecc.ecc.)]} >> > > ! lines omitted for brevity > >> In questo modo, R1 annuncia correttamente la rete connessa 10.0.0.0/24, ma >> su R2 "vince" la statica in quanto ha Administrative Distance piu' bassa. > > ! lines omitted for brevity > >> ora, che fa R2? Cosa annuncia a R3? >> >> annuncia: >> -le rotte apprese via EIGRP che ha installato in tabella di routing >> -le rotte che lui stesso dichiara in EIGRP > > Ha senso, ma... perchè guarda anche la routing table? Mi aspettavo > (forse erroneamente) che l'EIGRP guardasse solo la topology table e > poi facesse altri ragionamenti solo su di essa per stabilire se > annunciare o meno una rete, tipo feasibility condition, etc. > > In fondo stiamo parlando solo del fatto che impara una rotta tramite > un protocollo di routing e la annuncia a sua volta. Forse mi sono > perso io qualche dettaglio dell'EIGRP. > > Grazie a tutti > > Saluti > Francesco
Confermo tutto il discorso della distanza amministrativa, anche se studiando la teoria me l'ero completamente persa sta cosa :S Quando il router apprende la stessa rotta da una sorgente con distanza amministrativa diversa, l'EIGRP considera la sua rotta nativa invalida, manda addirittura delle query ai vicini per avere notizie! In lab ho simulato la stessa situazione: R1 - R2 - R3 dove i tre router si parlano EIGRP. R1 annuncia la 10.3.100.0/24. Ad un certo punto ho configurato anche OSPF tra R1 ed R2 per le stesse reti. Ho modificato la distanza amministrativa di OSPF per farla diventare minore di quella di EIGRP. Quando OSPF sale, su R2 si vede: R2# *Jan 29 21:13:46.295: %OSPF-5-ADJCHG: Process 1, Nbr 10.3.100.223 on FastEthernet0/0 from LOADING to FULL, Loading Done *Jan 29 21:13:51.775: RT: closer admin distance for 10.3.100.0, flushing 1 routes *Jan 29 21:13:51.775: RT: NET-RED 10.3.100.0/24 *Jan 29 21:13:51.775: RT: SET_LAST_RDB for 10.3.100.0/24 NEW rdb: via 172.31.0.1 *Jan 29 21:13:51.775: RT: add 10.3.100.0/24 via 172.31.0.1, ospf metric [110/2] *Jan 29 21:13:51.775: RT: NET-RED 10.3.100.0/24 *Jan 29 21:13:51.775: DUAL: lostroute: force active state *Jan 29 21:13:51.775: DUAL: Find FS for dest 10.3.100.0/24. FD is 0, RD is 30720 *Jan 29 21:13:51.775: DUAL: 172.31.0.1 metric 30720/28160 not found Dmin is 30720 *Jan 29 21:13:51.775: DUAL: Peer total 2 stub 0 template 2 *Jan 29 21:13:51.775: DUAL: Dest 10.3.100.0/24 entering active state. *Jan 29 21:13:51.775: DUAL: Set reply-status table. Count is 2. *Jan 29 21:13:51.775: DUAL: Not doing split horizon *Jan 29 21:13:51.839: DUAL: rcvreply: 10.3.100.0/24 via 172.31.0.1 metric 30720/28160 *Jan 29 21:13:51.843: DUAL: reply count is 2 *Jan 29 21:13:51.843: DUAL: Clearing handle 0, count now 1 *Jan 29 21:13:51.863: DUAL: dest(10.3.100.0/24) active ... _______________________________________ Articoli CISCO: http://www.areanetworking.it/category/cisco [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
