- Cisco Networking: Changing the Routing Protocol in Your Network

Selecting the right IP routing protocol is one of the most important decisions in the network design phase. But even after careful consideration of all facts known to you at that time, you might get it wrong and have to change the routing protocol after the network has been deployed. In this article, I’ll give you some suggestions on how to do that in a moderately complex network.

There might be a number of reasons that would force you to change the routing protocol (I’m assuming you’re not one of those unhappy people who have decided their network is small enough to use RIP):

If you’ve decided to go with EIGRP, you might be forced to switch to OSPF to be able to integrate equipment from multiple vendors in your network or to deploy MPLS traffic engineering.

If you’ve chosen OSPF and have a large network that cannot use route summarization, IS-IS might be a better choice, as its implementation in Cisco IOS scales better in very large networks.

You might have chosen IS-IS, but discovered that although it’s a standard routing protocol, it’s not supported by all the equipment you’d like to integrate into your network.

It’s not Simple

Before giving you a sample blueprint for the routing protocol migration, it’s fair to give you a few warnings. Unless your network has just a few routers, changing the brains of your network (that’s the essential function of the IP routing protocol) is a complex project that requires careful design, project management and expert knowledge. If you don’t have all these ingredients readily available, you’d be best off partnering with a Professional Services organization. But even if you decide to make it on your own, make sure you have:

Thoroughly documented the network structure before the migration (some of the worst nightmares can be caused by unknown backdoor links between sites or undocumented route redistributions).

Prepared a well-understood roll-out plan and a roll-back procedure in case you encounter unexpected complications in the roll-out phase.

Developed test procedures to check the network stability and proper route propagation and IP routing table computation after the migration.

Assuming you did your homework, let’s see how you would change the routing protocol in a network using no summarization and no route redistribution. The individual migration steps are illustrated with diagrams and printouts from a sample network described in the next section.

Sample Network

The sample network that will be migrated from EIGRP to OSPF has four routers, as shown in Figure 1. Each router has two LAN and a WAN interface plus a loopback interface (its IP address is shown in the yellow box overlaying the router).

Figure 1

Topology and IP addressing of the sample network

EIGRP is run on all interfaces. The stub LAN interface is configured as passive to prevent inadvertent EIGRP adjacencies with unauthorized equipment. The EIGRP configuration is common to all routers (Listing 1).

Listing 1

EIGRP configuration on all routers

router eigrp 1

passive-interface FastEthernet0/1

network 0.0.0.0

no auto-summary

The IP routing table computed by EIGRP on router B2 is shown in Listing 2; the EIGRP neighbors of B2 are displayed in Listing 3.

Listing 2

EIGRP-derived IP routing table on B2

b2#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

Gateway of last resort is not set

172.16.0.0 255.255.0.0 is variably subnetted, 6 subnets, 2 masks

D 172.16.0.21 255.255.255.255

[90/156160] via 192.168.0.5, 00:00:06, FastEthernet0/0

C 172.16.0.22 255.255.255.255 is connected, Loopback0

D 172.16.0.12 255.255.255.255

[90/1920000] via 172.16.1.5, 00:01:31, Serial0/0/0.101

D 172.16.0.11 255.255.255.255

[90/1922560] via 192.168.0.5, 00:00:06, FastEthernet0/0

[90/1922560] via 172.16.1.5, 00:00:06, Serial0/0/0.101

C 172.16.1.4 255.255.255.252 is connected, Serial0/0/0.101

D 172.16.1.0 255.255.255.252

[90/1794560] via 192.168.0.5, 00:00:08, FastEthernet0/0

10.0.0.0 255.255.255.0 is subnetted, 5 subnets

D 10.1.3.0 [90/1794560] via 172.16.1.5, 00:00:16, Serial0/0/0.101

D 10.1.2.0 [90/1797120] via 192.168.0.5, 00:00:09, FastEthernet0/0

[90/1797120] via 172.16.1.5, 00:00:09, Serial0/0/0.101

D 10.0.0.0 [90/1794560] via 172.16.1.5, 00:00:09, Serial0/0/0.101

C 10.5.2.0 is connected, FastEthernet0/1

D 10.5.1.0 [90/30720] via 192.168.0.5, 00:00:16, FastEthernet0/0

C 192.168.0.0 255.255.255.0 is connected, FastEthernet0/0

Listing 3

EIGRP neighbors on B2

b2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

1 172.16.1.5 Se0/0/0.101 14 00:05:46 53 318 0 38

0 192.168.0.5 Fa0/0 14 00:05:46 2 200 0 33

Ships in the Night

The first migration step is very simple: deploy the new routing protocol on all routers with a very high administrative distance. Since we’re going from EIGRP to OSPF, you have to design your OSPF areas in advance; replacing EIGRP with a flat single-area OSPF network is not a good idea, unless you have a small stable network. Assuming you did not do any route summarization in EIGRP (and it’s amazing how few people actually use route summarization in EIGRP), you would not need to consider OSPF inter-area summarization in the migration phase, but would be well advised to deploy it in a later stage to further stabilize your network.

Note

When designing OSPF areas, you have to be very careful to establish the correct boundaries of area 0. EIGRP by itself imposes no restrictions on traffic flow (unless you deploy route filters, summarization or stub routers), whereas OSPF does not allow inter-area traffic unless the path goes through area 0 (which you can extend with virtual links).

After you’ve completed the OSPF network design, start deploying OSPF on your routers: configure OSPF routing process, set the administrative distance of OSPF routes above 200 (by default EIGRP external routes have administrative distance of 170) with the distance ospf router configuration command and assign individual IP interfaces to OSPF areas.

Hint

Unless you have a very large number of interfaces on a single router or a very well-designed addressing scheme, it’s easier to assign each individual interface to an OSPF area with the ip ospf id area area-number interface configuration command than using the network statements.

When you’ve completed OSPF configuration on a particular router, check that the expected OSPF neighbors are discovered and that no OSPF routes appear in the IP routing table. OSPF routes might appear in the IP routing table if you forgot to change the OSPF administrative distance (in which case you’d likely encounter an interesting routing loop) or if your EIGRP network used route summarization that you were not aware of (either configured with the ip summary-address eigrp interface configuration command or the default automatic EIGRP summarization between major networks).

Hint

To ensure you don’t make configuration errors, it’s advantageous to have an automatic configuration generation tool.

OSPF Deployment in the Sample Network

When the sample network is migrated from EIGRP to OSPF, we replace the flat EIGRP hierarchy with OSPF areas. All four routers become area border routers and all the transit links are in area 0. The stub LAN interfaces are in individual areas to support future network expansions beyond the original four routers. The OSPF design is shown in Figure 2.

Figure 2

OSPF design

The OSPF configuration is slightly more complex than the original EIGRP configuration due to the introduction of OSPF areas and the decision to use ip ospf area interface configuration commands instead of the network area router configuration commands. The OSPF-related configuration on router B2 is shown in Listing 4.

Listing 4

OSPF configuration on B2

interface Loopback0

ip address 172.16.0.22 255.255.255.255

ip ospf 1 area 0

interface FastEthernet0/0

ip address 192.168.0.6 255.255.255.0

ip ospf 1 area 0

interface FastEthernet0/1

ip address 10.5.2.1 255.255.255.0

ip ospf 1 area 22

interface Serial0/0/0.101 point-to-point

ip address 172.16.1.6 255.255.255.252

ip ospf 1 area 0

router ospf 1

log-adjacency-changes

passive-interface FastEthernet0/1

distance ospf intra-area 200 inter-area 200 external 210

After the OSPF has been configured on B2, B1 and A2, the show ip ospf neighbor command executed on B2 shows the expected neighbors, while the show ip route ospf command displays no routes at all (as expected due to the very high distance of OSPF routes).

Listing 5

OSPF neighbors and routes on B2

b2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

172.16.0.12 0 FULL/- 00:00:36 172.16.1.5 Serial0/0/0.101

172.16.0.21 1 FULL/DR 00:00:38 192.168.0.5 FastEthernet0/0

b2#show ip route ospf

b2#

Check Before You Jump

When you have deployed OSPF throughout your network, check that the OSPF view of the network matches the existing EIGRP view. Perform the following checks on all routers:

Check that the OSPF neighbors match the EIGRP neighbors.

Check that there are still no OSPF routes in the IP routing table.

Inspect the OSPF database on all routers and verify that it contains all the prefixes that are present in the IP routing table.

These checks are almost impossible to do manually; if you want to do them thoroughly, you have to prepare an automatic testing tool before the migration (or you might just trust your skills and jump into the next phase hoping for the best).

If you check the OSPF and EIGRP neighbors on the router A1 in our sample network, you see that the interface IP addresses (column Address) of the show ip ospf neighbor printout match the neighbor addresses of the show ip eigrp neighbor printout. Obviously we’ve configured OSPF correctly on all the transit interfaces, as the neighbors are identical (Listing 6).

Listing 6

OSPF and EIGRP neighbors on A1

a1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

172.16.0.12 1 FULL/DR 00:00:31 10.0.0.6 FastEthernet0/0

172.16.0.21 0 FULL/ - 00:00:35 172.16.1.2 Serial0/0/0.100

a1#show ip eigrp neighbor

IP-EIGRP neighbors for process 1

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

1 172.16.1.2 Se0/0/0.100 11 00:19:59 54 324 0 34

0 10.0.0.6 Fa0/0 13 00:20:48 2 200 0 39

The next check should verify the lack of OSPF routes in the IP routing table. The show ip route ospf command should display no routes (Listing 7).

Listing 7

OSPF routes in the IP routing table on A1

a1#show ip route ospf

a1#

The traditional check of the OSPF database is beyond the abilities of any network operator of average patience; you’d have to dump all the LSAs in the OSPF database (using the detailed dump format to get all connected IP prefixes from the router LSAs), collect the IP prefixes from them and check them against the IP routing table. IOS release 12.4(15)T made the process significantly simpler with the OSPF Local RIB feature – whenever Shortest Path First (SPF) algorithm is run, the results are stored in an OSPF-specific IP routing table (Routing Information Base; RIB) and only then merged with the main IP routing table. The full OSPF local RIB is configured with the local-rib-criteria router configuration command and inspected with the show ip ospf id rib command. Executing this command on A1 shows all the OSPF routes and their next hops (Listing 8); this information is now easily compared with the main IP routing table shown in Listing 9 (although you’d still need a script to do the comparison in a larger network).

Hint

If you’re using an older IOS release, you could use an OSPF-specific trick to inspect the OSPF topology database: if your router is already an area border router (ABR) or resides in area 0, configure a bogus area on it and inspect the network link states in that area with the show ip ospf id area database summary command.

Listing 8

OSPF local RIB on A1

a1#show ip ospf 1 rib

OSPF local RIB for Process 1

Codes: * - Best, > - Installed in global RIB

* 10.0.0.0/24, Intra, cost 1, area 0, Connected

via 10.0.0.5, FastEthernet0/0

* 10.1.2.0/24, Intra, cost 1, area 11, Connected

via 10.1.2.1, FastEthernet0/1

* 10.1.3.0/24, Inter, cost 2, area 0

via 10.0.0.6, FastEthernet0/0

* 10.5.1.0/24, Inter, cost 51, area 0