Changing Route Preferences to Migrate to Another IGP

Problem

You are migrating the IGP on your network from OSPF to IS-IS and you want to do this in a controlled manner.

Solution

After configuring both OSPF and IS-IS on the routers you are migrating, change the route preference on the OSPF routes to be higher than the IS-IS preference:

	[edit protocols ospf]
	aviva@Router3#  
set preference 175

Discussion

While you can change the preference values for all dynamic routing protocols and user-configured routes using the set preference and set external-preference commands when configuring the protocols, it is generally not a good idea. The changes you make affect only the router you are configuring, and the local router will end up with a different idea of relative route preferences than the other routers on the network. Also, changing route preferences could affect which routes become active, which, in turn, would affect which routes are used to forward traffic.

However, one situation where you might want to change route preferences is when migrating IGPs. In this recipe, we are migrating from using OSPF as the IGP to using IS-IS. A preference of 175 for OSPF is greater than that of any IS-IS routes. From Table 8-2, you see that IS-IS internal routes have a preference of either 15 (for Level 1) or 18 (for Level 2), and external routes have a preference of 160 (for Level 1) or 165 (for Level 2).

The command shown in this recipe is actually the last step in an OSPF-to-IS-IS migration strategy. The first step is to configure IS-IS on the same interfaces that are running OSPF (see Recipe 11.1), then verify that IS-IS adjacencies are established on the same interfaces that have OSPF adjacencies:

	aviva@Router3> show isis adjacency
	Interface System L State Hold (secs) SNPA
	so-0/2/0.0 R1 2 Up 20
	so-0/2/1.0 R2 2 Up 21
	so-0/2/2.0 R4 2 Up 19
	so-0/2/3.0 R10 2 Up 19

	aviva@Router3> show ospf neighbor
	 Address Interface State ID Pri Dead
	10.1.2.1 so-0/2/0.0 Full 10.10.255.1 128 36
	10.1.6.1 so-0/2/1.0 Full 10.10.255.2 128 38
	10.1.7.2 so-0/2/2.0 Full 10.10.255.4 128 34
	10.1.8.2 so-0/2/3.0 Full 10.10.255.10 128 38

You then need to ensure that IS-IS calculates the same paths as OSPF. The default IS-IS metrics must be changed so that they give the same relative cost to each path as does OSPF. You can do this by manually assigning appropriate interface metrics or by configuring a reference bandwidth. (See Recipe 11.10 for IS-IS and Recipe 12.11 for OSPF.)

Unlike OSPF, for which the JUNOS software has an automatic costing algorithm based on interface bandwidth, for IS-IS JUNOS software assigns a default metric of 10 to all IS-IS interfaces. If this default is left unchanged, the shortest paths calculated by IS-IS are essentially shortest-hop paths.

With IS-IS enabled and metrics configured correctly, the routing table should have the same number of IS-IS entries as OSPF entries for each destination, and they should point to the same outgoing next hops. That is, if there is one OSPF route to a prefix, there should be one IS-IS route to the same prefix and with the same outgoing interface. If there are two OSPF routes to a prefix, there should be two IS-IS routes, and so on.

	aviva@Router3> show route
	inet.0: 28 destinations, 48 routes (28 active, 0 holddown, 0 hidden)
	Restart Complete
	+ = Active Route, - = Last Active, * = Both
	10.1.1.0/24 *[OSPF/10] 00:16:20, metric 65
	 via so-0/2/0.0
	 > via so-0/2/1.0
	 [IS-IS/18] 00:16:08, metric 126
	 to 10.1.2.1 via so-0/2/0.0
	 > to 10.1.6.1 via so-0/2/1.0
	10.1.3.0/24 *[OSPF/10] 00:16:20, metric 65
	 via so-0/2/0.0
	 > via so-0/2/2.0
	 [IS-IS/18] 00:16:08, metric 126
	 > to 10.1.2.1 via so-0/2/0.0
	 to 10.1.7.2 via so-0/2/2.0
	…

The output shows that for each destination prefix, OSPF and IS-IS have the same number of routes and the same outgoing interfaces. The preferred route for each prefix (marked with an *) is the OSPF route. If there are equal-cost paths, the next hop chosen by OSPF (>) is not always the same as that chosen by IS-IS. This will not cause routing problems as long as the equal-cost paths are consistent between the protocols.

At this point, you change the route preference using the set protocols ospf preference command shown in this recipe. Here, you increase the OSPF preference to a value higher than any of the IS-IS preferences because OSPF is the protocol that you are migrating away from. You could instead change the IS-IS route preference so that its routes are more preferred than OSPF. However, leaving the IS-IS preference at its default value simplifies any future addition of routers to the network. Another alternative at this point would be to delete OSPF from the configuration altogether. However, you should leave it in for a short period of time to test the migration. If there are any problems and you need to back out of the migration, all you need to do is return to the default OSPF preference value:

	[edit protocols ospf]
	aviva@Router3# delete preference
	aviva@Router3# commit

To verify the preference change, look at the routing table to check that IS-IS is the preferred protocol for all the routes:

	aviva@Router3> show route
	inet.0: 28 destinations, 48 routes (28 active, 0 holddown, 0 hidden)
	Restart Complete
	+ = Active Route, - = Last Active, * = Both
	10.1.1.0/24 *[IS-IS/18] 00:32:24, metric 126
	 to 10.1.2.1 via so-0/2/0.0
	 > to 10.1.6.1 via so-0/2/1.0
	 [OSPF/175] 00:01:48, metric 65
	 via so-0/2/0.0
	 > via so-0/2/1.0
	10.1.3.0/24 *[IS-IS/18] 00:32:24, metric 126
	 > to 10.1.2.1 via so-0/2/0.0
	 to 10.1.7.2 via so-0/2/2.0
	 [OSPF/175] 00:01:48, metric 65
	 > via so-0/2/0.0
	 via so-0/2/2.0

When you are sure that IS-IS is working properly, remove the OSPF configuration from the router:

	[edit 
protocols]
	aviva@Router3# delete ospf
	aviva@Router3# commit