|
|
< Free Open Study > |
|
Protection ScalabilityThis section covers how to use Fast Reroute (FRR) link, node, and path protection in your network—specifically, how well it scales. There's quite a lot to FRR. But the biggest piece people want to get their hands on, after understanding how protection works, is how it scales. If I do link protection everywhere in my network, how many extra LSPs does that give me? What about node protection? Or path protection? Luckily, the formulae for link/node/path protection are pretty simple. All you need to do is determine the number of additional LSPs each node will have to deal with. You can then add this back into the full-mesh scalability numbers generated earlier in the chapter and see how your design stacks up against your scalability limits. Before defining any formulae, though, you need to define some variables. In addition to the variables already defined in the full-mesh scalability discussion, you need to add the following:
Two pieces to talk about when considering protection (discussed in the next few sections) are as follows:
Link ProtectionFor link protection, the number of additional LSPs in the network is approximately D * Rn—the average degree of connectivity per node, multiplied by the number of nodes in the cloud. From real-world experience, D tends to be somewhere in the neighborhood of 3 to 5. So if you're doing a WR full mesh, and Wn = 28 (therefore, Rn = 28), you're talking about Fn being somewhere between 84 and 112 additional LSPs in the entire network. One assumption made here is that it takes only one backup tunnel to protect a link. If your network topology requires you to build two or three or x backup tunnels to protect a link, you're really talking about x * D * Rn LSPs. This is still not much signalling. If x gets big enough that the number of backup LSPs starts taking significant resources, you probably have underlying network issues. Another assumption is that you're FRR-protecting every link. If you don't need to protect all the links in your network, of course, the number of protection LSPs will go down. Protecting a CR full mesh requires protecting all the links those CR LSPs might traverse. So in this case, Rn = Wn + Dn + Cn = 168, and if D still varies between 3 and 5, Fn is an additional 504 to 840 LSPs. In the entire network. Still not a big deal. The additional load on a given router is 2 * D. If a router has six links, it is a headend for six protection LSPs and a tail for six protection LSPs. Scalability as a TE tail is generally not a concern, as was illustrated earlier in this chapter. All you have to deal with, then, are the additional six LSPs this node is a headend for, and there's not much work there, either. But how many LSPs is a node a midpoint for? This depends on the LSP length (that is, how far they have to diverge from the shortest path to arrive at the next-next hop). Certainly an LSP is a midpoint for no more than Fn LSPs. But the number will be far less than that. It's hard to come up with an accurate rule for generating this number because networks are so different, but a reasonable approximation is
where Ln = Rn * D and T is the fudge factor that we used earlier in this chapter. Note that this equation reduces to (D * T) – (2 * D). For a WR full mesh (28 nodes) and T = 3, with D = 3 to 5, a node is a midpoint for 3-5 protection LSPs. Not a big deal at all. Node ProtectionIn node protection, each node needs an LSP not to its neighbors, but to the neighbors of its neighbors. So the total number of LSPs added to the network (Ln) is Rn*D*(D-1). In a WR full mesh, this means that Fn ranges somewhere around (28 * 3 * 2) = 168 through (28 * 5 * 4) = 560 LSPs. The equation for Fn is the same as it was in link protection; the only difference is in the value of Ln. The equation is still
In node protection, though, remember that Ln = Rn*D*(D-1), rather than Rn*D. That means that this equation reduces to (D * (D – 1) * T) – (2 * D). Assuming that T = 3 and D is 3 to 5, the number of node-protection LSPs for which a node is a midpoint is between 12 and 50. Still not a big deal either way. Path ProtectionPath protection is the easiest to calculate. If you have Ln LSPs in a network, and you calculate fully diverse paths for each one, you have a total of 2 * Ln LSPs in the network; for each LSP, you have one additional (protection) LSP. So Fn = Ln. Again employing a fudge-factor T value of 3, it's safe to assume that a router is a midpoint for approximately (Fn * T) / Rn LSPs. This can be further refined, as with the link and node protection cases, by subtracting the LSPs that a node is a headend or tail for. If you assume that each node has the same number of LSPs as head and tail, a router is a midpoint for somewhere around ((Fn * T) / Rn) – (Ln / Rn) LSPs. Where path protection gets tricky is if you need more than one LSP to protect a primary LSP. Maybe you can't get enough bandwidth to match the entire LSP (or whatever portion of it you're protecting) in one path. Cisco IOS Software doesn't implement path protection, but as you will see, it scales so poorly that it's not a very attractive solution on a network of any reasonable size. Consider the network shown in Figure 9-10. Figure 9-10. Primary LSP Requiring Multiple LSPs
The LSP from A to D is 200 Mbps, but there are only OC-3 links to protect it over. If you want to protect all the bandwidth, you have to build two LSPs of 100 Mbps—one across each path. So in this case, Fn > Ln. If the entire network happens to look like this, Fn > Fn. How much greater? It depends. It could be two to three times greater. But no matter whether Fn = 1 * Ln or Fn = 3 * Ln or Fn = 100 * Ln (not likely!). Actual Data for Determining ScalabilitySo how well does this stuff scale in real life? Good question. Let's look at some data. In some topologies, in order to protect your network fully using link or node protection, you could have more protection LSPs than primary LSPs. This happens when you have either a small number of nodes or a high degree of connectivity. Assume that the break-even point is the point at which the number of protection LSPs and primary LSPs are equal, for a given protection scheme. So a network in which you have 12 LSPs, but you need 36 LSPs to enact full node protection, does not break even. A network in which you have 110 primary LSPs and 99 protection LSPs meets the break-even point. The definition of this break-even point is somewhat arbitrary. You might decide that a protection scheme is good only if the number of protection LSPs is no more than 50 percent of the number of primary LSPs. Or 20 percent. Or some other percentage. But given the following data, it's easy to see that you'll reach that point eventually. NOTE Of course, the break-even scalability point isn't the only reason to consider a particular type of protection. You also need to consider things such as where your failures occur, how often they happen, how much data you have to protect, and so forth. Given the formula and assumptions here, the break-even point for link protection is at four nodes, and node protection is at ten nodes. It should be obvious that path protection is always just at the break-even point, because Fn = Ln. This assumes that multiple LSPs are not protecting a single LSP. Table 9-16 shows different numbers of nodes, the total number of LSPs used in the network (assuming that all links in the TE portion of the network are to be protected), and the number of protection LSPs used. In this table, the average degree of connectivity (D) is 3.
The number of LSPs used in node protection is the formula Rn * D * (D – 1) plus the number of LSPs in link protection (Rn * D). So the entire formula is
which reduces to Rn * D2. Why do you need both link and node protection? Because if you have LSPs that terminate on a directly connected neighbor, you can't node-protect that neighbor; you need to link-protect it. You might not always need to link-protect every node (not all nodes are TE tunnel tails), but the number of additional LSPs is so small that it's not worth calculating and trying to factor out here. Figure 9-11 shows a graph of link, node, and path scalability. Figure 9-12 shows a graph of only the link and node scalability numbers, because it's easier to see the difference between these two if path protection isn't in the way. It's important to note, however, that the graphs in both figures use the exact same data. The reason it's hard to see link and node protection numbers on the path protection graph is because of how poorly path protection scales to large numbers. Figure 9-11. Link/Node/Path Scalability Graph
Figure 9-12. Link/Node Scalability Graph
As you can see, both link and node protection scale quite nicely, while path protection quickly creates a large number of protection LSPs. Path protection has other issues as well, so it's not very suitable for deployment on large TE networks. |
|
|
< Free Open Study > |
|
