Configuring MPLS TE

< Day Day Up >

Source : http://fengnet.com/book/ios_mpls/ch09lev1sec4.html

Configuring MPLS TE This section introduces you to the steps involved in the configuration of Cisco routers to implement MPLS TE. The first subsection identifies the stepwise procedure involved in the configuration of Cisco routers for TE. It is then followed by a subsection depicting the actual configuration process on a topology consisting of six routers in which multiple paths can be used for TE purposes from a headend to tailend router. MPLS TE Configuration Flowchart The configuration of Cisco routers for MPLS TE support can be described in a systematic flowchart as depicted in the top row of Figure 9-11. It is assumed that the network is already configured with an IGP for NLRI exchange as well as MPLS forwarding on the appropriate interfaces prior to performing the following steps: Step 1. Configure a loopback interface for tunnel association to the TE tunnel, as depicted in Figure 9-11. Figure 9-11. MPLS TE Configuration: Step 1 [View full size image] Step 2. The next step is the first configuration performed in relevance to enabling TE on the Cisco router. Figure 9-12 outlines the configurations performed on the Cisco router to enable TE functions globally on the router as well as interfaces that are possible candidates to be chosen for TE LSP paths. Figure 9-12. MPLS TE Configuration: Step 2 [View full size image] Step 3. Configure RSVP bandwidth parameters that will be used on the interface for signaling purposes and resource allocation for traffic engineered sessions. Figure 9-13 outlines the configurations that need to be performed on the interface. Figure 9-13. MPLS TE Configuration: Step 3 [View full size image] Step 4. After the interfaces that can be chosen to be a part of the LSP have been enabled for TE as well as RSVP parameters configured, the next step is to configure the tunnel interface. The main configurations of the tunnel interface would be association of the tunnel interface IP address to the loopback address configured earlier, the mode of the tunnel operation, and the destination address of the tunnel endpoint, which would map to the IP address of a loopback on the tailend router as well as the process by which the tunnel LSP path is chosen. In this step, if the path chosen for the LSP is done using the IGP and CSPF, the path option is chosen to be dynamic. Figure 9-14 depicts the configuration involved in setting up the tunnel interface. Figure 9-14. MPLS TE Configuration: Step 4 [View full size image] Step 5. In addition to using the IGP for LSP path setup, the user can also define an explicit-path that will be used for the TE LSP. This optional step can be performed on the headend router so that the dynamic tunnel can be chosen to be the tunnel of choice for traffic forwarding and the explicit-path tunnel or user-defined static tunnel can be the backup path. In some cases, load balancing can also be achieved between the two types. Figure 9-15 depicts the configurations to set up an explicit-path LSP. Figure 9-15. MPLS TE Configuration: Step 5 [View full size image] Step 6. By default, the tunnel interface is not announced into the IGP for use in the routing table. This will have to be configured explicitly for the tunnel interface to be used as the next hop in the routing table by the IGP. Figure 9-16 outlines the configurations that will have to be performed on the headend router to enable tunnel interface use as the next-hop address in the routing table for TE. Figure 9-16. MPLS TE Configuration: Step 6 [View full size image] Step 7. The final step in the configuration of MPLS TE is the configuration of the IGP for TE support. The IGP in use can be either OSPF or IS-IS. The IGP process used for TE is the same as what's defined for NLRI reachability. The configurations involved for enabling TE extensions for both these protocols are outlined in Figure 9-17. Figure 9-17. MPLS TE Configuration: Step 7 [View full size image] Configuring Dynamic Paths and Explicit Paths with MPLS TE Figure 9-18 outlines the layout of the devices in the network that will be used to configure MPLS TE using dynamic and explicit paths. Prior to the following configurations, the devices shown in Figure 9-18 are configured with appropriate IP addresses on the interfaces as well as OSPF as the IGP. In addition, MPLS forwarding has been enabled on all interfaces in the network, as shown in Figure 9-18. Figure 9-18. MPLS TE Configuration Topology [View full size image] The following steps show how to configure dynamic paths and explicit paths with MPLS TE: Step 1. Configure a loopback interface for tunnel association. This IP address can be used as the router ID in the various processes on the router (see Example 9-1). Example 9-1. Configure Loopback Interface for Tunnel Association PE1-AS1(config)#interface loopback 0 PE1-AS1(config-if)# ip address 10.10.10.101 255.255.255.255 Step 2. Enable TE globally on the router and per interface. Because we want the headend router to take all links in the network as possible links for LSP path setup, this interface-specific configuration is performed on all links in the network topology shown in Figure 9-18. Only the configuration pertaining to PE1-AS1 is shown in Example 9-2. Example 9-2. Enable TE on the Router and per Interface PE1-AS1(config)#mpls traffic-eng tunnels PE1-AS1(config)#interface serial 2/0 PE1-AS1(config-if)#mpls traffic-eng tunnels PE1-AS1(config-if)#interface serial 3/0 PE1-AS1(config-if)#mpls traffic-eng tunnels PE1-AS1(config-if)#interface serial 4/0 PE1-AS1(config-if)#mpls traffic-eng tunnels Step 3. Configuring RSVP bandwidth parameters—Because we have chosen to include all interfaces in the network topology to be considered for LSP path setup, this configuration is performed on all interfaces. The chosen RSVP bandwidth configured on all interfaces is 256 K with the maximum that can be allotted to a single flow also 256 K. The configuration of headend Router PE1-AS1 is shown in Example 9-3. Example 9-3. Configure RSVP Parameters per Interface PE1-AS1(config)#interface serial 2/0 PE1-AS1(config-if)#ip rsvp bandwidth 256 256 PE1-AS1(config-if)#interface serial 3/0 PE1-AS1(config-if)#ip rsvp bandwidth 256 256 PE1-AS1(config-if)#interface serial 4/0 PE1-AS1(config-if)#ip rsvp bandwidth 256 256 Step 4. Configuring tunnel interface parameters on the headend router—On headend Router PE1-AS1, the tunnel destination is the loopback on Router PE2-AS1 (10.10.10.103). First, dynamic tunnels are configured in which the IGP performs a CSPF calculation and identifies the appropriate LSP path. Therefore, the path-option for this tunnel creation would be dynamic. The tunnel is defined with a priority of 1 and a bandwidth requirement of 100 K. In addition, the tunnel is also provided a setup and hold priority of 1 to define that this is the most preferred tunnel LSP in the domain. See Example 9-4. Example 9-4. Configure Tunnel Interface Parameters on PE1-AS1 PE1-AS1(config)#interface Tunnel0 PE1-AS1(config-if)# ip unnumbered Loopback0 PE1-AS1(config-if)# tunnel destination 10.10.10.103 PE1-AS1(config-if)# tunnel mode mpls traffic-eng PE1-AS1(config-if)# tunnel mpls traffic-eng priority 1 1 PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 100 PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic Step 5. Configuring dynamic tunnel announcement into IGP—In this step, the tunnel interface is configured to be added into the IGP routing table to enable traffic forwarding along the tunnel. See Example 9-5. Example 9-5. Announce Tunnel Interface into IGP PE1-AS1(config)#interface Tunnel0 PE1-AS1(config-if)#tunnel mpls traffic-eng autoroute announce Step 6. Configure explicit-path tunnel—In this step, an explicit-path tunnel named LSP1 is configured via P2-AS1 between PE1-AS1 and PE2-AS1. Configure the tunnel interface with appropriate parameters. The tunnel is configured with association to the same loopback address as used earlier with the same destination address on PE2-AS1. The resource requirements of the tunnel are also maintained. However, the tunnel priorities are configured to be 2 versus 1 in the prior dynamic tunnel configuration so that the dynamic tunnel is not chosen over the explicit tunnel for establishing primary LSP. Also, the path-option maps to the name of an explicit-path are configured on the headend router that maps to next-hop addresses in the LSP path. See Example 9-6. Example 9-6. Configure Tunnel Interface on PE1-AS1 PE1-AS1(config)#interface Tunnel1 PE1-AS1(config-if)# ip unnumbered Loopback0 PE1-AS1(config-if)# tunnel destination 10.10.10.103 PE1-AS1(config-if)# tunnel mode mpls traffic-eng PE1-AS1(config-if)# tunnel mpls traffic-eng priority 2 2 PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 100 PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name LSP1 Step 7. Configure the explicit-path with next-hop IP addresses of routers in the LSP path, as depicted in Example 9-7. Example 9-7. Configuration of Explicit LSP Path PE1-AS1(config)#ip explicit-path name LSP1 PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.10 Explicit Path name LSP1: 1: next-address 10.10.10.10 PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.14 Explicit Path name LSP1: 1: next-address 10.10.10.10 2: next-address 10.10.10.14 PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.103 Explicit Path name LSP1: 1: next-address 10.10.10.10 2: next-address 10.10.10.14 3: next-address 10.10.10.103 Step 8. Configure the tunnel interface to be announced into IGP to be the preferred path for traffic engineered traffic in the domain. See Example 9-8. Example 9-8. Announce Tunnel Interface into IGP PE1-AS1(config)#interface Tunnel1 PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce Step 9. Enable IGP for MPLS TE—The configurations on Router PE1-AS1 to enable OSPF for MPLS TE are shown in Example 9-9. The router ID configured under the MPLS TE module in OSPF and IS-IS is the loopback interface on the local router. This configuration needs to be performed on all routers in the TE domain. Example 9-9. Configure IGP for MPLS TE PE1-AS1(config)#router ospf 100 PE1-AS1(config-router)#mpls traffic-eng area 0 PE1-AS1(config-router)#mpls traffic-eng router-id loopback 0 Verification of MPLS TE Tunnel Creation The following steps outline the various commands that can be entered on PE1-AS1 (after the just mentioned configuration) to determine if the TE tunnel has been created successfully on the router (headend): Step 1. Perform a show mpls traffic-eng tunnels brief on the headend Routers PE1-AS1 and P1-AS1 in the LSP path, as well as the tailend Router PE2-AS1 to verify the tunnel state is up/up. The output of the command also gives us information on the LSP path in the tunnel setup. UP IF defines the upstream interface for the tunnel, and DOWN IF defines the downstream interface for the tunnel. See Example 9-10. Example 9-10. show mpls traffic-eng tunnels brief on Tunnel LSP Path Routers PE1-AS1#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled Periodic reoptimization: every 3600 seconds, next in 3206 seconds Periodic FRR Promotion: Not Running Periodic auto-bw collection: every 300 seconds, next in 206 seconds TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT PE1-AS1_t0 10.10.10.103 - Se3/0 up/up PE1-AS1_t1 10.10.10.103 - Se2/0 up/up Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails _________________________________________________________________________________ P1-AS1#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled Periodic reoptimization: every 3600 seconds, next in 2951 seconds Periodic FRR Promotion: Not Running Periodic auto-bw collection: every 300 seconds, next in 251 seconds TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT PE1-AS1_t0 10.10.10.103 Se2/0 Se4/0 up/up Displayed 1 (of 1) heads, 1 (of 1) midpoints, 0 (of 0) tails _________________________________________________________________________________ PE2-AS1#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled Periodic reoptimization: every 3600 seconds, next in 2857 seconds Periodic FRR Promotion: Not Running Periodic auto-bw collection: every 300 seconds, next in 157 seconds TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT PE1-AS1_t0 10.10.10.103 Se3/0 - up/up PE1-AS1_t1 10.10.10.103 Se2/0 - up/up Step 2. A view of the actual parameters of the tunnel can be retrieved by performing a show mpls traffic-eng tunnels destination ip-address (only Tunnel 0 depicted in Example 9-8) or a show mpls traffic-eng tunnels tunnel interface-number. As illustrated in Example 9-11, the output shows the status of the tunnel and the information about the parameters associated with the tunnel. In addition, it shows the preferred path chosen by the CSPF process under the explicit-path field in the output of the command, as shaded in Example 9-11. Example 9-11. MPLS TE Verification: Tunnel Parameters PE1-AS1#show mpls traffic-eng tunnels destination 10.10.10.103 Name: PE1-AS1_t0 (Tunnel0) Destination: 10.10.10.103 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 20) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: disabled Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : Serial3/0, 26 RSVP Signalling Info: Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71 RSVP Path Info: My Address: 10.10.10.101 Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits History: Tunnel: Time since created: 3 hours, 42 minutes Time since path change: 33 minutes, 26 seconds Current LSP: Uptime: 33 minutes, 26 seconds _________________________________________________________________________________ PE1-AS1#show mpls traffic-eng tunnels tunnel 0 Name: PE1-AS1_t0 (Tunnel0) Destination: 10.10.10.103 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 20) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: disabled Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : Serial3/0, 26 RSVP Signalling Info: Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71 RSVP Path Info: My Address: 10.10.10.101 Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 20 (TE) Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103 History: Tunnel: Time since created: 3 hours, 42 minutes Time since path change: 33 minutes, 47 seconds Current LSP: Uptime: 33 minutes, 47 seconds Step 3. Verify that the next hop to the destination IP address points to the tunnel interfaces in the IGP routing table. Only routes to network 10.10.10.103 (destination) pointing to the tunnel interface as the next hop are shown for brevity. See Example 9-12. Because we have two tunnels configured on Router PE1-AS1 (dynamic and explicit) with the same parameters, the traffic to destination 10.10.10.103 is load balanced equally among the two paths, as shown in Example 9-12, because the bandwidths configured on the TE tunnels are the same. Traffic from PE1-AS1 to PE2-AS1 is equally load balanced across the two tunnels. Example 9-12. Verify Next-Hop Mapping to Tunnel Interface (Truncated) PE1-AS1#show ip route 10.10.10.103 Routing entry for 10.10.10.103/32 Known via "ospf 100", distance 110, metric 97, type intra area Routing Descriptor Blocks: * directly connected, via Tunnel0 Route metric is 97, traffic share count is 1 directly connected, via Tunnel1 Route metric is 97, traffic share count is 1 Step 4. By performing an extended ping to the destination loopback address on PE2-AS1, we see that the packets are load balanced across the two tunnel paths. See Example 9-13. Example 9-13. Extended Ping Verification for MPLS TE Tunnel Path PE2-AS1#ping Protocol [ip]: Target IP address: 10.10.10.103 Repeat count [5]: 2 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.10.10.101 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: r Number of hops [ 9 ]: 4 Loose, Strict, Record, Timestamp, Verbose[RV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 10.10.10.103, timeout is 2 seconds: Reply to request 0 (28 ms). Received packet has options Total option bytes= 40, padded length=40 Record route: (10.10.10.103) (10.10.10.6) (10.10.10.2) (10.10.10.101) <*> End of list Reply to request 1 (28 ms). Received packet has options Total option bytes= 40, padded length=40 Record route: (10.10.10.103) (10.10.10.14) (10.10.10.10) (10.10.10.101) <*> End of list Final Configurations for Dynamic and Explicit Tunnels with MPLS TE Example 9-14 and Example 9-15 outline the final configurations for all devices in Figure 9-18 for implementation of dynamic and explicit tunnels from PE1-AS1 to PE2-AS1. Example 9-14. Final Configurations for PE1-AS1 and PE2-AS1 to Implement Dynamic and Explicit Tunnels hostname PE1-AS1 ! ip cef ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.10.10.103 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic tunnel MPLS traffic-eng bandwidth 100 ! interface Tunnel1 ip unnumbered Loopback0 tunnel destination 10.10.10.103 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 2 2 tunnel mpls traffic-eng path-option 1 explicit name LSP1 tunnel MPLS traffic-end bandwidth 100 ! interface Serial2/0 ip address 10.10.10.9 255.255.255.252 mpls traffic-eng tunnels tag-switching ip fair-queue 64 256 48 ip rsvp bandwidth 1000 ! interface Serial3/0 ip address 10.10.10.1 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial4/0 ip address 10.10.10.17 255.255.255.252 mpls traffic-eng tunnels MPLS ip ip rsvp bandwidth 1000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.0.0.0 0.255.255.255 area 0 ! ip explicit-path name LSP1 enable next-address 10.10.10.10 next-address 10.10.10.14 next-address 10.10.10.103 ! end ____________________________________________________________________________ hostname PE2-AS1 ! ip cef ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.103 255.255.255.255 ! interface Serial2/0 ip address 10.10.10.14 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial3/0 ip address 10.10.10.6 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial4/0 ip address 10.10.10.22 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.0.0.0 0.255.255.255 area 0 ! end Example 9-15. Final Configurations for P1-AS1, P2-AS1, and P3-AS1 to Implement Dynamic and Explicit Tunnels hostname P1-AS1 ! ip cef ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Serial2/0 ip address 10.10.10.2 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial3/0 ip address 10.10.10.26 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial4/0 ip address 10.10.10.5 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.0.0.0 0.255.255.255 area 0 ! end __________________________________________________________________________ hostname P2-AS1 ! ip cef ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.104 255.255.255.255 ! interface Serial2/0 ip address 10.10.10.10 255.255.255.252 mpls traffic-eng tunnels MPLS ip ip rsvp bandwidth 1000 ! interface Serial3/0 ip address 10.10.10.13 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.0.0.0 0.255.255.255 area 0 ! end __________________________________________________________________________ hostname P3-AS1 ! ip cef ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.105 255.255.255.255 ! interface Serial2/0 ip address 10.10.10.18 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial3/0 ip address 10.10.10.25 255.255.255.252 no ip directed-broadcast mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! interface Serial4/0 ip address 10.10.10.21 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.0.0.0 0.255.255.255 area 0 ! end Unequal Cost Load Balancing Across Multiple TE Tunnels In this section, we will configure another tunnel via the path PE1-AS1, P3-AS1, and PE2-AS1 with bandwidth requirements of 50 kbps versus 100 kbps. In every five packets, load balancing is performed so that two packets are sent on Tunnel 0, two on Tunnel 1, and one packet on Tunnel 2. In this case, if the source and destination of the tunnel interfaces are the same, the traffic between the sites performs unequal cost load balancing among the various tunnels between Routers PE1-AS1 and PE2-AS1. The configuration on PE1-AS1 (headend router) for another explicit LSP path setup via the path PE1-AS1, P3-AS1, and PE2-AS1 is shown in Example 9-16. Example 9-16. Unequal Cost Load Balancing Configuration on PE1-AS1 PE1-AS1(config)#interface Tunnel2 PE1-AS1(config-if)# ip unnumbered Loopback0 PE1-AS1(config-if)# tunnel destination 10.10.10.103 PE1-AS1(config-if)# tunnel mode mpls traffic-eng PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce PE1-AS1(config-if)# tunnel mpls traffic-eng priority 3 3 PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 50 PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name LSP2 PE1-AS1(config)#ip explicit-path name LSP2 enable PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.18 Explicit Path name LSP2: 1: next-address 10.10.10.18 PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.22 Explicit Path name LSP2: 1: next-address 10.10.10.18 2: next-address 10.10.10.22 PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.103 Explicit Path name LSP2: 1: next-address 10.10.10.18 2: next-address 10.10.10.22 3: next-address 10.10.10.103 PE1-AS1(cfg-ip-expl-path)#end After the configuration is performed, the output of the routing table entry for 10.10.10.103/32 shows the unequal cost load balancing in effect (see Example 9-17). Example 9-17. Verification of Unequal Cost Load Balancing PE1-AS1#show ip route 10.10.10.103 Routing entry for 10.10.10.103/32 Known via "ospf 100", distance 110, metric 97, type intra area Routing Descriptor Blocks: * directly connected, via Tunnel0 Route metric is 97, traffic share count is 2 directly connected, via Tunnel1 Route metric is 97, traffic share count is 2 directly connected, via Tunnel2 Route metric is 97, traffic share count is 1 Therefore, the final configuration for PE1-AS1 includes, in addition to Example 9-14, the configuration shown in Example 9-18. Example 9-18. Additional Configuration on PE1-AS1 for Unequal Cost Load Balancing interface Tunnel2 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 10.10.10.103 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 3 3 tunnel mpls traffic-eng bandwidth 50 tunnel mpls traffic-eng path-option 1 explicit name LSP2 MPLS TE Fast ReRoute Link Protection Fast ReRoute (FRR) is a procedure used in conjunction with MPLS TE to reroute around a link in the case of link failure. Protection in networks can be provided by SONET, optical protection, or, more recently, MPLS FRR. With MPLS FRR, we can implement both link and node protection. In addition, different protection policies can be applied to different classes of traffic traversing the MPLS backbone. In FRR operation, a backup tunnel is configured to be used if the primary tunnel LSP fails. The backup tunnel must be configured so that the LSP can get to the next-hop LSR downstream without attempting to use the failed link. The configuration for implementing FRR for link protection is simple to implement. If you use a subset of the network shown in Figure 9-18 to implement link protection, as illustrated in Figure 9-19, you can configure a backup tunnel on the LSR P1-AS1. If the primary tunnel from PE1-AS1 via P1-AS1 to PE2-AS1 fails due to link failure between P1-AS1 and PE2-AS1, the backup tunnel is used to forward traffic. Figure 9-19. MPLS FRR Network Topology, Configuration, and Verification [View full size image] Configuration of the tunnel (Tunnel0 on PE1-AS1) to be protected from a link failure includes the tunnel mpls traffic-eng fast-reroute command under the tunnel interface configuration on the headend router (PE1-AS1) to enable FRR protection on the tunnel. In addition, a backup tunnel, Tunnel100, is configured on the downstream LSR (in our case, P1-AS1) to reroute traffic if the link between P1-AS1 and PE2-AS1 fails. Configuration is performed following the procedure shown in the earlier sections with an explicit path from P1-AS1 to PE2-AS1 via P3-AS1. Finally, this tunnel (Tunnel100) on P1-AS1 is associated to the link to be protected by using the command mpls traffic-eng backup-path tunnel tunnel100 under the interface to be protected (Serial 4/0 on P1-AS1). Verification of FRR capabilities can be performed by issuing the show mpls traffic-eng fast-reroute database detail command on the downstream LSR configured with a backup tunnel, as shown in Figure 9-19. Implementing MPLS VPNs over MPLS TE MPLS was initially adopted due to its inherent properties to deliver VPNs. However, in recent years, MPLS TE has gained popularity due to the robust TE capabilities it provides. In this section, we will discuss the configurations involved in the implementation of MPLS VPN over TE tunnels. TE tunnels can be configured between PE to PE routers as well as from PE to provider core or P routers. The configurations involved in both of these implementations of MPLS TE in the provider core are introduced. The network used to implement MPLS VPN over TE tunnels is shown in Figure 9-20. Figure 9-20. MPLS VPN Over TE Network Topology/Configuration [View full size image] For simplicity, the OSPF PE-CE connectivity implementation is used on both PE Routers PE1-AS1 and PE2-AS1 in Figure 9-20. For this section, the IGP used in the core is OSPF with process-id 100. The process-id for the PE to CE connections is configured under OSPF 1. All networks are in area 0. The configurations on Routers P1-AS1, CE1-A, and CE2-A are illustrated in Figure 9-20. Configurations for PE1-AS1 and PE2-AS1 are illustrated in Example 9-19. A tunnel is already configured with a dynamic path-option between PE1-AS1 and PE2-AS1. Example 9-19. PE1-AS1 and PE2-AS1 Configuration: MPLS VPN Over TE with PE to PE Tunnels hostname PE1-AS1 ! ip cef ! ip vrf VPNoverTE rd 1:100 route-target export 1:100 route-target import 1:100 ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.10.10.103 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic ! interface Serial2/0 ip vrf forwarding VPNoverTE ip address 172.16.1.1 255.255.255.252 ! interface Serial3/0 ip address 10.10.10.1 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 256 256 ! router ospf 1 vrf VPNoverTE redistribute bgp 100 metric 10 subnets network 172.16.1.0 0.0.0.3 area 0 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.10.10.0 0.0.0.3 area 0 network 10.10.10.101 0.0.0.0 area 0 ! router bgp 100 bgp router-id 10.10.10.101 neighbor 10.10.10.103 remote-as 100 neighbor 10.10.10.103 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family ! address-family ipv4 vrf VPNoverTE redistribute ospf 1 vrf VPNoverTE metric 2 exit-address-family ! end ___________________________________________________________________________________ hostname PE2-AS1 ! ip cef ! ip vrf VPNoverTE rd 1:100 route-target export 1:100 route-target import 1:100 ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.10.10.103 255.255.255.255 ! interface Serial3/0 ip address 10.10.10.6 255.255.255.252 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 256 256 ! interface Serial4/0 ip vrf forwarding VPNoverTE ip address 172.16.2.1 255.255.255.252 ! router ospf 1 vrf VPNoverTE redistribute bgp 100 metric 2 subnets network 172.16.2.0 0.0.0.3 area 0 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.10.10.4 0.0.0.3 area 0 network 10.10.10.103 0.0.0.0 area 0 ! router bgp 100 bgp router-id 10.10.10.103 neighbor 10.10.10.101 remote-as 100 neighbor 10.10.10.101 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended exit-address-family ! address-family ipv4 vrf VPNoverTE redistribute ospf 1 vrf VPNoverTE metric 2 exit-address-family ! end Verification of MPLS VPN over TE with PE to PE Tunnels Figure 9-21 outlines the various verification steps for identifying the operation of MPLS VPNs over TE with PE to PE tunnels. Figure 9-21. MPLS VPN over TE Verification—PE to PE Tunnels [View full size image] Figure 9-21 illustrates the routing tables on CE routers in which the CE routers learn the routes from the remote CEs via the MPLS backbone and place them in their local routing tables as OSPF IA routes, though all CE routes are in area 0 because sham-links are not configured. Figure 9-21 also shows the routing table on the respective PE routers for the VRF VPNoverTE to check for route propagation in the MPLS VPN domain. As can be derived from the output, the appropriate VPN routes obtained from the remote CEs are learned from the next hop that maps to the remote PE loopback. A closer look at the prefix 172.16.1.102 (loopback0 on CE2-A), learned across the MPLS domain one PE1-AS1, indicates a next-hop address of the remote PE loopback 10.10.10.103 (lo0 on PE2-AS1). In the global routing table, if this VPN forwards traffic over the MPLS TE tunnel configured on PE1-AS1, the next-hop address of 10.10.10.103 must point to the tunnel interface (Tunnel0) as shown in Figure 9-21 by the output of show ip route 10.10.10.103 on PE1-AS1. In addition, note that in the label-stack imposed on the packets in the MPLS domain when implementing MPLS VPN over TE (one label for MPLS VPN and the top label for TE), the top label maps to the label assigned by RSVP for the traffic engineered LSP path. Therefore, the out-label value in the output of show MPLS traffic-eng tunnels tunnel0 (16) maps to the top label in the label stack, as highlighted in the output of show ip cef vrf VPNoverTE 172.16.1.102 in Figure 9-21. For final verification of connectivity, an extended ping is performed between loopback interfaces on CE routers, as shown in Figure 9-21. Configuration of MPLS VPN over TE with PE to P Tunnels In the preceding section, MPLS VPN was configured over TE tunnels in which the TE tunnel was configured between the two PE routers in the MPLS domain. Another possibility that might arise while deploying MPLS VPN over a TE enabled domain is a tunnel existing between a PE router and a provider core router. In our existing setup, the tunnel interface, Tunnel 0, configured on the PE Router PE1, is changed so that the destination of the tunnel is the loopback address on P1 or 10.10.10.102/32 (see Example 9-20). This configuration might be used in conjunction with FRR to enable link protection in the SP backbone for MPLS forwarded traffic belonging to a customer. Example 9-20. Configuration on PE1-AS1: Tunnel Destination Changed to 10.10.10.102/32 PE1-AS1(config)#interface tunnel 0 PE1-AS1(config-if)# tunnel destination 10.10.10.102 If no other changes in configuration are made on any router, the CE routers no longer have connectivity to one another because the LSP is broken, as shown in Example 9-21. Example 9-21. CE1-AS1 Cannot Reach CE2 Because LSP Is Broken CE1-AS1#ping 172.16.1.102 source 172.16.1.101 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.102, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) To enable a complete LSP, MPLS is enabled on the tunnel interface on PE1-AS1. Also, P1-AS1 is configured to accept directed hellos, as shown in Example 9-22. Example 9-22. Enabling MPLS on the Tunnel Interface and Configuring Directed-Hello Accept on P1-AS1 PE1-AS1(config)#interface tunnel 0 PE1-AS1(config-if)#mpls ip __________________________________________________________________________________ P1-AS1(config)#mpls ldp discovery targeted-hello accept Because the P1-AS1 router can accept directed hellos from neighbors who are not directly connected, the LSP is now established using the tunnel. This is shown in Figure 9-22 where the next hop for the remote CE loopback interfaces point to the interface tunnel 0 on PE1-AS1. Figure 9-22. MPLS VPN Over TE Verification—PE to P Tunnels [View full size image] Connectivity between CE routers is verified using extended pings between loopback interfaces on CE routers, as shown in Figure 9-22.

< Day Day Up >