UP Geo Redundancy

Feature Summary

Table 1. Feature Summary

Applicable Product(s) or Functional Area

cnBNG

Applicable Platform(s)

SMI

Feature Default Setting

Disabled – Configuration Required

Related Changes in this Release

First Release

Related Documentation

Not Applicable

Revision History

Table 2. Revision History
Revision Details Release

First introduced

2022.04.0

Feature Description


Note


This feature is Network Services Orchestrator (NSO) integrated.


To provide redundancy for the subscriber sessions, cnBNG supports Geographical Redundancy across multiple User Planes (UPs), without having any L1 or L 2 connectivity between them. The UPs may be located in multiple geographical locations, and they have L3 connectivity over a shared core network through IP or MPLS routing.

Geo redundancy feature is currently supported for IPoE DHCP-triggered (IPv4, IPv6 and dual-stack) sessions.

UP Geo Redundancy Architecture

The following figure depicts a UP geo redundancy deployment network model:

Figure 1. UP Geo Redundancy Deployment Network Model


The redundancy pairing between UPs work by synchronizing the subscriber state from cnBNG CP to primary (active) and its subordinate (standby).

Geo redundancy works in conjunction with any of the access technologies. The CPEs are agnostic to redundancy; they see only one UP or gateway. The access nodes are dual or multi-homed for redundancy using a variety of technologies based on the service provider network design and choices. Multi-chassis Link Aggregation (MC-LAG), dual-homed (Multiple Spanning Tree - Access Gateway or MST-AG), Ring (MST-AG or G.8032), xSTP and seamless MPLS (pseudowires) are a few such access networks.

For more information on access technologies supported on UP, see the Broadband Network Gateway Configuration Guide for Cisco ASR 9000 Series Routers guide.

Subscriber Redundancy Group

Geo redundancy for subscribers is delivered by transferring the relevant session state from primary UP to subordinate UP which can then help in failover (FO) or planned switchover (SO) of sessions from one UP to another. Subscriber Redundancy Group (SRG) which is a set of access-interface (or a single access-interface) is introduced in cnBNG, and all subscribers in an SRG would FO or SO as a group.

The SRG has two modes of operation:

  • Hot-standby

  • Warm-standby

Currently UP geo redundancy supports only the hot-standby subordinate mode. This is achieved by a 1:1 mirroring of subscriber session state from the primary to the subordinate where the entire provisioning is done before the FO or SO. The sessions provisioned on subordinate is in sync with the set up on the primary. Because the data plane is already set up for sub-second traffic impact, there is minimal action on switchover in the case of hot-standby mode and therefore, it is suitable for subscribers requiring high service level agreement (SLA). With appropriate capacity planning, the sessions can also be distributed across multiple UPs to achieve an M: N model. The primary-subordinate terminology is always in the context of a specific SRG; not for the UP as a whole.

The following figure depicts a typical subscriber redundancy group (SRG):

Figure 2. Subscriber Redundancy Group


SRG Virtual MAC

For seamless switchover between two UPs, the L2-connected CPE devices must not detect change in gateway MAC and IPv4 or IPv6 addresses. The access technology like MC-LAG uses the same MAC address on both UPs with active-standby roles, providing seamless switchover. Where MAC sharing is not provided by the access technology or protocol (like MST-AG, G.8032), the cnBNG SRG virtual MAC (vMAC) must be used.

For more information on SRG Virtual MAC, see the BNG Geo Redundancy chapter of Broadband Network Gateway Configuration Guide for Cisco ASR 9000 Series Routers guide.

Session Distribution Across SRG

The session distribution across SRGs can be in either of these modes:

  • Active-standby mode:

    In this mode, a dedicated standby UP can be a subordinate for multiple SRGs from different active UPs which are primaries for those respective SRGs.

    This figure shows an active-standby mode of session distribution across SRGs:

    Figure 3. Active-standby Mode of Session Distribution


    In figure A:

    • Sessions are associated with partitions (VLAN 1, 2, 3 and 4) on UP1, with each VLAN mapped to separate SRG configured as primary role.

    • UP2 acts as standby for all VLANs.

    • Each VLAN has 8K sessions terminated on it.

    In figure B:

    • An interface failure gets detected (using object-tracking of the access-interface).

    • SRG for each VLAN on UP2 gets the primary role.

    • All 32K sessions are switched to UP2.

    • UP2 sees a session termination count of 32K.

  • Active-active mode:

    In this mode, an UP can be primary for one SRG and a standby for another SRG at the same time.

    The following figure shows an active-active mode of session distribution across SRGs:

    Figure 4. Active-active Mode of Session Distribution


    In figure A:

    • Sessions are associated with partitions (VLAN 1, 2) on UP1, with each VLAN mapped to separate SRG configured as primary role.

    • Sessions are associated with partitions (VLAN 3, 4) on UP2, with each VLAN mapped to separate SRG configured as primary role.

    • Each VLAN has 8K sessions terminated on it.

    • Each UP has 16K sessions terminated on it.

    In figure B:

    • The interface associated with VLAN 2 on UP1 goes down.

    • Sessions associated with partitions (VLAN 2) on UP1 are switched to UP2.

    • UP1 sees a session termination count of 8K and UP2 sees a session termination count of 24K.

Benefits of UP Geo Redundancy

Major benefits of UP Geo Redundancy include:

  • Supports various redundancy models such as 1:1 (active-active) and M:N, including M:1.

  • Provides flexible redundancy pairing on access-link basis.

  • Works with multiple access networks such as MC-LAG, dual-home and OLT rings.

  • Supports various types of subscribers such as IPv4, IPv6 and dual-stack IPoE sessions.

  • Provides failure protection to access link failures, N4 link failures, LC failures, RP failures and chassis failures.

  • Performs automatic switchovers during dynamic failures or planned events such as maintenance, upgrades and transitions.

  • Co-exists with other high availability (HA) or redundancy mechanisms.

  • Does switchover of the impacted session group only; other session groups remain on the same UP.

  • Provides fast convergence and rapid setup of sessions, with minimal subscriber impact during switchover.

  • Provides automatic routing convergence towards core and efficient address pool management.

  • Provides seamless switchover for subscriber CPE without the need for any signaling.

  • Integrates with RADIUS systems.

  • Does not impact session scale and call-per-second (CPS) during normal operation.

Supported Features in UP Geo Redundancy

These base geo redundancy features are supported:

  • Multiple SRG groups to different peer routers.

  • Hot-standby mode for subordinate (that is, subscribers provisioned in hardware on the subordinate as they are synchronized).

  • Dynamic role negotiation between peers.

  • Manual SRG switchover through command line interface (CLI).

  • Dynamic failure detection using object tracking (link up-down, route and IPSLA tracking).

  • Revertive timer per SRG group.

  • SRG active-active mode without any access protocol.

  • G.8032 (dual-home and ring) access technologies.

These DHCP features are supported:

  • DHCPv6 IA-NA and IA-PD support for L2 connected sessions.

  • DHCPv4 support for L2 connected sessions.

  • DHCPv4 or DHCPv6 dual-stack support.

  • DHCP server mode.

  • Session initiation through DHCPv4 or DHCPv6 protocol.

UP Geo Redundancy Configuration Guidelines

UP Configuration Consistency

  • Geo redundancy feature infrastructure synchronizes individual subscriber session state from primary to subordinate. But, it does not synchronize the UP related configurations (namely dynamic-template, DHCP profiles, policy-maps, access-interface configurations, external RADIUS or DHCP server, and so on).

  • For successful synchronization and setup of subscriber sessions between the two UPs, it is mandatory that the relevant UP configurations must be identical on the two routers and on the access-interfaces pairs in the SRG.

  • While the access-interfaces or their types (or both) may vary between the paired UPs, their outer-VLAN tag (that is, S-VLAN imposed by the access or aggregation devices) must be identical.

  • Inconsistencies in base UP or SRG configurations may result in synchronization failure and improper setup of sessions on the subordinate.

Session Sync

Once the session is up on the primary node, the entire session information gets synced to the subordinate node. This includes dynamic synchronization of updates such as CoA or service logon.

Configuring UP Geo Redundancy

To configure the subscriber redundancy group in the control plane, use the following sample configuration:

config 
   user-plane instance instance_id 
      user-plane user_plane_name 
         subscriber-redundancy 
            group group_name 
               disable 
               domain-identifier domain_name 
               peer-identifier peer_id 
               port-id-map port-name port_name port_number 
               preferred-role-active 
               revertive-timer revertive_timer_value 
               exit 

NOTES:

  • subscriber-redundancy : Configures subscriber geo-redundancy. All SRG groups are configured in this mode.

  • group group_name : Specifies the name of the subscriber redundancy group that is unique to a user plane.

  • disable : Disables an SRG group without deleting the entire configuration of the group. By default, an SRG group is enabled.

  • domain-identifier domain_name : Specifies the domain name to identify all groups between two user planes.

  • peer-identifier peer_id : Identifies the peer user-plane for the group. This identifier must be unique across all groups in the control plane. The same peer-identifier must be configured in the peer user-plane.

  • port-id-map port-name port_name port_number : Specifies the mapping of access interfaces between user planes. At least one port-map-id must be configured.

  • preferred-role-active : This is an optional configuration.

    Sets the preferred role active for user plane. Default value: false.

  • revertive-timer revertive_timer_value : This is an optional configuration.

    Specifies the revertive timer in seconds. revertive_timer_value must be an integer in the range of 60 to 3600 . This command is available only when preferred-role-active is configured.

Configuration Example

The following is a sample configuration for configuring UP Geo Redundancy, as illustrated in Figure 5.

config
  user-plane
   instance 1
    user-plane user-plane1
    peer-address ipv4 {UP1 ipv4-address}
     subscriber-redundancy
      group Group1
       preferred-role-active
       revertive-timer       3600
       domain-identifier     domain1
       peer-identifier       Peer1
       port-id-map port-name Bundle-Ether1.10 1
      exit
     exit
    exit
    user-plane user-plane2
    peer-address ipv4 {UP2 ipv4-address}
     subscriber-redundancy
      group Group1
       domain-identifier domain1
       peer-identifier   Peer1
       port-id-map port-name Bundle-Ether2.10 1
      exit
     exit
    exit
   exit
  exit

The following diagram illustrates the sample configuration.

Figure 5. Sample Configuration

Configuration Verification

To verify the configuration, execute the following commands:

  • show subscriber redundancy [ count | debug | detail | gr-instance gr_instance_id | srg-peer-id srg_peer_id | upf upf_name ] 
  • show subscriber redundancy-sync [ gr-instance gr_instance_id | srg-peer-id srg_peer_id | upf upf_name ] 
  • show subscriber dhcp [ count | detail | filter filter_value | gr-instance instance_id | sublabel sublabel_name ] 
  • show subscriber session [ detail | filter { smupstate { upf_name/smUpSessionCreated } } ] 
  • show subscriber synchronize [ srg-peer-id peer_id | upf upf_name ] 

For more information on these commands, see the Monitoring Support section.

Configuring IPAM

Dynamic Pool Configuration

Use the following configuration to configure dynamic pool:

config 
   ipam 
      instance instance_id 
      source local 
         address-pool pool_name 
           vrf-name string
           ipv4
             split-size 
               per-cache value 
               per-dp value  
             exit
             address-range start_ipv4_address end_ipv4_address
           exit
           ipv6
             address-ranges
               split-size 
                 per-cache value 
                 per-dp value
               exit
               address-range start_ipv6_address end_ipv6_address
             exit
            prefix-ranges
               split-size 
                 per-cache value 
                 per-dp value }
               exit
               prefix-range prefix_value length prefix_length 
             exit
           exit
         exit 
   

Static Pool Configuration

Use the following configuration to configure static pool:

config 
   ipam 
     instance instance_id
       address-pool pool_name 
          vrf-name string 
          static enable user-plane srg_id
          ipv4
             split-size   
             no-split
             exit
             address-range start_ipv4_address end_ipv4_address
          exit
          ipv6
             address-ranges
               split-size 
                 no-split
               exit
               address-range start_ipv6_address end_ipv6_address
             exit
             prefix-ranges
               split-size 
                 no-split
               exit
               prefix-length prefix_length
               prefix-range prefix_value length prefix_length 
             exit
           exit
         exit 
   

NOTES:

  • ipam : Enters the IPAM Configuration mode.

  • instance instance_id : Configures multiple instances for the specified instance and enters the instance sub-mode.

  • source local : Enters the local datastore as the pool source.

  • address-pool pool_name [ address-quarantine-timer ] [ offline ] [ static user_plane_name ] [ vrf-name string ] : Configures the address pool configuration. pool_name must be the name of the address pool.

  • ipv4 : Enters the IPv4 mode of the pool.

  • split-size { per-cache value | per-dp value } : Specifies the size of the IPv4 range to be split for each IPAM cache allocation. The IPAM server consumes this configuration. The no-split command disables the splitting of the address-ranges into smaller chunks.

    per-cache value : Specifies the size of the IPv4 range to be split for each Data-Plane (User-Plane) allocation. The valid values range from 2 to 262144. The default value is 1024.

    per-dp value : Specifies the size of the IPv4 range to be split for each Data-Plane (User-Plane) allocation. The valid values range from 2 to 262144 The default value is 256.

  • address-range start_ipv4_address end_ipv4_address : Configures the IPv4 address range with the starting and ending IPv4 address.

  • ipv6 : Enters the IPv6 mode of the pool.

  • address-ranges : Enters the IPv6 address ranges sub-mode.

  • prefix-ranges : Enters the prefix ranges mode.

  • prefix-length prefix_length : Specifies the IPv6 prefix length.

  • prefix-range prefix_value length prefix_length : Specifies the IPv6 prefix range, and prefix length.

  • static enable user-plane srg_id : Associates an user plane for the static pool.

Session Synchronization between UPs

This section describes different scenarios where the subscriber needs to be synchronized to a UP manually.

Scenario 1

One UP in a Subscriber Redundancy group is active, and a session is created. Now, another UP in the same SRG is connected for the first time. All the groups in the second UP become standby. To synchronize the sessions with the second (standby) UP, use the following CLI command:

bng# subscriber redundancy session-synchronize add domain [ domain_ID ] target-upf upf_ID 

You can also use the following CLI command, if there are only two UPs involved (as in Scenario 1):

bng# subscriber redundancy session-synchronize add upf-id [ upf_ID ] target-upf upf_ID 

Example-1:

subscriber redundancy session-synchronize add domain [ Domain12 ] target-upf Upf2

The above CLI command synchronizes all the subscribers from active UP, which are part of Domain12 , to the target UP (Upf2 ).

Or,

subscriber redundancy session-synchronize add upf-id [ Upf1 ] target-upf Upf2

The above CLI command synchronizes all the subscribers from Upf1 to Upf2 .

Example-2:

The following is a sample configuration if two UPs are active, and a third UP is connected later.

subscriber redundancy session-synchronize add domain [ Domain12 Domain13 ] target-upf Upf1

The above CLI command synchronizes all the subscribers from the active UPs, which are part of Domain12 , and Domain13 to the target UP (Upf1 ).

Scenario 2

Initially, a Subscriber Redundancy group is configured on only one UP, and a session is created. Later, the second UP is configured with SRG. Now, to synchronize the session with the second UP in the group, use the following CLI command:

bng# subscriber redundancy session-synchronize add peer-id [ peer_ID ]  target-upf upf_ID 

Example:

subscriber redundancy session-synchronize add peer-id [ Peer1 ] target-upf Upf2

The above CLI command synchronizes subscribers that are part of a group with peer-id Peer1 to target UP (Upf2 ).

Scenario 3

A group is removed from an UP. To remove sessions in the group, use the following CLI command:

bng# subscriber redundancy session-synchronize delete peer-id [ peer_ID ]  target-upf upf_ID 

Example:

subscriber redundancy session-synchronize delete peer-id [ Peer1 ] target-upf Upf2

The above CLI command removes subscribers from target UP (Upf2 ) that are part of the SRG group with peer-id peer1 .

Scenario 4

All groups are removed from an UP. To remove all sessions in an UP, use the following CLI command:

bng# subscriber redundancy session-synchronize delete domain [ domain_list ]  target-upf upf_ID 

Example:

subscriber redundancy session-synchronize delete domain [ domain12 domain13 ] target-upf Upf3

The above CLI command deletes all the subscribers that are part of the domains domain12 , and domain13 from the target UP (Upf3).

Or,

subscriber redundancy session-synchronize delete upf-id [ Upf3 ] target-upf Upf3

The above CLI command deletes all the subscribers that are related to Upf3 from the target UP (Upf3 ).


Note


You can also delete all non-SRG sessions in the UP.


Scenario 5

An UP from a group is replaced with another UP. To synchronize the sessions, use the following CLI commands:

bng# subscriber redundancy session-synchronize delete peer-id [ peer_ID ]  target-upf old_upf_id 
bng# subscriber redundancy session-synchronize add peer-id [ peer_ID ]  target-upf new_upf_id 

Example:

subscriber redundancy session-synchronize delete peer-id [ peer1 ] target-upf Upf1
subscriber redundancy session-synchronize add peer-id [ peer1 ] target-upf Upf2

The above CLI commands remove the sessions in the group with peer-id peer1 from Upf1 , and add the group to Upf2 .

Scenario 6

An UP is replaced with another UP in all the groups in a domain. To synchronize the sessions, use the following CLI commands:

bng# subscriber redundancy session-synchronize delete domain [ domain_ID ]  target-upf upf_ID 
bng# subscriber redundancy session-synchronize add domain [ domain_ID ]  target-upf upf_ID 

Example:

subscriber redundancy session-synchronize delete domain [ domain1 ] target-upf Upf1 
subscriber redundancy session-synchronize add domain [ domain1 ] target-upf Upf2 

The above CLI commands remove the sessions in the groups that are part of domain1 from Upf1 , and add the groups to Upf2 .

Scenario 7

All domain/group/peers are moved from one UP to another. Initially, to delete all subscribers from the UP, use the following CLI command:

bng# subscriber redundancy session-synchronize delete upf [ upf_ID ]  target-upf upf_ID 

Example:

subscriber redundancy session-synchronize delete upf [ Upf1 ] target-upf Upf1

The above CLI command removes all the sessions from Upf1 .

Configure the second UP with the configurations deleted from the first UP. Then, to synchronize the sessions, use the following CLI command:

bng# subscriber redundancy session-synchronize add domain [ domain_list ] target-upf upf_ID 

Example:

subscriber redundancy session-synchronize add domain [ domain1...domainN ] target-upf Upf2

The above CLI command synchronizes all the sessions that are in the list of given domains to the new UP (Upf2).

Route Synchronization between CP and UP

Use the following CLI command to synchronize the routes between the Control Plane and the User Plane.

subscriber route-synchronize upf upf_name 

To check the status of route synchronization, use the following CLI command:

subscriber route-synchronize upf upf-name status 

Order of Reconciliation

It is recommended to perform the reconciliation activity in the following order:

  1. Group reconciliation

  2. Route reconciliation

  3. CP reconciliation (CP-Audit)

  4. CP-UP reconciliation

Monitoring Support

This section describes the monitoring support information for the UP Geo Redundancy feature.

Use the following show and clear commands for troubleshooting. The output of these commands provides specific configuration and status information.

clear subscriber sessmgr

Use this command to clear subscribers.

clear subscriber sessmgr [ gr-instance gr_instance_id | srg-peer-id srg_peer_id | upf upf_name ] 

NOTES:

  • clear subscriber sessmgr srg-peer-id srg_peer_id : Clears subscribers in CP and both UPs.

  • clear subscriber sessmgr upf upf_name srg-group-id srg_group_id : If the group is active, this command clears sessions in CP and both UPs. If the group is standby, this command clears sessions in the standby UP.

show subscriber redundancy

Use this command to display the key values of SRG groups.

show subscriber redundancy [ count | debug | detail | gr-instance gr_instance_id | srg-peer-id srg_peer_id | upf upf_name ] 

NOTES:

  • show subscriber redundancy count : Displays the count of SRG groups.

  • show subscriber redundancy detail : Displays the detailed content of SRG groups.

  • show subscriber redundancy upf upf_name : Displays all the groups related to UPF.

  • show subscriber redundancy peer-id peer_id debug : Displays the detailed output with event history.

The following is a sample output of the show subscriber redundancy detail command:

bng# show subscriber redundancy detail 
Fri Apr  29 14:48:36.840 UTC+00:00
subscriber-details
{
  "subResponses": [
    {
      "PeerID": "Peer15993-x",
      "GroupID": "Group-5-3-15993-x",
      "UP List": {
        "asr9k-3": {
          "N4 State": "Connected",
          "Srg State": "Up",
          "RoleChangeInProgress": true,
          "Srg Role": "Active",
          "Interface map": {
            "GigabitEthernet11636": 1,
            "GigabitEthernet11637": 2
          }
        },
        "asr9k-5": {
          "N4 State": "Disconnected",
          "Srg State": "Init",
          "Srg Role": "Standby",
          "Interface map": {
            "GigabitEthernet58174": 1,
            "GigabitEthernet58175": 2
          }
        }
      }
    }
  ]
}

show subscriber redundancy-sync

Use this command to display the subscriber reconciliation details.

show subscriber redundancy-sync [ gr-instance gr_instance_id | srg-peer-id srg_peer_id | upf upf_name ] 

NOTES:

  • gr-instance gr_instance_id : Displays the reconciliation details for the specified GR instance.

  • srg-peer-id srg_peer_id : Displays the reconciliation details for the specified SRG peer ID.

  • upf upf_name : Displays the reconciliation details for the specified UPF.

The following is a sample output of the show subscriber redundancy-sync upf upf_name command:

bng#  show subscriber redundancy-sync upf asr9k-1
Tue Apr  5  17:31:15.659 UTC+00:00
subscriber-details
{
  "Upf": "asr9k-1",
  "State": "Completed",
  "Status": "Passed",
  "Total Number of Groups": 2914,
  "Number of enabled Groups": 2914,
  "Maximum Duration": 180,
  "Started": "2022-04-05 17:31:30 +0000 UTC",
  "Ended": "2022-04-05 17:31:33 +0000 UTC",
  "Time Taken": "3 Seconds"
}

show subscriber dhcp

Use this command to display the DHCP CDL record keys per session.

show subscriber dhcp [ count | detail | filter filter_value | gr-instance instance_id | sublabel sublabel_name ] 

NOTES:

  • show subscriber dhcp detail : Displays the session details from DHCP CDL record.

The following is a sample output of the show subscriber dhcp command:

bng# show subscriber dhcp
Mon Mar  14 09:12:59.135 UTC+00:00
subscriber-details 
{
  "subResponses": [
    {
      "records": [
        {
          "cdl-keys": [
            "aa11.0000.0001:m:100:v1:200:v2:1:p:Peer1:r@dhcp",
            "sublabel:33554433@dhcp",
            "type:dhcp",
            "mac:aa11.0000.0001",
            "srg-peer-id:Peer1",
            "upf:asr9k-2",
            "upf:asr9k-1",
            "port-id:asr9k-1/GigabitEthernet0/0/0/1",
            "port-id:asr9k-2/GigabitEthernet0/0/0/3",
            "vrf:ISP",
            "ipv4-addr:pool-ISP/11.0.96.2",
            "ipv4-pool:pool-ISP",
            "ipv4-range:pool-ISP/11.0.0.1",
            "ipv4-startrange:pool-ISP/11.0.96.0",
            "ipv4-state:bound",
            "ipv6-addr-startrange:pool-ISP/1:2::2000",
            "ipv6-addr:pool-ISP/1:2::2000",
            "ipv6-addr-pool:pool-ISP",
            "ipv6-addr-range:pool-ISP/1:2::1",
            "ipv6-addr-state:bound",
            "afi:dual"
          ]
        }
      ]
    }
  ]
}

show subscriber session

Use this command to display the session manager (SM) CDL record keys per session.

show subscriber session [ detail | filter { smupstate { upf_name/smUpSessionCreated } } ] 

NOTES:

  • show subscriber session detail : Displays the session details from SM CDL record.

  • show subscriber session filter { smupstate { upf_name/smUpSessionCreated } } : Use this command to check whether the session is created in the respective UPF for the SRG sessions.

    The session count for both UPFs show up in both SM and DHCP CDL records after SRG is created successfully in the respective UPFs.

The following is a sample output of the show subscriber session command:

bng# show subscriber session
Mon Mar  14 09:12:52.653 UTC+00:00
subscriber-details 
{
  "subResponses": [
    {
      "records": [
        {
          "cdl-keys": [
            "33554433@sm",
            "acct-sess-id:Local_DC_33554433@sm",
            "upf:asr9k-1",
            "port-id:asr9k-1/GigabitEthernet0/0/0/1",
            "feat-template:svc1",
            "feat-template:automation-feature-template-accounting",
            "type:sessmgr",
            "mac:aa11.0000.0001",
            "sesstype:ipoe",
            "srg-peer-id:Peer1",
            "smupstate:smUpSessionCreated",
            "up-subs-id:asr9k-1/1",
            "smupstate:asr9k-1/smUpSessionCreated",
            "srg-group-id:asr9k-1/Group1",
            "upf:asr9k-2",
            "port-id:asr9k-2/GigabitEthernet0/0/0/3",
            "srg-group-id:asr9k-2/Group1",
            "smstate:established",
            "up-subs-id:asr9k-2/1",
            "smupstate:asr9k-2/smUpSessionCreated",
            "afi:dual"
          ]
        }
      ]
    }
  ]
}

show subscriber synchronize

The subscriber session-synchronize [ srg-peer-id peer_id | upf upf_name ] command is used to synchronize subscriber information on the UP.

To view the status of subscriber information synchronization, use the following CLI command:

show subscriber synchronize [ srg-peer-id peer_id | upf upf_name ] 

The following is a sample output of the show subscriber synchronize command:

bng# show subscriber synchronize srg-peer-id Peer108-x
Tue Apr  5  06:31:51.167 UTC+00:00
subscriber-details
{
  "asr9k-11": {
    "upf": "asr9k-11",
    "sync status": "sync start in progress",
    "sync state": "Start",
    "sync startTIme": "05 Apr 22 06:31 UTC",
    "sync srgGroupId": "Group-11-8-108-x"
  },
  "asr9k-8": {
    "upf": "asr9k-8",
    "sync status": "sync start in progress",
    "sync state": "Start",
    "sync startTIme": "05 Apr 22 06:31 UTC",
    "sync srgGroupId": "Group-11-8-108-x"
  }
}

show ipam dp

Use this command to view the list of UPFs to which the corresponding routes (both static and dynamic) are pushed.

  • show ipam dp peerid { ipv4-address | ipv6-address | ipv6-prefix } 

NOTES:

  • show ipam dp peerid ipv4-address : Displays the UPFs of IPv4 address type

  • show ipam dp peerid ipv6-address : Displays the UPFs of IPv6 address type

  • show ipam dp peerid ipv6-prefix : Displays the UPFs of IPv6 prefix type

The following is a sample output of the show ipam dp peerid ipv4-address :

bng# show ipam dp peer-asr9k2 ipv4-addr
Wed Mar  30 12:43:09.313 UTC+00:00
 
======================================================================================================
Flag  Indication: S(Static) O(Offline) R(For Remote Instance) RF(Route Sync Failed)
G:N/P Indication: G(Cluster InstId) N(Native NM InstId) P(Peer NM InstId)
======================================================================================================
StartAddress          EndAddress      Route            G:N/P    Utilization   Flag      AllocContext
======================================================================================================
7.67.133.0            7.67.133.255    7.67.133.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.134.0            7.67.134.255    7.67.134.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.135.0            7.67.135.255    7.67.135.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.136.0            7.67.136.255    7.67.136.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.137.0            7.67.137.255    7.67.137.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.138.0            7.67.138.255    7.67.138.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.139.0            7.67.139.255    7.67.139.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.140.0            7.67.140.255    7.67.140.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.141.0            7.67.141.255    7.67.141.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
7.67.142.0            7.67.142.255    7.67.142.0/24    1:N/A                  S         srg-9k-static2(default)(asr9k-11,asr9k-12)
33.0.0.0              33.0.7.255      33.0.0.0/21      1:0/-1   0.20%                   automation-poolv4(default)(asr9k-11,asr9k-12)
======================================================================================================