RADIUS Accounting：追蹤工作階段、使用量與稽核記錄
本指南提供 RADIUS accounting 的完整技術參考 - 說明其如何記錄 WiFi 工作階段的 Start、Stop 及 Interim-Update 資料、擷取哪些屬性，以及如何利用該資料進行安全性稽核、GDPR 合規與容量規劃。對於需要從 WiFi 驗證事件中取得具抗辯性稽核軌跡的網路營運與安全性團隊，以及尋求將工作階段資料整合至 SIEM 平台與分析儀表板的場域營運商而言，這是必讀內容。
Video overview
收聽此指南
查看播客逐字稿
核心系列的一部分：企業級 WiFi 安全性指南 →
RADIUS accounting sizing and session audit advisor
Calculate steady-state packet throughput (PPS), database log expansion, WAN bandwidth overhead, and generate turnkey AAA accounting profiles across enterprise network controllers.
RADIUS packet rate and database write analysis
RFC 2866 dictates that Network Access Servers (NAS) transmit an Accounting-Start packet when a client associates, periodic Interim-Update packets during the session, and an Accounting-Stop packet upon termination. Sizing your AAA layer requires modeling peak connection rushes alongside ongoing heartbeat load.
- Accounting-Start: 0.04 req/s average baseline
- Interim-Update: 3.33 req/s continuous heartbeat flow
- Accounting-Stop: 0.04 req/s closure telemetry
- Morning rush burst (2.5x): 8.5 requests per second peak
- Daily table growth: 39.3 MB / 24-hour cycle
- 90-day retention total: 3.5 GB uncompressed index pool
- Recommended SQL pooling: Minimum 8 worker threads
- Table partitioning: Standard B-tree indexes sufficient
執行摘要
對於企業 IT 與網路維運團隊而言，驗證使用者登入 WiFi 網路僅完成了工作的一半。一旦裝置連線，了解該裝置的行為 - 包含連線時間、消耗的數據量以及斷線時間 - 對於安全、容量規劃和合規性至關重要。這正是 RADIUS accounting 不可或缺的原因。雖然 RADIUS 驗證負責處理網路存取的「誰」與「如何」，但 RADIUS accounting 會細緻地記錄「什麼」、「何時」以及「多少」。
本指南深入探討 RADIUS accounting 的技術細節，探索 Start、Stop 和 Interim-Update 封包的運作機制，以及使其發揮價值的屬性。它概述了 旅宿業、零售業 等領域的場域營運商如何利用這些數據來維護健全的稽核軌跡、確保符合 GDPR 規範，並將具備實用價值的情報輸入至 SIEM 平台或 WiFi Analytics 系統。透過掌握 RADIUS accounting，網路架構師可以將原始工作階段記錄轉化為推動營運效率並降低風險的策略資產。
技術深入探討
RADIUS Accounting 對比 RADIUS Authentication
在 RFC 2865 中定義並在 RFC 2866 中擴展用於 accounting 的 RADIUS (Remote Authentication Dial-In User Service)，其運作基於用戶端與伺服器模型。在典型的企業 WiFi 部署中，存取點 (AP) 或無線區域網路控制器 (WLC) 會充當 Network Access Server (NAS) - 即 RADIUS 用戶端。RADIUS 伺服器 (例如 FreeRADIUS、Cisco ISE、Aruba ClearPass) 會接收並處理請求。
驗證與 accounting 之間的區別至關重要：
| 維度 | RADIUS Authentication | RADIUS Accounting |
|---|---|---|
| 目的 | 驗證身分並允許/拒絕存取 | 記錄工作階段使用情況與活動 |
| UDP 連接埠 | 1812 | 1813 |
| RFC 參考 | RFC 2865 | RFC 2866 |
| 封包類型 | Access-Request、Access-Accept、Access-Reject | Accounting-Request (Start/Stop/Interim) |
| 擷取的數據 | 憑證、VLAN 分配、策略 | 工作階段時間、傳輸的位元組數、IP 位址 |
| 合規角色 | 存取控制 | 稽核軌跡、合法攔截 |
對於大規模部署 Guest WiFi 的團隊而言，這兩項功能皆不可或缺 - 但 accounting 才是讓您保持合規且具備防禦能力的關鍵。
三種 Accounting 封包類型
RADIUS accounting 依賴三種主要的 Accounting-Request 封包類型，每一種皆由 Acct-Status-Type 屬性定義：
Start (Acct-Status-Type = 1)：由 NAS 在使用者成功連線並開始工作階段時傳送。它在計費資料庫中建立基準記錄，擷取使用者身分、裝置 MAC 位址、分配的 IP 位址以及使用者連線的 AP。
Interim-Update (Acct-Status-Type = 3)：在作用中的工作階段期間定期傳送。這些封包提供目前使用情況的即時快照 - 包括已傳輸的位元組、工作階段持續時間和封包數量。它們充當檢測信號以確認工作階段仍處於作用中狀態，並提供對長時間執行工作階段的能見度，而無需等待斷開連線。
Stop (Acct-Status-Type = 2)：在工作階段終止時傳送 - 無論是因為使用者主動中斷連線、AP 重新啟動、閒置逾時還是工作階段逾時。它包含整個工作階段的最終累計統計資料。
圖 1：跨 WiFi 工作階段的 RADIUS 計費封包生命週期。
關鍵計費屬性
為了有效追蹤工作階段並建立具防禦力的稽核記錄，NAS 會使用特定屬性填入 Accounting-Request 封包。以下是運作上最重要的屬性：
| 屬性 | 說明 | 合規相關性 |
|---|---|---|
| Acct-Session-Id | 由 NAS 產生的唯一工作階段識別碼 | 用於關聯 Start、Interim 和 Stop 記錄的主鍵 |
| User-Name | 通過驗證的身分（使用者名稱或 MAC 位址） | 將工作階段對應到特定使用者或裝置 |
| NAS-IP-Address | 提報的 AP 或 WLC 的 IP 位址 | 識別網路區段與實體位置 |
| Framed-IP-Address | 分配給用戶端裝置的 IP 位址 | 對於與防火牆和網頁代理伺服器記錄進行關聯至關重要 |
| Calling-Station-Id | 用戶端裝置的 MAC 位址 | 稽核軌跡的裝置層級身分 |
| Called-Station-Id | AP 的 MAC 位址與 SSID | 識別使用者連線的特定無線電與網路 |
| Acct-Input-Octets | 從用戶端接收的位元組數 | 頻寬監控與容量規劃 |
| Acct-Output-Octets | 傳送到用戶端的位元組數 | 頻寬監控與容量規劃 |
| Acct-Session-Time | 工作階段持續時間（秒） | 停留時間分析與計費 |
| Acct-Terminate-Cause | 工作階段結束的原因 | 疑難排解與異常偵測 |
對於使用 802.1X 驗證 的團隊，User-Name 屬性將包含來自 EAP 交換的已驗證身分，提供比單純 MAC 驗證略過 (MAB) 更豐富的稽核軌跡。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。
實作指南
部署穩健的 RADIUS 計費基礎架構，需要在 NAS 與 RADIUS 伺服器端進行仔細的配置。以下是建立可靠計費管道且不限特定廠商的通用方法。
步驟 1：配置 NAS (無線基地台 / 控制器)
NAS 配置通常是大多數部署失敗之處。管理員往往正確配置了驗證，卻將計費保留為預設設定或完全停用。
- 定義計費伺服器：指定 RADIUS 伺服器的 IP 位址以及用於 UDP 連接埠 1813 的共用金鑰。在高可用性部署中，請配置次要計費伺服器，以防止主要伺服器無法連線時發生資料遺失。
- 啟用過渡更新 (Interim Updates)：這是最關鍵的配置步驟。設定適當的間隔 - 企業部署通常為 10 到 15 分鐘。較短的間隔（例如 1 分鐘）可提供更精細的資料，但在大規模環境下會產生無法承受的寫入負載；較長的間隔（例如 30 分鐘）可減少開銷，但會延遲對活動工作階段的掌握。
- 確保時間同步：在所有 NAS 裝置與 RADIUS 伺服器上配置 NTP。精確的時間戳記對於稽核記錄和 SIEM 關聯性分析是不可或缺的。在合法監聽的情境下，5 分鐘的時鐘偏差就可能使稽核軌跡失效。
步驟 2：配置 RADIUS 伺服器
- 資料庫整合：配置 RADIUS 伺服器將計費資料記錄到結構化關聯式資料庫（例如 PostgreSQL、MySQL），而非純文字檔案。結構化儲存能實現高效的查詢、索引以及與下游系統的整合。確保
Acct-Session-Id、User-Name、Framed-IP-Address以及工作階段開始時間戳記上建有索引。 - 資料保留政策：實作符合合規要求的自動封存或清除指令碼。GDPR 第 5(1)(e) 條要求資料保留時間不得超過必要期限；然而，許多司法管轄區的合法監聽法規（例如英國的《2016 年調查權力法》）可能要求保留長達 12 個月。
步驟 3：建立資料管道
為了最大化計費資料的價值，必須將其匯出至取用平台，以便進行查詢、關聯分析與視覺化。
- SIEM 整合：配置 RADIUS 伺服器或底層資料庫，使用 Syslog 或 REST API 將記錄轉發到您的 SIEM（例如 Splunk、Microsoft Sentinel、IBM QRadar）。這使安全性團隊能夠將 WiFi 驗證事件與防火牆阻擋、入侵偵測警報或資料外洩防護觸發器進行關聯分析。- 分析整合：將工作階段資料匯入 Purple 的 WiFi Analytics 等平台，將原始位元組和 MAC 位址轉換為關於人流量、停留時間和尖峰使用時段的可行洞察。這對於需要根據實際使用模式調整員工配置和基礎設施投資的 Retail 和 Hospitality 營運商而言特別有價值。
圖 2：從存取點到 SIEM 和分析平台的 RADIUS 計費資料管線。
最佳實踐
務必使用過渡更新（Interim Updates）。 僅依賴 Start 和 Stop 封包會產生營運盲點。連線中斷或 AP 電源故障可能會導致無法傳送 Stop 封包，從而在資料庫中無限期留下過期工作階段。過渡更新提供了偵測並關閉這些過期工作階段的機制。經驗法則：如果某個工作階段在設定間隔的兩到三倍時間內未傳送過渡更新，請將其視為已終止。
將 RADIUS 計費與 DHCP 記錄進行關聯。 RADIUS 計費提供了 Framed-IP-Address，但在某些環境中，DHCP 租約時間可能短於工作階段持續時間。將 DHCP 記錄與 RADIUS 記錄一起保留，可提供更具彈性的稽核軌跡，尤其是在 IP 位址回收頻繁的高密度場域中。
使用 RadSec 保護傳輸安全。 傳統的 RADIUS 流量是透過 UDP 傳輸，且加密極少 - 僅對使用者密碼欄位進行模糊處理。在分散式佈署中，特別是跨多個站點或雲端託管的 RADIUS 伺服器，請使用 RadSec（TLS 上的 RADIUS，定義於 RFC 6614）或 IPsec 隧道來保護傳輸中的計費資料。對於任何處理持卡人資料的網路，這是 PCI-DSS 4.0 的要求。
監控計費佇列。 如果 RADIUS 伺服器變得無法連線，NAS 設備將在本機將計費封包排入佇列。監控此佇列長度；佇列已滿將導致丟棄封包和遺失稽核資料。針對佇列深度設定警示，並為高可用性佈署實施次要計費伺服器。
在具規模的佈署中分離驗證和計費伺服器。 在同時上線使用者超過 5,000 人的佈署中，計費帶來的寫入負載可能會降低驗證回應時間。配備獨立資料庫執行個體的專用計費伺服器可防止這種資源爭奪。
疑難排解與風險緩釋
過期工作階段問題
症狀：RADIUS 資料庫顯示使用者已連線 48 小時，但該場域在夜間已關閉。
根本原因：NAS 未能傳送 Stop 封包 - 通常是由於電源故障、AP 重啟或網路中斷 - 且 RADIUS 伺服器從未收到該封包。
緩釋措施：在 RADIUS 伺服器上實施過期工作階段清理指令碼。該指令碼應定期掃描活動工作階段，其中最後收到的封包（Start 或 Interim-Update）比定義的閾值（例如：過渡更新間隔的 2.5 倍）更舊。超過此閾值的工作階段應使用合成的 Stop 記錄強制關閉，並將終止原因註記為「Lost-Carrier」或「Admin-Reset」。
RADIUS 伺服器 CPU 和 I/O 負載過高
症狀：在尖峰時段，驗證回應時間變慢；RADIUS 伺服器回報 CPU 和磁碟 I/O 過高。
根本原因：在數千個 AP 上設定了過於頻繁的過渡更新間隔（例如：1 分鐘），產生了無法承受的資料庫寫入量。
緩解措施：將過渡更新（interim update）間隔增加至 15 分鐘。驗證記帳資料庫是否具有適當的索引。考慮將驗證和記帳分離到專屬的伺服器執行個體上。評估針對高容量的記帳數據，時間序列資料庫（例如 InfluxDB）是否比關聯式資料庫更合適。
記帳記錄中遺失 Framed-IP-Address
症狀：存在 RADIUS 記帳記錄，但 Framed-IP-Address 欄位為空或不存在，導致無法進行 IP 與 MAC 的關聯。
根本原因：NAS 可能在 DHCP 向用戶端分配 IP 地址之前就發送了 Start 封包。該 IP 只有在 DHCP 交換完成後才可用。
緩解措施：如果平台支援，請將 NAS 設定為延遲發送 Start 封包，直到 DHCP 分配完成後再發送。或者，依賴在 DHCP 分配後發送且將包含 Framed-IP-Address 的 Interim-Update 封包。確保您的稽核查詢在 Start 記錄缺少 IP 時，透過檢查 Interim-Update 記錄來考慮到這一點。
投資報酬率與商業影響
實作健全的 RADIUS 記帳可在三個維度上提供可衡量的商業價值：
合規性與法律風險緩解。 在發生安全性事件、GDPR 規範下的資料當事人存取請求或合法監聽命令時，準確的記帳記錄可提供必要的稽核軌跡，以識別哪個使用者或裝置在特定時間點持有特定的 IP 地址。如果沒有這些記錄，企業將面臨 GDPR 規範下的潛在監管處罰（最高可達全球年營業額的 4%）和商譽損失。實作妥善記帳基礎設施的成本，僅是單次監管執法行動成本的一小部分。
容量規劃與基礎設施投資報酬率。 透過分析長期下來的 Acct-Input-Octets 和 Acct-Output-Octets 趨勢，網路架構師可以識別頻寬消耗模式、尖峰使用期，以及帶來最高負載的特定 AP 或 SSID。這些數據能直接為 WAN 升級決策和 AP 部署策略提供資訊，確保基礎設施投資能用在產生最大效益的地方。對於 大眾運輸 樞紐和大型場館而言，這可以節省大量的資本支出。增強型分析與場域智慧。 當 RADIUS 工作階段資料與 Purple 的 WiFi Analytics 和 Sensors 等平台相結合時，原始計費資料就會轉化為場域智慧。源自工作階段持續時間的停留時間指標、源自 Calling-Station-Id 歷史記錄的重複訪客識別，以及源自並行工作階段計數的尖峰容量分析，皆可輕鬆取得。對於 Hospitality 營運商而言，這些資料能直接為員工配置模型、餐飲配置和行銷個人化策略提供決策依據。如需進一步瞭解 WiFi 基礎設施如何支援這些功能，請參閱我們關於 Wireless Access Points 和 Modern Hospitality WiFi Solutions 的指南。
關鍵定義
RADIUS Accounting
收集並記錄有關使用者網路資源消耗數據的程序，包括工作階段開始與結束時間、傳輸的資料量以及 IP 位址分配。定義於 RFC 2866。
在任何企業 WiFi 部署中，對於計費、容量規劃、GDPR 合規性以及維護安全稽核軌跡皆至關重要。
Acct-Status-Type
一個 RADIUS 屬性（屬性 ID 40），用於指示記帳封包的目的。值包括 Start (1)、Stop (2) 和 Interim-Update (3)。
RADIUS 伺服器用來判斷是要建立新的工作階段記錄、更新現有記錄還是關閉記錄。這是任何記帳封包中最基礎的屬性。
Interim-Update
NAS 在作用中工作階段期間定期傳送的 RADIUS Accounting 封包，用於回報當前的使用統計資料，包括已傳輸的位元組數和工作階段持續時間。
對於追蹤長期工作階段，以及在用戶端意外斷線且未傳送 Stop 封包時偵測過期工作階段至關重要。
Acct-Session-Id
由 NAS 產生的唯一字串，用於識別特定的使用者連線執行個體。對於同一個工作階段的所有記帳封包（Start、Interim-Update、Stop），此值均保持一致。
用於關聯屬於同一工作階段之所有記帳記錄的主索引鍵。若沒有此屬性，將無法重建完整的工作階段歷程記錄。
NAS (Network Access Server)
控制對網路實體存取並充當 RADIUS 用戶端的裝置 - 通常為無線基地台或無線區域網路控制器 - 負責產生並傳送記帳封包。
NAS 負責記帳數據的準確性與完整性。NAS 層級的配置錯誤（例如停用記帳、遺失屬性）無法在 RADIUS 伺服器層級進行補救。
Framed-IP-Address
在工作階段持續期間分配給用戶端裝置的 IP 位址，包含在 RADIUS Accounting 封包中。
對於將 RADIUS Accounting 記錄與其他網路記錄（例如防火牆、網頁代理或 DNS 記錄）進行關聯分析至關重要。缺少此屬性將無法進行 IP 與裝置之間的關聯。
Calling-Station-Id
通常為連接到網路的用戶端裝置的 MAC 位址，格式化為以冒號分隔的十六進位字串（例如 AA:BB:CC:DD:EE:FF）。
用於識別特定的硬體裝置，無論其分配到的 IP 位址為何。這是稽核軌跡的裝置層錨點。
Acct-Terminate-Cause
包含在 Stop 封包中的屬性，指定工作階段結束的原因。常見值包括 User-Request、Lost-Carrier、Idle-Timeout、Session-Timeout 和 Admin-Reset。
對於排查連線問題和偵測異常非常實用 - 例如，特定 AP 上的 Lost-Carrier 中斷率過高可能表示存在硬體或干擾問題。
RadSec
透過 TLS（傳輸層安全性協定）傳輸的 RADIUS，定義於 RFC 6614。為 RADIUS 封包提供加密和身分驗證的傳輸，取代傳統基於 UDP 的傳輸。
在 RADIUS 流量行經未受信任網路（例如連線至網際網路的雲端 RADIUS 伺服器）的任何部署中均為必需。PCI DSS 4.0 對於持卡人資料環境的要求也越來越多地強制執行此項。
範例
一家擁有 300 間客房並設有會議設施的飯店正準備部署新的訪客 WiFi 網路。IT 經理需要確保該部署符合 GDPR 關於資料最小化與稽核軌跡完整性的要求，同時還能為行銷團隊提供停留時間與重複訪客分析。該飯店使用雲端託管的 RADIUS 伺服器與 Cisco Meraki AP。
部署應配置如下。在 Meraki 儀表板上，導覽至 Network-wide > RADIUS servers，並在連接埠 1813 上新增雲端 RADIUS 伺服器，設定強共用金鑰。啟用 accounting 並將暫時更新（interim update）間隔設為 15 分鐘。在 RADIUS 伺服器上，將 accounting 配置為寫入具有以下結構的 PostgreSQL 資料庫：session_id（主索引鍵）、user_name、nas_ip、framed_ip、calling_station_id、called_station_id、session_start、session_end、input_octets、output_octets、terminate_cause。實施資料保留原則，自動將超過 12 個月的記錄封存至冷儲存，並清除超過 24 個月的記錄，此原則需記錄在飯店的 GDPR 處理活動記錄中。配置 Purple WiFi Analytics 整合以匯入工作階段資料，使行銷團隊能夠存取停留時間報告和重複訪客頻率儀表板。確保所有 Meraki AP 與 RADIUS 伺服器之間的 NTP 同步在 1 秒以內。
一家擁有 150 家門市的連鎖零售商需要符合 PCI-DSS 4.0 關於網路存取監控的要求。其銷售點（POS）終端在 WiFi 網路上使用 MAC 驗證規避（MAB）。安全性團隊收到其 QSA（合格安全性評估員）的要求，要求證明他們能夠僅使用防火牆記錄中的來源 IP 地址和時間戳記，識別在任何特定時間存取付款網路的特定 POS 終端。
該解決方案需要三部分的整合。首先，驗證所有無線區域網路控制器（WLC）均已配置為在 RADIUS accounting 封包中包含 Framed-IP-Address 屬性。這通常不是預設啟用的，必須進行明確配置。其次，將 RADIUS accounting 資料庫與 SIEM 平台（例如 Splunk）整合。在 Splunk 中建立對照表，將 Framed-IP-Address 和工作階段時間範圍對應到 Calling-Station-Id（MAC 地址）。第三，建立一個 Splunk 已儲存搜尋，該搜尋接受來源 IP 和時間戳記作為輸入，並從 RADIUS accounting 記錄中傳回對應的 MAC 地址、NAS-IP-Address（用於識別門市和 AP）以及 User-Name。接著便可向 QSA 演示此工作流程：給定一筆顯示特定日期 14:23:07 來源 IP 為 10.5.12.44 的防火牆記錄項目，搜尋會傳回該 POS 終端的 MAC 地址、其連線的 AP 以及門市位置。
練習題
Q1. 飯店 IT 經理注意到，儘管大廳和餐廳明顯很忙碌，但 WiFi 分析儀表板顯示白天的活躍使用者卻非常少。然而，前一天的歷史報告卻顯示數據使用量大幅飆升。RADIUS 伺服器記錄確認已收到 Start 封包，但資料庫顯示的 Interim-Update 記錄卻非常少。最可能的錯誤配置是什麼，您會如何解決？
提示：請考慮在作用中工作階段期間與斷線時，資料使用量是如何回報的差異。
查看標準答案
最可能的原因是無線區域網路控制器（WLC）上停用或未設定 Interim-Updates。在沒有臨時更新的情況下，RADIUS 伺服器僅在使用者連線時收到 Start 封包，並在其中斷連線時收到 Stop 封包。由於沒有回報工作階段內的數據，分析儀表板無法顯示目前的使用情況。一旦使用者離開並中斷連線，Stop 封包就會隨總累積數據一起送達，從而導致歷史報告中出現延遲的飆升。解決方案是在 WLC 上啟用 Interim-Updates 並設定適當的間隔 - 飯店環境建議設定為 15 分鐘。啟用後，透過檢查計費資料庫中 Acct-Status-Type = 3 的記錄，確認 RADIUS 伺服器是否正在接收 Interim-Update 封包。
Q2. 在安全性事件調查期間，您的 SIEM 標記了訪客 WiFi 網路上的某個 IP 位址在特定日期的 09:47:23 存取了已知的命令與控制（C2）伺服器。您需要識別負責的實體裝置。您的 DHCP 租約時間設定為 30 分鐘。請描述您將對 RADIUS 計費資料庫使用的確切查詢邏輯，以識別該裝置。
提示：IP 位址不是靜態的。您必須使用時間範圍查詢，而不是特定時間點的查找，並考慮到 DHCP 租約循環使用。
查看標準答案
您必須查詢 RADIUS 計費資料庫中符合以下條件的工作階段：(1) Framed-IP-Address 等於被標記的 IP 位址，且 (2) session_start 時間戳記早於或等於 09:47:23，且 (3) session_end 時間戳記晚於或等於 09:47:23，或 session_end 為 NULL（查詢時工作階段仍處於活躍狀態）。如果有多個工作階段相符（在 30 分鐘 DHCP 租約下是有可能的），請審查 Interim-Update 記錄以確認哪個工作階段在 09:47:23 正在主動回報使用量。相符的工作階段記錄將包含 Calling-Station-Id（裝置的 MAC 位址）和 User-Name（已驗證的識別身分，如果使用了 802.1X）。將 MAC 位址與您的裝置清冊或 DHCP 伺服器記錄進行交叉比對，以識別實體裝置及其擁有者。
Q3. 您是一家會議中心的網路架構師，該中心舉辦的活動最多可容納 8,000 名同時在線的 WiFi 使用者。您目前的 RADIUS 伺服器在高峰活動期間遇到資料庫寫入飽和，導致驗證延遲 3 - 5 秒。您目前的臨時更新間隔設定為 2 分鐘。請描述一個多步驟的補救計劃，以解決眼前的效能問題和底層的架構風險。
提示：同時考慮配置變更與架構變更。其目標是在減少寫入負載的同時，維持稽核軌跡的完整性。
查看標準答案
補救計畫應從三個層面著手。首先，作為立即生效的權宜措施，將所有無線控制器上的臨時更新（interim update）間隔從 2 分鐘增加到 15 分鐘。這可以將計費寫入負載降低約 87%（從每會話每 2 分鐘寫入一次降至每 15 分鐘一次），從而立即緩解資料庫的 I/O 壓力。其次，將認證與計費的工作負載分離到專用的伺服器執行個體上。認證伺服器處理 Access-Request/Accept/Reject 封包，而專用的計費伺服器則處理 Accounting-Request 封包並寫入獨立的資料庫。這可以防止計費寫入負載影響認證的回應時間。第三，針對底層的架構風險，評估時序資料庫（例如 InfluxDB 或 TimescaleDB）是否比關聯式資料庫更適合處理計費工作負載。時序資料庫針對高吞吐量的順序寫入與時間範圍查詢進行了最佳化，這與計費資料的模式完全吻合。將計費寫入轉移到時序資料庫，同時保留關聯式資料庫用於合規性報告查詢。
常見問題
What is RFC 2866 RADIUS accounting and how does it differ from RADIUS authentication?
RFC 2866 defines RADIUS accounting as a distinct UDP protocol (port 1813) decoupled from authentication (UDP 1812). While authentication validates client identity and authorizes access, accounting tracks session lifecycle events through three message types: Accounting-Start (session initiation), Accounting-Stop (disconnection), and periodic Interim-Update packets. These packets record connect timestamps, session durations, input and output octets, and termination reasons.
How do Acct-Interim-Interval timers impact network controllers and RADIUS servers?
Acct-Interim-Interval (Attribute 85) controls the heartbeat frequency at which Network Access Servers transmit session progress telemetry. Setting this interval too low (under 120 seconds) creates write amplification on backend database tables and consumes excess CPU on access points. Setting it too high (over 900 seconds) leaves ghost sessions active in analytics pipelines and delays bandwidth quota enforcement. An interval between 300 and 600 seconds offers the optimal balance between real-time accuracy and server capacity.
How does RADIUS accounting track client bandwidth consumption accurately?
Bandwidth utilization is reported using Acct-Input-Octets (Attribute 42) and Acct-Output-Octets (Attribute 43), representing bytes transmitted and received by the client. For high-throughput WiFi 6 and WiFi 7 connections that exceed 4GB of traffic during a single session, RFC 2869 attributes Acct-Input-Gigawords (Attribute 52) and Acct-Output-Gigawords (Attribute 53) track 32-bit counter rollovers to provide exact multi-gigabyte session accounting.
Why is Acct-Delay-Time essential when Network Access Servers buffer accounting packets?
When network congestion or temporary WAN outages prevent a NAS from reaching the RADIUS accounting server, the controller queues accounting packets in local memory. RFC 2866 Section 5.1 requires the NAS to populate Acct-Delay-Time (Attribute 41) with the number of seconds a packet sat in its queue before successful delivery. The RADIUS server subtracts this delay from the receipt timestamp to determine the exact historical event time, preventing audit log clock skew.
How should network administrators prevent database bottlenecks from RADIUS accounting logs?
Large campuses and high-density venues generate millions of accounting rows daily. To maintain sub-millisecond database insertion times and prevent table locking, administrators should implement monthly or daily table partitioning on the radacct table using AcctStartTime range keys. Indexing should be restricted to Acct-Unique-Id, UserName, and FramedIPAddress, while historical audit partitions older than the statutory retention window are archived to cold object storage.
How does Purple utilize RADIUS accounting for enterprise analytics and compliance?
Purple ingests RFC 2866 accounting streams from enterprise access points to power real-time visitor presence dashboards, dwell time metrics, and bandwidth policy enforcement. Purple automatically reconciles Acct-Session-Id telemetry across multi-vendor networks, correlates physical venue footfall with digital authentication events, and retains tamper-evident audit logs with a configurable retention window, so the period you keep visitor records for is one you can document and defend.
繼續閱讀本系列
Cyber Essentials and Staff WiFi：在您的無線網路通過五項控制指標
您將能夠把 Cyber Essentials 的五項控制指標與您的員工 WiFi 進行對照，並補強評估人員發現的安全漏洞。接著，您可以為各類別裝置選擇使用 802.1X、iPSK 或隔離的 WPA2 - PSK 網路。最後，您將了解如何為 Cyber Essentials Plus 審計準備好存取點、控制器及 BYOD 裝置。
HPE Aruba Central 存在感分析：設定、匯出與限制
您將能夠針對每個場地啟用 Aruba Central 存在感分析、根據實地真實數量校準 RSSI 閾值與停留時間界限，並透過 Central REST API 匯出場地層級的彙總數據。您還將了解原生存在感分析在何處受限，以及像 Purple 這樣與硬體無關的平台層何時能在您現有的 Aruba 基地台（AP）上發揮其價值。
CIPA 合規性：場所營運商的合規檢查清單
您將能夠判定您的 WiFi 是否受到 CIPA 約束，進而對網路進行區隔、將 DNS 路由導向 Purple Shield 並關閉繞過路徑。您還將了解為 Form 486 或 Form 479 認證需要保留哪些證據。此檢查清單為每項要求都指定了負責人，讓您在下一個資助年度的認證中不會遺漏任何內容。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。