Organizations that grow have networks that grow with them. For example, an expanding business that started out with a single main office might open a branch office. Now the network administrator has two networks that should be connected to share resources. The trick, then, is to connect these two separate networks together.

To connect two or more office networks together, each needs to be able to find the others. This is the job of routing. A network router examines incoming packets and forwards them towards their destination. The router does this by looking the destination up in its routing table, a kind of index of all the remote networks the router knows about. An important question for network administrators to answer is how the routing table should be populated.

Let’s discuss this question using the following diagram as a reference.

Your First Deployment: EIGRP

The least sophisticated way to populate a router’s routing table is manually using static routes. For example, an administrator could add a static route to tell the main office router where to forward traffic for remote office 1’s 10.101.1.0/24 network.

Consider the below example. Router1 is unable to ping the remote office network connected to Router2. But then we add a static route and the ping works.

Router1-Main#ping 10.101.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.101.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router1-Main#show ip route 10.101.1.0 255.255.255.0
% Subnet not in table
Router1-Main#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router1-Main(config)#ip route 10.101.1.0 255.255.255.0 192.168.1.2
Router1-Main(config)#exit
Router1-Main#show ip route 10.101.1.0 255.255.255.0
Routing entry for 10.101.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.1.2
     Route metric is 0, traffic share count is 1
Router1-Main#ping 10.101.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.101.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/52/100 ms
Router1-Main#

Static routes work but don’t scale. They’re hard to keep up with and are awkward to troubleshoot when things go wrong. Dynamic routing protocols are a big improvement over manually programming routing tables with static routes. Dynamic routing protocols allow routers to discover each other and exchange the destinations they know how to get to.

While there are many different routing protocols to choose from, folks in a predominantly Cisco network environment often choose Enhanced Interior Gateway Routing Protocol. EIGRP is deceptively simple to configure; it enables a dynamic routing exchange with just a few commands.

For example, we can configure Router1, 2, and 3 to start an EIGRP process on several different network segments attached to each router. This causes the routers to discover each other via EIGRP hello messages announced on their connected segments. As a result, the EIGRP routers become neighbors.

Let’s take a look at a basic EIGRP configuration and the neighbor relationships that are formed. Correlate this router output to the diagram. The diagram will help you make sense of what’s happening here.

Router1-Main#show run | section router eigrp
router eigrp 1
 network 10.100.0.0 0.0.0.255
 network 10.100.1.0 0.0.0.255
 network 10.100.2.0 0.0.0.255
 network 10.100.3.0 0.0.0.255
 network 192.168.1.0 0.0.0.3
 network 192.168.2.0 0.0.0.3
Router1-Main#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   192.168.2.2             Fa0/1                    14 00:03:27  120   720  0  3
0   192.168.1.2             Fa0/0                    11 00:04:14   82   492  0  5
Router1-Main#

Router2-Remote1#show run | section router eigrp
router eigrp 1
 network 10.101.1.0 0.0.0.255
 network 192.168.1.0 0.0.0.3
Router2-Remote1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   192.168.1.1             Fa0/0                    11 00:03:35  101   606  0  7
Router2-Remote1#

Router3-Remote2#show run | section router eigrp
router eigrp 1
 network 10.101.2.0 0.0.0.255
 network 192.168.2.0 0.0.0.3
Router3-Remote2#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   192.168.2.1             Fa0/0                    12 00:02:42  132   792  0  8
Router3-Remote2#

What you see is that Router2 and Router3 in the remote office are each EIGRP neighbors with Router1 in the main office. If we examine the routing tables of the three routers, we can see what routes they’ve exchanged information about.

Note that Router1 learned about the networks known to Router2 and Router3. Router2 learned about the routes known to Router1 and Router3. Router3 learned about the networks known to Router1 and Router2. In Cisco routers, the “D” indicates an EIGRP-learned route.

Note – I’ve edited the output to make it easier to read.

Router1-Main#show ip route eigrp
D        10.101.1.0/24 [90/156160] via 192.168.1.2, 00:06:56, FastEthernet0/0
D        10.101.2.0/24 [90/156160] via 192.168.2.2, 00:06:14, FastEthernet0/1

Router2-Remote1#show ip route eigrp
D        10.100.0.0/24 [90/156160] via 192.168.1.1, 00:07:03, FastEthernet0/0
D        10.100.1.0/24 [90/156160] via 192.168.1.1, 00:07:03, FastEthernet0/0
D        10.100.2.0/24 [90/156160] via 192.168.1.1, 00:07:03, FastEthernet0/0
D        10.100.3.0/24 [90/156160] via 192.168.1.1, 00:07:03, FastEthernet0/0
D        10.101.2.0/24 [90/158720] via 192.168.1.1, 00:06:21, FastEthernet0/0
D        192.168.2.0 [90/30720] via 192.168.1.1, 00:06:51, FastEthernet0/0

Router3-Remote2#show ip route eigrp
D        10.100.0.0/24 [90/156160] via 192.168.2.1, 00:06:37, FastEthernet0/0
D        10.100.1.0/24 [90/156160] via 192.168.2.1, 00:06:37, FastEthernet0/0
D        10.100.2.0/24 [90/156160] via 192.168.2.1, 00:06:37, FastEthernet0/0
D        10.100.3.0/24 [90/156160] via 192.168.2.1, 00:06:37, FastEthernet0/0
D        10.101.1.0/24 [90/158720] via 192.168.2.1, 00:06:37, FastEthernet0/0
D        192.168.1.0 [90/30720] via 192.168.2.1, 00:06:37, FastEthernet0/0

Many network administrators are content to leave EIGRP configuration right there. Start EIGRP, announce the connected networks, make sure neighbor relationships form as expected, and call it a day. However, there’s more to a robust EIGRP configuration than this.

We’ll look at two improvements to a basic EIGRP design. The first is route summarization. The second is stub routing.

Route summarization

Route summarization is a simple idea: Group several contiguous routes into a single, summarized route. In our example, we can summarize the four 10.100.x.0/24 networks from the main office into a single 10.100.0.0/22 summary route. This is accomplished with an “ip summary-address” statement on the interface connecting an EIGRP neighbor to which you wish to announce the summary.

Router1-Main#show run interface fa0/0
interface FastEthernet0/0
 description LINK TO REMOTE OFFICE 1
 ip address 192.168.1.1 255.255.255.252
 ip summary-address eigrp 1 10.100.0.0 255.255.252.0

Router1-Main#show run interface fa0/1
interface FastEthernet0/1
 description LINK TO REMOTE OFFICE 2
 ip address 192.168.2.1 255.255.255.252
 ip summary-address eigrp 1 10.100.0.0 255.255.252.0

When the summary is configured, the EIGRP neighbors will see the summary route instead of the individual routes that fall under the summary. Take a look at Router2’s routing table now that the summary is in place.

Router2-Remote1#show ip route eigrp
D        10.100.0.0/22 [90/156160] via 192.168.1.1, 00:06:18, FastEthernet0/0
D        10.101.2.0/24 [90/158720] via 192.168.1.1, 02:47:20, FastEthernet0/0
D        192.168.2.0 [90/30720] via 192.168.1.1, 02:47:50, FastEthernet0/0
Router2-Remote1#

Why bother summarizing routes in EIGRP? Don’t modern routers have enough CPU and memory to handle substantial routing tables with many thousands of routes? While it’s true that routers can handle lots of routes, route summarization in EIGRP is a part of scalable design.

Route summarization in EIGRP not only reduces the number of routes in routing tables, it also reduces something known in EIGRP as the query scope. When an EIGRP route is lost to a router, the router will query its EIGRP neighbors to see if they know about that specific route. If the neighbors also experienced the loss of that route, the neighbors will query their neighbors, and so on throughout the EIGRP domain. In large EIGRP domains with many routers, this query process can negatively impact EIGRP processing overall, as EIGRP routers must wait for replies to their queries before sending a response to the router that queried them.

Route summarization has the effect of limiting query scope. Imagine that our example network has several more connected routers, and let’s say a query arrived at Router2 asking about the 10.100.1.0/24 network. Without route summarization in place, Router2 would query all of its EIGRP neighbors. With route summarization in place, Router2 immediately responds to the query about 10.100.1.0/24 that he knows nothing about that specific route. The query scope stops at Router2.

Stub routing

Another tool to limit query scope is stub routing. Stub routing means different things in different routing protocols. In EIGRP, stub routing means configuring a specific router to be a stub.

When an EIGRP is a stub, a non-stub EIGRP neighbor understands an EIGRP stub neighbor to be a dead-end. Put another way, stub routers offer no possibility of providing a path to lost routes. Therefore, when query situations arise, there’s no reason to query the stub router, limiting the query scope.

Configuring an EIGRP router to be a stub is straightforward. In our network, Router1 is not a good stub candidate, because Router2 uses Router1 to get to the networks Router3 knows about, and vice versa. Router1 is therefore a transit router. Any EIGRP router that acts as a transit point between two network segments should not be defined as a stub.

In our topology, Router2 and Router3 are both dead-ends. Once traffic arrives at Router2 or Router3, there’s nowhere else to go — no other network segments to connect to. Therefore, Router2 and Router3 are good candidates to be stubs.

To illustrate a difference between stub and non-stub routers, let’s configure Router2 as a stub while leaving Router3 alone. Then we’ll look at the details of Router1’s EIGRP neighbors.

Router2-Remote1#conf t
Router2-Remote1(config)#router eigrp 1
Router2-Remote1(config-router)#eigrp stub
Router2-Remote1(config-router)#^Z
Router2-Remote1#

Router1-Main#show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   192.168.1.2             Fa0/0                    11 00:00:13  114   684  0  20
   Version 10.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED SUMMARY ) Routes
   Suppressing queries
1   192.168.2.2             Fa0/1                    11 00:00:49  697  4182  0  19
   Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
Router1-Main#

We configured EIGRP on Router2 to be a stub router. Now, when looking at the details of Router1’s EIGRP neighbors, we can see that Router1 recognizes Router2 as a stub, and is suppressing queries.

Take-away

I’ve inherited a few sizeable EIGRP networks over the years, and often find that route summarization and stub routing were under-used by those who preceded me. I’ve also spoken to network administrators who think EIGRP routing is easy, simply because of how easy it is to turn it on, establish neighbors, and start exchanging routes.

I encourage you to realize that there’s more to a good EIGRP design than turning it on. A well-designed EIGRP domain is capable of scaling into hundreds and even thousands of routers, but the only way that happens is if good design practices are followed from the outset. No network is too small to take the extra time needed to build it right.