Infinite metric for IGRP

Hi,

The infinite metric for EIGRP is 32^2-1 = 4.294.967.295 Since the difference between EIGRP and IGRP metrics is by a factor of 256, is the infinite metric for IGRP = 16.777.215 (2^24-1)?

Bernard.

Reply to
Bernard Herickx
Loading thread data ...

"Bernard Herickx" wrote in news: snipped-for-privacy@scarlet.biz:

Bernard,

It is not quite that way.

The numerical value of 0 (zero) is interpreted by RIP, IGRP and EIGRP as infinite metric by default. It is default value of seed metric during redistribution. Because of this you must define it using "default- metric" keyword during redistribution into those three protocols otherwise they will not advertise the distributed routes at all.

So unswer to your question is: infinite metric for IGRP, EIGRP (and RIP too) is equal 0 (ZERO!!!). It is not those large numbers.

Reply to
name

Hmm ! Do not know about redistribution. May be you are right. However, with "debug eigrp" and "debug igrp", you clearly see that both protocols advertise no longer reachable routes with 4294967295 metric to poison the route. That so called "infinite" metric is the maximum value coded on a 4 bytes word.

Bernard

Reply to
Bernard Herickx

Bernard,

Good point, but this is for "route poisoning". I guess that Cisco has at least two confusing definitions for "infinite metric" and "metric of ureacheable" route. To make matter worst is varies per protocol. It was not clear for me which case you were asking about and I assumed that it was the more confusing - the one related to redistribution - my bad. BTW, trust me on redistribution - metric value of zero is treated by default as unreacheable for IGRP, EIGRP and RIP. I also thought that IGRP has 24 bit metric but you are telling that both IGRP and EIGRP are showing 32 bit numbers which is interesting. It was some time ago I play with IGRP but according to Mr Jeff Doyle in his book "Routing TCP/IP Vol

1" (which is sort of Cisco Scripture) you must be running both EIGRP and IGRP using the same AS number which is causing automatic redistribution between both protocols and igrp metric is adjusted by factor of 256 in eigrp and vice versa. So on eigrp running router you see 32 bit numbers and on igrp side it should be 24 bits. But I am guessing and assuming a lot. To be sure I need to know more about your setup like IOS version, configuration, are you running both igrp and eigrp on the same router or separate ones, and so on. Peharps Cisco did something to IGRP while we did not pay attention. The same source states that for IGRP "route will be marked ureacheable by setting the delay to 0xFFFFFF" which is aprox. 167.8 seconds.

Try to use interface "bandwith" and "delay" command to set extreme values and see what happens to composite metrics in both protocols. Please note that "show interface" delay is ten times bigger then IGRP delay.

IGRP is pulled out from any Cisco current exam and curriculum I know of but like old protocol it never dies and refuses to fade away too.

"Bernard Herickx" wrote in news: snipped-for-privacy@scarlet.biz:

Reply to
name

Hi "name",

To answer

Here is a comment from "Cisco Tutor" from the CCNA Prep Center at Cisco <

formatting link
>:

------------------------------------------------------ Hi,

The infinite metric for both IGRP and EIGRP is 4294967295.

Even though both protocols - IGRP and EIGRP use the same metric components, they store them in different size values: EIGRP uses a 32-bit metric, while IGRP uses a 24-bit metric. When integrating the two protocols together, EIGRP routes are divided by 256 to fit a 24-bit metric structure when passed to IGRP and IGRP routes are multiplied by 256 to fit a 32-bit metric structure when passed to EIGRP.

Hence the metric value within the IGRP network would be less than

16777215(2^24-1) for the route to be valid.

Regards Cisco Tutor

----------------------------------------------------

I checked the value with the debug command "debug ip igrp transactions" & "debug ip eigrp" for both IGRP and EIGRP but not togheter. Done on a triangular router configuration and the route poisining was triggered simply by shutting down one advertised serial interface.

The IOS version was:

IOS (tm) 2500 Software (C2500-I-L), Version 12.1(20), RELEASE SOFTWARE (fc2) Compiled Thu 29-May-03 22:00 by kellythw System image file is "flash:c2500-i-l.121-20.bin"

Bernard.

Reply to
Bernard Herickx

Bernard,

I just got off lab session during which played with both eigrp and igrp. Configured three 2500 routers in series to avoid routing loop. First set them all with igrp in AS 1. Configured all K values to 0. Played with extreme (like 1 or max allowed by command) delay and bandwith combinations on advertised loopback intefaces.

Typical config looked like this:

hostname R1

! !

ip subnet-zero

no ip domain-lookup

! ! ! !

interface Loopback0

ip address 1.1.1.1 255.255.255.255 shutdown !

interface Ethernet0

ip address 10.1.1.1 255.255.255.0

!

interface Serial0

no ip address

shutdown

no fair-queue

!

interface Serial1

bandwidth 1

ip address 10.1.0.1 255.255.255.0

delay 16777215

!

router igrp 1 network 1.0.0.0

network 10.0.0.0

metric weights 0 0 0 0 0 0

!

Metrics in igrp updates were showing to be either 0 or 4294967295:

R2#

02:00:12: IGRP: received update from 10.1.0.1 on Serial1

02:00:12: subnet 10.1.1.0, metric 0 (neighbor 0)

02:00:12: network 1.0.0.0, metric 0 (neighbor 0)

R2#

02:00:39: IGRP: sending update to 255.255.255.255 via Ethernet0 (10.1.2.2)

02:00:39: subnet 10.1.1.0, metric=0

02:00:39: subnet 10.1.0.0, metric=Inaccessible

02:00:39: network 1.0.0.0, metric=Inaccessible

02:00:39: network 2.0.0.0, metric=0

02:00:39: IGRP: sending update to 255.255.255.255 via Loopback1 (2.2.2.2)

02:00:39: network 1.0.0.0, metric=Inaccessible

02:00:39: network 10.0.0.0, metric=0

02:00:39: IGRP: sending update to 255.255.255.255 via Serial1 (10.1.0.2)

02:00:39: subnet 10.1.2.0, metric=0

02:00:39: network 1.0.0.0, metric=Inaccessible

02:00:39: network 2.0.0.0, metric=0

R1#

02:03:21: IGRP: received update from 10.1.0.2 on Serial1

02:03:21: subnet 10.1.2.0, metric 0 (neighbor 0)

02:03:21: network 1.0.0.0, metric 4294967295 (inaccessible)

02:03:21: network 2.0.0.0, metric 0 (neighbor 0)

R1#

02:04:18: IGRP: sending update to 255.255.255.255 via Ethernet0 (10.1.1.1)

02:04:18: subnet 10.1.2.0, metric=0

02:04:18: subnet 10.1.0.0, metric=0

02:04:18: network 1.0.0.0, metric=0

02:04:18: network 2.0.0.0, metric=0

02:04:18: IGRP: sending update to 255.255.255.255 via Loopback0 (1.1.1.1)

02:04:18: network 2.0.0.0, metric=0

02:04:18: network 10.0.0.0, metric=0

02:04:18: IGRP: sending update to 255.255.255.255 via Serial1 (10.1.0.1)

02:04:18: subnet 10.1.1.0, metric=0

02:04:18: network 1.0.0.0, metric=0

R1#

No matter of metrics values I got full connectivity all the time with exception of when interfaces were shut down!!!

During simmilar eigrp setup metric were showing always to be 4294967295. See for yourself:

02:34:45: IP-EIGRP: Processing incoming UPDATE packet

02:34:45: IP-EIGRP: Int 3.3.3.3/32 M 1 - 256000 153600 SM 1 - 256 128000

02:34:45: IP-EIGRP: Processing incoming UPDATE packet

02:34:45: IP-EIGRP: Int 1.1.1.1/32 M 4294967295 - 256000 4294967295 SM

4294967295 - 256000 4294967295

02:34:45: IP-EIGRP: Int 10.1.0.0/24 M 4294967295 - 2560000000 4294967295 SM 4294967295 - 2560000000

I could reach all loopbacks all the time despite infinite metrics with the exception as above.

All Feaseable Distances were alway equal 1

IP-EIGRP Topology Table for AS(1)/ID(1.1.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 2.2.2.2/32, 1 successors, FD is 1

P 3.3.3.3/32, 1 successors, FD is 1

P 1.1.1.1/32, 1 successors, FD is 1

via Connected, Loopback0

P 10.1.2.0/24, 1 successors, FD is 1

P 10.1.1.0/24, 1 successors, FD is 1

via Connected, Ethernet0

P 10.1.0.0/24, 1 successors, FD is 1

via Connected, Serial1

I discovered few timing issues when forming neiboring relations due to "mismatched K values" for first few seconds after bringing routing proces up

Configuration of automatic redistribution in the middle on R2 did not change metrics, reacheability or "general picture"

Tests were conducted on version: IOS (tm) 2500 Software (C2500-JS-L), Version 12.2(23), RELEASE SOFTWARE (fc2)

Few things learned/confirmed

Infinite metric for eigrp is 4294967295

Infinite metric for igrp is 4294967295 (not 2^24-1)

Value above 16777215 appears to be still valid metric for igrp

They both seems to be stored as 4 byte integers.

When router A advertises to router B route with infinite metric

4294967295 router B says cool and computes Feaseable Distance as 1 (when K values are configures as all 0s)

No matter of what Router A is saying to B in route update A still can ping router A loopback interface as nothing happened as long interface is up.

Do you agree that results are somewhat strange?

I need some more time to analyse session logs to really grasp whats going on. Granted, this is not the way you would configure routing on production system so at least good news is that when metris are in more "normal" ranges both protocols behave as expected.

"Bernard Herickx" wrote in news: snipped-for-privacy@scarlet.biz:

Reply to
name

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.