Scenario
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!
Goal:
- 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.
IOS:
c3725-adventerprisek9-mz.124-7.image
Topology:
Do you want your CCNA or CCNP Certificate?
The How to Master series helps you to understand complex topics like spanning-tree, VLANs, trunks, OSPF, EIGRP, BGP and more.
Written by René Molenaar - CCIE #41726
you ‘re amazing, thank you
Hey,
There is no GNS3 topology file.. could you please add it here .
The 3.3.3.3, 4.4.4.4, 7.7.7.7, and 8.8.8.8 IP addresses shown in the above configuration for the Loops will not work with a /32 subnet.
Those addresses are the network for (4.4.4.4, 8.8.8.8 ) and the broadcast (3.3.3.3, 7.7.7.7)
I am not sure what those Loops have to do with the configuration other than IP’s to ping across the network so I changed the IP’s to useables within the next range.
For anyone reading I used 9.9.9.9, 10.10.10.10, 13.13.13.13 and 14.14.14.14. You can also change the subnet to allow for a larger range of useables.
ip classless and no ip subnet-zero did not help the configuration for my routers. Maybe with a newer image those commands will work to allow for those IP’s to be used.
Image used: c3725-adventerprisek9-mz.124-15.T5.image
Jason,
Those loopbacks are just to test connectivity, so if you are having issues using what the lab prescribes, use anything else that works! Something is definitely wrong with your IOS image or possibly the configuration.
rajkumar,
The lab must be built from scratch. This is deliberate.
Can you Pls Upload the Topology, if somebody have it, Pls forward to aqeel_abid@yahoo.com
Thanks.
Here are my initial configurations and .net file for this lab.
I include only ip address for each interface. Also you have to add
by your own R1’s loopbacks. The IOS version is
c3640-jk9s-mz.124-16.image
http://dl.dropbox.com/u/45596553/EIGRP-advanced.zip
High quality lab! Really had couple hours of fun. Trick with 255 adm.distance was especially fun. Thank you!
have you a video solution pls?
Hey Nick, Can you please give some idea for " * 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…."
I tried using
1. the same route-map where i m redistributing the routes
2. with distributelist and a new route-map.
both with "match metric XXX +- XX" but it is not working..
Also, i observed one more thing that metric change automatically from AS100 to AS200, ( checking it in topology table).. Please reply ASAP.. and yes, the LAB is just awesome.Thank you..
Regs
Hello Faheem. I have same issue, however, the route can be learned via another interface.
That’s my route-maps for the exercise.
route-map to-eigrp200 deny 10
match tag 200
route-map to-eigrp200 permit 20
set tag 100
route-map to-eigrp200 permit 30
match metric 250000 +- 250000
set metric 0 10 0 0 0
route-map to-eigrp200 permit 40
match metric 750000 +- 250000
set metric 0 20 0 0 0
=====================================
route-map to-eigrp100 deny 10
match tag 100
route-map to-eigrp100 permit 20
set tag 200
route-map to-eigrp100 permit 30
match metric 500 +- 500
set metric 0 1000 0 0 0
route-map to-eigrp100 permit 40
match metric 750 +- 250
set metric 0 1500 0 0 0
Rene, could you correct me if a mistake something?
hi! have you th solution?
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.
Where is this section in the final configs? Looking at the final config for R5 doesn’t show any changes to any interface bandwidths or delays, I’m seeing a traffic load share of 1:40, nothing close to the 3:80 you’re requesting…
Hello Nick,
Question on this item
– 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.
aren’t the natural AD of EIGRP gonna fix this even without doing the tagging ?
Hello Renee,
Where is the .net file for this lab?
I can only find the configs….
Thanks,
Carlos Dias
Hi Rene or Nick. these configs have passwords. what is the password to get into exec mode?
I’m proud of myself cause i have done all the tasks of this lab 🙂 but in more than 2h …^^
The metrics shrinking and enlarging part seems to be catching me up. I was able to perform mutual redistribution between EIGRP 100 and 200 using route-maps and tagging, avoiding loops by denying the alternate tag as the first line of each route-map.
When it comes to adjusting the metrics for each ASN, this is really confusing me. I did the same thing that Faheem did and created additional lines in my route-maps, using a permit statement and
match metric 250000 +- 250000
set metric 0 +10 255 1 1500
but saw no real change. Then I did some digging today and realized I had set my metric weights incorrectly. I had them set at
metric weights 0 0(k1) 1(k2) 0(k3) 0(k4) 0(k5)
I had always been taught to think of bandwidth, delay, reliability, load, and mtu as the five k values. The k values in the metric weights command are actually
k1 bandwidth
k2 load
k3 delay
k4 reliability
k5 mtu
So I had been telling eigrp to only look at the load on the link, not the delay.
Patric,
although late, but just to clarify, the k-values are not exactly what you wrote. Whereas k1 to k4 indeed correspond to:
k1 – bandwidth,
k2 – load (but also bandwidth, see formulas below),
k3 – delay,
k4 – reliability,
the k5 value ALSO corresponds to reliability, not MTU. It couldn’t have anything to do with MTU, because MTU is NOT used in the metric calculation.
The actual formula depends on the value of k5.
If k5 == 0 then
metric = 256*[ (k1*bandwidth) + (k2*bandwidth)/(256-load) + (k3*delay) ]
else
metric = 256*[ (k1*bandwidth) + (k2*bandwidth)/(256-load) + (k3*delay) ] *k5/(k4 + reliability)
No MTU here, and both k4 and k5 correspond to reliability.
—
Wojtek
Thank you very much! 🙂
enter your message here…[quote=MysticRyuujin]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.
Where is this section in the final configs? Looking at the final config for R5 doesn’t show any changes to any interface bandwidths or delays, I’m seeing a traffic load share of 1:40, nothing close to the 3:80 you’re requesting…[/quote]
Renee did a lab on traffic shaping (http://gns3vault.com/EIGRP/eigrp-variance-traffic-engineering.html). If you watch his video he will show you how to adjust the ratio between routes and that should give you a hint on how to do the 3:80 ratio asked by the lab.
rene,
plz add topology file for this lab…
[url=]https://www.dropbox.com/s/uwlg6lrgshsldla/EIGRP%20Advanced.rar[/url]
Salam
There’s the lab with the topology, the gns3 pic is used as wallpaper of the lab
[url=]https://www.dropbox.com/s/uwlg6lrgshsldla/EIGRP%20Advanced.rar[/url]
R6 and R3 should ignore EIGRP updates from one another but maintain their neighborship….etc
Ok I’m not sure how this works. Looking at the configs its using a prefix list to allow 192.168.3.5/32, but I’ma bit lost how that works. It’s not like it’s saying only accept updates from THIS router, its saying only accept updates that match this route. What am I missing here?
After applying that prefix-list on a distribute-list in the result is no updates on Fa0/0 as expected, since there are no matching routes.
Thanks
Did a solution video or final configs ever get made for this lab. Just struggling on my route-map (logical thinking DOH!!!)…
Would like to glance over, as it is a big lab….
Would be useful.
Thanks
“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.”
On this point, I was able to tag the routes and redistribute to AS 200 and vice-versa. I’m curious to know how/when routing loops occur in the above given lab if we don’t do tagging. It would be great if anyone comes up with good practical explanation.
Thanks! Hoping to see a reply from experts…..
I wrote this lab years ago, probably at a time when I did not fully understand it myself. AD will probably prevent any routing loops in this scenario as is, although I have not studied it recently. I just wanted people to think through tagging since it is NOT automatic like AD often is.
Nice lab, thanks Rene, really enjoying!
I finished what i could in about two hours, but i was not able to solve
the following any help would be great
my email is: ajtaurus2011@gmail.com
• 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.
• 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.
• 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.
thanks before hand
It has been years since I wrote this lab… I will do my best here. The metric translation is a set of route-maps that essentially match metric ranges, then set some parameters. So, match metric 0 – 100000, set metric a b c d e. Something like that.
Regarding R6 and R3, you’ll need a prefix-list gateway to accomplish this. You’ll also need to configure R5 to send updates to both routers on the segment as a segment.
The last bullet is straightforward. Build a prefix list (2 lines), and apply it under EIGRP (1 line).
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.
I can’t understand this task please help me out
You need to use the “match metric” and “Set metric” constructs here. For example
match metric 250000 +- 250000
set metric x 10 x x x
Something like that…
Hello sir
I am studing for CCNP and do your LABs thank you for making these LABs
I Ask you to please Make Video for this Scenario too because when you are configing many thing I catch from your configuration And I can correct my wrong thought and Misconfigs
Thank you sir
Soheil Taran
After 2 days of hard work. Finally got this done.
Took time but learnt a lot! thanks a ton!
Pheww!!
People,
In reference to the exercise below:
“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.”
I don’t see this route explicity include inside the neighbors routing table. So, Is it needed to use LEAK-MAP to include it?
Thank you.
Luiz Polli