EIGRP traffic engineering with delay modification

Note: I have modified the metric weights so that delay is the ONLY value used to calculate the composite metric.

First off, lets check to see what R4's EIGRP topology table shows for R3's loopback (3.3.3.3/32)...

As we can see here, R4 has equal costs via R1 and R2. We can also see that the total delay is currently 5200 microseconds, or 520 10s of microseconds. This is useful, as the delay calculation is 256*10s of microseconds, or 256*520 = 133120. We can also take the reported distance (delay calculation as advertised from our peer) to determine that both R1 and R2 have a delay value of 510 10s of seconds, or 5100.  

Now, say we wish to modify the path so that the preferred path from R4 is through R2, exclusively. We can shoot from the hip, and crank R1's delay to the moon (99999), or try and figure out what value we can configure so that the path will remain as a feasible successor. If we make the modification on R1, we will increase both the feasible distance as well as the advertised distance from R4's perspective. Unfortunately, if we crank the value up too high..it won't be a feasible successor. So the goal here is that we modify the feasible distance high enough, but not enough so that the value is greater than or equal to 133120.  

BAM! We increased the delay value on R1's fa1/0 interface to 11 10s of microseconds..or 110. With previous value of 100, we now see a total delay via R1 to be 5210 versus the 5200 via R2. By only increasing the delay by a marginal amount, we've successfully maintained R1 as a feasible successor, yay!

**********************Previous configurations removed**********************

What would have happened if we were to modify the delay value on R4’s fa0/0 interface?  Would we see the FD and the RD increase, or just one or the other?  Well, since the RD is what is “reported” to us from our neighbor, the value will stay the same.  Since we are modifying our local delay value, the FD will increase for both paths.  This might be a possible solution if we were to have two separate paths…but in this scenario it is a shared segment..so there will be no path changes.

**********************Previous configurations removed**********************

What happens if we increase the delay value on R1’s fa0/0 interface?  What will happen?  For sake of clarity, lets crank it up to 9999999.

As you can see, there is no change....From R4's perspective. But if we were to look at R3, it wouldn't see R1 as a feasible successor.

QoS DSCP/ToS conversion

Just a quick note on the conversion process with some examples and an explanation...

Prior to DiffServ, IPv4 networks could use the Precedence field in the TOS byte of the IPv4 header to mark priority traffic. The TOS octet and IP precedence were not widely used. The IETF agreed to reuse the TOS octet as the DS field for DiffServ networks. In order to maintain backward compatibility with network devices that still use the Precedence field, DiffServ defines the Class Selector PHB.

The Class Selector code points are of the form 'xxx000'. The first three bits are the IP precedence bits. Each IP precedence value can be mapped into a DiffServ class. CS0 equals to IP precedence 0, CS1 to IP precedence 1, and so on. If a packet is received from a non-DiffServ aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class Selector code point.

We have the hex value of 0x80 for our ToS.

0x80 in hex = 1000 0000 in decimal, or 128 in binary.

A quick in dirty to convert this to the PHB...drop the first 2 numbers.

100000 in binary or 32 in decimal.

Now, what lets look at the first 3 bits:

000000 = CS0
001000 = CS1
010000 = CS2
011000 = CS3
100000 = CS4
101000 = CS5
110000 = CS6
111000 = CS7

Based on our DSCP value of 100000, we can infer that this is CS4.

The way that we can tell that this is a CS DSCP value versus AF (Assured Forwarding), is that the trailing 3 bits are all 0.  If we have a 1 in the remaining 3 bits, then we know that it is an AF value.
Furthermore, the first half of the number is what identifies the priority and the second half of the number identifies the drop probability.  For example, AF31 has a lower drop probability than AF33, while AF31 has a higher priority than AF11.  The priority is derived from the first 3 bits.

For example,

010010 in decimal equals 18.  We can convert this into the AF value by dividing the decimal value by 8, and the remainder by 2.  18/8= 2 with a remainder of 2, or AF21.

Inversely, if we have the AF21 already, we can convert this into the decimal value by multiplying the first digit by 8 and the second digit by 2...and then add the result:

(8*2)+(2*1)=18.