FRR

Allows for sub-50ms failover after link failure detection. Applicable for LSPs established using RSVP-TE. CSPF plays an important role. Allows protection to be applied as close to the point of failure as

MPLS Fast Reroute (FRR) defines ways of automatically establishing

protection paths before a failure the foellowing are the characteristics:-

The protection method is signaled in the Flags field of the One-to-one (0x01) Facility (0x02)



also indicates the following flags:

In the Session_Attribute object of the PATH message, the router local-protection-desired



FRR is only established after the primary LSP path is established.

Routers wait for the second RESV (first refresh) message

calculating and signaling the detours.



established end-to-end.This is to ensure that the primary LSP-Path is successfully

Upon receipt of the second RESV message, all routers along the

primary LSP-Path (except the Tail-End):



Assume the PLR (Point of Local Repair) role.



themselves, taking into account the protection method and type

(one-to-one and node-protect in this example)

When a router receives the refresh message for the previously established primary LSP-Path, it initiates the pending

detour calculation process. As a result of the randomization introduced in the session refresh timers, as described in

Module 4, the detour calculation and establishment processes may start at slightly different times on each router.

While testing with Fast Reroute, establishing all the detours along the primary LSP-Path might take a while (mostly up

to 60-70 seconds) because of the reasons described above.

When computing a protection path on a PLR, the constraints for

CSPF are:



that avoids the downstream node and all of its network links.

Node-protect ― To find a protection path for the primary LSP



that avoids only the link connected to the downstream node.

Link-protect ― To find a protection path for the primary LSP



(failure of the Tail-End router is catastrophic for the

LSP).

The router just before the Tail-End always performs linkprotection



constraints other than Shared Link Risk Groups (“srlg-frr

needs to be enabled in the global MPLS context, if that is desired).

SRLG concept can also be used for Fast Reroute, if the following system-wide configuration is enabled:

A:R1>config>router>mpls#

srlg-frr [strict]

•

SRLG constraint.

Strict: With the strict option, CSPF will not establish any FRR protection tunnel if there is no path that meets the

•

constraint, it disregards the constraint and tries to establish a tunnel over links that are not complaint to SRLG.



Merge point for one to one

The termination point for a protection tunnel is called the Merge

Point (MP) router.



protected tunnel merge, or meet again.

In other words, the MP is where the protection tunnel and



protection mode and the actual topology.

The location of the MP for a protection tunnel depends on the



to the Tail-End router of the protected LSP as possible.

For One-to-One protection, the detour tunnel terminates as near



using the shortest IGP path.

In the above figure the metric is changed which changes the merge point

Path message for the detour tunnel:-

The PLR sends a separate RSVP PATH message to signal the detour

tunnel.



Object (ERO) of the PATH message.

The result of the CSPF calculation is included in the Explicit Route



original primary LSP-Path. This is to identify the association on all

the routers.

The detour tunnel uses the same Tunnel ID and LSP ID as the



takes the following format:

The LSP-Name field in the PATH message of the detour tunnel



<LSP-Name>::<Path-Name>_detour For example, “to_R6::fully_loose_detour”

When a PLR router calculates a path for the detour, the hop information calculated by CSPF is inserted into the ERO of

the PATH message sent by the PLR. This PATH message is used to signal the detour.\

This association is achieved by assigning the

The difference lies in the

name to identify the detours.

Detour Object used in the Detour PATH Message



PLR to signal the detour path.

A Detour Object is also included in the PATH message sent by the



different PLRs.

The detour object helps to distinguish the detour tunnels from



Among other fields, the detour object contains:



PLR ID: System IP address of the PLR



— Node protect: System IP address of the protected router

— Link protect: The interface IP address of the protected

router

Accordingly, multiple detours protecting the same LSP might be transiting or terminating on a certain router. The main

purpose of the Detour object is to distinguish between them.

The ERO field contains the hops that are calculated by the PLR for the detour.

The Detour object indicates the PLR_ID as 10.10.10.1, which is the System IP address of router R1.

The

with a System IP address of 10.10.10.2.Avoid_Node field indicates that the detour is created to avoid the next router for router R1, which is router R2,Avoid_Node, depending on the protection mode:same Tunnel ID and LSP ID for the detour tunnels as their protected LSPPath.LSP-Name given to detour tunnels. A “_detour” suffix is appended to the original LSPPathIn other words, the detour tunnel is calculated to the Tail-End,Non-Strict: With the non-strict (default) option, if CSPF cannot find a path for the protection tunnel using the SRLGFRR protection tunnels do not follow any protected path” optionCalculate separate protection tunnels that originate onnode-protection-desired (unless disabled in configuration)

When Fast Reroute is enabled on an LSP, the Head-End includes an

additional Fast_Reroute object in the PATH message.









Fast_Reroute object:

























RRO:-

Record Route Object (RRO) is included, by default, in RSVP PATH

and RESV messages.

 Each router along the LSP-Path updates the RRO field.

 RRO is used to track the exact path that an LSP-Path takes.

 Interface IP addresses are used.

 In the context of FRR, routers make special use of the RRO inside

the RESV message.

 Labels are also recorded in the RRO of the RESV message.

The RRO is updated at each hop of the PATH message.

 Each router adds its own IP address connecting to the downstream

router at the top of the list.

When sending the PATH message, the Head-End router R1 inserts its own interface IP address (10.1.2.1) in the RRO list.

Router R2 adds its own address (10.2.3.2) to the top of the list, when forwarding the PATH message to router R3.

Router R3 does the same so that, eventually, router R4 has full visibility over the path that the RSVP PATH message has

traversed.





possible.

FRR:- Protection Methods:-



One-to-One Backup Facility Backup



Each LSP can use only one method.



the protected LSP.

The protection method needs to specified in the configuration of

Given below is an example of one to one protection path:-

 Given below is an example of facility protection path:-

All the LSP's are protected by the same bypass tunnel:-

FRR protection types:-

From a topological perspective, both one-to-one and facility

backup can protect different network elements:



downstream router.

Node Protection ― Protects against the failure of the next



next downstream router.

Link Protection ― Protects against the failure of the link to the



Possible configuration options for an LSP are:



One-to-one node protection



One-to-one link protection



Facility node protection

By default node protection is enabled by default and need not be mentioned however it can be optionally be disabled.

In the below case router R3 and all its links are avoided.

In the case of link protection it does not avoid any node:-

The default method is node protection.
 If node protection is desired:
 A router may make up to 3 consecutive attempts to establish a
node protection tunnel.
 If this cannot be accomplished, as a result of topological or
other constraints, the router reverts to link protection.
 Node protection can be disabled in the LSP configuration
 In this case, the routers only attempt link protection.Routers play different roles in Fast Reroute protection.
 Head-End Router ― Where the primary (protected) LSP-Path is
configured and where it originates.
 Tail-End Router ― Where the primary (protected) LSP terminates.
 Point of Local Repair (PLR) ― Where the protection tunnel
originates.
 Merge Point (MP) ― Where the protection tunnel terminates and
merges into the original protected LSP-Path.

All the routers along the path acts as a PLR except the tail end tries to establish a detour path hence all the routers along the lsp path acts as a PLR.Point of Local Repair (PLR) is the router where the protection tunnel
originates. When the link fails, the LSP traffic is locally recovered at
this point.
 Merge Point (MP) is the router where the protection tunnel
terminates and merges into the original LSP-Path.

In the above figure R2 is the PLR and R3 is the merge point.

FRR requirements:-For Fast Reroute to function, the Head-End needs to know the
exact path of the LSP-Path before signaling it.
 This can be accomplished in several ways:
 A path with fully strict hops (CSPF need not be enabled) in this case CSPF is not required however global revertive will not work in this case.
 A path with loose hops (CSPF must be enabled)
 A path with a mixture of strict and loose hops (CSPF must be
enabled)
 For a primary LSP-Path that has:
 Loose hops in path definition,
 Fast-Reroute enabled,
 CSPF disabled,
the LSP does NOT come up with failure code “looseHopsInFRRLsp”

Given below is the configuration for the FRR:-A:R2>config>router>mpls#
--------------------------------
path “fully_loose”
no shutdown
lsp "to_R4“
to 10.10.10.4
cspf
fast-reroute one-to-one
node-protect
primary “fully_loose”
exit
no shutdown
exit

FRR has two objects in the path message:-The RSVP-TE protocol was extended to allow for the automatic
signaling of the protection tunnels.
 Defined in RFC 4090.
 Introduces two objects:
 Fast_Reroute Object
 Detour Object (only for one-to-one method)
 The new objects are also carried in the RSVP PATH messages.Facility link protectionFRR can only protect the primary LSP-Path of an LSP, there is no protection for the secondary LSP path.

There are two methods of FRR protection.

An RRO is also present in the RESV message.

 Each router adds:

 Its interface IP address connecting to the upstream router

 The label allocated for the LSP

The Tail-End router R4 adds its own interface IP address (10.3.4.4) and the label it reserved for the LSP-Path (400) in

the RRO list.

Router R3 receives the RESV message from router R4. It appends its own interface IP address (10.2.3.3) and the label it

reserved for the LSP to the top of the list.

Router R2 performs a similar operation and, eventually, router R1 has full visibility over the LSP-Path with label

reservation information.

RRO to report FRR status

One of the uses of the RRO in the Fast Reroute implementation is the reporting of protection tunnel status to the Head-

End.

When a PLR router is able to successfully establish a protection tunnel, it sets the “local-protection-available” flag in

the following RESV refresh messages that it sends.

If node-protection was requested by the Head-End, and a node-protection tunnel is successfully established by the PLR,

the node-protection-available flag is also set. If a link-protection tunnel is established instead, then the flag value

remains at zero.

In the end, the Head-End router has full visibility of the routers and labels along the LSP-Path, as well as the tunnel

protection status on each router.

The above slide illustrates the reporting of protection tunnel process performed by all the PLRs.

Router R4 is the Tail-End router, and does not perform the PLR role.

Router R3 is able to establish a link protection tunnel and sets only the “local protection available” flag, which is

indicated with a “@” symbol in the SR OS CLI.

Router R2 is able to establish a node protection tunnel and sets both the “local protection available” (@) and “node

protection available” (n) flags in the RESV refresh messages.





Bandwidth Reservation

1>This is defined in mbps
2>The bandwidth is only checked during the initial phase during the establishment of the LSP, later on there are no checks done
3>Present in the FLOW_SPEC object of the RSVP path message.
4> Upon receipt of the FLOW_SPEC object the intermediate routers check if the requested b/w is available on the egress links this operation is called Connection Admission Control( CAC).
5> If the requested b/w is not present then a path error message is generated which travels to the head-end node. If CSPF is enabled the HE node checks at the head-end if the appropriate amount of b/w is availble.
R1---------R2----------R3------R4
6>A path message is sent from R1 to R4 with a specific amount of b/w the path message reaches r2, r2 checks the egress interface to see if the amount of b/w is present if it is present the path message is sent to R3, in this case no b/w is reserved at this stage as R2 is not sure if the b/w reservation will also succeed on the remaining nodes this is just a sanity check.
7>After the path message reaches the R4, a RESV message is sent from R4 which goes to R3, once the RESV message is received the bandwidth is reserved, and the unreserved b/w is propogated to all the other nodes.
8> Show router rsvp interface
The above comand shows the total b/w and the reserved b/w the admin status and the active sessions. Reserved b/w refers to the summation of the b/w of the all the lsp's on that particular interface.
9>The unreserved b/w is updated on with the TE updates.
10> Over-subscription or undersubsription is possible for a particular link.
11> config> router>rsvp#
interface abc
subscription 40
This sets the b/w of a particular link to 400 mbps
12> If a particular amount of b/w is not available a failure code is generated in the Path message which is known as admission control error if CSPf is not enabled the LSP continues to establish this session although without much success.
13> An alternative path is used if CSPF is enabled on the link which is not the IGP based path.
14> By default whenever there is a change in the bandwidth the IGP updates are triggered, which are flooded throughout the entire network in a scaled network with a large amount of LSP this can lead to a huge amount of updates which can be overhead for the network and causes processing power.
15> To reduce the amount of updates bandwidth update trigger feature can be used, in this case updates are only triggered when the reserved bandwidth only crosses certain thresholds.
Thresholds can be defined as up (rising) or down (falling) direction
16> In the up direction LSA TE updates are only sent when the threshold rises from the threshold which is defined, at the min at least 1 threshold should be defined and at the max 16 thresholds can be defined. These are defined as the % of the link b/w
In the down direction TE updates are sent only when the b/w falls below the bandwidth which is defined.
17> config router rsvp
te-threshold-update this can also be configured on each particular interface
Config router rsvp te-up-threshold
config router rsvp te-down-threshold
This can be overriden by individual config per interface.
18> config router rsvp te-threshold-update on-cac-failure this lets the router imediately send a TE update if the bandwidth reservation fails this is to notify the hed-end node immediately that there is no b/w available.
19>config>router>te-threshold# update
Periodic updates can be sent within a range of 1-300 seconds even if there is no change in the link bandwidth.
20> When the following configs are made
config router rsvp
te-threshold-update
The default te-threshold values are valid this can be verified by using the command show router rsvp status.
Or show router rsvp interface xx detail.
21> In some cases the primary and secondary paths for an LSP might cross the same link in some part of the network there are 2 reservation styles for that:-
Shared Explicit:- this is the default and according to this the bandwidth can be shared on the common links. The total reservation is equivalent to the masimum reservation done by either of the LSP path.
Fixed Filter:- The total reservation is the sum of all individual LSP path b/w reservations
22> R1-----R2------R3------R5
| |
|-----R4
If we have the following network the primary and standby paths merge on R2 hence if the b/w is reserved for both in the SE style the highest b/w will be considered
Suppose 500mbps and 300 mbps SE style b/w reserved is 500 mbps, the paths are seperated by the LSP ID's
In the case of FF the max reservation is 800 mbps
23> To configure FF >>>>>>>>>> config.router.rsvp-resv-style ff
24> Make Before Break:- If there is a change in some parameters of an LSP ie for suppose the b/w of the LSP changes or a failover occurs or any other parameters change a new lsp is required to be signalled, in this case the alternative LSP is signalled first and only after the alternative LSP is signalled and established traffic is switched over to the alternative LSP with no traffic loss, if the establishment of the alternative LSP is not successful traffic stays on the old LSP this process is known as MBB. A path error message is sent after establishing the new LSP from the HE node
25> The tunnel-id for the old and the new LSP remains the same, however the LSP id of the new LSP is incremented for a brief period of time both the LSP's can co-exist.
　
26> MBB is generally used in cases of Fast reroute, optimization of the LSP path, soft pre-emption.
MBB is enabled by default however it can be disabled by using the following command config >router>mpls>lsp#
no adaptive is enabled by default.
27> If there are multiple Equal cost paths to a particular destination for the HE router to reach the TE router, the router chooses the CSPF randomly chooses one of them, the least-fill-configuration option instructs CSPF to choose a link with least amount of b/w reservation.
28> the above faetaure will only work with CSPF enabled.
29> This feature is generally used to eradicate unbalanced reservation of b/w among the links.
30> ECMP need not be enabled for this. Least fill leads to more balanced bandwidth distribution.
31> LSP soft preemption provides relative priorities for the LSP's it allows more important lsp paths preempt the less important LSP paths.
32> LSP paths are alloted different priority levels, a better priority level lsp can topple an lsp with a lower priority level if they contend for the bandwidth.
33> The unreserved b/w values are signalled with IGP TE updates using the unreserved_bw_subtlv.
34> LSP paths have two priority values setup priority and hold priority.
35> The values for both the priorities range from 0 to 7. 0 is the best priority and 7 is the worst priority.
36> LSP A can preempt LSP B and eventually succeed if the setup priority of LSP A is better then the hold priority of LSPB.
37> Setup and hold priorities are signalled through the session attribute object of the RSVP path message.
38> The default setup priority for an LSP is 7 (worst) , with this it cannot pre-empt another LSP and the default hold priority for an LSP is 0 (best) ie once established the LSP cannot be pre-empted by another LSP.
39> Setup priority cannot be lower then its hold priority which can cause undesired loops. Best practice is to set them equal.
40> config router mpls lsp
bandwidth xxxx
priority 2 2
The first value defines the setup priority and the second value defines the hold priority.
41> R1------ R2-----------R3
An LSP is setup between R1 to R3 the priorities (setup & hold) for the LSP is 2. Hence the unreserved bandwidth which will be displayed are the following:-
P0:- 1000000 kbps
P1:- 100000 kbps
P2:- 600000 kbps
P3:- 600000 kbps
P4:- 600000 kbps
P5:- 600000 kbps
P6:- 600000 kbps
P7:- 600000 kbps
42> If another LSP with priority levels between priority levels between 2 to 7 wants to reserve the bandwidth it will only get 600 mbps however an LSP with priority levels of 0 or 1 can still reserve 1000 mbps or 1 gig.
43> Like for eg if a few more LSP are created and Priority Levels P5 to P7 changes to 300000 kbps another LSP needs to be established which requests for 600 mbps, then the priority of that LSP should be between 1 to 4.
44>

ERO/RRO

An RSVP PATH message contains a number of objects:

Label Request Object (Mandatory)

§

§

 

Explicit Route Object (ERO) (optional)

§

§

§

§

Record Route Object (RRO) (optional)

§

§

§

Session Attribute Object (optional)

§

 

 

 

The RSVP RESV message is sent back upstream to the ILER following the path created by the PATH message, in reverse order. It contains a number of objects:

Label Object (Mandatory)

§

§

§

 

Record Route Object (RRO) (Optional)

§

Session Attribute Object (Optional)

§

 

 

Includes control information  Used by the RESV message to follow the same set of hops back to the RSVP originator, reserving resources along the path and confirming the tunnel creation If the node is not ILER, it allocates a new label and places it in the LABEL object sent upstream A node receiving a Label object uses that label for outgoing traffic associated with this LSP tunnel Sent in response to a PATH message including a Label Request Includes control information such as the path setup and hold priorities and local-protection May be used for loop detection Allows the sender and receiver to know the actual route that the LSP tunnel traverses Records hop-by-hop path information Stored in the path state block on each node along the path Can be manually provided or computed based on RSVP requirements such as QoS and policy criteria If ERO is not present then IGP is used to follow the path Sent in the PATH message to specify the path to be followed independent of the IGP shortest path If a node does not supported this object or is incapable of providing a label binding, it sends a PathErr message to the ILER Request intermediate and receiver nodes to provide a label binding for the session

LDPoRSVP

82> If we use a hierarchial ospf ie ospf with different areas it increases the scalability of the network however the downside is TE database could not be spread over multiple areas.
83> Opaque LSA type 10 used for TE purposes cannot cross a particular area as they are blocked by the ABR.
Hence CSPF based LSP's cannot cross multiple areas. If we create such an LSP we get an error message saying No CSPF route to destination.
84>To get rid of such solutions we implement what is known as LDPoRSVP.
PE--------------ABR1---------------------->ABR2------------------>PE2
Area 1 Area 0 Area 2
85> So we need an CSPF based LSP from PE to ABR1 we needs another LSP from ABR1 to ABR2 and the third from ABR2 to PE2
These 3 independent LSP's should be stitched to form an end to end tunnel.
86> The stitching of these independent CSPF based LSP is performed by T-LDP and is performed by the ABR. So a T-LDP session should exist between PE---ABR1 ABR1---ABR2 and ABR2---PE2.
87> So in the case of LDPoRSVP resiliency features can be done inside an Area.
88> In this case 3 label MPLS stack is used
Top label is the RSVP label (outer most)-----T-LDP label----Service label
89> The RSVP label or the tunnel label is the label which is exchanged between the PE device and the intermediate node
PE----R1-----R2(ABR)-------R3-----R4(ABR)------R5-----PE
As seen above the Tunnel label is exchanged between PE and R1.

90> Second label is the LDP transport label which is exchanged between PE and R2 ie the T-LDP label.
91>The third label is service label which is only exchanged between the PE routers.
92 > So R1 swaps the top label however it does not touch the TLDP label
R2 Pops the RSVP label and also pops the T-LDP label, and inserts a new T-LDP label and a new RSVP label.
PE pops all the 3 labels.
93 > T-LDP is usually used between PE and R2 as in the case of T-LDP the peers need not be directly connected.
94> Config router ldp
Targeted session
Peer x.x.x.x
Tunneling
Tunneling needs to be enabled under the peer.
This needs to be configured on the PE and the ABR routers and not the intermediate routers in the Area.
95 > If link ldp also exists and the T-LDP also exists between the two nodes then by default link ldp gets a preference to change that we can configure
Config router ldp
Prefer-tunnel-in-tunnel
96> Then LDP over RSVP should also be enabled inside the IGP
Config router ospf or isis ldp-over-rsvp
97> We can verify this by using the command
Show router ldp bindings active
The LSP ID is displayed as the egress interface as the ldp tunnels is encapsulated inside the RSVP.
The LSP ID in ldp bindings active and show router rsvp session tunnel id should be identical.
*A:R1# show router ldp bindings active
==========================================================================
Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop
--------------------------------------------------------------------------
. . . . . . .
10.10.10.6/32 Push -- 131068 LspId 147 10.10.10.2
--------------------------------------------------------------------------
　
*A:R1# show router rsvp session
==========================================================================
From To Tunnel LSP Name
State
ID ID
--------------------------------------------------------------------------
10.10.10.1 10.10.10.2 147 18944 LSP1::fully_loose
　
98> Generally in a scalable network an area at least have two ABR for reasons that one ABR can fail in such scenarios PE needs to form a TLDP session with both the ABR's.
99> PE wil send the traffic to the closest ABR.
100> Full mesh of LSP and T-LDP sessions are required between the ABR's