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
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.
Operational and administrative roles
- 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.
- primary
- secondary
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.
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.
configure redundancy multi-chassis peer mc-mobile traffic-detection
When
the traffic detection is set to relaxed, the standby system changes to
the active role only when it receives a PFCP or IBCP packet. configure redundancy multi-chassis peer mc-mobile master-traffic-detection
When
the preceding command is enabled, the active system performs traffic detection to avoid
an active/active scenario when mc-mobile is down.If the number of BNG-UPs is small, 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.
- MD-CLI
configure subscriber-mgmt pfcp association heartbeat
- classic
CLI
configure subscriber-mgmt pfcp-association heartbeat
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
configure redundancy multi-chassis peer mc-mobile mc-complete-ue-sync
show redundancy multi-chassis mc-mobile
Routing
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
- standby system when mc-mobile is down or shunting is down (if shunting is
configured) or shunting is not configured (see Shunting)
- 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:
- primary active (best metric value)
- secondary active
- primary standby
- 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.
configure redundancy multi-chassis peer mc-mobile mc-redirect
Shunting is supported for VPRN over generic routing encapsulation (GRE) service destination point (SDP) for the following types of traffic:
- PFCP
- IBCP
- RADIUS CoA
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
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:
- A user executes the mc-mobile-switchover command on the active system.
- 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.
- When the synchronization is complete, the active system changes its state to mobile-slave, which triggers a next routing metric update.
- If configured, shunting is enabled on the active system.
- The standby system becomes the active system and advertises its route with state mobile-master.
- The previously active system (now standby) withdraws its routes.
Deploying and configuring geo-redundancy
Deployment guidelines
- 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 the routing convergence. Otherwise, the BNG-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.
- For fixed access geo-redundant deployments, set the traffic detection type
to relaxed using the following
command.
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
configure redundancy multi-chassis peer mc-mobile
configure router policy-options policy-statement
Geo-redundant configuration on a primary system
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
Geo-redundant configuration on a secondary system
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