Core Function Analysis - Diagramatic Representations

1. Overview

The Enterprise (ENT) AAA system focuses on core authentication, IP assignment, and subscriber provisioning using RADIUS. This section describes the essential functional components: Router-Based Authentication, Framed Address Handling, RADIUS Processing, and Provisioning Flow.

2. RADIUS Process

The system uses RADIUS protocol for authentication and accounting between the router (NAS) and AAA server.

2.1. Authentication Flow

Diagram

2.2. Accounting Flow

Diagram

2.3. Key Attributes

  • User-Name

  • User-Password

  • NAS-IP-Address

  • Framed-IP-Address

  • Session-Timeout

3. Router-Based Authentication

3.1. Flow Diagram

Diagram

3.2. Decision Logic

Diagram
Attribute Description

Framed-IP-Address

Assigns user IP

VRF-Name

Routing context

Session-Timeout

Session duration

3.3. Failure Scenarios

  • Invalid credentials → Reject

  • User not found → Reject

  • Account inactive → Reject

  • AAA timeout → Retry/Fail

4. Framed Address Handling

4.1. Flow Diagram

Diagram

4.2. Decision Logic

  • Request IP takes priority

  • DB IP used if request absent

  • External IP used as fallback

  • Reject if none available

4.3. Attribute-Level Details

Attribute Description

Framed-IP-Address

Assigned IP

Framed-Pool

Pool reference

Framed-IP-Netmask

Subnet

4.4. Failure Scenarios

  • No IP available → Reject

  • Pool exhausted → Reject

  • Duplicate IP → Conflict

5. Provisioning Flow

5.1. User Creation

Diagram

The user creation process begins when an administrator initiates the operation through the user interface (UI). The UI forwards the request to the backend API, which is responsible for handling business logic and processing.

At the API level, the input data is validated to ensure all required fields are correctly provided and meet system constraints. This step helps prevent invalid or inconsistent data from being stored in the system.

Once validation is successful, the processed data is stored in the database (DB). After storing the user information, the system assigns an appropriate policy or IP pool to the user based on predefined configurations.

Following policy assignment, the user account is activated by updating its status to ACTIVE. Finally, the process completes successfully, indicating that the user has been created, configured, and is ready for use within the system.

5.2. User Update

Diagram

The user update process begins when an administrator initiates an update through the user interface (UI). The UI sends the update request to the backend API, which handles the processing logic.

At the API level, the system first retrieves the existing user details from the database to ensure that updates are applied to the correct record. Once the user data is fetched, the administrator’s requested changes are applied by modifying the relevant attributes such as user credentials, policies, or assigned resources.

After updating the necessary fields, the modified data is stored back in the database. These changes are not immediately enforced on active sessions; instead, they take effect during the user’s next session or reconnection.

This ensures system stability by avoiding disruption to currently active sessions while still applying updated configurations moving forward.

5.3. User Deletion

Diagram

The user deletion process starts when an administrator initiates a deletion request through the user interface (UI). The UI forwards this request to the backend API, which is responsible for handling the operation.

At the API level, the system interacts with the database to locate and remove the specified user record. Once the user is deleted from the database, the system ensures that any active sessions associated with that user are immediately terminated.

Terminating active sessions is a critical step to enforce the deletion in real time, preventing the user from continuing to access the system with previously established connections.

This process ensures that the user is completely removed from the system and no further access is permitted.

5.4. View Subscriber

Diagram

The subscriber view process begins when a request is initiated to retrieve user details. This request is sent to the backend API, which acts as the central processing layer.

The API communicates with the database to fetch the relevant subscriber information based on the request parameters, such as user ID or username. The database returns the stored user details, including attributes like account status, assigned policies, and other related information.

Once the data is retrieved, the API formats the response and sends it back to the requester. This enables administrators or systems to view accurate and up-to-date subscriber information for monitoring, management, or troubleshooting purposes.

5.5. Key Attributes

  • Username

  • Password

  • Framed- IP

  • Group

  • Status

5.6. Failure Scenarios

  • Duplicate user → Reject

  • Invalid input → Error

  • DB failure → Operation failed

6. Session Lifecycle

The Enterprise AAA system implicitly follows a session lifecycle through RADIUS authentication and accounting processes.

6.1. Lifecycle Stages

  1. Authentication → Access-Request / Access-Accept

  2. Session Start → Accounting-Start

  3. Active Session → Interim Update

  4. Session Termination → Accounting-Stop

6.2. Example Flow

Diagram

6.3. Example SQL Representation

Session data can be stored and tracked using a table structure like below:

CREATE TABLE user_sessions (
    session_id VARCHAR(64) PRIMARY KEY,
    username VARCHAR(64),
    framed_ip VARCHAR(45),
    start_time TIMESTAMP,
    last_update TIMESTAMP,
    stop_time TIMESTAMP,
    input_octets BIGINT,
    output_octets BIGINT,
    status VARCHAR(20)
);

-- Insert on Accounting-Start
INSERT INTO user_sessions (session_id, username, framed_ip, start_time, status)
VALUES ('ABC123', 'user1', '10.0.0.10', NOW(), 'ACTIVE');

-- Update on Interim-Update
UPDATE user_sessions
SET last_update = NOW(),
    input_octets = input_octets + 5000,
    output_octets = output_octets + 3000
WHERE session_id = 'ABC123';

-- Update on Accounting-Stop
UPDATE user_sessions
SET stop_time = NOW(),
    status = 'TERMINATED'
WHERE session_id = 'ABC123';

6.4. Purpose

  • Tracks active user sessions in real-time

  • Maintains usage data for billing and monitoring

  • Ensures session continuity even if stop packets are delayed