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>Search

Reminder

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

upgrade

ME60 V800R010C10SPC500 Configuration Guide - Virtual Access 01

This is ME60 V800R010C10SPC500 Configuration Guide - Virtual Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Configuring Reliability for the Virtual Access System

Configuring Reliability for the Virtual Access System

This section describes how to configure reliability for the virtual access system.

Background Information

To ensure service reliability, the virtual access system supports multiple reliability mechanisms, including two control planes (primary and secondary masters) and BFD. You can configure reliability as required.

Pre-configuration Tasks

Before configuring reliability for the virtual access system, establish a virtual access system.

Configuration Procedures

Perform one or more of the following configurations as required.

Configuring Primary and Secondary Masters

To ensure reliability, you can specify one primary master and one secondary master for an AP.

Context

An AP can be managed by two masters. The two masters use IS-IS to notify their own management priority information for the AP to each other. The roles of the two masters are determined based on the following rules:

  1. The system first checks the management priorities of the two masters. The master with a higher priority becomes the primary master, and the master with a lower priority becomes the secondary master.

  2. If the management priorities of the two masters are the same, the master with a smaller management IP address becomes the primary master, and the master with a larger management IP address becomes the secondary master.

Perform the following steps to configure a master's management priority for an AP.

NOTE:

The configurations for an AP must be the same on the primary and secondary masters. If they are different, configuration reconciliation must be performed on the AP during a primary/secondary master switchover. The process may cause a new configuration to take a long time to take effect.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ap-id ap-id

    The AP view is displayed.

  3. Run management priority priority-value

    The master's management priority is specified for the AP.

    A master's default management priority is 255 (lowest priority) for all APs.

    The elected primary master uses the NETCONF channel to deliver the following configuration to the AP and the AP automatically performs the configuration and saves it to a configuration file:

    master admin-ip primary primary-ip [ secondary secondary-ip ]

  4. Run commit

    The configuration is committed.

Adjusting BFD Session Parameters

You can adjust BFD parameters to control BFD's sensitivity to faults.

Context

When a virtual access system is established, a master automatically establishes the following BFD sessions:

  • BFD for vaLSP session: used to quickly detect vaLSP faults. If the primary vaLSP fails, BFD triggers traffic to be switched to the backup vaLSP.

  • BFD for vaTunnel session: used to quickly detect vaTunnel faults. A vaTunnel is a TE tunnel that consists of a group of primary and backup vaLSPs. If both the primary and backup vaLSPs fail, BFD triggers traffic to be switched between the primary and secondary vaPWs.

  • BFD for Diameter session: used to quickly detect Diameter channel status changes. If the primary master fails, the secondary master uses BFD for Diameter to quickly detect the fault, enables the virtual access interface for the secondary vaPW, and triggers the secondary vaPW to become the primary vaPW.

You can configure BFD session parameters to control BFD's sensitivity to faults, preventing intermittent network faults from resulting in unnecessary traffic switchovers.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ap-id ap-id

    The AP view is displayed.

  3. Run either of the following commands:
    • To configure BFD for vaLSP session parameters, run the bfd va-lsp { min-tx-interval tx-interval | min-rx-interval rx-interval | detect-multiplier multiplier } * command.

    • To configure BFD for vaTunnel session parameters, run the bfd va-tunnel { min-tx-interval tx-interval | min-rx-interval rx-interval | detect-multiplier multiplier } * command.

    Masters and APs may support different BFD session parameter values. If the BFD session parameter values configured on a master are less than the minimum BFD session parameter values supported by an AP, the AP uses the default BFD session parameter values to negotiate with the master to determine parameter values used for BFD sessions.

  4. Run quit

    The system view is displayed.

  5. Run virtual-access

    The virtual access view is displayed.

  6. Run diameter bfd { min-rx-interval min-rx-interval | min-tx-interval min-tx-interval | detect-multiplier multiplier } *

    Configure BFD for Diameter session parameters.

    NOTE:

    A BFD session actually monitors the DCN route used by the Diameter channel between the primary and secondary masters. If a direct link exists between the primary and secondary masters, run the virtual-access enable inter-link command on the interfaces connecting the primary and secondary masters so that the Diameter channel uses the direct DCN route. If no direct link exists between the primary and secondary masters, the DCN route used by the Diameter channel passes through an AP. To prevent DCN route convergence and BFD session flapping caused by an AP restart or fault, run the diameter bfd command to increase the BFD session detection time properly.

  7. Run commit

    The configuration is committed.

Configuring Dynamic Multicast BFD to Monitor the Status of an Internal Communication Interface

This section describes how to configure dynamic multicast BFD to monitor the status of internal communication interfaces, implementing rapid fault detection on the interfaces.

Context

To rapidly detect faults on internal communication interfaces in a virtual access system, enable dynamic multicast BFD on a master. The BFD module automatically generates a dynamic multicast BFD session for each internal communication interface managed by the master, and associates the session with the interface's port state table (PST) and process interface status (PIS).

  • If the session is associated with the interface's PST and the BFD module detects a fault on the interface, the BFD module modifies the interface's status in the PST, triggering fast DCN route reconvergence in the virtual access system.

  • If the session is associated with the interface's PIS and the BFD module detects a link fault on the interface, the BFD module immediately sends a Down message to the interface. The interface then enters the BFD Down state, which is equal to the Down state of the link protocol. In the BFD Down state, only BFD packets can be properly processed and therefore the interface can rapidly detect the link fault.

After enabling dynamic multicast BFD, you can adjust dynamic multicast BFD parameters to control BFD's sensitivity to faults, preventing intermittent network faults from resulting in unnecessary traffic switchovers.

Procedure

  1. Run systerm-view

    The system view is displayed.

  2. Run virtual-access

    The virtual access view is displayed.

  3. Run bfd mcast all-inner-interface enable

    Dynamic multicast BFD is enabled on internal communication interfaces.

  4. (Optional) Perform the following operations to adjust dynamic multicast BFD session parameters:
    • To configure the minimum interval at which dynamic multicast BFD packets are received from the remote end, run the bfd mcast all-inner-interface min-rx-interval rx-interval command.
    • To configure the minimum interval at which dynamic multicast BFD packets are sent to the remote end, run the bfd mcast all-inner-interface min-tx-interval tx-interval command.
    • To configure a local detection multiplier for dynamic multicast BFD packets, run the bfd mcast all-inner-interface detect-multiplier detect-multiplier command.

    If the local end does not receive dynamic multicast BFD packets from the remote end within the local BFD detection time, the local end considers the corresponding internal communication interface's link faulty.

    Local BFD detection time = Remotely configured local detection multiplier x Max {Locally configured minimum interval at which dynamic multicast BFD packets are received, Remotely configured minimum interval at which dynamic multicast BFD packets are sent}

    You can adjust dynamic multicast BFD parameters to control BFD's sensitivity to faults. If high network reliability is required, adjust parameters to decrease the local BFD detection time. If moderate network reliability is required, adjust parameters to increase the local BFD detection time.

    Generally, the default values are recommended for dynamic multicast BFD session parameters.

  5. Run commit

    The configuration is committed.

Configuring a Master to Detect Diameter Channel Faults Based on a DCN Route's Status

This section describes how to configure a master to detect Diameter channel faults based on a DCN route's status, preventing two primary masters' coexistence caused by BFD session Down from affecting traffic forwarding.

Context

When multiple APs are dual-homed to the primary and secondary masters, the masters negotiate the primary/secondary status. By default, the virtual access system automatically creates a BFD for Diameter session to detect Diameter channel faults. However, when the link used by the Diameter channel is switched between the primary master's different boards, the BFD for Diameter session may incorrectly go Down. On the network shown in Figure 1, in normal cases, the Diameter channel between the primary and secondary masters uses the link of primary master -> AP1 -> secondary master. If the No.1 board in the primary master fails, the primary master switches the link used by the Diameter channel to the No.2 or No.3 board. However, the BFD for Diameter session takes a long time for the link switchover. The BFD for Diameter session incorrectly goes Down within this time, and the secondary master considers the Diameter channel Down. As a result, the secondary master becomes the primary master. When two primary masters coexist, service traffic fails to be forwarded.

Figure 2-3 Multiple APs dual-homed to the primary and secondary masters

To resolve this issue, configure a master to detect Diameter channel faults based on a DCN route's status. The secondary master determines the Diameter channel's status based on the DCN route's status. The DCN route goes Down only if all links between the primary and secondary masters fail. When the secondary master detects that the DCN route goes Down, the secondary master determines that the Diameter channel goes Down and becomes the primary master.

NOTE:

To implement fast DCN route reconvergence in the case of a link fault, configure dynamic multicast BFD to monitor the status of an internal communication interface before configuring this task.

Procedure

  1. Run systerm-view

    The system view is displayed.

  2. Run virtual-access

    The virtual access view is displayed.

  3. Run va-pw diameter fault-detect mode route

    The master is configured to detect Diameter channel faults based on a DCN route's status.

  4. Run commit

    The configuration is committed.

Configuring the Minimum Number of Available Links Between a Master and AP

This section describes how to configure the minimum number of available links between a master and AP. If the number of available links between a master and AP is less than the configured minimum number, traffic protection switching is triggered.

Context

In virtual access scenarios, if multiple physical links exist between a master and AP, traffic carried on the primary vaLSP between the master and AP is balanced among the links. By default, traffic is switched to the backup vaLSP only if all links between a master and AP fail. However, when some links fail, traffic between the master and AP may exceed the bandwidths of the remaining available links. As a result, packet loss occurs.

To resolve the preceding issue, configure the minimum number of available links between the master and AP. If the number of links available for the primary vaLSP between the master and AP is less than the configured minimum number, the primary vaLSP's status becomes Unavailable, triggering traffic to be switched to the backup vaLSP. If the numbers of links available for both the primary and backup vaLSPs are less than the configured minimum number, the status of the vaTunnel that is composed of the primary and backup vaLSPs becomes Unavailable, triggering a primary/secondary vaPW switchover. Traffic is then switched between the vaPWs, ensuring service forwarding quality.

Procedure

  1. Run systerm-view

    The system view is displayed.

  2. Run ap-id ap-id

    The AP view is displayed.

  3. Run va-lsp switch-threshold min-link-number min-link-number

    The minimum number of available links between the master and AP is configured.

  4. Run commit

    The configuration is committed.

Associating an External Communication Interface with AP Plug-and-Play

This section describes how to associate an external communication interface with AP plug-and-play. After the association, the status of the external communication interface on the AP changes when the AP goes online or offline, preventing the user-side upstream traffic from being lost.

Context

In a virtual access scenario, if the DCN route or control channel between an AP and master fails, the AP goes offline from the master. The internal forwarding tunnel between the AP and master also fails. However, the external communication interface for directly connecting the AP to a user-side CE remains Up. If a static route or Eth-Trunk interface has been configured on the CE, the route from the CE to the AP remains valid because the interface status is Up. As a result, the user-side upstream traffic is lost.

To resolve the preceding issue, associate an external communication interface with AP plug-and-play on a master. After the association, the AP's external communication interface for the virtual access interface goes Down when the AP goes offline. If the route between the CE and AP fails, a user-side network protection switchover is triggered to prevent upstream traffic loss. When the AP goes online again, the AP's external communication interface for the virtual access interface immediately goes Up by default. However, if instability in the virtual access network causes the AP to frequently go offline and online, the external communication interface frequently alternates between Up and Down. As a result, user-side services become unstable. In this situation, you can run the ap-online trigger-up-delay delay-time-interval command in the virtual access interface view based on the network conditions. This command enables you to delay the external communication interface from going Up immediately after the AP goes online again, thereby preventing the external communication interface from flapping.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-type interface-number

    The virtual access interface view is displayed.

    A virtual access interface is a virtual agent interface of an AP's external communication interface on a master. For example, GigabitEthernet 1025/1/0/1 indicates that the virtual access interface corresponds to AP 1025's external communication interface GigabitEthernet 1/0/1.

  3. Run ap-offline trigger if-down

    The system is enabled to trigger an external communication interface to go Down when an AP goes offline.

    When an AP is dual-homed to a primary and secondary master:

    • Run this command on only the primary master.

    • The AP's external communication interface goes Down only if the DCN routes or control channels both between the AP and primary master and between the AP and secondary master fail.

  4. (Optional) Run ap-online trigger-up-delay delay-time-interval

    A delay is configured so that an external communication interface does not immediately go Up after the AP goes online.

  5. Run commit

    The configuration is committed.

Configuring a Switchback Policy for vaPWs

You can configure a switchback policy for vaPWs to prevent vaPW flaps and reduce impact on services from network instability.

Context

By default, traffic switchback delays for 30 seconds after the primary vaPW is restored. When the network is unstable, you can use the following methods to configure the switchback delay time or disable traffic switchback:

  • Configure a global switchback policy for vaPWs in the virtual access view.

  • Configure a switchback policy for a specified vaPW in the virtual access interface view.

The switchback policy configured for a specified vaPW has a higher priority.

Procedure

  • Configure a global switchback policy for vaPWs.
    1. Run systerm-view

      The system view is displayed.

    2. Run virtual-access

      The virtual access view is displayed.

    3. Run pw reroute { delay delay-time | never }

      A global switchback policy is configured for vaPWs.

      • The delay delay-time parameter indicates that traffic is switched back to the primary vaPW after the time specified in delay-time elapses.

      • The parameter never indicates that traffic is not switched back until the secondary vaPW fails.

    4. Run commit

      The configuration is committed.

  • Configure a switchback policy for a specified vaPW.
    1. Run systerm-view

      The system view is displayed.

    2. Run interface interface-type interface-number

      The virtual access interface view is displayed.

    3. Run virtual-access pw reroute { delay delay-time | never }

      A switchback policy is configured for a specified vaPW.

      • The delay delay-time parameter indicates that traffic is switched back to the primary vaPW corresponding to the current virtual access interface after the time specified in delay-time elapses.

      • The never parameter indicates that traffic is not switched back until the secondary vaPW fails.

    4. Run commit

      The configuration is committed.

Configuring the Delay Status of a Virtual Access Interface as Unblocked

You can configure the delay status of a virtual access interface as unblocked to prevent dual-master situations after master restart.

Context

When an AP is dual-homed to the primary and secondary masters and one of the master is restarted, if the peer master does not receive virtual access PW (vaPW) information from the restarted master within a given period, the virtual access interface is configured as unblocked. In this case, the vaPW is Up on the restarted master but the vaPW information still fails to be received from the peer master. The restarted master is considered the only master, and the virtual access interface status is configured as unblocked. In this context, the dual-master situation occurs, and traffic fails to be forwarded.

To address the issue, you can configure the delay time for restoring the virtual access interface status to unblocked. The virtual access interface of the restarted master keeps blocked within the configured delay time and changes to unblocked until the vaPW information is received from the peer master or the delay-time timer times out. This prevents the dual-master situation during master restart to some extent.

By default, a virtual access interface changes to the unblocked state 120s after the master is restarted. When the network is unstable, you can configure the delay time for restoring the virtual access interface status to unblocked on the primary and secondary masters.

Procedure

  1. Run systerm-view

    The system view is displayed.

  2. Run virtual-access

    The virtual access view is displayed.

  3. Run pw recover delay-time delay-time

    The delay time for restoring the virtual access interface status to unblocked is configured.

  4. Run commit

    The configuration is committed.

Checking the Configurations

After configuring reliability for the virtual access system, check the configurations, including information about the primary and secondary masters that manage an AP, vaPW block status, and BFD session information.

Prerequisites

Reliability has been configured for the virtual access system.

Procedure

  • Run the display virtual-access ap [ ap-id ] command on a master to check information about the primary and secondary masters that manage an AP.
  • Run the display virtual-access va-pw [ ap ap-id | state { up | down } | interface interface-type interface-number ] command on a master to check that the primary vaPW is not blocked but the secondary vaPW is blocked.
  • Run the display bfd session all [ verbose ] command on a master to check BFD session information.
  • Run the display va-pw diameter [ peer-master admin-ip ] command on a master to check the session status and fault detection information of the Diameter channel.
  • Run the display virtual-access va-tunnel p2p [ source source-address destination destination-address ] command on a master to check the link status of a specified vaTunnel based on the LinkState field.
Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059451

Views: 3745

Downloads: 18

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next