VXLAN Basics

VXLAN is an acronym for Virtual eXtensiable Local Area Network. A joint venture by a few companies of which Cisco is one of them.

VXLAN is yet another overlay solution which provides a solution to facilitate sending Layer-2 traffic over a Layer-3 network.

Also, one major reason for VXLAN [as per me at least] is due to the importance virtualization and cloud computing are gaining over the recent years. To isolate huge number customers in a cloud environment becomes extremely challenging when we have just 4,096 VLANs currently available to us [of which again, some cannot be used].

Even though VLANs add a 4 byte header to a packet, they effectively use only 12 bits for VLAN tagging. VXLAN has doubled the bits it uses to 24 for tagging information, which immediately scales the value from 4,096 to 16,000,000 [16 million].

So what VXLAN essentially does is very simple, in the sense, it just encapsulates the original data into another frame [UDP frame, and Cisco uses port '8472']. Since this is an encapsulation solution, it adds an overhead of close to about 50 bytes. The first packet sent out from the router performing VXLAN encapsulation [called VTEP router] is a multicast packet. Subsequent messages would become unicast packets. Its worth mentioning here that only unknown unicasts are flooded using multicast. The MAC addresses once known are not flooded anymore.

Before we try out basic configurations related to VXLAN the below terminologies are best to keep in mind:

VTEP [Virtual Tunnel End-Point] - This in our case will the CSR1000V [Cisco's cloud services router]. This router will be used to encapsulate the Layer-2 frames at the source side and strip the encapsulation at the receiver side.

VNI [VXLAN Network Identifier] - Each of the 16 million VXLAN ID's which are available at our disposal is known as a VNI. VNI's work very similarly to our legacy VLAN's and provide isolation between the VNI traffic.

The multicast mode used is PIM-BIDIR which is a tweaking of PIM sparse-mode.

Lets now move forward and try out our very own VXLAN configuration:

With the current implementation [XE-3.11], VXLAN on Cisco [CSR1000v, to be specific] supports only multicast mode.

VXLAN - Unicast: http://stayinginit.blogspot.in/2014/10/vxlan-unicast.html

Topology:

1. We have Router1 and Router2 [both CSR1000V] and we have a core router [ASR1K]
2. It worth keeping in mind, Router1 and Router2 are virtual routers which were spawned on a UCS server [I am using ESXi 5.5]
3. The VM's are also part of the same UCS server
4. Yet another point of interest is that to configure VXLAN related commands your CSR1000V should have the premium license

Configurations:

Before we start VXLAN configuration, let us first ensure the basic routing and multicast related configurations are in place:

Router1:

ip multicast-routing distributed
router ospf 100
 router-id 1.1.1.1
interface GigabitEthernet2
 description "connected to core"
 ip address 10.1.1.1 255.255.255.0
 ip pim sparse-mode
 no shutdown
 ip ospf 100 area 100
ip pim bidir-enable
ip pim rp-address 100.100.100.100 bidir

CORE:

ip multicast-routing distributed
router ospf 100
 router-id 2.2.2.2
interface GigabitEthernet0/0/0
 description "connected to Router1"
 ip address 10.1.1.2 255.255.255.0
 ip pim sparse-mode
 no shutdown
 ip ospf 100 area 100
interface GigabitEthernet0/0/1
 description "connected to Router2"
 ip address 11.1.1.2 255.255.255.0
 ip pim sparse-mode
 no shutdown
 ip ospf 100 area 100
interface Loopback100
 ip address 100.100.100.100 255.255.255.255
 ip pim sparse-mode
 ip ospf 100 area 100
ip pim bidir-enable
ip pim rp-address 100.100.100.100 bidir

Router2:

ip multicast-routing distributed
router ospf 100
 router-id 3.3.3.3
interface GigabitEthernet2
 description "connected to core"
 ip address 11.1.1.1 255.255.255.0
 ip pim sparse-mode
 ip ospf 100 area 100
 no shutdown
ip pim bidir-enable
ip pim rp-address 100.100.100.100 bidir

With the above configurations, we should be able to reach all the routers in our topology. Now let us go onto the next phase of configuration, that is, VXLAN:

Router1:

interface Loopback100

 ip address 10.10.10.10 255.255.255.255

 ip pim sparse-mode

 ip ospf 100 area 100

interface nve1

 no shutdown

 source-interface Loopback100

interface GigabitEthernet3

 description "connected to VM1"

 no shutdown

 service instance 10 ethernet

  encapsulation dot1q 10

  rewrite ingress tag pop 1 symmetric

bridge-domain 10

 member GigabitEthernet3 service-instance 10

1. Interface NVE [network virtualization endpoint] is the one on which we configure the VNI and multicast mapping
2. We cannot assign an IP address to this interface, hence we use a Loopback interfaces as its source-interface [which once assigned immediately creates a tunnel interface, the VTEP]
3. The Loopback IP address should be reachable
4. Finally, we have ethernet virtual circuit [EVC] configuration on the GigabitEthernet3 to make that an Layer-2 interface 
1. As per the above configuration, we expect to receive a tagged traffic "VLAN 10". By using "rewrite ingress tag pop 1 symmetric" we are essentially removing the tagging related to ingress traffic and re-adding the tagging to the traffic going out from this interface

The next configuration is the binding configuration, which is shown based on what is observed on the router:

Router1(config)#interface nve 1

Router1(config-if)#member vni ?

  WORD  VNI range or instance between 4096-16777215 example: 6010-6030 or 7115

Router1(config-if)#member vni 4096 ?

  mcast-group  Configure multicast group for vni(s)

Router1(config-if)#member vni 4096 mcast-group ?

  A.B.C.D  Starting Multicast Group IPv4 Address

Router1(config-if)#member vni 4096 mcast-group 225.1.1.1

Router1(config-if)#exit

The range of VNI is from 4096 to 16777215. After the above configuration, the final configuration that needs to be done is binding this VNI to our bridge-domain:

bridge-domain 10

 member vni 4096

A very similar configuration repeats on Router2:

Router2:

interface Loopback100

 ip address 11.11.11.11 255.255.255.255

 ip pim sparse-mode

 ip ospf 100 area 100

interface nve1

 no shutdown

 source-interface Loopback100

 member vni 4096 mcast-group 225.1.1.1

interface GigabitEthernet3

 description "connected to VM1"

 no shutdown

 service instance 10 ethernet

  encapsulation dot1q 10

  rewrite ingress tag pop 1 symmetric

exit                ! in case you are pasting this configuration

exit                ! in case you are pasting this configuration

bridge-domain 10

 member vni 4096

 member GigabitEthernet3 service-instance 10

That ends our configuration. Now, let us send our most favorite ping traffic from VM1 to VM2.
But again, before we do this, let me do a quick EPC configuration to see what kind of packets we see going out of Router1.

The configuration details:

A very basic level EPC

Router1#monitor capture vxlan interface gigabitEthernet 2 both match any buffer size 200
Router1#monitor capture vxlan start

Now, ping from VM1 to VM2:

[root@localhost ~]# ping 172.16.11.111 -c 5
PING 172.16.11.111 (172.16.11.111) 56(84) bytes of data.
64 bytes from 172.16.11.111: icmp_seq=1 ttl=64 time=4.33 ms
64 bytes from 172.16.11.111: icmp_seq=2 ttl=64 time=1.52 ms
64 bytes from 172.16.11.111: icmp_seq=3 ttl=64 time=1.75 ms
64 bytes from 172.16.11.111: icmp_seq=4 ttl=64 time=2.05 ms
64 bytes from 172.16.11.111: icmp_seq=5 ttl=64 time=1.79 ms

--- 172.16.11.111 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 1.526/2.293/4.337/1.035 ms
[root@localhost ~]#

Then, stop the EPC capture:

Router1#monitor capture vxlan stop  

Check the capture contents / export them to a machine if you prefer to view via wireshark.
To export use this command:

Router1#monitor capture vxlan export tftp://<IP_address>/<location>/<file_name>.pcap

!!
Exported Successfully

Router1#

You will see the following if viewed on Router1:

Router1#show monitor capture vxlan buffer brief
 -------------------------------------------------------------
 #   size   timestamp     source           destination   protocol
 -------------------------------------------------------------
   2  110    4.497975   10.10.10.10      ->  225.1.1.1        UDP
   3  110    4.498982   11.11.11.11      ->  10.10.10.10      UDP
   4  148    4.498982   10.10.10.10      ->  11.11.11.11      UDP
   5  148    4.499974   11.11.11.11      ->  10.10.10.10      UDP
   6  148    5.496984   10.10.10.10      ->  11.11.11.11      UDP
   7  148    5.497975   11.11.11.11      ->  10.10.10.10      UDP
   8  148    6.496984   10.10.10.10      ->  11.11.11.11      UDP
   9  148    6.498982   11.11.11.11      ->  10.10.10.10      UDP
  10  148    7.497975   10.10.10.10      ->  11.11.11.11      UDP
  11  148    7.499974   11.11.11.11      ->  10.10.10.10      UDP
  13  148    8.496984   10.10.10.10      ->  11.11.11.11      UDP
  14  148    8.498982   11.11.11.11      ->  10.10.10.10      UDP
  17  110    9.498982   11.11.11.11      ->  10.10.10.10      UDP
  18  110    9.499974   10.10.10.10      ->  11.11.11.11      UDP
       
Router1#

I have removed the OSPF and PIM captures. Apart from those, the ping traffic from VM1 to VM2 triggers our first UDP packet, with source as 10.10.10.10 and destination 225.1.1.1.

As mentioned earlier, this is the first message sent out from Router1 [our VTEP]. The source and destination port of this packet is 8472 which is the default VXLAN port.

However, the subsequent UDP messages are sent out with arbitrary source ports with destination ports retained as 8472 and are unicast packets. The source and destination addresses we observe are that of our Router1's and Rotuer2's Loopback addresses.

The below command will give the number of packet's sent / received via the NVE interface:

Router1#show nve interface nve 1 detail
Interface: nve1, State: Admin Up, Oper Up Encapsulation: Vxlan
source-interface: Loopback100 (primary:10.10.10.10 vrf:0)
   Pkts In   Bytes In   Pkts Out  Bytes Out
         7        666          7        666
Router1#

From above, 5 are ping packets and the remain 2 are related to VXLAN. The same have been highlighted in the EPC capture.

Router1#show nve peers
Interface  Peer-IP          VNI        Up Time     
   nve1    11.11.11.11      4096       -        
Router1#

The above is the binding data which will give information. However, this information will expire after sometime [provided the traffic flow inactive].

Here is one small portion of VXLAN UDP tweaking which by default uses 8742, and we use the "vxlan udp port" in the global config-mode to make this change.

The usage of this is very simple, but, has to be configured on both the VTEP routers.

The port being used by VXLAN can be viewed using the show command "show platform software vxlan F0 udp-port". The same is displayed below:

Router1#show platform software vxlan F0 udp-port
VXLAN UDP Port: 8472

Router1#

Now, let's go ahead and make the port change:

Router1(config)#vxlan udp port ?
  <1024-65535>  Port number

Router1(config)#vxlan udp port 1025 ?
  <cr>

Router1(config)#

Lets see the show command to see the change in the VXLAN UDP port:

Router1#show platform software vxlan F0 udp-port
VXLAN UDP Port: 1025

Router1#

If we fail to configure Router2 with the same port, we end up seeing 'OverlayBadPkt' drops on Router2. This can be verified after sending traffic from VM1 to VM2.

So, let us configure the same port on Router2 as well:

Router2(config)#vxlan udp port 1025

Now, let me send the ping traffic again:

[root@localhost ~]# ping 172.16.11.111 -c 5
PING 172.16.11.111 (172.16.11.111) 56(84) bytes of data.
64 bytes from 172.16.11.111: icmp_seq=1 ttl=64 time=4.48 ms
64 bytes from 172.16.11.111: icmp_seq=2 ttl=64 time=1.73 ms
64 bytes from 172.16.11.111: icmp_seq=3 ttl=64 time=1.69 ms
64 bytes from 172.16.11.111: icmp_seq=4 ttl=64 time=1.81 ms
64 bytes from 172.16.11.111: icmp_seq=5 ttl=64 time=1.56 ms

--- 172.16.11.111 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 1.566/2.258/4.480/1.114 ms
[root@localhost ~]#

Details can be captured via EPC and the same viewed using wireshark.

Hope you found this post informative.

EIGRP Basics

EIGRP is a Cisco proprietary protocol. This protocol can be used instead of OSPF if you have only Cisco routers. The debate of which is better will go on, but from the point of view of configuration on Cisco routers, EIGRP is definitely a lot easier to bring up.

This is a very basic overview related to EIGRP based on what I have understood and experimented :-). 

EIGRP is an acronym for Enhanced Interior Gateway Routing Protocol. It falls in the family of Interior Gateway Protocols. EIGRP makes use of the Diffusing Update Algorithm [DUAL], which is an advanced distance vector algorithm. Also, the updates sent by EIGRP make use of Reliable Transport Protocol [RTP] to ensure the updates once received are acknowledged by the peers.

For this basic topic we would need 2 routers. As I learn more, probably I wil add more routers on this existing setup of mine.

NOTE: Some of the output's shown are in small text to fit them in a single line

Topology:

Router1 configuration:

interface TenGigabitEthernet4/0/0

 no shutdown

 ip address 10.1.1.2 255.255.255.0

router eigrp 100

 eigrp router-id 1.1.1.1

 network 10.1.1.0

Router2 configuration:

interface TenGigabitEthernet0/1/0

 no shutdown

 ip address 10.1.1.2 255.255.255.0

router eigrp 100

 eigrp router-id 2.2.2.2

 network 10.1.1.0 0.0.0.255

Brief explanation on the configuration:

Interface configurations [I have used 10.1.1.0/24 subnet; later, we will see a slight twist in configuration, since EIGRP really is not that strict on the same subnet requirement] 

Now lets look at the EIGRP configuration:

1. 'router eigrp <as-num>' 
1. 'router eigrp' are keywords those have to be used
2. 'as-num' is called the autonomous system number [people aware of BGP will be able to relate to this]
1. states that EIGRP is being managed by a particular administrator
2. So for two EIGRP routers to for neighbor relationship with each other, this as-num has to match
3. I have used a random number '100' [one can use anything from 1 to 65535]
2. 'eigrp router-id <dotted decimal>' [Optional Configuration, but useful]
1. this is majorly for our reference, makes it easier for us to identify which routes have come from which router
3. 'network <network number> <wildcard>'
1. this is what is needed to enable EIGRP on interfaces
2. the network which is matched by this statement will ensure EIGRP packets are sent / received on those interfaces
3. the usage of the wildcard is optional, however, its best to use for better clarity on what routes are actually being sent by the local router

Considering Router1 configuration:

1. As soon as we configure "network 10.1.1.0" the EIGRP process tries to locate interfaces which are in UP/UP state with IP addresses starting from 10.x.x.x network
2. Once found, EIGRP will send out hello messages on those links [since this is an 10 Gig ethernet link, it will send out the hello over a multicast group 224.0.0.10 to locate other EIGRP routers]

Considering Router2 configuration:

1. As soon as we configure "network 10.1.1.0 0.0.0.255" the process tries to locate interfaces which are in UP/UP state with IP addresses starting from 10.1.1.x network and tries to locate other EIGRP routers on the interface link once the interface is found

To know the number of interfaces identified by EIGRP, use 'show ip eigrp interfaces':

Router1#show ip eigrp interfaces 

EIGRP-IPv4 Interfaces for AS(100)

                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending

Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Te4/0/0                  1        0/0       0/0           1       0/0           50           0
Router1#

In our case, since there was only a single interface which matched the network command under the EIGRP process we will see just one interface as above.

Neighbor relationship can be verified using 'show ip eigrp neighbors':

Router1#show ip eigrp neighbors 

EIGRP-IPv4 Neighbors for AS(100)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

                                                   (sec)         (ms)       Cnt Num

0   10.1.1.2                Te4/0/0                  13 00:32:47    1   100  0  17

Router1#

Since we have configured just the connected interfaces in our network config's under EIGRP we will not observe any routes related to EIGRP on the routers. However, we can still observe the data related to this interface in the topology database as shown below:

Router1#show ip eigrp topology 

EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status 

P 10.1.1.0/24, 1 successors, FD is 512

        via Connected, TenGigabitEthernet4/0/0

Router1#

Router1#show ip eigrp topology 10.1.1.0/24

EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 10.1.1.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 512

  Descriptor Blocks:

  0.0.0.0 (TenGigabitEthernet4/0/0), from Connected, Send flag is 0x0

      Composite metric is (512/0), route is Internal

      Vector metric:

        Minimum bandwidth is 10000000 Kbit

        Total delay is 10 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 0

        Originating router is 1.1.1.1

Router1#

The above output will be re-visited again when we talk about EIGRP metrics, but for now just make a note of 'Hop count' and 'Originating router'.

Hop count of '0' means this is a connected route and we can see that the router ID of 1.1.1.1 [highlighted in yellow] is same as the Originating router value

The below output is just for confirmation that no EIGRP route is observed in the routing table 'show ip route eigrp 100':

Router1#show ip route eigrp 100

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

       a - application route

       + - replicated route, % - next hop override

Gateway of last resort is not set

Router1#

Before I conclude this small topic, I would like to discuss a few things based on what we have configured so far:

1. The difference between the usage of network <network number> and network <network number> <wildcard>

When we do a "show running-config | section router eigrp 100" on Router1, we observe the following:

Router1#show running-config | section router eigrp 100

router eigrp 100

 network 10.0.0.0

 eigrp router-id 1.1.1.1

Router1#
 

As seen on Router1, even though we configure "network 10.1.1.0", the configuration accepted without the wildcard is just the classful boundary of 10.0.0.0

Now say suppose I configure Gig0/0/0 and Gig0/0/1 of Router1 with the IP address of 10.2.1.1/24 and 10.3.1.1/24 respectively:

Router1#show ip interface brief | section 10.  

GigabitEthernet0/0/0   10.2.1.1        YES manual up                    up      

GigabitEthernet0/0/1   10.3.1.1        YES manual up                    up      

Te4/0/0                10.1.1.1        YES manual up                    up      

Router1#

Now, lets check the 'show ip eigrp interfaces' on Router1:

Router1#show ip eigrp interfaces 

EIGRP-IPv4 Interfaces for AS(100)

                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending

Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Te4/0/0                  1        0/0       0/0           1       0/0           50           0

Gi0/0/0                  0        0/0       0/0           0       0/0            0           0

Gi0/0/1                  0        0/0       0/0           0       0/0            0           0

Router1#

From the above, its very clear that with the usage of just "network 10.x.x.x" subcommand, without the wildcard, we will be matching all the IP addresses which are part of this network. So if we are planning to enable only on the Te4/0/0 and not on the other two, we need to use the wildcard. The same is shown below:

Router1(config)#router eigrp 100

Router1(config-router)#no network 10.0.0.0       

Router1(config-router)#network 10.1.1.0 0.0.0.255

Router1(config-router)#end

Router1#show ip eigrp interfaces 

EIGRP-IPv4 Interfaces for AS(100)

                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending

Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Te4/0/0                  1        0/0       0/0           1       0/0           50           0

Router1#

2. The subnet concept of EIGRP

We have used the subnet 10.1.1.0/24 on the connected interfaces of both Router1 and Router2. So now we will tweak the configuration on the Router1 interface keeping Router2 as is.

Router1 will become 10.1.1.1/30
Router2 will remain 10.1.1.2/24

Router1(config)#interface TenGigabitEthernet 4/0/0

Router1(config-if)#ip address 10.1.1.1 255.255.255.252

Router1(config-if)#

*Jan 23 09:23:45.335: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2 (TenGigabitEthernet4/0/0) is down: address changed

*Jan 23 09:23:47.109: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2 (TenGigabitEthernet4/0/0) is up: new adjacency

Router1(config-if)#

Router1#show ip eigrp neighbors 

EIGRP-IPv4 Neighbors for AS(100)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

                                                   (sec)         (ms)       Cnt Num

0   10.1.1.2                Te4/0/0                  13 00:00:39    2   100  0  22

Router1#

As seen above the neighbor relationship did go down, but got re-established again without any fuss. This is because each router looks at the IP address of the other using its own subnet for reference.

3. Hello and Hold Timers

The hello messages which EIGRP started sending immediately after we configured the network subcommand under the EIGRP process is one of the main messages which ensures the neighbor relationship between the routers remain UP. The hello messages are sent by default, every 5 seconds between the routers [this is in case of LAN, not Serial]. Also, by default, if a router fails to receive 3 successive hello messages from its peer, it would deem that peer as down and remove all the routes it learned from that peer.

These values can be viewed when we execute the 'show ip eigrp interfaces detail'

Router1#show ip eigrp interfaces detail 
EIGRP-IPv4 Interfaces for AS(100)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Te4/0/0                  1        0/0       0/0           2       0/0           50           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 15/1
  Hello's sent/expedited: 6515/6
  Un/reliable mcasts: 0/8  Un/reliable ucasts: 14/12
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 3  Out-of-sequence rcvd: 3
  Topology-ids on interface - 0 
  Authentication mode is not set
Router1#

As seen above, the hello-interval is 5 seconds. Alongside that we see the hold-time. The hold-time is 15 seconds, by default. The hold-time ticks from 15 seconds downwards till it receives its peer's hello message, upon which it gets refreshed back to 15 seconds. Ideally, the value of hold-time ticks down from 15 seconds to 10 seconds, and it goes back to 15 seconds once a hello is received from the peer.
This is the reason, when we have 3 successive hello messages missed, the hold-time becomes zero which immediately triggers the rip off the EIGRP neighbor relationship.

Both the hello and the hold-timers can be changed at the interface level. However, there is a bit of understanding needed in this as well. The configuration takes effect in the following manner:
the hello timer is for the local router and the hold-time applies for the neighboring router. Let us see this based on an the below configuration:

Router1(config)#interface TenGigabitEthernet 4/0/0
Router1(config-if)#ip hello-interval eigrp ?
  <1-65535>  AS number
Router1(config-if)#ip hello-interval eigrp 100 ?
  <1-65535>  Seconds between hello transmissions
Router1(config-if)#ip hello-interval eigrp 100 2
Router1(config-if)#

Once configured, the same is reflected immediately when we check the 'show ip eigrp interfaces detail'

Router1#show ip eigrp interfaces detail 
EIGRP-IPv4 Interfaces for AS(100)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Te4/0/0                  1        0/0       0/0           2       0/0           50           0
  Hello-interval is 2, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 15/1
  Hello's sent/expedited: 8042/6
  Un/reliable mcasts: 0/8  Un/reliable ucasts: 14/12
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 3  Out-of-sequence rcvd: 3
  Topology-ids on interface - 0 
  Authentication mode is not set

Router1#

Now, lets configure the hold-time:

Router1(config)#interface TenGigabitEthernet 4/0/0
Router1(config-if)#ip hold-time eigrp ?
  <1-65535>  AS number
Router1(config-if)#ip hold-time eigrp 100 ?
  <1-65535>  Seconds before neighbor is considered down
Router1(config-if)#ip hold-time eigrp 100 6 
Router1(config-if)#

Router1#show ip eigrp interfaces detail 

EIGRP-IPv4 Interfaces for AS(100)

                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending

Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Te4/0/0                  1        0/0       0/0           2       0/0           50           0

  Hello-interval is 2, Hold-time is 6

  Split-horizon is enabled

  Next xmit serial <none>

  Packetized sent/expedited: 15/1

  Hello's sent/expedited: 8729/6

  Un/reliable mcasts: 0/8  Un/reliable ucasts: 14/12

  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0

  Retransmissions sent: 3  Out-of-sequence rcvd: 3

  Topology-ids on interface - 0 

  Authentication mode is not set

Router1#

Even though the configuration is reflected above, its more importantly reflected on the peer as seen below on Router2:

Router2#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.1.1.1                Te0/1/0                   5 07:47:26    2   100  0  22
Router2# 

So, what all this means is, when we configure Router1 with a hello-interval of 2 seconds and then configure its hold-time to 6 seconds, its peer 'Router2' will wait for 6 seconds [Router1's hold-time] before it brings down the neighbor relationship with this router 'Router1' if it does not receive any hello messages from Router1. Router1 on the other hand sends hello messages every 2 seconds to Router2.

One should remember that the hold-time should be greater than the hello-interval. This check is not done by EIGRP process, hence, if we end up configuring the hold-time lesser than the hello-interval, it will result in continuous neighbor relationship flaps between the EIGRP routers.
The recommendation is to have the hold-time at least 3 times the hello-interval.

4. Metrics

For better understanding of the metrics let us first add another network command on Router1 to ensure Gig0/0/0 network gets advertised to Router2.

Router1(config)#router eigrp 100
Router1(config-router)#network 10.2.1.0 0.0.0.255
Router1(config-router)#

On Router2 we see the following

Router2#show ip eigrp topology 
EIGRP-IPv4 Topology Table for AS(100)/ID(2.2.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 10.2.1.0/24, 1 successors, FD is 3072
        via 10.1.1.1 (3072/2816), TenGigabitEthernet0/1/0
P 10.1.1.0/24, 1 successors, FD is 512
        via Connected, TenGigabitEthernet0/1/0
Router2#

As we observe the route has appeared in the topology database of Router2. However, we have two values of interest [bold]. The value 3072 is called the Feasible Distance [denoted as FD, again seen in the database, in yellow]
The value 2816 is called Reported Distance [RD]. This value is from the point of view of the router from which it received this route. What this means is, the RD observed on Router2 for 10.2.1.0/24 is actually the FD value for the same route on Router1. The same is displayed below:

Router1#show ip eigrp topology 
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 10.2.1.0/24, 1 successors, FD is 2816
        via Connected, GigabitEthernet0/0/0
P 10.1.1.0/30, 1 successors, FD is 512
        via Connected, TenGigabitEthernet4/0/0
Router1#

Now, lets look at how the FD calculation takes place. The equation that is used for the calculation is as shown below: 

FD = 256*Cumulative-Delay + 256*[10^7/minimum bandwidth]

Here, we are considering only the bandwidth and delay based on Cisco's recommendation against the usage of the other two components, viz, load and reliability. The usage of these are said to introduce route flaps.

So for our discussion we will just look at delay and link bandwidth.

Before we go more further with this discussion its best to note the units of measurement of these two components:

Delay is measured in 'tens of microsecond'
Bandwidth is measured in 'kilo bits per second [Kbps]'

Now, lets go back to the topology database on Router2 and expand the '10.2.1.0/24' route

Router2#show ip eigrp topology 10.2.1.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(2.2.2.2) for 10.2.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
  Descriptor Blocks:
  10.1.1.1 (TenGigabitEthernet0/1/0), from 10.1.1.1, Send flag is 0x0
      Composite metric is (3072/2816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 1.1.1.1

Router2#

Seen above is a wealth of metric information, but, we will choose only the ones in bold

Total delay is nothing but cumulative delay and its displayed in 'microseconds'. This in 'tens of micorseconds' would be just 2.

So lets apply the values to the above formula to see what number we will obtain:

FD => 256*2 + 256*[10^7 / 10^6] => 512 + 2560 => 3072

Its worth noting here that MTU and Hop count are not part of the metrics matrix of EIGRP.

As before, we can definitely modify these two parameters as well under the interface.

Changing Delay:

Router1(config)#interface GigabitEthernet 0/0/0
Router1(config-if)#delay 4 
Router1(config-if)#end

Router1#show ip eigrp topology                            
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 10.2.1.0/24, 1 successors, FD is 3584
        via Connected, GigabitEthernet0/0/0
P 10.1.1.0/30, 1 successors, FD is 512
        via Connected, TenGigabitEthernet4/0/0

Router1#

As observed, the FD value has immediately reflected this change in delay. From its previous value of 2816, it has jumped to 3548.

Changing Bandwidth:

In the real world, changes in bandwidth values have to do something with SLA's / QoS etc., rarely it involves EIGRP, but for our understanding that this can be done its displayed below:

Router1(config)#interface GigabitEthernet 0/0/0
Router1(config-if)#bandwidth 100
Router1(config-if)#end

Router1#show ip eigrp topology            
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 10.2.1.0/24, 1 successors, FD is 25601024
        via Connected, GigabitEthernet0/0/0
P 10.1.1.0/30, 1 successors, FD is 512
        via Connected, TenGigabitEthernet4/0/0

Router1#

As observed, the FD exponentially grew to a value of 25601024 due to the bandwidth value of 100 Kbps.

The same is elaborated below:

Router1#show ip eigrp topology 10.2.1.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 10.2.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 25601024
  Descriptor Blocks:
  0.0.0.0 (GigabitEthernet0/0/0), from Connected, Send flag is 0x0
      Composite metric is (25601024/0), route is Internal
      Vector metric:
        Minimum bandwidth is 100 Kbit
        Total delay is 40 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 1.1.1.1

Router1#

We have discussed about both metric affecting parameters: delay and bandwidth which were enabled by default for our metric calculation. However, the reason for these to be considered in our calculation in the first place is due to the EIGRP's K-values. These values can be observed when we execute 'show running-config all | section router eigrp 100'

Router1#show running-config all | section router eigrp 100
router eigrp 100
 timers active-time 3
 timers graceful-restart purge-time 240
 timers nsf signal 20
 timers nsf converge 120
 metric maximum-hops 100
 metric weights 0 1 0 1 0 0
 traffic-share balanced
 variance 1
 network 10.1.1.0 0.0.0.255
 network 10.2.1.0 0.0.0.255
 distance eigrp 90 170
 no auto-summary
 no passive-interface default
 no passive-interface TenGigabitEthernet4/0/0
 eigrp router-id 1.1.1.1
 eigrp log-neighbor-changes
 eigrp log-neighbor-warnings 10
 eigrp event-log-size 500
 no shutdown
 no nsf
Router1#

The one highlighted in the above output is what are known as K-values. Lets look at them in slight detail:

metric weights 0 1 0 1 0 0

'metric weights' are keywords
the first '0' is called TOS: However, the only valid option here is '0'
What follow are called K values: K1, K2, K3, K4 and K5
K1: for enabling bandwidth
K3: for enabling delay
The other values: K2, K4 and K5 are made zero to ensure they won't be part of the metric calculation [Cisco recommended, hence, we will ignore enabling them as they are never used in any scenario]

However, there is one important point about K-values, that is, the K-values have to match between the EIGRP routers which are trying to form neighbor relationship with one another. If the K-values do not match, the routers cannot become peers.

More updates on EIGRP shortly...

NOTE: all the confgurations and verifications were done using the XE-3.11 release software on ASR1K routers