Migration of Old Pools Without Chunk-Group into Pools with Chunk-Group

Migration of IP pools is carried-out in the following process:

  1. Add new pools with chunkGroupSize configuration for the same vDNN (with IP ranges unique across the pools within the system and also the subnets for the address-ranges of the new pool must be as per standard IP-subnet). Here, reserve-contiguous-groups can be enabled or disabled based on the usage or planning.

  2. Check if the new pools are showing from show ipam pool output.

    Sample config:

    [smf-m6-cndp-rack2/data] smf# show ipam pool Mon Jul 24 08:34:36.617 UTC+00:00 ==========================================================================================
    PoolName Ipv4Utilization Ipv6AddrUtilization Ipv6PrefixUtilization ==========================================================================================
    data-ipv6-pool2 92.23% 0.00% 97.66%
    data-ipv6-pool1 59.42% 0.00% 34.40%
    data-ipv6-pool4 0.00% 0.00% 0.00%
    data-ipv6-pool3 1.70% 0.00% 1.10%
    ==========================================================================================
    [smf-m6-cndp-rack2/data] smf#
    
  3. When the newly added pool is visible from show ipam pool output, check if the new pool is active with chunk-group-wise allocation as per chunks-per-group configuration. It can be done using the command show ipam pool <newly added pool> ipv4-addr/ ipv6-prefix.

    Sample config:

    show ipam pool data-ipv6-pool4 ipv4-addr/ ipv6-prefix
  4. Mark the old pools without chunk-group as offline. Expectation is New IPs must not be allocated from the old pool further.

  5. For the ongoing traffic, chunks from the new pool will be allocated as per chunk-group configuration. It can be checked using the same CLI.

    show ipam dp <DP association> show ipam pool <new pool> ipv4-addr/ ipv6-prefix
  6. As sessions associated with IPs from the old pools are terminated, they release the IPs from the old pools, and further release their chunks.

  7. Wait until all the chunks from the old pools are released.

    Note

    If there are further IPs still stuck/stale with old pools, then the subscribers can be cleared with admin-clear CLIs. For example, show subscriber count nf-service smf dnn <dnn> show subscriber count nf-service smf ipv4-pool/ ipv6-pool <old pool>, and clear subscriber nf-service smf ipv4-pool/ ipv6-pool <old pool>. Wait for all the subscribers to get cleared from the old pools with this CLI and the corresponding old routes toward the UPF must also get deleted.

  8. Check if all the subscribers are moved back in the new pool with chunk-group.

    show subscriber count nf-service smf ipv4-pool/ ipv6-pool <new pool>
  9. When all the subscriber move back in the new pool, delete the configuration for the old pool from IPAM.

    [smf-m6-cndp-rack2/data] smf(config)# ipam instance 1 
    Mon Jul 24 08:43:19.875 UTC+00:00 
    [smf-m6-cndp-rack2/data] smf(config-instance-1)# no address-pool data-ipv6-pool2
Note

It is recommended to carry-out the migration of old pools without chunk-group into pools with chunk-group in low-traffic hours/maintenance window.