EIGRP – The Basics IV

EIGRP använder sig av ett flertal olika typer paket för att fungera, dessa är:

  • Hello
  • Update
  • Query
  • Reply
  • Ack

För att vara säker på att exempelvis en routing-uppdatering nått sin mottagare använder sig EIGRP av  “Reliable Transport Protocol” (RTP, ej att omväxlas med Real-time Transport Protocol som Voice använder sig av).

Hello-packet

Hello-paket används för neighbor-discovery och skickas som multicast, när två routers utväxlat varsitt hello-paket med varandra skapas en “neighbor adjacency” . Hello-paketen skickas med antingen 5 eller 60 sekunders intervaller. En holdtimer används sedan för att hålla koll på om en neighbor går ner, denna är satt till 3x hello-intervallet som standard, dvs 15/180 sekunder. Hello-intervallen bestäms efter följande:

5 sekunders Hello

  • Broadcast media, such as Ethernet, Token Ring, and FDDI
  • Point-to-point serial links, such as PPP or HDLC leased circuits
  • Frame Relay point-to-point subinterfaces, and
  • ATM point-to-point subinterface
  • High bandwidth (greater than T1) multipoint circuits, such as ISDN PRI and Frame Relay

60 sekunders Hello

  • Multipoint circuits T1 bandwidth or slower, such as Frame Relay multipoint interfaces
  • ATM multipoint interfaces
  • ATM switched virtual circuits
  • ISDN BRIs

T1 = 1,544Mbps

Holddown-timern förnyas förresten enbart av Hello-paket i äldre IOS, men i senare versioner så går det lika bra med Query/Update/Reply/Ack. Det går givetvis bra att modifiera både Hello & Holdown-timer för snabbare konvergens. Detta görs på det önskade interfacet genom kommandot:

ip hello-interval eigrp x
ip hold-time eigrp x

Observera att holdown-timern EJ automatiskt uppdateras, så ändrar du hello-timern till 20 sekunder men holdtimern ligger kvar på 15 sek kommer du få problem.. 🙂 Värdet för hello/hold-timern behöver dock inte matchas mellan routrarna, det gäller dock som sagt att hålla koll så att ett hello-paket kommer hinna fram innan holddown-timern är nere på 0 för att inte tappa adjencency.

Update-packet

Innehåller routing-information och skickas “reliable”, dvs routern förväntar sig ett “ack” tillbaka. Skickas antingen som unicast eller till en grupp av routrar genom multicast. Dessa skickas endast när det skett en förändring, exempelvis att en länk har gått ner/lagts till. Multicast skickas till adressen 224.0.0.10.

Vid en ny neightbor-adjacency skickas ett update-paket som unicast, den nya routern placeras i en grupp som kallas “laggard” då den äldre routern räknar med att fler multicast-paket kan behövas skickas till andra enheter innan den nya routern är fullt synkroniserad. Detta medför att resterande routrar i nätverket kan fortsätta kommunicera som vanligt, när den nya routern anses “up to date” flyttas den ut från laggard-gruppen och Update-paketen skickas istället som multicast, detta är dock lite över CCNP-nivån tror jag..

Routern tar dock hur som helst i beaktning Split-Horizon och skickar ej ut routes den lärt sig tillbaka från det specifika interfacet, se tidigare poster relaterat till detta för en mer ingående förklaring.

Query-packet

Används för att fråga andra routrar efter en specifik route och skickas “reliable”. Använder multicast, får den inget svar försöker den dock även med 16st unicast.

Reply-packet

Används för att svara på ett Query-paket, skickas som unicast (reliable).

Ack

Mottagaren ack:ar Update/Query/Reply-paket till avsändaren (unicast).

Neighbor-adjacency

Hur går det då till när en neighbor-adjaceny skapas mellan exempelvis R1 & R2?
Efter att EIGRP aktiverats på länken mellan R1 & R2 (genom network x.x.x.x wildcard):

  1. R1 skickar ett Hello-paket (multicast)
  2. R2 mottager Hello-paketet och skickar samtidigt ut sin egen (multicast)
  3. R2 skickar även ett Update-paket (unicast) med sin routing-information
  4. R1 svarar med en ack (unicast) och sparar denna information i sin topology-table
  5. R1 skickar sedan själv ett Update-paket (unicast) med sin routing-information
  6. R2 svarar med en ack (unicast) och sparar denna information i sin topology-table

Ett adjaceny skapas dock endast om följande parametrar stämmer överens (Autentisering/nycklar, AS-nummer & “K-values”).

Debug

Här är ett snabbt exempel hur det ser ut när man debuggar detta genom “debug eigrp packets” för nedanstående topologi.

debug eigrp neighbor

Detta är innan EIGRP är konfigurerat på R2’s neighbor, vi kan se att den skickar Hello var 5:e sekund.

*Mar 1 00:05:09.863: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:05:09.863: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 00:05:14.491: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:05:14.491: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

EIGRP skickar även ut Hello-paket på loopback-interfacet per default, men detta stängde jag av genom “passive-interface lo0” för att få det lite mer lättläst sen.

*Mar 1 00:09:18.075: EIGRP: Sending HELLO on Loopback0
*Mar 1 00:09:18.075: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 00:09:18.079: EIGRP: Received HELLO on Loopback0 nbr 1.1.1.1
*Mar 1 00:09:18.079: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 00:09:18.079: EIGRP: Packet from ourselves ignored

Efter att ha aktiverat EIGRP även på länknätet får vi direkt upp adjaceny.

*Mar 1 00:12:41.459: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:12:41.483: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.1.2
*Mar 1 00:12:41.487: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.1.2 (FastEthernet0/0) is up: new adjacency

*Mar 1 00:12:41.487: EIGRP: Enqueueing UPDATE on FastEthernet0/0 nbr 192.168.1.2 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 00:12:41.507: EIGRP: Sending UPDATE on FastEthernet0/0 nbr 192.168.1.2

*Mar 1 00:12:41.535: EIGRP: Received UPDATE on FastEthernet0/0 nbr 192.168.1.2
*Mar 1 00:12:43.547: EIGRP: Sending ACK on FastEthernet0/0 nbr 192.168.1.2

*Mar  1 00:12:43.643: EIGRP: Received ACK on FastEthernet0/0 nbr 192.168.1.2

Detta skrapar dock fortfarande egentligen bara på ytan av vad som egentligen sker, men detta borde täcka CCNP-nivån ganska bra tror jag. Neighbor-adjacenys kan verifieras genom kommandot “show ip eigrp neighbors“.

IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.2 Fa0/0 14 00:10:18 56 336 0 4

H – Handle, turordningen som adjacenys skapats, nästa kommer ha 1, 2, 3, 4 etc.
Hold Uptime – Holddown-timern, räknar ner från 15 sek i detta fall och refreshas av Hello/Update/Query/Reply/Ack-paket, då Hello’s i detta fall skickas var 5:e sekund  bör den timern gå tillbaka till 15 inom kort om allt fungerar som det ska.
SRTT (Smooth round-trip time) – Tiden i ms det tar för ett EIGRP-paket att nå sin neighbor och motta ett ack som svar (Update/Query/Reply).
RTO (Retransmisson Timeout) – Tiden i ms EIGRP väntar innan den försöker med en omsändning från “retransmission que” till neighborn.
Q Cnt (Q count) – Antal EIGRP-paket (Update/Query/Reply) i kö som väntar på att bli skickade. Detta bör givetvis alltid vara 0, visas något annat kan det vara en indikation på ett överbelastat nät.
Seq Num (Sequence Number) – Visar sekvensnumret från senaste Update/Query/Reply-paketet mottaget från neighborn.

Detta är ett litet sidospår men om Q Cnt skulle vara ett problem finns det möjlighet att justera hur mycket bandbredd EIGRP kan använda sig av per interface. Som default använder den 50% av bandwith (delat per antal neighbors vid multiaccess). Har du en väldigt dålig länk kan detta ge riktiga usla värden. Säg att du exempelvis har en 128 kbit’s Frame  Relay-länk med 4 neighbors, detta skulle ge följande bandbredds-reservation:

128kbit / 2 (50%) = 64k, 64k/4 (neighbors) = 16kbit. Dvs EIGRP kommer endast kunna använda 16kbit av interface-bandbredden, detta bör rimligtvis kunna leda till rätt stora prestandaproblem. Går dock att justera genom kommandot “ip bandwith-percent eigrp “AS” x” (där X är % av bandwith), exempelvis “ip bandwith-percent eigrp 10 90”.

Nästa inlägg blir om EIGRP inom Frame-Relay (brrrr)..

Lämna ett svar

Din e-postadress kommer inte publiceras.