EIGRP Bounded updates

I was reading about EIGRP in Routing TCP/IP Volume 1 by Jeff Doyle and focusing on the comparisons between it and distance vector and link-state protocols. One characteristic of EIGRP that sets it part from other protocols is that updates are "bounded" meaning that they are only sent to the "affected" neighbors. I was trying to find a way to see this behavior in action so I created this summarization scenario.

R4 is in the middle of the star with R3,R5 and R7 at the edges:

R4-R5 = 192.168.45.0/24
R4-R7 = 192.168.47.0/24
R4-R3 = 192.168.34.0/24

R4 is advertising a summary of 192.168.44.0/22 to R3.
If a new link was brought up in the /22 range, R4 will not send an update to R3.

Here it is in action:

R3#debug eigrp packets update
R4#debug eigrp packets update
R5#debug eigrp packets update

R3#sho ip route eigrp
D 192.168.44.0/22 [90/2681856] via 192.168.34.4, 00:02:54, Serial1/1

R7 is off of R4 serial 1/1, R3 is off of R4 serial 1/0:

R4#sho ip eigrp ne
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.47.7 Se1/1 10 00:11:55 75 450 0 8
2 192.168.34.3 Se1/0 13 00:30:39 106 636 0 8
0 192.168.45.5 Se1/2 12 00:32:16 106 636 0 8
R4#

Let's add a new loopback on R5 in the range of the summary:

R5(config)#int lo 1
R5(config-if)#ip address 192.168.46.5 255.255.255.0
R5(config-if)#router eigrp 1
R5(config-router)#network 192.168.46.5 0.0.0.0

*Mar 1 20:02:59.075: EIGRP: Enqueueing UPDATE on Serial1/0 iidbQ un/rely 0/1 serno 8-8
*Mar 1 20:02:59.079: EIGRP: Enqueueing UPDATE on Serial1/0 nbr 192.168.45.4 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 8-8
*Mar 1 20:02:59.087: EIGRP: Sending UPDATE on Serial1/0 nbr 192.168.45.4
*Mar 1 20:02:59.095: AS 1, Flags 0x0, Seq 8/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 8-8
*Mar 1 20:02:59.235: EIGRP: Received UPDATE on Serial1/0 nbr 192.168.45.4
*Mar 1 20:02:59.235: AS 1, Flags 0x0, Seq 26/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

R5 sends an update to R4. R4 only sends it to R7:

*Mar 1 20:02:59.515: EIGRP: Received UPDATE on Serial1/2 nbr 192.168.45.5
*Mar 1 20:02:59.519: AS 1, Flags 0x0, Seq 8/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 20:02:59.563: EIGRP: Enqueueing UPDATE on Serial1/1 iidbQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.567: EIGRP: Enqueueing UPDATE on Serial1/1 nbr 192.168.47.7 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11
*Mar 1 20:02:59.575: EIGRP: Sending UPDATE on Serial1/1 nbr 192.168.47.7
*Mar 1 20:02:59.579: AS 1, Flags 0x0, Seq 24/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.583: EIGRP: Enqueueing UPDATE on Serial1/0 iidbQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.587: EIGRP: Enqueueing UPDATE on Serial1/0 nbr 192.168.34.3 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11
*Mar 1 20:02:59.587: EIGRP: Enqueueing UPDATE on Serial1/2 iidbQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.591: EIGRP: Enqueueing UPDATE on Serial1/2 nbr 192.168.45.5 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11
*Mar 1 20:02:59.591: EIGRP: Sending UPDATE on Serial1/2 nbr 192.168.45.5
*Mar 1 20:02:59.591: AS 1, Flags 0x0, Seq 26/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11

And of course on R3 we see nothing. What's really interesting is we see R4 "Enqueuing" the update but never actually sending it as it does to R5 and R7.

I am still not sure of one thing though. Is this a fundamental characteristic of EIGRP itself or the fact that we are summarizing? I cannot think of another scenario where this "bounded" update scenario would take place without summarization. If you can, please drop a comment.

Routing Loop - Part I

I was reading "Optimal Routing Design" by Cisco Press today and a routing loop scenario was described (chapter 2), but they had it all wrong and screwy and it gave me a routing loop in my brain. So I wanted to actually do a similar scenario some justice. This hopefully will be first part in maybe a series of posts that deal with routing loops, since they can be real buggers.

The Topology:



The Scenario:

R2 is hub with R5 and R6 as OSPF neighbors.
R5 and R6 are also EIGRP neighbors with R7.
R7 is redistributing it's serial interface with R8 into the EIGRP domain.
R5 and R6 are mutually redistributing between OSPF and EIGRP.

If R5 and R6 redistribute OSPF into EIGRP with equal metrics, everything stabilizes, even though you have a suboptimal path. This is because External OSPF (AD=110) is preferred over External EIGRP (AD=170). So whichever device (R5 or R6) redistributes R7's serial network into OSPF first, will keep it's route via EIGRP but the other router will learn it via OSPF.

Let's take a look at R5 and R6 OSPF and EIGRP config (there both the same):

R5#show run | sec router ospf|eigrp
router eigrp 1
redistribute ospf 1 metric 1 1 1 1 1
network 150.100.0.0
no auto-summary
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets
network 150.100.100.0 0.0.0.255 area 0
R5#

This results in the following route entries for 150.100.78.0

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:10:23 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:10:23 ago, via Serial1/0
Route metric is 20, traffic share count is 1

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:01:21 ago
Routing Descriptor Blocks:
150.100.56.7, from 150.100.56.7, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
* 150.100.56.5, from 150.100.56.5, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 76 msec 72 msec 20 msec
2 150.100.56.7 48 msec * 72 msec
R2#

Notice that R5 has learned the route via OSPF and has advertised it back into EIGRP with the same metric that R7 is originally advertising it with. R6 has installed them both. So far it's not impacting anything.

Now let's suppose we had a task that said R7 should prefer R5 to reach the OSPF domain and you must configure the solution on R5. How could we do that? We could adjust the metric when redistributing. Let's do this by increasing the bandwidth metric on R5:

R5(config)#router eigrp 1
R5(config-router)#redistribute ospf 1 metric 2 1 1 1 1

Now let's look at R6's entry:

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 1280002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.5 on FastEthernet0/0, 00:01:37 ago
Routing Descriptor Blocks:
* 150.100.56.5, from 150.100.56.5, 00:01:37 ago, via FastEthernet0/0
Route metric is 1280002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 2 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

Its' pointing back to R5!! Let's look at R5:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 2 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:15:35 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:15:35 ago, via Serial1/0
Route metric is 20, traffic share count is 1

It's still pointing to R2!! Trace from R2:


R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 40 msec 76 msec 16 msec
2 150.100.56.5 96 msec 28 msec 44 msec
3 150.100.100.2 44 msec 36 msec 44 msec
4 * * *
5 * * *
6 * * *

So...how would you fix it?

R5 and R6 should learn this route via EIGRP...but last time I tried you could not alter AD for specific external routes...but you can do it for OSPF.

access-list 78 permit 150.100.78.0 0.0.0.255
router ospf 1
distance 180 0.0.0.0 255.255.255.255 78

Now the OSPF route will never be preffered but we do have failover should R5 or R6 lose its LAN connection. Doing this on one side actually fixes it, but leaves R6 with a suboptimal route. I prefer to do it on both.

Final verification of the solution:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:16 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:16 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:12 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:12 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 44 msec
150.100.100.5 104 msec
150.100.100.6 20 msec
2 150.100.56.7 56 msec * 72 msec
R2#

If you know any other scenarios, please let me know.

Redistribution filtering with distribute list

This command still gets me because of the "out" keyword but here is it how it works. It might help to remember there is no "in" keyword when you filter from a routing process.

Topology:

R1---OSPF---R2---OSPF---R5---EIGRP---R6---EIGRP---R9

R9 has loopback 9.9.9.9
R2 has loopback 2.2.2.2

We will filter these routes during redistribution but allow all others.

Will start by filtering R9's loopback from EIGRP to OSPF. On R5 we create the prefix-list:

R5(config)#ip prefix-list BLOCK9 deny 9.9.9.9/32
R5(config)#ip prefix-list BLOCK9 permit 0.0.0.0/0 le 32

Then we apply it under the OSPF process. I know it looks weird but just remember there is no "in" direction when you filter this way.

R5(config)#router ospf 1
R5(config-router)#distribute-list prefix BLOCK9 out eigrp 1

Lets' check R2, notice we see R6's loopback but not R9's

R2#show ip route | inc E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 6.6.6.6 [110/20] via 150.100.100.5, 00:00:11, Serial1/0.2
O E2 150.100.69.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2
O E2 150.100.56.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2

Now let's do the other direction. First Let's check R9's table:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 2.2.2.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1

Configure R5. remember this blocks FROM ospf process 1:

R5(config)#ip prefix-list BLOCK2 seq 5 deny 2.2.2.2/32
R5(config)#ip prefix-list BLOCK2 seq 10 permit 0.0.0.0/0 le 32
R5(config)#router eigrp 1
R5(config-router)#distribute-list prefix BLOCK2 out ospf 1

The neighbors will resync:

*Mar 1 00:20:38.571: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.100.56.6 (FastEthernet0/0) is resync: route configuration changed

Now check R9 and R2's loopback has been filtered:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1

EIGRP - summarization with leak-map

R7 has three loopbacks:

172.29.17.7/24
172.29.18.7/24
172.29.19.7/24

And it is connected to a few routers including R8. You want R7 to summarize the networks but also advertise a specific route of 172.29.18.0/24 to R8. Here's how:

R7:

access-list 18 permit 172.29.18.0 0.0.0.255
!
route-map LEAK18
match ip address 18
!
int s0/0/0
ip summary-address eigrp 1001 172.29.16.0 255.255.252.0 leak-map LEAK18

Now on R8:

R8#show ip route | in 172
172.29.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.29.16.0/22 [90/20640000] via 150.100.78.7, 00:03:31, Serial0/0/0
D 172.29.18.0/24 [90/20640000] via 150.100.78.7, 00:01:04, Serial0/0/0

Easy, eh?

EIGRP - ip default-network command

I hate this command, I think it's unbelievably ....... But here we go. I am going to show some outputs of each router's route table along the way.

[R4]====[R5]

R4 and R5 have two links between each other.
R5 has a loopback 155.1.5.5 being advertised to R4

Before:

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

155.1.0.0/24 is subnetted, 3 subnets
D 155.1.4.0 [90/2297856] via 155.1.45.4, 00:00:04, Serial1/1
[90/2297856] via 10.0.0.4, 00:00:04, Serial1/0
C 155.1.5.0 is directly connected, Loopback0
C 155.1.45.0 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0

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

155.1.0.0/24 is subnetted, 3 subnets
C 155.1.4.0 is directly connected, Loopback0
D 155.1.5.0 [90/2297856] via 155.1.45.5, 00:07:36, Serial1/1
[90/2297856] via 10.0.0.5, 00:07:36, Serial1/0
C 155.1.45.0 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0

------------------------------------------------------------------

Now on R5 we enter:

R5(config)#ip default-network 155.1.5.0

Notice what this does to R5's route-table. It modifies the first line to read 155.1.0.0/16 and puts a static route with admin distance of 1 pointing to network 155.1.5.0. However this is not enough to pass the default route to R4.

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

155.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
S 155.1.0.0/16 [1/0] via 155.1.5.0
D 155.1.4.0/24 [90/2297856] via 155.1.45.4, 00:01:17, Serial1/1
[90/2297856] via 10.0.0.4, 00:01:17, Serial1/0
C 155.1.5.0/24 is directly connected, Loopback0
C 155.1.45.0/24 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0

R5#show run | inc ip route
ip route 155.1.0.0 255.255.0.0 155.1.5.0
R5#

R4 is the same:

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

155.1.0.0/24 is subnetted, 3 subnets
C 155.1.4.0 is directly connected, Loopback0
D 155.1.5.0 [90/2297856] via 155.1.45.5, 00:10:44, Serial1/1
[90/2297856] via 10.0.0.5, 00:10:44, Serial1/0
C 155.1.45.0 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0

------------------------------------------------------------------

Now we enter another default-network command on R5, this time pointing to a classful network. Notice that the static route now has * next to it which means it is a candidate default route. In fact, the gateway of last resort is now set.

R5# show ip route | begin Gateway
Gateway of last resort is 155.1.5.0 to network 155.1.0.0

* 155.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
S* 155.1.0.0/16 [1/0] via 155.1.5.0
D 155.1.4.0/24 [90/2297856] via 155.1.45.4, 00:03:40, Serial1/1
[90/2297856] via 10.0.0.4, 00:03:40, Serial1/0
C 155.1.5.0/24 is directly connected, Loopback0
C 155.1.45.0/24 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0

This command shows up as default network

R5#show run
(output omitted)
ip default-network 155.1.0.0
ip route 155.1.0.0 255.255.0.0 155.1.5.0

R4 is still the same:

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

155.1.0.0/24 is subnetted, 3 subnets
C 155.1.4.0 is directly connected, Loopback0
D 155.1.5.0 [90/2297856] via 155.1.45.5, 00:13:07, Serial1/1
[90/2297856] via 10.0.0.5, 00:13:07, Serial1/0
C 155.1.45.0 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0

------------------------------------------------------------------

Let's get that puppy over to R4:

R5(config-router)#redistribute static

R4#show ip route | begin Gateway
Gateway of last resort is 155.1.45.5 to network 155.1.0.0

155.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
D*EX 155.1.0.0/16 [170/2297856] via 155.1.45.5, 00:05:01, Serial1/1
[170/2297856] via 10.0.0.5, 00:05:01, Serial1/0
C 155.1.4.0/24 is directly connected, Loopback0
D 155.1.5.0/24 [90/2297856] via 155.1.45.5, 00:22:36, Serial1/1
[90/2297856] via 10.0.0.5, 00:22:36, Serial1/0
C 155.1.45.0/24 is directly connected, Serial1/1
C 10.0.0.0/8 is directly connected, Serial1/0
R4#

Basically you need to remember that the default-network needs a classful address in order to mark the route as a candidate default. Then you must redistribute it in order to advertise it.

I don't understand why you would want to use this command. Maybe someone else can chime in?

EIGRP - Tuning Convergence Times

Unlike OSPF, EIGRP hello and hold timers (hold timer is like dead timer in ospf) do not have to match between neighbors. It would make sense that if you want fast convergence in one direction you would want it the other direction as well. However, for this example, we are going to tune convergence one way.

The Network:

R1----FR----R2
|-----R3-----|

R1-R2 are connected via frame relay on 12.0.0.0/8
R1-R3 = 13.0.0.0/8
R2-R3 = 23.0.0.0/8

Each router has a loopback advertised into EIGRP. We are testing from R2's loopback 2.2.2.2 to R1's 1.1.1.1. Eigrp hello/hold timers on frame-relay interfaces are 60 and 180 seconds respectively. This means for traffic from R2 to R1 to failover and use R3 it would take 3 minutes to failover!

That would look like this:

R2#ping 1.1.1.1 source 2.2.2.2 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!................................

You get the idea.

Let's adjust the timers on R1's frame-relay interface, in this case serial 1/2:

R1(config)#int s1/2
R1(config-if)#ip hello-interval eigrp 1 5
R1(config-if)#ip hold-time eigrp 1 15

If we shut down R1's s1/2 interface it should take R2 15 seconds to realize R1 is down and switch over to R3's path to 1.1.1.1.

Let's try it out:

R2#ping 1.1.1.1 source 2.2.2.2 repeat 500

Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

switch to R1:

R1(config)#int s1/2
R1(config-if)#shut

Back to R2:

......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 98 percent (493/500), round-trip min/avg/max = 4/32/112 ms

As you can see, this was much faster than the default timers and we only lost 7 pings.

EIGRP - Automatic Summarization

I dont like auto-summarization, especially since you can always manual summarize networks as you please in EIGRP. But it seems to be enabled by default in all the IOS versions I use and it's probably a good idea to know how it works for the lab.

EIGRP auto-summarizes at classful network boundaries. This means that if one interface is in 1.1.0.0/16 and another interface is in 2.2.2.0/24 then EIGRP will summarize the networks before advertising them out of the opposite interface. This is because each subnet belongs to a separate major classful network: 1.0.0.0/8 and 2.0.0.0/8 in this case.

However if you have one interface in 2.2.2.0/24 and another interface in 2.3.0.0 then auto-summarization will not take affect because both interfaces belong to the major network 2.0.0.0/8. EIGRP may auto-summarize for some networks and not others in the same EIGRP process. Here we take a look:

[R1]----[R2]

R1 and R2 are connected to the same LAN 12.0.0.0/16

R1 has two loopbacks:

R1#show run | section interface Loopback
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface Loopback1
ip address 12.1.1.1 255.255.255.0

R2 also has two loopbacks:

R2#show run | section interface Loopback
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface Loopback1
ip address 12.2.2.2 255.255.255.0

All interface have EIGRP enabled with auto-summary on (default).

R1's route table:

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

1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.1/32 is directly connected, Loopback0
D 1.0.0.0/8 is a summary, 00:09:40, Null0
D 2.0.0.0/8 [90/156160] via 12.0.0.2, 00:09:34, FastEthernet0/0
12.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
D 12.2.2.0/24 [90/156160] via 12.0.0.2, 00:09:43, FastEthernet0/0
C 12.1.1.0/24 is directly connected, Loopback1
C 12.0.0.0/16 is directly connected, FastEthernet0/0
D 12.0.0.0/8 is a summary, 00:09:40, Null0

R2's route table:

R2#show ip route | begin Gate
Gateway of last resort is not set

D 1.0.0.0/8 [90/156160] via 12.0.0.1, 00:19:01, FastEthernet0/0
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.2/32 is directly connected, Loopback0
D 2.0.0.0/8 is a summary, 00:18:55, Null0
12.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C 12.2.2.0/24 is directly connected, Loopback1
D 12.1.1.0/24 [90/156160] via 12.0.0.1, 00:00:02, FastEthernet0/0
C 12.0.0.0/16 is directly connected, FastEthernet0/0
D 12.0.0.0/8 is a summary, 00:18:55, Null0
R2#

Analysis:

Looking at R1's route table you can see that R2 has summarized the route 2.2.2.2/32 into 2.0.0.0/8. This is because R2 sits in the boundary between two classful networks 12.0.0.0 and 2.0.0.0. It does not summarize loopback 1 which is 12.2.2.0/24. This shows up on R1 with the 24 bit mask.

On R2 the same can be said for routes from R1. R1 summarizes it's loopback0 interface into 1.0.0.0/8 because it sits on the boundary between 1.0.0.0 and 12.0.0.0. It does not summarize 12.1.1.1/24.

RIP version 2 auto-summarization works pretty much the same way as far as I can tell. If you know any differences please let me know.