Feature Description

The AMF protocol pod maintains the security context cache, NAS UL, and DL counter information for subscribers. Whenever this information is modified in the cache, the same information gets replicated to the peer protocol pod to ensure high availability.

Note

It is recommended to support a maximum of two protocol pod replicas for high availability. If both protocol pod replicas go down back to back or together, the security context data gets lost.

Typically, the two replicas of protocol endpoint pods are spawned on active-standby mode on different servers to achieve redundancy and resiliency.

Note

In a single server deployment of AMF, two replicas of protocol-ep pods can be spawned on the same node by enabling the k8s single-node true command in the AMF Ops-center. For more information on single server deployment of AMF, contact your Cisco account representative.

The AMF protocol pods determine among themselves who is the leader by using the Etcd for electing a leader. The leader information gets registered in the topology management module in the Etcd. The leader selection upgradation helps with replicating the security context cache to the other AMF protocol pod. If the leader pod goes down, the other (follower) pod becomes active and handles the traffic. The follower pod works with the replicated security context cache, UL, and DL counters from the leader.

The AMF-SCTP and the AMF-service pods query the leader information for the AMF protocol pod before making any IPC call. When the leader pod goes down, the other pod gets selected as a leader and the subsequent IPC request goes to the selected protocol pod.

If a pod comes up, the security context cache gets synced with the peer before the pod becomes ready.