IGRP-metriek

Downloadopties

  • PDF     (135.8 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (91.8 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (86.3 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:10 augustus 2005
Document-id:13678

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inleiding

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.

Voorwaarden

Vereisten

Lezers van dit document zouden kennis moeten hebben van deze onderwerpen:

Gebruikte componenten

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.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Vind de IGRP-metriek

Deze sectie gebruikt een voorbeeld om te illustreren hoe de metriek te vinden wanneer IGRP het routingprotocol is.

Netwerkdiagram

Het schema voor het gegeven scenario wordt hier gegeven:

3_01.gif

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

Hoe vaak wordt de lading berekend?

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.

Hoe snel kan de waarde van het wasgoed worden verhoogd?

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.

Kan IGRP worden geconfigureerd voor het snelste pad door de netwerkcloud?

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.

Welke metriek moet worden gebruikt bij het opnieuw verdelen van routes in IGRP?

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.

Gerelateerde informatie

Revisiegeschiedenis

Revisie Publicatiedatum Opmerkingen
1.0
10-Aug-2005
Eerste vrijgave

Was dit document nuttig?

FeedbackFeedback

Contact Cisco