Link Type 100+ Mbps Token Ring 10-Mbps Ethernet Serial Load and Reliability in Objective-C

Encoding PDF 417 in Objective-C Link Type 100+ Mbps Token Ring 10-Mbps Ethernet Serial Load and Reliability

Load is not normally used, but when it is, it is based on the exponentially weighted average of how saturated the link is during a given sample period The sample period is normally five minutes, and the load calculation is updated every five seconds (in other words, every five seconds, the load calculation will change to reflect the load on the link in the previous five minutes) Load is measured from 1 to 255, with 1 being minimal use and 255 being fully saturated (100 percent used) Reliability is similar to load in that it is calculated using an exponentially weighted average that is taken from activity occurring in the previous five minutes and is updated every five seconds It is also not normally used Reliability, however, uses a reverse scale from load (I

am convinced this was done solely to cause confusion), with 255 being completely error-free and 1 being unusable Calculating the Formula Now that you have a better idea of how each component is calculated, take a look at that formula again: metric = K1 x Be + (K2 x Be)/(256 load) + K3 x Dc) x (K5/(reliability + K4) Well, you now know what the Be and Dc are, but what about all those Ks K is a constant, referred to as a weight Weights allow you to assign different priorities to different metric components, which is useful when classifying traffic and routing packets based on the classification For instance, for voice traffic, latency (delay) is most important, with bandwidth being secondary For file transfers, however, delay is pretty unimportant, while bandwidth reigns supreme The original idea was to use IGRP as a routing mechanism that could use packet classifications to choose the best route for specific types of traffic, but this concept was never fully implemented, so choosing weights ends up coming down to choosing which metric component you feel is most important Simple Metric Calculations Usually, it is recommended that you simply use the defaults, which are K1 (bandwidth weight) = 1, K3 (delay weight) = 1, K2 (load weight) = 0, K4 (secondary reliability weight) = 0, and K5 (primary reliability weight) = 0 With the default weights, only K1 and K3 are used The rest of the weights are set to zero, which, instead of being inserted as zero into the equation (and giving a resulting metric of zero for every route), means that part of the equation is removed After removing the unused sections of the equation, the formula simplifies to this: metric = K1 x Be + K3 x Dc, or, even more simply (because the default weights for K1 and K3 are 1), metric = Be + Dc With the default weights, metric determination is fairly simple For instance, examine the network shown in Figure 24-3

Figure 24-3: Network for the basic metric calculation example In this example, calculating the metric for the route from Miura to Net 4 is fairly simple First, you find the lowest bandwidth in the path, which is the serial link between Urraco and Jalpa You then divide 10,000,000 by the bandwidth in bps of that link to create the final bandwidth figure, 19,531 You then add up all of the delays on all of the outgoing interfaces to create a delay score of 40,630 (20,000 + 20,000 + 630) You then divide this delay score by 10 (because delay is calculated for the metric in units of ten microseconds) for a total of 4,063 Finally, you add the bandwidth to the delay to achieve a total metric of 23,594

You need to be aware of a couple of points here First, notice how the outgoing interface is used to achieve the delay score This point is important, because it means that the path from Net 1 to Net 4 will have a metric of 23,594, but the return path has a metric of 23,631 (19,531 (bandwidth) + 2,000 + 2,000 + 100 (delays)) Keep in mind that in a large, complex network, a packet might take a different path to return than it took to arrive Second, notice how important bandwidth is in this example Delay was responsible for 4,063 points (about 20 percent) on the metric, while bandwidth accounted for a whopping 19,531 (75 percent) The moral of the story is that, with the default weights, delay along the path typically has minimal impact compared to bandwidth If you wanted to reduce bandwidth's role in metric determination, you would either increase the delay weight (K3) or increase the delay settings for each link Because you are already using the recommended delay figures, let's increase K3 and examine the results With this example, if you set K3 to equal 2, then your simplified formula would change to metric = Be + (2 x Dc) In this case, the bandwidth computation is 19,531, while the delay is 8126 That's not quite good enough If you increase the weight to 4, however, you have a much better match In this network, this would give you a metric of 35,783, with approximately a 50/50-percent split between bandwidth (19,531) and delay (16,252) This split is pretty good if you want delay to make a large impact on route selection Now, in this network, if you added a slightly higher speed (like 1544 Mbps) but a high-latency link (for instance, a VPN tunnel through another network) between Urraco and Jalpa, it would be not preferred over the standard serial link Okay, now that you have learned how to handle the weights and values for bandwidth and delay, what about load and reliability Well, first, load is not typically used (and highly discouraged) because load is not controllable, and a transient high load measurement can cause a route to fail However, because load can only double the total metric (with a K2 value of 1, anyway), I don't typically consider this to be the main problem Tips for Using Weights Cisco recommends that you leave the weights at their default settings, mostly because if you don't understand the consequences involved with changing them, you might make poor routing choices I generally break with Cisco a bit on this subject, however, and recommend that you understand not only the math behind metric calculation, but also the needs (latency vs throughput) of your network applications If you feel you have a firm grasp of these concepts, I suggest computing an optimal weighting scheme and testing the scheme in a lab environment to see whether you can obtain a performance improvement If you cannot set up a lab (due to costs or other constraints), then choose a time of little or no activity and test then One way or another, be very careful about changing weights in a production network until you are sure the results will be favorable Be aware that if you change the delay (K3) weight, that delay is the sum of all delays between the source and the destination In a large network, you may actually have to increase the bandwidth (K1) weight instead of the delay (K3) weight, because the cumulative delays may be very large indeed For instance, if you had 22 serial hops and a 512-Kbps slowest link, with the default K values, delay would be responsible for 44,000 points of the metric (2,000 x 22), while bandwidth is responsible for only 19,531 points

The primary problem with either load or reliability is that they tend to cause significant traffic through flash, or triggered, updates These flash updates cause the remote routers to place the route in holddown and, in some cases, remove the route from the table entirely (The best route can become the worst route very quickly, and with little or no warning) To illustrate, change the K2 weight to 1 for the previous example, and examine the resulting formula and metric calculation The formula that would result (with the default weights for K1 and K3) would be metric = bandwidth + (bandwidth/(256 load) + delay If the load calculation were the lowest possible (remember, load is not set, it is measured, so you have no control over this), the metric would be 19,531 + (19,531/255) + 4,063 = 23,671 This figure is almost the same as before, right Yes, but what if the load rises to its maximum (255) Then you have 19,531 + (19,531/1) + 4,063 = 43,125 This figure is a big difference A second side effect of this metric change is that it will cause a triggered update And because load is updated every five seconds, if you had a really "bursty" line, load has the ability to cause triggered updates every five seconds, which is bad news Furthermore, if you give load a high weight (by setting the K2 weight), like 1000, serious problems may result With this kind of weight, the formula changes to this: bandwidth + (bandwidth x 1,000/(256 load) + delay When you plug in the numbers, it looks like this (with a load of 255): 19,531 + (19,531,250/1) + 4,063 = 19,554,844 Pretty significant jump, huh What's worse is that with a load of 1, it looks like this: 19,531 + (19,531,250/255) + 4,063 = 100,187 This leads to a metric that has a pretty wide range, all controlled by a factor that you can't manually modify The end result is that problems tend to occur at the worst possible times Reliability can cause the same constant triggered updates problem as load, although it normally doesn't Because most lines today are relatively error-free, you will likely see little or no difference in the metric due to reliability However, because reliability multiplies the rest of the calculated metric, on an error-prone link, reliability has the ability to singlehandedly cause a route to be removed because it can cause a metric to be higher than infinite (4,294,967,295) Reliability also uses two weights, K4 and K5, to attempt to "scale" the calculation to be more or less powerful For instance, in the previous example, with the bandwidth (K1) weight set to 1, the load (K2) weight set to 1, and the delay (K3) weight set to 1, if you set the reliability weights (K4 and K5) to 1, the resulting formula will be (bandwidth + (bandwidth/(256 load) + delay) x (1/(reliability + 1)) With a maximum reliability score (255) and a minimal load (1), plugging in the numbers ends up looking like this: (19,531 + (19,531/255) + 4,063) x (1/(255 + 1)) = 92 Whoa, big jump, huh In this case, maximum reliability cuts the metric down to practically nothing However, with a minimum reliability score (1) and a maximal load (255), plugging in the numbers ends up looking like this: (19,531 + (19,531/1) + 4,063) x (1/(1+1)) = 21,563 As you can see, reliability can greatly impact your metric calculations Therefore, I suggest that you do not use reliability in your metrics Advanced Metric Calculation So what do you do if you actually need to use all of the metric components to calculate your metrics First, realize that all of the metrics are very rarely needed But sometimes, you might need to use all of the metric variables in the metric calculation Take the remote office network shown in Figure 24-4, for example

Figure 24-4: Network for the complex metric calculation example Note With the possible exception of the CCIE lab exam, you will most likely never need to understand IGRP or EIGRP metric calculation to the degree covered here, because almost no one goes to all of this trouble in real life I am including the subject just so you have a better understanding of how the variables in a metric work together to create the total metric In this case, a router at a distant location needs to have full redundancy in its connection to the network at HQ In this location, let's say a large number of huge file transfers need to take place In this scenario, you want the router to use the highest speed link possible for the route to HQ, but you want load on the link to be taken into account In addition, because some of the links are not very reliable (the satellite link, for instance), you want reliability to be accounted for Finally, delay, although important, is not nearly as important as unused bandwidth for this scenario Tip If you want to perform these calculations, the best strategy is to build a spreadsheet that allows you to punch the numbers into the various variables until you achieve the desired results Attempting to perform this math using pencil, paper, and a standard calculator is a frustrating and time-consuming process For a free Excel spreadsheet that can be used to perform these calculations, visit http://wwwalfageekcom/mybookshtm You want to make sure that the satellite link is used as the primary link if it has ample bandwidth and is reliable, because it is the fastest link If there is a reliability issue or most of the bandwidth is being used on the satellite link, you want the T1 to be used If the T1 is having reliability difficulties or is heavily overused, you want the ISDN link to be used The problem is that, with the default weights, you would end up using the ISDN link much more than the other two links, which is not the idea Let's plug the math into the equation (Note that, in this example, delay shown on the links in question is the cumulative delay for the route to HQ, not the individual delay settings for each link) With default settings, the K1 and K3 values are 1, and K2, K4, and K5 are all 0, making the final equation simply bandwidth + delay = metric In this scenario, the ISDN link would have a metric of 80,125 (78,125 + 2000), the satellite link would have a metric of 121,000 (1,000 + 120,000), and the T1 would have a metric of 84,477 (6,4767 + 78,000) Therefore, the ISDN line would be preferred Several solutions exist to this problem (The Cisco suggested solution is to adjust the delays; but in this case, we will assume the delays are accurate) However, the only solution that accomplishes all of the goals is to modify the weights To eliminate the initial problem of the ISDN line being preferred over the faster T1 and sat links, you could modify the delays on the sat and T1 links (again, this is the Ciscorecommended solution) But your problem is that, for the sat link, the delay figure is accurate;

and for the T1, the delay figure is caused by the route having to be sent through 30+ routers, all with a delay of 20,000 leading to a massive cumulative delay To reduce the delay figure on the T1, you would either need to purchase a PVC directly to the HQ (to reduce the number of hops in the path) or change the delay figures on all of the routers in the path (a solution with unintended consequences, because other routers in the WAN that do not have this specific problem also use these delay figures) However, if you change the bandwidth (K1) weight on the remote router, it will not adversely affect other routers and it will accomplish the goals By changing the K1 to 8, you would change the metrics as follows:

ISDN link: (78,125 x 8) + 2,000 = 627,000 Sat link: (1,000 x 8) + 120,000 = 128,000 T1 link: (64767 x 8) + 78,000 = 129,813

Bingo Initial problem solved The sat link is now preferred, with the T1 second, and the ISDN is a long last However, now you need to take load into account If you change the load (K2) weight to a nonzero integer, you end up with the following formula: (K1 x bandwidth) + (K2 x bandwidth)/(256 load) + delay With a K2 of 1, your metrics would look like this under a minimal load:

ISDN link: (78,125 x 8) + (78,125/(256 1)) + 2,000 = 627,306 Sat link: (1,000 x 8) + (1,000/(256 1)) + 120,000 = 128,004 T1 link: (6,4767 x 8) + (6,4767/(256 1)) + 78,000 = 129,839

So, under minimal load, nothing really changes Well, let's see what happens if you put the sat link under full load Remember, the goal was to have the T1 be used if the sat link was saturated Under full load for only the sat link, the metrics would be as follows:

ISDN link: (78,125 x 8) + (70,000/(256 1)) + 2,000 = 627,306 Sat link: (1,000 x 8) + (1,000/(256 255)) + 120,000 = 129,000 T1 link: (6,4767 x 8) + (6,4767/(256 1)) + 78,000 = 129,839

Close, but no cigar Even under full load, the route through the sat link still has a lower metric than the route through the T1; therefore, the sat link will still be the primary link, even under times of heavy congestion To solve this problem, you need to make the load a more important factor in the metric calculation by increasing the K2 To simply ensure that the route through the T1 will be the primary route if the sat link is fully saturated, you could just increase the K2 to 2 However, then the sat link will have to reach full saturation before the route through the T1 becomes the primary route Actually, if the sat link is more than 85-percent saturated (because the sat link is down to less than 15 Mbps at 85-percent saturation), and the T1 is unsaturated, the preferred primary route should be through the T1 To enable this setup, you need to increase the K2 to a level where the sat link at a load score of 217 (85 percent) becomes the secondary route Unfortunately, because load is on a logarithmic scale (sort of like half of a bell curve), load doesn't really start significantly influencing the metric until it reaches 252 or higher To allow the route through the T1 to become the primary route once the sat link reaches 85percent saturation, you have to increase the K2 to around 10,000 As a result, load become a major influence in route selection and, normally, would cause problems with excessive triggered updates However, in this situation, the remote router is an edge device that doesn't

re-advertise the routes to HQ back to any other routers (due to split horizon), so increasing the K2 won't cause any update or holddown problems Once you increase the K2 to 10,000, the metrics with the sat link at a 217 load and the other links at 1 become the following:

ISDN link: (78,125 x 8) + ((10,000 x 70,000)/(256 1)) + 2,000 = 3,690,725 Sat link: (1,000 x 8) + ((10,000 x 1,000)/(256 217)) + 120,000 = 384,410 T1 link: (6,4767 x 8) + ((10,000 x 6,4767)/(256 1)) + 78,000 = 383,801

Now let's see what happens if the T1 is saturated as well (Remember, the goal was to have the ISDN link become the primary route if the T1 and the sat link were saturated) Again, you are looking for the route through the ISDN line to become the primary if the sat link is over 99-percent saturated (253 load) and the T1 is over 92-percent saturated (235 load) The numbers, if both the T1 and sat link were saturated, are as follows:

ISDN link: (78,125 x 8) + ((10,000 x 70,000)/(256 1)) + 2,000 = 3,690,725 Sat link: (1,000 x 8) + ((10,000 x 1,000)/(256 253)) + 120,000 = 3,461,333 T1 link: (6,4767 x 8) + ((10,000 x 6,4767)/(256 235)) + 78,000 = 3,213,949

You are very close, but still no cigar At this level of saturation, the route through the T1 would still be the primary, the route through the sat link would be the secondary, and the ISDN would be a close third So what do you need to do That's right, increase the K2 yet again Like before, due to the logarithmic nature of the load calculation, you will have to increase the K2 by a very large number to achieve your goals In this case, you will have to increase K2 to around 300,000 Once you increase the K2 to 300,000, the metrics under the previous load values are as follows:

ISDN link: (78,125 x 8) + ((300,000 x 70,000)/(256 1)) + 2,000 = 92,538,765 Sat link: (1,000 x 8) + ((300,000 x 1,000)/(256 253)) + 120,000 = 100,128,000 T1 link: (6,4767 x 8) + ((300,000 x 6,4767)/(256 235)) + 78,000 = 92,653,870

Whew! It's a good thing the infinite metric in IGRP is 4 billion! Now, let's add the final two weights (K4 and K5) and put reliability into the equation In this case, you would like to use the sat link unless it is unreliable enough that the T1 will have a higher throughput (due to retransmissions required on the sat link) Again, with just reliability taken into account, the sat link would have to reach an 85-percent error rate for the route through the T1 to be faster An 85-percent error rate on the sat link ends up as a 38 reliability rating (Remember, reliability is backward, with 255 being the best and 1 being the worst) Because the T1 is a reliable link, you don't need to be too concerned about reliability issues with it Therefore, this equation will be a bit simpler than the load equation because you do not need to worry about failover to the ISDN due to T1 reliability Note In actuality, IGRP metrics are 24-bit, making the infinite metric 167 million, not 4 billion (which is the infinite value for EIGRP) However, this is a miniscule point in most environments, where the metrics typically never reach either maximum value I chose to use 4 billion as the maximum value in this chapter in order to illustrate the use of extremely large metrics Just keep in mind that metrics larger than 16 million are not actually valid in IGRP Before modifying the reliability weights for the example, let's look at the details of the reliability calculation When modifying the K4 and K5 weights, you need to realize the

purpose of each and the mathematical relationship each has with the rest of the metric The composite metric calculated up to this point is modified in its entirety by the reliability portion of the equation Basically, the relationship boils down to this: (all of the other factors) x (reliability factors) = metric So, reliability will modify everything else As far as the reliability portion of the equation is concerned, K4 and K5 influence each other Just for review, the formula in the reliability portion of the equation is K5/(reliability + K4) You can use K4 to decrease the metric range based on reliability (in other words, K4 sets how important reliability is), and K5 to increase or decrease the final metric For instance, if your base metric (before setting K4 and K5) is 500,000, you set K4 and K5 to be 1, and then you compute the metric at maximum reliability (255), your final formula will be (500,000) x (1/(255 + 1)), for a final metric of 1,953 If you set K5 to be 2, however, your formula becomes (500,000) x (2/(255 + 1)), for a final metric of 3,906 To understand K5, think of it as a metric scalar, meaning that it can scale the final metric up or down to match it to your environment K4, on the other hand, tells you how important reliability is in the final metric calculation For instance, in the previous example, with a base metric of 500,000 and K5 and K4 values of 1, the metric with a reliability rating of 255 was 1,953 However, with a reliability rating of 1, the metric increases to a whopping 250,000! If you set K4 to be 1,000, however, the metric with a 255 reliability is 398, while the metric with a 1 reliability is 500 In this manner, K4 determines how much reliability matters in the final metric You must be very careful when matching K4 and K5 in your metric calculations, because if you set K5 too low and K4 too high, you will end up with extremely low metrics For instance, with a base metric of 500,000, if you set K4 = 1,000,000 and K5 = 1, your metric will always be 1, regardless of the reliability of the link Now that you have seen how K4 and K5 modify the metric, let's configure the reliability settings for our "Complex Metric Calculation" example So far, in my example, I have decided on the following weights: K1 = 8, K2 = 300,000, K3 = 1 These weights provide the following metrics during periods of low congestion (load of 1):

ISDN link: 92,538,765 Sat link: 1,304,471 T1 link: 7,749,442

These weights also provide the following metrics in times of total congestion (load of 255):

ISDN link: 23,438,127,000 (unreachable, infinite distance) Sat link: 300,128,000 T1 link: 1,943,134,995

Again, the main goal is to allow the route through the T1 to become the primary route if the sat link experiences error rates of greater than 85 percent (reliability rating of 38 or lower) Secondarily, you also want to reduce the metrics to numbers that are within the realm of mere mortals Finally, you want to ensure that the best route will be chosen based on the combination of available bandwidth and reliability For this exercise, I chose a K4 value of 5 and a K1 value of 1 When you plug those figures into the equation, with no congestion, if the sat link has a reliability rating of 38, the formulas work out as follows:

ISDN link: 92,538,765 x (1/255 + 5) = 355,918 Sat link: 1,304,471 x (1/38 + 5) = 30,337 T1 link: 7,749,442 x (1/255 + 5) = 29,806

Notice that the route through the sat link becomes a higher-cost route than the T1 link if the reliability of the sat link drops to 38 or lower If the sat link also had congestion, the metric differences would be even more pronounced For instance, if the sat link were experiencing 50-percent congestion as well (load of 128), the metric for the sat link would be 57,483 The final formula is (8 x bandwidth + (300,000 x bandwidth)/(256 load) + delay) x (1/reliability + 5) The final weights are K1 = 8, K2 = 300,000, K3 = 1, K4 = 5, and K5 = 1