|
|
< Free Open Study > |
|
Interarea TunnelsUp until now, you've seen TE tunnels that must start and end in the same area (or level, rather than area, if you're an IS-IS fan.) In fact, in older versions of Cisco IOS Software, a router was limited to a single TE database. This meant that not only could you not have a TE tunnel that spanned multiple areas, you couldn't have a router that was connected to multiple areas and had TE tunnels in each area independently. However, this restriction can be overcome using interarea tunnels. IGP TerminologyBefore diving into how interarea TE tunnels work, it's important to get the terminology straight. In OSPF, an area is a set of routers that share a common SPF tree. IS-IS, however, uses the term level to mean the same thing. Because the official Cisco term for the feature about to be discussed is interarea tunnels, this section uses the word area rather than level. However, realize that the feature under discussion is equally usable in both OSPF and IS-IS; there are no differences in what you can do based on the IGP you're running. Another important term is the word used to describe the device that sits between SPF trees. In OSPF, this box is an Area Border Router (ABR). In IS-IS, this function is performed by the router with both an L1 and an L2 neighbor. Because we're using the term area already, we refer to this box as an ABR, regardless of whether the IGP is OSPF or IS-IS. Figure 4-39 shows the terminology in use. Figure 4-39. Proper Terminology for Discussing Interarea TE
From the perspective of R1, ABR1 is the entrance to the backbone and is therefore called the ingress ABR. ABR3 and ABR4, because they are how an R1 The IS-IS picture is slightly different because, in IS-IS, the area borders are built on the links, not on the routers. However, the terminology remains the same to make it easier to talk about interarea tunnels independent of your IGP. What Interarea Tunnels Can DoThe interarea tunnels feature allows you to do two things:
Consider Figure 4-39. Without interarea tunnels, you can build TE tunnels in only one of the following areas:
You cannot build TE tunnels in any combination of these areas. ABR1 can't have a tunnel to R1 and a tunnel to ABR3 because it is limited to a single area's worth of topology in its traffic engineering database (TE-DB). As soon as you are running code that supports interarea TE tunnels, you can build tunnels from R1 to R2, R1 to ABR1, ABR1 to ABR3, R3 to R4, R1 to R4, or any other combination. You have a tremendous amount of flexibility. Most TE features work on an interarea TE tunnel. Any feature that is purely a local function of the headend works, because these features don't care if the tunnel crosses multiple areas. These features include the following (see Chapter 5, "Forwarding Traffic Down Tunnels" for more information):
Additionally, most midpoint features don't care if a TE tunnel is single-area or multiarea. These features include
How Interarea Tunnels WorkInterarea tunnels are simple to configure, and intra-area tunnels are even easier. To start with, there's the IGP configuration. In older versions of the Cisco IOS Software, if you try to enable MPLS TE in more than one area, you get a warning like the one shown in Example 4-38. Example 4-38 Attempting to Configure Interarea TE Tunnels in Older Codegsr1(config)#router isis gsr1(config-router)#mpls traffic-eng level-2 gsr1(config-router)#mpls traffic-eng level-1 %MPLS TE already enabled, on isis level-2 gsr1(config-router)# With code that supports interarea tunnels, you don't get this warning, as demonstrated in Example 4-39. Example 4-39 Successfully Configuring Interarea TE Tunnelsgsr1(config)#router isis gsr1(config-router)#mpls traffic-eng level-2 gsr1(config-router)#mpls traffic-eng level-1 gsr1(config-router)# It's that simple. If all you want to do is have multiple intra-area tunnels (ABR1 to R1 and ABR1 to ABR3), you're done. However, if you want to build true interarea tunnels, there's a bit of headend work to be done. You have to specify an explicit path for the tunnel to take. This explicit path must use the loose ERO subobject for hops outside its own area. Why? When you configure an explicit path, each hop in that path is implicitly known as a strict hop. When a tunnel has an explicit route starting with strict hops, all the strict hops are checked against the TE database to make sure that they're valid. Because enabling interarea tunnels doesn't change the information flooding scheme, R1 does not know how to get to anything outside its area. Using the next-address loose command is a way of telling the next node in the ERO (the ABR, the one that has more than one TE database) that it needs to figure out what to do next. Make sense? Look at Figure 4-40 before we look at this concept in a little more detail. Figure 4-40. Network Topology with Interarea Tunnels
Example 4-40 shows the headend configuration on gsr4 when building a TE tunnel from gsr4 to gsr8. Example 4-40 gsr4 Headend Configurationinterface Tunnel8 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 192.168.1.8 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name interarea end ... ip explicit-path name interarea enable next-address 192.168.1.5 next-address loose 192.168.1.6 next-address loose 192.168.1.8 In Figure 4-40, the ABR is directly connected to the headend, so the explicit path has only a single next hop before specifying the loose hops. If the ABR were not directly connected to the tunnel headend, this path option would either specify the entire path to the ABR or would simply specify the first ABR with a loose path option. In the configuration shown in Example 4-40, the tunnel tail is specified as a loose hop in the explicit path option. Although this is not strictly necessary, not specifying the tunnel tail as a loose hop can cause signalling problems. The configuration shown in Example 4-40 says, "To build a TE tunnel to gsr8, first get to gsr5. Then tell gsr5 that it has to figure out how to get you to gsr6." gsr6 realizes that it is directly connected to gsr8 and forwards the Path message in that direction. When an ABR receives an ERO with a loose subobject as the next object in the ERO, it is the ABR's job to resolve that loose object into a strict one. The ERO is then sent on its way. At the tunnel headend, a loose subobject in the ERO results in slightly modified show mpls traffic-eng tunnels output, as demonstrated in Example 4-41. Example 4-41 Output of show mpls traffic-eng tunnels Showing a Loose ERO Subobject (Continued)gsr4#show mpls traffic-eng tunnels Tunnel8 Name: gsr4_t8 (Tunnel8) Destination: 192.168.1.8 Status: Admin: up Oper: up Path: valid signalling: connected path option 10, type explicit interarea (Basis for Setup, path weight 10) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare 100 bw-based auto-bw: disabled(0/219) 0 Bandwidth Requested: 100 InLabel : - OutLabel : POS4/1, 12309 RSVP Signalling Info: Src 192.168.1.4, Dst 192.168.1.8, Tun_Id 8, Tun_Instance 390 RSVP Path Info: My Address: 192.168.1.4 Explicit Route: 192.168.3.5 192.168.1.5 192.168.1.6* 192.168.1.8* Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 192.168.3.5 192.168.10.6 192.168.9.8 Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=Inf Shortest Unconstrained Path Info: Path Weight: UNKNOWN Explicit Route: UNKNOWN History: Tunnel: Time since created: 1 hours, 31 minutes Time since path change: 3 minutes, 9 seconds Current LSP: Uptime: 3 minutes, 9 seconds Prior LSP: ID: path option 10 [389] Removal Trigger: path error In the Explicit Route line, you can see that the headend has resolved next-address 192.168.1.5 into the path necessary to get to 192.168.1.5. 192.168.1.6, specified as next-address loose 192.168.1.6 in the explicit-path configuration, has an asterisk to signify that that hop in the ERO is a loose hop. 192.168.1.8 is listed the same way. When gsr5 gets the Path message for this LSP, it resolves the loose subobject 192.168.1.6 into a series of strict hops to get to 192.168.1.6 by running CSPF and taking into account this LSP's requested bandwidth. When gsr6 gets the Path message for this LSP, it resolves the loose subobject 192.168.1.8 into a series of strict hops to get to 192.168.1.8 by running CSPF and taking into account this LSP's request bandwidth. When gsr8 gets the Path message, it responds to this message by sending a Resv, just like it would in response to any other Path message. The Resv makes its way upstream, hop by hop, and when it reaches gsr4, the tunnel interface comes up. Figure 4-41 is a more complicated topology, so perhaps it is a more realistic example. Figure 4-41. More Complex Interarea Tunnel Topology
NOTE Figure 4-41 has three kinds of routers—CRs (Customer Routers), DRs (Distribution Routers), and WRs (WAN Routers). The prefixes L-, C-, and R- stand for Left, Core, and Right. See Chapter 9, "Network Design with MPLS TE," for a discussion of router-naming syntax. Here are some examples of how you might configure interarea tunnels between various routers. Rather than getting caught up in IP addressing schemes, the path options use router names rather than IP addresses. If you want to build a tunnel from L-CR1 to R-CR4, you might use the configuration shown in Example 4-42. Example 4-42 Sample Configuration for an Interarea TE Tunnelinterface Tunnel4 description Tunnel from L-CR1 to R-CR4 ip unnumbered Loopback0 tunnel destination R-CR4 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name to-R-CR4 ip explicit-path name to-R-CR4 next-address loose L-WR1 next-address loose R-WR1 next-address loose R-CR4 This configuration works fine. But what if L-WR1 or R-WR1 goes away? You don't want to have your interarea TE tunnels fail; you'd rather they reroute through L-WR2 or R-WR2. In the current implementation, if you have multiple permutations of ABRs to go through, you need to configure each one as a separate path option. Because there are two L-WRs and two R-WRs, this means you need to build four explicit paths:
Example 4-43 shows what a more thorough configuration on L-CR1 might look like. Example 4-43 Multiple Path Options in an Interarea Tunnel Configurationinterface Tunnel4 description Tunnel from L-CR1 to R-CR4 ip unnumbered Loopback0 tunnel destination R-CR4 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name to-R-CR4.1 tunnel mpls traffic-eng path-option 20 explicit name to-R-CR4.2 tunnel mpls traffic-eng path-option 30 explicit name to-R-CR4.3 tunnel mpls traffic-eng path-option 40 explicit name to-R-CR4.4 ip explicit-path name to-R-CR4.1 next-address loose L-WR1 next-address loose R-WR1 next-address loose R-CR4 ip explicit-path name to-R-CR4.2 next-address loose L-WR1 next-address loose R-WR2 next-address loose R-CR4 ip explicit-path name to-R-CR4.3 next-address loose L-WR2 next-address loose R-WR1 next-address loose R-CR4 ip explicit-path name to-R-CR4.4 next-address loose L-WR2 next-address loose R-WR2 next-address loose R-CR4 What order should you put the path options in? It's up to you. It makes sense to put them in the order that's most likely to succeed, although it really doesn't make much difference. It's hard to come up with a general rule. You need to take a look at your network and do whatever you find is best. However, having to lay out multiple path options looks like it might not scale all that well, for the following reasons:
It's reasonable to assume that the number of explicit path options you need to configure is no more than four. What Interarea Tunnels Cannot DoA few features currently are not supported with interarea traffic engineering:
Autoroute and Forwarding AdjacencyAutoroute and forwarding adjacency (both covered fully in Chapter 5) rely on the fact that the tunnel head and tunnel tail are in the same area. As such, you cannot build a tunnel across multiple areas and have either autoroute or forwarding adjacency work. To put packets down an interarea tunnel, you need to use static or policy routing. If you are taking advantage of interarea code to build intra-area tunnels (R1 to ABR1, ABR1 to ABR4, ABR3 to R4, and so on), autoroute and forwarding adjacency will work. It's only when you have a TE tunnel spanning multiple areas that autoroute and forwarding adjacency don't work. See Chapter 5 for a more detailed explanation of how autoroute and forwarding adjacency work, and why they don't work across areas. Tunnel AffinityThe current Cisco MPLS TE implementation does not signal tunnel affinity in the LSP setup. Instead, it relies on the fact that the TE extensions for IGP propagate link attributes in their advertisements. Because the headend does not see the entire topology in interarea tunnel setup, and because there's no way to tell an ABR what the headend affinity string and bitmask are, tunnel affinity cannot be supported for interarea TE LSPs. tunnel mpls traffic-eng path-option dynamic CommandA POP often has multiple exit points. One exit point might be much closer to the tunnel destination than another. Because the headend doesn't have the entire topology, it can't know which exit point is the best one to take. The same thing applies when going from the near-side ABR (for L-CR1, this is L-WR1 or L-WR2) to the far-side ABR: How does L-WR1 know what the best path is to get to R-CR4? In Figure 4-41, things are pretty symmetric, but that's not always the case in the real world. Because you need to tell the network which ABRs to go through from source to destination, you can't specify path-option dynamic. You need to specify explicit paths. ReoptimizationThis one is subtle. Reoptimization is the recalculation of a path from the head to the tail. What about that calculation is missing in multiarea TE? Break the problem into pieces. Clearly, from the headend's perspective, two places that reoptimization could happen are
Reoptimization within the headend's area happens normally. Only reoptimization outside the headend's area is different. In Figure 4-42, an LSP goes from Router A to Router L. Figure 4-42. Interarea Reoptimization
Example 4-44 shows the configuration for this LSP's explicit path-option. Example 4-44 LSP explicit path-option Configurationip explicit-path name to-L next-address loose E next-address loose J next-address loose L Router A knows the entire topology up to and including Router E. When reoptimization is triggered, either periodic, on demand, or driven by a link-up change in Area 1, Router L recalculates its path to Router E. However, the rest of the LSP (the part from E to L, through J) is never reoptimized. Why? Because there's currently no method for the headend to tell the ingress ABR that it wants a reoptimization. Because Router E can't tell the difference between a reoptimize-driven Path message and a refresh-driven Path message, it can't know when to reoptimize the LSP. The same thing applies to Router J. You don't want ABRs reoptimizing every time they get a Path message, because that could cause quite a lot of signalling and CPU load on the router. In the future, there will probably be more-complex mechanisms that let the ABRs reoptimize interarea LSPs for which they are midpoints, but for right now, the only reoptimization is done by the headend, and only in the headend area. |
|
|
< Free Open Study > |
|
R3 LSP gets to the other area, are called 
