1. Trang chủ
  2. » Công Nghệ Thông Tin

The Complete IS-IS Routing Protocol- P27 pdf

10 239 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 10
Dung lượng 205,7 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

10.2.1 Working Principle The SPF algorithm maintains three lists: • TENTative • PATHs All nodes currently in the link-state database are first moved to the UNKNOWN list.. Once SPF determi

Trang 1

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:

• 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.

Trang 2

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

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-New York

315000 26000 315000 London-Pennsauken

TENTative List

LSDB entry cost cost to root

PATH List

Destination via cost to root

Pennsauken

Frankfurt London

Washington

New York

Paris

F 10.2 At initialization all information in the LSDB is moved on the UNKNOWN list

Trang 3

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

87000 600000

250000

22000

oc768/STM-256

22000 315000

315000 26000

315000 Pennsauken- London

Pennsauken- Frankfurt Pennsauken- New York

315000 26000 315000 London- Pennsauken

Frankfurt- Pennsauken 315000 Frankfurt- Washington D.C 250000

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

PATH List

315000

Pennsauken- Frankfurt 315000 315000

26000

via 2

1

Frankfurt

Pennsauken

New York

Area 49.0001 Level 2-only

oc768/STM-256

Washington

oc192/STM-64

Paris

UNKNOWN List

cost to root

Destination

cost to root

F 10.3 New York has the least-cost path to root and is moved onto the PATH list

Trang 4

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

315000

315000 26000

Frankfurt- Washington D.C 250000

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

315000

Pennsauken- Frankfurt 315000 315000

22000

PATH List

3

4

Pennsauken

New York oc48/STM-16 London

Level 2-only

oc768/STM-256

Washington

oc192/STM-64

Frankfurt

Paris

UNKNOWN List

Cost to root

New York New York

F 10.4 Washington has the least-cost path to root and is moved onto the PATH list

Trang 5

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

UNKNOWN List

87000 600000

250000

315000

315000 26000

Frankfurt- Washington D.C 250000

Paris- Washington D.C 600000 Washington D.C.- Paris 600000 Washington D.C.- Frankfurt 250000

TENTative List

315000

Pennsauken- Frankfurt 315000 315000 Washington D.C.- Paris 600000 Washington D.C.- Frankfurt 250000

648000 298000

PATH List

5

6

Pennsauken

New York

Level 2-only

oc768/STM-256

Washington

oc192/STM-64

Frankfurt

Paris

cost to root

cost to root

New York New York New York

F IGURE 10.5 Frankfurt is routed via New York although a direct line exists

Trang 6

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

315000

315000 26000

TENTative List

315000

Washington D.C.- Paris 600000 648000

320000 385000

PATHs List

London Paris

315000 385000

7

8

9

Pennsauken

New York

Level 2-only

oc768/STM-256

Washington

oc192/STM-64

Frankfurt

Paris

New York New York

New York London

F IGURE 10.6 If the TENTative list is empty, the SPF calculation is terminated

Trang 7

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

LSDB representation

10 10

10

0

10

10

10 0

LAN Stockholm.02

Amsterdam.00

p2p circuit

10 10 0 0

10

10

10

F IGURE 10.7 Two equal cost paths over a p2p and a broadcast circuit and its representation in the link-state database

Trang 8

255

Trang 9

256

Trang 10

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 protoproto-cols (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

Ngày đăng: 03/07/2014, 19:20

TỪ KHÓA LIÊN QUAN