Then, after executing the SPF calculation, the router needs to find out if there are dependent routes. The route resolver determines if a change of the IS-IS-supplied topology and routes also results in a change of dependent routes. Routing protocols like BGP rely on a working IGP to map the reachability information to a topology in order to calculate the path cost properly. Finally, after the affected dependent routes have been determined, the router proceeds to the third stage, which is prefix insertion. At the prefix insertion stage the router inserts, deletes or changes prefixes of all address families (IPv4, IPv6) and their corresponding Next-hops, then downloads the new forwarding tables to the line-cards and ASICs of the packet forwarding complex of the router. The next sections explore all three elements both from a theoretical and practical per- spective. At the end of each section performance considerations for the network designer are highlighted. 10.2 The SPF Algorithm The Shortest Path First algorithm was invented and first documented by Edser Dijkstra, a Dutch mathematician who was researching the topic of graph theory and looking for an algorithm to determine the shortest spanning distance between two points on a graph. The SPF algorithm is perhaps one of the best-analyzed algorithms in computer science, and its scaling properties are well understood. There are many resources available on the Internet that explain and illustrate how the SPF algorithm works. A good tutorial to learn more about the algorithm, even running through an animated SPF calculation, can be found at http://www.tutor.ms.unimelb.edu.au/dijkstra/dijkstra.html Briefly, SPF is based on a database of node-to-node costs and, using three lists, the SPF algorithm can determine the shortest path to all nodes in N steps, where N is the number of nodes in the network. 10.2.1 Working Principle The SPF algorithm maintains three lists: • UNKNOWN • TENTative • PATHs All nodes currently in the link-state database are first moved to the UNKNOWN list. The node currently being evaluating is placed on the TENTative list, and the local router executing the SPF calculation puts itself on the TENTative list. The TENTative list consists of triplets in the form of neighbour, neighbours-cost and cost to root (the router running SPF). Once SPF determines the best path (lowest cost back to the root) to a node, the node is moved to the PATHs list. The PATHs list sometimes is called the Known list. 248 10. SPF and Route Calculation The list of explored PATHS starts at zero. Next, a loop of at most N steps starts, where N is the number of nodes in the link-state database. Each loop through the algorithm has these steps: 1. Find the node with the lowest cost and move it into PATHs 2. Find all neighbours reachable from that node and move the neighbours from UNKNOWN into TENTative, but … 3. Before a node is moved from UNKNOWN into TENTative, apply a two-way check. If Node A claims that it can see Node B, re-verify that Node B also reports to see Node A. If not, ignore that adjacency. 4. For each node that moves onto the TENTative list, maintain the cost to get there and store the first-hop information. The first-hop is needed for populating the routing-table with routes when SPF is done. The forwarding-engine of a router thinks only in terms of prefixes and directly connected next-hops (the first-hop). 10.2.2 Example The SPF algorithm can be very abstract. Consider the sample topology shown in Figure 10.2. For a better illustration of SPF calculation, we will do an SPF calculation The SPF Algorithm 249 UNKNOWN List Area 49.0001 Level 2-only oc192/STM-64 87000 oc12/STM-4 600000 oc192/STM-64 250000 oc768/STM-256 22000 oc768/STM-256 22000 oc48/STM-16 315000 oc48/STM-16 315000 oc192/STM-64 26000 315000 Pennsauken-ϾLondon Pennsauken-ϾFrankfurt Pennsauken-ϾNew York 315000 26000 315000 London-ϾPennsauken London-ϾFrankfurt 22000 Frankfurt-ϾLondon 22000 Frankfurt-ϾPennsauken 315000 Frankfurt-ϾWashington D.C. 250000 Frankfurt-ϾParis 87000 Paris-ϾFrankfurt 87000 Paris-ϾWashington D.C. 600000 Washington D.C ϾParis 600000 Washington D.C ϾFrankfurt 250000 Washington D.C ϾNew York 22000 New York-ϾWashington D.C. 22000 New York-ϾPennsauken 26000 TENTative List LSDB entry cost cost to root empty 0 0 PATH List empty - 0 Destination via cost to root Pennsauken Frankfurt London Washington New York Paris FIGURE 10.2. At initialization all information in the LSDB is moved on the UNKNOWN list just as a router in this sample topology would, in this example, the Pennsauken router. The figure shows all the Level-2 routers and eight links to connect them. Those links have speeds varying from OC-12/STM-4 (622Mbit/s) up to OC-768/STM-256 (40Gbit/s). The link cost has been assigned on a composite bandwidth/cost scheme. (Those bandwidth-to-IGP cost values are taken from Figure 12.10 in Chapter 12 “IP Reachability Information.”) The full link-state database consists of six routers reporting eight links. Due to these eight links, the router holds 8 * 2 ϭ 16 unidirectional link-states in the link-state data- base (LSDB). At the beginning of the SPF calculation, all 16 links are moved, together with their respective cost field, into the UNKNOWN list, as shown in Figure 10.2. Then the list of explored PATHs is cleared and each router performing the SPF calcula- tion puts itself as the first entry into the TENTative list. In our example, we will execute the SPF calculation from Pennsauken’s point of view as illustrated in Figure 10.3. All adjacencies that are reported via Pennsauken are moved into the TENTative list. 250 10. SPF and Route Calculation 87000600000 250000 22000 oc768/STM-256 22000 315000 31500026000 315000Pennsauken-ϾLondon Pennsauken-ϾFrankfurt Pennsauken-ϾNew York 315000 26000 315000London-ϾPennsauken London-ϾFrankfurt 22000 Frankfurt-ϾLondon 22000 Frankfurt-ϾPennsauken 315000 Frankfurt-ϾWashington D.C. 250000 Frankfurt-ϾParis 87000 Paris-ϾFrankfurt 87000 Paris-ϾWashington D.C. 600000 Washington D.C ϾParis 600000 Washington D.C ϾFrankfurt 250000 Washington D.C ϾNew York 22000 New York-ϾWashington D.C. 22000 New York-ϾPennsauken 26000 TENTative List PATH List LSDB entry cost 315000Pennsauken-ϾLondon 315000 Pennsauken-ϾFrankfurt 315000 315000 Pennsauken-ϾNew York 26000 26000 26000 via 2 1 Frankfurt Pennsauken oc192/STM-64 oc48/STM-16 New York oc48/STM-16 London Area 49.0001 Level 2-only oc768/STM-256 Washington oc192/STM-64 oc12/STM-4 oc192/STM-64 Paris UNKNOWN List cost to root Destination New York New York cost to root FIGURE 10.3. New York has the least-cost path to root and is moved onto the PATH list The SPF Algorithm 251 Routers also execute a so-called two-way check. The two-way check verifies that neighbouring nodes are mutually connected on the graph. Routers are required only to announce two-way verified reachability information. However, there are cases where two neighbouring routers believe that they are connected when in fact they are not. Several broken two-way scenarios were presented and illustrated in Chapter 5, “Neighbour- Discovery and Handshaking”. Because of the two-way check requirement, Pennsauken takes a look in the LSDB to see if all its neighbours (New York, London, Frankfurt) have pointers pointing to Pennsauken as well. If all reported adjacencies pass this two-way check, they are purged from the UNKNOWN list. The algorithm now tries to find the best path to the root node (Pennsauken). The least- cost path on the TENTative list is New York with a cost of 26000. Therefore, as indicated in Figure 10.3, New York’s path cost is moved onto the PATH list. As a next step, the algorithm tries to further drill down the best path found so far and load all the immediate successors onto the TENTative list, since traffic obviously has to pass this way. New York only has one immediate successor, which is Washington. In Figure 10.4, the Pensauken router loads all Washington-related LSDBs onto the TENTative list and verifies 87000 600000 250000 22000 22000 315000 315000 26000 London-ϾFrankfurt 22000 Frankfurt-ϾLondon 22000 Frankfurt-ϾWashington D.C. 250000 Frankfurt-ϾParis 87000 Paris-ϾFrankfurt 87000 Paris-ϾWashington D.C. 600000 Washington D.C ϾParis 600000 Washington D.C ϾFrankfurt 250000 Washington D.C ϾNew York 22000 New York-ϾWashington D.C. 22000 TENTative List LSDB entry Cost 315000 Pennsauken-ϾLondon 315000 Pennsauken-ϾFrankfurt 315000 315000 22000 New York-ϾWashington D.C. 48000 PATH List New York 26000 Destination via cost to root Washington D.C 48000 3 4 Pennsauken oc192/STM-64 oc48/STM-16 New York oc48/STM-16 London oc768/STM-256 Area 49.0001 Level 2-only oc768/STM-256 Washington oc192/STM-64 oc12/STM-4 oc192/STM-64 Frankfurt Paris UNKNOWN List Cost to root New York New York FIGURE 10.4. Washington has the least-cost path to root and is moved onto the PATH list each claimed adjacency using the two-way check again. After the two-way check, the entries are deleted from the UNKNOWN list. The link from New York to Washington has a cost of 22000 and the link from the Pennsauken root to New York comes to 26000, which the router already determined. The aggregate path cost therefore is 22000 ϩ 26000 ϭ 48000 which is written into the cost-to-root field. Washington is the shortest path to the root and is therefore moved onto the PATH list. Next, Washington’s successors are explored. In Figure 10.5, the nodes Paris and Frankfurt are moved onto the TENTative list, but only after satisfying the two-way condition. Two- way-check-related LSDB entries are then deleted from the UNKNOWN list. Now, there are two paths to Frankfurt on the TENTative list. One path goes directly and one goes via New York. SPF adds the shortest path by cost, which is via New York. Frankfurt via New York moves onto the PATH list with a cost of 298000. Additionally, the higher cost path to Frankfurt, which is the direct OC-48/STM-16 link, is deleted from the TENTative list. In Figure 10.6, the last step of the SPF calculation is described. The last node that has been put onto the PATH list is Frankfurt. Therefore, all nodes that are reported 252 10. SPF and Route Calculation UNKNOWN List 87000600000 250000 22000 22000 315000 31500026000 London-ϾFrankfurt 22000 Frankfurt-ϾLondon 22000 Frankfurt-ϾWashington D.C. 250000 Frankfurt-ϾParis 87000 Paris-ϾFrankfurt 87000 Paris-ϾWashington D.C. 600000 Washington D.C ϾParis 600000 Washington D.C ϾFrankfurt 250000 TENTative List LSDB entry cost 315000Pennsauken-ϾLondon 315000 Pennsauken-ϾFrankfurt 315000 315000 Washington D.C ϾParis 600000 Washington D.C ϾFrankfurt 250000 648000 298000 PATH List New York 26000 Destination via Washington D.C 48000 Frankfurt 298000 5 6 Pennsauken oc192/STM-64 oc48/STM-16 New York oc48/STM-16 London oc768/STM-256 Area 49.0001 Level 2-only oc768/STM-256 Washington oc192/STM-64 Frankfurt oc12/STM-4 oc192/STM-64 Paris cost to root cost to root New York New York New York FIGURE 10.5. Frankfurt is routed via New York although a direct line exists The SPF Algorithm 253 via Frankfurt are further examined. The two remaining LSDB entries Frankfurt reports are the adjacencies to Paris and London. After passing the two-way check, the two links are moved onto the TENTative list. There are two ways to London: one direct link and one by way of New York to Washington and then to Frankfurt. The direct link has, in spite of the lower bandwidth, precedence in SPF over the indirect path. The direct link has a cost of 315000, which is better than the 320000 of the composite path. Finally, there are two paths to Paris, one by way of New York to Washington to Frankfurt at a cost of 385000, and one via New York to Washington at a cost of 648000. The path through Frankfurt is, due to the lower cost, moved into the PATH list. Finally, there is no further information on the TENTative list, which is the condition that terminates the SPF calculation. Fortunately, the UNKNOWN list is also empty, but it does not necessarily have to be. There could be “stale” LSDB entries on it, which have not yet aged out, but also could list nodes that did not pass the two-way check. Anyway, UNKNOWN List 87000 600000 250000 22000 22000 315000 31500026000 London-ϾFrankfurt 22000 Frankfurt-ϾLondon 22000 Frankfurt-ϾParis 87000 Paris-ϾFrankfurt 87000 TENTative List LSDB entry cost cost to root 315000Pennsauken-ϾLondon 315000 Washington D.C ϾParis 600000 648000 Frankfurt-ϾLondon 22000 Frankfurt-ϾParis 87000 320000 385000 PATHs List New York New York 26000 Destination via cost to root Washington D.C 48000 Frankfurt 298000 London Paris 315000 385000 7 8 9 Pennsauken oc192/STM-64 oc48/STM-16 New York oc48/STM-16 London oc768/STM-256 Area 49.0001 Level 2-only oc768/STM-256 Washington oc192/STM-64 Frankfurt oc12/STM-4 oc192/STM-64 Paris New York New York New York London F IGURE 10.6. If the TENTative list is empty, the SPF calculation is terminated those do no harm, as long as all nodes are reachable. Eventually these “extra” entries will age out of the link-state database. 10.2.3 Pseudonode Processing In the example network topology illustrated in Figure 10.1, there are only real nodes in the network. There is no pseudonode on the topology, because a WAN network typically contains point-to-point links, which do not require pseudonode generation. You can find complete information about pseudonodes, their background, and how to suppress them, in Chapter 7, “Pseudonodes and Designated Routers”. The pseudonode requires special treatment during the SPF calculation. Figure 10.7 shows an example scenario. Amsterdam and Stockholm are connected by two circuits. The first one is a point-to-point circuit and the second one is a broadcast circuit. Both circuits have an IGP cost of 10 assigned. On the left-hand side of the figure, this is represented inside the link- state database. Note that the cost from the non-pseudonode to the pseudonode is the IGP metric that has been assigned to the interface, in this case 10. The cost from the pseudonode to the non-pseudonode is always zero. Figure 10.8 shows an illustration of the SPF run at Amsterdam on this network. The SPF calculation starts with moving all reported adjacencies to the UNKNOWN list. In this small, sample network there are six reported adjacencies between the three nodes. Next the calculating router (Amsterdam) puts all local adjacencies into the TENTative list (1). Both adjacencies pass the two-way check and the links are removed from the UNKNOWN list (2). Next, the Amsterdam router randomly decides to move a node from the TENTative to the PATH list, as both have equal cost. In the example, the Amsterdam.00 to Stockholm.00 element is moved onto the PATH list (3). (We will see later that this random decision was a mistake.) The immediate successors of Stockholm.00, which is now the node under consideration in the PATH list, are moved from the UNKNOWN list onto the TENTative list (4). Stockholm.02 passes the two-way check and its links are removed from the UNKNOWN list (5). Now the Amsterdam router realizes it already has a path to Stockholm.00 with a cost of 10, so this link is discarded (6). As there are no further ele- ments in the UNKNOWN list, the SPF calculation terminates and as a result just one path (the point-to-point link) is used between the two routers. 254 10. SPF and Route Calculation LSDB representation 1010 10 10 10 0 10 10 10 0 Amsterdam.00 Stockholm.00 LAN Stockholm.02 Amsterdam.00 p2p circuit Ethernet Stockholm.00 10 10 0 0 10 10 10 10 10 FIGURE 10.7. Two equal cost paths over a p2p and a broadcast circuit and its representation in the link-state database 255 TENTative List LSDB entry cost cost to root 10 Amsterdam.00-ϾStockholm.00 10 Amsterdam.00-ϾStockholm.02 10 10 PATH List cost to root 10 Unknown List LSDB entry cost Stockholm.00-ϾAmsterdam.00 10 Stockholm.02-ϾStockholm.00 0 Stockholm.00-ϾStockholm.02 0 Stockholm.02-ϾAmsterdam.00 10 Amsterdam.00-ϾStockholm.00 10 Amsterdam.00-ϾStockholm.02 10 1 3 TENTative List LSDB entry cost cost to root 10 Amsterdam.00-ϾStockholm.02 10 10 PATH List LSDB entry via cost to root Stockholm.00 Stockholm.00 10 Unknown List LSDB entry cost Stockholm.02-ϾStockholm.00 0 Stockholm.00-ϾStockholm.02 10 4 Stockholm.00-ϾStockholm.02 LSDB entry via Stockholm.00 Stockholm.00 2 5 6 2 F IGURE 10.8. If the pseudonode is not prioritized on the TENT to PATH mo ve then an equal cost path is lost 256 TENTative List LSDB entry cost cost to root 10 Amsterdam.00-ϾStockholm.00 10 Amsterdam.00-ϾStockholm.02 10 10 PATH List cost to root 10 Unknown List LSDB entry cost Stockholm.00-ϾAmsterdam.00 10 Stockholm.02-ϾStockholm.00 0 Stockholm.00-ϾStockholm.02 0 Stockholm.02-ϾAmsterdam.00 10 Amsterdam.00-ϾStockholm.00 10 Amsterdam.00-ϾStockholm.02 10 1 3 TENTative List LSDB entry cost cost to root PATH List LSDB entry via cost to root 10 Unknown List LSDB entry cost Stockholm.02-ϾStockholm.00 0 Stockholm.00-ϾStockholm.02 10 4 LSDB entry via Stockholm.02 Stockholm.02 10 Amsterdam.00-ϾStockholm.00 10 Stockholm.02 Stockholm.02 Stockholm.02-ϾStockholm.00 0 10 Stockholm.00 Stockholm.00 10 6 2 5 2 Stockholm.00 Stockholm.02 10 7 8 F IGURE 10.9. If the pseudonode is prioritized on the TENT to PATH move then multiple equal cost paths are calculated SPF Calculation Diversity 257 Figure 10.9 illustrates another SPF run, but this time no random decision is made when moving a node from the TENTative list to the PATH list. Steps (1) and (2) are processed exactly as in the previous example. The difference now is that the system prefers the pseudonode (3) when moving an equal cost node from the TENTative to the PATH list. The router knows that the pseudonode will connect to a real node with a cost of zero, and so is a path of interest. Next, the router evaluates immediate successors from Stockholm.02 and puts them onto the TENTative list (4). After passing the two-way check, the links are removed (5). Next, the router evaluates the TENTative list and moves Stockholm.00 onto the PATH list (6). The remaining node in the TENTative list has a cost of 0 to a node (Stockholm.02) that is already on the PATH list. After summing up 0 plus the cost to reach Stockholm.02, it turns out that there is another path at cost 10 to Amsterdam.00 available, and this one moved into the PATH list (7). The TENTative and UNKNOWN lists are empty, which is the terminating condition for the SPF calculation. The result this time is that both paths are available, which is the desired result. The above example has shown that any sane SPF implementation must prioritize the pseudonode when moving it from the TENTative to PATH list. Otherwise, paths in an equal cost multi-path environment get lost. The interesting thing is that the pseudonode prioritization is never mentioned in ISO 10589. Many implementers therefore make this mistake, and years later it is discovered in the field. JUNOS, for example, contained this oversight for 3 years until it was addressed in JUNOS 5.7. The SPF calculation itself has been optimized during the course of networking history. So there are three different kinds of SPF calculations around. The next sections explore them and their particular performance and resource consumption properties. 10.3 SPF Calculation Diversity There are two passes in the SPF calculation. The purpose of the first pass is to calculate the topological grid in an area. This tries to determine which routers are connected to each other. In the first pass, any prefix information is considered to be irrelevant for the structure of the grid and hence is disregarded. The router does its calculation of the topo logical grid purely on the information found in the IS Reachability and/or the Extended IS Reachability TLVs that are contained in each router’s LSPs. In the previous section, this first pass was described in great detail. In the second pass, all the leaf information is extracted. The router tries to find out if a given node speaks the correct Network Layer protocol. Each Network Layer protocol has to perform a leaf calculation. For instance, if a router does not speak IPv4, its IPv4- related TLVs (128,130,135), are completely disregarded during the second pass leaf calcu- lation. At worst, an IS-IS router needs to calculate prefixes for three distinct address families (IPv4, IPv6 and CLNS). However, it is uncommon to run all three address proto- cols in an area. The most typical deployments are two protocols (IPv4 and IPv6 or IPv4 and CLNS) together in an area. In most SPF implementations of the IS-IS protocol the terms full SPF run and partial SPF run are used, which are different names for the first pass and the second pass, or leaf extraction. . moves onto the TENTative list, maintain the cost to get there and store the first-hop information. The first-hop is needed for populating the routing- table with routes when SPF is done. The forwarding-engine. 648000. The path through Frankfurt is, due to the lower cost, moved into the PATH list. Finally, there is no further information on the TENTative list, which is the condition that terminates the. inside the link- state database. Note that the cost from the non-pseudonode to the pseudonode is the IGP metric that has been assigned to the interface, in this case 10. The cost from the pseudonode to