| Subscriber | Access | Gateway | IP | Status |
|---|---|---|---|---|
| FTTH-44120 | PPPoE | bng-01 | 100.64.18.23 | Authorised |
| FTTH-51877 | PPPoE | bng-02 | 100.64.22.140 | Authorised |
| ENT-2209 | IPoE | bng-01 | 203.0.113.14 | Authorised |
| WIFI-GUEST-88 | Hotspot | ap-lobby | 10.20.4.77 | Captive portal |
| FTTH-39002 | PPPoE | bng-02 | – | Rejected: expired plan |
4 authorised · 1 rejectedIP logs retained · Trace
Overview
i2i AAA is a RADIUS AAA server for ISPs and operators. It authenticates each subscriber, authorises what the session may use and records the accounting stream. The same node can also disconnect or re-shape a live session on request, so the network follows the plan the subscriber has bought.
Behaviour is set in a web console rather than in code. You define workflows made of steps, route each request to a workflow by source or condition, attach policies written in a compiled expression language and keep subscriber data in the database you already run. Nodes pull their configuration from a central control service and keep the last good copy on disk. It works with i2i BNG and i2i Hotspot as RADIUS clients and writes usage into the i2i billing schema, so accounting feeds invoicing directly.
At a glance
- Access decided by plan, status and policy
- Live disconnect and speed change from the console
- Enterprise Wi-Fi with a managed certificate store
- Accounting written straight to billing
What is a RADIUS AAA server?
AAA stands for authentication, authorisation and accounting. RADIUS, defined in RFC 2865 and RFC 2866, is the protocol that network access equipment uses to ask a central server the three questions. A broadband gateway, a Wi-Fi controller or an access point sends an Access-Request. The server checks the credentials, decides what the user may do and replies with attributes such as an address, a speed or a session limit.
Once the session starts, the access device sends accounting messages. Start, Interim and Stop records tell the server how long the session ran and how much data moved. Operators use those records for billing, fair-use limits and audit. RFC 5176 adds dynamic authorisation, which lets the server send a Disconnect or a Change-of-Authorisation to a session that is already running.
A RADIUS server therefore sits in the path of every login. It holds the rules, reads subscriber data from a database or directory and produces the usage records that finance depends on. Enterprise and public Wi-Fi add the EAP family of methods, which carry certificate or tunnelled credentials inside RADIUS.
Capabilities
What i2i AAA does
Authentication
- PAP and CHAP with constant-time comparison
- EAP-TLS with client certificates checked against a trust store
- EAP-TTLS and EAP-PEAP over a server TLS tunnel
- MS-CHAPv2 in the RADIUS wire layer
Authorisation and policy
- Workflows built from steps such as Identify and Authorise
- Policies with AND, OR, NOT, IN, REGEX and BETWEEN
- Requests routed by peer, peer group or condition
- Vendor attributes by number or name with a dictionary
Bandwidth and quality of service
- QoS profiles and bandwidth policy per plan
- Time-of-day and schedule-driven QoS
- Bandwidth override rules by VLAN or plan
- IP pools with dual-stack address assignment
Accounting and sessions
- Start, Interim and Stop records with gigawords
- CDRs written to the billing database with a fallback chain
- Daily usage roll-up and quota metering
- Session managers with concurrency limits
Live control
- Disconnect and CoA sent as an RFC 5176 client
- Batch disconnect and per-vendor CoA templates
- Session browser with peer and drop analytics
- Mikrotik peer provisioning with drift detection
Operations
- Console for nodes, workflows, policies and datasources
- Hot configuration reload and last-good snapshot
- SNMP v2c agent with RADIUS MIBs
- Users, roles and an audit log
Use cases
Where i2i AAA is used
Broadband ISP with PPPoE
A regional ISP points its gateways at i2i AAA. Each login is checked against the subscriber record in the billing database, the plan sets the speed through vendor attributes and the accounting stream lands in the billing schema. Support can then disconnect a subscriber from the console.
Enterprise and campus Wi-Fi
An operator serving business customers runs 802.1X with EAP-TLS, EAP-TTLS or EAP-PEAP. The team loads the issuing certificate authorities into the Trust Anchors screen, so only clients whose certificates chain to a trusted root are admitted.
Fair-use by time of day
A plan gives full speed overnight and a reduced speed in the evening peak. The access-time policy and its agent send CoA to running sessions when a schedule changes, so subscribers do not need to log in again for the new speed to apply.
Public Wi-Fi with i2i Hotspot
A venue network authenticates guests through i2i Hotspot. i2i AAA runs the Wi-Fi authorise and accounting steps, tracks sessions and writes usage records that the operator can reconcile against the plan sold.
FAQ
i2i AAA: frequently asked questions
Which authentication methods does i2i AAA support?
The current engine supports PAP, CHAP and MS-CHAPv2 in the RADIUS layer, plus EAP over RADIUS with EAP-TLS, EAP-TTLS with inner PAP and EAP-PEAP with inner GTC. EAP-AKA' cryptography is present, but it has no live vector source yet, so we do not offer it as a working method.
Can i2i AAA administer network devices as well as subscribers?
No. The current engine is a RADIUS and Diameter server for subscriber and Wi-Fi access. The console has a device-admin data model for admin users and command sets, but no device-administration listener is delivered, so it does not replace a dedicated network-device access server.
Where does it read subscriber data from?
From a JDBC database through a lookup query, from the i2i billing schema, from LDAP and from an external subscriber API. Datasources can be grouped. The engine does not change your database schema; database scripts are supplied separately.
How is it different from the older i2i AAA?
The current engine is a rewrite. It has a separate control service and a Next.js operator console, and it runs both RADIUS and Diameter frontends in one node process. The older engine still exists for existing deployments and keeps its own admin service. Ask us which one your deployment uses.
Can it disconnect a subscriber or change their speed?
Yes. The node acts as an RFC 5176 client and sends Disconnect-Request and CoA messages to the access device, from a console action, in batch or from the schedule agent. It does not yet act as a receiver of CoA requests from another system.
What happens if the control service is unavailable?
A node writes a snapshot of its configuration each time it loads one. If the control service cannot be reached at start-up, the node uses the last good snapshot. If no snapshot exists it stops rather than running with unknown rules.
Does it support Diameter?
Partly. The node implements Diameter base-protocol peer handling and a relay step. Connectors to subscriber-data, policy and charging systems are not complete, so we do not present it as a Diameter policy or charging platform. RADIUS is the mature interface.
