|
|
< Free Open Study > |
|
How CSPF WorksThe process that generates a path for a TE tunnel to take is different from the regular SPF process, but not much. There are two major differences between regular SPF, done by routing protocols, and CSPF, run by MPLS Traffic Engineering. For one thing, the path determination process is not designed to find the best route to all routers—only to the tunnel endpoint. This makes the SPF algorithm slightly different: You stop as soon as the node you're trying to get to is on the PATH list, rather than trying to calculate the shortest path to all nodes. Also, there's now more than one metric at each node. Instead of just a single cost for a link between two neighbors, there's also
So how does CSPF work? First, the triplet used in regular SPF needs to hold bandwidth, link attributes, and administrative weight. This turns the triplet into a sextuplet. See Chapter 3 for information on how to configure these properties. Another subtle detail of CSPF is that because you're looking for a single path to an end node, there is no load sharing. There are a few tiebreakers when two paths have all the same attributes: minimum path bandwidth, the lowest IGP metric to a path, and the path's lowest hop count. So the sextuplet really becomes something of a nonet (nine items in the object). To help you better understand this concept, let's run through a couple of examples. The first one, shown in Figure 4-3, is similar to Figure 4-1, but each link is advertising its available bandwidth. For simplicity, only four link properties are shown in the PATH/TENT lists {link, cost, next hop, and available bandwidth}. Assume that the other link attributes don't come into play in this example; you'll learn about those shortly. Figure 4-3. Simple Network Topology Demonstrating the CSPF Algorithm
In the topology shown in Figure 4-3, Router A wants to build a TE tunnel to Router D with a bandwidth of 60 Mbps. Each link lists its metric (the same as in Figure 4-1) and its available bandwidth. Without taking bandwidth into account, Router A's best path to Router D is A This is actually quite simple. The steps for the CSPF algorithm are as follows:
Given that the rules are similar, here's the SPF calculation for a path from A to D that needs 60 Mbps. Instead of {node, cost, next hop}, the PATH and TENT lists contain information encoded as {node, cost, next hop, minimum bandwidth}. You'll understand this better as you follow the next example. This example follows the same general format as the previous SPF example, but some of the basic steps are compressed into one (for example, moving a node from TENT to PATH and putting its neighbors on the TENT list.)
In reality, the path calculation is more complex than what is covered here. CSPF has to keep track of all the nodes in the path, not just the next hop. Also, there's more than just bandwidth to consider—there are also link attributes and tiebreakers. Tiebreakers in CSPFIn regular SPF (as used in OSPF and IS-IS), it's OK to use multiple paths to the destination that have the same cost. This is sometimes called Equal-Cost MultiPath (ECMP), and it's a good idea when talking about your regular Interior Gateway Protocol (IGP). In CSPF, however, remember that you're not trying to calculate all the best paths to all possible destinations. You're looking for one path to one destination. What do you do when you go to put a node on the TENT list and the node in question is already on the TENT list, with the same cost? You need to find a way to differentiate these paths from each other. Here are the tiebreakers between paths, in order:
NOTE Things aren't really "random." When you get this far in the decision process, you take the top path on the PATH list. There's no "random" in the sense that every possible tied path has an equal chance of being chosen, but it's random in that which path ends up on the top of the PATH list is topology- and implementation-dependent, so it's not something that you, as the network administrator, control. These tiebreakers are applied as a node is put on the TENT list. At any time, a given node should be listed only once on the TENT list. This is different from an IGP SPF, in which you can have multiple ways to get to a given node and can load share between them. Assume that, in the network shown in Figure 4-4, you want to build a tunnel from RtrA to RtrZ with a bandwidth of 10 Mbps. Every path in this network fits that description. So which one do you choose? Figure 4-4. Sample Network in Which CSPF Tiebreakers Come into Play
There are five possible paths from A to Z, referred to as P1 through P5 (from top to bottom). Table 4-15 lists the path attributes.
Here's the decision process that RtrA goes through to pick one of these paths:
Other Things That Influence CSPFChapter 3 discussed the use and configuration of bandwidth, link attributes, and administrative weight in the context of information flooding. It also covered how to configure an MPLS Traffic Engineering tunnel to take advantage of these attributes. How are these attributes used to influence CSPF? It's pretty straightforward. Bandwidth has been pretty well covered. A path is not considered eligible for use for a particular MPLS TE tunnel if it does not have the bandwidth required. Link attributes are similar to bandwidth, from a CSPF perspective. As covered in Chapter 3, you can optionally configure affinity bits on a tunnel so that it can be routed on or away from certain links. If a tunnel's affinity bits do not match the configured attribute string on a link, that link is not considered eligible for use for a particular MPLS Traffic Engineering tunnel. Administrative weight is equally simple, although it is used a little differently. Adminis-trative weight is what is propagated by the IGP when it floods traffic engineering information. By default, only the administrative weight is used to calculate a tunnel's path. However, just being able to change the administrative weight for a particular link might not give you the flexibility you need. IGP metrics are usually derived from bandwidth. In OSPF, the default link metric is reference-bandwidth/link bandwidth. The default reference bandwidth (changeable through the command auto-cost reference-bandwidth) is 108, which means that any link of 100 Mbps or more has a cost of 1. You can also set the cost on an individual link with the ip ospf cost cost command. In IS-IS, the default link cost is 10. You can change this cost with the command isis metric. Both IS-IS and OSPF typically use their metric to encode some measure of link bandwidth. This is fine for data-only networks. TCP's congestion-control mechanisms, when combined with DiffServ queuing, take advantage of as much bandwidth as they can. But what about voice? Voice tends to care less about bandwidth and more about delay. But there's no way to advertise delay on a link. Or is there? You can always manipulate the IGP's link metric to represent delay rather than bandwidth. But the problem with this is that you then lose the ability to accurately route data traffic, which can seriously impact your network. Consider the topology shown in Figure 4-5. Figure 4-5. Topology in Which Voice and Data Traffic Prefer Different Paths
The three paths between RtrA and RtrZ are
Because the low-delay, high-bandwidth path is full, you could juggle priorities and shift traffic around so that the land-line OC3 path is no longer full, but that doesn't address what the example is trying to show you. It comes down to a simple question: Do you want the high-bandwidth, high-latency path or the low-bandwidth, low-latency path? The answer to this question, like so many others, is, "It depends." Data is generally OK with the high-delay path, and voice has relatively lower bandwidth demand, so it is OK with the low-bandwidth path. MPLS Traffic Engineering gives you the ability to consider both link bandwidth and link delay, so your voice tunnels can consider delay a separate cost from the metric your data tunnels use. To accomplish this, you must do the following:
No inherent unit of measurement is associated with the configuration of administrative weight. If you configure mpls traffic-eng administrative-weight 10, the value 10 could be interpreted in all sorts of ways. Is 10 the propagation delay in microseconds? Hundredths of microseconds? Milliseconds? Seconds? It's whatever you want it to be. Generally, it's a good idea to encode the delay in milliseconds for the following reasons:
To expand on that last point, how do you know how much latency to expect between two points? Three ways exist to determine this number. In increasing order of complexity, they are as follows:
Pinging from One Router to Another to Determine Expected LatencyThis is by far the easiest way to determine a circuit's expected latency. It's pretty simple. You get on a router that's connected to a circuit you want to measure the latency on and then run some pings or traceroute to the other end. Example 4-1 demonstrates a ping from a router in Massachusetts to a router in California. Example 4-1 Ping Results from a Massachusetts Router to a California Routerchelmsford-gb1>ping sanjose-gb4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.30.253.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/80 ms The round-trip time on this ping is 80 ms. It's a fair guess that the one-way latency on this circuit is half that, or 40 ms, but there's no guarantee for that estimate. In this case, the link between the two routers is an OC3. At the SONET level, this circuit can be routed differently in two directions, so the latency from Massachusetts to California might be 60 ms and the latency from California to Massachusetts is 40 ms. Because ping inherently tests two-way latency, there's no easy way to know for sure. The other drawback of this approach is that ping runs at process level on the router. This means that when a router receives an ICMP echo request, it deals with it when it gets around to it, in between its more important jobs of maintaining routing protocol adjacencies, forwarding packets, and other such stuff. So if you ping a router that's under a high CPU load, it might have ping response times that are not representative of the actual latency, but more of the load on the router. Despite these caveats, using ping to determine average latency is good enough most of the time. You might want to run an extended ping of 1000 packets or so, just so that any anomalous responses because of router processing are averaged out. You also want to make sure that the ping you're sending across a link does not encounter congestion because you want to measure transmission and propagation delay, not queuing delay. Determining the Expected Latency Based on Route-MilesThe speed of light in a vacuum is roughly 3 * 108 meters per second, which translates to about 3.3 ms to travel 1000 km. The speed of light over fiber is a little less than that, and you also need to account for various other kinds of delays in a real network. It's better to use an estimate of 6 to 9 ms per 1000 km when estimating delay across a network. Refer to the Cisco Press book Integrating Voice and Data Networks for more details on delay, jitter, and all sorts of fabulous stuff. The other tricky piece is knowing the distance between two points. The shortest distance is easy to find. Attack your favorite map with a ruler, or see web sites such as the CIA World Factbook (www.odci.gov/cia/publications/factbook/) for maps. Using these maps, you can figure the latency that your circuit would take if it took the shortest possible path, and use that as a minimum expectation of delay. For example, it's about 4500 km from Boston to San Francisco. Given that, the best possible one-way delay you should expect in an optical network is somewhere between 28 ms and 41 ms. It's important to realize that this is an estimate of the best possible delay. It does not take into account the fact that no circuits run from one end of the U.S. to the other as a single piece of fiber. But the upper end of the estimate (40.5 ms) correlates nicely with the ping testing from the preceding section (which suggests 40 ms one-way), so perhaps 40 ms is a good number to expect for average one-way latency on this link. Using SAAThe best way to determine one-way latency across a circuit is to use Service Assurance Agent (SAA), because it was developed for just this purpose. Chapter 10, "MPLS TE Deployment Tips," covers SAA in greater detail. CSPF KnobsYou should now understand how CSPF works. Also, between the preceding chapter and this one, you should have a good handle on the basic concept of link bandwidth. Three other major pieces to path calculation that you should understand are
path-option ConfigurationExample 4-2 repeats the basic MPLS TE tunnel configuration demonstrated in Chapter 3. Example 4-2 MPLS Traffic Engineering Tunnel Configurationinterface Tunnel0 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination destination-ip tunnel mpls traffic-eng path-option 10 dynamic One command you can use to influence CSPF on the headend is the path-option command. In addition to being able to control path properties such as requested link bandwidth, affinity and mask, and administrative weight for the tunnel, you also have control over which path the tunnel takes. path-option lets you specify one or more possible paths that you want the tunnel to take, in the order you want to try them. The complete syntax is as follows: tunnel mpls traffic-eng path-option preference [dynamic | explicit [identifier identifier | name name]] {lockdown} Table 4-16 explains the syntax in better detail.
The most basic path-option configuration is tunnel mpls traffic-eng path-option 10 dynamic. Why use 10 for the preference? There's no good reason why, really. Too much BASIC programming in the mid-1980s, perhaps. And it's a good idea to leave some space between your path-option preferences (10, 20, and so on), rather than using 1, 2, 3, 4 for successive path-option preferences. But the value 10 doesn't have any special meaning when compared to the value 9, other than an ordinal one. Creating an Explicit PathWhen you use an explicit path-option, you also need to define the path-option itself. You do this using the following configuration-level command: ip explicit-path [identifier identifer | name name] {enable | disable} When you enter the following command:
vxr15(config)#ip explicit-path name foo
vxr15(cfg-ip-expl-path)#
you enter a submode for path-option creation. In this submode, not only can you add nodes to the path-option, but you can also delete and change them. Example 4-3 demonstrates the possible options. Example 4-3 Possible Options for the path-optionvxr15(config)#ip explicit-path name foo vxr15(cfg-ip-expl-path)#? Explicit-Path configuration commands: append-after Append additional entry after specified index exclude-address Exclude an address from subsequent partial path segments exit Exit from explicit-path configuration mode index Specify the next entry index to add, edit (or delete) list Re-list all or part of the explicit path entries next-address Specify the next (adjacent) address in the path no Delete a specific explicit-path entry index Explicit paths are usually a series of next addresses that list router hops (either TE RIDs or interface addresses) in the order you want the tunnel to traverse them. You also have the option for exclude-address, which lets you specify a list of links or nodes to not be used in the tunnel path calculation. Not all code has this option. How does this work? Consider Figure 4-6. Figure 4-6. Finding the Lowest-Path Cost While Excluding Specific Links/Nodes
In Figure 4-6, each link has a cost of 10. Assume for now that all links can hold the tunnel you want to build (they all have enough bandwidth, the attribute bits match, and so forth). Note the two links from RtrB to RtrD. The four paths from RtrA to RtrE are detailed in Table 4-17.
If you ask the router to dynamically calculate a path from RtrA to RtrE, the tunnel is placed across the A Table 4-18 shows each router's TE RID.
Figure 4-6 shows the link addresses between each router. Notice that the last octet of each interface address is the same as the RID's last octet. Although this might not be an entirely realistic addressing plan, it makes things easier to deal with in a lab setup; most of the examples in this book use that format. If you wanted to build a tunnel from RtrA to RtrE over path 4, you could list the RIDs, as shown in Example 4-4. Example 4-4 Listing the RIDs for the Tunnel from RtrA to RtrE Over Path 4RtrA(cfg-ip-expl-path)#next-address 192.168.1.2 Explicit Path name foo: 1: next-address 192.168.1.2 RtrA(cfg-ip-expl-path)#next-address 192.168.1.3 Explicit Path name foo: 1: next-address 192.168.1.2 2: next-address 192.168.1.3 RtrA(cfg-ip-expl-path)#next-address 192.168.1.4 Explicit Path name foo: 1: next-address 192.168.1.2 2: next-address 192.168.1.3 3: next-address 192.168.1.4 RtrA(cfg-ip-expl-path)#next-address 192.168.1.5 Explicit Path name foo: 1: next-address 192.168.1.2 2: next-address 192.168.1.3 3: next-address 192.168.1.4 4: next-address 192.168.1.5 RtrA(cfg-ip-expl-path)# As you can see, every time you enter a next address, you are shown the entire explicit path. You're actually shown the entire explicit path after every change to it, whether you are adding to or deleting from the path-option configuration. You can also list the explicit path with the list subcommand, as shown in Example 4-5. Example 4-5 Listing the Explicit PathRtrA(cfg-ip-expl-path)#list ? <1-65535> List starting at entry index number <cr> RtrA(cfg-ip-expl-path)#list Explicit Path name foo: 1: next-address 192.168.1.1 2: next-address 192.168.1.2 3: next-address 192.168.1.3 4: next-address 192.168.1.4 5: next-address 192.168.1.5 Example 4-5 defines the explicit path to be the list of RIDs. If you wanted to use path 3, which specifies a particular link between RtrB and RtrD, you'd have to specify the link address rather than the router ID. The explicit path would be something like the output from the show ip explicit-paths name command, as demonstrated in Example 4-6. Example 4-6 Using the show ip explicit-paths name Command
RtrA#show ip explicit-paths name foo
PATH foo (strict source route, path complete, generation 28)
1: next-address 192.168.1.2
2: next-address 192.168.7.4
3: next-address 192.168.1.5
As you can see, path option foo is a strict source route, it is a complete path (paths are almost always complete; incomplete paths are rare), and it is generation 28 of that path option. The generation number changes every time the path option is changed—in much the same way that the BGP table version changes when any updates happen. If the explicit path in Example 4-6 had any loose subobjects specified in it (see "Interarea Tunnels" later in this chapter), you'd see loose source route rather than strict source route in the output of show ip explicit-paths. This example uses the RID for RtrB and RtrE, but uses RtrD's incoming link address on link 2 to specify which link the tunnel crossed. The explicit path configuration can accept a mix of node addresses and link addresses; it's pretty flexible that way. Example 4-7 demonstrates another way to specify the explicit path. Example 4-7 Specifying an Explicit Path
PATH foo (strict source route, path complete, generation 33)
1: next-address 192.168.1.2
2: next-address 192.168.7.2
3: next-address 192.168.7.4
4: next-address 192.168.8.5
Feel free to use any mix of interfaces and RIDs; as long as they are listed in the order you want them to traverse the network, you're fine. In addition to next-address, you also have the option of exclude-address. The exclude-address option lets you specify nodes that are not to be used in the tunnel path calculation. Consider Figure 4-6 again. Assume that you want to build a tunnel from Router A to Router E, and you want it to not go through Router C, but to consider all other possible paths. To accomplish this, you could define a series of explicit paths from Router A to Router E, or you could just define a path option that excludes Router C from the path calculation using the following command sequence: ip explicit-path name avoid-RtrC exclude-address 192.168.1.3 NOTE Currently, an explicit path cannot contain both a next address and an exclude address; it's one or the other. You won't get any warnings if you create an explicit path that uses both exclude-address and next-address; it just won't work. Table 4-19 describes some of the other commands in the explicit path submode.
append-after and index are useful when you're editing an existing path option. You can insert new nodes in the list by specifying either a relative placement (through append-after previous index number) or an absolute placement (through index index number). no index index lets you delete a node in the path option list. Using Multiple Path OptionsEarlier in this chapter, you saw that you can specify a preference when selecting a path option for a TE tunnel. A TE tunnel can have multiple path options listed; they are tried in order of preference. For example, if you want to build a path from Router A to Router E, as in Figure 4-6, and you want the router to try using path 3, and then path 4 if path 3 is unavailable, and then path 2 if path 4 is unavailable, and then finally path 1, you could configure a tunnel as shown in Example 4-8. Example 4-8 Configuring a TE Tunnel with Multiple Path Optionstunnel mpls traffic-eng path-option 30 explicit name Path3 tunnel mpls traffic-eng path-option 40 explicit name Path4 tunnel mpls traffic-eng path-option 20 explicit name Path2 tunnel mpls traffic-eng path-option 10 explicit name Path1 It is generally a good idea to have the last path option in your tunnel calculation be dynamic:
tunnel mpls traffic-eng path-option 50 dynamic
This is useful because putting dynamic as the last path option ensures that if it's at all possible for a TE tunnel to come up, it will. Although specifying a dynamic path option isn't strictly necessary in the topology depicted in Figure 4-6, it would be useful if a link were added between Router B and Router E. Router A's list of path options wouldn't need to be updated to allow Router A to take advantage of the A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
< Free Open Study > |
|
B
