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.
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:
- 'router eigrp <as-num>'
- 'router eigrp' are keywords those have to be used
- 'as-num' is called the autonomous system number [people aware of BGP will be able to relate to this]
- states that EIGRP is being managed by a particular administrator
- So for two EIGRP routers to for neighbor relationship with each other, this as-num has to match
- I have used a random number '100' [one can use anything from 1 to 65535]
- 'eigrp router-id <dotted decimal>' [Optional Configuration, but useful]
- this is majorly for our reference, makes it easier for us to identify which routes have come from which router
- 'network <network number> <wildcard>'
- this is what is needed to enable EIGRP on interfaces
- the network which is matched by this statement will ensure EIGRP packets are sent / received on those interfaces
- 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:
- 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
- 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:
- 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#
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
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)#
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.
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
NOTE: all the confgurations and verifications were done using the XE-3.11 release software on ASR1K routers
No comments:
Post a Comment