3-R&S/Enhanced Interior Gateway Routing Protocol (EIGRP) Part 3 (Configuration).

In this post i will talk about how can we configure simple and advanced EIGRP and how we verify the EIGRP operation and configuration, so i will talk about EIGRP configuration and verification commands from CLI point of view.

Basic EIGRP Configuration:

Before we discuss the simple EIGRP configuration, let’ see the simple topology that we will use to explain the configuration topic:

eigrp-config

As mentioned in the previous two posts for explaining the EIGRP operation 1-R&S/Enhanced Interior Gateway Routing Protocol (EIGRP) Part 1 and 2-R&S/Enhanced Interior Gateway Routing Protocol (EIGRP) Part 2 , what is the meaning of “EIGRP-speaking router” ?, simply it means that the router should enable the EIGRP process globally, and become part of certain EIGRP domain, so this means that the first step for the router to become “EIGRP-speaking router” to run the EIGRP process and define certain EIGRP Autonomous system number, and as mentioned before in the previous post  1-R&S/Enhanced Interior Gateway Routing Protocol (EIGRP) Part 1 that the AS number at the EIGRP is just a number representing a process domain, which represent the number of that EIGRP process, so for the EIGRP-speaking routers to establish an adjacency with each other, they have to configure the same AS number, as this means that they are wiling to participate on the same process domain, so EIGRP process can be enabled on the router using the following command:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router eigrp 100

Here we enabled the EIGRP process with AS number 100 on R1, so as well we need to enable the EIGRP process at both R2 and R3 using the same commands:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router eigrp 100
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router eigrp 100

Once we enabled the EIGRP process on the router, next step is to enable the EIGRP on the required interfaces, and the interface is either connected to another EIGRP-speaking router(s) (to form an EIGRP adjacency with this/those router(s) ) or is a stub interface (no EIGRP adjacency will be formed on this interface) which means that the router need to advertise the subnet/network of this stub interface in the EIGRP domain. We can enable the EIGRP on the interface using the following commands:

R1(config)#router eigrp 100
R1(config-router)#network 192.168.12.0 0.0.0.255
R1(config-router)#network 1.1.1.1 0.0.0.0
R2(config)#router eigrp 100
R2(config-router)#network 192.168.12.0 0.0.0.255
R2(config-router)#network 192.168.23.0 0.0.0.255
R2(config-router)#network 2.2.2.2 0.0.0.0
R3(config)#router eigrp 100
R3(config-router)#network 192.168.23.0 0.0.0.255
R3(config-router)#network 3.3.3.3 0.0.0.0

From the previous configuration commands, we can deduce the following points:

1-The command “network 192.168.12.0 0.0.0.255” on R1 means that we need to enable the EIGRP on the interface(s) that has/have an IP address fall in the range (192.168.12.0 – 192.168.12.255), but how we know this ? The value “0.0.0.255” represents the wild card mask of  “192.168.12.0” that is the inverse of the subnet mask, at which if we need to know the subnet mask, simply we can subtract the wild card mask from “255.255.255.255”, this means that the subnet mask = 255.255.255.255 – 0.0.0.255 = 255.255.255.0 (/24), but in reality the wild card mask is used to indicate what is the exact IP addresses we need to match, at which the value “0” in the wild card mask means “match this specific bit”, while the value “1” means “don’t care”. Here R1 has an IP address “192.168.12.1”, so when we issued the command “network 192.168.12.0 0.0.0.255” on R1, it will search for any interface that has an IP address within the range (192.168.12.0 – 192.168.12.255), here we can see that the first three octets of this IP addresses range are the same (192.168.12) why ?? as the first three octets of the wild card mask are “0” in decimal or “00000000” in binary, this means that the first three octets of the IP address that we need to check should match the first three octets of “192.168.12.0” that we mentioned in the “network” command, this means that the first three octets of the IP address that we need to check should be  “192.168.0”, while the fourth (last) octet in this IP address can be any value from 0 to 255 (i.e 0, 1, 2, 3, …. , 253, 254 or 255) why ?? as the fourth (last) octet in the wild card mask is “255” in decimal or “11111111” in binary, which means that the fourth (last) octet in the IP address that we need to check can be any value as the corresponding bits of this last octet in the wild card mask are “1s” which means “don’t care”, so the IP address “192.168.12.1” of the interface “Eth0/0” match, hence R1 will enable the EIGRP on the interface “Eth0/1” as the IP address “192.168.12.1” match the network command “192.168.12.0 0.0.0.255”.
2-The command “network 1.1.1.1 0.0.0.0” on R1 means that we need to enable the EIGRP on the interface(s) that has/have an IP address fall in the range (1.1.1.1 – 1.1.1.1), this means that it will search for an interface that has an exact IP address of “1.1.1.1”, so R1 will enable the EIGRP on the interface “Loopback0” as the IP address “1.1.1.1” match the network command “network 1.1.1.1 0.0.0.0”.
3-The same concept is applicable for both R2 and R3, at which R2 will enable the EIGRP on the interfaces “Eth0/0”, “Eth0/1” and “Loopback0”, and R3 will enable the EIGRP on the interfaces “Eth0/1” and “Loopback0”.

4-Once the EIGRP is enabled on the proper interface(s), the router will start the EIGRP operation on those interfaces and send the EIGRP hello message out those interfaces to form an EIGRP adjacency with any connected EIGRP-speaking routers, this means that R1 will send EIGRP hello message out Eth0/0 and Loopback0, R2 will send EIGRP hello message out Eth0/0, Eth0/1 and Loopback0 and R3 will send EIGRP hello message out Eth0/1 and Loopback0.

As mentioned before, R1 and R2 will form an EIGRP adjacency on Eth0/0,  R2 and R3 will form an EIGRP adjacency on Eth0/1.

Basic EIGRP adjacency verification:

Once the EIGRP adjacency is formed between the routers, the router will generate log message that indicate that the EIGRP is successfully formed as the following:

At R1:

*Jan 21 16:12:28.121: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.2 (Ethernet0/0) is up: new adjacency

At R2:

*Jan 21 16:12:28.111: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.1 (Ethernet0/0) is up: new adjacency
*Jan 21 16:12:30.446: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.23.3 (Ethernet0/1) is up: new adjacency

At R3:

*Jan 21 16:12:30.440: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.23.2 (Ethernet0/1) is up: new adjacency

To verify that the EIGRP adjacency is formed on the EIGRP-speaking router, we can use the following command:

R1#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 192.168.12.2 Et0/0 13 00:00:03 13 100 0 5

From the previous O/P we can deduce the following points:

1-“EIGRP-IPv4 Neighbors for AS(100)” indicate that R1 is running an EIGRP process with AS value = 100.
2-The “H” value is used to indicate the order in which the EIGRP adjacency is formed, this means that if this local EIGRP-speaking router form 3 EIGRP adjacencies, the “H” value is used to tell which EIGRP adjacency is formed first, which one is formed second and which one is formed third, the EIGRP adjacency formed first has “H” value of 0, the EIGRP adjacency formed second has “H” value of 1 and the EIGRP adjacency formed third has “H” value of 2. So at the case of R1 there is only one “H” value as there is only one EIGRP adjacency is formed with R2, so its value is 0 as this is the first and only EIGRP adjacency.
3-The “Address” value is used to indicate the IP address of the EIGRP neighbor that form an EIGRP adjacency with R1. So at the case of R1 there is only one EIGRP adjacency formed with the EIGRP-speaking router R2 with an IP address “192.168.12.2”.
4-The “interface” value is used to indicate on which interface the EIGRP adjacency is formed, so at the case of R1, there is only one EIGRP adjacency is formed with R2 on interface “Eth0/0”.
5-The “Hold” value is used to indicate the remaining hole timer for the EIGRP adjacency, which indicate the number of seconds after which the router will consider the EIGRP neighbor to be down if no EIGRP hello message is receved, so at the case of R1, there is only one EIGRP adjacency is formed with R2 and the reaming hold timer is 13 seconds, this means that if R1 didn’t receive EIGP hello message from R2 after 13 seconds, it will consider R2 to be dead and will tear down the EIGRP adjacency with R2.
6-The “Uptime” value is used to indicate the uptime of the EIGRP adjacency, so at the case of R1, there is only one EIGRP adjacency is formed with R2 and it is formed 3 seconds ago.
7-The “SRTT” value is used to indicate the average round trip time between the router transmit an EIGRP message (that is needed to be reliably delivered) and receive the Ack message from the neighbor, so at the case of R1, there is only one EIGRP adjacency is formed with R2, so assume that R1 send 3 reliable messages, at which the RTT of the first message is 15 msec, the RTT of the second message is 13msec and the RTT of the third message is 11msec, so from these three values we can deduce that the SRTT is the average of 15, 13 and 11 msecs, so SRTT = 13msec.
8-The “RTO” value is used to indicate the time to wait for the EIGRP Ack message before retransmitting the unicast EIGRP message again, so at the case of R1, there is only one EIGRP adjacency is formed with R2, and the RTO value is 100 msec.
9-The “Seq” value is used to indicate the sequence number of the last EIGRP message reliably received from the neighbor, and as mentioned before, reliably delivered means that the EIGRP message depend on the RTP for reliably delivering, and the messages that needs to be reliably delivered are Update, Query, reply, SIAQuery and SIAReply, so at the case of R1, there is only one EIGRP adjacency is formed with R2, and this means that the Seq value = 5, which indicates that the last EIGRP message reliably delivered from R2 has sequence number of 5.

The same concept is applicable for both R2 and R3:

R2#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
1 192.168.12.1 Et0/0 13 00:00:22 1600 5000 0 4
0 192.168.23.3 Et0/1 11 00:00:22 12 100 0 9
R3#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 192.168.23.2 Et0/1 14 00:00:20 588 3528 0 5

Now we need to check the IP routing table on the three routers R1, R2 and R3 as the following:

R1#show ip route eigrp | begin Gateway
Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/409600] via 192.168.12.2, 00:00:03, Ethernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/435200] via 192.168.12.2, 00:00:03, Ethernet0/0
D 192.168.23.0/24 [90/307200] via 192.168.12.2, 00:00:03, Ethernet0/0
R2#show ip route eigrp | begin Gateway
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/409600] via 192.168.12.1, 00:00:02, Ethernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/409600] via 192.168.23.3, 00:00:03, Ethernet0/1
R3#show ip route eigrp | begin Gateway
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/435200] via 192.168.23.2, 00:00:03, Ethernet0/1
 2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/409600] via 192.168.23.2, 00:00:04, Ethernet0/1
D 192.168.12.0/24 [90/307200] via 192.168.23.2, 00:00:04, Ethernet0/1

From the previous O/P we can deduce that R1 has routes in its IP routing table for three subnets 2.2.2.2/32, 3.3.3.3/32 and 192.168.23.0/24, and R2 has routes in its IP routing table for two subnets 1.1.1.1/32 and 3.3.3.3/32 and R3 has routes in its IP routing table for three subnets 1.1.1.1/32, 2.2.2.2/32 and 192.168.12.0/24.

Hello and Hold time:

As mentioned before in the first post that the EIGRP hello message is used by the EIGRP-speaking router to discover its neighbors, form an adjacency and maintain the formed EIGRP adjacency, at which the EIGRP-speaking router send the EIGRP hello message at periodic interval, the default hello timer is 5 seconds and the default hold timer is 15 seconds. We can change the hello and hold timer in a per-interface basis using the following commands:

R1(config)#interface Ethernet0/0
R1(config-if)#ip hello-interval eigrp 100 4
R1(config)#interface Ethernet0/0
R1(config-if)#ip hold-time eigrp 100 12

We can check the EIGRP hello and hold timer configured on the interface using the following command:

R1#show ip eigrp interfaces detail Ethernet0/0
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
Et0/0 1 0/0 0/0 10 0/2 50 0
 Hello-interval is 4, Hold-time is 12    <==== (Hello Timer = 4 seconds, Hold Time = 12 seconds)
 Split-horizon is enabled
 Next xmit serial <none>
 Packetized sent/expedited: 13/0
 Hello's sent/expedited: 2248/4
 Un/reliable mcasts: 0/13 Un/reliable ucasts: 30/4
 Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
 Retransmissions sent: 1 Out-of-sequence rcvd: 2
 Topology-ids on interface - 0 
 Authentication mode is not set

As mentioned before in the first post that the default “K” values are as the following:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
K6 = 0
We can check the “K” values using the following command:

R1#show ip protocols | begin eigrp
Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks accepted from incoming updates
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0   <==== (K1 = 1, K2 = 0, K3 = 1, K4 = 0 and K5 = 0)
 --More--

We can change the “K” values using the following command:

R1(config)#router eigrp 100
R1(config-router)#metric weights 0 1 1 1 0 0

The first value in the command is the Type Of Service (TOS) routing supported by the EIGRP, and Cisco support only TOS 0.
The remaining values represent the “K” values, K1 = 1, K2 = 1, K3 = 1, K4 = 0 and K5 = 0.

Note: As mentioned before that the “K” values should match between the routers to be able to form an EIGRP adjacency with each other, so make sure that when you configure the “K” values to be the same on all the EIGRP-speaking routers that should form an EIGRP adjacency with each other.


Static EIGRP neighborship:

The router can form static EIGRP adjacency with certain neighbor, assume that there are three routers in the subnet and are running EIGRP process with same parameters and same AS number, and we need only two of them to form the EIGRP adjacency with each other, simply we can define static neighborship on the two routers that need to form the EIGRP adjacency with each other using the following command:

R1(config)#router eigrp 100
R1(config-router)#neighbor 192.168.12.2 Ethernet0/0
R2(config)#router eigrp 100
R2(config-router)#neighbor 192.168.12.1 Ethernet0/0

Commonly the static EIGRP neighborship is used with the NBMA network, as this network doesn’t support the forwarding of the multicast frames, and as you know the EIGRP hello message and other messages are multicast messages, so for this reason the EIGRP adjacency will never be formed over this NBAM network, hence we should use static EIGRP neighborship for such situation to overcome the multicast forwarding limitation.

Static EIGRP neighborship verification:

R1#show ip eigrp neighbors detail Ethernet0/0
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 192.168.12.2 Et0/0 12 00:24:01 13 100 0 29
 Static neighbor     <==== (Static neighbor)
 Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 3
 Topology-ids from peer - 0 
Max Nbrs: 0, Current Nbrs: 0

We can deduce from the previous O/P that R1 form static EIGRP adjacency with the IP address (192.168.12.2) which is R2.

Auto Summarization:

All the distance vector routing protocol support the concept of auto summarization, at which is used to summarize the subnets to their major network or classful network and this happened at the network boundary, this means that the Auto summary concept is used to suppress the advertisement of the subnets and advertise the major or classful network instead and this happened at the boundary of this major or classful network. By default the Auto summary feature is disabled on EIGRP, so that by default the EIGRP-speaking router advertise the subnet with its actual subnet mask and not to suppress it, and we can verify that the Auto summary feature is disabled using the following command:

R1#show ip protocols | begin eigrp
Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks accepted from incoming updates
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 NSF-aware route hold timer is 240
 Router-ID: 1.1.1.1
 Topology : 0 (base) 
 Active Timer: 3 min
 Distance: internal 90 external 170
 Maximum path: 4
 Maximum hopcount 100
 Maximum metric variance 1

Automatic Summarization: disabled     <==== (Auto Summary is disabled)
 --More--

To enabled the Auto summary feature, we can use the following command:

R1(config)#router eigrp 100
R1(config-router)#auto-summary

 

R1#show ip protocols | begin eigrp
Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks accepted from incoming updates
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 NSF-aware route hold timer is 240
 Router-ID: 1.1.1.1
 Topology : 0 (base) 
 Active Timer: 3 min
 Distance: internal 90 external 170
 Maximum path: 4
 Maximum hopcount 100
 Maximum metric variance 1

Automatic Summarization: enabled    <==== (Auto Summary is enabled)
 --More--

We can check the IP routing table on R2 to see the entry that match the IP address 1.1.1.1/32:

R2#show ip route 1.1.1.1
Routing entry for 1.0.0.0/8   <==== (1.0.0.0/8)
 Known via "eigrp 100", distance 90, metric 409600, type internal
 Redistributing via eigrp 100
 Last update from 192.168.12.1 on Ethernet0/0, 00:00:03 ago
 Routing Descriptor Blocks:
 * 192.168.12.1, from 192.168.12.1, 00:00:03 ago, via Ethernet0/0
 Route metric is 409600, traffic share count is 1
 Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

From the previous O/P we can deduce that R2 has an entry for (1.0.0.0/8) that match the IP address 1.1.1.1, which means that R2 received this summary network from R1 after we enabled Auto summary feature on R1, at which R1 advertise the major or classful network of the subnet (1.1.1.1/32) which is (1.0.0.0/8) and suppress the advertisement of this subnet (1.1.1.1/32)

Auto summary can be disabled using the following command:

R1(config)#router eigrp 100
R1(config-router)#no auto-summary 

 

Administrative Distance:

As you know that there are two types of EIGRP routes, Internal and External EIGRP routes, for this reason there are two values for the ُُEIGRP administrative distance, one for the Internal which is 90 and the other for External EIGRP routes which is 170. We can change the Administrative distance value for both internal and external EIGRP routes using the following command:

R1(config)#router eigrp 100
R1(config-router)#distance eigrp 91 171

Once we changed the Administrative distance, we will find that the router will generate an EIGRP peer termination message as the following:

eigrp-pak18

We found that the EIGRP peer termination message is represented by all K values have value of 255, which indicates that R1 need to terminate the EIGRP adjacency with the EIGRP neighbors on the interface Eth0/0

As well R1 will generate the following log message indicating that there is a change happened regarding the routes (as the Administrative distance is changed):

At R1:

*Feb 3 14:52:01.912: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.2 (Ethernet0/0) is down: route configuration changed

Then the EIGRP adjacency is formed again with R2:

*Feb 3 14:52:06.453: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.2 (Ethernet0/0) is up: new adjacency

Once R2 received the EIGRP peer termination message, it will generate the following log message:

At R2:

*Feb 3 14:52:01.902: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.1 (Ethernet0/0) is down: Interface PEER-TERMINATION received

Then the EIGRP adjacency is formed again with R1:

*Feb 3 14:52:06.453: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.1 (Ethernet0/0) is up: new adjacency

We can check the Administrative Distance value configured on R1 using the following command:

R1#show ip protocols | begin eigrp
Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks accepted from incoming updates
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 NSF-aware route hold timer is 240
 Router-ID: 1.1.1.1
 Topology : 0 (base) 
 Active Timer: 3 min
 Distance: internal 91 external 171    <==== (Internal AD = 91, External AD = 171)
 --More--

We can change the Administrative distance value for all the routes received from certain neighbor using the following command:

R2(config)#router eigrp 100 
R2(config-router)# distance 89 192.168.25.5 0.0.0.0

We configured the administrative distance to be 89 for all the EIGRP routes received from the neighbor with the IP address (192.168.25.5)

We can verify that all the EIGRP routes received from the neighbor with the IP address (192.168.25.5) has administrative distance of 89 as the following:

R2#show ip route eigrp | include 192.168.25.5
D 3.3.3.3 [89/435200] via 192.168.25.5, 00:05:31, Ethernet0/3
D 4.4.4.4 [89/460800] via 192.168.25.5, 00:05:31, Ethernet0/3
D 6.6.6.6 [89/435200] via 192.168.25.5, 00:05:31, Ethernet0/3
D 192.168.34.0/24 [89/332800] via 192.168.25.5, 00:05:31, Ethernet0/3
D 192.168.35.0/24 [89/307200] via 192.168.25.5, 00:05:31, Ethernet0/3
D 192.168.36.0/24 [89/332800] via 192.168.25.5, 00:05:31, Ethernet0/3
D 192.168.46.0/24 [89/332800] via 192.168.25.5, 00:05:31, Ethernet0/3
D 192.168.56.0/24 [89/307200] via 192.168.25.5, 00:05:31, Ethernet0/3

We can change the Administrative distance value for specific routes received from certain neighbor using the following command:

R2(config)#ip access-list standard 1 
R2(config-std-nacl)#permit 192.168.36.0 0.0.0.255 
R2(config-std-nacl)#exit
R2(config)#router eigrp 100
R2(config-router)#distance 89 192.168.25.5 0.0.0.0 1

We configured the administrative distance to be 89 for specific EIGRP route received from the neighbor with the IP address (192.168.25.5), this specific EIGRP route (192.168.36.0/24) is defined by the standard ACL 1

We can verify that the EIGRP route for the subnet/network 192.168.36.0/24 received from the neighbor with the IP address (192.168.25.5) has administrative distance of 89 as the following:

R2#show ip route | include 192.168.25.5
D 6.6.6.6 [90/435200] via 192.168.25.5, 00:04:57, Ethernet0/3
D 192.168.35.0/24 [90/307200] via 192.168.25.5, 00:04:57, Ethernet0/3
D 192.168.36.0/24 [89/332800] via 192.168.25.5, 00:04:57, Ethernet0/3    <==== (Only the EIGRP route for 192.168.36.0/24 had AD = 89)
D 192.168.46.0/24 [90/332800] via 192.168.25.5, 00:04:57, Ethernet0/3
D 192.168.56.0/24 [90/307200] via 192.168.25.5, 00:04:57, Ethernet0/3


Load Balancing:

We already know what is the meaning of load balancing, simply load balancing means that the traffic destined to certain IP address will be forwarded out two or more paths, which means that the traffic will be balanced over two or more paths and this is based on the design. Let’s check the following topology that we will use to explain the load balancing concept:

eigrp-config1

There are two types of load balancing supported by EIGRP:

1-Equal cost load balancing: Equal cost means that two or more paths used to balance the traffic destined to certain IP addresses and those routes have the same metric, which means that the traffic destined to this IP address is equally balanced over those two or more paths. Assume that R2 has three routes for the subnet/network (6.6.6.6/32) with the same metric, this means that R2 will install those three routes in the IP routing table for the subnet/network (6.6.6.6/32), hence it will perform equal load balancing for the subnet/network 6.6.6.6/32,  simply if there are 6 packets needed to be sent to the IP address 6.6.6.6 and R2 has three routes in its IP routing table for this IP address and those three routes have the same metric, hence R2 will perform “Equal load balancing”, and assume that R2 is implementing “per-packet load balancing”, this means that R2 will forward the first packet over the first path (out Eth0/3), then the second packet over the second path (out Eth0/1), then the third packet over the third path (out Eth0/2), then the fourth packet over the first path (out Eth0/3),  then the fifth packet over the second path (out Eth0/1), then the sixth packet over the first path (out Eth0/2) as the following:

eigrp-config2

EIGRP support equal cost load balancing, and by default it is configured to support only up to 4 paths to be used for load balancing, but it can be configurable to support up to 32 paths to be used for load balancing, and we can configure this maximum paths value using the following command:

R1(config)#router eigrp 100
R1(config-router)#maximum-paths 6

We can check the maximum-paths value configured on R1 using the following command:

R1#show ip protocols | begin eigrp
Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks accepted from incoming updates
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 NSF-aware route hold timer is 240
 Router-ID: 1.1.1.1
 Topology : 0 (base) 
 Active Timer: 3 min
 Distance: internal 90 external 170
 Maximum path: 6    <==== (Maximum Path value = 6)
 --More--

We can check that the three routes are installed in the IP routing table of R2 based on the following:

R2#show ip route 6.6.6.6
Routing entry for 6.6.6.6/32
 Known via "eigrp 100", distance 90, metric 435200, type internal
 Redistributing via eigrp 100
 Last update from 192.168.23.3 on Ethernet0/1, 01:42:46 ago
 Routing Descriptor Blocks:
 * 192.168.25.5, from 192.168.25.5, 01:42:46 ago, via Ethernet0/3    <==== (Route via R5)
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2
 192.168.24.4, from 192.168.24.4, 01:42:46 ago, via Ethernet0/2      <==== (Route via R4)
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2
 192.168.23.3, from 192.168.23.3, 01:42:46 ago, via Ethernet0/1      <==== (Route via R3)
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

 

2-Unequal cost load balancing: Unequal cost means that two or more paths used to balance the traffic destined to certain IP addresses and those routes have different metric, which means that the traffic destined to this IP address is unequally balanced over those two or more paths. Assume that R2 has three routes for the subnet/network (6.6.6.6/32) with different  metrics, this means that R2 will not install those three routes in the IP routing table for the subnet/network (6.6.6.6/32), it will check first which route(s) has/have the lowest/best metric to install it in the IP routing table, so assume the following AD and FD values for the three routes:

1-The AD value for the route received from R5 = 409600, and the FD = 435200.
2-The AD value for the route received from R3 = 409600, and the FD = 435200.
3-The AD value for the route received from R4 = 409600, and the FD = 857600.

This means that R2 has two successor routes, the routes received from R5 and R3, this means that R2 will install only those routes in its IP routing table, but the scenario here we need to install the three routes in the IP routing table for the subnet/network 6.6.6.6/32, for this reason we need to enable the unequal cost load balancing on R2 to be able to install the route received from R4 in its IP routing table. To enable unequal cost load balancing we need to define certain value called by “Variance”, at which this value is used to tell the router the range of metric that the router will use their routes to be installed in the IP routing table, so let’s explain these words in our topology, here we need to calculate the “Variance” value, so to calculate the Variance value we need to know two other values, the lowest metric and highest metric, so in this example the lowest metric is 435200 (for the routes received from R5 and R3) and the highest metric is 857600 (for the route received from R4), then we can calculate the variance value using the following:

Variance value = (Highest metric / Lowest metric)

Variance = (857600 / 435200) = 120 / 61 = 1.97

But the variance value should be integer, for this reason we need to approximate it to the nearest higher integer, hence the variance will be 2. The question here,  what is the meaning of variance = 2 ?? this means that R2 will install all the routes that have metric range from (Lowest metric) to (2 x Lowest metric), but before R2 install the three routes in the IP routing table it should check first if those routes should be either successor or feasible successor to make sure that no routing loop can happen in the network, this means that R2 need to check first if those routes achieved the Feasibility condition or not, and i already explained the feasibility condition in the previous post 2-R&S/Enhanced Interior Gateway Routing Protocol (EIGRP) Part 2 , so in this case we need to check if the feasibility condition is achieved for three routes, the two routes received from R5 and R3 are successor for this reason they will be installed without any issues, as well if we check the route received from R4 we will find that the feasibility condition is achieved as the AD (409600) of the route received from R4 is lower than FD (435200) of the successors R5 and R3, for this reason R2 will successfully install all the routes that have metric range from 435200 to  870400, so R2 will install the three routes (route received from R5 with metric 435200, route received from R3 with metric 435200 and route received from R4 with metric 857600).

To configure unequal load balancing on R2, we need to define the variance value under the EIGRP process using the following command:

R2(config)#router eigrp 100
R2(config-router)#variance 2

We can check the configured variance value using the following command:

R2#show ip protocols | be eigrp
Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks not accepted from incoming updates
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 NSF-aware route hold timer is 240
 Router-ID: 2.2.2.2
 Topology : 0 (base) 
 Active Timer: 3 min
 Distance: internal 90 external 170
 Maximum path: 4
 Maximum hopcount 100
 Maximum metric variance 2    <==== (Variance value = 2)

--More--

So R2 will perform unequal load balancing for the subnet/network 6.6.6.6/32 as it has three routes in its IP routing table for this IP address and those three routes have different metrics, hence R2 will perform “Unequal load balancing”, and assume that R2 is implementing “per-packet load balancing”, this means that R2 will forward the packets based on “Traffic share count” value, as this value is used to determine how the load balancing is achieved over the paths (i.e how many packets should be forwarded over the available paths as for sure the number of packets that should be forwarded over the available paths will not be the same because of unequal load balancing concept), for this reason R2 need to know the traffic share count for each route to know how many packets should be forwarded out each path, so we can get the traffic share count from the variance value, since the variance value = 120 / 61, this means that the traffic share count for the route received from R4 is 61, while the traffic share count for the routes received from R5 and R3 is 120, this means that if we need to send 301 packets to the IP address 6.6.6.6, R2 will forward the first 120 packets (packet 1, packet 2, packet 3, …, packet 120) over the first path (out Eth0/3), then the second 120 packets (packet 121, packet 122, …, packet 240) over the second path (out Eth0/1), then the remaining 61 packets (packet 241, packet 242, …, packet 301) over the third path (out Eth0/2) as the following:

eigrp-config3

We can check that the three routes are installed in the IP routing table of R2 based on the following:

R2#show ip route 6.6.6.6
Routing entry for 6.6.6.6/32
 Known via "eigrp 100", distance 90, metric 435200, type internal
 Redistributing via eigrp 100
 Last update from 192.168.23.3 on Ethernet0/1, 00:00:05 ago
 Routing Descriptor Blocks:
 * 192.168.25.5, from 192.168.25.5, 00:00:05 ago, via Ethernet0/3    <==== (Route via R5)
 Route metric is 435200, traffic share count is 120    <==== (Traffic share count = 120)
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2
 192.168.24.4, from 192.168.24.4, 00:00:05 ago, via Ethernet0/2      <==== (Route via R4)
 Route metric is 857600, traffic share count is 61     <==== (Traffic share count = 61)
 Total delay is 23500 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2
 192.168.23.3, from 192.168.23.3, 00:00:05 ago, via Ethernet0/1      <==== (Route via R3)
 Route metric is 435200, traffic share count is 120    <==== (Traffic share count = 120)
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

 

As mentioned before that the “traffic share count” value is used to determine how the load balancing is achieved over the paths (i.e how many packets should be forwarded over the available paths), in case of equal load balancing, the traffic share count will be 1 as all the routes installed in the IP routing table have the same metric hence the number of packets forwarded over these available paths will be the same, but in case of unequal load balancing, the traffic share count is inversely proportional to the route metric, this means that if the route has small metric value, the traffic share count value will be large, hence it will carry more packets and vice versa, which means that if the route has high metric value, the traffic share count value will be small, hence it will carry less packets.

EIGRP process has two methods to compute the traffic share over the available paths:

1-Balanced traffic share: Balanced traffic share means that the router will balance the traffic among all the interfaces installed in the IP routing table based on the route metric, as mentioned before, the traffic share count is inversely proportional to the route metric, this means that if we need to enable unequal cost load balancing we need to enable the balanced traffic share on the router, by default the balanced traffic share is the default traffic share option. To enable balanced traffic share we can use the following command:

R2(config)#router eigrp 100
R2(config-router)#traffic-share balanced

2-Minimum traffic share: Min traffic share means that the router will balance the traffic only among the paths with the min metric, this means that we can’t use unequal cost load balancing when the min traffic share is configured. To enable balanced traffic share we can use the following command:

R2(config)#router eigrp 100
R2(config-router)#traffic-share min across-interfaces

 

Passive-Interface:

Passive interface is a feature used by EIGRP to neither send nor process any EIGRP message on certain interface, this means that it will not send nor process EIGRP hello on this interface and you can use the passive-interface feature if you don’t want to form an EIGRP adjacency with the EIGRP-speaking router(s) connected on this interface. passive-interface feature is used to be enabled on the stub interface, i mentioned before what is the meaning of stub interface (no EIGRP adjacency will be formed on this interface) which means that the router need to advertise the subnet/network of this stub interface in the EIGRP domain without forming any EIGRP adjacency on this stub interface. Passive interface feature can be enabled either on certain interface(s) or on all interfaces, but it is not logical to enable passive-interface feature on all interfaces as the router will not form any EIGRP adjacency, hence the EIGRP process has no purpose on this router, for this reason we can use passive-interface feature only on the interfaces that we don’t want to from an EIGRP adjacencies.
Passive-interface feature can be enabled on certain interface using the following command:

R1(config)#router eigrp 100
R1(config-router)#passive-interface Ethernet0/1

Passive-interface feature can be enabled on all the interfaces using the following command:

R1(config)#router eigrp 100
R1(config-router)#passive-interface default

If we want to enable passive-interface feature on all the interfaces except Ethernet0/0 we can use the following commands:

R1(config)#router eigrp 100 
R1(config-router)#passive-interface default    <==== Enable passive-interface on all interfaces
R1(config-router)#no passive-interface Ethernet0/0    <==== Disable passive-interface on interface Eth0/0

 

Offset List:

Offset list is a feature used by EIGRP to make modification to the EIGRP route metric, at which is used by adding an offset value to the Advertised distance (AD) for the routes received from the EIGRP neighbors or add an offset to the AD for the routes sent by the local router to the EIGRP neighbors , this means that the offset list can be used either in the “in” or “out” direction (i.e for the routes received from the neighbors or the routes advertised to the neighbors). The offset list is used per subnet/network and per interface basis, this means that when we use the offset list we need to define which subnet/network we need to add an offset to, what is the offset value we need to add to the AD value and which interface we need to apply this offset list either in the “in” or “out” direction.Before we can configure offset list, let’s check the EIGRP topology table for the subnet/network 6.6.6.6/32 on R2:

R2#show ip eigrp topology 6.6.6.6/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(2.2.2.2) for 6.6.6.6/32
 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200    <==== (There are 2 Successors for 6.6.6.6/32 with FD = 4352200)
 Descriptor Blocks:
 192.168.23.3 (Ethernet0/1), from 192.168.23.3, Send flag is 0x0    <==== (Successor 1)
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6
 192.168.25.5 (Ethernet0/3), from 192.168.25.5, Send flag is 0x0    <==== (Successor 2)
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6
 192.168.24.4 (Ethernet0/2), from 192.168.24.4, Send flag is 0x0
 Composite metric is (857600/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 23500 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6

From the previous O/P we can deduce the following:
1-There are 2 successors for the subnet/network (6.6.6.6/32).
2-The two successors have FD = 435200.
3-The first successor is known from the neighbor with the IP address (192.168.23.3) via (Ethernet0/1) and it has AD = 409600 and FD = 435200.
4-The first successor is known from the neighbor with the IP address (192.168.25.5) via (Ethernet0/3) and it has AD = 409600 and FD = 435200.

We can configure an offset list to add an offset value of 100 for the subnet/network (6.6.6.6) received from the neighbor connected to the interface (Eth0/1) using the following command:

R2(config)#access-list 1 permit 6.6.6.6
R2(config)#router eigrp 100
R2(config-router)#offset-list 1 in 100 Ethernet0/1

We configured standard ACL 1 that match the IP address 6.6.6.6, then we apply the offset list using this standard ACL in the “in” direction by adding an offset value of “100” for the EIGRP routes received from the neighbor connected to the interface (Eth0/1), this means that we added an offset value of 100 for the EIGRP route that carry the subnet/network 6.6.6.6/32 that is received from the neighbor connected to the interface (Eth0/1).

Once we configured the offset list command, R2 send an EIGRP update message (with “Restart” flag is set to 1) out the interface (Eth0/1) for graceful restart to force the neighbor (R3) connected to this interface to send an EIGRP update message to add the offset value to the AD value advertised from R3 as the following:

eigrp-pak19

As well R2 will generate the following log message indicating that there is a change happened regarding the routes (as we configured offset list):

At R2:

*Feb 5 14:03:00.466: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.23.3 (Ethernet0/1) is resync: intf route configuration changed

Once R3 received the EIGRP update message (with Restart flag is set to 1) , it will generate the following log message:

At R3:

*Feb 5 14:03:00.508: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.23.2 (Ethernet0/1) is resync: peer graceful-restart

We can check the EIGRP topology table for the subnet/network 6.6.6.6/32 on R2 after we configured the offset list in the “in” direction on R2:

R2#show ip eigrp topology 6.6.6.6/32 
EIGRP-IPv4 Topology Entry for AS(100)/ID(2.2.2.2) for 6.6.6.6/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 435200    <=== (After configuring offset list, only one Successor)
 Descriptor Blocks:
 192.168.25.5 (Ethernet0/3), from 192.168.25.5, Send flag is 0x0
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6
 192.168.23.3 (Ethernet0/1), from 192.168.23.3, Send flag is 0x0
 Composite metric is (435300/409700), route is Internal     <==== (AD become 409700 instead of 409600 and FD = 435300 instead of 435200)
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7003 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6
 192.168.24.4 (Ethernet0/2), from 192.168.24.4, Send flag is 0x0
 Composite metric is (857600/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 23500 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6

We can apply offset list in the “out” direction using the following command:

R3(config)#access-list 1 permit 6.6.6.6
R3(config)#router eigrp 100
R3(config-router)#offset-list 1 out 100 Ethernet0/1

We configured standard ACL 1 that match the IP address 6.6.6.6, then we apply the offset list using this standard ACL in the “out” direction by adding an offset value of “100” for the EIGRP routes advertised to the neighbor connected to the interface (Eth0/1), this means that we added an offset value of 100 for the EIGRP route that carry the subnet/network 6.6.6.6/32 when R3 advertised this subnet/network to the neighbor (R2) connected to the interface (Eth0/1).

We can check the EIGRP topology table for the subnet/network 6.6.6.6/32 on R2 after we configured the offset list in the “out” direction on R3:

R2#show ip eigrp topology 6.6.6.6/32 
EIGRP-IPv4 Topology Entry for AS(100)/ID(2.2.2.2) for 6.6.6.6/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 435200
 Descriptor Blocks:
 192.168.25.5 (Ethernet0/3), from 192.168.25.5, Send flag is 0x0
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6
 192.168.23.3 (Ethernet0/1), from 192.168.23.3, Send flag is 0x0
 Composite metric is (435300/409700), route is Internal     <==== (AD become 409700 instead of 409600 and FD = 435300 instead of 435200)
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7003 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6
 192.168.24.4 (Ethernet0/2), from 192.168.24.4, Send flag is 0x0
 Composite metric is (857600/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 23500 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 6.6.6.6

If we need to add offset value for all the subnets/networks advertised or received to or from the EIGRP neighbors, simply we can use the following command:

R2(config)#router eigrp 100
R2(config-router)#offset-list 0 in 100 Ethernet0/1      <==== (0 means select all networks)
R3(config)#router eigrp 100
R3(config-router)#offset-list 0 out 100 Ethernet0/1     <==== (0 means select all networks)

 

Distribute List:

Distribute list is a feature used by EIGRP to make EIGRP prefix filtering, this means that the EIGRP can filter EIGRP prefixes from being advertised or received to or from the EIGRP neighbor, this means that the distribute list can be used either in the “in” or “out” direction (i.e for the routes received from the neighbors or the routes advertised to the neighbors). The distribute list has multiple options to be applied under the EIGRP process based on the following:

1-Use distribute list to deny certain subnet/prefix from being received from any neighbor connected to certain interface, here we need to deny the subnet/network (5.5.5.5/32) from being received on R2 from any neighbor connected to the interface (Eth0/3), but before we configure the distribute list, let’s check how R2 reach the IP address 5.5.5.5/32:

R2#show ip route 5.5.5.5
Routing entry for 5.5.5.5/32
 Known via "eigrp 100", distance 90, metric 409600, type internal
 Redistributing via eigrp 100
 Last update from 192.168.25.5 on Ethernet0/3, 00:00:13 ago    <==== (The IP address 5.5.5.5 is known from R5 via Eth0/3)
 Routing Descriptor Blocks:
 * 192.168.25.5, from 192.168.25.5, 00:00:13 ago, via Ethernet0/3
 Route metric is 409600, traffic share count is 1
 Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

We can configure the distribute list using Access List using the following commands:

R2(config)#access-list 1 deny 5.5.5.5
R2(config)#access-list 1 permit any 
R2(config)#router eigrp 100
R2(config-router)#distribute-list 1 in Ethernet0/3

We configured standard ACL 1 that deny the subnet/network (5.5.5.5/32) and permit anything else, then we applied the distribute list using this standard ACL 1 in the “in” direction for the interface (Eth0/3).

We can configure the distribute list using Prefix List using the following commands:

R2(config)#ip prefix-list DENY_PREFIX5 deny 5.5.5.5/32
R2(config)#ip prefix-list DENY_PREFIX5 permit 0.0.0.0/0 le 32
R2(config)#router eigrp 100 
R2(config-router)#distribute-list prefix DENY_PREFIX5 in Ethernet0/3

We configured prefix list (DENY_PREFIX5) that deny the subnet/network (5.5.5.5/32) and permit anything else (0.0.0.0/0 le 32), then we applied the distribute list using this prefix list (DENY_PREFIX5) in the “in” direction for the interface (Eth0/3).

We can configure the distribute list using route-map using the following commands:

R2(config)#access-list 1 deny 5.5.5.5
R2(config)#access-list 1 permit any 
R2(config)#route-map DENY_PREFIX5
R2(config-route-map)#match ip address 1
R2(config)#router eigrp 100
R2(config-router)#distribute-list route-map DENY_PREFIX5 in Ethernet0/3

We configured standard ACL 1 that deny the subnet/network (5.5.5.5/32) and permit anything else, then we configured route-map (DENY_PREFIX5) that match this standard ACL 1, then we applied the distribute list using this route-map (DENY_PREFIX5) in the “in” direction for the interface (Eth0/3).

We can configure the distribute list using route-map using the following commands:

R2(config)#ip prefix-list DENY_PREFIX5 deny 5.5.5.5/32
R2(config)#ip prefix-list DENY_PREFIX5 permit 0.0.0.0/0 le 32
R2(config)#route-map DENY_PREFIX5
R2(config-route-map)#match ip address prefix-list DENY_PREFIX5
R2(config)#router eigrp 100
R2(config-router)#distribute-list route-map DENY_PREFIX5 in Etherne0/3

We configured prefix list (DENY_PREFIX5) that deny the subnet/network (5.5.5.5/32) and permit anything else (0.0.0.0/0 le 32), then we configured route-map (DENY_PREFIX5) that match this prefix list, then we applied the distribute list using this route-map (DENY_PREFIX5) in the “in” direction for the interface (Eth0/3).

Once we configured the distribute list command, R2 send an EIGRP update message (with “Restart” flag is set to 1) out the interface (Eth0/3) for graceful restart to force the neighbor (R5) connected to this interface to send an EIGRP update message to deny the subnet/network (5.5.5.5/32) advertised from R3 as the following:

eigrp-pak20

As well R2 will generate the following log message indicating that there is a change happened regarding the routes (as we configured distribute list):

At R2:

*Feb 5 15:17:13.377: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.25.5 (Ethernet0/3) is resync: intf route configuration changed

Once R5 received the EIGRP update message (with Restart flag is set to 1) , it will generate the following log message:

At R5:

*Feb 5 15:17:13.417: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.25.2 (Ethernet0/3) is resync: peer graceful-restart

Once we configured the distribute list we can check how R2 reach the IP address 5.5.5.5/32:

R2#show ip route 5.5.5.5
Routing entry for 5.5.5.5/32
 Known via "eigrp 100", distance 90, metric 435200, type internal
 Redistributing via eigrp 100
 Last update from 192.168.23.3 on Ethernet0/1, 00:00:04 ago    <==== (The IP address 5.5.5.5 is known now from R3 via Eth0/1)
 Routing Descriptor Blocks:
 * 192.168.23.3, from 192.168.23.3, 00:00:04 ago, via Ethernet0/1
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

2-Use distribute list to deny certain subnet/prefix from being received from any neighbor connected to any interface, here we need to deny the subnet/network (5.5.5.5/32) from being received on R2 from any neighbor connected to any interface.

We can configure the distribute list using either Access list, prefix list or route-map using the following commands:

R2(config)#access-list 1 deny 5.5.5.5
R2(config)#access-list 1 permit any 
R2(config)#router eigrp 100
R2(config-router)#distribute-list 1 in

We configured standard ACL 1 that deny the subnet/network (5.5.5.5/32) and permit anything else, then we applied the distribute list using this standard ACL 1 in the “in” direction without specifying any interface to apply it for all neighbors.

Once we configured the distribute list we can check how R2 reach the IP address 5.5.5.5/32:

R2#show ip route 5.5.5.5
% Network not in table    <==== (R2 no longer has route for the subnet/network 5.5.5.5/32 in the IP routing table)

3-Use distribute list to deny certain subnet/prefix from being received from certain neighbor connected to certain interface, here we need to deny the subnet/network (5.5.5.5/32) from being received on R2 from the neighbor with the IP address (192.168.25.5) connected to the interface (Eth0/3).

We can configure the distribute list using prefix list using the following commands:

R2(config)#ip prefix-list DENY_PREFIX5 deny 5.5.5.5/32 
R2(config)#ip prefix-list DENY_PREFIX5 permit 0.0.0.0/0 le 32
R2(config)#ip prefix-list GATEWAY permit 192.168.25.5/32
R2(config)#router eigrp 100
R2(config-router)#distribute-list prefix DENY_PREFIX5 gateway GATEWAY in Ethernet0/3

We configured prefix list (DENY_PREFIX5) that deny the subnet/network (5.5.5.5/32) and permit anything else (0.0.0.0/0 le 32), as well we configured another prefix list (GATEWAY) that is used to match the IP address (192.168.25.5) of the neighbor (R5) that we need to deny the subnet/network from being received on R2, then we applied the distribute list using those two prefix lists (DENY_PREFIX5) and (GATEWAY) in the “in” direction for the interface (Eth0/3).

Once we configured the distribute list we can check how R2 reach the IP address 5.5.5.5/32:

R2#show ip route 5.5.5.5 
Routing entry for 5.5.5.5/32
 Known via "eigrp 100", distance 90, metric 435200, type internal
 Redistributing via eigrp 100
 Last update from 192.168.23.3 on Ethernet0/1, 00:00:37 ago    <==== (The IP address 5.5.5.5 is known now from R3 via Eth0/1)
 Routing Descriptor Blocks:
 * 192.168.23.3, from 192.168.23.3, 00:00:37 ago, via Ethernet0/1
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

 

EIGRP Summarization:

We already know what is the meaning of network summarization, simply the network summarizarion means that the router will not send (suppress) some of  the more specific prefixes it has in its IP routing table, instead it will collect some of the more specific prefixes and summarize them into small number of less specific prefixes and advertise these less specific prefixes, at which these less specific prefixes are called summary, aggregate or supernet prefixes. EIGRP support the concept of summarization, at which it can summarize some of  the more specific prefixes it has in its IP routing table and advertise one or more summary prefixes per interface basis, this means that the EIGRP summary is configured per interface basis at which it will advertise this single or multiple summary addresses out the interface on which the summary is configured. Before we configure EIGRP summary, let’s see check the route entry for the IP address 1.1.1.1 in the IP routing table of R2:

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32    <==== (R2 has route entry of 1.1.1.1/32 that match the IP address 1.1.1.1)
 Known via "eigrp 100", distance 90, metric 409600, type internal
 Redistributing via eigrp 100
 Last update from 192.168.12.1 on Ethernet0/0, 00:43:53 ago
 Routing Descriptor Blocks:
 * 192.168.12.1, from 192.168.12.1, 00:43:53 ago, via Ethernet0/0
 Route metric is 409600, traffic share count is 1
 Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

We can configure EIGRP summary per interface basis using the following command:

R1(config)#interface Ethernet0/0
R1(config-if)#ip summary-address eigrp 100 1.0.0.0/8

Here we configured EIGRP summary  on the interface (Eth0/0) on R1 by summarizing any more specific subnets/networks that is advertised by EIGRP and match the summary address (1.0.0.0/8), at our case R1 has Loopback0 interface configured with IP address (1.1.1.1/32) and is advertised in the EIGRP domain and it match the summary address (1.0.0.0/8), hence R1 will suppress the advertisement of (1.1.1.1/32) and advertise only the summary address (1.0.0.0/8) as the following:

R2#show ip route 1.1.1.1
Routing entry for 1.0.0.0/8
 Known via "eigrp 100", distance 90, metric 409600, type internal
 Redistributing via eigrp 100
 Last update from 192.168.12.1 on Ethernet0/0, 00:00:19 ago
 Routing Descriptor Blocks:
 * 192.168.12.1, from 192.168.12.1, 00:00:19 ago, via Ethernet0/0
 Route metric is 409600, traffic share count is 1
 Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

Once we configured the EIGRP summary, R1 send an EIGRP update message (with “Restart” flag is set to 1) out the interface (Eth0/0) for graceful restart as the following:

eigrp-pak21

As well R1 will generate the following log message indicating that there is a change happened regarding the routes (as we configured EIGRP summary):

At R1:

*Feb 5 17:24:59.093: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.2 (Ethernet0/0) is resync: summary configured

Once R2 received the EIGRP update message (with Restart flag is set to 1) , it will generate the following log message:

At R2:

*Feb 5 17:24:59.150: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.1 (Ethernet0/0) is resync: peer graceful-restart

Once R1 configured the EIGRP summary using the command “ip summary-address eigrp 100 1.0.0.0/8” under the interface (Eth0/0), it will install an entry in its IP routing table for this summary address (1.0.0.0/8) with “Null0” as its next hop, and the reason for this is to drop any packet destined to an IP address that didn’t match any route entry in its IP routing table, and it match this newly created summary route entry (that has next hop of Null0), the reason for this is to avoid routing loop that can result if no entry is created for this summary address, so let’s take the following example to explain what happened when the EIGRP summary is configured:
Assume that we have three routers Router1, Router2 and Router3 and they are connected as the following:
(Router1)<======>(Router2)<======>(Router3)

The three routers form an EIGRP adjacency with each other, Router2 form EIGRP adjacency with both Router1 and Router3. Router1 advertise three subnets/networks (192.168.0.0/24), (192.168.1.0/24) and (192.168.2.0/24), and it need to summarize those subnet/networks into single supernet, so Router1 will configure EIGRP summary using the command “ip summar-address eigrp 100 192.168.0.0/22”, and assume that Router3 advertised default route, so that Router2 install default route in its IP routing table toward Router3 and Router1 install default route in its IP routing table toward Router2.
Assume that Router2 want to send a packet to the IP address 192.168.3.1, it checked its IP routing table and it found an entry match 192.168.3.1 which is (192.168.0.0/22) toward Router1, so it send the packet to Router1, once Router1 received the packet it checked its IP routing table and found that the IP address 192.168.3.1 match the default route toward Router2, then it forward the packet to Router2, then Router2 forward it to Router1, then Router1 to Router2 and so on, this means that there is a routing loop happened between Router1 and Router2. For this reason Router1 should install an entry in its IP routing table for the summary address (192.168.0.0/22) with “Null0” as its next hop to avoid such issue.

So once R1 configured the EIGRP summary using the command “ip summary-address eigrp 100 1.0.0.0/8” under the interface (Eth0/0), it will install an entry in its IP routing table for this summary address (1.0.0.0/8) with “Null0” as its next hop and this entry has an Administrative distance of 5 as the following:

R1#show ip route 1.0.0.0 255.0.0.0
Routing entry for 1.0.0.0/8     <====(An entry is created for the summary address 1.0.0.0/8) 
 Known via "eigrp 100", distance 5, metric 128256, type internal    <==== (Admin Distance = 5)
 Redistributing via eigrp 100
 Routing Descriptor Blocks:
 * directly connected, via Null0    <==== (The next hop is Null0)
 Route metric is 128256, traffic share count is 1
 Total delay is 5000 microseconds, minimum bandwidth is 8000000 Kbit
 Reliability 255/255, minimum MTU 1514 bytes
 Loading 1/255, Hops 0

We can change the Administrative Distance for this summary route entry using the following command:

R1(config)#router ei 100
R1(config-router)#summary-metric 1.0.0.0/8 distance 10

We can check the entry for this summary route after we change the Administrative distance to be 10 as the following:

R1#show ip route 1.0.0.0 255.0.0.0
Routing entry for 1.0.0.0/8
 Known via "eigrp 100", distance 10, metric 128256, type internal    <==== (Admin Distance = 10)
 Redistributing via eigrp 100
 Routing Descriptor Blocks:
 * directly connected, via Null0
 Route metric is 128256, traffic share count is 1
 Total delay is 5000 microseconds, minimum bandwidth is 8000000 Kbit
 Reliability 255/255, minimum MTU 1514 bytes
 Loading 1/255, Hops 0

As mentioned, when configuring EIGRP summary, the router will suppress all the more specific routes that match certain summary address and advertise only this summary route. EIGRP support the concept of advertising the more specific routes as well in addition to the summary route and this can be done using the “Leak map” feature that can be configured with the EIGRP summary.
Assume that R1 has three subnets (1.1.1.1/32), (1.1.1.2/32) and (1.1.1.3/32), and it need to summarize those more specific routes and advertise only the summary route (1.0.0.0/8) in addition to the more specific route (1.1.1.1/32), so we can configure it using the following:

R1(config)#ip prefix-list ADVERTISE_1.1.1.1/32 permit 1.1.1.1/32
R1(config)#route-map ADVERTISE_1.1.1.1/32
R1(config-route-map)#match ip address prefix-list ADVERTISE_1.1.1.1/32
R1(config)#interface Ethernet0/0
R1(config-if)#ip summary-address eigrp 100 1.0.0.0/8 leak-map ADVERTISE_1.1.1.1/32

Here we configured prefix list (ADVERTISE_1.1.1.1/32) that match the more specific route (1.1.1.1/32), then configured route-map (ADVERTISE_1.1.1.1/32) that match this prefix list, then we configured  EIGRP summary  on the interface (Eth0/0) on R1 by summarizing any more specific subnets/networks that is advertised by EIGRP and match the summary address (1.0.0.0/8), at our case R1 has Loopback0 interface configured with IP address (1.1.1.1/32), Loopback1 with IP address (1.1.1.2/32) and Loopback2 with IP address (1.1.1.3/32) and it advertised those more specific routes in the EIGRP domain and they match the summary address (1.0.0.0/8), hence R1 will suppress the advertisement of (1.1.1.1/32), (1.1.1.2/32) and (1.1.1.3/32) and advertise only the summary address (1.0.0.0/8), but because we configured “leak map” that match the IP address (1.1.1.1/32), so R1 will advertise the summary route (1.0.0.0/8) in addition to this leaked route (1.1.1.1/32) as the following:

R2#show ip route | include 192.168.12.1
D 1.0.0.0/8 [90/409600] via 192.168.12.1, 00:14:08, Ethernet0/0     <==== (R2 received route for the summary route 1.0.0.0/8)
D 1.1.1.1/32 [90/409600] via 192.168.12.1, 00:17:34, Ethernet0/0    <==== (R2 received route for the more specific route 1.1.1.1/32)

 

EIGRP Stub Routing:

EIGRP stub routing is a feature supported by EIGRP to enhance some factors in the EIGRP domain, it is used to enhance routes stability, try to minimize resource utilization, and resource here means BW of the EIGRP-enabled links, CPU processing cycles and memory. EIGRP stub routing is mainly used when we have the “Hub and Spoke” design, in the Hub and Spoke design the Spoke may has only one WAN connection and this WAN connection is toward the Hub router, this means from routing point of view, all traffic needed to be sent to other sites or to internet should be forwarded toward the Hub router, this means that it is better that the Spoke router either configure default route or receive default route from the Hub router, as well the Spoke router will advertise only the connected subnets/networks to the Hub Router, so it is not logical for the Hub router to ask this Spoke router about other subnets/networks that are previously known from another EIGRP neighbor, hence it is not logical for the Hub router to send EIGRP Query or EIRP SIAQuery messages to this Spoke router or to even expect to receive EIGRP reply or EIGRP SIAReply messages from this Spoke router, so to achieve these parts, we can configure the Spoke router as an EIGRP stub router. From this explanation we can deduce that the EIGRP stub feature is used by the Spoke router to force the Hub router not to ask it for any subnets/networks by sending EIGRP Query message and not to expect any EIGRP reply message from the Spoke router, so by this action we try to enhance the routes stability, try to minimize storing (memory utilization) and processing (CPU processing cycles utilization) unwanted EIGRP message that will not help the requester (Hub router at our example) to know any information about the lost subnets/networks. Configuring EIGRP stub feature on the Spoke router will not cause the Hub router to advertise only either default route or summary route, but this modification should be manually done on the Hub router by either advertise default route or summary route as from design point of view network summarization should be done on the Hub router. Before we configure EIGRP stbub feature, let’s see check the EIGRP adjacency between R1 and R2 from R2 point of view:

R2#show ip eigrp neighbors detail Ethernet0/0 
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
3 192.168.12.1 Et0/0 12 01:06:24 1596 5000 0 4
 Version 15.0/2.0, Retrans: 1, Retries: 0, Prefixes: 3     <==== (R2 received 3 prefixes from R1)
 Topology-ids from peer - 0 
Max Nbrs: 0, Current Nbrs: 0  

There are multiple modes for EIGRP stub feature:
1-connected: When “connected” mode is configured for EIGRP stub, this means that the EIGRP-speaking router that will be configured as EIGRP stub router will advertise only the connected subnets/networks to its EIGRP neighbors. The following represents the routes received from R1:

R2#show ip route eigrp | in 192.168.12.1
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/307200] via 192.168.12.1, 01:00:01, Ethernet0/0     <==== (I configured static default route toward Null0 and make redistribution for static routes)
D 1.1.1.1 [90/409600] via 192.168.12.1, 01:00:01, Ethernet0/0
D 11.11.11.11 [90/409600] via 192.168.12.1, 01:00:27, Ethernet0/0

We can configure EIGRP Stub connected using the following command:

R1(config)#router eigrp 100
R1(config-router)#eigrp stub connected

Here we configured EIGRP stub connected on R1, so it will send an EIGRP hello message containing the Peer Stub information with “Connected” and “Redistributed” flags set to 1 to tell R2 that it now become an EIGRP stub router (Connected mode), as well it contain Peer termination information to terminate the EIGRP adjacency and establish it again based on the new configuration, the following represents the EIGRP hello message:

eigrp-pak22

As well R1 will generate the following log message indicating that there is a change happened regarding the peer (as the EIGRP stub feature is configured):

At R1:

 *Feb 22 01:42:39.507: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.2 (Ethernet0/0) is down: peer info changed

Then the EIGRP adjacency is formed again with R2:

*Feb 22 01:42:40.865: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.2 (Ethernet0/0) is up: new adjacency

Once R2 received the EIGRP Hello message containing both Peer Stub and Peer termination information, it will generate the following log message:

At R2:

*Feb 22 01:42:39.502: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.1 (Ethernet0/0) is down: Interface PEER-TERMINATION received

Then the EIGRP adjacency is formed again with R1:

*Feb 22 01:42:40.877: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.12.1 (Ethernet0/0) is up: new adjacency

We can check on R2 that R1 is now configured as Stub router using the following command:

R2#show ip eigrp neighbors detail Ethernet0/0
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
3 192.168.12.1 Et0/0 10 00:05:36 19 114 0 7
 Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2     <==== (R2 received 2 prefixes from R1)
 Topology-ids from peer - 0 
 Stub Peer Advertising (CONNECTED ) Routes     <==== (R1 now advertise Stub peer information which is advertising only CONNECTED routes) 
 Suppressing queries     <==== (R2 will not send Query message to R1) 
Max Nbrs: 0, Current Nbrs: 0

We can check that R2 received only the directly connected subnets/networks from R1 as the following:

R2#show ip route eigrp | in 192.168.12.1
D 1.1.1.1 [90/409600] via 192.168.12.1, 00:01:45, Ethernet0/0
D 11.11.11.11 [90/409600] via 192.168.12.1, 01:00:27, Ethernet0/0

2-receive-only: When “received-only” mode is configured for EIGRP stub, this means that the EIGRP-speaking router that will be configured as EIGRP stub router will not advertise any routes, it just receive the EIGRP routes from its EIGRP neighbors.
We can configure EIGRP Stub connected using the following command:

R1(config)#router eigrp 100
R1(config-router)#eigrp stub receive-only

Here we configured EIGRP stub receive-only on R1, so it will send an EIGRP hello message containing the Peer Stub information with “receive-only” flag set to 1 to tell R2 that it now become an EIGRP stub router (receive-only mode), as well it contain Peer termination information to terminate the EIGRP adjacency and establish it again based on the new configuration

We can check on R2 that R1 is now configured as Stub router using the following command:

R2#show ip eigrp neighbors detail Ethernet0/0
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
3 192.168.12.1 Et0/0 13 00:00:55 9 100 0 13
 Version 15.0/2.0, Retrans: 0, Retries: 0     <==== (R2 didn't receive any prefixes from R1)
 Topology-ids from peer - 0 
 Receive-Only Peer Advertising (No) Routes     <==== (R1 now advertise Stub peer information which is No routes) 
 Suppressing queries      <==== (R2 will not send Query message to R1)
Max Nbrs: 0, Current Nbrs: 0

We can check that R2 didn’t receive any routes from R1 as the following:

R2#show ip route eigrp | in 192.168.12.1 
R2#       <==== (R2 didn't receive any routes from R1)

3-redistributed: When “redistributed” mode is configured for EIGRP stub, this means that the EIGRP-speaking router that will be configured as EIGRP stub router will advertise only the redistributed routes (e.g static, connected, RIP, OSPF, …) to its EIGRP neighbors.
We can configure EIGRP Stub connected using the following command:

R1(config)#router eigrp 100
R1(config-router)#eigrp stub redistributed

Here we configured EIGRP stub redistributed on R1, so it will send an EIGRP hello message containing the Peer Stub information with “redistributed” flag set to 1 to tell R2 that it now become an EIGRP stub router (redistributed mode), as well it contain Peer termination information to terminate the EIGRP adjacency and establish it again based on the new configuration

We can check on R2 that R1 is now configured as Stub router using the following command:

R2#show ip eigrp neighbors detail Ethernet0/0
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
3 192.168.12.1 Et0/0 14 00:00:45 1 100 0 14
 Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1     <==== (R2 received only 1 prefix from R1)
 Topology-ids from peer - 0 
 Stub Peer Advertising (REDISTRIBUTED ) Routes      <==== (R1 now advertise Stub peer information which is REDISTRIBUTED routes) 
 Suppressing queries     <==== (R2 will not send Query message to R1)
Max Nbrs: 0, Current Nbrs: 0

We can check that R2 received only the redistributed routes from R1 as the following:

R2#show ip route eigrp | in 192.168.12.1 
D*EX 0.0.0.0/0 [170/307200] via 192.168.12.1, 01:00:01, Ethernet0/0     <==== (R2 received only the redistributed routes(all the redistributed routes e.g static, connected, ...))

 

4-static: When “static” mode is configured for EIGRP stub, this means that the EIGRP-speaking router that will be configured as EIGRP stub router will advertise only the redistributed static routes to its EIGRP neighbors.
We can configure EIGRP Stub connected using the following command:

R1(config)#router eigrp 100
R1(config-router)#eigrp stub static

Here we configured EIGRP stub redistributed on R1, so it will send an EIGRP hello message containing the Peer Stub information with “static” flag set to 1 to tell R2 that it now become an EIGRP stub router (static mode), as well it contain Peer termination information to terminate the EIGRP adjacency and establish it again based on the new configuration

We can check on R2 that R1 is now configured as Stub router using the following command:

R2#show ip eigrp neighbors detail Ethernet0/0
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
3 192.168.12.1 Et0/0 11 00:01:00 9 100 0 29
 Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1     <==== (R2 received only 1 prefix from R1)
 Topology-ids from peer - 0 
 Stub Peer Advertising (STATIC ) Routes      <==== (R1 now advertise Stub peer information which is REDISTRIBUTED Satic routes)
 Suppressing queries      <==== (R2 will not send Query message to R1)
Max Nbrs: 0, Current Nbrs: 0

We can check that R2 received only the redistributed static routes from R1 as the following:

R2#show ip route eigrp | in 192.168.12.1 
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/281600] via 192.168.12.1, 00:00:05, Ethernet0/0     <==== (R2 received only the redistributed static routes)

 

5-summary: When “summary” mode is configured for EIGRP stub, this means that the EIGRP-speaking router that will be configured as EIGRP stub router will advertise only the summary routes to its EIGRP neighbors.
We can configure EIGRP Stub summary using the following command:

R1(config)#router eigrp 100
R1(config-router)#eigrp stub summary

Here we configured EIGRP stub summary on R1, so it will send an EIGRP hello message containing the Peer Stub information with “summary” flag set to 1 to tell R2 that it now become an EIGRP stub router (summary mode), as well it contain Peer termination information to terminate the EIGRP adjacency and establish it again based on the new configuration. I configured EIGRP summary (1.0.0.0/8) on interface (Eth0/0) at R1 to test the EIGRP stub summary.

We can check on R2 that R1 is now configured as Stub router (Summary mode) using the following command:

R2#show ip eigrp neighbors detail Ethernet0/0
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
3 192.168.12.1 Et0/0 11 00:01:00 9 100 0 29
 Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1    <==== (R2 received only 1 prefix from R1)
 Topology-ids from peer - 0 
 Stub Peer Advertising (SUMMARY ) Routes      <==== (R1 now advertise Stub peer information which is REDISTRIBUTED Satic routes)
 Suppressing queries      <==== (R2 will not send Query message to R1)
Max Nbrs: 0, Current Nbrs: 0

We can check that R2 received only the summary routes from R1 as the following:

R2#show ip route eigrp | in 192.168.12.1 
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
D 1.0.0.0/8 [90/409600] via 192.168.12.1, 00:00:14, Ethernet0/0     <==== (R2 received only the summary routes)

6-Leak Map: When “Leak Map” mode is configured for EIGRP stub, this means that the EIGRP-speaking router that will be configured as EIGRP stub router will advertise only the connected and summary routes in addition to the dynamically learned routes (learned from its EIGRP neighbors) that are matched in “leak map” to its EIGRP neighbors.
We can configure Standard ACL “LEAK_ROUTE” that is used to match the dynamically learned routes that will be leaked, the leak-map “LEAK_MAP” itself that will reference this ACL and configured R5 as an EIGRP Stub with leak-map using the following command:

R5(config)#ip access-list standard LEAK_ROUTE
R5(config-std-nacl)#permit 6.6.6.6
R5(config-std-nacl)#exit
R5(config)#route-map LEAK_MAP
R5(config-route-map)#match ip address LEAK_ROUTE
R5(config-route-map)#exit
R5(config)#router eigrp 100
R5(config-router)#eigrp stub leak-map LEAK_MAP

Here we configured EIGRP stub summary at R5, so it will send an EIGRP hello message containing the Peer Stub information with “connected” , “summary” and “leak-map” flags set to 1 to tell R2 that it now become an EIGRP stub router (leak-map mode), as well it contain Peer termination information to terminate the EIGRP adjacency and establish it again based on the new configuration. The following represents the routes received from R5 at R2:

R2#show ip route eigrp | in 192.168.25.5 
D 5.5.5.5 [90/409600] via 192.168.25.5, 01:43:10, Ethernet0/3
D 6.6.6.6 [90/435200] via 192.168.25.5, 01:43:09, Ethernet0/3
D 192.168.35.0/24 [90/307200] via 192.168.25.5, 01:43:10, Ethernet0/3
D 192.168.46.0/24 [90/332800] via 192.168.25.5, 01:43:09, Ethernet0/3
D 192.168.56.0/24 [90/307200] via 192.168.25.5, 01:43:09, Ethernet0/3

We can check on R2 that R5 is now configured as Stub router (leak-map mode) using the following command:

R2#show ip eigrp neighbors detail Ethernet0/3
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
2 192.168.25.5 Et0/3 12 00:00:16 9 100 0 205
 Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 4      <==== (R2 received 4 prefixes from R5)
 Topology-ids from peer - 0 
 Stub Peer Advertising (CONNECTED SUMMARY LEAKMAP ) Routes     <==== (R5 now advertise Stub peer information which is CONNECTED, SUMMARY and LEAKMAP routes)
 Suppressing queries      <==== (R2 will not send Query message to R5)
Max Nbrs: 0, Current Nbrs: 0

We can check that R2 received only the connected and summary routes from R5, in addition to the dynamically learned routes (6.6.6.6/32) that are matched by the leak-map “LEAK_MAP” as the following:

R2#show ip route eigrp | in 192.168.25.5
D 5.5.5.5 [90/409600] via 192.168.25.5, 00:00:06, Ethernet0/3     <==== (5.5.5.5/32 is a Loopback interface configured on R5, hence it is connected route)
D 6.6.6.6 [90/435200] via 192.168.25.5, 00:00:04, Ethernet0/3     <==== (R5 learn the route 6.6.6.6/32 from R6, and it is leaked by R5 using the leak-map configuration)
D 192.168.35.0/24 [90/307200] via 192.168.25.5, 00:00:08, Ethernet0/3    <==== (192.168.35.0/24 is the network of Eth0/2 configured on R5, hence it is a connected route)
D 192.168.56.0/24 [90/307200] via 192.168.25.5, 00:00:06, Ethernet0/3    <==== (192.168.56.0/24 is the network of Eth0/0 configured on R5, hence it is a connected route)

 

Hope that the post is helpful.

Regards

Mostafa Hamza

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s