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.

IPv6 notes

I've been gone for some time as a result of my CCIE studies.  One might think: Why aren't you using your blog to keep notes--everyone else is?"  I know...I just usually spend too much time dicking around with the formating and end up not using my time wisely.  I typically commit to making a blog post when I've learned something using examples I care about.

I've been reading quite a bit of material on IPv6, as I have training in 2 weeks and don't want to feel like I'm going in blind.

Today, I'll be doing an example on IPv6..and go through the motions.  All of the motions..even down to the decimal to hex conversion.

So..lets kick it off with this particular allocation that we have for work:

2620:158::/36

Based off that allocation, we can immediately realize two things:

1) HOLY SHIT, that is a lot of potential subnets, given the default host length of /64.  That mean, we have potentially 28 bits to play around with (64-36).  Using the 2^(X) formula, that equals 268,435,456 potential subnets.

2) EACH subnet could support 18,446,744,073,709,551,616 hosts.  Thats a lot of potential addresses.

So what is the full range of addresses available to us, based on the prefix 2620:158::/36?

Well, one helpful tidbit might be to figure out how the /36 address was derived.  If we have a /36, that means it was derived from a shorter prefix...possibly a /32?

If we use the 2620:158::/32 prefix..lets do some fancy magic using a couple basic steps:

1) Find the number of subnet bits:

Pretending we're the RIR responsible for handing out the /36s...how many /36s can we get from our existing /32?  Well...36-32 is equal to 4, and with 2 to the power of 4 (2^4) we can have 16 possible subnets from /32.

2) Find the number of subnet (or interesting hexits):

Subnet hexits = s/4 (round up!).  In our example, 16/4 = 4.  Thus, our sub-prefixes will be in the form of 2620:158:HHHH::/36
Note:

• If s/4 leaves a remainder, the the rightmost hexist will NOT end in something other than an "F."
• If s/4 DOES leave a remainder, then it means the hex values for each of the hexits for the last subnet will be "F."

We'll come back to that! 

3) Find the increment (or Block B)

This step required me to go do some reading on a math topic I haven't touched in some while: Modulus.  The formula is B=2^(16-L%16).  My first reaction: The hell is a percent sign doing in there :)

Essentially, the result is the remainder when dividing the two.  For our example, B=2^(16-36%16):

B=2^(16-4)
B=2^12
B=4096


Wait..what?  4096?  That's a huge number!  How can that be?  Well...thats in decimal.  We'll need to convert that into hex!





This can quite EASILY be done by using your windows calculator..but for the sake of knowing what exactly is going on...lets walk through it!

1.  Divide 4096/16:

Here, we have two important values:

1) 0!  We take this value and notate it.

2) 256!  We take this value and continue the process!

Current value: 0








2. Divide 256/16:

Same as before, we have two important values:


1) 0!  We take this value and add it to our running list.

2) 16!  We take this value and continue the process!

Current value: 0 0








3. Divide 16/16:

Same as before, we have two important values:


1) 0!  We take this value and add it to our running list.

2) 1!  We can now add this to our running list, as it is no longer divisible by 16!

Current value:   1 0 0 0





We just found that the hex value for 4096 in decimal to be 1000.  That means, that we have a incremental block value of 1000.  What can we do with that?  Well, if our original intention was to find the subnets available by subnetting the 2620:158::/32 into 16 subnets, we will get the following subnets:

1)    2620:158:0000::/36
2)    2620:158:1000::/36
3)    2620:158:2000::/36
4)    2620:158:3000::/36
5)    2620:158:4000::/36
6)    2620:158:5000::/36
7)    2620:158:6000::/36
8)    2620:158:7000::/36
9)    2620:158:8000::/36
10)  2620:158:9000::/36
11) 2620:158:A000::/36
12) 2620:158:B000::/36
13) 2620:158:C000::/36
14) 2620:158:D000::/36
15) 2620:158:E000::/36
16) 2620:158:F000::/36

4. How to find a particular subnet number?

In the previous example, we only had 16 subnets..so figuring out the nth subnet number may be as simple as writing it out.  But what if you have a million subnets?!  The easiest way to write it out is to use the formula: subnetID(n) = S (n-1), with S being the number of subnets.

For example, what if we wanted to find the 12th subnet ID in the previous example?

SubnetID(12) = 16 (12-1)

SubnetID(12) = 16 (11)

SubnetID(12) = 176

*Note: This is NOT correct, based off every resource I've seen...but we are simply not coming to the correct solution.  If I multiply 176 in decimal by 256..we get 45056.  THIS in hex is B000, which is the correct answer.  Why is it being multiplied by 256?  Not sure..I'll fix it once I figure out why!*

Don't forget we have to convert this back into hex!  45056 in hex is B000

Context-based access control (CBAC)

Ok...so we have a couple of spokes with context-based access control configured.  Just to make sure I can come back here and put my mind at ease when it happens to fall out of my head.

This resource proved to drive the point home..so I'm going off it!

https://www.youtube.com/watch?v=VfX0lA4BLIU

Concept:

Given this sort of setup..

We have user X on the inside attempting to get out to the internet.  While we want to allow the user to get out to whatever they wish, in doing so also means that the "bad people" on the internet will be able to get in.

What can we do to limit access from the outside world?  Well, we can drop an inbound ACL on Fa0/1 of R2 to stop certain addresses from entering the network.  Unfortunately, if we were to drop a "deny any any" on the outside interface of Fa0/1, that would block any return traffic...malicious or not.

Context-based access control is essentially like a hand-stamp.  Just like when you're leaving an event that hand-stamps your hand, CBACs essentially stamps traffic (statefully inspects) either inbound or outbound (depending on interface).  By doing so, this creates a stateful database on the configured router to remember everyone who initiated sessions from the inside going out.  If the return traffic's IP address and ports match a session in the stateful database, it gets to bypass the inbound ACL.

Implementation:

The first thing we need to do is create an ACL.

I'm going to create an ACL and drop it on the "outside" interface of R2

config t
ip access-list block
deny any any
!
interface fa0/1
ip access-group block in

By configuring an inbound ACL...this will block all traffic from the internet.  

Next, we need to configure the named inspection list.  This will be configured on the inside interface.  Remember, it could have been configured outbound on fa0/1 as well.

ip inspect name POLICE http
ip inspect name POLICE ftp
ip inspect name POLICE dns
!
interface fa0/0
ip inspect POLICE in

We have just told all traffic coming into fa0/0 that matches dns/ftp/http to get stored in the stateful database. When return traffic hits the "block" ACL...it is permitted, as the ports are stored in the stateful database.  Without the CBAC, the requests would have been otherwise denied.