You’ve been a loyal Cisco employee your whole life and never thought OSPF was worth learning. Your boss wants to test your knowledge of EIGRP before offering you a promotion, though. He tells you that you have (2) hours to solve it!
- Nothing has been preconfigured for you! Refer to the diagram for IP addressing and connectivity.
- EIGRP 200 is configured on the interfaces that are encompassed by the circle. All other interfaces are EIGRP 100.
- Change the K-values within EIGRP 200 to only use the throughput delay on a link for the metric computation.
- Assign a delay of 1 to R7 F0/0, R8 F0/0, and R8 Lo0. Assign a delay of 3 to R4 S0/1 and R8 S0/0. Verify proper metrics are computed (math is simple). The network administrator in EIGRP 200 wants to keep his metrics low because he can’t count very high.
- SW1 is becoming overwhelmed by all the EIGRP hello packets. Double the EIGRP hello interval on all connected routers and appropriately tune the hold-down interval as well.
- Perform mutual redistribution between EIGRP 100 and 200 on both R4 and R7. Use a strict tagging solution that ensures no routing loops; do not rely on AD or metrics to accomplish this.
- In addition, metric translation should be done on both R4 and R7.
* Going from EIGRP 100 to 200, metrics will be shrunk down to satisfy the EIGRP 200 network administrator. For every five hundred thousand, add ten microseconds of delay. For example, EIGRP 100 metrics in the range of 0-500,000 should be translated to 10 microseconds of delay for EIGRP 200 to compute. EIGRP 100 metrics in the range of 500,000-1,000,000 should be translated to 20 microseconds of delay for EIGRP 200 to compute. Continue this until you reach 2,500,000 at which all prefixes will be assigned 60 microseconds of delay.
* Going from EIGRP 200 to 100, metrics will be enlarged to normal values. For one thousand, add 500 microseconds of delay, starting at 1000 microseconds of delay and 100MBps bandwidth. For example, EIGRP 200 metrics in the range of 0-1,000 should be translated to 1000 microseconds of delay for EIGRP 100 to compute. EIGRP 200 metrics in the range of 1,000-2,000 should be translated to 1500 microseconds of delay for EIGRP 100 to compute. Continue this until you reach 3,000 at which all prefixes will be assigned 2500 microseconds of delay.
- R4 is low on memory and should not be queried by EIGRP about routes in the active state. Make sure that R4 does not lose it’s role as a redistributor of routes from EIGRP 200.
- R5 has important information for R8 and it wants to load balance traffic to R8’s loopback0. Enable this feature, along with balanced traffic sharing, and achieve a 3:80 ratio of balancing between F0/0 and S0/0 on R5. Ensure that any bandwidth and delay changes you make are mirrored on the other end of the link for consistency.
- R1 should never load balance.
- R6 and R3 should ignore EIGRP updates from one another but maintain their neighborship. R5, however, should facilitate EIGRP communications between both routers on the LAN segment by ensure R3 and R6 still see one another’s updates, even indirectly.
- For additional security on the LAN segment, configure EIGRP authentication. Keys should rotate as well. The first key is valid from the time you started this lab until 1 hour from now. The second key is valid forever and starts being valid 5 minutes before expiration of the first key.
- Configure (4) new loopbacks on R1 with IP addresses 172.16.0.1/24, 172.16.1.1/24, 172.16.2.1/24, and 172.16.3.1/24. Summarize these networks on all of R1’s EIGRP neighboring interfaces. Make sure the 172.16.1.0/24 is still advertised explicitly. Also, this 172.16.1.0/24 route have it’s metric increased by 1 when it is advertised to EIGRP neighbors.
- R2 refuses to honor this explicit 172.16.1.0/24 route and prefers to use the summary only. Ensure R2 can never learn this route from any EIGRP peer using exactly three commands.
- R8 should originate a default route, advertised to both R4 and R7. Do not use the “redistribute” or “ip default-network” commands. Ensure that this default route does not show up in the routing table of R8, and to prevent loops, ensure R8 can never dynamically learn a default route. Lastly, R8’s loopback address must remain visible to all routers.
- For some reason, routers don’t always reply to R2’s queries quickly. R2 should wait forever for these queries
- Ensure you have full network connectivity, especially between loopback addresses which simulate host LANs.