April 16, 2013 at 09:38Composite EIGRP Metric
- Tutorial
Which just did not have to read articles about the composite metric EIGRP. Both very useful and frankly stupid. Let's look at what's what again. I will try not to chew what has already been chewed 10 times, but to point out interesting, in my opinion, features and tricks of counting this very composite metric in a short article. Recall the nightmare formula:
Here it is immediately very important to remember the first rule once and for all:
Rule 1:K-values are not bandwidth, delay, loading, or whatever else as we were taught in the CCNA track or in many articles! K-values (K1, K2, K3, K4 and K5), these are some indices, changing which, we can influence the calculation of the composite metric. The BW value is not just the minimum bandwidth value, but 10,000,000 (10 ^ 7) divided by the minimum bandwidth value, and delay is not just the sum of all interface delays, but the sum divided by 10.
As we all know, the following are used to calculate the route metric parameters:
With bandwidth, everything is simple. We got an announcement on some interface. If the bandwidth on this interface is less than what we received in the announcement, we replace the value in the announcement and the helmet further. Thus, from any point to any, the endpoint will receive an announcement with a minimum bandwidth over the entire route. The same rule applies to MTU. By the way, both values are taken into account, and L2 MTU of the interface, and L3 IP MTU, a smaller value is selected. This is not written in books. Another interesting fact is that changing the MTU on the interface does not cause the update of the route, and for the change to actually take effect, you have to pull the interface, or change another parameter, for example delay or bandwidth, to cause update. Another little-known fact.
Delay is still easier. We received an announcement on the interface - we added our delay to this interface in the delay value and are announcing further. I honestly couldn’t understand exactly how reliability and load behave from hop to hop, since I could not emulate their change. I will be glad if someone completes this post.
UPD: In the comments they suggest that reliability, like bw / mtu, is transmitted the worst on the highway. Load, it seems, is summed up, but until it runs into 255.
Rule 2: only the interfaces on which we received the announcement are taken into account in the calculations. Interfaces where we send these announcements are not taken into account at all, whatever the bandwidth, delay, MTU parameters are.
Here the head begins to break. How does the router, having received the announcement, find out what is the minimum bandwidth on the way to subtract it from the composite metric and replace it with its own? What about the other options? Interesting. Let's open the book Troubleshooting IP Routing Protocols (CCIE Professional Development) , which shows the structure of the EIGRP IP Internal Route TLV package:
Where is the composite metric here? But not her. From hop to hop, only the parameters themselves are passed. Derive:
Rule 3: Composite metrics are not passed between routers. The metric is calculated locally on the router, and exists only on it. Further, the router transmits only the changed parameters of bandwidth, delay, MTU, etc.
From here we can draw interesting conclusions. Firstly, since the composite metric is not transmitted, it becomes extremely clear why K-values must coincide in order to establish a neighborhood. Otherwise, each router will consider it in its own way, and not far from the loop. Secondly, if we consider all 5 parameters transmitted from hop to hop, it becomes clear that we can only control one - delay, since bandwidth always carries the minimum value of bandwidth along the track, reliability and load are not at all suitable for manual change and have the move is in a very narrow range (1-255), but MTU is similar to bandwidth. Hence the conclusion, if we carry out Traffic Engineering and adjust the EIGRP metric using an offset-list, we only change the delay value and only it, and do not add / subtract the entire metric! Suppose we specified offset-list, correcting our metric by +100. As you know, delay is set in tens of microseconds, so immediately multiply by 10, we get 1000. Next, we know that the calculation formula for the EIGRP metric multiplies the result by 256 to improve the EIGRP metric compared to the IGRP metric, which has the same calculation formula . So we will divide 1000 by 256, and we will receive 3,90, we reduce to three. So, the next router will receive a delay parameter 3 microseconds more than it should have without an offset-list. and get 3.90, reduce to three. So, the next router will receive a delay parameter 3 microseconds more than it should have without an offset-list. and get 3.90, reduce to three. So, the next router will receive a delay parameter 3 microseconds more than it should have without an offset-list.
Armed with this information, having met a task on the CCIE R + S lab that requires giving one route an advantage over another by changing the delay parameter, but you are not allowed to change the delay on the interface in the text of the task, feel free to write the usual offset-list.
UPD2: As correctly noted in the comments, MTU does not participate in the calculation of the metric at all. However, this is one of the attributes that we specify wherever we need to manually specify the metric, for example during redistribution. Changing this attribute in the announcement of the prefix from hop to hop is handled in the same way as attributes that affect the metric.
Here it is immediately very important to remember the first rule once and for all:
Rule 1:K-values are not bandwidth, delay, loading, or whatever else as we were taught in the CCNA track or in many articles! K-values (K1, K2, K3, K4 and K5), these are some indices, changing which, we can influence the calculation of the composite metric. The BW value is not just the minimum bandwidth value, but 10,000,000 (10 ^ 7) divided by the minimum bandwidth value, and delay is not just the sum of all interface delays, but the sum divided by 10.
As we all know, the following are used to calculate the route metric parameters:
- The minimum bandwidth value among all interfaces along the route
- The sum of the delay values of all interfaces along the route
- Reliability
- Load
- The minimum MTU among all interfaces along the route
With bandwidth, everything is simple. We got an announcement on some interface. If the bandwidth on this interface is less than what we received in the announcement, we replace the value in the announcement and the helmet further. Thus, from any point to any, the endpoint will receive an announcement with a minimum bandwidth over the entire route. The same rule applies to MTU. By the way, both values are taken into account, and L2 MTU of the interface, and L3 IP MTU, a smaller value is selected. This is not written in books. Another interesting fact is that changing the MTU on the interface does not cause the update of the route, and for the change to actually take effect, you have to pull the interface, or change another parameter, for example delay or bandwidth, to cause update. Another little-known fact.
Delay is still easier. We received an announcement on the interface - we added our delay to this interface in the delay value and are announcing further. I honestly couldn’t understand exactly how reliability and load behave from hop to hop, since I could not emulate their change. I will be glad if someone completes this post.
UPD: In the comments they suggest that reliability, like bw / mtu, is transmitted the worst on the highway. Load, it seems, is summed up, but until it runs into 255.
Rule 2: only the interfaces on which we received the announcement are taken into account in the calculations. Interfaces where we send these announcements are not taken into account at all, whatever the bandwidth, delay, MTU parameters are.
Here the head begins to break. How does the router, having received the announcement, find out what is the minimum bandwidth on the way to subtract it from the composite metric and replace it with its own? What about the other options? Interesting. Let's open the book Troubleshooting IP Routing Protocols (CCIE Professional Development) , which shows the structure of the EIGRP IP Internal Route TLV package:
Where is the composite metric here? But not her. From hop to hop, only the parameters themselves are passed. Derive:
Rule 3: Composite metrics are not passed between routers. The metric is calculated locally on the router, and exists only on it. Further, the router transmits only the changed parameters of bandwidth, delay, MTU, etc.
From here we can draw interesting conclusions. Firstly, since the composite metric is not transmitted, it becomes extremely clear why K-values must coincide in order to establish a neighborhood. Otherwise, each router will consider it in its own way, and not far from the loop. Secondly, if we consider all 5 parameters transmitted from hop to hop, it becomes clear that we can only control one - delay, since bandwidth always carries the minimum value of bandwidth along the track, reliability and load are not at all suitable for manual change and have the move is in a very narrow range (1-255), but MTU is similar to bandwidth. Hence the conclusion, if we carry out Traffic Engineering and adjust the EIGRP metric using an offset-list, we only change the delay value and only it, and do not add / subtract the entire metric! Suppose we specified offset-list, correcting our metric by +100. As you know, delay is set in tens of microseconds, so immediately multiply by 10, we get 1000. Next, we know that the calculation formula for the EIGRP metric multiplies the result by 256 to improve the EIGRP metric compared to the IGRP metric, which has the same calculation formula . So we will divide 1000 by 256, and we will receive 3,90, we reduce to three. So, the next router will receive a delay parameter 3 microseconds more than it should have without an offset-list. and get 3.90, reduce to three. So, the next router will receive a delay parameter 3 microseconds more than it should have without an offset-list. and get 3.90, reduce to three. So, the next router will receive a delay parameter 3 microseconds more than it should have without an offset-list.
Armed with this information, having met a task on the CCIE R + S lab that requires giving one route an advantage over another by changing the delay parameter, but you are not allowed to change the delay on the interface in the text of the task, feel free to write the usual offset-list.
UPD2: As correctly noted in the comments, MTU does not participate in the calculation of the metric at all. However, this is one of the attributes that we specify wherever we need to manually specify the metric, for example during redistribution. Changing this attribute in the announcement of the prefix from hop to hop is handled in the same way as attributes that affect the metric.