Routing protocol migration

Each routing protocol on a Cisco router is assigned a default administrative distance (AD). The term is something of a misnomer; rather than affecting any metric calculations within a protocol, administrative distances are simply a way to prefer one routing protocol over another. If a router has learned of a route via both OSPF and EIGRP, for example, it will prefer the route learned via EIGRP regardless of its metric because EIGRP has a lower default AD.

Here is the ubiquitous table of default AD values:

These defaults can be modified to any number between 1 and 255. This can be especially handy when migrating from one routing protocol to another. For example, consider migrating a network (or part of a network) from IS-IS to OSPF. By default, routers will begin to follow OSPF routes as soon as they are learned because OSPF has a lower AD than IS-IS. This means that the entire migration would need to be done within a single maintenance window to avoid disruption, which isn't always practical, particularly on large networks.

In such a scenario, the distance command can be used under the new routing protocol to set a higher AD than the current routing protocol, ensuring that routes from the current protocol are always given priority.

R1(config)# router ospf 1
R1(config-router)# distance ?
  <1-255>  Administrative distance
  ospf     OSPF distance

R1(config-router)# distance 250

Some protocols, like OSPF, allow for more granular manipulation of AD by route type:

R1(config-router)# distance ospf ?
  external    External type 5 and type 7 routes
  inter-area  Inter-area routes
  intra-area  Intra-area routes

There's an important point to consider when applying this strategy to a migration: routes may be summarized differently within the new protocol. Any more-specific routes learned via the new protocol will be favored over less-specific routes known via the current protocol, regardless of their administrative distances. How then can you guarantee that deployment of the new protocol won't alter the current, stable routing topology?

The table above indicates that any routes with an AD of 255 will be considered invalid. We can take advantage of this behavior and set the AD of our new protocol to 255. Here's an example topology of IS-IS network being migrated to OSPF, with OSPF an assigned AD of 250:

R1# 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
C       10.11.0.0/16 is directly connected, Loopback11
O IA    10.14.0.0/16 [250/21] via 10.0.13.3, 00:05:13, FastEthernet0/1
                     [250/21] via 10.0.12.2, 00:05:13, FastEthernet0/0
O IA    10.12.0.0/16 [250/11] via 10.0.12.2, 00:05:13, FastEthernet0/0
C       10.0.12.0/24 is directly connected, FastEthernet0/0
O IA    10.13.0.0/16 [250/11] via 10.0.13.3, 00:05:13, FastEthernet0/1
C       10.0.13.0/24 is directly connected, FastEthernet0/1
i L1    10.2.0.0/16 [115/20] via 10.0.12.2, FastEthernet0/0
i L2    10.3.0.0/16 [115/20] via 10.0.13.3, FastEthernet0/1
C       10.1.0.0/16 is directly connected, Loopback1
i L2    10.4.0.0/16 [115/30] via 10.0.13.3, FastEthernet0/1
                    [115/30] via 10.0.12.2, FastEthernet0/0
i L2    10.0.24.0/24 [115/20] via 10.0.12.2, FastEthernet0/0
i L2    10.0.34.0/24 [115/20] via 10.0.13.3, FastEthernet0/1

Note that a number of new routes, not present in IS-IS, have been learned by OSPF (with an AD of 250 versus IS-IS's default AD of 115) and added to the routing table. This can lead to unpredictable and undesired routing. Here's the same table after increasing OSPF's AD to 255:

R1(config)# router ospf 1
R1(config-router)# distance 255
R1(config-router)# ^Z
R1# show ip route
...

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
C       10.11.0.0/16 is directly connected, Loopback11
C       10.0.12.0/24 is directly connected, FastEthernet0/0
C       10.0.13.0/24 is directly connected, FastEthernet0/1
i L1    10.2.0.0/16 [115/20] via 10.0.12.2, FastEthernet0/0
i L2    10.3.0.0/16 [115/20] via 10.0.13.3, FastEthernet0/1
C       10.1.0.0/16 is directly connected, Loopback1
i L2    10.4.0.0/16 [115/30] via 10.0.13.3, FastEthernet0/1
                    [115/30] via 10.0.12.2, FastEthernet0/0
i L2    10.0.24.0/24 [115/20] via 10.0.12.2, FastEthernet0/0
i L2    10.0.34.0/24 [115/20] via 10.0.13.3, FastEthernet0/1

The OSPF-learned routes are gone. This configuration succeeds in protecting our stable routing topology. But if the routes aren't added to the table, how can we verify that OSPF is working correctly at all? By examining the OSPF database, of course:

R1# show ip ospf database

OSPF Router with ID (10.1.0.1) (Process ID 1)

Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.1.0.1        10.1.0.1        663         0x80000006 0x001E73 2
10.2.0.1        10.2.0.1        657         0x80000005 0x003146 2
10.3.0.1        10.3.0.1        652         0x80000005 0x006CEF 2
10.4.0.1        10.4.0.1        545         0x80000007 0x0079C5 2

Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.12.2       10.2.0.1        765         0x80000001 0x00FCFE
10.0.13.3       10.3.0.1        752         0x80000001 0x00E710
10.0.24.4       10.4.0.1        745         0x80000001 0x007078
10.0.34.4       10.4.0.1        746         0x80000001 0x000ECF

Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.11.0.0       10.1.0.1        659         0x80000001 0x0024F6
10.12.0.0       10.2.0.1        653         0x80000001 0x001009
10.13.0.0       10.3.0.1        648         0x80000001 0x00FB1B
10.14.0.0       10.4.0.1        541         0x80000001 0x00E72D

Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.1.0.1        10.1.0.1        664         0x80000001 0x009B68 1

Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.12.0       10.1.0.1        665         0x80000001 0x007E92
10.0.13.0       10.1.0.1        665         0x80000001 0x00739C
10.0.24.0       10.1.0.1        665         0x80000001 0x005E9C
10.0.34.0       10.1.0.1        665         0x80000001 0x00EF01