7 Fault Recovery

This chapter describes the procedures to perform fault recovery for Oracle Communications Cloud Native Core, Network Repository Function (NRF) deployment.

7.1 Overview

You must take database backup and restore it either on the same or a different cluster. It uses the NRF database to run any command or follow instructions.

Note:

This chapter describes scenario-based procedures to restore NRF databases only. To restore all the databases that are part of cnDBTier, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide available on My Oracle Support (MOS).

7.2 Database Model of NRF

The NRF database consists of the following:

  • Configuration Data: The configuration data is exclusive for a given NRF instance. You can configure NRF instance specific configurations using RESTful config API exposed by ocnrf-nrfconfiguration service through the Oracle Communications Cloud Native Configuration Console (CNC Console).
  • State Data: This contains the data belonging to NFProfiles and NFSubscriptions.

Figure 7-1 NRF Database Model


NRF Database Model

The above image shows the database model of a three site geo replicated NRF and represents how each NRF instance is using it's dedicated database. The data is getting replicated to all other sites of the cnDBTier cluster so that the data is available on all the cnDBTier cluster sites in case of a cnDBTier instance failure. The cnDBTier instance of each site has the data of its own site and the replicated data of the other two sites. All the three cnDBTier instances are replicated with each other.

Note:

To recover cnDBTier through automated backup file or on-demand backup from mate site, see the restore procedure in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

7.3 Impacted Area

The following table shares information about the impacted areas during NRF fault recovery:

Table 7-1 Impacted Areas

Scenario Requires Fault Recovery or re-install of CNE? Requires Fault Recovery or re-install of cnDBTier? Requires Fault Recovery or re-install of NRF?
Scenario 1: NRF Migration to a New Cluster Yes, if cluster is not present. Yes, if cnDBTier is not present. Yes
Scenario 2: Deployment Failure (NRF Corruption) No No Yes
Scenario 3: NRF cnDBTier Corruption No Yes, in case replication is not up. No, use Helm upgrade of the same NRF version to update the NRF configuration if required. For example, change in cnDBTier service information, such as cnDB endpoints, DB credentials, and so on. Refer to NRF Behavior Post Fault Recovery section.
Scenario 4: Site Failure Yes Yes Yes

7.4 Prerequisites

Before you take any action for fault recovery, ensure that following prerequisites are met:

  • cnDBTier must be in healthy state and available on single or multiple sites along with NRF. To verify the health status of cnDBTier, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  • The database backup from a healthy site must be available. The database backup can be taken from a healthy georedundant mated site or from a latest scheduled automatic backup.
  • Automatic backup should be enabled on cnDBTier. Scheduled regular backups help to:
    • Restore stable version of the network function database
    • Minimize significant loss of data due to upgrade or roll back failures
    • Minimize loss of data due to system failure
    • Minimize loss of data due to data corruption or deletion due to external input
    • Migrate network function database information from one site to another
  • Docker images used during the last installation or upgrade must be retained in the external data source.
  • Custom values file used at the time of NRF deployment is retained. If the ocnrf_custom_values.yaml file is not retained, then regenerate it manually. This task increases the overall fault recovery time.
  • The following files must be available for fault recovery:
    • Custom values file (ocnrf-custom-values-<release_number>)
    • Helm charts (ocnrf-<release_number>.tgz)
    • Secrets and Certificates
    • RBAC resources
  • If the NRF site which is under recovery is receiving the traffic, perform the controlled shutdown procedure to isolate the site. For more information, see Graceful Shutdown of NRF Deployment.

7.5 Fault Recovery Scenarios

This section describes the fault recovery procedures for various scenarios.

7.5.1 Scenario 1: NRF Migration to a New Cluster

This section describes how to migrate NRF from an existing cluster to a different cluster.

Following are the assumptions:

  1. NRF in the existing cluster is healthy and running.
  2. Install a new Kubernetes cluster by performing the Cloud Native Environment (CNE) installation procedure as described in Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.
  3. Install cnDBTier as described in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  4. Take NRF configuration backup from a healthy cluster using Backup of NRF Configuration Data section.
  5. Install NRF as described in Installing NRF section.
  6. Restore the NRF configuration from the existing cluster to the new cluster as described in Restore NRF Configuration Data section.

7.5.2 Scenario 2: Deployment Failure (NRF Corruption)

This section describes the steps to recover NRF when deployment is corrupted and NRF is not responding to traffic, but cnDBTier is healthy.

Restore NRF as described in Restoring NRF section.

7.5.3 Scenario 3: NRF cnDBTier Corruption

This section describes how to recover cnDBTier from the corrupted database.

When the database corrupts in one site, the database on all other sites may also corrupt due to data replication. It depends on the replication status after the corruption has occurred. If the data replication is broken due to database corruption, then cnDBTier fails in either single or multiple sites but not on all sites. If the data replication is successful, then database corruption replicates to all the cnDBTier sites and cnDBTier fails in all sites.

To recover cnDBTier when cnDBTier corrupts in single, multiple, or all sites, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

After the cnDBTier is recovered, the NRF users must be recreated using the following commands:
CREATE USER IF NOT EXISTS 'nrfPrivilegedUsr'@'%' IDENTIFIED WITH mysql_native_password BY 'nrfPrivilegedPasswd';

CREATE USER IF NOT EXISTS 'nrfApplicationUsr'@'%' IDENTIFIED WITH mysql_native_password BY 'nrfApplicationPasswd';

If NRF is not functioning properly even after the above cnDBTier fault recovery procedure, perform NRF recovery procedure by following Restoring NRF section.

7.5.4 Scenario 4: Site Failure

This section describes how to perform fault recovery when either one, many, or all of the sites have software failure.

7.5.4.1 Single or Multiple Site Failure

A scenario where you have cnDBTier and NRF installed on multiple sites with automatic data replication and backup enabled. It is observed that one or more sites, not all of them, have failed and there is a requirement to perform fault recovery.

Following are the assumptions:
  • One of the cnDBTier is in healthy state.
  • All the prerequisites mentioned in the Prerequisites are met.

To recover the failed sites:

  1. (Optional) Install Oracle Communications Cloud Native Environment, in case the complete site is down. For information about installing CNE, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.
  2. (Optional) Install cnDBTier, in case replication is down or cnDBTier pods are not up and running. For information about installing cnDBTier, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  3. Perform cnDBTier fault recovery procedure:
    1. Perform cnDBTier fault recovery procedure to take backup from older healthy site by following the "Create On-demand Database Backup" procedure in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
    2. Restore the database to new site by following the "Restore Database with Backup" procedure in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
    3. Recreate database users and grant permissions by following the Configuring Database, Creating Users, and Granting Permissions procedure.
  4. If NRF is not functioning properly even after the above cnDBTier fault recovery procedure, perform NRF recovery procedure by following Restoring NRF section.
7.5.4.2 Complete Site Outage

A scenario where you have cnDBTier and NRF installed on multiple sites with automatic data replication and backup enabled. It is observed that all the sites have failed and there is a requirement to perform fault recovery.

To recover all the failed sites:

  1. Uninstall NRF. Run the following command:
    helm uninstall <helm-release> -n <namespace> --no-hooks
  2. (Optional) Install Oracle Communications Cloud Native Core, Cloud Native Environment. For information about installing CNE, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.
  3. (Optional) Install cnDBTier. For information about installing cnDBTier, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  4. Perform cnDBTier fault recovery procedure. Use auto-data backup file for restore procedure. For more information about cnDBTier restore, see the "Restore Database with Backup" procedure in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

    Note:

    The auto-data backup file is one that built from scheduled automatic backup. cnDBTier Backup Manager Service ensures auto-data backup as per the predefined configuration. For more information about cnDBTier Backup Manager Service, see Oracle Communications Cloud Native Core, cnDBTier User Guide.
  5. Recreate database users and grant permissions by following the Configuring Database, Creating Users, and Granting Permissions procedure.
  6. Install NRF by using Restoring NRF section.

Caution:

There might be a data loss in this scenario. Since the backup used to restore the database is not the latest, and there may be updates to the data between the time at which the backup was taken and the site failed, the data updated during this period will be lost during the restore. These updates have to be applied manually after recovering the site.

7.5.5 Post Fault Recovery

This section provides the procedure to recover the NRF traffic after fault recovery. If any of the site was isolated during the fault recovery procedure, perform the steps as mentioned in Recovery of NRF.

7.5.6 Graceful Shutdown of NRF Deployment

This section provides the procedure to gracefully shutdown and recover NRF deployment.

NRF supports isolating an NRF from the current network at a particular site. This isolation helps to perform any maintenance activities or recovery procedures as required without uninstalling the NRF at the particular site. For more information regarding the procedure and information on graceful shutdown, refer feature, see "Controlled Shutdown of NRF" in Oracle Communications Cloud Native Core, Network Repository Function User Guide.

In any case, if the graceful shutdown procedure using the controlled shutdown feature fails or cannot perform controlled shutdown, then perform the procedure specified in Manual Shutdown and Recovery of NRF. For information about NRF behavior after controlled shutdown feature, see NRF Behavior Post Fault Recovery.

7.6 Restoring NRF

To restore NRF, perform the following steps:

  1. Perform a database backup, if not available already. The database backup can be taken from a healthy georedundant mated site or from a latest scheduled automatic backup.
  2. Take a backup of the ocnrf-custom_values.yaml file that was used for installing NRF.
  3. Uninstall NRF (if applicable). Run the following command:
    helm uninstall <helm-release> -n <namespace> --no-hooks
  4. Restore the database using the backup data taken in step-1. For more information about the restore, see "Restore Database with Backup" procedure in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide
  5. Set global.appValidate.faultRecoveryMode parameter to true before installing NRF. For more information about the parameter, see "Audit NRF Database Tables" in Oracle Communications Cloud Native Core, Network Repository Function User Guide.
  6. Install NRF using the Helm charts and the ocnrf-custom_values.yaml modified in step-5. For more information about installing NRF, see the Installing NRF section.
  7. To verify whether NRF installation is complete, see Postinstallation Tasks.
  8. Revert the changes done in step-5 and save the custom values file for future use.

Note:

In case, if manual restoration of configuration data is required, use Backup and Restore of NRF Configuration Data section.

7.7 Backup and Restore of NRF Configuration Data

This section describes the procedure to perform backup and restore of Configuration data.

7.7.1 Backup of NRF Configuration Data

This section describes the procedure to perform backup of NRF Configuration data.

To perform backup of NRF Configuration data, use the following steps:

  1. Take the backup of NRF configuration data by sending a request to the NRF's configuration service using the HTTP GET method for the APIs mentioned in "NRF Configurations" table in Configuration APIs section.

    An example output of NRF generalOptions configuration.

    URI: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X GET > NRF1_<Resource Name(name of configuration)>_backup.json

    Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf-configuration/v1/generalOptions -X GET > NRF1_General_Options_backup.json

    Sample output of generalOptions:

    
{
    "nrfPlmnList": [{
        "mcc": "310",
        "mnc": "14"
    }],
    "enableF3": true,
    "enableF5": true,
    "maximumHopCount": 3,
    "defaultLoad": 5,
    "defaultPriority": 100,
    "defaultPriorityAssignment": false,
    "defaultLoadAssignment": false,
    "add3gppSBICorrelationInfoHeader": "ENABLED",
    "ocnrfUserAgentHeader": "",
    "ocnrfHost": "ocnrf-ingressgateway.ocnrf",
    "ocnrfPort": 80,
    "ocnrfScheme": "http"
}
  2. Take the backup of all the Common Services configuration data by sending a request to the existing NRF's configuration service using the GET HTTP method. Save this into a file.
    1. Perform a GET operation to the NRF configuration service to get the Egress Gateway configurations APIs as in "Egress Gateway Configurations" table in Configuration APIs section.

      An example output of Egress Gateway peerconfiguration:

      URI: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X GET

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/egw/peerconfiguration -X GET > NRF1_egw_peerconfiguration.json

      Sample output of Egress Gateway peerconfiguration:

      
[
   {
      "id":"peer1",
      "host":"10.75.225.67",
      "port":"31235",
      "apiPrefix":"/",
      "healthApiPath":"/health/v1"
   },
   {
      "id":"peer2",
      "host":"10.75.214.18",
      "port":"31236",
      "apiPrefix":"/",
      "healthApiPath":"/health/v2"
   },
   {
      "id":"peer3",
      "host":"10.75.214.18",
      "port":"30075",
      "apiPrefix":"/",
      "healthApiPath":"/health/v3"
   },
   {
      "id":"peer4",
      "virtualHost":"abc.test.com",
      "apiPrefix":"/",
      "healthApiPath":"/health/v4"
   }
]
    2. Perform a GET operation to the NRF configuration service to get the Ingress Gateway configuration APIs as in "Ingress Gateway Configurations" table in Configuration APIs section.

      An example output of Ingress Gateway ocpolicymapping configuration.

      URI: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X GET

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nfcommoncomponent/v1/igw/ocpolicymapping -X GET > NRF1_igw_ocpolicymapping.json

      Sample output of Ingress Gateway ocpolicymapping:

      {
   "enabled": true,
   "mappings": [
   {
     "svcName": "sm.pcf.com",
     "policyName": "OCDP1"
   },
   {
     "svcName": "cm.pcf.com",
     "policyName": "OCDP2"
   },
   {
     "svcName": "localhost",
     "policyName": "OCDP3"
   }],
   "samplingPeriod": 200
}
    3. Perform a GET operation to the NRF configuration service to get the Alternate Route configuration APIs as in "Alternate Route Configurations" table in Configuration APIs section.

      An example output of Alternate Route Logging configuration:

      URI: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X GET

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/altRoute/logging -X GET > NRF1_altRoute_logging.json

      Sample output of Alternate Route Logging:

      
{
 "appLogLevel": "WARN",
 "packageLogLevel": [ {
 "packageName": "root",
 "logLevelForPackage": "INFO"
 }]
}
    4. Perform a GET operation to the NRF configuration service to get the Perf-Info configuration APIs as in "Perf-Info Configurations" table in Configuration APIs section.

      An example output of perf-info Logging configuration:

      URI: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X GET

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/perfinfo/logging -X GET > NRF1_perfinfo_logging.json

      Sample output of PerfInfo Logging:

      {
 "appLogLevel": "WARN",
 "packageLogLevel": [ {
 "packageName": "root",
 "logLevelForPackage": "INFO"
 }]
}
    5. Perform a GET operation to the NRF configuration service to get the AppInfo configuration APIs as in "App Info Configurations" table in Configuration APIs section.

      An example output of AppInfo Logging configuration:

      URI: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X GET

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/appinfo/logging -X GET > NRF1_appinfo_logging.json

      Sample output of AppInfo Logging:

      
{
 "appLogLevel": "WARN",
 "packageLogLevel": [ {
 "packageName": "root",
 "logLevelForPackage": "INFO"
 }]
}

7.7.2 Restore NRF Configuration Data

This section describes the procedure to restore the configuration data.

To restore the configuration data onto a different site, use the following steps:

  1. To restore NRF configuration data, send PUT request to NRF configuration service along with the json file saved during backup to the APIs mentioned in "NRF Configurations" table in Configuration APIs section.

    An example output of NRF generalOptions configuration:

    Url: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X PUT -d@<json file of corresponding configuration resource> -H 'Content-Type:application/json'

    Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf-configuration/v1/generalOptions -X PUT -H 'Content-Type:application/json' -d@NRF1_General_Options_backup.json

    Sample output of generalOptions:

    {
    "nrfPlmnList": [{
        "mcc": "310",
        "mnc": "14"
    }],
    "enableF3": true,
    "enableF5": true,
    "maximumHopCount": 3,
    "defaultLoad": 5,
    "defaultPriority": 100,
    "defaultPriorityAssignment": false,
    "defaultLoadAssignment": false,
    "add3gppSBICorrelationInfoHeader": "ENABLED",
    "ocnrfUserAgentHeader": "",
    "ocnrfHost": "ocnrf-ingressgateway.ocnrf",
    "ocnrfPort": 80,
    "ocnrfScheme": "http"
}
  2. To restore all the common services configuration data, send a request to NRF configuration service using PUT HTTP method.
    1. Configure all the Egress Gateway configuration APIs as in "Egress Gateway Configurations" table in Configuration APIs section.

      An example output of Egress Gateway peerconfiguration:

      Url : curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X PUT -d@<json file of corresponding configuration resource> -H 'Content-Type:application/json'

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/egw/peerconfiguration -X PUT -H 'Content-Type:application/json' -d@NRF1_egw_peerconfiguration.json

      Sample output of Egress Gateway peerconfiguration:-

      [
   {
      "id":"peer1",
      "host":"10.75.225.67",
      "port":"31235",
      "apiPrefix":"/",
      "healthApiPath":"/health/v1"
   },
   {
      "id":"peer2",
      "host":"10.75.214.18",
      "port":"31236",
      "apiPrefix":"/",
      "healthApiPath":"/health/v2"
   },
   {
      "id":"peer3",
      "host":"10.75.214.18",
      "port":"30075",
      "apiPrefix":"/",
      "healthApiPath":"/health/v3"
   },
   {
      "id":"peer4",
      "virtualHost":"abc.test.com",
      "apiPrefix":"/",
      "healthApiPath":"/health/v4"
   }
]
    2. Configure all the Ingress Gateway configuration APIs as in "Ingress Gateway Configurations" table in Configuration APIs section.

      An example output of Ingress Gateway ocpolicymapping configuration:

      Url:curl http://<NRF configuration service name>:< NRF configuration service port>/<path> -X PUT -d@<json file of corresponding configuration resource> -H 'Content-Type:application/json'

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/igw/ocpolicymapping -X PUT -H 'Content-Type:application/json' -d@NRF1_igw_ocpolicymapping.json

      Sample output of Ingress Gateway ocpolicymapping:

      {
   "enabled": true,
   "mappings": [
   {
     "svcName": "sm.pcf.com",
     "policyName": "OCDP1"
   },
   {
     "svcName": "cm.pcf.com",
     "policyName": "OCDP2"
   },
   {
     "svcName": "localhost",
     "policyName": "OCDP3"
   }],
   "samplingPeriod": 200
}
    3. Configure all the Alternate Route configuration APIs as in "Alternate Route Configurations" table in Configuration APIs section.

      An example output of Alternate Route configuration:

      Url: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X PUT -d@<json file of corresponding configuration resource> -H 'Content-Type:application/json'

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/altRoute/logging -X PUT -H 'Content-Type:application/json' -d@NRF1_altRoute_logging.json

      Sample output of Alternate Route Logging:

      {
 "appLogLevel": "WARN",
 "packageLogLevel": [ {
 "packageName": "root",
 "logLevelForPackage": "INFO"
 }]
}
    4. Configure all the Perfinfo configuration APIs as in "Perf-Info Configurations" table in Configuration APIs section.

      An example output of Perfinfo configuration:

      Url: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X PUT -d@<json file of corresponding configuration resource> -H 'Content-Type:application/json'

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/perfinfo/logging -X PUT -H 'Content-Type:application/json' -d@NRF1_perfinfo_logging.json

      Sample output of PerfInfo Logging:

      {
 "appLogLevel": "WARN",
 "packageLogLevel": [ {
 "packageName": "root",
 "logLevelForPackage": "INFO"
 }]
}
    5. Configure all the Appinfo configuration APIs as in "App Info Configurations" table in Configuration APIs section.

      An example output of Appinfo configuration.

      Url: curl http://<NRF configuration service name>:<NRF configuration service port>/<path> -X PUT -d@<json file of corresponding configuration resource> -H 'Content-Type:application/json'

      Sample command: curl http://ocnrf-nrfconfiguration:8080/nrf/nf-common-component/v1/appinfo/logging -X PUT -H 'Content-Type:application/json' -d@NRF1_appinfo_logging.json

      Sample output of AppInfo Logging:

      {
 "appLogLevel": "WARN",
 "packageLogLevel": [ {
 "packageName": "root",
 "logLevelForPackage": "INFO"
 }]
}
  3. To verify if all the configuration data is successfully restored in the new site, send a GET request to NRF Configuration service using the APIs mentioned in "NRF Configurations", "Egress Gateway Configurations","Ingress Gateway Configurations", "Alternate Route Configurations", "Perf-Info Configurations", and "App Info Configurations" tables in Configuration APIs section and compare the outputs with the corresponding backed up data.

7.7.3 Configuration APIs

This section lists the configuration APIs used for backup and restore of NRF configuration data.

Table 7-2 NRF Configurations

S No. Resource Name Path
1. General Options nrf-configuration/v1/generalOptions.
2. NfScreening Options nrf-configuration/v1/nfScreeningOptions
3. NfManagement Options nrf-configuration/v1/nfManagementOptions
4. NfDiscovery Options nrf-configuration/v1/nfDiscoveryOptions
5. NfAccessToken Options nrf-configuration/v1/nfAccessTokenOptions
6. Forwarding Options nrf-configuration/v1/forwardingOptions
7. SLF Options nrf-configuration/v1/slfOptions
8. GeoRedundancy Options nrf-configuration/v1/geoRedundancyOptions
9. NfAuthentication Options nrf-configuration/v1/nfAuthenticationOptions
10. DnsNAPTRUpdate Options nrf-configuration/v1/dnsNAPTRUpdateOptions
11. Roaming Options nrf-configuration/v1/roamingOptions
12. Subscription PodProtection Options nrf-configuration/v1/nfSubscription/podProtectionOptions
13. NfScreening Rules nrf-configuration/v1/screening-rules/{nfScreeningRulesListType}
14. NfAccessToken Logging nrf-configuration/v1/nfAccessToken/logging
15. NfDiscovery Logging nrf-configuration/v1/nfDiscovery/logging
16. NfRegistration Logging nrf-configuration/v1/nfRegistration/logging
17. NfSubscription Logging nrf-configuration/v1/nfSubscription/logging
18. NrfAuditor Logging nrf-configuration/v1/nrfAuditor/logging
19. NrfConfiguration Logging nrf-configuration/v1/nrfConfiguration/logging
20. NrfArtisan Logging nrf-configuration/v1/nrfArtisan/logging

Table 7-3 Egress Gateway Configurations

S.No Resource Name Path
1. Egress Gateway - PeerMonitoringConfiguration {apiRoot}/nrf/nfcommoncomponent/v1/egw/peermonitoringconfiguration
2. Egress Gateway - PeerConfiguration {apiRoot}/nrf/nfcommoncomponent/v1/egw/peerconfiguration
3. Egress Gateway -PeerSetConfiguration {apiRoot}/nrf/nfcommoncomponent/v1/egw/peersetconfiguration
4. Egress Gateway -RoutesConfiguration {apiRoot}/nrf/nfcommoncomponent/v1/egw/routesconfiguration
5. Egress Gateway -SbiRoutingErrorCriteriaSets {apiRoot}/nrf/nf-common-component/v1/egw/sbiroutingerrorcriteriasets
6. Egress Gateway -SbiRoutingErrorActionSets {apiRoot}/nrf/nf-common-component/v1/egw/sbiroutingerroractionsets
7. Egress Gateway - Logging {apiRoot}/nrf/nf-common-component/v1/egw/logging

Table 7-4 Ingress Gateway Configurations

S.No Resource Name Path
1. Ingress Gateway - Policy Mapping Configuration {apiRoot}/nrf/nf-common-component/v1/igw/ocpolicymapping
2. Ingress Gateway - Discard Policy Configuration {apiRoot}/nrf/nf-common-component/v1/igw/ocdiscardpolicies
3. Ingress Gateway - Error Code Profile Configuration {apiRoot}/nrf/nf-common-component/v1/igw/errorcodeprofiles
4. Ingress Gateway - Error Code Series Configuration {apiRoot}/nrf/nf-common-component/v1/igw/errorcodeserieslist
5. Ingress Gateway - Routes Configuration {apiRoot}/nrf/nf-common-component/v1/igw/routesconfiguration
6. Ingress Gateway - CCA Header {apiRoot}/nrf/nf-common-component/v1/igw/ccaheader
7. Ingress Gateway - Controlled Shutdown Errormapping {apiRoot}/nrf/nf-common-component/v1/igw/controlledshutdownerrormapping
8. Ingress Gateway - Logging {apiRoot}/nrf/nf-common-component/v1/igw/logging
9. Ingress Gateway Pod Protection {apiRoot}/nf-common-component/v1/igw/podprotection

Table 7-5 Alternate Route Configurations

S.No Resource Name Path
1. Alternate Route - Logging {apiRoot}/nrf/nf-common-component/v1/altRoute/logging

Table 7-6 Perf-Info Configurations

S.No Resource Name Path
1. Perf Info - Overload Threshold {apiRoot}/nrf/nf-common-component/v1/perfinfo/overloadLevelThreshold
2. Perf Info - Logging {apiRoot}/nrf/nf-common-component/v1/perfinfo/logging

Table 7-7 App Info Configurations

S.No Resource Name Path
1. App Info - Logging {apiRoot}/nrf/nf-common-component/v1/appinfo/logging