EIGRP Composite Metric
Which just did not have to read articles about the composite metric of EIGRP. Both very useful and frankly stupid. Let's look at what’s what. I will try not to chew on what has already been chewed 10 times, but to point out the interesting, in my opinion, features and tricks of counting this composite metric in a short article. Recall the nightmarish formula:
Here it is very important to remember the first rule once and for all:
')
Rule 1: K-values are not bandwidth, delay, loading, or whatever it was like we were taught in the CCNA track or in many articles! K-values (K1, K2, K3, K4 and K5) 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 amount divided by 10.
As we all know, the following parameters are used to calculate the route metrics:
With bandwidth, everything is simple. We received an announcement on some kind of interface. If the bandwidth on this interface is less than what we received in the announcement, we substitute the value in the announcement and send the helmet further. Thus, from any point to any, the end point will receive an announcement with a minimum bandwidth value along 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 chosen. This is not written in the books. Another interesting fact is that the change of MTU on the interface does not cause the update of the route, and in order for the change to take effect, you have to pull the interface, or change another parameter, such as delay or bandwidth, to trigger update. Another little known fact.
Delay is still easier. Received an announcement on the interface - added to the value of delay your delay of this interface and announce further. I honestly could not understand exactly how to behave from hop to hop reliability and load, since I could not emulate their change. I would be glad if someone complements this post.
UPD: The comments suggest that reliability, like bw / mtu, is the worst transmitted on the track. Load, it seems to be like, is summed up, but until it comes to rest at 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 considered at all, no matter what bandwidth, delay, MTU parameters would be on them.
Here the head begins to break. How does a router, having received an announcement, find out what is the minimum bandwidth on the way to subtract it from the composite metric and replace it with its own? How with other parameters? Interesting. Open the book Troubleshooting IP Routing Protocols (CCIE Professional Development) , which contains the structure of the EIGRP IP Internal Route TLV package:
Where is the composite metric here? And not her. Only the parameters themselves are passed from hop to hop. We derive:
Rule 3: Composite metric is not transmitted between routers. The metric is calculated locally on the router, and exists only on it. Further, the router transmits only the modified bandwidth, delay, MTU, etc. parameters.
From here you can draw interesting conclusions. First, since the composite metric is not transmitted, it becomes extremely clear why the 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 adjust one — delay, since the bandwidth always carries the minimum bandwidth on the highway, reliability and load are not at all suitable for manual change and have the move is in a very narrow range (1-255), but the MTU is similar to the bandwidth. Hence, if we carry out Traffic Engineering and adjust the EIGRP metric with the help of the offset-list, we change only the delay value and only that, and do not add / subtract from the entire metric! Suppose we specify an offset-list that corrects our metric by +100. As you know, delay is defined in tens of microseconds, then we will immediately multiply by 10, get 1000. Next, we know that the formula for calculating the EIGRP metric multiplies the result of calculations by 256 in order to improve the EIGRP metric, which has the same calculation formula . So we will divide 1,000 by 256, and we get 3.90, reduce to three. This means that the next router will receive the delay parameter by 3 microseconds longer than it should have been without an offset-list.
Armed with this information, having encountered a task on the CCIE R + S lab that requires giving one route advantage over another, changing the delay parameter, but you are forbidden to change the delay on the interface, feel free to write the usual offset-list.
UPD2: As was rightly 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 prefix announcement from hop to hop is handled in the same way as attributes affecting the metric.
Here it is very important to remember the first rule once and for all:
')
Rule 1: K-values are not bandwidth, delay, loading, or whatever it was like we were taught in the CCNA track or in many articles! K-values (K1, K2, K3, K4 and K5) 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 amount divided by 10.
As we all know, the following parameters are used to calculate the route metrics:
- The minimum value of bandwidth among all interfaces along the route
- The sum of the delay values of all interfaces along the route
- Reliability
- Load
- Minimum MTU among all interfaces along the route
With bandwidth, everything is simple. We received an announcement on some kind of interface. If the bandwidth on this interface is less than what we received in the announcement, we substitute the value in the announcement and send the helmet further. Thus, from any point to any, the end point will receive an announcement with a minimum bandwidth value along 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 chosen. This is not written in the books. Another interesting fact is that the change of MTU on the interface does not cause the update of the route, and in order for the change to take effect, you have to pull the interface, or change another parameter, such as delay or bandwidth, to trigger update. Another little known fact.
Delay is still easier. Received an announcement on the interface - added to the value of delay your delay of this interface and announce further. I honestly could not understand exactly how to behave from hop to hop reliability and load, since I could not emulate their change. I would be glad if someone complements this post.
UPD: The comments suggest that reliability, like bw / mtu, is the worst transmitted on the track. Load, it seems to be like, is summed up, but until it comes to rest at 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 considered at all, no matter what bandwidth, delay, MTU parameters would be on them.
Here the head begins to break. How does a router, having received an announcement, find out what is the minimum bandwidth on the way to subtract it from the composite metric and replace it with its own? How with other parameters? Interesting. Open the book Troubleshooting IP Routing Protocols (CCIE Professional Development) , which contains the structure of the EIGRP IP Internal Route TLV package:
Where is the composite metric here? And not her. Only the parameters themselves are passed from hop to hop. We derive:
Rule 3: Composite metric is not transmitted between routers. The metric is calculated locally on the router, and exists only on it. Further, the router transmits only the modified bandwidth, delay, MTU, etc. parameters.
From here you can draw interesting conclusions. First, since the composite metric is not transmitted, it becomes extremely clear why the 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 adjust one — delay, since the bandwidth always carries the minimum bandwidth on the highway, reliability and load are not at all suitable for manual change and have the move is in a very narrow range (1-255), but the MTU is similar to the bandwidth. Hence, if we carry out Traffic Engineering and adjust the EIGRP metric with the help of the offset-list, we change only the delay value and only that, and do not add / subtract from the entire metric! Suppose we specify an offset-list that corrects our metric by +100. As you know, delay is defined in tens of microseconds, then we will immediately multiply by 10, get 1000. Next, we know that the formula for calculating the EIGRP metric multiplies the result of calculations by 256 in order to improve the EIGRP metric, which has the same calculation formula . So we will divide 1,000 by 256, and we get 3.90, reduce to three. This means that the next router will receive the delay parameter by 3 microseconds longer than it should have been without an offset-list.
Armed with this information, having encountered a task on the CCIE R + S lab that requires giving one route advantage over another, changing the delay parameter, but you are forbidden to change the delay on the interface, feel free to write the usual offset-list.
UPD2: As was rightly 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 prefix announcement from hop to hop is handled in the same way as attributes affecting the metric.
Source: https://habr.com/ru/post/176831/
All Articles