Igrp which layer

In order to avoid the routing loop, the IGRP neglects the newly generated data for a period of time when the certain changes take place. Although, the IGRP is easily configurable.

It gives rise to the hybrid routing which is developed by merging the features of the distance vector routing and link state routing. The benefits of EIGRP is that is simple to configure, efficient and secure, but its main advantage is that it assists the classless routing which was not supported by IGRP. Your email address will not be published. For bandwidth and delay, the IGRP is allotted 24 bits. This is done in accordance with the composite metric for each data path.

For instance, if one path has a composite metric of 1 and another path has a composite metric of 3, three times as many packets will be sent over the data path having the composite metric of 1. There are two advantages to using a vector of metric information. The first is that it provides the ability to support multiple types of service from the same set of data.

The second advantage is improved accuracy. When a single metric is used, it is normally treated as if it were a delay. Each link in the path is added to the total metric. If there is a link with a low bandwidth, it is normally represented by a large delay. However, bandwidth limitations don't really cumulate the way delays do.

By treating bandwidth as a separate component, it can be handled correctly. Similarly, load can be handled by a separate channel occupancy number. IGRP provides a system for interconnecting computer networks which can stably handle a general graph topology including loops. The system maintains full path metric information, i.

Traffic can be distributed over parallel paths and multiple path parameters can be simultaneously computed over the entire network. However, doing this is not entirely fair. RIP was intended for use in small networks with reasonably uniform technology. In such applications it is generally adequate. Unfortunately this is not a change that can simply be retrofitted to RIP.

It requires the new algorithms and data structures present in IGRP. RIP uses a simple "hop count" metric to describe the network. Unlike IGRP, where every path is described by a delay, bandwidth, etc. Normally this number is used to represent how many gateways the path goes through before getting to the destination. This means that no distinction is made between a slow serial line and an Ethernet. In some implementations of RIP, it is possible for the system administrator to specify that a given hop should be counted more than once.

Slow networks can be represented by a large hop count. But since the maximum is 15, this can't be done very much. In order to represent the full range of available network speeds, and allow for a large network, studies done by Cisco suggest that a bit metric is needed. If the maximum metric is too small, the system administrator is presented with an unpleasant choice: either he can not distinguish between fast and slow routes, or he can't fit his whole network into the limit. In fact a number of national networks are now large enough that RIP can not handle them even if every hop is counted only once.

RIP simply can't be used for such networks. The obvious response would be to modify RIP to allow a larger metric. Unfortunately, this won't work. Like all distance vector protocols, RIP has the problem of "counting to infinity". This is described in more detail in RFC When topology changes, spurious routes will be introduced.

The metrics associated with these spurious routes slowly increase until they reach 15, at which point the routes are removed. This is not tolerable. IGRP has features designed to prevent spurious routes from being introduced. These are discussed below in section 5. It is not practical to handle complex networks without introducing such features or changing to a protocol such as SPF.

IGRP does a bit more than simply increase the range of allowable metrics. It restructures the metric to describe delay, bandwidth, reliability, and load. For example, with a single metric, several successive fast links will appear to be equivalent to a single slow one. This may be the case for interactive traffic, where delay is the primary concern. However, for bulk data transfer, the primary concern is bandwidth, and adding metrics together is not the right approach there.

IGRP handles delay and bandwidth separately, cumulating delays, but taking the minimum of the bandwidths. It is not easy to see how to incorporate the effects of reliability and load into a single-component metric. In my opinion, one of the big advantages of IGRP is ease of configuration. It can directly represent quantities that have physical meaning.

This means that it can be set up automatically, based on interface type, line speed, etc. With a single-component metric, the metric is more likely to have to be "cooked" to incorporate effects of several different things. Other innovations are more a matter of algorithms and data structures than of the routing protocol. For example, IGRP specifies algorithms and data structures that support splitting traffic among several routes.

It is certainly possible to design an implementation of RIP that does this. However, once routing is being re-implemented, there is no reason to stick with RIP. So far I have described "generic IGRP", a technology which could support routing for any network protocol. That is the implementation that is going to be compared with RIP.

RIP update messages simply contain snapshots of the routing table. That is, they have a number of destinations and metric values, and little else. First, the update message is identified by an "autonomous system number. However, for most networks what it means is that you can run several different routing systems on the same network. This is useful for places where networks from several organizations converge. Each organization can maintain its own routing. Because each update is labeled, gateways can be configured to pay attention only to the right one.

Certain gateways are configured to receive updates from several autonomous systems. They pass information between the systems in a controlled manner. Note that this is not a complete solution to problems of routing security. Any gateway can be configured to listen to updates from any autonomous system. However, it is still a very useful tool in implementing routing policies where is a reasonable degree of trust between the network administrators.

Most routing protocols have a concept of default route. It is often not practical for routing updates to list every network in the world. Typically a set of gateways need detailed routing information for networks within their organization. All traffic for destinations outside their organization can be sent to one of a few boundary gateways. Those boundary gateways may have more complete information.

The route to the best boundary gateway is a "default route". It's a default in the sense that it is used to get to any destination that is not listed specifically in the internal routing updates.

RIP, and some other routing protocols, circulate information about the default route as if it were a real network. IGRP takes a different approach. Rather than a single fake entry for the default route, IGRP allows real networks to be flagged as candidates for being a default. This is implemented by placing information about those networks in a special exterior section of the update message.

However, it might as well be thought of as turning on a bit associated with those networks. Periodically IGRP scans all the candidate default routes and chooses the one with the lowest metric as the actual default route. Potentially this approach to defaults is somewhat more flexible than the approach taken by most RIP implementations. Most typically RIP gateways can be set to generate a default route with a certain specified metric.

The intention is that this would be done at boundary gateways. When a gateway is first turned on, its routing table is initialized. This may be done by an operator from a console terminal, or by reading information from configuration files.

A description of each network connected to the gateway is provided, including the topological delay along the link for example, how long it takes a single bit to transverse the link and the bandwidth of the link. For instance, in the diagram above, gateway S would be told that it is connected to networks 2 and 3 via the corresponding interfaces. Thus, initially, gateway 2 only knows that it can reach any destination computer in networks 2 and 3.

All the gateways are programmed to periodically transmit to their neighboring gateways the information that they have been initialized with, as well as information gathered from other gateways. Thus, gateway S would receive updates from gateways R and T and learn that it can reach computers in network 1 through gateway R and computers in network 4 through gateway T. Since gateway S sends its entire routing table, in the next cycle gateway T will learn that it can get to network 1 through gateway S.

It is easy to see that information about every network in the system will eventually reach every gateway in the system, providing only that the network is fully connected. Each gateway computes a composite metric to determine the desirability of the data paths to destination computers.

For instance, in the diagram above, for a destination in Network 6, gateway A gw A would compute metric functions for two paths, via gateways B and C. Note that paths are defined simply by the next hop. There are actually three possible routes from A to Network However, gateway A need not choose between the two routes involving C. The routing table in A has a single entry representing the path to C. Its metric represents the best way of getting from C to the final destination.

However, in practice a standard delay figure is used for each type of network technology. For instance, there will be a standard delay figure for Ethernet, and for serial lines at any particular bit rate. Here is an example of how gateway A's routing table might look in the case of the Network 6 diagram above. Note that individual components of the metric vector are not shown, for simplicity. The basic process of building up a routing table by exchanging information with neighbors is described by the Bellman-Ford algorithm.

Instead of a simple metric, a vector of metrics is used to characterize paths. A single composite metric can be computed from this vector according to Equation 1, above. Use of a vector allows the gateway to accommodate different types of service, by using several different coefficients in Equation 1. It also allows a more accurate representation of the characteristics of the network than a single metric. Instead of picking a single path with the smallest metric, traffic is split among several paths with metrics falling into a specified range.

This allows several routes to be used in parallel, providing a greater effective bandwidth than any single route. A variance V is specified by the network administrator. All paths with minimal composite metric M are kept. In addition, all paths whose metric is less than V x M are kept.

Traffic is distributed among multiple paths in inverse proportion to the composite metrics. There are some problems with this concept of variance. It is difficult to come up with strategies that make use of variance values greater than 1, and do not also lead to packets looping. In Cisco release 8. I am not sure in what release the feature was removed.

The effect of this is to set the variance permanently to 1. Several features are introduced to provide stability in situations where the topology is changing.

These features are intended to prevent routing loops and "counting to infinity," which have characterized previous attempts to use Ford-type algorithms for this type of application. The primary stability features are "holddowns", "triggered updates", "split horizon," and "poisoning". These will be discussed in more detail below. Traffic splitting point 2 raises a rather subtle danger.

The variance V is designed to allow gateways to use parallel paths of different speeds. If the variance V is 1, only the best path will be used. However, if several paths are the same, the load will be shared among them. By raising the variance, we can allow traffic to be split between the best route and other routes that are nearly as good.

With a large enough variance, traffic will be split between the two lines. The danger is that with a large enough variance, paths become allowed that aren't just slower, but are actually "in the wrong direction". Thus there should be an additional rule to prevent traffic from being sent "upstream": No traffic is sent along paths whose remote composite metric the composite metric calculated at the next hop is greater than the composite metric calculated at the gateway.

In general system administrators are encouraged not to set the variance above 1 except in specific situations where parallel paths need to be used. In this case, the variance is carefully set to provide the "right" results.

IGRP is intended to handle multiple "types of service," and multiple protocols. Type of service is a specification in a data packet that modifies the way paths are to be evaluated. Generally, interactive applications will specify low delay, whereas bulk transfer applications will specify high bandwidth. These requirements determine the relative values of K1 and K2 that are appropriate for use in Eq. Each combination of specifications in the packet that is to be supported is referred to as a "type of service".

For each type of service, a set of parameters K1 and K2 must be chosen. A routing table is kept for each type of service. This is done because paths are selected and ordered according to the composite metric defined by Eq.

This is different for each type of service. Information from all of these routing tables is combined to produce the routing update messages exchanged by the gateways, as described in Figure 7. This section describes holddowns, triggered updates, split horizon, and poisoning. These features are designed to prevent gateways from picking up erroneous routes. As described in RFC , this can happen when a route becomes unusable, due to failure of a gateway or a network.

In principle, the adjacent gateways detect failures. They then send routing updates that show the old route as unusable.

However, it is possible for updates not to reach some parts of the network at all, or to be delayed in reaching certain gateways. A gateway that still believes the old route is good can continue spreading that information, thus reentering the failed route into the system. Eventually this information will propagate through the network and come back to the gateway that re-injected it.

The result is a circular route. In fact there is some redundancy among the countermeasures. In principle, holddowns and triggered updates should be sufficient to prevent erroneous routes in the first place. However, in practice, communications failures of various kinds can cause them to be be insufficient.

Split horizon and route poisoning are intended to prevent routing loops in any case. Normally, new routing tables are sent to neighboring gateways on a regular basis every 90 seconds by default, although this can be adjusted by the system administrator. A triggered update is a new routing table that is sent immediately, in response to some change.

The most important change is removal of a route. This can happen because a timeout has expired probably a neighboring gateway or line has gone down , or because an update message from the next gateway in the path shows that the path is no longer usable.

When a gateway G detects that a route is no longer usable, it triggers an update immediately. This update will show that route as unusable. Consider what happens when this update reaches the neighboring gateways.

If the neighbor's route pointed back to G, the neighbor must remove the route. This causes the neighbor to trigger an update, etc. Thus a failure will trigger a wave of update messages. This wave will propagate throughout that portion of the network in which routes went through the failed gateway or network.

Triggered updates would be sufficient if we could guarantee that the wave of updates reached every appropriate gateway immediately.

However, there are two problems. First, packets containing the update message can be dropped or corrupted by some link in the network. Second, the triggered updates don't happen instantaneously.

It is possible that a gateway that has not yet gotten the triggered update will issue a regular update at just the wrong time, causing the bad route to be reinserted in a neighbor that had already gotten the triggered update. Holddowns are designed to get around these problems.

The holddown rule says that when a route is removed, no new route will be accepted for the same destination for some period of time. This gives the triggered updates time to get to all other gateways, so that we can be sure any new routes we get aren't just some gateway reinserting the old one.

The holddown period must be long enough to allow for the wave of triggered updates to go throughout the network. In addition, it should include a couple of regular broadcast cycles, to handle dropped packets.

Consider what happens if one of the triggered updates is dropped or corrupted. The gateway that issued that update will issue another update at the next regular update. This will restart the wave of triggered updates at neighbors that missed the initial wave. The combination of triggered updates and holddowns should be sufficient to get rid of expired routes and prevent them from being reinserted.

However, some additional precautions are worth doing anyway. They allow for very lossy networks, and networks that have become partitioned. The additional precautions called for by IGRP are split horizon and route poisoning. Split horizon arises from the observation that it never makes sense to send a route back in the direction from which it came.

Consider the following situation:. Gateway A will tell B that it has a route to network 1. When B sends updates to A, there is never any reason for it to mention network 1. Routers using a distance vector protocol must send all or a portion of their routiTg tabl e in a routing-update message at regular intervals to each of their neighboring routers.

As routing information proliferates through the network, routers can identify new destinations as they are added to the network, learn of failures in the network, and, most importantly, calculate distances to all known destinations. Distance vector routing protocols are often contrasted with link-state routing protocols, which send local connection information to all nodes in the internetwork.

IGRP uses a composite metric that is calculated by factoring weighted mathematical values for internetwork delay, bandwidth, reliability, and load. Network administrators can set the weighting factors for each of these metrics, although great care should be taken before any default values are manipulated.

IGRP provides a wide range for its metrics.