When using a guest anchor setup with layer 3 (where external webauth is being used with an external radius server) it appears that although radius accounting works fine, the "acctinputoctets" and "acctoutputoctets" values are always zero (0) in both Interim and Stop accounting packets. Everything else seems okay, like the account session time, framed ip values etc.
User-Name Attribute (1), length: 52, Value: abc123@test NAS-Port Attribute (5), length: 6, Value: 1 NAS-IP-Address Attribute (4), length: 6, Value: ip-192.168.31.1 Framed-IP-Address Attribute (8), length: 6, Value: 10.14.5.234 Acct-Session-Id Attribute (44), length: 35, Value: 5ae6695d/c0:1a:da:1a:20:1a/634449 Acct-Status-Type Attribute (40), length: 6, Value: Interim-Update Acct-Input-Octets Attribute (42), length: 6, Value: 0 Acct-Output-Octets Attribute (43), length: 6, Value: 0 Acct-Session-Time Attribute (46), length: 6, Value: 32091 Acct-Delay-Time Attribute (41), length: 6, Value: 00 secs Calling-Station-Id Attribute (31), length: 19, Value: c0-1a-da-xx-xx-xx Called-Station-Id Attribute (30), length: 19, Value: 18-e7-28-xx-xx-xx
Is this a known issue, bug or restriction when using guest anchor with radius accounting? Could it be that this information is lost over the tunnel and thus only the foreign controller knows about the data usage?
We have many clients facing the same problem on many different WLC's (5508, 5760, 3540 etc) and different versions (8.2+)
When anchoring, you should only use the Foreign (Internal) WLC for accounting, not the Anchor. This is a known
Have a look at some of the Cisco Live Presentations for doing Guest Anchoring with ISE & CWA. Although this may not actually be your use case, the factors behind the limitation - RADIS Accounting from an Anchor WLC - are exactly the same.
In this scenario, when webauth is used on the anchor, will the foreign be aware of the authentication being passed and know about things like the username, client IP and session time etc as all this is done by the anchor. Also as above most customers have the foreign on an internal network that may not have an Internet route...
Whether this actually fixes your data figures I'm not sure, raised as a point of best practise more than anything else.
I know Cisco made improvements to RADIUS Accounting behaviour in later releases because customers wanted more granular reporting on some things.
I've also just checked the release notes and it looks like the Foreign/Anchor Accounting limitation is probably resolved in 8.6 onwards - see below. This will make the info you get from the Foreign & Internal WLCs more consistent.