Per calcolare il valore metrico, il protocollo IGRP (Interior Gateway Routing Protocol) somma i valori ponderati delle diverse caratteristiche del collegamento alla rete in questione. Le caratteristiche del collegamento da cui IGRP calcola una metrica composita sono larghezza di banda, ritardo, carico, affidabilità e MTU (Maximum Transmission Unit). Per impostazione predefinita, il protocollo IGRP sceglie un percorso in base alla larghezza di banda e al ritardo.
Questo documento è utile per conoscere i seguenti argomenti:
IGRP e funzionalità correlate
Nota: per ulteriori informazioni, vedere Introduzione alla tecnologia IGRP.
Le informazioni fornite in questo documento si basano sulle versioni software e hardware:
Software Cisco IOS® versione 12.2(24a)
Cisco serie 2500 Router
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
In questa sezione viene illustrato un esempio per trovare la metrica quando il protocollo di routing è IGRP.
Il diagramma per lo scenario specificato è il seguente:
Di seguito è riportata la formula utilizzata per calcolare la metrica composita per IGRP:
Metrica = [K1 * Larghezza di banda + (K2 * Larghezza di banda)/(carico 256) + K3*Ritardo] * [K5/(affidabilità + K4)]
I valori costanti di default sono K1 = K3 = 1 e K2 = K4 = K5 = 0.
Se K5 = 0, il termine [K5/(affidabilità + K4)] non viene utilizzato. Pertanto, dati i valori predefiniti da K1 a K5, il calcolo metrico composito utilizzato da IGRP si riduce a Metrica = Larghezza di banda + Ritardo.
I valori K in queste formule sono costanti che è possibile definire con il comando di configurazione del router metric Weights (pesi metrici) tos k1 k2 k3 k4 k5 (k1 k2 k3 k5).
Nota: Cisco consiglia di non modificare i parametri K predefiniti.
Per calcolare la larghezza di banda, individuare la più piccola tra tutte le larghezze di banda in Kbps delle interfacce in uscita e dividere 10.000.000 per tale numero. La larghezza di banda viene scalata di 10.000.000 in kilobit al secondo.
Per trovare il ritardo, aggiungere tutti i ritardi (in microsecondi) dalle interfacce in uscita e dividere questo numero per 10. Il ritardo è espresso in decimi di microsecondi.
Tenete presente che il percorso con la metrica più piccola è il percorso migliore.
I vari output dei comandi show per entrambi i router sono come mostrato di seguito:
Venus# show interfaces ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0060.5cf4.a9a8 (bia 0060.5cf4.a9a8) Internet address is 12.1.1.1/24 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Venus# show interfaces serial 0 Serial0 is up, line protocol is up Hardware is HD64570 Internet address is 172.16.10.2/24 MTU 1500 bytes, BW 784 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec) LMI enq sent 981, LMI stat recvd 330, LMI upd recvd 0, DTE LMI up LMI enq recvd 340, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Saturn# show interfaces serial 1 Serial0 is up, line protocol is up Hardware is HD64570 Internet address is 172.16.10.1/24 MTU 1500 bytes, BW 224 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec) LMI enq sent 167, LMI stat recvd 168, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Saturn# show interfaces ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0060.5cf4.a955 (bia 0060.5cf4.a955) Internet address is 172.17.10.1/16 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set
È possibile visualizzare i valori delle metriche calcolati da IGRP con il comando show ip route:
Venus# show ip route 172.17.10.1 Routing entry for 172.17.0.0/16 Known via "igrp 100", distance 100, metric 14855 Redistributing via igrp 100 Advertised by igrp 100 (self originated) Last update from 172.16.10.1 on serial0, 00:00:13 ago Routing Descriptor Blocks: * 172.16.10.1, from 172.16.10.1, 00:00:13 ago, via Serial0 Route metric is 14855, traffic share count is 1 Total delay is 21000 microseconds, minimum bandwidth is 784 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 0
I calcoli corrispondenti sono:
Metrica = Larghezza di banda + Ritardo = 10000000/784 + (2000 + 1000)/10 = 14855
Saturn# show ip route 12.1.1.1 Routing entry for 12.0.0.0/8 Known via "igrp 100", distance 100, metric 46742 Redistributing via igrp 100 Advertised by igrp 100 (self originated) Last update from 172.16.10.2 on serial1, 00:00:43 ago Routing Descriptor Blocks: * 172.16.10.2, from 172.16.10.2, 00:00:43 ago, via Serial1 Route metric is 46742, traffic share count is 1 Total delay is 21000 microseconds, minimum bandwidth is 224 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 0
I calcoli corrispondenti sono:
Metrica = Larghezza di banda + Ritardo = 10000000/224 + (2000 + 1000)/10 = 46742
Il valore predefinito della costante K2 è zero. Se K2 è impostato su 1, load diventa una variabile utilizzata nel routing. Il problema sembra essere il salto del carico. Se il costo della metrica salta all'inizio di una sessione FTP, è possibile che la route entri in attesa a causa dell'aumento. Con quale frequenza viene calcolato il carico?
Il carico è una media ponderata esponenzialmente di cinque minuti che viene aggiornata ogni cinque secondi.
È possibile che il valore del carico aumenti abbastanza rapidamente da rendere la route instabile?
Sì. E peggio ancora, quando il carico cala, il sistema metrico diminuisce. Questo errore causa un aggiornamento Flash.
Poiché il costo metrico composito per un determinato sito è determinato dal collegamento più lento nel percorso e il collegamento più lento è in genere la linea di accesso nel cloud, come è possibile configurare IGRP per utilizzare il percorso più veloce nel cloud di rete?
Dopo aver determinato il collegamento più lento, il resto del routing viene eseguito sugli hop (ritardo), a prescindere dalla velocità dei collegamenti hop. A causa dei grandi gap nei valori della larghezza di banda, non sembra pratico provare a usare il ritardo per influenzare il routing del cloud di rete. Una soluzione ovvia consiste nel configurare il comando bandwidth sulle linee di accesso in modo che sia più veloce di qualsiasi linea backbone del cloud di rete.
Un'altra soluzione è configurare il ritardo sui collegamenti WAN in modo che sia una misurazione accurata del ritardo per quel particolare collegamento. Non dovrebbe essere necessario affinare i ritardi e il routing dovrebbe essere corretto.
È sicuramente utile modificare le larghezze di banda sulla linea di accesso se si dispone di larghezze di banda radicalmente diverse all'interno della WAN.
Utilizzare il comando default-metric per impostare la metrica per le route ridistribuite. Questa dichiarazione è appropriata per la maggior parte dei casi:
Venus(config)# router igrp 100 Venus(config-router)# default-metric 10000 100 255 1 1500
dove 10000 = Larghezza di banda, 100 = Ritardo, 255 = Affidabilità, 1 = Caricamento e 1500 = MTU.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
10-Aug-2005 |
Versione iniziale |