--- title: "Ribbon SBC" slug: "ribbon-sbc" updated: 2026-05-07T19:35:32Z published: 2026-05-07T19:35:32Z canonical: "support.nectarcorp.com/ribbon-sbc" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.nectarcorp.com/llms.txt > Use this file to discover all available pages before exploring further. # Ribbon SBC ## Introduction This document describes the Ribbon Scripted Vendor Knowledge Module (Ribbon SVKM), a declarative monitoring and alerting solution for Ribbon Session Border Controllers (SBCs). Ribbon SVKM enables automated discovery, monitoring, and alerting using REST-based data collection and the ScriptedVKM framework. It is designed to scale across multi-cluster environments while maintaining consistency and operational simplicity. --- ## Architectural Overview Ribbon SVKM follows a layered architecture that ensures repeatability, scalability, and operational safety. ### Architecture Layers - **Collection Layer** Retrieves operational data from SBC APIs - **Alignment Layer** Creates folders, agents, and pollers dynamically - **Task Layer** Executes scheduled jobs to populate poller values - **Threshold Layer** Evaluates values and generates alarms --- ### Data Flow ``` Collection (Parent Agent) ↓ Alignment (Creates pollers on device agents) ↓ Task Execution (Runs on device agents using parent credentials) ↓ Poller values updated ↓ Threshold evaluation → Alarms generated ``` --- ### Operational Capabilities Ribbon SVKM provides: - Automated discovery of SBC components (nodes, zones, interfaces, DSPs, licenses) - Dynamic poller creation based on discovered inventory - Scheduled task execution with staggered intervals - Threshold-based alerting across all monitored components - Efficient API utilization using bulk data collection --- ### Operational Safety and Maintainability - Fully declarative architecture - No code changes required for extensions - Centralized configuration via ScriptedVKM - Secure credential storage at the parent agent level - Built-in logging via `scriptedvkm.log` The solution separates: - **Cluster-level configuration (parent agent)** - **Node-level monitoring (device agents)** --- ## Installation Instructions ### Prerequisites - ScriptedVKM module enabled on RIG - Ribbon SBC API access (FQDN preferred) - Valid credentials - Network connectivity from RIG to SBC NoteYou must collect the IP & credentials from the customer before proceeding. View/Monitor level credentials are preferred. --- ### Importing SVKM 1. Navigate to: **Configure → Knowledge Scripts** 2. Right-click and select **Import** 3. Select the Ribbon SVKM package 4. Wait for import to complete ![](https://cdn.document360.io/f8330b7a-360f-4ca0-b0ac-2664b7c04c49/Images/Documentation/image-1778181841047.png?sv=2026-02-06&spr=https&st=2026-11-08T16%3A36%3A23Z&se=2026-11-08T17%3A36%3A23Z&sr=c&sp=r&sig=gxYStGOQ4aezO24BtoWPwoA%2Fbrn46V1OP9ExxlwDcxM%3D) NoteIf you don't have access to the Ribbon SBC script, please contact support@nectarcorp.com --- ## Deployment Procedure Follow the steps below to deploy Ribbon SBC monitoring using ScriptedVKM. --- ### Step 1: Configure Agent Navigate to your **Nectar RIG** and create an agent with the following parameters: ![](https://cdn.document360.io/f8330b7a-360f-4ca0-b0ac-2664b7c04c49/Images/Documentation/image-1778181353884.png?sv=2026-02-06&spr=https&st=2026-11-08T16%3A36%3A23Z&se=2026-11-08T17%3A36%3A23Z&sr=c&sp=r&sig=gxYStGOQ4aezO24BtoWPwoA%2Fbrn46V1OP9ExxlwDcxM%3D) --- ### Step 2: Edit Agent Click **Edit** on the previously created agent, and add the following properties: - Login - Password - URL ![](https://cdn.document360.io/f8330b7a-360f-4ca0-b0ac-2664b7c04c49/Images/Documentation/image-1778181594313.png?sv=2026-02-06&spr=https&st=2026-11-08T16%3A36%3A23Z&se=2026-11-08T17%3A36%3A23Z&sr=c&sp=r&sig=gxYStGOQ4aezO24BtoWPwoA%2Fbrn46V1OP9ExxlwDcxM%3D) --- ### Step 3: Associate Knowledge Scripts Click **Associate Knowledge Scripts** on the previously created agent: ![](https://cdn.document360.io/f8330b7a-360f-4ca0-b0ac-2664b7c04c49/Images/Documentation/image-1778181678819.png?sv=2026-02-06&spr=https&st=2026-11-08T16%3A36%3A23Z&se=2026-11-08T17%3A36%3A23Z&sr=c&sp=r&sig=gxYStGOQ4aezO24BtoWPwoA%2Fbrn46V1OP9ExxlwDcxM%3D) Associate the Ribbon SVKM script by selecting it and clicking add: **![](https://cdn.document360.io/f8330b7a-360f-4ca0-b0ac-2664b7c04c49/Images/Documentation/image-1778182526489.png?sv=2026-02-06&spr=https&st=2026-11-08T16%3A36%3A23Z&se=2026-11-08T17%3A36%3A23Z&sr=c&sp=r&sig=gxYStGOQ4aezO24BtoWPwoA%2Fbrn46V1OP9ExxlwDcxM%3D)**Click done. --- ### Step 4: Verify Data After association, the script will automatically execute. After execution, please validate that inventory data is collected successfully. NoteData may take **3-10 minutes** to populate --- ## Folder Structure ``` RibbonSBC └── ├── ├──       └── _licenseInfo ``` Optional zone-based grouping: ``` RibbonSBC └──       └── ``` --- ## Agent Structure | Agent | Purpose | | --- | --- | | `<SBC_CLUSTER_NAME>` | Parent agent (credentials only) | | `<SBC_NODE_A>` | Device node A (pollers live here) | | `<SBC_NODE_B>` | Device node B (pollers live here) | | `<SBC_CLUSTER_NAME>_licenseInfo` | License monitoring | --- ## Poller Placement Rules - Pollers are created only on node agents - Parent agent is used only for credentials - Shared pollers (license, interfaces) may exist at cluster level - Naming must be consistent across alignment and tasks --- ## Poller Naming Conventions Poller names are dynamically generated and must remain consistent across alignment, tasks, and thresholds. ### Naming Format ``` + + + ``` ### Examples by Type | Type | Format | | --- | --- | | High Availability | ceName + HA Port + status | | Policy Servers | Cluster + Policy Server + IP + status | | Hard Disk | ceName + Disk Name + status | | Interface | ceName + Interface Group + Interface + IP + status | | CPU | ceName + CPU Number + utilization | | Power | ceName + Power location + status | | DSP | ceName + DSP Name + status | | License | License Name + percent used | > Naming must match exactly between alignment and task logic or data will not populate correctly. --- ## Running Script (Onboarding) 1. Right-click the parent agent 2. Select **Associate Knowledge Script** 3. Add the Ribbon onboarding script 4. Execute collections ### Notes - Large environments may create thousands of pollers - Execution time depends on SBC size - **Data may take 3–10 minutes to populate** --- ## Onboarding Validation ### Folder - RibbonSBC exists - Cluster folder created ### Agents - Node A and Node B created - License agent present ### Pollers - Created only on node agents - Naming format is correct ### Tasks - Running on node agents - Using parent credentials ### Alerts - Trigger correctly - Clear when conditions normalize --- ## Core Components ### Agent Creation Creates cluster and node agents dynamically based on discovered data. --- ### Collections Retrieves inventory and operational data via REST APIs. Examples: - Trunk groups - CPU utilization - DSP resources - Power supplies - Interfaces - Policy servers - License usage --- ### Alignment - Iterates through discovered objects - Creates pollers - Applies naming conventions --- ### Task Execution | Parameter | Behavior | | --- | --- | | Execution Location | Node agents | | Credentials | Parent agent | | Frequency | 3–10 minutes | --- ## Severity Mapping Across Modules The following table defines how metrics are evaluated and mapped to severity levels across Ribbon SBC components. | Module | Metric | Condition | Value | Severity | Description | | --- | --- | --- | --- | --- | --- | | **HA Status** | HA Port | negotiatedSpeed ≠ unknown AND oosReason = na | 1 | Normal | Link operational | | | | negotiatedSpeed = unknown OR oosReason ≠ na | 5 | Critical | Link failure | | **Interface Status** | Interface | state = enabled/inService | 1 | Normal | Interface active | | | | state ≠ enabled OR out of service | 5 | Critical | Interface down | | **CPU** | Utilization | ≤ 80% | 1 | Normal | Acceptable usage | | | | > 80% and ≤ 95% | 3 | Warning | Elevated usage | | | | > 95% | 5 | Critical | CPU saturation | | **Power Supply** | Power/Voltage | No faults present | 1 | Normal | Power supply healthy | | | | powerFault OR voltageFault present | 5 | Critical | Hardware fault detected | | **DSP Resources** | DSP Status | present AND enabled | 1 | Normal | DSP operational | | | | missing OR disabled | 5 | Critical | DSP unavailable | | **License Usage** | Capacity | ≤ 80% | 1 | Normal | Capacity available | | | | > 80% and ≤ 95% | 3 | Warning | Approaching limit | | | | > 95% | 5 | Critical | Capacity exceeded | --- ## Monitoring Logic ### High Availability (HA) - If negotiated speed exists AND no out-of-service reason → Normal - Otherwise → Critical ### Policy Server Monitoring - Active/standby servers take priority - If negotiated version exists → Normal - If missing → Major ### Trunk Group Monitoring - Calculates total vs used capacity - Uses percentage for alerting --- ## Troubleshooting ### Logging - File: `scriptedvkm.log` - Created automatically - Recommended during onboarding --- ### Common Issues | Issue | Cause | Resolution | | --- | --- | --- | | No data | Credential issue | Verify parent agent properties | | No connection | Invalid URL | Validate FQDN | | No alarms | Threshold mismatch | Verify task outputs | --- ## Key Design Rules - Pollers must be created on node agents - Parent agent is credential-only - Naming must match exactly across modules - Threshold values must align with task outputs - Folder structure must remain consistent --- ## Summary Ribbon SVKM provides: - Scalable monitoring across SBC clusters - Efficient API-driven data collection - Automated poller creation and management - Standardized alerting across infrastructure