INE Workbook Vol 1 EIGRP

Another day, another section to study!

I haven't picked up too much from the eigrp section. This tells me I'm pretty well versed in EIGRP. I did pick up a few tips:

When configuring an interface level summary address, you can assign a distance of 255 to the summary. This will prevent the installation of the null route (thus preventing blackhole activity of summary component subnets) but will still advertise the summary.

interface fastethernet0/0
ip summary-address eigrp 100 150.1.4.0 255.255.252.0 255

I received another scenario where I needed to prefer one route over the other. Ok, no problem I can alter the bandwidth or delay metric to make that happen. So I view the EIGRP topology table for that subnet. Uh-oh, there is only one route available. I immediately thought there was something wrong with my topology or something else going on. That was not the case. The problem was a downstream router only advertises a candidate that meets the Feasibility condition and since split-horizon is enabled on the link, the route will not advertise back upstream. Now if I alter the metrics so the downstream router prefers the path that I want, I will achieve the desired solution.  Well, I hope that makes sense! It was a good scenario and shows you the process of EIGRP.

I've learned that because of the feasibility condition, you will not see all available routes, only those that meet the condition so you need to go step by step throughout the topology, and comparing the metrics. To make this easier, INE changed the metrics to only delay so to calculate a metric would simply be the sum of delay * 256. Once you step through the topology and view the metrics, you will see how you can get alternate paths into EIGRP. Very good scenario. Next, you need to balance the traffic by 5 to 1. Wow. This was a tough one and one that I will have to read and re-read again....I don't get where INE get's their math from. After some time, I finally figured it out. I am going to attempt to explain it here below, and then I am calling it a night!

From Cisco's whitepaper [http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#loadbalancing]

"How does the router divide the traffic between these paths? It divides the metric through each path into the largest metric, rounds down to the nearest integer, and uses this number as the traffic share count."


So look at your two available routes in your routing table.



R6(config-subif)#do sh ip route 155.1.9.9
Routing entry for 155.1.9.0/24
  Known via "eigrp 100", distance 90, metric 7680, type internal
  Redistributing via eigrp 100, eigrp 10
  Advertised by eigrp 10 metric 1 1 1 1 1
  Last update from 155.1.146.1 on FastEthernet0/0.146, 00:00:11 ago
  Routing Descriptor Blocks:
    155.1.146.1, from 155.1.146.1, 00:00:11 ago, via FastEthernet0/0.146
      Route metric is 8192, traffic share count is 15
      Total delay is 320 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 4
  * 155.1.67.7, from 155.1.67.7, 00:00:11 ago, via FastEthernet0/0.67
      Route metric is 7680, traffic share count is 16
      Total delay is 300 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2


To get a traffic share count of 5 to 1, your composite metric must be 5 times that of your best route. So from above, we need 5 times 76800 or 38400. Ok, here are the delay of our links.


R6 (100) -> SW1 (100) -> SW3 (100) = 300usec which is 30msec * 256 = 7680.
R6 (100) -> R1 (10) -> R3 (10) -> SW1 (100) -> SW3 (100) = 320usec/32msec * 256 = 8192


Ok, hopefully everyone is still with me. We need a metric of 38400. Let's get back to delay numbers so divide by 256 = 150msec of 1500usec. We can change the delay anywhere or everywhere along the path (provided we still meet feasibility condition) but to make it simple, just change one link! We will change R6 as listed above. So subtract the delays from the other links you are not changing and that will give you your delay number for R6.


1500 - SW3 (100) = 1400
1400 - SW1 (100) = 1300
1300 - R3 (10) = 1290
1290 - R1 (10) = 1280


1280usec is what we need on R6, but remember, you configure delay on the interface in msec, so 1280 becomes 128.


R6 (config)# interface f0/0.146
R6(config-subif)#delay 128


Now give EIGRP a few seconds to re-compute and tada!!



R6(config-subif)#do sh ip route 155.1.9.9
Routing entry for 155.1.9.0/24
  Known via "eigrp 100", distance 90, metric 7680, type internal
  Redistributing via eigrp 100, eigrp 10
  Advertised by eigrp 10 metric 1 1 1 1 1
  Last update from 155.1.146.1 on FastEthernet0/0.146, 00:00:00 ago
  Routing Descriptor Blocks:
    155.1.146.1, from 155.1.146.1, 00:00:00 ago, via FastEthernet0/0.146
      Route metric is 38400, traffic share count is 1
      Total delay is 1500 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 4
  * 155.1.67.7, from 155.1.67.7, 00:00:00 ago, via FastEthernet0/0.67
      Route metric is 7680, traffic share count is 5
      Total delay is 300 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Wow, I really hope that helps someone because for me, it took forever to digest this and figure it out. It didn't help that INE's solution was confusing as all hell to me. I am going to call it a night and resume EIGRP tomorrow.