IGRP was developed by Cisco primarily to overcome the hop count limit and hop count metric of RIPv1. In general, IGRP differs from RIPv1 in the following ways:
• IGRP runs directly over IP with protocol type field set to 9.
• Autonomous system is part of the message fields.
• Distance vector updates include five different metrics for each route, although one is not used in computing the composite metric.
• External routes can be advertised.
• It allows multiple paths for a route for the purpose of load balancing; this requires mod- ification of the Bellman–Ford computation so that instead of a single best path to a desti- nation, multiple “almost” equal cost paths can be stored.
IGRP’s normal routing update is sent every 90 sec on average with a variation of 10% to avoid synchronization. It has an invalid timer to indicate nonreachability of a route; this is set to three times the value of the update period. It is important to note that IGRP does not support variable length subnet masking, much like RIPv1; this is an instance in which IGRP differs from RIPv2.
5.5.1 Packet Format
IGRP packet is fairly compact consisting of 12-byte header fields followed by 14 bytes for each route entry (see Figure 5.6). The header field consists of the following fields:
• Version (4 bits): This field is set to 1.
• Opcode (4 bits): This field is equivalent to the command code in RIP. 1 is a Request and 2 is an Update. In case of a request, only the header is sent; there are no entries.
• Edition (1 byte): A counter that is incremented by the sender; this helps prevent a receiving router from using an old update; it essentially plays the role of a timestamp.
• Autonomous system number (2 bytes): ID number of an IGRP process.
• Number of interior routes (2 bytes): A field to indicate the number of routing entries in an update message that are subnets of a directly connected network.
• Number of system routes (2 bytes): This is a counterpart of the number of interior routes;
this field is used to indicate the number of route entries that are not directly connected.
• Number of exterior routes (2 bytes): The number of route entries that are default networks.
This and the previous two fields, the number of interior routes and the number of system routes, together constitute the total number of 14-byte route entries.
• Checksum (2 bytes): This value is calculated on the entire IGRP packet (header+entries).
For each route entry, there are seven fields that occupy 14 bytes:
F I G U R E 5.6 IGRP packet format.
• Destination (3 bytes): This is the destination network for which the distance vector is gen- erated. It seems confusing to see that this field is only 3 bytes instead of the standard 4 bytes for IP addresses. However, for classful addresses, this is workable. If the update is for a system route, the first 3 bytes of the address are included; for example, if IP address of a route is 192.168.1.0, entry 192.168.1 is listed in this field. On the other hand, if it is an interior route, the last 3 bytes are listed; for example, if the field lists 16.2.0 for an interior route that is received on interface 172.16.1.254/24, it is meant for the subnet 172.16.2.0.
• Delay (3 bytes), bandwidth (3 bytes), reliability (1 byte), and load (1 byte): These fields are explained in Section 5.5.2 while discussing how the composite metric is computed.
• Hop count (1 byte): A number between 0 and 255 used to indicate the number of hops to the destination.
• MTU (2 bytes): The smallest MTU of any link along the route to the destination.
5.5.2 Computing Composite Metric
An interesting aspect of IGRP is the elaborate method it uses to compute the composite metric to represent the link cost; this was included to provide the flexibility to compute better or more accurate routes from a link cost rather than just using a hop count as a link cost as in RIPv1 or RIPv2. The composite metric in IGRP is based on four factors: bandwidth (B),
delay (D), reliability (R), and load (L), along with five nonnegative coefficients (K1,K2,K3, K4, K5) for weighing these factors. The composite metric, C(“cost of a link”), is given as follows:
C=
⎧⎨
⎩
K1×B+K2×256−LB +K3×D
×
K5 R+K4
, ifK5=0 K1×B+K2×256B−L+K3×D, ifK5=0.
(5.5.1) This composite cost metric is used in routing table computation. Here, the special case for K5=0means that the last part,K5/(R+K4), which considers the reliability of a link, is not included; in other words, this means that ifK5=0, all links have the same level of reliability.
In the default case,K1=K3=1andK2=K4=K5=0. Thus, the composite metric reduces to
Cdefault=B+D. (5.5.2)
This shows that the default composite metric is the summation of bandwidth and delay.
Now, certainly this seems odd since bandwidth is typically given in mbps or kbps while delay is given in time unit such as sec or, millisec; that is, how do you add apples and oranges? IGRP uses a transformation process to map the raw parameters to a comparable level.
First, the raw bandwidth (Braw) is expressed in kbps. Thus an Ethernet link with a data rate of 10 mbps is given the raw value 10,000. The calculated bandwidth,B, is the inverse of the raw bandwidth multiplied by the factor107to scale everything in terms of 10 gbps. That is,
B= 107 Braw
. (5.5.3)
Thus, in the case of an Ethernet link,B=101074 =1000, and for a Fast-Ethernet link, B=100.
Essentially, this means that the faster the data rate of a link, the smaller the value of Bis capping withB=1 for a 10 Gbps link. Since 24 bits are provided for the bandwidth field, even for a 1 kbps link the value is within the range. Certainly, we do not expect any network to have a 1-kbps link anymore! In any case, the intent behind making a higher bandwidth data rate translate to a smaller value is that it takes less time to send a data packet—in other words, inverting the raw data rate allows us to think in terms of time. In some sense, this is no different than a road network in which you can drive to a place in much less time on a road with a speed limit of 120 Kmph compared to a road with a speed limit of 70 kmph.
Bandwidth or raw bandwidth assumes that the road is clear and your packet is the only packet traveling; it does not assume how much time the packet itself will take from the first bit of the packet to the last bit of the packet. Thus, the delay parameter is meant to capture the packet transmission delay on an interface, which is given in tens ofμsec of raw delay,Draw. That is,
D=Draw/10. (5.5.4)
Thus, if the raw delay is 1000μsec, we haveD=100. Also, 24 bits are assigned for the delay field. Thus, for an interface running Ethernet and a delay computed to be 1000 μsec, the
default composite metric value,Cdefault, is1000+100=1100. The default composite metric is computing a link cost that essentially reflects delay due to path delay and packet transmission delay.
Going beyond the default composite metric, consider the middle term with coefficientK2 in the generic composite metric given in Eq. (5.5.1). This term incorporates delay “cost” due to load on a link, that is, due to traffic. For the load factor, an 8-bit field is used; thus, raw load,Lraw, which is a fraction between 0 and 1, can be written as
Lraw= L
256 (5.5.5)
so thatLcan take a value between 0 and 255 (inclusive) to represent link load.
The delay cost term in the middle term in Eq. (5.5.1) essentially follows the queueing delay formula modeled using anM/M/1 queue system (see Appendix B.12.2). IfSis the av- erage packet size andλis the average arrival rate of packets, the average delay for anM/M/1 queueing system is given by
T= 1
Braw S −λ
. (5.5.6)
By pullingBraw/Sout of the expression in the denominator, we can rewrite it as T= S
Braw × 1 (1−BSλraw).
However,Sλ/Braw=Lrawis the raw load. Thus, we arrive at T= S
Braw × 1 (1−Lraw).
Multiplying the numerator and denominator by 256, we get T= S
Braw × 256 (256−256Lraw).
Using relations forBandLgiven in Eq. (5.5.3) and Eq. (5.5.5), respectively, we can then finally write this expression as
T=S×B
107 × 256
(256−L)=S×256
107 × B
(256−L). (5.5.7)
Since the first term S×256/107 is a constant, we can assign a coefficient, K2, including accounting for any proportion compared to other terms—this is then the middle term in Eq. (5.5.1).
We can see that IGRP provides an elaborate way to compute cost of a link. In practice, the default composite metric given in Eq. (5.5.2) is often used. You might notice that if the network has an interface of the same data rate, the value of the default composite metric will be the same for all links; this essentially means that network routing is working as if a hop count metric is in place much like RIP.
Next, we consider the reliability termK5/(R+K4)in Eq. (5.5.1) and discuss possible ways to setK4andK5. First observe that if a link is not fully reliable, we want the cost of the link to be higher than if it is reliable. It is given that the “base” reliability is 1 (whenK5=0); thus, for an unreliable link, we want
K5 R+K4>1.
This means K5>R+K4.
Since the largest value ofRis 255, this implies thatK5andK4should be chosen such that
K5>K4+255. (5.5.8)
It is worth noting that the protocol message includes all the different metric components rather than the composite metric; in other words, the composite metric is left to a router to compute first, before doing the Bellman–Ford computation for the shortest path. This also means that it is extremely important to ensure that each router is configured with the same value of the coefficientsK1,K2,K3,K4,K5. For example, if in one routerK1 is set to 1 and the rest to zero, while in another routerK3is set to 1 and the rest to zero, their view of the shortest path would be different, thus potentially causing yet another problem.