EIGRP Hello and Hold Timers

The Hello and Holddown timers can be a bit tricky to understand if you mostly work with, say, OSPF for example. So let's get down to it.

Both timers are defined under an interface. In Classic Mode it is directly under the interface proces, whereas under the Named Mode it will be defined under the af-interface section of the EIGRP process.

The Hello timer defines how often the local router will send out a Hello packet. This information is not advertised to the neighbor and the Hello timer does not need to match between the neighbors for EIGRP to form adjacencies.

The Holddown timer defines how long the neighbor router will wait for a Hello packet from the local router. The way this works is that the Holddown is advertised in the Hello packet, so that the local router can instruct the neighbor how long it should wait for a Hello packet before tearing down the adjacency.

Hold Time advertised in an EIGRP Hello packet

So, because the Hello timer is locally significant only and the Holddown is the timeout for the local routers adjacency on the neighboring router, there is no need for the timers to match between EIGRP neighbors - unlike OSPF where these timers must match.

Note: I do believe the best-practice recommendation would be to have the timers match on the peering devices - but it is a technical possibility to have them configured differently between the adjacent routers.

Maximum Transmission Unit (MTU)

I was asked, this week by a colleague of mine, to explain to him some things regarding a Maximum Transmission Unit (MTU) setting at a customers site, where the customer told him, that he had to set his MTU to 1472 on an endpoint device in order to accommodate for Dot1Q VLAN tagging in his network (which I doubt he actually needed to do, but some times you need to choose your battles, when explaining network stuff to people who are not well-versed in such).

As I was explaining the meaning and workings of MTU size and when you would want to change it versus when not to, I discovered I actually didn't have all the answers he sought after - mainly because I did not have much of the specifics from this particular setup we were discussing, but also because I didn't actually remember all of the header sizes of IP and Ethernet - I knew the theory of it, but it is hard to convey that without specific numbers, which I feel like I shouldn't be struggling with as a CCIE candidate. So, I sat down and looked it all up, threw some pings and other traffic around in the lab and captured some packets - and now I am writing this down so that I may gain an even better grasp of these concepts myself - and also not have to spend time explaining it to someone, when I can just send them a link to this post.

Alright, on with it!

Maximum Transmission Unit, or MTU, defines the maximum size of an Ethernet frame transmitted on the network. In most cases, this would default to 1500 bytes. Testing the MTU is usually done using ICMP ping requests with a packet size set somewhere between 1300 and 1500 (depending on what you want to test) and the DF-bit set. The DF-bit means that the packet should not be fragmented and if it encounters a point on the path from A to B, that requires fragmentation, an ICMP packet will be returned stating that it needed fragmentation, but the DF-bit was set. This reply is generated by the device, which would otherwise have fragmented the packet - had the DF-bit not been set. When testing the MTU size, you should know how the OS handles ICMP sizes.

Let's do a sample with Windows 7 pinging its local gateway, which is set with an IP MTU of 1500 on its interface.

R1#show ip interface GigabitEthernet1
GigabitEthernet1 is up, line protocol is up
  Internet address is 172.16.0.1/24
  <output omitted>
  MTU is 1500 bytes
  <output omitted>

Let's try a ping size of 1500 with the DF-bit set and see what happens.

Win7 ping size 1500 w/ df-bit set

Okay, that didn't work - but why ?! We said 1500 in the length of the packet and that is what is allowed on the router interface. So, why are we needing to fragment the packet? Well, simply put, the packet is too large for the host to send out its interface without fragmenting it. The reason is that Windows 7 takes the -l 1500 command as meaning 1500 bytes of payload - then it adds the various headers (we'll get to the headers in a second). This makes the packet too big to be transmitted without fragmentation.

Now, lets try lowering the length of the packet to 1472 and see if we can get a packet through.

Win7 ping size 1472 w/ df-bit set

So, the packet was sent and a reply was received. Now, why can we only send with 1472, even though the client and the network is configured for 1500 bytes?

If we were to replicate this on a router, pinging another device with the size set to 1500 it would work - as seen in the output below, where router R2 pings R1 on the same layer 2 subnet (172.16.0.0/24).

R2#ping 172.16.0.1 size 1500 df-bit repeat 1
Type escape sequence to abort.
Sending 1, 1500-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with the DF bit set
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms

The simple explanation here is, that the packet length is interpreted differently between a router and a Windows 7 machine. The router takes the 1500 bytes value as meaning a 1500 byte Ethernet frame (excluding the Ethernet encapsulation itself), whereas the Windows machine means 1500 bytes of payload - then comes the layer 3 encapsulation and subsequently the layer 2 encapsulation.

Let's break down the packet that makes it through on the Windows machine.
Ping towards 172.16.0.1 with the df-bit set and a payload of 1472.

• Payload: 1472 bytes
• ICMP encapsulation: 8 bytes (1480 bytes)
• IP encapsulation: 20 bytes (1500 bytes)
• Ethernet encapsulation: 18 bytes (1518 bytes)
• Transmit on wire

So, as seen above, the packet reaches 1500 bytes after it is encapsulated at layer 3 (IP). This is where the IP source and destination addresses are added (among other things). After that it as handed off to layer 2 and encapsulated in an Ethernet frame containing the source and destination MAC addresses. What you will most likely see when capturing packets is a a frame size of 14 bytes, which is not wrong, but as you can see above I wrote 18 bytes - the 4 extra bytes are from the FCS (frame check sequence), which most network cards don't capture in Wireshark.

Below I have a few MTU size examples. First we will look at a TCP example as seen in a Wireshark capture that doesn't include the Ethernet FCS (most network cards don't include this value).

Alright, next up we have the same example as above, but this time we include the FCS and the result is actually how packets today are sent (by default) on an Ethernet network.

The layer 2 MTU size is now 1518 bytes and this is what counts as the packet sent on the wire.

Now, let's take it a little further and add 802.1Q VLAN tags into the mix. The packet, as seen above, is transmitted to a switch, that then transmits it to another switch over a trunk link - adding a VLAN tag to the 1518 byte long frame. This VLAN tag is worth 4 bytes, which now makes the frame a whopping 1522 bytes!

In 1998, the max-packet was changed, in 802.3, from 1518 to 1522 to allow for the 4 bytes VLAN tagging. So, the new standard size in Ethernet networks today is actually considered to be 1522 - sizes above that would be considered jumbo frames.

This would be standard Ethernet network allowing for 1500 byte packets. However, the tale is not done quite yet. The Ethernet frame may be 1522 (when using VLAN tagging), but the bytes transmitted on the wire for a packet includes a little more than just the frame itself - this is unrelated to the MTU, but still a nice little fun-fact to know about.

Before an Ethernet frame is sent, the sender makes sure the coast is clear by sending a preamble and the SFD (start-of-frame-delimiter). This is known as CSMA/CD (Carrier Sense Multiple Access Collision Detection), which is used in 802.3 networks. This takes up 8 bytes on the wire. And finally, at the end of a transmission there is a silence called the Interframe Gap, which adds another 12 bytes. So, a frame of 1522 bytes becomes a total of 1542 bytes transmitted on the wire. Keep in mind that the preamble, SFD and Interframe Gap does not count towards the MTU size - neither does the Ethernet frame encapsulation including the FCS and VLAN tag (if any).

EIGRP Wide Metrics

Along with the EIGRP multi-af (named) mode also came the Wide Metrics of EIGRP. Let us do a short recap of the classic metrics before tackling the wide metrics.

The classic metrics consisted of K values 1 through 5 with the default settings listed below.

K1 = bandwidth = 1
K2 = load = 0
K3 = delay = 1
K4 = reliability = 0
K5 = MTU = 0

So, the above means that any K value set to 1 i used in the metric calculation - so by default only bandwidth and delay is used. These K values are used in a formula (shown at the bottom of this post) to scale the bandidth, load, delay etc. and finally produce a number that is the actual metric for EIGRP.

In EIGRP Named Mode, the wide metrics was introduced along with a sixth K value. The delay was also changed from being measured in tens of microseconds to being measured in picoseconds. The new wide metrics, delay in picoseconds and K6 are only part of EIGRP multi-af mode - it is not available in classic mode.

The need for wide metrics, in short, is due to the classic metrics being unable to handle interfaces above 1 Gigabit properly. Due to both the bandwidth and delay values not allowing for the granularity needed. So the wide metrics introduce a 64-bit metric calculation as opposed to the classic 32-bit.

The new 64-bit calculations introduced another issue - the metric in the RIB can only accommodate 4 bytes (32 bits) of data. This is solved by scaling the metric for the RIB using the metric rib-scale <1-255> command in the routing process address-family section.

Below is an excerpt of the Cisco documentation regarding the EIGRP metrics calculation formula.

Use this command to alter the default behavior of EIGRP routing and metric computation and to allow the tuning of the EIGRP metric calculation for a particular type of service (ToS). 

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:
metric = [k1 * bandwidth + (k2 * bandwidth)/(256 – load) + k3 * delay + K6 * extended metrics] 

If k5 does not equal zero, an additional operation is performed:
metric = metric * [k5/(reliability + k4)] 

Scaled Bandwidth= 10^7/minimum interface bandwidth (in kilobits per second) * 256 

Delay is in tens of microseconds for classic mode and pico seconds for named mode. In classic mode, a delay of hexadecimal FFFFFFFF (decimal 4294967295) indicates that the network is unreachable. In named mode, a delay of hexadecimal FFFFFFFFFFFF (decimal 281474976710655) indicates that the network is unreachable.  

Reliability is given as a fraction of 255. That is, 255 is 100 percent reliability or a perfectly stable link. 

Load is given as a fraction of 255. A load of 255 indicates a completely saturated link.

A thing to remember is, that if you change the K value weighting on one router, you will have to change it on all routers in the EIGRP network. The K values must match!

Configure Replace

If you plan on loading a lot of different topologies into your lab - be it physical or logical - you may want to consider learning the configure replace command to speed things up a bit. What this command can do for you in the lab is to cut down on the time it takes to "reset to zero" by having a base configuration for your router/switch, that you can then use to overwrite any changes done when tampering with different technologies or lab assignments. What I used to do was to make sure not to write anything to the config and then when I needed to reset the lab I would reload the devices and wait the excruciatingly long time it took for them to reload (this was with my hardware lab consisting of a couple of 2600 routers). When I started building a lab setup for my CCIE I knew I had to find a way to change configs faster and I found that this command would help me do just that.

This is how I setup my lab routers  (the routers I use are CSR1000v - Ciscos virtual cloud routers).

You boot up your router and configure the things you want to be configured just about always.

enable
configure terminal
!
hostname R1
!
logging buffered 8192
!
no aaa new-model
!
no ip domain lookup
!
no ip http server
no ip http secure-server
!
line con 0
 exec-timeout 0
 logging synchronous
!
end

When you are done setting up the very basics  - save the running-config to a file on flash.

copy running-config flash:/config/base.conf

Now, whenever you have configured anything on the router - like, say, some DMVPN or EIGRP configuration - and you want to reload it to the base to start another lab, this is what you do.

From the privileged exec mode enter the following command

R1#configure replace flash:/config/base.conf force
Total number of passes: 1
Rollback Done
R1#
*Nov 12 10:30:42.186: Rollback:Acquired Configuration lock.
R1#

This makes the running-config identical that of the base.conf file saved earlier. The "Total number of passes: 1" indicates it took 1 pass of the config to make it identical. The amounts of passes it will take depends on how much the runnin-config and the base.conf file differs.

There is a bit more to the command if you want to use it outside of the lab, but this just about covers what you may want in a lab environment.

EIGRP Packets

EIGRP communicates using IP Protocol 88 and uses the following packet types:

• Hello/Ack
• Update
• Query
• Reply
• SIA-query
• SIA-reply

Hello packet
Opcode = 5
The Hello packet is used to automatically form adjacencies with neighboring routers. This is done by sending a message to the multicast address 224.0.0.10 or FF02::A. Since this packet type is unreliable the sequence number will be set to 0. The Hello packet includes the routers K values and these must match between neighbors for adjacencies to form - this ensures a consistent metric calculation throughout the network. It also includes the Holdtime, which by default is set to 15 seconds - 3 times the default Hello interval. The Hello packet is also used to send Ack messages if the acknowledge is not able to "piggyback" in another Update, Query or Reply packet.

Update packet
Opcode = 1
The Update packet is used to exchange routing information between neighbors. It is sent as unicast to new adjacencies to inform them of the full topology and afterwards as multicast to all adjacent neighbors, when a topology changes occur (such as change of metric). The first Update packet exchange between neighbors will have the Init flag set - this instructs the neighboring router to advertise all routes. The next Update packet exchange will contain the actual routes. Updates are subsequently only sent when triggered by an event and the contents of the update will be that of the changed network - not the full routing information.

Query packet
Opcode = 3
A query packet is sent in response to a route going into the active state and requests an alternate path to the affected network from the adjacent routers. This is done by sending a Query packet containing the affected network(s) with an infinite metric.
Each destination in a Query packet will be processed by DUAL on the receiving end and a reply will be sent only after the entire Query packet has been processed.

Reply packet
Opcode = 4
The Reply packet is a response to a Query packet and is acknowledged immediately, when received, and then processed by DUAL on the receiving end. If the destination network requested in a Query packet is not in the topology table, the Reply packet will state an infinite metric in its response.

SIA-Query
Opcode = 10
The SIA-query packet is sent if a Query packet has gone unanswered for 90 seconds (by default). The SIA-query requests the router to respond with whether it is still working on processing the original Query request or not. It is sent as unicast to the neighbors that have yet to reply to a Query packet. Upon receiving an SIA-query, the router must immediately send an ack, before processing the contents of the SIA-query.

SIA-reply
Opcode = 11
The SIA-reply packet is sent in response to an SIA-query, if the receiving router is still active for the destination network specified in the SIA-query. This is done by responding with the Active flag set in the response.

EIGRP Feasible Successor Routes

EIGRP uses the term successor and feasible successor to denote the best path and backup path for a particular route. The successor is the route with the Computed Distance (CD). The CD is calculated by taking the advertising routers Reported Distance (RD), which is a neighbors CD to reach the particular subnet, and then adding the cost for the local router to reach the advertising router.

There is also a term known as Feasible Distance (FD). The FD is the lowest metric observed for a given route since the last time it went from active to passive. The FD is used when converging the topology to avoid temporary routing loops by comparing the FD with the RD of a given path. If the RD is higher than the FD it means that there is a possibility that the route could point back to the local router and would therefore cause a temporary routing loop to occur if used. Note that it is only a possibility that it would be a loop and EIGRP is designed with this in mind: it will rather black-hole traffic, than cause a temporary routing loop.

So, let's look at an example. Below is a diagram of an EIGRP network with 3 routers R1 through R3.

EIGRP topology with IP address notations

And below here we have the same topology with the EIGRP metric noted for R3 to reach the network 172.16.1.0/24

EIGRP topology with metric notations

Note: the composite metric is calculated by taking the lowest bandwidth (in kilobits) on the path and the cumulative delay (in 10s of microseconds) on the path in a formula that looks like this: 256*(BW+DLY).

From the perspective of router R3, the network 172.16.1.0/24 is reachable via successor route 10.0.0.5 with Computed Distance of 3072 and through the feasible successor route 172.16.2.1 with a Computed Distance of 3328.

Below is the topology output as seen on R3.

R3#show ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(1)/ID(172.16.2.2)
<output omitted>
P 172.16.1.0/24, 1 successors, FD is 3072, serno 37
        via 10.0.0.5 (3072/2816), GigabitEthernet1.13
        via 172.16.2.1 (3328/3072), GigabitEthernet1.23

The output states "1 successors" meaning only one route has the lowest metric and will be entered into the routing table. The Computed Distance and the Reported Distance can be seen in the output in the parentheses (CD/RD).

This feasible route will be a backup route for the network 172.16.1.0/24 in case the current best route, directly through R1, should fail - effectively enabling EIGRP to failover to the backup route without having to mark the route as active and sending out queries to its adjacent neighbors.

This feature also allows EIGRP to do unequal cost load distribution. It can do this because it knows of a loop-free path to the destination with a lower cost than the best path. So, by setting the variance under the routing process, you can influence how much the cost of the best path and the lesser path may vary for them to be used in unequal load distribution. Again, I don't think unequal cost load distribution is a desired feature in most networks - otherwise it would have been a feature of some other routing protocol by now.

Forming adjacencies in EIGRP with primary addresses on different subnets

In EIGRP it is best to only use the network statement for primary addresses of an interface, if adjacencies are required to form properly on that link - the primary address, meaning the address configured on an interface without the secondary added to the end of it.

What you can do in EIGRP is, that you can enable it to run using the network command that matches a secondary address of an interface, but that will only make the process run on that interface - the process will use the primary interface to form adjacencies with any peers. Below is a the configuration of two routers, router R1 and R2. They are connected through a switch on interface GigabitEthernet1.

Router R1 configuration

R1(config)#interface GigabitEthernet1
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#ip address 172.16.0.1 255.255.255.0 secondary
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 10.0.0.1 0.0.0.0

Router R2 configuration

R2(config)#interface GigabitEthernet1
R2(config-if)#ip address 172.16.0.2 255.255.255.0
R2(config-if)#ip address 10.0.0.2 255.255.255.0 secondary
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#router eigrp 1
R2(config-router)#no auto-summary
R2(config-router)#network 10.0.0.2 0.0.0.0

The output of a show ip eigrp neighbors command will on both routers shows some confusing information.

EIGRP adjacency table on R1

EIGRP adjacency table on R2

R1 shows a neighbor of 172.16.0.2 on interface Gi1 and R2 shows a neighbor of 10.0.0.1 on interface Gi1.

The addresses that form the neighborship are the primary addresses on the interfaces, where EIGRP is enabled. On R1 the primary address is 10.0.0.1 and on R2 the primary address is 172.16.0.2. The primary address is the address that is used for EIGRP messages regardless of which secondary address is used to enable the EIGRP process on an interface.

I want to point out here, that I actually expected some error messages to pop up and adjacencies to fail between the two routers, but it appears that these routers running IOS 15.4 (they're actually CSR1000v routers) are more capable than the routers I ran this type of scenario on back when I was studying for my CCNP ROUTE exam.

Nonetheless, this type of configuration will most likely not work on routers running older versions of IOS and in the case here, where the adjacencies do form, it gives a somewhat confusing output from the show ip eigrp neighbors command and also in the next-hop addresses of the routing tables.

So, in short, be sure to use the same common subnet as primary addresses for EIGRP enabled interfaces - it may work, but at best it gives confusing output when the neighbor that forms is on a subnet that is not defined in a network command under the router process.