Guest anchor RADIUS accounting = no data usage figures?

[PWJPW]

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.

Example packet:

          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+)

Thank you

James

[RichardAtkin]

When anchoring, you should only use the Foreign (Internal) WLC for accounting, not the Anchor.  This is a known limitation 'feature'.

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.

[PWJPW]

Thanks. However all the authentication requests are Layer 3 so must come from the Anchor (web auth). So, how to tell the foreign to send just accounting packets? Also, in most setups, the Anchor is inside a DMZ with Internet access, whereas the Foreign is on an internal network with no Internet access?

[RichardAtkin]

Make the foreign send auth & acct, the anchor only sends auth auth.

[PWJPW]

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...

[RichardAtkin]

"Yes" - aware of all of that; it'll be fine.  Have a play yourself in a lab or with a test SSID.

[RichardAtkin]

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.

https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn86.html#multisession-id-support

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-6/config-guide/b_cg86/wlan_timeouts.html#c_info_multisession_id_support

[PWJPW]

Thanks. I can see detail about the Multisession ID Support but I don't think that's related or the problem regarding zero usage information being sent? The description doesn't sound like it anyway?