Modify Non-NAT IP Pool

Introduction

This document describes the steps required in order to modify a Non-NAT IP pool in StarOS products ASR5500 and Cisco Virtual Packet Core with Inter Chassis Session Recovery (ICSR) and non-CUPS environment.  

Background Information

IP Address pools functionality is to allow configuring a range of IP addresses as one pool under a pool name and allow either allocation or assignment of these addresses to the subscribers. The IP address pool functionality is co-located with vpnmgr component.  You may modify an existing IP Pool with the exception of NAT without deleting only if the address space used by the pool is increasing or if the existing pool parameters are identified as being dynamically configurable.  If the pool size is decreasing or a parameter is not dynamically configurable the IP pool must be deleted and re-added.

The options here can be enabled or disabled dynamically without deleting the IP Pool. 

Note: Please check with configuration guides on the parameters to modify on a particular software release.

address-hold-timer	When this is enabled, and an active subscriber is disconnected, the IP address is held or considered still in use and is not returned to the free state until the address-hold-timer expires. This enables subscribers who reconnect within the length of time specified (in seconds) to obtain the same IP address from the IP pool.
alert-threshold	Configures IP address pool-level utilization thresholds. These thresholds take precedence over context-level IP pool thresholds.
explicit-route-advertise	When enabled, the output of show IP pool verbose includes the total number of explicit host routes.
group-name	Specifies the pool group name
include-nw-bcast	Allows pools to include the classful network and broadcast addresses that are usually excluded when a pool crosses the classful network boundaries.
nexthop-forwarding-address	Specifies the next-hop forwarding address for this pool
nw-reachability server	Binds the name of a configured network reachability server to the IP pool and enables network reachability detection for the IP pool. This takes precedence over any network reachability server settings in a subscriber configuration.
policy	Configures an address allocation policy
send-icmp-dest-unreachable	When enabled, this generates an ICMP destination unreachable PDU when the system receives a PDU destined for an unused address within the pool.
srp-activate	Activates the IP pool for Interchassis Session Recovery
suppress-switchover-arps	Sets an alert based on the Suppress Gratuitous ARPs when performing cards switchover.
tag	Adds a specific tag to the IP address pool
unicast-gratuitous-arp-address	Performs a unicast gratuitous ARP to the specified IP address rather than broadcast gratuitous ARP when gratuitous ARP generation is required.

Prerequisites - Configuration Backup

The following are the pre-requisites for IP Pool modification. If ICSR is enabled then run the steps on both ICSR chassis.

1. Confirm the version of the software that is currently running on the node show version verbose 

[local]StarOS# show version verbose 
Active Software:
Image Version: ww.x.y.zzzzz
Image Build Number: zzzzz

2. Note the system uptime of the chassis show system uptime 

[local]StarOS# show system uptime 

System uptime: 14D 10H 24M

3. Verify the system's boot configuration  show boot

[local]StarOS# show boot

boot system priority 50 \
image /flash/sftp/asr5500-AA.BB.CC.bin.SPA \
config /flash/test_config.cfg

boot system priority 51 \
image /flash/sftp/asr5500-AA.CC.CC.bin.SPA \
config /flash/backup_config.cfg

boot system priority 52 \
image /flash/asr5500-AA.BB.CC.bin.SPA \
config /flash/one_more_config.cfg

4. Save the current configuration  save configuration

[local]StarOS# save configuration /flash/<current_filename.cfg> -re 

5. Collect Support Details for the future analysis  show support details to file

[local]StarOS# show support details to file /flash/sftp/support-before-<date> compress 

6. Synchronize the file system  filesystem synchronize all

[local]StarOS# filesystem synchronize all

7. Perform additional systems health checks if needed.

Prerequisites - ICSR Health Checks

These steps are performed on both chassis to ensure they are operational and ready to take traffic in the event of a failover.

1. Log in to the Active and Standby chassis to verify their Chassis State: show srp info

2. Verify you have the correct number of sessmgrs show srp checkpoint statistics | grep Sessmgrs

3. Verify session recovery is in Ready For Recovery state show session recovery status verbose

4. Validate the SRP configuration. If the chassis’ appear healthy perform a switchover validation on the ACTIVE chassis:

[local]ASR5K# srp validate-configuration
# should get no output
[local]ASR5K# srp validate-switchover
# should get no output
[local]ASR5K# show srp info
# should get no config errors and ready for switchover

Modify IP Pool in Non-ICSR Scenario

These steps cover IP Pool modification for Non-ICSR node. Please verify the context name and pool name to be modified.

1. Busy-out the IP Pool

[local]StarOS# config
[local]StarOS(config)# context <context-name>
[local]StarOS(config-ctx)# busyout <ip or ipv6> pool name <ip pool name>

Check the port shows busyout  show ip pool summary  or  show ipv6 pool summary 

[context]StarOS# show ip pool summary 
context test5:
+-----Type: (P) - Public (R) - Private (N) - NAT
| (S) - Static (E) - Resource (O) - One-to-One NAT
| (M) - Many-to-One NAT
|
|+----State: (G) - Good (D) - Pending Delete (R)-Resizing
|| (I) - Inactive
||
||++--Priority: 0..10 (Highest (0) .. Lowest (10))
||||
||||+-Busyout: (B) - Busyout configured
|||||
|||||
vvvvv Pool Name Start Address Mask/End Address Used Avail 
----- -------------------------------- --------------- --------------- ---------------- 
PG00B test 10.10.0.0 255.255.255.0 0 254 

2. Clear remaining subscribers from the pool use context local.

[local]StarOS1# show subscribers summary ip-pool <pool name> | grep -i total

Total Subscribers: 31252

Check the number of subscribers attached with idle_time greater-than 3600 seconds.

[local]StarOS# show subscribers summary ip-pool <pool name> idle-time greater-than <seconds>

Clear subscribers either all at the same time or with pace-out-interval.

# clear subscribers ip-pool <pool name>

# clear subscribers ip-pool <pool name> idle-time greater-than <seconds> pace-out-interval <seconds>

3. Perform the IP pool configuration change. 

4. Disable busyout on the pool.

[local]StarOS# config
[local]StarOS(config)# context <context-name>
[local]StarOS(config-ctx)# no busyout <ip or ipv6> pool name <ip pool name>

Modify IP Pool in ICSR Scenario

Note: All activities to modify the IP pool should be replicated in the geo-redundant chassis. 

Ensure any changes are also planned and executed in both ICSR chassis.  The basic image here refers to the ICSR pair where H1 is the primary chassis and H2 is the back chassis.

1. Confirm that H2 is in a standby state and H1 in active state. On H2, issue the command show srp info.
You should see the Chassis State as Standby and its peer as Active

Chassis State: Standby
Peer State: Active

2. Disable the SRP link on H1. It can be done locally or on the switch/router side.
If locally, then use the show ip int sum command from SRP context to figure out the SRP port, as shown in the example below. Take note of the SRP port and VLAN ID as it is required later, and follow these steps:

[local]StarOS# context <context with SRP>
[SRP]ASR5K# show ip interface sum
Interface Name Address/Mask Port Status
======================== =================== =========================== ======
<SRP-interface-name> 10.10.1.1/24 <SRP-port> vlan <SRP-vlan> UP

Remove SRP interface-to-Port binding:

[local]StarOS# config
[local]StarOS(config)# port ethernet <SRP-port>
[local]StarOS(config-port-5/10)# vlan <SRP-vlan>
[local]StarOS(config-port-5/10)# no bind interface <SRP-interface-name> SRP
[local]StarOS(config-port-5/10)# end

3. Make sure both H1 and H2 are active show srp info
You should see both Chassis as Active

Chassis State: Active

4. Modify IP Pool on H2.

5. Make the related route map changes on the routers and firewalls (connected to H2) to match the modified pool and subnet masks on the gateway. You may skip this step if the only changes are to the IP pool parameters. If you are changing the IP pool size (subnet), numbering (new addressing), or next-hop (routing) then appropriate changes must be made on the connecting devices.

Note: If related route map changes are not made on the BGP peer routers, the IP pool route will not be learned.

6. Check the status of the modified pool on H2

[local]StarOS# context <context-name>
[context]StarOS# show ip pool
[context]StarOS# show ip pool wide
[context]StarOS# show ipv6 pool

7. Verify H2 is advertising the modified IP pool route to its BGP peers if needed.

[local]StarOS# context <context>
[context]StarOS# show ip bgp neighbors <IPv4 or IPv6 address> advertised-routes

8. Verify the modified IP pool route is learned on BGP peer routers if needed.

9. Enable the SRP link on H1. The information captured earlier about SRP interface name, port, and VLAN is required here.

Normalize the SRP interface-to-Port binding:

[local]StarOS# config
[local]StarOS(config)# port ethernet <SRP-port>
[local]StarOS(config-port-5/10)# vlan <SRP-vlan>
[local]StarOS(config-port-5/10)# bind interface <SRP-interface-name> <context with SRP>
[local]StarOS(config-port-5/10)# end

10. Ensure that H2 is in the standby state and H1 is in active state. On H2, issue the command show srp info

You should see the Chassis State as Standby and its peer as Active

Chassis State: Standby
Peer State: Active

11. Wait for 20 minutes and verify that sessions are synced.

• On H2: show srp checkpoint statistics confirm that Current Call Recovery Records and Current pre-allocated calls are matching.
• On H1: show subscribers sum connected-time greater-than 60 confirm that Total Subscribers and Active are matching.

12. From H1, perform a switchover (from H1 to H2), after verifying switchover validation status.

On H1: srp validate-switchover and show srp info | grep "Last Validate Switchover Status"
If the state of the SRP is Ready for Switchover then continue with the switchover.

Note: Do not switchover until all health checks are completed

On H1: # srp initiate-switchover

13. Ensure that H2 is in active state and H1 is in a standby state.

On H2: show srp info

You should see the Chassis State as Standby and its peer as Active

Chassis State: Active
Peer State: Standby

14. Test the modified IP Pool on the H2. Make sure that the subscriber connected to this pool is able to reach all services.

15. Disable the SRP link on H2. It can be done locally or on the switch/router side.  If locally, then use the show ip int sum command from SRP context to figure
out the SRP port, as shown in this example here. Take note of the SRP port and VLAN ID as it is requried later, and follow these steps:

[local]StarOS# context <context with SRP>
[SRP]ASR5K# show ip interface sum
Interface Name Address/Mask Port Status
======================== =================== =========================== ======
<SRP-interface-name> 10.10.1.1/24 <SRP-port> vlan <SRP-vlan> UP

Remove SRP interface-to-Port binding:

[local]StarOS# config
[local]StarOS(config)# port ethernet <SRP-port>
[local]StarOS(config-port-5/10)# vlan <SRP-vlan>
[local]StarOS(config-port-5/10)# no bind interface <SRP-interface-name> SRP
[local]StarOS(config-port-5/10)# end

16. Ensure that both H1 and H2 are active. show srp info

You should see both Chassis as Active.

Chassis State: Active

17. Modify IP Pool on H1.

18. Make the related route map changes on the routers and firewalls (connected to H1) to match the modified pool and subnet masks on the gateway. You may skip this step if the only changes are to the IP pool parameters. If you are changing the IP pool size (subnet), numbering (new addressing), or next-hop (routing) then appropriate changes must be made on the connecting devices.

Note: If related route map changes are not made on the BGP peer routers, the IP pool route will not be learned.

19. Check the status of the modified pool on H1.

[local]StarOS# context <context-name>
[context]StarOS# show ip pool
[context]StarOS# show ip pool wide
[context]StarOS# show ipv6 pool

20. Verify H1 is advertising the modified IP pool route to its BGP peers if needed.

[local]StarOS# context <context>
[context]StarOS# show ip bgp neighbors <IPv4 or IPv6 address> advertised-routes

21. Verify the modified IP pool route is learned on BGP peer routers if needed.

22. Enable the SRP link on H2. The information captured earlier about SRP interface name, port and VLAN is required here.

Normalize the SRP interface-to-Port binding:

[local]StarOS# config
[local]StarOS(config)# port ethernet <SRP-port>
[local]StarOS(config-port-5/10)# vlan <SRP-vlan>
[local]StarOS(config-port-5/10)# bind interface <SRP-interface-name> <context with SRP>
[local]StarOS(config-port-5/10)# end

23. Ensure that H1 is in the standby state and H2 is in active state. On H1, issue the command show srp info

You should see the Chassis State as Standby and its peer as Active.

Chassis State: Standby
Peer State: Active

24. Wait for 20 minutes and verify that sessions are synced.

On H1: show srp checkpoint statistics confirm that Current Call Recovery Records and Current pre-allocated calls are matching.
On H2: show subscribers sum connected-time greater-than 60 confirm that Total Subscribers and Active are matching.

25. From H2, perform a switchover (from H2 to H1), after verifying switchover validation status.

On H2: srp validate-switchover and show srp info | grep "Last Validate Switchover Status"
If the state of SRP is Ready for Switchover then continue with switchover.

Note: Do not switchover until all health checks are completed.

On H2: # srp initiate-switchover

26. Ensure that H1 is in active state and H2 is in standby state.

On H1: show srp info
You should see the Chassis State as Standby and its peer as Active.

Chassis State: Active
Peer State: Standby

27. Test the modified IP Pool on the H1. Make sure that the subscriber connected to this pool is able to reach all services.

Post Activity

After all IP pool changes are complete and call testing is successful continue to save the new configuration changes.

1. Verify the system's boot configuration  show boot

[local]StarOS# show boot

boot system priority 50 \
image /flash/sftp/asr5500-AA.BB.CC.bin.SPA \
config /flash/test_config.cfg

boot system priority 51 \
image /flash/sftp/asr5500-AA.CC.CC.bin.SPA \
config /flash/backup_config.cfg

boot system priority 52 \
image /flash/asr5500-AA.BB.CC.bin.SPA \
config /flash/one_more_config.cfg

2. Save the current configuration  save configuration

[local]StarOS# save configuration /flash/<new-filename.cfg> -re -no

3. Change the boot priority, so that the new configuration is loaded if the chassis is reloaded. boot system priority

[local]StarOS# config
[local]StarOS(config)# boot system priority <n-1> image /flash/<image-file-name>.bin config /flash/<new-filename.cfg>.cfg
[local]StarOS(config)# end

4. Synchronize the file system  filesystem synchronize all

[local]StarOS# filesystem synchronize all -no

5. Collect post-activity Support Details for future analysis show support details to file.

[local]StarOS# show support details to file /flash/sftp/support-after-<date> compress 

6. Perform additional systems health checks if needed.

Delete / Add IP Pools

The procedure above does not cover scenario adding/deleting IP pools with SRP.

• In order to delete IP Pool:
  
  
  1. Break SRP connection as shown above.
  2. After the SRPConnDown then delete IP pools on both chassis.
     
     
• In order to add IP pool:
  
  

1. Break SRP connection as shown above.
2. After the SRPConnDown then add IP pools on both chassis.

Known Errors

• Failure: session managers in GR PActv State 

  
  The error is reported when clear subscribers are sent and ICSR does not complete syncing or SRP connection down.  It is an expected error because syncing and/or connection between Active and Standby chassis are not completed or broken, the node is unable to clear subscribers and the clear command should be rejected.
  
  

• Failure: Old VRF/Pool Information still persistent, clearing sessions still in progress. Please wait

  Verify IP that is being in use with show ip pool address pool-name <name> used  Note this is a context-specific command. 
  Force cleanup and delete the pool - no ip|ipv6 pool <pool_name> force-cleanup
  Re-add the IP pool again.