Geo-redundancy

Two MAG-c systems can be deployed in a geo-redundant configuration. If one system fails, the other system ensures uninterrupted service and minimizes the impact of failure for broadband clients.

Geo-redundancy overview

Note: Nokia has introduced the terms active/standby as alternatives to the former master/slave terminology. This document has been updated with these new terms.

Geo-redundancy is the deployment of two MAG-c systems, a primary and secondary system, in a redundant configuration. If the primary system fails, the secondary system continues the service and minimizes the impact of failure for broadband clients.

The session states are synchronized between the two systems so that the secondary system can operate at full state after switchover.

The user configures the administrative primary or secondary role for each system. The operational active and standby roles are determined at runtime. The algorithm ensures that only one system has the active role at a specific time.

Both systems get the same service address (for example, the PFCP address) and advertise their route with different metrics. Geo-redundancy is integrated in the routing protocols so that the active system always attracts the CP traffic.

The following figure shows a geo-redundant MAG-c deployment.
Figure 1. Geo-redundant MAG-c deployment

Operational and administrative roles

Each system in a geo-redundant deployment has one of the following operational roles at runtime:
  • active – attracts and processes the traffic
  • standby – takes over from the active system when required

Only one system is active and only the active system processes traffic.

Each system also has one of the following configured administrative roles:
  • primary
  • secondary
The primary system is preferred over the secondary when the active role is assigned.

The administrative and operational roles represent two different concepts; that is, a primary system can be standby, and a secondary system can be active.

The following events trigger a switchover of the operational roles:

  • failure of the active system
  • execution of the following command for a manual switchover
    admin redundancy mc-mobile-switchover

The mc-mobile protocol runs between the two systems to select the active system. The standby system detects a failure of the active system when mc-mobile goes down. Optionally, a BFD session can be bound to mc-mobile to speed up the failure detection.

Use the following command to display the administrative and operational roles.
show redundancy multi-chassis mc-mobile peer

Traffic detection

A network issue that brings down the mc-mobile protocol triggers an unwanted switchover when the active system has not failed. To avoid the actual switchover in this scenario, the standby system listens for incoming traffic (traffic detection) before switching to the active role.

Use the following command to configure the traffic detection behavior on the standby system.
configure redundancy multi-chassis peer mc-mobile traffic-detection

When you specify the relaxed option for the traffic detection command, the standby system changes to the active role only when it receives a PFCP or a IBCP packet (for BNG).

In strict mode, the standby system changes to the active role when it receives a PFCP packet and a GTP-C packet on S11 for 4G FWA or an HTTP/2 packet on N11 for 5G SA FWA.

Use the following command to configure traffic detection behavior on the active system.
configure redundancy multi-chassis peer mc-mobile master-traffic-detection
When the master-traffic-detection command is enabled, the active system performs traffic detection to avoid an active/active scenario when mc-mobile is down.
Note: Nokia recommends enabling the master-traffic-detection command and configuring the traffic-detection command to the relaxed option for BNG deployment and the strict option for FWA deployment.

If the number of BNG-UPs is small, you can ensure that the MAG-c receives PFCP or IBCP packets during traffic detection by decreasing the PFCP heartbeat timer on the BNG-UP and increasing the traffic detection time on the MAG-c.

Use the following command to decrease the PFCP heartbeat timer on the BNG-UP or FWA-UP:
Note: The BNG-UP and FWA-UP support both the MD-CLI and the classic CLI, while the MAG-c only supports the classic CLI.
  • MD-CLI
    configure subscriber-mgmt pfcp association heartbeat
  • classic CLI
    configure subscriber-mgmt pfcp-association heartbeat
Use the following command to increase the traffic detection timer on the MAG-c.
configure redundancy multi-chassis peer mc-mobile traffic-detection-poll-timer

State synchronization

The session states are synchronized between the active and standby system to ensure continuity of service after a switchover.

The system can be in one of the following synchronization states:

  • hot – all session states are synchronized
  • warm – synchronization is ongoing
  • cold – no session states are synchronized
Use the following command to configure the session state synchronization.
configure redundancy multi-chassis peer mc-mobile mc-complete-ue-sync
Use the following command to display the synchronization state.
show redundancy multi-chassis mc-mobile

Routing

The active system attracts traffic by advertising its corresponding route with a better metric than the standby system. The active and standby systems advertise the same route with different metrics based on their operational state. To achieve routes with different metrics, use the following command to configure a router policy to export the route and configure different entries with different metrics. 
configure router policy-options policy-statement entry
The options for the from state command in the preceding context include the following:
  • mobile-master

    Routes associated with an active system match this entry.

  • mobile-slave

    Routes associated with the following systems match this entry:

    • standby system when mc-mobile is down or shunting is down (if shunting is configured) or shunting is not configured (see Shunting)
      Note: When mc-mobile is up and shunting is up, the route on the standby system does not match this entry.
    • active system during manual switchover after the active system switches to standby, but before the route is withdrawn from the active system
  • mobile-pre-slave

    Routes associated with an active system during a manual switchover before the active system switches to standby match this entry.

The configured metrics on the primary and secondary systems for each state must meet the following requirements:

  • The metric values for each state must be assigned from best to worst in the following order:
    1. primary active (best metric value)
    2. secondary active
    3. primary standby
    4. secondary standby (worst metric value)
  • The mobile-pre-slave and the mobile-master metric values must be identical.

Shunting

When the standby system receives a packet (for example, before the routing finishes convergence after a switchover), it can forward the packet to the active system. This behavior, which is called shunting, is configurable.

Use the following command to enable shunting.
configure redundancy multi-chassis peer mc-mobile mc-redirect

Shunting is supported for VPRN over generic routing encapsulation (VPRN-over-GRE) service destination point (SDP) for the following types of traffic:

  • PFCP
  • IBCP
  • RADIUS CoA
  • GTP-C
  • HTTP/2

The standby system performs shunting when a received and resolved multiprotocol BGP (MPBGP) VPN-IPv4 or VPN-IPv6 route matches the local route for supported traffic. The MPBGP route is preferred over the local route.

Manual switchover

Use the following command to execute a manual switchover.
admin redundancy mc-mobile-switchover

A manual switchover can only be triggered on the active system.

The process of a manual switchover is as follows:

  1. A user executes the mc-mobile-switchover command on the active system.
  2. The active system starts synchronizing its session states with the standby system and changes its state to mobile-pre-slave, which triggers a routing metric update.
  3. When the synchronization is complete, the active system changes its state to mobile-slave, which triggers a next routing metric update.
  4. If configured, shunting is enabled on the active system.
  5. The standby system becomes the active system and advertises its route with state mobile-master.
  6. The previously active system (now standby) withdraws its routes.

Deploying and configuring geo-redundancy

Deployment guidelines

The following guidelines apply to geo-redundant deployments:

  • Configure the PFCP path timers such that the termination of a PFCP path takes longer than the completion of a geo-redundancy switchover, including the detection time and routing convergence. Otherwise, the BNG-UPs or FWA-UPs may terminate a PFCP path and remove all corresponding sessions during a geo-redundancy switchover.

    Use the PFCP headless mode to achieve the preceding configuration. See PFCP connectivity failure for more information about the PFCP path timers.

  • When adding a new configuration on a geo-redundant pair, provision the standby system before the active system.
  • Use the following command to configure the relaxed option for fixed access geo-redundant deployments and the strict option for FWA deployments.
    configure redundancy multi-chassis peer mc-mobile traffic-detection
  • For fixed access geo-redundant deployments, Nokia recommends increasing the traffic detection timer to 10 seconds using the following command.
    configure redundancy multi-chassis peer mc-mobile traffic-detection-poll-timer

Configuration commands

The following commands and their leaf commands configure geo-redundancy.
configure redundancy multi-chassis peer mc-mobile
configure router policy-options policy-statement

The following example shows a geo-redundant configuration for an active system, with the relaxed option specified for traffic detection, as recommended for BNG deployments.

Geo-redundant configuration on a primary system (BNG-UP deployment)

config>redundancy>multi-chassis# info
----------------------------------------------
            peer 46.46.46.46 create
                mc-mobile
                    mc-redirect
                    mc-complete-ue-sync
                    master-traffic-detection enable
                    traffic-detection relaxed
                    mobile-gateway 1 role primary
                        no shutdown
                    exit
                exit
                no shutdown
            exit
----------------------------------------------
config>router>policy-options>policy-statement# info
----------------------------------------------
                entry 10
                    from
                        prefix-list "prefix-list-1"
                        state mobile-slave
                    exit
                    action accept
                        community add "vprn100"
                        metric set 30
                    exit
                exit
                entry 20
                    from
                        prefix-list "prefix-list-1"
                        state mobile-master
                    exit
                    action accept
                        community add "vprn100"
                        metric set 10
                    exit
                exit
                entry 30
                    from
                        prefix-list "prefix-list-1"
                        state mobile-pre-slave
                    exit
                    action accept
                        community add "vprn100"
                        metric set 10
                    exit
                exit

The following example shows a geo-redundant configuration for a standby system, with the relaxed option specified for traffic detection, as recommended for BNG deployments.

Geo-redundant configuration on a standby system (BNG-UP deployment)

config>redundancy>multi-chassis# info
----------------------------------------------
            peer 45.45.45.45 create
                mc-mobile
                    mc-redirect
                    mc-complete-ue-sync
                    master-traffic-detection enable
                    traffic-detection relaxed
                    mobile-gateway 1 role secondary
                        no shutdown
                    exit
                exit
                no shutdown
            exit
----------------------------------------------
config>router>policy-options# info
            policy-statement "mcred"
                entry 10
                    from
                        prefix-list "prefix-list-1"
                        state mobile-slave
                    exit
                    action accept
                        community add "vprn100"
                        metric set 40
                    exit
                exit
                entry 20
                    from
                        prefix-list "prefix-list-1"
                        state mobile-master
                    exit
                    action accept
                        community add "vprn100"
                        metric set 20
                    exit
                exit
                entry 30
                    from
                        prefix-list "prefix-list-1"
                        state mobile-pre-slave
                    exit
                    action accept
                        community add "vprn100"
                        metric set 20
                    exit
                exit
            exit