No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

How to Implement Multi-protection

Publication Date:  2013-10-30 Views:  13 Downloads:  0
Issue Description

Version: NE5000E V300R007C00SPC500

Networking: Typical dual-plane networking

Symptom: To implement dual-FRR protection, two bypass tunnels were created for a link.

The active tunnel was faulty and later the bound protection tunnel was also faulty. However, traffic was not switched to another backup tunnel as expected.
Handling Process

To address the issue, Huawei performed the following operations and observed the following information:

1. Checked the status of the active tunnel Tunnel0/0/102 and found that it was bound with Tunnel0/1/102.

<R1>disp mpls te tunnel path Tunnel0/0/102
 Tunnel Interface Name : Tunnel0/0/102
 Lsp ID : 1.1.1.1 :1002 :10
 Hop Information
  Hop 0   10.1.1.1 Local-Protection available
  Hop 1   10.1.1.2  Label 3
  Hop 2   2.2.2.2  Label 3
<R1>disp mpls te tunnel name Tunnel0/0/102 ver | include Bypass
    Bypass In Use           :  Not Used
    Bypass Tunnel Id        :  53
    BypassTunnel            :  Tunnel Index[ Tunnel0/1/102], InnerLabel[3]
    Bypass Lsp ID           :  3           FrrNextHop        :  10.1.2.2
    ReferAutoBypassHandle   :  -
    Bypass Attribute(Not configured)
    Bypass Unbound Bandwidth Info(Kbit/sec)
<R1>

2. After the link that carried the active tunnel was down, traffic was switched to the protection tunnel. 

[R1-Serial0/0/0]shutdown
<R1>disp mpls te tunnel path Tunnel0/0/102
 Tunnel Interface Name : Tunnel0/0/102
 Lsp ID : 1.1.1.1 :1002 :10
 Hop Information
  Hop 0   10.1.2.1 Local-Protection in use
  Hop 1   10.1.2.2  Label 3
  Hop 2   2.2.2.2  Label 3
<R1>

<R1>display mpls te tunnel name Tunnel0/0/102 verbose | include Bypass
    Bypass In Use           :  In Use
    Bypass Tunnel Id        :  57
    BypassTunnel            :  Tunnel Index[ Tunnel0/1/102], InnerLabel[3]
    Bypass Lsp ID           :  4           FrrNextHop        :  10.1.2.2
    ReferAutoBypassHandle   :  -
    Bypass Attribute(Not configured)
    Bypass Unbound Bandwidth Info(Kbit/sec)
<R1>

3. After the in-use bypass tunnel was faulty, traffic failed to be switched to another FRR tunnel.

<R1>display interface brief | include Tunnel0/0/102
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface                   PHY   Protocol InUti OutUti   inErrors  outErrors
Tunnel0/0/102               up    down        --     --          0          0
<R1>
Root Cause
If FRR was performed, data switched from the primary CR-LSP to the bypass CR-LSP. During the period that data was being transmitted on the bypass CR-LSP, the bypass CR-LSP must keep Up all the time. If the bypass CR-LSP was faulty, the protected data, however, cannot be forwarded through MPLS. As a result, data transmission was interrupted and the FRR function was invalidated. Even if the bypass CR-LSP went Up, it could not forward data. Data could be forwarded only after the primary CR-LSP restored or was reestablished.
Solution

Deploy FRR+CR-LSP backup to implement dual-protection. To be specific, enable CR-LSP backup on the active tunnel. After the bypass tunnel is faulty, traffic is switched to the backup CR-LSP.

---------------------------------------
interface Tunnel0/0/102
 ip address unnumbered interface LoopBack0
 tunnel-protocol mpls te
 destination 2.2.2.2
 mpls te tunnel-id 1002
 mpls te record-route label
 mpls te path explicit-path pri
 mpls te fast-reroute
 mpls te backup ordinary
 mpls te igp shortcut isis
 mpls te igp metric relative -10
 mpls te commit
 isis enable 1

[R1]int s0/0/0
[R1-Serial0/0/0]shut
[R1-Serial0/0/0]q
[R1]disp int tunnel0/0/102          
Tunnel0/0/102 current state : UP
Line protocol current state : UP
Last line protocol up time : 2012-06-29 21:17:10 UTC-08:00
Description:HUAWEI, Quidway Series, Tunnel0/0/102 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(1.1.1.1/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 2.2.2.2
Tunnel up/down statistics 5
Tunnel protocol/transport MPLS/MPLS, ILM is available,
primary tunnel id is 0x3e, secondary tunnel id is 0x0
Current system time: 2012-06-29 21:21:06-08:00
    300 seconds output rate 0 bits/sec, 0 packets/sec
    0 seconds output rate 0 bits/sec, 0 packets/sec
    0 packets output,  0 bytes
    0 output error
    0 output drop
    Input bandwidth utilization  : --
    Output bandwidth utilization : --
[R1]
[R1]disp mpls te tunnel name Tunnel0/0/102 ver
[R1]disp mpls te tunnel name Tunnel0/0/102 verbose | include Bypass
    Bypass In Use           :  In Use
    Bypass Tunnel Id        :  63
    BypassTunnel            :  Tunnel Index[Tunnel0/1/102], InnerLabel[3]
    Bypass Lsp ID           :  5           FrrNextHop        :  10.1.2.2
    ReferAutoBypassHandle   :  -
    Bypass Attribute(Not configured)
    Bypass Unbound Bandwidth Info(Kbit/sec)
[R1]int s0/0/1

[R1-Serial0/0/1]shutdown

[R1]disp mpls te tunnel name Tunnel0/0/102 verbose | include Bypass
    Bypass In Use           :  Not Exists
    Bypass Tunnel Id        :  -
    BypassTunnel            :  -
    Bypass Lsp ID           :  -           FrrNextHop        :  -
    ReferAutoBypassHandle   :  -
    Bypass Attribute(Not configured)
    Bypass Unbound Bandwidth Info(Kbit/sec)

[R1]disp int tunnel0/0/102                                        
Tunnel0/0/102 current state : UP
Line protocol current state : UP
Last line protocol up time : 2012-06-29 21:21:37 UTC-08:00
Description:HUAWEI, Quidway Series, Tunnel0/0/102 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(1.1.1.1/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 2.2.2.2
Tunnel up/down statistics 7
Tunnel protocol/transport MPLS/MPLS, ILM is available,
primary tunnel id is 0x40, secondary tunnel id is 0x0
Current system time: 2012-06-29 21:21:47-08:00
    300 seconds output rate 0 bits/sec, 0 packets/sec
    41 seconds output rate 0 bits/sec, 0 packets/sec
    0 packets output,  0 bytes
    0 output error
    0 output drop
    Input bandwidth utilization  : --
    Output bandwidth utilization : --
[R1]
Suggestions

Deploy TE-FRR+CR-LS to implement multi-protection for TE tunnels.

You can configure the TE FRR bypass tunnel and the end-to-end backup CR-LSP together. The backup CR-LSP is more reliable than the TE FRR bypass tunnel. Therefore, to increase security of the tunnel, you are recommended to configure both the TE FRR bypass tunnel and the backup CR-LSP. If CR-LSP backup is associated with TE FRR, protection varies according to the backup mode.

If hot standby is configured, the following situations occur:

If the protected link or node fails, traffic switches to a bypass CR-LSP. The system attempts to re-establish the primary CR-LSP, while attempting to establish various types of backup CR-LSPs in sequence.

If the ordinary backup CR-LSP is set up successfully before the primary CR-LSP is restored, traffic switches to the backup CR-LSP.

If the primary CR-LSP is restored successfully, traffic is switched back to the primary CR-LSP no matter whether the traffic is on the TE FRR bypass tunnel or the backup CR-LSP.

When the backup CR-LSP fails to be set up and the primary CR-LSP is not restored, traffic passes still through the TE FRR bypass tunnel.

If hot standby is configured, the following situations occur:

If the backup CR-LSP is in the Up state and the protected link or node is faulty, traffic is switched to the TE FRR bypass tunnel and then immediately switched to the backup CR-LSP. At the same time, the system attempts to restore the primary CR-LSP.

If the backup CR-LSP is in the Down state, traffic is switched the same as in the ordinary backup mode.

When the primary CR-LSP is Up, the hot-standby CR-LSP is also being set up. After the backup CR-LSP is created successfully, more bandwidth resources are needed. The ordinary backup CR-LSP is set up only when the primary CR-LSP is in the FRR-in-use state. That is, when the primary CR-LSP works normally, no more bandwidth is needed. Association between ordinary backup CR-LSPs and TE FRR is recommended.

END