Posted by: Mudassir Ali | June 18, 2010

Changing the Routing Protocol in Your Network

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 PriState 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 PriState 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

via 172.16.1.2, Serial0/0/0.100

* 10.5.2.0/24, Inter, cost 52, area 0

via 10.0.0.6, FastEthernet0/0

via 172.16.1.2, Serial0/0/0.100

* 172.16.0.11/32, Intra, cost 1, area 0, Connected

via 172.16.0.11, Loopback0

* 172.16.0.12/32, Intra, cost 2, area 0

via 10.0.0.6, FastEthernet0/0

* 172.16.0.21/32, Intra, cost 51, area 0

via 172.16.1.2, Serial0/0/0.100

* 172.16.0.22/32, Intra, cost 52, area 0

via 10.0.0.6, FastEthernet0/0

via 172.16.1.2, Serial0/0/0.100

* 172.16.1.0/30, Intra, cost 50, area 0, Connected

via 172.16.1.1, Serial0/0/0.100

* 172.16.1.4/30, Intra, cost 51, area 0

via 10.0.0.6, FastEthernet0/0

* 192.168.0.0/24, Intra, cost 51, area 0

via 172.16.1.2, Serial0/0/0.100

Listing 9

Main routing table on A1

a1#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/1920000] via 172.16.1.2, 00:11:28, Serial0/0/0.100

D 172.16.0.22 255.255.255.255

[90/1922560] via 172.16.1.2, 00:00:43, Serial0/0/0.100

[90/1922560] via 10.0.0.6, 00:00:43, FastEthernet0/0

D 172.16.0.12 255.255.255.255

[90/156160] via 10.0.0.6, 00:11:53, FastEthernet0/0

C 172.16.0.11 255.255.255.255 is connected, Loopback0

D 172.16.1.4 255.255.255.252

[90/1794560] via 10.0.0.6, 00:00:54, FastEthernet0/0

C 172.16.1.0 255.255.255.252 is connected, Serial0/0/0.100

10.0.0.0 255.255.255.0 is subnetted, 5 subnets

D 10.1.3.0 [90/30720] via 10.0.0.6, 00:11:55, FastEthernet0/0

C 10.1.2.0 is connected, FastEthernet0/1

C 10.0.0.0 is connected, FastEthernet0/0

D 10.5.2.0 [90/1797120] via 172.16.1.2, 00:00:45, Serial0/0/0.100

[90/1797120] via 10.0.0.6, 00:00:45, FastEthernet0/0

D 10.5.1.0 [90/1794560] via 172.16.1.2, 00:11:30, Serial0/0/0.100

D 192.168.0.0 255.255.255.0

[90/1794560] via 172.16.1.2, 00:00:45, Serial0/0/0.100

Slow Removal of the Old Protocol

After you have verified that the new routing protocol runs between all routers in your network and produces similar results as the old routing protocol, it’s time to start removing the old routing protocol.

Note

If you’re migrating between OSPF and IS-IS, it’s possible to closely match the old and the new network topology (as long as you set the IS-IS costs manually and use long IS-IS metrics), as they are both cost-based link-state routing protocols. Migrating from EIGRP to OSPF or IS-IS might slightly change the routing topology due to different cost calculation algorithms.

The removal of the old routing protocol should be done in small chunks using the following steps:

Select a contiguous set of routers to be migrated. Ensure that the old routing protocol remains in one contiguous piece.

Note

When you’re migrating from OSPF to another routing protocol, it’s best to eliminate OSPF area by area and remove the area 0 last.

Decide on a maintenance window. Prepare the execution and test timeline and decide on the roll-back deadline.

Completely remove the old routing protocol from the selected routers (it’s a single configuration command: no router protocol id).

Wait a few seconds for the routing tables to be adjusted throughout the network.

Check the routing tables on all routers in your network. They should still contain the same IP prefixes as before, but some of them would be derived from the new routing protocol, as they are no longer present in the old one.

Check the end-to-end connectivity between critical points in your network.

If the checks fail and you are not able to troubleshoot the problem before the roll-back deadline, simply revert back to the previous configuration. You might want to store the router configurations in NVRAM (or on an archive server) before the start of the migration process and use configuration rollback feature of Cisco IOS to revert to the pre-migration configuration.

After all the checks have been successfully completed, commit the new router configuration to NVRAM and save it on a central server (if you use one). When the whole network has been successfully migrated and there are no remains of the old routing protocol left, change the administrative distance of the new routing protocol to its default value.

Note

Do not change the administrative distance of the new routing protocol until the migration is finished. Never change the administrative distance of the new routing protocol on routers still running both protocols.

Sample Network Migration

The first migration step in our sample network is the removal of EIGRP from A1. After the EIGRP routing process is eliminated with the no router eigrp 1 network configuration command, the IP routing table contains the same prefixes as before, but they are derived from OSPF now (Listing 10).

Listing 10

IP routing table on A1

a1#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

O 172.16.0.21 255.255.255.255

[200/51] via 172.16.1.2, 00:00:03, Serial0/0/0.100

O 172.16.0.22 255.255.255.255

[200/52] via 172.16.1.2, 00:00:03, Serial0/0/0.100

[200/52] via 10.0.0.6, 00:00:03, FastEthernet0/0

O 172.16.0.12 255.255.255.255

[200/2] via 10.0.0.6, 00:00:03, FastEthernet0/0

C 172.16.0.11 255.255.255.255 is connected, Loopback0

O 172.16.1.4 255.255.255.252

[200/51] via 10.0.0.6, 00:00:04, FastEthernet0/0

C 172.16.1.0 255.255.255.252 is connected, Serial0/0/0.100

10.0.0.0 255.255.255.0 is subnetted, 5 subnets

O IA 10.1.3.0 [200/2] via 10.0.0.6, 00:00:05, FastEthernet0/0

C 10.1.2.0 is connected, FastEthernet0/1

C 10.0.0.0 is connected, FastEthernet0/0

O IA 10.5.2.0 [200/52] via 172.16.1.2, 00:00:05, Serial0/0/0.100

[200/52] via 10.0.0.6, 00:00:05, FastEthernet0/0

O IA 10.5.1.0 [200/51] via 172.16.1.2, 00:00:05, Serial0/0/0.100

O 192.168.0.0 255.255.255.0

[200/51] via 172.16.1.2, 00:00:05, Serial0/0/0.100

To check the successful migration of A1, you should inspect the routing tables on all other routers (an automated script should perform that job in a production network). The IP routing table on B2 shows that the majority of the routes are coming from EIGRP, but the stub interfaces of A1 are now learnt via OSPF (Listing 11).

Listing 11

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:04:31, 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:44:15, Serial0/0/0.101

O 172.16.0.11 255.255.255.255

[200/52] via 192.168.0.5, 00:00:44, FastEthernet0/0

[200/52] via 172.16.1.5, 00:00:44, 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:15:23, 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:42:59, Serial0/0/0.101

O IA 10.1.2.0 [200/52] via 192.168.0.5, 00:00:46, FastEthernet0/0

[200/52] via 172.16.1.5, 00:00:46, Serial0/0/0.101

D 10.0.0.0 [90/1794560] via 172.16.1.5, 00:15:19, 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:04:33, FastEthernet0/0

C 192.168.0.0 255.255.255.0 is connected, FastEthernet0/0

The connectivity tests that are part of your testing suite should test host-to-host connectivity if you’re changing the routing protocol of a mission-critical network. In our sample network, a router-to-router ping will do (Listing 12).

Note

If you decide to do router-to-router pings, perform them between LAN interfaces with the extended ping syntax.

Listing 12

Testing connectivity from B2 to A1

b2#ping a1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.0.11, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/67/88 ms

Why does it Work?

It seems almost impossible that a routing protocol migration could be as seamless as the process described in this article. The basic explanation is simple: as there is no route redistribution involved, there is no chance that a routing loop would be introduced in the network. Nonetheless, let’s examine the potential scenarios. There are four types of potential traffic paths based on the migration status of the ingress and egress router:

Both routers still use the old routing protocol.

Both routers use only the new routing protocol.

The ingress router uses the both routing protocols, the egress one uses only the new one.

The ingress router uses the new routing protocol, the egress one uses both.

The first scenario is obvious; as the routers using the old routing protocol should form a contiguous part of the network, the traffic between these routers follows the old paths (remember: the old protocol has lower administrative distance than the new one).

Both routers use the new routing protocol

If both routers lie in a contiguous part of the network that uses solely the new routing protocol (A to B in Figure 3), it’s obvious that the traffic between them follows the path computed by the new routing protocol; it’s more challenging to figure out what happens if the path between them still uses the old routing protocol (A to Z in Figure 3).

Figure 3

Half-migrated network

As long as the packet traverses the routers that use only the new routing protocol (from A to B), it obviously follows the topology computed by the new protocol. But even when it reaches a router using both protocols (let’s assume it’s E), the route toward the destination (Z) is no longer known to the old routing protocol (as Z is not using it anymore), so the whole network is traversed according to the loop-free topology computed by the new routing protocol.

From Old to New

This scenario is identical to the previous one. Let’s assume the packet travels from F to A. As the route toward A is no longer known by the old routing protocol, all routers involved in packet forwarding use the path computed by the new routing protocol.

From New to Old

This is the only scenario where the path taken by a packet (for example, from A to H) is influenced by both routing protocols. As long as the forwarding routers use only the new routing protocol, the packet is progressing toward the egress router following the topology computed by the new routing protocol. As soon as the packet is received by a router using both routing protocols, it starts following the topology computed by the old protocol. Assuming that the routers using the old routing protocol form a contiguous part of the network, the routing protocol boundary is crossed only once and thus there is no possibility of a permanent routing loop.

Summary

In this article, you’ve seen one potential scenario that would help you change the routing protocol of your network. Although the process itself seems simple enough, it nevertheless requires thorough preparation and planning in larger networks:

The old network topology has to be thoroughly documented (it’s very important to discover all potential backdoor links between sites).

The new routing protocol has to be designed and documented. Configurations changes for all routers should be prepared in advance, if possible using an automatic configuration generation tool.

You should prepare automatic testing tools that would check migration readiness after the new routing protocol is deployed and correct network operation after the old routing protocol is removed from parts of your network.

The whole process should be managed as a mission-critical project.

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Categories

%d bloggers like this: