IPv6 Intro: BGP, OSPF and IPv6...or Maybe Just EIGRP and IPv6, smh

Being a network engineer is kind of like being Sisyphus. Just when you think you you're starting to get to the top of your game, someone moves the target on you. In fact, a writer by the name of Spencer Johnson (M.D.) wrote a book on that subject not quite 20 years ago, and even though I've never read the book, I'd guess that it's at least as relevant today as it was then. Case in point, even though I've used IPv4, OSPF, and EIGRP professionally for years, I don't have a lot of professional experience with IPv6 or BGP. To address that problem, I set up the following network in GNS3 for playing with IPv4 and IPv6 with multiple routing protocols on emulated Cisco 7200 routers:

We have R1, R2 and R3 as routers within an autonomous system, R4 a random (IPv4-only) Internet router and R5 as another (IPv6-only, this time) random Internet router. My intent was to set up BGP peering between R1, R4 and R5, and to have R1, R2 and R3 share routes via OSPF. Sounds easy enough, right?

Hahaha...no.

In a previous lab, we set up OSPFv3 (OSPF for IPv6) on Cisco 3640 routers, so I used those instruction to (try to) set up OSPFv3 on the 7200 routers:
R1(config)#int gig0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
                   ^
% Invalid input detected at '^' marker.

R1(config-if)#ipv6 o?
% Unrecognized command
R1(config-if)#ipv6 ?
IPv6 interface subcommands:
  address             Configure IPv6 address on interface
  authentication      authentication subcommands
...
  multicast           multicast
  nat                 Enable IPv6 NAT on interface
  nd                  IPv6 interface Neighbor Discovery subcommands
  next-hop-self       Configures IP-EIGRP next-hop-self
  policy              Enable IPv6 policy routing
  redirects           Enable sending of ICMP Redirect messages
  rip                 Configure RIP routing protocol
...

Okay...is OSPFv3 not supported on this router? As it turns out, I think it actually is, but I'll save that for another lab.

Edit: no, it's not. I mean, it is, but it isn't. The "hooks" are there to configure OSPFv3 using "ipv6 ospf <process ID>" in global configuration, but you have to have an Advanced IP Services image to run it. The SP Services image I am running isn't licensed for it, because after all, what service provider would run OSPF on their network (answer: every one I've ever worked at), grrr...

For now, I decided to try to set up EIGRP for IPv6 since, 1) it *is* supported on the 7200, and 2) it did not seem to be supported on the 3640's:
R1(config)#int gig0/0
R1(config-if)#ipv6 router eigrp 10
R1(config-rtr)#int gig1/0
R1(config-if)#ipv6 router eigrp 10
R1(config-rtr)#exit
R1(config)#exit
R1#sho run int gig0/0
Building configuration...

Current configuration : 201 bytes
!
interface GigabitEthernet0/0
ip address 66.223.227.5 255.255.255.252
duplex full
speed 1000
media-type gbic
negotiation auto
ipv6 address 2001:C0:FFEE:2::1/126
ipv6 enable
ipv6 eigrp 10
end
R1#sho ipv6 route
IPv6 Routing Table - Default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       M - MIPv6, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
C   2001:C0:FFEE::/126 [0/0]
     via GigabitEthernet1/0, directly connected
L   2001:C0:FFEE::1/128 [0/0]
     via GigabitEthernet1/0, receive
C   2001:C0:FFEE:2::/126 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:C0:FFEE:2::1/128 [0/0]
     via GigabitEthernet0/0, receive
LC  2001:C0:FFEE:254::1/128 [0/0]
     via Loopback0, receive
C   2016:FA:1::/64 [0/0]
     via FastEthernet6/0.20, directly connected
L   2016:FA:1::1/128 [0/0]
     via FastEthernet6/0.20, receive
L   FF00::/8 [0/0]
     via Null0, receive
R1#

Weird...why are none of my EIGRP routes showing up? I could ping across the interfaces and my IPv4 routing protocols were working as expected, but I could not get EIGRP in IPv6 to form neighbor adjacencies. What gives?

I started troubleshooting EIGRP using essentially the same toolkit I would use for IPv4...:
R1#sho ipv6 eigrp 10 neigh
IPv6-EIGRP neighbors for process 10
% EIGRP 10 is in SHUTDOWN
R1#sho ipv6 eigrp 10 int
IPv6-EIGRP interfaces for process 10
% EIGRP 10 is in SHUTDOWN
R1#

"EIGRP...is in SHUTDOWN?" I'm not familiar with that error message. WWGS ("What Would Google Say")? I quickly found a couple of tutorials on-line which showed that setting up EIGRP in IPv6 on a 7200 is a little different than setting OSPFv3 on a 3640 (go figure). Whereas OSPFv3 on a 3640 is entirely configured on the interface, EIGRP for IPv6 is a mix of interface-level commands and global config commands:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ipv6 router eigrp 10
R1(config-rtr)#router-id 10.254.254.1
R1(config-rtr)#redistribute connected
R1(config-rtr)#passive-int default
R1(config-rtr)#no passive-int gig0/0
R1(config-rtr)#no passive-int gig1/0
R1(config-rtr)#no shut
02:35:27: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::C802:7FF:FE00:70 (GigabitEthernet1/0) is up: new adjacency
R1(config-rtr)#
02:35:38: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::C801:6FF:FEF0:70 (GigabitEthernet0/0) is up: new adjacency
R1(config-rtr)#exit
R1(config)#exit

After making eseentially the same changes on R2 and R3 (the interface names were different, but...), I saw my routes as expected:
R1#sho ipv6 route
IPv6 Routing Table - Default - 12 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       M - MIPv6, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
C   2001:C0:FFEE::/126 [0/0]
     via GigabitEthernet1/0, directly connected
L   2001:C0:FFEE::1/128 [0/0]
     via GigabitEthernet1/0, receive
C   2001:C0:FFEE:2::/126 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:C0:FFEE:2::1/128 [0/0]
     via GigabitEthernet0/0, receive
D   2001:C0:FFEE:3::/64 [90/28416]
     via FE80::C802:7FF:FE00:70, GigabitEthernet1/0
LC  2001:C0:FFEE:254::1/128 [0/0]
     via Loopback0, receive
D   2001:C0:FFEE:254::2/128 [90/130816]
     via FE80::C801:6FF:FEF0:70, GigabitEthernet0/0
D   2001:C0:FFEE:254::3/128 [90/130816]
     via FE80::C802:7FF:FE00:70, GigabitEthernet1/0
D   2001:C0:FFEE:2222::/64 [90/28416]
     via FE80::C801:6FF:FEF0:70, GigabitEthernet0/0
C   2016:FA:1::/64 [0/0]
     via FastEthernet6/0.20, directly connected
L   2016:FA:1::1/128 [0/0]
     via FastEthernet6/0.20, receive
L   FF00::/8 [0/0]
     via Null0, receive
R1#

Well that was more cumbersome than it should have been, but <shrug>. At least we've got EIGRP working now. BGP via IPv4 is nothing new, so I won't waste a lot of time discussing the BGP configuration for R1-R4. However, the IPv6 configuration between R1 and R5 had me swearing at Cisco:
R1(config)#router bgp 65511
R1(config-router)# neighbor 2016:FA:1::5 remote-as 65515
R1(config-router)# address-family ipv6
R1(config-router-af)#  network 2001:C0:FFEE:254:0:0:0:1/128
R1(config-router-af)#  network 2001:C0:FFEE:254:0:0:0:2/128
R1(config-router-af)#  network 2001:C0:FFEE:254:0:0:0:3/128
R1(config-router-af)#  network 2001:C0:FFEE:2:0:0:0:0/126
R1(config-router-af)#  network 2001:C0:FFEE:0:0:0:0:0/126
R1(config-router-af)#  network 2001:C0:FFEE:2222:0:0:0:0/64
R1(config-router-af)#  network 2001:C0:FFEE:3:0:0:0:0/64
R1(config-router-af)#  neighbor 2016:FA:1::5 activate
% BGP context not been initialized properly.
R1(config-router-af)# exit
R1(config-router)#exit
R1(config)#exit
R1#sho bgp ipv6 unicast neighbors

R1#sho run | begin router bgp
router bgp 65511
bgp router-id 10.254.254.1
bgp log-neighbor-changes
neighbor 2016:FA:1::5 remote-as 65515
neighbor 209.193.4.4 remote-as 65514
!
address-family ipv4
  neighbor 209.193.4.4 activate
  no auto-summary
  no synchronization
  network 10.254.254.1 mask 255.255.255.255
  network 10.254.254.2 mask 255.255.255.255
  network 10.254.254.3 mask 255.255.255.255
  network 66.223.224.0 mask 255.255.255.224
  network 66.223.224.32 mask 255.255.255.224
  network 66.223.227.0 mask 255.255.255.252
  network 66.223.227.4 mask 255.255.255.252
  network 209.193.4.0
exit-address-family
!
ip forward-protocol nd
...

Wait, where's my "address-family ipv6" entries, and what's with that "BGP context has not been initialized properly" error message? I went back to the Great Oracle of Google, where I found this little tidbit of information:
Q. Error message: "% BGP context not been initialized properly." when Configuring neighbor under address-family IPv6

A. The issue is with the feature set. If the feature set is SP services, the following services are not supported.

• IPv6 Routing: Multiprotocol BGP Extensions for IPv6
• IPv6 Routing: Multiprotocol BGP Link-local Address Peering

To use these features,change the feature set to Advanced Enterprise Services.

Okay, let's check the code version on my routers:
R1#sho ver
Cisco IOS Software, 7200 Software (C7200-SPSERVICESK9-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)

Well, <expletive deleted>! Since I don't have an Advanced IP Services image laying around, that pretty much kills the BGP portion of this lab for now.

I went ahead and removed the BGP portion and played with EIGRP across the network, but I'm slightly miffed by the fact that I couldn't do any testing with BGP or OSPF under IPv6, since IPv6 is now a part of certification testing. With adoption of IPv6 "in the wild" still lagging, it would be nice to be able to mock such networks up in a lab without spending a fortune in hardware and software licensing.

Cisco Routing Oddities -- Interaction Between EIGRP, Distribute-List, and Static Routes

I ran into something at work today that I didn't quite understand, and which I finally had to mock up in GNS-3 to figure out. While trying to track down a routing problem, I found a distribute-list statement on an EIGRP configuration that referenced an access list which denied anything from 10.0.0.0/8. That's not terribly unusual, except that it looked like there were still a lot of 10-dot subnets being propagated by EIGRP on this router. Digging into the configuration a bit more, I saw that there was a "redistribute static" command inside the EIGRP configuration, and I found several static routes to 10-dot subnets. To understand the interaction between EIGRP, static routes, and the "distribute-list" statement, I created the following, simple network in GNS-3:



In this network, R1, R3, R4 and R5 will all use EIGRP to share routes with each other. R2 will have a default route pointing to R1, and R1 will have a single static route to R2's loopback address:
R1(config)#ip route 10.254.254.0 255.255.255.0 10.0.0.2
R1(config)#router eigrp 10
R1(config-router)#redistribute static metric 1000000 1 255 1 1500

After turning up EIGRP, R1 shared all of its known routes with R3, R4 and R5, exactly as you would expect:
R2#ping 100.64.254.1
Sending 5, 100-byte ICMP Echos to 100.64.254.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
R2#

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

R3#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/17/44 ms
R3#

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

R4#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/29/72 ms
R4#

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

R5#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/27/44 ms
R5#

Then, I added the following configuration statements to R1:
R1(config)#ip access-list standard FILTER-NULL-ROUTES
R1(config-std-nacl)#deny 10.0.0.0
R1(config-std-nacl)#permit any
R1(config-std-nacl)#!
R1(config-std-nacl)#router eigrp 10
R1(config-router)#distribute-list FILTER-NULL-ROUTES out
R1(config-router)#!

Running the exact same ping tests...:
R2#ping 100.64.254.1
Sending 5, 100-byte ICMP Echos to 100.64.254.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/40 ms
R2#

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

R3#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#

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

R4#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R4#

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

R5#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#

This is to be expected -- 10.0.0.0/30 is a control to verify that the distribute-list is working as expected (that is, that it is filtering 10.0.0.0/8 from the EIGRP updates). Let's see if the distribute-list overrides the static route, or if the static route overrides the distribute-list:
R3#ping 10.254.254.9
Sending 5, 100-byte ICMP Echos to 10.254.254.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/23/40 ms
R3#

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

R4#ping 10.254.254.9
Sending 5, 100-byte ICMP Echos to 10.254.254.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/72 ms
R4#

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

R5#ping 10.254.254.9
Sending 5, 100-byte ICMP Echos to 10.254.254.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/48 ms
R5#

Notice how we can still reach 10.254.254.9, even though we can no longer reach 10.0.0.2? The distribute-list is filtering 10.0.0.0/8 addresses from the EIGRP routing updates sent by R1. However, we have explicitly stated that we want static routes to be redistributed by EIGRP, and we have a static route for 10.254.254.0/24 via 10.0.0.2. Consequently, R1 is still advertising a route for 10.254.254.9, despite the distribute-list filter. This explains how my router at work was still sharing 10-dot routes with other routers in its EIGRP area, even though there was a distribute-list statement filtering 10-dot subnets.

Advanced Cisco Routing: Summary Addresses

So this probably isn't really an advanced routing topic, but it's not something I ran into while working on my CCNA, either...

Anyway.

Consider the following network:


On the left, we have our server farm (okay, it's a rather small data center). On the right, we have our desktop users (see previous comment, lol). Because we actually engineer our network, we have divided our network up into logical units, each on its own subnet. R2, R3 and R4 are department routers, each hosting a subnet -- say, 192.168.2.0/24 for R2, 192.168.3.0/24 for R3 and 192.168.4.0/24 for R4. R5 is the data center router, and all of the hosts in the data center are on the 172.16.0.0/24 subnet. R1 is our dist router, and uses 192.168.1.x/30 for each of its links to R2, R3 and R4, as well as using 10.0.0.0/30 for the link to R5. IRL, we should probably be using another 192.168.1.x/30 subnet for the R1 -- R5 link, but I'm actually treating R5 as both an edge and dist router here. I've enabled EIGRP on all five routers.

By default, EIGRP will try to summarize all of the routes by class; i.e., networks from 0.0.0.0 to 127.255.255.255 will be Class-A networks, networks from 128.0.0.0 through 191.255.255.255 will be Class-B networks, and networks from 192.0.0.0 through 223.255.255.255 will be Class-C network, no matter how you've actually subnetted them.

Modern best-practice, however, is not to do that, as free IPv4 address space is becoming increasingly rare, and therefore, you tend to see Class-A, Class-B and even Class-C networks subnetted into smaller blocks of IP space, as we've done on R5's LAN, on the link between R1 and R5, and on each of the links between R1 and R2, R3 and R4 here. Consequently, when using EIGRP in modern production networks, you will typically see the command "no auto-summary" somewhere in the EIGRP configuration.

However, on a large production network, this can be really ugly, as you see /30 network after /30 network listed in the "sho ip route" ouptut:
R5#sho ip route
<...snip...>
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Vlan10
D EX 192.168.4.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.254.254.2/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 10.254.254.3/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
C 10.0.0.0/30 is directly connected, FastEthernet1/0
D EX 10.254.254.1/32 [170/156160] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 10.254.254.4/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
C 10.254.254.5/32 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 3 subnets
D 192.168.1.8 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D 192.168.1.0 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D 192.168.1.4 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 192.168.2.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 192.168.3.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
R5#

Notice that there are six 192.168.x.x subnets shown in the output of the "sho ip route" command on this router, and this is a SMALL network, so imagine how it would look on the service-provider network where I work! Not only does it make it more difficult to parse the output of the "sho ip route" command, but EIGRP on R1 has to advertise each of these networks separately to R5, making the update larger than it has to be.

Fortunately, this isn't an all-or-nothing choice. It is possible to have EIGRP summarize some routes, but advertise individual subnets for others. Furthermore, you don't have to summarize into a classful network -- you can use any valid IP subnet to summarize the routes. In the example network shown in this lab, we have 192.168.1.0/30, 192.168.1.4/30, 192.168.1.8/30, 192.168.2.0/24, 192.168.3.0/24 and 192.168.4.0/24 in use. The smallest valid subnet that contains all of these networks would be 192.168.0.0/21 (192.168.0.0 -- 192.168.7.255). If we assume that that IP space is reserved for use by R1 and edge routers hanging off of R1, then we can have R1 summarize the 192.168.x.x subnets into one single route advertisement for this entire range:
R1(config)#int fa0/0
R1(config-if)#ip summary-address eigrp 10 192.168.0.0 255.255.248.0
R1(config-if)#
01:44:20: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.0.0.2 (FastEthernet0/0) is down: summary configured
R1(config-if)#
01:44:23: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.0.0.2 (FastEthernet0/0) is up: new adjacency
R1(config-if)#

Now, if we look at the routes on R5, we will see that, rather than advertising six 192.168.x.x subnets, R1 is only advertising a single /21 that contains each of the previous six subnets:
R5#sho ip route
<...snip...>
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Vlan10
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.254.254.2/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
D EX 10.254.254.3/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
C 10.0.0.0/30 is directly connected, FastEthernet1/0
D EX 10.254.254.1/32 [170/156160] via 10.0.0.1, 00:03:56, FastEthernet1/0
D EX 10.254.254.4/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
C 10.254.254.5/32 is directly connected, Loopback0
D 192.168.0.0/21 [90/30720] via 10.0.0.1, 00:03:55, FastEthernet1/0  <---
R5#

Cool!

Lesson 8 -- Dynamic Routing with EIGRP

Later in the week, your boss calls you to ask about another dynamic routing protocol known as EIGRP. She explains that she read that EIGRP is a Cisco proprietary routing protocol, and since we are using Cisco equipment, wouldn't it be best to use the routing protocol that Cisco designed for their routers? Also, she continues, the article said that EIGRP allows the network admin to configure authentication between routers, which can help keep malicious hackers from injecting bogus routes into your routing tables. You try to tell her that while that's true, you are only sending and receiving route updates across a point-to-point link on a private, leased line -- there's no way for a miscreant to inject a route into your routing tables unless they have physical access to your T1 line, but she tells you that she thinks you should remove OSPF and move to EIGRP, anyway. You roll your eyes (you're on the phone, after all), and agree to give it a try, silently fantasizing about shutting off her Internet access so you can stop reconfiguring your routers every time she reads a new article on-line.

Once again, you log into the main office and branch office routers, remove OSPF and configure EIGRP:

lab2651rtr# conf t
lab2651rtr(config)# no router ospf 2112
lab2651rtr(config)# router eigrp 42
lab2651rtr(config-router)# network 192.168.3.4 0.0.0.3
lab2651rtr(config-router)# redistribute connected
lab2651rtr(config-router)# redistribute static
lab2651rtr(config-router)# no auto-summary
lab2651rtr(config-router)# key chain EIGRP
lab2651rtr(config-keychain)# key 1
lab2651r(config-keychain-key)# key-string +h@nks_4_+he_f!sh
lab2651r(config-keychain-key)# int serial 0/1
lab2651rtr(config-if)# ip authentication mode eigrp 1 md5
lab2651rtr(config-if)# ip authentication key-chain eigrp 1 EIGRP
lab2651rtr(config-if)# exit
lab2651rtr(config)# exit
lab2651rtr#


...and on the branch office router:

lab3640rtr# conf t
lab3640rtr(config)# no router ospf 2112
lab3640rtr(config)# router eigrp 42
lab3640rtr(config-router)# network 192.168.3.4 0.0.0.3
lab3640rtr(config-router)# redistribute connected
lab3640rtr(config-router)# no auto-summary
lab3640rtr(config-router)# key chain EIGRP
lab3640rtr(config-keychain)# key 1
lab3640r(config-keychain-key)# key-string +h@nks_4_+he_f!sh
lab3640r(config-keychain-key)# int serial 0/1
lab3640rtr(config-if)# ip authentication mode eigrp 1 md5
lab3640rtr(config-if)# ip authentication key-chain eigrp 1 EIGRP
lab3640rtr(config-if)# exit
lab3640rtr(config)# exit
lab3640rtr#


Hmmm...EIGRP looks a little more complex, but a lot of the commands look similar to the other routing protocols we've used. Let's discuss the commands in detail:
* First, we tell the router that we want to use EIGRP, just like we did with RIP and OSPF. However, the "42" is not an EIGRP process number, like we saw with OSPF. EIGRP uses "Autonomous Systems" and and they must match between routers that are sharing routes through EIGRP!
* Again, we tell the router what networks to advertise with the "network" statement, very similar to the "network" statements found in RIP and OSPF, but what looks sort of like a subnet mask following the network address is actually a "wildcard mask." Logically, if you convert the subnet mask to binary (in this case, 11111111.11111111.11111111.11111100), then invert the ones and zeros (00000000.00000000.00000000.00000011), then convert back to decimal, that's a "wildcard mask." Or, you can just subtract each octet of the subnet mask from 255, like a normal (i.e., lazy) person ;)
* The "redistribute connected" command is identical to the same command in OSPF.
* The "no auto-summary" command tells EIGRP not to collapse classless subnets into a single classful network address.
* From here on, configuring EIGRP becomes very different from what we've done previously. On the plus side, the authentication configuration is entirely optional -- you don't have to configure authentication if you don't want to, but if you do, here's how you do it. First, we will store the password in a "key chain" (a database of passwords). Since there can be multiple key chains, we have to tell the router which one to use. In this case, we called it, logically enough, "EIGRP." The number we use in the "key" command must match between routers sharing routes through EIGRP. Next, we configure the password to be used by the two routers to authenticate with each other, using the "key-string" command. After that, we have to apply the authentication mechanism to a specific interface, in this case, serial 0/1 on both routers. Inside the interface configuration, we set the authentication mode (authentication is for the EIGRP routing protocol, using key 1, and it will be encrypted with the MD5 algorithm. Finally, we state that we are using key 1 (again) from the EIGRP key chain.

Whew...glad we've got that configured. Make sure the settings match on both routers, or else the routers won't be able to share routes. If anything doesn't match, fix it now, then check your work:

lab2651rtr# sho ip route
<...snip...there are a lot of extra lines of output that aren't needed now...>
Gateway of last resort is 100.64.1.1 to network 0.0.0.0

     100.0.0.0/24 is subnetted, 1 subnets
C     100.64.1.0 is directly connected, FastEthernet0/1
C     192.168.1.0/24 is directly connected, FastEthernet0/0
      192.168.3.0/30 is subnetted, 1 subnets
C     192.168.3.4 is directly connected, Serial0/1
S*     0.0.0.0/0 [1/0] via 100.64.1.1


Wait...what? Where's the 192.168.2.0/24 subnet?

lab2651rtr# sho ip eigrp topology
IP-EIGRP Topology Table for AS(42)/ID(192.168.3.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
     r - reply Status, s - sia Status
P 0.0.0.0/0, 1 successors, FD is 281600
     via Rstatic (281600/0)
P 100.64.1.0/24, 1 successors, FD is 281600
     via Rconnected (281600/0)
P 192.168.1.0/24, 1 successors, FD is 28160
     via Rconnected (28160/0)
P 192.168.3.4/30, 1 successors, FD is 2169856
     via Connected, Serial0/1
lab2651rtr#


The configuration looks good, and on the branch office router, I can see routes shared by the main office router:

lab3640rtr# sho ip route
<...snip...>
Gateway of last resort is 192.168.3.5 to network 0.0.0.0

     100.0.0.0/24 is subnetted, 1 subnets
D EX     100.64.1.0 [170/2195456] via 192.168.3.5, 00:50:24, Serial0/1
D EX 192.168.1.0/24 [170/2172416] via 192.168.3.5, 00:50:24, Serial0/1
     192.168.3.0/30 is subnetted, 1 subnets
C     192.168.3.4 is directly connected, Serial0/1
D*EX 0.0.0.0/0 [170/2195456] via 192.168.3.5, 00:50:21, Serial0/1
lab3640rtr#


That tells me that whatever is wrong, it isn't an EIGRP problem -- routes from the main office router are showing up on the branch office router. You glance at your watch, and suddenly realize what the problem is. It's two hours after quitting time. Everyone at the branch office had gone home for the night, and all their PCs were shut off. With nothing connected to FA0/0 on the branch office router, the interface had gone down, and therefore EIGRP wasn't propagating any routes to the 192.168.2.0/24 subnet. You go home for the night, and check again the next morning. Sure enough, you can see the 192.168.2.0/24 subnet on the main office router's routing tables.