Interior Gateway Routing Protocol (IGRP) voegt gewogen waarden van verschillende kenmerken van de link naar het netwerk in kwestie toe om een metriek te berekenen. De verbindingskenmerken waarvan IGRP een samengestelde metriek berekent zijn bandbreedte, vertraging, lading, betrouwbaarheid, en maximum transmissieeenheid (MTU). IGRP kiest standaard een route gebaseerd op bandbreedte en vertraging.
Lezers van dit document zouden kennis moeten hebben van deze onderwerpen:
IGRP en verwante functies
Opmerking: Raadpleeg Een Inleiding naar IGRP voor meer informatie.
De informatie in dit document is gebaseerd op de software- en hardwareversies:
Cisco IOS®-softwarerelease 12.2(24a)E
Cisco 2500 Series routers
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Deze sectie gebruikt een voorbeeld om te illustreren hoe de metriek te vinden wanneer IGRP het routingprotocol is.
Het schema voor het gegeven scenario wordt hier gegeven:
Hier is de formule die wordt gebruikt om de samengestelde metriek voor IGRP te berekenen:
Metriek = [K1 * Bandbreedte + (K2 * Bandbreedte)/(256-belasting) + K3*Vertraging] * [K5/(betrouwbaarheid + K4)]
De standaardconstante waarden zijn K1 = K3 = 1 en K2 = K4 = K5 = 0.
Indien K5 = 0 wordt de term [K5/(betrouwbaarheid + K4)] niet gebruikt. Gezien de standaardwaarden voor K1 tot en met K5 vermindert de samengestelde metrische berekening die door IGRP wordt gebruikt tot Metriek = Bandbreedte + Vertraging.
De K waarden in deze formules zijn constanten die u met de opdracht van de routerconfiguratie kunt definiëren, metrische gewichten naar k1 k2 k3 k4 k5 .
Opmerking: Cisco suggereert sterk dat u de standaard K parameters niet wijzigt.
Om de bandbreedte te vinden, vind de kleinste van alle bandbreedte in Kbps van uitgaande interfaces en verdeel 10.000.000 door dat aantal. (De bandbreedte wordt per seconde met 10.000.000 in kilobits geschaald.)
Om de vertraging te vinden, voegt u alle vertragingen (in microseconden) toe van de uitgaande interfaces en verdeel dit aantal met 10. (De vertraging is in tiende van microseconden).
Onthoud, het pad met de kleinste metriek is het beste pad.
De verschillende uitgangen van de opdrachten van de show zijn voor beide routers zoals hier wordt getoond:
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
U kunt de metrische waarden die door IGRP met de opdracht tonen ip worden berekend bekijken:
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
De bijbehorende berekeningen zijn:
Metriek = bandbreedte + vertraging = 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
De bijbehorende berekeningen zijn:
Metriek = bandbreedte + vertraging = 10000000/224 + (2000 + 1000)/10 = 46742
De constante K2 staat op nul. Als K2 op 1 is ingesteld wordt load een variabele die in het routing wordt gebruikt. Het probleem lijkt te zijn als de lading springt. Als de metrische kosten springen aan het begin van een FTP sessie, is het mogelijk voor de route naar holddown door de toename. Hoe vaak wordt de lading berekend?
De lading is een exponentieel gewogen gemiddelde van vijf minuten dat elke vijf seconden wordt bijgewerkt.
Is het mogelijk dat de belastingswaarde snel genoeg stijgt om de route onstabiel te maken?
Ja, dat is het. Erger nog, als de lading valt, neemt de metrische waarde af. Deze mislukking veroorzaakt een Flash update.
Aangezien de samengestelde metrische kosten voor een bepaalde locatie worden bepaald door de traagste link in het pad en de traagste link normaal de toegangslijn in de cloud is, hoe kan IGRP worden geconfigureerd om het snelste pad door de netwerkcloud te gebruiken?
Zodra de langste link is bepaald, wordt de rest van de routing uitgevoerd op hop (vertraging) zonder rekening te houden met de snelheden van de hop. Met de grote gaten in de bandbreedtewaarden, lijkt het niet praktisch om vertraging te proberen en te gebruiken om de routing van netwerkwolken te beïnvloeden. Eén voor de hand liggende oplossing is de opdracht bandbreedte op de toegangslijnen te configureren om sneller te zijn dan elke backbone-lijn van de netwerkcloud.
Een andere oplossing is de vertraging op de WAN-links te configureren als een nauwkeurige meting van de vertraging voor die bepaalde link. U hoeft de vertragingen helemaal niet aan te passen en u moet een goede routing hebben.
Het is zeker de moeite waard om de bandbreedte op de toegangslijn te veranderen als u radicaal verschillende bandbreedte binnen uw WAN hebt.
Geef de standaard-metrische opdracht uit om de metriek voor de herverdeelde routes in te stellen. Deze verklaring is in de meeste gevallen geschikt:
Venus(config)# router igrp 100 Venus(config-router)# default-metric 10000 100 255 1 1500
waarbij 10000 = Bandbreedte, 100 = Vertraging, 255 = Betrouwbaarheid, 1 = Laden, en 1500 = MTU.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
10-Aug-2005 |
Eerste vrijgave |