TLDR
- The AAA server picks each client’s shared secret by source IP address (RFC 2865 §3), so every BNG needs a fixed address and its own secret.
- Use shared secrets of at least 24 random octets, as the IETF’s July 2026 draft on insecure RADIUS practices recommends (7.1).
- Acct-Interim-Interval must not go below 60 seconds and should not go below 600 (RFC 2869 §5.16).
RADIUS server configuration for a broadband network gateway (BNG) or broadband remote access server (BRAS) comes down to eight values: AAA server addresses and ports, a unique shared secret per client, NAS-Identifier, retransmit count and timeout, dead time before failover, the accounting interim interval, realm routing rules, and a CoA listener on UDP 3799.
AAA stands for authentication, authorization, and accounting. RFC 5176 lets the AAA server act on a live session in two ways: a Disconnect-Request (§2.1) ends the session, and a CoA-Request (§2.2) changes its authorization.
The BNG is the RADIUS client, or network access server in RFC terms, and talks to the AAA server over the User Datagram Protocol (UDP). Each value it holds needs a matching AAA-side entry.
Figure 1. RADIUS messages exchanged between a BNG and Alepo AAA Server during one subscriber session.
RADIUS client configuration on the BNG or BRAS
RADIUS client configuration tells the BNG where to send requests, which shared secret signs them, and when to give up on a silent AAA server. Vendors name these settings differently, so match them by function.
| Setting | Starting value or range | Why | Matching AAA-server entry |
| AAA servers and ports | Two or more per server group. UDP 1812 for authentication (RFC 2865 §3), UDP 1813 for accounting (RFC 2866 §3) | Gives the BNG a server to fail over to | A client record for this BNG on every server in its group |
| Source address | One fixed loopback or management address | The AAA server picks the secret by source IP (RFC 2865 §3), so a changing address breaks logins | Client record keyed to that exact IP address |
| Shared secret | Unique per BNG, 24 or more random octets | A leak exposes only that BNG | The same secret in this BNG’s client record |
| NAS-Identifier | A stable, unique site-and-node name | Identifies the BNG in policies and reports after readdressing (RFC 2865 §5.32) | Policies and reports keyed to the name |
| Timeout and retransmit | 2 to 5 seconds, 2 to 3 tries per server, with backoff (a longer wait after each retry) and jitter (a small random offset), per RFC 5080 §2.2.1 | Gets a login to the second server sooner | Duplicate detection on, so retries are not processed twice (RFC 5080 §2.2.2) |
| Dead time | 2 to 10 minutes | Skips a silent server long enough to ride out a restart | Status-Server answered, so the BNG can detect recovery (RFC 5997) |
| Message-Authenticator | Send in every Access-Request and require it in responses | With the AAA server also requiring it, this integrity check (RFC 2869 §5.14) closes the 2024 BlastRADIUS forgery attack (draft §4.2–4.6) | “Require Message-Authenticator” set for this client (draft §4.1, §4.3), and Message-Authenticator sent first in every response (§4.5) |
| CoA listener | UDP 3799 (RFC 5176 §2.1 and §2.2), open only to AAA server addresses | Lets the AAA server change or disconnect live sessions | CoA and Disconnect requests sent to the BNG’s address on UDP 3799 |
Keep the realm in User-Name (RFC 2865 §5.1) and let the AAA server set the interim interval per subscriber.
RADIUS server configuration: clients, realms, and policies
On the AAA server, each BNG is a client record matched by source IP address. Realm rules then route each request to local authentication, a partner, or a reject.
Registering each BNG as a RADIUS client
Create one client record per BNG and key it to the exact source address. A subnet-wide entry that shares one secret is quicker to set up and far harder to rotate.
Each record holds the secret, the BNG model’s attribute dictionary (the vendor-specific attributes it understands), and the CoA destination. The IETF draft draft-ietf-radext-deprecating-radius-10 (July 3, 2026, a work in progress) adds two per-client flags in §4.1.
Set require Message-Authenticator for every BNG that sends it, and limit Proxy-State for older BNGs that cannot. Only proxies add Proxy-State (RFC 2865 §5.33), so a genuine BNG request never carries it (draft §4.4).
Realm routing for ISP and wholesale traffic
A realm is the domain part of a Network Access Identifier (NAI), the user@realm format in RFC 7542 §2. RADIUS has no routing protocol, so realm rules are static entries on each AAA server (draft §7.7.2). Bind each realm to the BNGs allowed to send it.
Take a regional internet service provider (ISP) with two BNGs that also wholesales access to a smaller provider:
| Realm in User-Name | AAA server action | Result |
| isp.example | Authenticate locally | Retail plans |
| biz.isp.example | Authenticate locally | Business plans with static addresses |
| partner.example | Proxy to the partner’s AAA server | Partner decides access; ISP keeps an accounting copy |
| No realm | Apply the default realm, isp.example | Older routers that send bare user names still log in |
| Any other realm | Reject | Unknown traffic stays out |
The realm picks the policy, and the RADIUS attributes in the Access-Accept carry it to the BNG.
RADIUS shared secret: what it is, how long, how to rotate
A RADIUS shared secret is a value set on both the BNG and the AAA server. It signs packets and hides passwords, so its strength limits what an attacker capturing RADIUS traffic can do.
What is a RADIUS key?
A RADIUS key is the shared secret under another name. Interfaces label it key, secret, or shared key.
The secret never travels in a packet. Each side hashes it with packet contents (MD5) to compute the Response Authenticator, the 16-octet signature on each reply (RFC 2865 §3). It also obfuscates User-Password (§5.2).
Message-Authenticator (RFC 2869 §5.14) uses the secret as the key for an HMAC-MD5 (keyed-hash message authentication code) over the whole packet. For the full exchange, see how the RADIUS protocol works.
RADIUS shared secret on the BNG: what it is, how long, how to rotate
The RADIUS shared secret (or RADIUS key) must match on the BNG and the AAA server. It never crosses the wire. Both sides use it to sign responses, accounting packets and CoA requests, to key Message-Authenticator, and to hide User-Password. For what it does not protect, see RADIUS security and the BlastRADIUS fix.
How to rotate RADIUS shared secrets without an outage
RADIUS cannot negotiate a new secret, so rotate on an AAA server that accepts two secrets per client for a short window, testing each request against both. An Access-Request’s Request Authenticator is random (RFC 2865 §3), so Access-Requests must carry Message-Authenticator for the server to tell which secret signed them. Accounting-Requests are checked by their Request Authenticator, which is computed with the secret (RFC 2866 §3). The server answers with whichever secret matched. CoA and Disconnect requests run the other way, and a BNG usually holds one secret per server, so the server must sign them with the secret that BNG last used (RFC 5176 §2.3).
- Generate a new secret of 24 or more random octets and store it in your secrets vault, out of tickets and chat.
- Confirm the BNG sends Message-Authenticator and its second AAA server is healthy.
- Add the new secret alongside the old one in this BNG’s client record on every AAA server in its server group, and confirm each server shows both secrets.
- In a low-traffic window, change the secret on the BNG for each AAA server entry.
- Log in a test subscriber, send a Status-Server health check (RFC 5997 §3), and check the AAA log for authenticator failures.
- After one clean interim interval, remove the old secret and record the date.
Without dual-secret support, use a short maintenance window per BNG, and first check whether the BNG drops sessions when accounting fails. Accounting records keep retrying until acknowledged (RFC 5080 §2.2.1). Rotate every 6 to 12 months and after any staff change or exposed backup.
RADIUS accounting interim interval and failover settings
Acct-Interim-Interval (RFC 2869 §5.16) sets the seconds between Interim-Update records (Acct-Status-Type 3, RFC 2869 §2.1). Retransmit, timeout, and dead time set how fast a BNG fails over.
Choosing an Acct-Interim-Interval
RFC 2869 §5.16 says the value MUST NOT be below 60 seconds and SHOULD NOT be below 600. Shorter intervals give fresher usage counters and lose less billable data if a Stop record (RFC 2866 §5.1) goes missing. Longer ones cut load on the BNG, network, and AAA server.
For flat-rate broadband, 600 to 1,800 seconds is a sound range. Usage-based quotas can justify 300 seconds, below the RFC 2869 recommendation, if the AAA cluster is sized for the extra records.
Sending the interval in each Access-Accept lets you change it per plan, though a BNG’s local minimum wins over a smaller value (RFC 5080 §2.3.4). Enable the per-session random delay RFC 2869 §2.1 allows, or sessions restored together after a power cut keep reporting together.
RADIUS dead time, timeout, and retransmit settings
RFC 5080 2.2.1 recommends a 2-second initial timeout that doubles on each retry, with jitter. It caps each wait at 16 seconds and the exchange at 5 attempts or 30 seconds. The July 2026 draft (5.4.1) would make backoff and jitter mandatory.
With two AAA servers, use 2 or 3 tries each. The RFC defaults can hold a login for up to 30 seconds before the BNG tries the second server. Accounting is the exception: RFC 5080 advises retrying an Accounting-Request until acknowledged, so usage records survive.
A dead time of 2 to 10 minutes rides out a node restart. Where the BNG supports Status-Server probes (RFC 5997), use them to detect recovery without risking a live login.
Frequently asked questions
Q1. How do you configure RADIUS on a BNG?
Give the BNG two or more AAA servers on UDP 1812 and 1813, a fixed source address, a unique shared secret, a NAS-Identifier, failover timers, an interim interval, and a CoA listener on UDP 3799. Then register it on the AAA server.
Q2. What is a RADIUS key?
It is another name for the RADIUS shared secret, set on both the BNG and the AAA server. It signs responses and obfuscates User-Password (RFC 2865 §5.2), and it never travels in a packet.
Q3. How do you rotate a RADIUS shared secret?
Add the new secret on the AAA server alongside the old one, change it on the BNG, test, then remove the old one. Without dual-secret support, use a short maintenance window per BNG.
Q4. What is a realm in RADIUS?
It is the part of a Network Access Identifier after the @, as in user@isp.example (RFC 7542 §2). The AAA server uses it to authenticate locally, proxy, or reject.
Q5. Which interim accounting interval should I use?
RFC 2869 §5.16 sets a 60-second floor and recommends at least 600. Use 600 to 1,800 seconds for flat-rate broadband, go lower only for usage-based quotas, and add jitter.
Q6. Which RADIUS settings control failover?
Failover depends on timeout, retransmit count, dead time, and server order. Use backoff and jitter (RFC 5080 §2.2.1) and Status-Server probes to spot a recovered server.
Conclusion
A mismatched secret fails silently on both sides. The BNG discards replies it cannot verify and simply times out (draft §4.6), and with Message-Authenticator required, the AAA server discards the request without replying (§4.3). Both should log each discard, so check those logs before suspecting the network.
Work in order: client records and secrets, then realm rules, then accounting and failover timers. Test one subscriber end to end at each step, since a broken secret fails every later test.
Alepo AAA Server, our carrier-grade AAA server, is engineered for 99.999% availability, and the AAA Server datasheet has its full specifications.
See your BNG settings on a live AAA server. Book a demo and our engineers will walk you through them on Alepo AAA Server.
