Cisco Cisco ASR 5700 Fehlerbehebungsanleitung

Seite von 3
gtpp storage-server mode local
Step 3. Please kill aaaproxy using this command in hidden mode. task kill facility aaaproxy all.
(Task kill will make the local mode to be applied to default group.)
Step 4. Come out of hidden mode
Step 5. Check show gtpp storage-server local file statistics is increasing.
Step 6. Run show gtpp counters all every 30 secs. This should come down to zero in a span of 5
minutes.
Step 7. Revert the mode to remote. config context gaggsnctx gtpp group default gtpp storage-
server mode remote
Step 8. Check the archived counter (show gtpp counters all) is not increasing and show gtpp
storage-server local file statistics
 is not increasing.
Step 9. Take the SSD and send back to us for verification to make sure that config is intact and all
steps are followed.
Note: After completion of activity, if you know the procedure to remove CDR files from HDD.
Go ahead. (if not, please engage the TAC engineer for this activity some other day)
If  aaaproxy doesn’t recovery after 1 minute, refer the recovery procedure.
Procedure to recover of aaaproxy
Technical explanation
Because of various reasons (most probably misconfigurations) for some APNs , CDRs go to
default group. In default group, you do not have CGF servers configured and hence the requests
get stuck. For the APNs for which there is a valid gtpp group configured , CDRs should not be
archived but they may go to the archive queue.
From archive queue you can only process five requests at a time. In case if all five requests
belong to the APNs which misconfiguration then  top five requests are never freed thus blocking all
CDRs behind the queue. This means the CDRs generated on specific month are stuck there and
processed wrongly.
ASR5x00 has an upper limit how many CDRs can be archived. Once the limit is crossed the
archived CDRs get purged. This makes way for the valid CDRs generated on a specific month and
they get released. 
For example,
If the queue has five requests and rest of the requests are belonging to the valid APN with correct
config and  when you  process, every time the five requests never gets freed as there is no server
configured and you are stuck forever as you process only five CDRs at a time. However if one of
the requests gets purged, this means you have 4 requests belonging to the invalid config APN and
next one is valid APN. Now when you process five requests the four requests are stuck but fifth