Problema rotta EIGRP

[zot]

ehm... concetto totalmente errato. Summarizzare porta ad avere una routing table piu' piccola, meno spreco di risorse, di update e soprattutto un'immagine di rete piu' "fluida". Una rete dietro summary che flappa non verra' mai ricalcolata da un segmento di rete dall'altra parte del network

Il problema del summarization nel mio caso ormai è senza soluzione perchè ho tutti i collegamenti punto-punto tra il centro stella (3750 o 4500) e i 2811 che gestiscono le FR delle varie sedi appoggiati su delle 10.0.x.x perciò se lascio la summarizzazione mi autocastro.... temo, corretto ?

E' proprio quello che ti ho riportato nel link prima : http://www.cisco.com/en/US/tech/tk365/t ... fexternals e che forse ha causato il tuo problema.

Non dovrebbe ,comunque, intervenire la metrica ad evitare il default e relativa congestione dei link FR?

Perchè ? Non capisco ? In caso di congestione EIGRP se ne accorge ?

EIGRP non sbaglia a distribuire la metrica. Se le sedi remote non sono impostate come stub ed il DUAL calcola in quel determinato momento che la rotta migliore e' passare attraverso una sede, l'unico modo per evitarlo e' appunto lo stub routing.

Essendo i parametri per decidere la metrica : Bandwidth(Solitamente l'unico parametro ad essere impostato manualmente),Delay,Reliability,Loading,mtu(sull'ultimo non sono sicuro), tericamente,EIGRP,dovrebbe accorgersi della congestione.
La mia era appunto una domanda rivolta a Intel che ,sull'argomento routing in generale e EIGRP in particolare, e' molto piu' ferrato di me.

Ogni quanto vengono ricalcolate le rotte ?
(P.S. cosa intendi con DUAL ? )

Dopo la perdita consecutiva di 3 pacchetti HELLO(ogni hello-interval puo' variare dai 5 ai 60 sec. ma puo' essere impostato manualmente)..confermi Intel?
Il DUAL e' l'algoritmo di "convergenza" dell 'EIGRP, ed e' lui che si preoccupa di far convergere la rete.

P.S. se imposti la sede I come stub, non viene tagliato fuori. Hai bisogno di ridondanza nella sede I e che passi da J oltre che dall'HUB? Basta lasciare a default J... (spero di essermi spiegato)

Possiamo quindi dire che in ,ambito EIGRP, l'affermazione "tutti i router tramite i quali non si puo' andare da nessuna parte debbono essere impostati come stub" e' corretta?

[Gianremo.Smisek]

Il problema del summarization nel mio caso ormai è senza soluzione perchè ho tutti i collegamenti punto-punto tra il centro stella (3750 o 4500) e i 2811 che gestiscono le FR delle varie sedi appoggiati su delle 10.0.x.x perciò se lascio la summarizzazione mi autocastro.... temo, corretto ?

al momento mi trovo un po' impacciato
se posti un disegno topologico, cosi' da capire bene tutto, possiamo valutare la cosa

Capisco e posso essere d'accordo in linea di massima ed è per quello che sto cercando di mettere i pesi corretti su ogni tratta; vorrei che la topologia fosse cambiata solo nel momento in cui c'è un fault e non in caso di congestione. Ogni quanto vengono ricalcolate le rotte ?
(P.S. cosa intendi con DUAL ? )

le rotte vengono ricalcolate solo in caso di fault. EIGRP manda l'aggiornamento SOLO ai router che ne hanno bisogno e manda SOLO la parte della routing table che interessa, non tutta.
In caso di congestione, EIGRP non dovrebbe ricalcolare nulla, semplicemente la metrica aumenta e dovrebbe scegliere (se c'e') un altro path nella RIB/routing table.

il DUAL = Diffusing Update ALgorithm e' il cuore di EIGRP

Cosa intendi

Basta lasciare a default J...

?

intendo che non lo setti come stub

Mi confermi che I, impostato come stub router, non verrà mai attraversato per raggiungere la sede principale da J se a J cade la FR ? Perchè in questo caso torno al discorso di prima: mi torna utile I come transit network.

si te lo confermo... e purtroppo se cade la FR non lo attraversa. Pero' puoi sempre 'fregarlo' in altro modo... magari, un controllo con IP SLA.


ciao!

[Gianremo.Smisek]

Essendo i parametri per decidere la metrica : Bandwidth(Solitamente l'unico parametro ad essere impostato manualmente),Delay,Reliability,Loading,mtu(sull'ultimo non sono sicuro), tericamente,EIGRP,dovrebbe accorgersi della congestione.
La mia era appunto una domanda rivolta a Intel che ,sull'argomento routing in generale e EIGRP in particolare, e' molto piu' ferrato di me.

scusa, prima non mi sono espresso bene forse. Si, EIGRP si accorge della congestione (tutti i proto lo fanno, altrimenti sarebbero useless ). Pero' nel caso di cui sopra, io intendevo che se una stub network viene interessata come transito (e quindi in quel determinato momento e' scarica), puo' congestionarsi a causa di tutto il traffico che poi ci passera'. (oddio, mi spiego da far schifo, se non avete capito, ditemelo che mi spiego in maniera migliore )

Dopo la perdita consecutiva di 3 pacchetti HELLO(ogni hello-interval puo' variare dai 5 ai 60 sec. ma puo' essere impostato manualmente)..confermi Intel?
Il DUAL e' l'algoritmo di "convergenza" dell 'EIGRP, ed e' lui che si preoccupa di far convergere la rete.

scusami, ho risposto prima a Rizio, non avevo visto il tuo post.
Yep, correttissimo, 60 secondi per le interfacce "slower" e 5 per le serial/ethernet/lan

Possiamo quindi dire che in ,ambito EIGRP, l'affermazione "tutti i router tramite i quali non si puo' andare da nessuna parte debbono essere impostati come stub" e' corretta?

yep, esattamente