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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
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.
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.
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
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.
Connectivity between CE routers is verified using extended pings between loopback interfaces on CE routers, as shown in Figure 9-22.
|
