show ip eigrp topology all-links

 

Oggi ho capito meglio come funziona la topology table generata da EIGRP.

 

NOTA sulla mappa:

i valori riportati in rosso sui collegamenti sono i valori di DELAY effettivamente configurati sulle interfacce che sui link si affacciano.
I valori di metrica nella topology table sono reali e ottenuti dopo aver configurato i “pesi” della formula EIGRP per il calcolo della metrica con il seguente comando:

metric weights 0 0 0 1 0 0

che vuol dire: “considera solo il delay per il calcolo della metrica”.

————————————————–

Note sullo split-horizon

 

http://ardenpackeer.com/routing-protocols/tutorial-troubleshooting-split-horizon-issues-part-1/

 

http://ardenpackeer.com/routing-protocols/tutorial-troubleshooting-split-horizon-issues-part-2/

 

Leggendo i due casi di studio sullo split-horizon che riporto qui sopra, ho imparato le seguenti cose:

 

Note sul RIP e l’approccio “Distance Vector”

 

Il RIP, in quanto protocollo basato sull’algoritmo “Distance Vector” (DV), risente di alcune debolezze dell’algoritmo stesso.

 

In sostanza il DV puo’ andare incontro a quello che in letteratura viene chiamato il “Count-to-Infinity” problem.

 

L’algoritmo presenta tempi lunghi di convergenza (comunque converge!) quando deve propagare notizie “negative”, cioe’ aumenti del costo delle rotte.

 

Durante la fase di convergenza , le tabelle di instradamento dei nodi (router) della rete possono presentarsi incoerenti tra di loro e dare luogo ad anelli di instradamento, routing loops.

 

I loops naturalmente vengono meno quando l’algoritmo arriva a convergere, ma la loro presenza puo’ durare diversi minuti, con tutte le conseguenze che questo comporta sul traffico “routed”.