Ab - MPLS Te

CHAPTER 8: MPLS Traffic Engineering
• MPLS TE allows for a TE scheme where the head-end router of the LSP can
calculate the most efficient route through the network towards the tail-end
router of the LSP.
• MPLS TE provides efficient traffic forwarding through the network, avoiding
underutilized and over-utilized links.
• MPLS TE takes into account the configured (static) bandwidths of links.
• MPLS TE takes link attributes into account (like delay, jitter)
• MPLS TE adapts automatically to changing bandwidth and link attributes
• Source-based routing is applied to the traffic-engineered load as opposed to
the IP destination-based routing
• Only link-state routing protocols can be used, as the bandwidth and link
attributes have to be known by the head-end router of the LSP since all routers
have the same topology information of the area running a link-state routing
protocol.
Building blocks of MPLS TE:

1. Link constraints- how much traffic each link can support and which TE tunnel can
use the link
2. TE information distribution (using link-state routing protocols like OSPF or IS-IS)
3. PCALC/CSPF- An algorithm to calculate the best path from the head-end router to
the tail-end router of the LSP
4. RSVP- A signalling protocol to signal the TE tunnel across the network
5. A way to forward traffic onto the tunnel using Static routing, Policy-based routing,
Autoroute, Forwarding adjacency and Class-based Tunnel Selection
Distribution of TE information:
• The head-end of the TE tunnel must have all topology information to see all
the possible paths, but it must also have the constraints information of the
links available to it.
• OSPF or IS-IS must be extended to carry these constraints information.
• These constraints information for the TE tunnel of the links are as follows-
1. TE metric- It can be used to construct a TE topology. By default, the TE metric is

same as IGP metric but can be changed. It can be configured on the link using
interface fastethernet 0/1
mpls traffic-eng administrative-weight <value>
2. Maximum bandwidth- It is the total (physical or configured) bandwidth of the

link.
3. Maximum reservable bandwidth- It is the bandwidth available to the TE. It can
be configured using ip rsvp bandwidth command on the interface.
4. Unreserved bandwidth- It is the remainder of the bandwidth that is available to

TE. It is maximum reservable bandwidth minus the total bandwidth currently reserved
by the TE tunnels crossing this link.
5. Administrative group (Attribute flags)- It is a 32-bit field with no syntax. The

operator can set each bit individually and have a meaning chosen by him.
OSPF Extensions for TE-
• Three new LSAs were defined called Opaque LSAs. Opaque LSA type 9 has a
flooding scope limited to local-link. Opaque LSA type 10 has a flooding scope
limited to the area (intra-area) and Opaque LSA type 11 has a flooding scope
that is autonomous system wide (inter-area like LSA type 5).
• MPLS TE uses LSA type 10 for intra-area MPLS TE.
• A new bit was defined ‘O’ in the Options field of OSPF Hello packet header.
It indicates whether a router is capable of sending and receiving Opaque
LSAs. The Options field is present in OSPF Hello, DBD packets and all
LSAs.
• The TE LSA Type 10 carries one or more TLVs. These TLVs carry specific
MPLS TE data.
• The Router TLV carries the router ID for TE.
• The Link TLV carries a set of sub-TLVs describing a single link for MPLS
TE.
The Link Type indicates whether the link is point-to-point or multi-access. The Link
ID is set to the router ID of the neighbor. The bandwidth parameters are specified in
bytes per second. The Unreserved bandwidth is 32 bytes because it is the available
bandwidth at each priority level (8 priority levels from 0 to 7).
These parameters can be viewed using show ip ospf database opaque-area command
on the head-end router.
The IGP floods TE information in the following cases-

1. Link Status changes
2. Configuration change
3. Periodic flooding (3 minutes by default)
4. Changes in the reserved bandwidth
5. After a tunnel setup failure
MPLS TE Tunnel Attributes:

1. Tunnel Destination: It is the MPLS TE router-ID of the tail-end LSR. It is
specified under tunnel-interface configuration mode-
interface Tunnel 1
tunnel destination 4.4.4.4
2. Desired/Requested bandwidth: This is the requested bandwidth for a particular

TE tunnel.
interface Tunnel 1
tunnel mpls traffic-eng bandwidth [sub-pool | global] <bandwidth>
The global keyword indicates a regular TE tunnel, and sub-pool keyword indicates a
Diffserve-aware TE tunnel.
3. Affinity bits: A link can have attribute flags associated with it. These attribute
flags indicate whether a tunnel with specific resources can cross that link.

mpls traffic-eng attribute-flags <attribute-flags>
Range of attribute-flags is 0x0 to 0xFFFFFFFF.
On the tunnel configuration on the head-end router, affinity bits and mask can be
configured to control whether the tunnel is allowed to cross the link with those
attribute-flags.
interface Tunnel 1
tunnel mpls traffic-eng affinity <properties> mask <mask>
The default properties value is 0x0 and mask is 0x0000FFFF.
The nth-bit of Attribute-flag should match the nth-bit of Affinity properties if the nth-
bit of the mask is 1; if the nth-bit of mask is 0, no match is required.
4. Path setup Option: You can configure the path option on the tunnel configuration
on the head-end router. A tunnel path can be set-up either explicitly or dynamically.
In Explicit way, you specify the router-ID or link IP addresses of all the routers along
the path to the tail-end router (including the tail-end router).
In dynamic way, you let the head-end router figure out how the TE tunnel should be
best routed through the network toward the tail-end router.
To configure,
interface Tunnel 1
tunnel mpls traffic-eng path-option 1 explicit name TE_PATH
tunnel mpls traffic-eng path-option 2 dynamic
!
ip explicit-path name TE_PATH
next-address 1.1.1.1
The more preferred path option is tried first. Only if the path is not available, the next
option is tried.
5. Setup and Holding Priorities: Both the setup and holding priorities indicate with
their relative values whether a TE tunnel can pre-empt another tunnel. The lower the
priority value, the higher the importance.
interface Tunnel 1
tunnel mpls traffic-eng priority <setup-priority> <holding-priority>
The setup priority indicates how important the tunnel is to pre-empt another tunnel(s).
The holding priority indicates how much the weight of the tunnel is to hold on to its
reservations on the link. When a tunnel is first set up, its Setup priority is considered
when deciding whether to admit or cancel the tunnel. When another tunnel comes
along and competes with the existing tunnel for link bandwidth, the Setup priority os
new tunnel is compared to the Holding priority of the existing tunnel.
Very important tunnel should be configured with setup priority and holding priority
set to 0.
Range of setup and holding priority is 0 to 7 with 0 being highest priority.
6. Reoptimization: A TE tunnel can end up on a path that is no longer the best or

optimal path for it. It could be because an unavailable link is now available. Since the
reservations are already made, Reoptimization is required.
Three types of triggers can cause Reoptimization-
a) Periodic Reoptimization- Occurs every 1 hour by default
To change the frequency,
mpls traffic-eng reoptimize timers frequency <interval>

The interval range is 0 (to disable Reoptimization) to 604,800 seconds.
b) Event-Driven Reoptimization- By default, Reoptimization does not trigger when

an unavailable link is available for TE tunnel.
To configure,
mpls traffic-eng reoptimize events link-up
c) Manual Reoptimization: To force immediate Reoptimization,
mpls traffic-eng reoptimize tunnel <number>
PCALC- Path Calculation:
• PCALC is the special SPF algorithm (called CSPF) that MPLS TE uses.
• OSPF/IS-IS has been extended to carry link resources/constraints and so
PCALC can calculate the path not just based on cost but based on these
resources.
• Links that do not have sufficient bandwidth or that do not have right resources
are pruned off while the SPF tree is built.
• The result of PCALC is a Path.
• This path is an explicit path which is a sequence of IP addresses, where each
IP address represents an interface on the router.
• This explicit path is then used to setup or signal the TE LSP.
• PCALC always builds only one path, not two or more.
RSVP:
• RSVP uses PATH and RESV messages to signal a TE tunnel.

• The TE head-end router sends the PATH message while the tail-end router
returns the RESV message following the exact path but in opposite direction.
• The head-end router either uses dynamic or explicit path option to send the
PATH messages. This path is put in an ERO (Explicit Route Object) and each
LSR along the path removes its own IP address from the ERO and forwards
the PATH message towards the tail-end router.
• The tail-end router returns the RESV message along the same path but in
opposite direction.
• When the head-end router receives the RESV message without RSVP error
messages, the TE tunnel is setup.
• RSVP also performs the task to carry MPLS labels so that packets can be
label-switched along the path of the TE tunnel.
• The PATH messages carry a Label Request Object. When the tail-end router
receives this object, it assigns a label to this TE tunnel LSP and advertises it to
its upstream router (penultimate hop router) in an RESV message.
• The tail-end router advertises the explicit NULL label to the penultimate hop
LSR, which the penultimate router interprets as an implicit NULL label, and
hence performs PHP.
• This label becomes the outgoing label in LFIB of PHP router for this TE
tunnel LSP. The PHP router then advertises the RESV message with its own
label for the TE tunnel LSP to its upstream LSR.
• This continues until the RESV message reaches the head-end router.
• Thus, the top label (TE tunnel label) is popped off at the penultimate hop
router.
Step-by-step LSP Setup (RSVP-TE Signalling):
PARIS BRUSSELS ROME
PATH: PATH: PATH:
Session Object (10.200.254.5, 1, Session Object (10.200.254.5, 1, Session Object

10.200.254.2) 10.200.254.2) (10.200.254.5, 1,
10.200.254.2)
HOP (10.200.210.2) HOP (10.210.211.2) HOP()
Label Request Object (0x0800) Label Request Object (0x0800) Label Request Object
(0x0800=IP)
ERO (10.200.210.2, 10.200.211.1, ERO (10.200.211.2, 10.200.254.5) ERO ()
10.200.211.2, 10.200.254.5)
Sender_Template (10.200.254.2, Sender_Template (10.200.254.2, Sender_Template
1) 1) (10.200.254.2, 1)
Session_Attribute (7, 7, 0x01) Session_Attribute (7, 7, 0x01) Session_Attribute (7, 7,
0x01)
Sender_Tspec (100kbps) Sender_Tspec (100kbps) Sender_Tspec (100kbps)
Record_Route () Record_Route (10.200.210.1) Record_Route
(10.200.210.1,
10.200.211.1)
RESV: RESV: RESV:
Session Object (10.200.254.5, 1, Session Object (10.200.254.5, 1, Session Object

10.200.254.2) 10.200.254.2) (10.200.254.5, 1,
10.200.254.2)
HOP () HOP (10.200.210.1) HOP (10.200.211.1)
Label Request Object (16) Label Request Object (16) Label Request Object
(Explicit Null)
Style= Shared_Explicit Style= Shared_Explicit Style= Shared_Explicit
FlowSpec (100kbps) FlowSpec (100kbps) FlowSpec (100kbps)
Record_Route(10.200.211.2, Record_Route(10.200.211.2) Record_Route()
10.200.210.2)
To view RSVP PATH and RESV messages on the router, use debug ip rsvp dump-
messages command.
FRR- Link Protection (NHOP):
• A regular tunnel T1 is configured between Paris (head-end) and Rome (tail-

end) routers.
• Fast Re-route link protection is to be configured for the link between Brussels
and Berlin. A backup tunnel called Next-hop (NHOP) bypass tunnel is
configured from Brussels to Berlin through Frankfurt.
• The backup tunnel starts at the PLR (Point of Local Repair) and ends at the
MP (Merge Point). The backup tunnel is an explicit path tunnel that RSVP
signals.
• The backup tunnel can be any hops long; here it is 2 hops.
• RSVP signals the labels as usual. The Berlin router signals Implicit-Null label
to Frankfurt router for the backup tunnel. The Frankfurt router assigns a label
and advertises it to the Brussels router.
• When the protected link is still operating, the Berlin router swaps label 30 with
label 33 for all the traffic going towards Brussels router.
• When the protected link fails between Berlin and Brussels router, the backup
tunnel is used by the Berlin router. The Berlin router swaps the incoming label
30 with label 33 first. Then imposes label 16 on top of it and forwards the
packet to Frankfurt router.
• The Frankfurt router pops label 16 and forwards the packet to Brussels router.
The packet reaches Brussels router with top label 33, same as in the previous
case when the protected link was still operating.
• The PLR should use this backup tunnel only temporarily, because as soon as
the protected link fails, the PLR sends RSVP PathErr message to the head-end
router.
• When the head-end router receives the PathErr message, it recalculates a new
path for the tunnel LSP and signals it.
• When the signalling is completed, the whole LSP is rerouted to the new path.
The protected TE LSP no longer uses the backup tunnel.
• If a new path is not found, the backup tunnel is used as long as the protected
link is down. If the head-end router is only configured with one Explicit path
option and no dynamic path option, it is stuck with the backup tunnel.
• To configure FRR on head-end (Paris) router
interface tunnel 1
tunnel mpls traffic-eng path-option 1 explicit name PATH
tunnel mpls traffic-eng fast-reroute
This command sets the flag in Session Attribute object of RSVP PATH message to
0x01, which indicates the tunnel wants link protection.
To configure the PLR (Brussels router) to use the backup tunnel in case of link
failure,
interface POS 10/3

mpls traffic-eng backup-path Tunnel 1000
!
interface Tunnel 1000
ip unnumbered Loopback 0
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option explicit name BACKUP
!
ip explicit-path name BACKUP
!
FRR- Node Protection (NNHOP):
• A regular tunnel is built between Paris router and Sydney router.

• The Berlin router (node) is to be protected using FRR Node protection.
• Node protection works by creating a next-next-hop (NNHOP) backup tunnel.
It is a tunnel to the next-hop of the router to be protected.
• The NNHOP backup tunnel goes from Brussels router to Rome router.
• When the protected node is operating, the Brussels router swaps the incoming
label 33 to label 30 and advertises the packet to Berlin router. The Berlin
router swaps the incoming label 30 to label 31 and forwards the packet to
Rome router since it advertised label 31 to all its upstream routers.
• When the protected node is not operating, a mechanism is required on Rome
router to send label 31 to Brussels router so that Brussels router can impose
that label onto the packet and when it finally reaches the Rome router, it can
POP it and follow the usual process.
• Hence, the Rome router (NNHOP router) advertises label 31 in the sub-object
of the RRO object in the RESV message to the Brussels router (PLR).
• When the packets need to be forwarded to the backup tunnel, the PLR swaps
incoming label 33 with label 31 first, then imposes label 17 (that it received
from its downstream Frankfurt LSR for backup tunnel) and then forwards the
packet to the Frankfurt router.
• The Frankfurt router pops the top label 17 and forwards the packet to the
Rome router. The Rome router pops the top label 31 and forwards the IP
packet to the Sydney router.
• To configure FRR Node protection on the head-end router
interface Tunnel 1
tunnel mpls traffic-eng fast-reroute node-protect
This command sets the flag in the RSVP PATH message to 0x10 to indicate that the
tunnel needs node protection.
To configure the PLR in case of node failure,
interface POS 10/3

mpls traffic-eng backup-path Tunnel 2000
!
interface Tunnel 2000
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng bandwidth 97
tunnel mpls traffic-eng path-option 2 explicit name EXCLUDE
!
ip explicit-path name EXCLUDE
exclude-address 10.200.254.5 !!! Exclude Berlin router
!
MPLS TE tunnels between MPLS VPN PE routers:
CE1 router:
interface serial 0/0

ip address 172.16.1.2 255.255.255.252
!
router ospf 42
network 172.16.1.0 0.0.0.3 area 0
!
PE1 router:
mpls traffic-eng tunnels

!
ip vrf CUST1
rd 1:1
route-target both 1:1
!
interface loopback 0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
ip vrf forwarding CUST1
ip address 172.16.1.1 255.255.255.252
!
ip address 10.1.1.1 255.255.255.252
ip ospf 1 area 0
ip rsvp bandwidth
!
router ospf 42 vrf CUST1
network 172.16.1.0 0.0.0.3 area 0
redistribute bgp 100 metric 10 subnets
!
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 update-source Loopback 0
!
address-family vpnv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community both
!
address-family ipv4 vrf CUST1
redistribute ospf 42 vrf CUST1 metric 10 match internal
!
interface Tunnel 1
tunnel mpls traffic-eng path-option 1 explicit name MY_PATH
tunnel mpls traffic-eng record-route
!
ip explicit-path name MY_PATH
!
router ospf 1
mpls traffic-eng area 0
mpls traffic-eng router-id Loopback 0
!
PE4 router:

!
ip vrf CUST1
rd 1:1
!
interface loopback 0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 0
!
ip address 172.16.2.1 255.255.255.252
!
ip address 10.2.2.2 255.255.255.252
ip ospf 1 area 0
ip rsvp bandwidth
!
network 172.16.2.0 0.0.0.3 area 0
!
router bgp 100
!
!
!
interface Tunnel 2
tunnel mpls traffic-eng path-option 1 explicit name MY_PATH
!
ip explicit-path name MY_PATH
!
router ospf 1
!
The following output shows that the outgoing interface for 4.4.4.4/32 is Tunnel 1.
The following output shows that the downstream router of PE1 advertises label 17 for
the tail-end router 4.4.4.4.
The following output shows that the outgoing vpnv4 label for remote CE2 prefix is
22. This is the vpnv4 label.
The following output shows the labels imposed for the remote CE2 prefix. Top label
17 is the TE label while the bottom label 22 is the vpnv4 label. At every intermediate
LSR the top TE label is swapped while at the PE4 router, label 22 is popped.
The following output shows the traceroute from CE1 router to the remote CE2 router.
MPLS TE Tunnel with tail-end as P router:
PE1 router:

mpls label protocol ldp
mpls ldp router-id Loopback 0 force
!
ip vrf CUST1
rd 1:1
!
interface Loopback 0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
ip address 172.16.1.1 255.255.255.252
ip ospf 42 area 0
!
ip address 10.1.1.1 255.255.255.252
ip ospf 1 area 0
ip rsvp bandwidth
mpls ip
!
!
router bgp 100
!
!
!
interface Tunnel 1
tunnel mode traffic-eng tunnels
mpls ip
!
router ospf 1
!
P3 router:

mpls label protocol ldp
mpls ldp router-id Loopback 0 force
!
interface Loopback 0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
ip address 10.2.2.2 255.255.255.252
ip ospf 1 area 0
ip rsvp bandwidth
mpls ip
!
mpls ldp discovery targeted-hello accept from TUNNEL
!
ip access-list standard TUNNEL
permit host 1.1.1.1
!
As shown below, the P2 router advertises Label 19 for Tunnel 1 (Tunnel instance 32)
to PE1 router for Tunnel 1.
The following output shows that the PE1 router forwards all traffic behind the tail-end
router to the Tunnel 1.
The below output shows that the PE1 router receives Label 23 for the vpnv4 prefix
12.1.1.1/32. The next-hop for PE1 router to reach 12.1.1.1/32 is its iBGP next-hop
neighbor 4.4.4.4.
The below output shows the tags imposed for the prefix 12.1.1.1/32. The top label 19
is the TE label received for Tunnel 1. The second label 19 is the label received from
P3 router for the targeted LDP session for BGP next-hop prefix 4.4.4.4/32 and the
bottom label 23 is the vpnv4 label received from iBGP neighbor 4.4.4.4.
The following output shows the traceroute of 12.1.1.1 from the CE1 router.
Traffic from CE2 to CE1 does not go through the TE tunnel 1 since it is only
unidirectional. The targeted-LDP session is only to advertise the label for the BGP
next-hop router-id so at the tail-end router, we will have two labels and label
switching will be correct.
MPLS VPN with MPLS TE: Failure detection with RSVP Hellos
• The link between P2 and PE4 is the protected link.

• P2 is the PLR and PE4 is the MP.
PE1 router: PE4 router:
mpls label protocol ldp mpls label protocol ldp

mpls ldp router-id Loopback 0 force mpls ldp router-id Loopback 0 force
mpls traffic-eng tunnels mpls traffic-eng tunnels
! !
ip vrf CUST1 interface Loopback 0
rd 1:1 ip address 4.4.4.4 255.255.255.255
route-target both 1:1 ip ospf 1 area 0
! !
interface Loopback 0 ip rsvp signalling hello
ip address 1.1.1.1 255.255.255.255 !
ip ospf 1 area 0 ip vrf CUST1
! rd 1:1
interface serial 1/0 route-target both 1:1
ip vrf forwarding CUST1 !
ip address 172.16.1.1 255.255.255.252 interface serial 1/0
! ip vrf forwarding CUST1
interface Tunnel 0 ip address 172.16.2.1 255.255.255.252
ip unnumbered Loopback 0 !
tunnel mode mpls traffic-eng interface fastethernet 2/0
tunnel destination 4.4.4.4 ip address 10.4.4.2 255.255.255.252
tunnel mpls traffic-eng autoroute announce ip ospf 1 area 0
tunnel mpls traffic-eng bandwidth 98 mpls ip
tunnel mpls traffic-eng path-option 1 explicit ip rsvp bandwidth
name PATH mpls traffic-eng tunnels
tunnel mpls traffic-eng record-route ip rsvp signalling hello
tunnel mpls traffic-eng fast-reroute !
! router ospf 42 vrf CUST1
ip explicit-path name PATH network 172.16.2.0 0.0.0.3 area 0
next-address 2.2.2.2 redistribute bgp 100 metric 10 subnets
next-address 4.4.4.4 !
! router bgp 100
router ospf 42 vrf CUST1 neighbor 1.1.1.1 remote-as 100
network 172.16.1.0 0.0.0.3 area 0 neighbor 1.1.1.1 update-source Loopback 0
redistribute bgp 100 metric 10 subnets !
! address-family vpvn4
router bgp 100 neighbor 1.1.1.1 activate
neighbor 4.4.4.4 remote-as 100 exit-address-family
neighbor 4.4.4.4 update-source Loopback 0 !
! address-family ipv4 vrf CUST1
address-family vpvn4 redistribute ospf 42 vrf CUST1 metric 10 match
neighbor 4.4.4.4 activate internal
exit-address-family exit-address-family
! !
redistribute ospf 42 vrf CUST1 metric 10 match
internal
exit-address-family
!
P2 router: P3 router:
mpls label protocol ldp mpls label protocol ldp

mpls ldp router-id Loopback 0 force mpls ldp router-id Loopback 0 force
! !
ip rsvp signalling hello interface Loopback 0
! ip address 3.3.3.3 255.255.255.255
interface Loopback 0 ip ospf 1 area 0
ip address 2.2.2.2 255.255.255.255 !
ip ospf 1 area 0 interface fastethernet 1/0
! ip address 10.2.2.2 255.255.255.252
interface fastethernet 1/1 ip ospf 1 area 0
ip address 10.4.4.1 255.255.255.252 mpls ip
mpls ip ip rsvp bandwidth
ip rsvp bandwidth mpls traffic-eng tunnels
mpls traffic-eng tunnels !
ip rsvp signalling hello interface fastethernet 1/1
mpls traffic-eng backup-path Tunnel 1000 ip address 10.3.3.1 255.255.255.252
! ip ospf 1 area 0
interface Tunnel 1000 mpls ip
ip unnumbered Loopback 0 ip rsvp bandwidth
tunnel mode mpls traffic-eng mpls traffic-eng tunnels
tunnel destination 4.4.4.4 !
tunnel mpls traffic-eng path-option 1 explicit
name SUB
!
ip explicit-path name SUB
!
The following output on P2 router shows that the backup tunnel is “ready” for use.
The LSP identifier indicates the source address of the primary LSP being protected.
When the protected link was shut down, the backup link becomes “active”.
The traceroute output from the CE1 router shows the path followed through the
backup tunnel after the protected link was shut down.
MPLS TE: Interarea tunnels
• Interarea MPLS TE tunnel is the one which spans multiple IGP (OSPF or IS-
IS) areas. The LSP spans from a head-end LSR in one area to a tail-end LSR
in another area through the backbone area.
• The LSR that acts as a head-end of this LSP should be able to pass the
constraints (using RSVP-TE) associated with this LSP to a path computation
server (usually an ABR). The ABR has the topology and TE information of
more than one area including the backbone area. The ABR computes the path
for the LSP. The ABR may compute the whole or partial path. In the latter
case, the computed path would include loose hops.
• Loose Hops: An LSR should be able to specify loose ERO hops, and let some
intermediate LSRs to expand it to strict hops. (Strict hops are defined using
explicit path-option for a single area).
• This mechanism requires the ability of the LSR that originates the LSP to pass
the constraints associated with that LSP to the ABR. It also requires the ability
of the head-end LSR to pass the address of the tail-end LSR, and the ability for
the ABR to pass back to the head-end LSR the ERO that contains the results
of the path computation.
Area1 router: Area2 router:

! !
interface Loopback 0 interface Loopback 0
ip address 1.1.1.1 255.255.255.255 ip address 4.4.4.4 255.255.255.255
! !
interface fastethernet 1/0 interface fastethernet 1/0
ip ospf 1 area 1 ip ospf 1 area 2
ip rsvp bandwidth ip rsvp bandwidth
! !
interface Tunnel 0 router ospf 1
ip unnumbered Loopback 0 mpls traffic-eng router-id Loopback 0
tunnel mode mpls traffic-eng mpls traffic-eng area 2
name INTERAREA
tunnel mpls traffic-eng fast-reroute
!
ip explicit-path name INTERAREA
next-address loose 2.2.2.2
!
router ospf 1
!
ABR1 router: ABR2 router:

! !
interface Loopback 0 interface Loopback 0
! !
ip rsvp signalling hello ip rsvp signalling hello
! !
! !
ip rsvp signalling hello ip rsvp signalling hello
mpls traffic-eng backup-path Tunnel 1000 !
! router ospf 1
interface Tunnel 1000 mpls traffic-eng router-id Loopback 0
ip unnumbered Loopback 0 mpls traffic-eng area 0
tunnel mode mpls traffic-eng mpls traffic-eng area 2
name FRR
!
ip explicit-path name FRR
!
router ospf 1
!
The following output shows that MPLS TE tunnel. The asterisk (*) shows the loose
hops.

Ab - MPLS Te

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ab - MPLS Te

Загружено:

Авторское право:

Доступные форматы

CHAPTER 8: MPLS Traffic Engineering

Building blocks of MPLS TE:

2. TE information distribution (using link-state routing protocols like OSPF or IS-IS)

4. RSVP- A signalling protocol to signal the TE tunnel across the network

1. TE metric- It can be used to construct a TE topology. By default, the TE metric is

2. Maximum bandwidth- It is the total (physical or configured) bandwidth of the

4. Unreserved bandwidth- It is the remainder of the bandwidth that is available to

5. Administrative group (Attribute flags)- It is a 32-bit field with no syntax. The

OSPF Extensions for TE-

The IGP floods TE information in the following cases-

MPLS TE Tunnel Attributes:

2. Desired/Requested bandwidth: This is the requested bandwidth for a particular

interface fastethernet 0/1

Range of attribute-flags is 0x0 to 0xFFFFFFFF.

The default properties value is 0x0 and mask is 0x0000FFFF.

Range of setup and holding priority is 0 to 7 with 0 being highest priority.

6. Reoptimization: A TE tunnel can end up on a path that is no longer the best or

Three types of triggers can cause Reoptimization-

a) Periodic Reoptimization- Occurs every 1 hour by default

To change the frequency,

mpls traffic-eng reoptimize timers frequency <interval>

b) Event-Driven Reoptimization- By default, Reoptimization does not trigger when

c) Manual Reoptimization: To force immediate Reoptimization,

mpls traffic-eng reoptimize tunnel <number>

PCALC- Path Calculation:

• RSVP uses PATH and RESV messages to signal a TE tunnel.

PARIS BRUSSELS ROME

PATH: PATH: PATH:

Session Object (10.200.254.5, 1, Session Object (10.200.254.5, 1, Session Object

RESV: RESV: RESV:

Session Object (10.200.254.5, 1, Session Object (10.200.254.5, 1, Session Object

• A regular tunnel T1 is configured between Paris (head-end) and Rome (tail-

interface POS 10/3

FRR- Node Protection (NNHOP):

• A regular tunnel is built between Paris router and Sydney router.

To configure the PLR in case of node failure,

interface POS 10/3

MPLS TE tunnels between MPLS VPN PE routers:

interface serial 0/0

mpls traffic-eng tunnels

mpls traffic-eng tunnels

mpls traffic-eng tunnels

mpls traffic-eng tunnels

• The link between P2 and PE4 is the protected link.

PE1 router: PE4 router:

mpls label protocol ldp mpls label protocol ldp

mpls label protocol ldp mpls label protocol ldp

MPLS TE: Interarea tunnels

mpls traffic-eng tunnels mpls traffic-eng tunnels

ABR1 router: ABR2 router:

mpls traffic-eng tunnels mpls traffic-eng tunnels

Вам также может понравиться