he RIP border router, also advertises the same destinations as BR1. Therefore BR3, redistributes the RIP routes into the EIGRP AS. BR2, then, has enough information to determine the AS entry point for the route, the original routing protocol used, and the metric. Further, the network administrator could assign tag values to specific destinations when redistributing the route. BR2 can use any of this information to use the route or re-advertise it back out into OSPF.
Using EIGRP route tagging can give a network administrator flexible policy controls and help customize routing. Route tagging is particularly useful in transit ASes where EIGRP would typically interact with an inter-domain routing protocol that implements more global policies. This combines for very scalable policy based routing.
EIGRP provides compatibility and seamless inter-operation with IGRP routers. This is important so users can take advantage of the benefits of both protocols. The compatibility features do not require users to have a flag day to enable EIGRP. EIGRP can be enabled in strategic places carefully without disruption to IGRP performance.
There is an automatic redistribution mechanism used so IGRP routes are imported into EIGRP and vice versa. Since the metrics for both protocols are directly translatable, they are easily comparable as if they were routes that originated in their own AS. In addition, IGRP routes are treated as external routes in EIGRP so the tagging capabilities are available for custom tuning.
IGRP routes take precedence over EIGRP routes by default. This can be changed with a configuration command that does not require the routing processes to restart.
The following network diagram illustrates how DUAL converges. The example focuses on destination N only. Each node shows its cost to N (in hops). The arrows show the node's successor. So, for example, C uses A to reach N and the cost is 2.
If the link between A and B fails, B sends a query informing its neighbors that it has lost its feasible successor. D receives the query and determines if it has any other feasible successors. If it does not, it has to start a route computation and enter the active state. However in this case, C is a feasible successor because its cost (2) is less than than D's current cost (3) to destination N. D can switch to C as its successor. Note A and C did not participate because they were unaffected by the change.
Now let's cause a route computation to occur. In this scenario, let's say the link between A and C fails. C determines that it has lost its successor and has no other feasible successors. D is not considered a feasible successor because its advertised metric (3) is greater than C's current cost (2) to reach destination N. C must perform a route computation for destination N. C sends a query to its only neighbor D. D replies because its successor has not changed. D does not need to perform a route computation. When C receives the reply it knows that all neighbors have processed the news about the failure to N. At this point, C can choose its new feasible successor D with a cost of (4) to reach destination N. Note that A and B were unaffected by the topology change and D needed to simply reply to C.
Yes, you configure EIGRP just like you configure IGRP. You configure a routing process and which networks the protocol should run over. Existing configuration files can be used.
Yes, there are both protocol independent and dependent debug commands that inform you what the protocol is doing. There is a suite of show commands that give you neighbor table status, topology table status, and EIGRP traffic statistics.
All of the features that you have used in IGRP are available in EIGRP. One feature to point out is multiple routing processes. You can use a single process that runs both IGRP and EIGRP. You can use multiple processes that run both. You can use one process that runs IGRP and another to run EIGRP. You can mix and match. This can help customize your routing to a particular protocol as your needs change.
The bandwidth utilization issue has