|
|
< Free Open Study > |
|
Tactical TE DesignIn the tactical model, you build TE LSPs to work around congestion. The key things to deal with in this model are as follows:
The following sections sift through all four considerations. One thing that this section assumes is that you have already configured MPLS TE on every link in your network, as well as in your IGP. In other words, you have everything you need to use MPLS TE tunnels already in place, except for the TE tunnels themselves. When you first decide to roll out MPLS, even if it's not for TE but for VPNs or some other reason, it can't hurt to enable MPLS TE everywhere (IGP and on interfaces) so that when you do need to use it in a tactical manner, it's right there waiting for you. When You Decide to Build TE LSPsConsider the sample network shown in Figure 9-1—specifically, the OC-12 link between St. Louis and Denver. Two cases in which that link can be overloaded for a significant amount of time are
Suppose a large amount of traffic is going from St. Louis to Denver, as shown in Figure 9-5. It is routed across the St. Louis Figure 9-5. Excess Traffic from St. Louis to Denver
If you discover a link that's full, how long do you wait before working around it with TE LSPs? You don't want TE LSPs to be built the instant a link starts queuing and dropping packets. And if you have an outage that you know will last only a little while (a router reboot or crash, for example), it's not worth working around. But if you have a significant traffic disruption for a long time (perhaps an hour or more), you should consider using TE-LSPs to see if you temporarily clear up the problem. There is no hard and fast minimum time you need to wait before using TE-LSPs. It's up to you. You should start applying them to failures of an hour or more, get a feel for how long it takes you to apply them, and then use that to factor into a policy specific to your network. Although it takes far less than an hour to build a TE-LSP (it can be done in seconds!), being too responsive to short-term problems can make you trigger-happy and twitchy, and that's no way to run a network. Where You Put TE LSPsBy the time you get around to determining where to put TE LSPs, you've already decided there's a problem you're going to work around. So now the question becomes "Where do I place TE-LSPs so that I don't create another problem?" Think about the St. Louis The first thing you might think of doing is splitting the traffic along two paths. You obviously want to keep using the St. Louis So what you can do is build two TE LSPs. One goes directly across the St. Louis Your network then ends up looking like Figure 9-6. Figure 9-6. Two LSPs Between St. Louis and Denver, Each Carrying 450 Mbps
For the sake of simplicity, assume that you don't have a significant amount of traffic on the Dallas Figure 9-7. Three LSPs Between St. Louis and Denver, Each Carrying 300 Mbps
Considering the two-LSP solution, using a 600-Mbps LSP and a 300-Mbps LSP isn't feasible, because putting 600 Mbps of traffic across a link with 600 Mbps of capacity is not a good idea. If even a small burst greater than 600 Mbps occurs, you'll have a lot of delay to deal with. A 450/450 split is better, because no link is full. In the three-LSP case, you can split the traffic into three 300-Mpbs LSPs; either solution might be appropriate given other bandwidth demands on the network. There are four ways you can control the ratio of traffic distributed between the two LSPs:
With only two equal-cost tunnels, it doesn't matter what method you pick. But if you're going to be doing unequal-cost load balancing between two or more tunnels, you should use solutions 2, 3, or 4. Use solution 2 (reserving actual bandwidth) if you want a quick way to look at a midpoint and see how much bandwidth each LSP should be carrying. Use solutions 3 or 4 if you don't want to have to worry about accidentally overreserving bandwidth but just want to control the load-share ratios. (Sometimes this is done by controlling bandwidth ratios, and sometimes this is done by directly controlling load-share ratios.) Laying out LSPs of 300 Mbps and 450 Mbps in a network whose bottleneck is 600 Mbps links can be dangerous; you might still have congestion problems even after you've shifted data around. One way to deal with this is to add more bandwidth, but that takes time. Another way to deal with this problem is to try to optimize your tunnel placement to avoid congestion as much as possible. Optimizing Tunnel Placement: Step 1Whereas distributing the traffic over multiple LSPs overcomes the problem of an overloaded link, it might introduce a new, although less-severe, problem—suboptimal forwarding. In the scenario with three LSPs, consider the East Coast traffic destined for Seattle and San Diego that enters St. Louis. Because two of the three LSPs have Seattle or San Diego as LSP midpoints, any traffic from St. Louis that goes over these LSPs and that is actually destined for Seattle or San Diego first must get to Denver (the tail of all three TE tunnels) before heading back west to Seattle and San Diego. For example, if traffic were destined for a Web-hosting center in Seattle, and it followed the IGP path from St. Louis, it would go St. Louis If you've got lots of extra capacity on the Seattle However, this path is certainly suboptimal. Of course, you have the same problem if you have traffic destined for San Diego that will go St. Louis How do you improve this? Take your three TE LSPs and terminating them not on the node at the other end of the St. Louis The St. Louis Optimizing Tunnel Placement: Step 2There's another problem that you can solve, too. Even after you make the adjustments described in Step 1, you still have some suboptimal packet paths. Take a closer look at the 900-Mbps traffic going St. Louis
Traffic from Dallas to Denver isn't likely to cross St. Louis, though, because Dallas has a more attractive path through San Diego to anything in the West region. So that leaves three possible ways this Denver-bound traffic (or, indeed, any traffic) could have come into St. Louis. For the sake of simplicity, assume that 300 Mbps of the 900 Mbps Denver-bound traffic originates from St. Louis, 300 Mbps comes from Raleigh, and 300 Mbps comes from Chicago. Because traffic arriving in St. Louis will be pretty evenly distributed across the three LSPs, this means that 100 Mbps of the Chicago-sourced traffic will go over the St. Louis How do you get around this suboptimality? By building TE LSPs farther away from the source of the congestion. Assume the following:
If you build TE LSPs between the following points, you can individually control each of these 100 Mb traffic streams and place them anywhere in the network you want:
NOTE In general, the farther you move from the point of congestion, the more exact control you have over your network traffic. The ultimate case of this is a full mesh of TE LSPs between all routers, or at least all routers with a given role in the network. For example, if you have a full mesh of TE LSPs between all the WRs in the network, you have full control over all traffic entering your WAN, at the level of granularity equal to the amount of traffic between any two WRs. See the sections "Online Strategic TE Design" and "Offline Strategic TE Design" for more information on a full mesh of TE LSPs and how to manage it. As soon as you understand this methodology, it's simple to apply. Based on real-life scenarios, as soon as you discover the source of congestion, you can make modifications in a matter of minutes! By now, hopefully you've seen some of the power of the tactical TE model; however, you still need to address a few more issues. When to Remove Your Tactical TE TunnelsNow that you've built all these nifty TE LSPs to work around problems, are you done? Nope. Because your problem was caused by a temporary event, the problem you're trying to solve will eventually go away. Just like your mother periodically harangued you to clean your room, so too should you periodically clean your network. In fact, two cases when you should consider taking TE LSPs down are
Determining When TE LSPs Are No Longer NeededHow do you tell if TE LSPs are no longer needed? It's pretty simple. Take the example of the LSPs that were created to work around the congested St. Louis
Tracking the existence of TE LSPs is easy enough, because TE LSPs are interfaces, and you will see them with SNMP's IF-MIB or via show interfaces and other such CLI commands. Remembering why the TE LSPs were put up in the first place is also straightforward, surprisingly enough. Because TE-LSPs are interfaces, you can put a description on them, like any other interface. This description is carried in the RSVP setup information as an LSP is set up. Determining When TE LSPs Are Causing ProblemsTE LSPs can induce artificial congestion—link congestion because of traffic that's there only because some TE LSPs are traversing a non-shortest path across that link. Remember that the sample network has a TE LSP from St. Louis If you discover a congested link, the first thing you need to do is check to see if any TE LSPs are crossing that link, and if so, how much bandwidth they're consuming. If the St. Louis You can check this by first determining which LSPs are traversing a given link, as demonstrated in Example 9-1. Example 9-1 Determining the LSPs Traversing a Link
STLouisWR1#show mpls traffic-eng tunnels interface out pos5/0 brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: disabled
Periodic auto-bw collection: disabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
STLouisWR1_t6 192.168.1.6 - PO5/0 up/up
Next, you can check one of two things:
Checking the traffic on the headend is simple—as you know by now, TE tunnels are interfaces. show interface tunnel1 on the headend router tells you how much traffic is going down the TE tunnel. You can check the midpoint by finding the incoming label for a particular tunnel and then keeping an eye on the traffic coming in with that label, as demonstrated in Example 9-2. Example 9-2 Checking the Midpoint for Traffic FlowDalWR2#show mpls traffic-eng tunnels name-regexp StLouisWR1 | include InLabel InLabel : POS1/2, 17 DalWR2#show mpls forwarding-table labels 17 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 17 Pop tag 192.168.1.5 8 [1] 1939835 PO1/1 point2point Keep an eye on the Bytes tag switched value, and see if it increases over time. On distributed systems (such as the GSR), you might not see the counters change for several seconds and then make quite a jump; this is normal. Checking at the headend is preferred, because it is easier, but either method works. Assume that the St. Louis You now have a tough choice to make. How do you solve the St. Louis Hacky? Sure. Difficult to track? Yeah, probably. But this is a workaround to a problem that exists until you get more bandwidth. If you have an OC-192 St. Louis On the other hand, if your St. Louis Remember, one of the things MPLS TE buys you is the capability to prolong the life of your existing capacity, thus putting off the amount of time until you have to buy new circuits. Every month you save on buying capacity can equal tens or hundreds of thousands of dollars. Of course, nobody ever said it was easy. If placing all these LSPs by hand seems too complex, skip ahead to the discussion of full-mesh TE models; they can manage a lot of that complexity. Useful TE Features for Tactical TEMPLS TE has lots of neat features, as covered throughout this book. There's auto bandwidth, Fast Reroute, DiffServ-aware TE, forwarding adjacency, and lots more. But not all of these features are appropriate for the tactical model. Table 9-2 lists the major TE features that might be suitable for a tactical TE deployment.
|
|
|
< Free Open Study > |
|
Seattle or Dallas
