READ THIS if you use Radius

One of our longest standing issues has finally been uncovered.

Ever since we have used MT from 2.7.x we have noticed that radius accounting was sometimes reading low for very heavy users.
We are now running 2.9.27 PPPoE servers with freeradius and the problem still exists.

The problem is that the MT PPPoE Server ppp byte counters appear to be limited to 32bit, or a maximum of 4294967295. This equates to approx 4.3 gigabytes. When you go past this number THE COUNTER WRAPS BACK TO ZERO !

In laymans terms, what this means is, if you use a radius server with your MT Radius client, and your users use more than 4.3gb per ‘radius session’ then their session usage will read very low.

EG IF I use 5gb of data in a single radius session, the end result is that only about 700Mb will get accounted for.

Solution: Ensure you impose a 4gb radius session limitation !

how exactly do you impose this limit, is it MT side or the Radius Server side?

You can do it either way, but if you’re already using radius, use radius.

radreply:
Xmit-Limit (transmit TO client - Downloads)
Recv-Limit (receive FROM client - Uploads)

Also be aware that sometimes the database column ‘AcctOutputOctets’ needs to be set to a type that can take a large integer - if you’re using a db.

http://www.mikrotik.com/docs/ros/2.9/guide/aaa_radius.content#13.4.5.1

Yes, dont forget the DB field type too. In MySQL if you use field type of ‘int’ instead of ‘bigint’, you get limited to 3.7gb !

We use Freeradius with MySQL. To enable the Xmit-Limit and Recv-Limit attributes we had to add this to the freeradius config file:

# MikroTik Attributes

VENDOR          Mikrotik        14988

ATTRIBUTE       Recv-Limit              1       integer         Mikrotik
ATTRIBUTE       Xmit-Limit              2       integer         Mikrotik

Then add the following attributes in the Freeradius MySQL table ‘radgroupreply’

Xmit-Limit == 4000000000 
Recv-Limit == 4000000000

Before the MT ppp counters have a chance to wrap, the radius session will be timed out and a new fresh one will begin as such:

pppoe,ppp,info MT1C: <pppoe-xxxxxxxx@xxxxxx.xxx.xx>: terminating... - max send/recv limit exceeded
pppoe,ppp,info MT1C: <pppoe-0>: waiting for call...
pppoe,ppp,info MT1C: <pppoe-xxxxxxxx@xxxxxx.xxx.xx>: authenticated
pppoe,ppp,info MT1C: <pppoe-xxxxxxxx@xxxxxx.xxx.xx>: connected
pppoe,ppp,info,account MT1C: xxxxxxxx@xxxxxx.xxx.xx logged in, 172.16.237.242

Bingo! No more weird stuff happening with radius accounting.

The proposed Xmit-Limit / Recv-Limit solution works, but I think it is not the most elegant way to do this. I find it disturbing to disconnect a customer (even very shortly) only because I would need this as a workaround for the accounting system. For some setups this might be acceptable (roaming hotspot users, “cheap” residential users etc.), but for customers that are expecting a “leased line experience” I find this unacceptable.

That’s why I use Radius interim accounting and the Acct-Input-Gigawords/Acct-Input-Octets/Acct-Output-Gigawords/… attributes with radius accounting. The Gigawords counters exist just to solve that exact problem of the 4 Gig wraparound of 32 bit counters.


–Tom

I was wondering what they were for and what you say makes perfect sense. I’ll look at including them into my accounting as while it mainly deals with hotspot users, it can accomodate longterm PPP subscribers.

How do you put this in place? the radius updates from MT dont seem to use it looking at the packets

2.9.28 now includes support for those particular attribs:

added support for Recv-Limit-Gigawords and Xmit-Limit-Gigawords Radius attributes for hotspot

There are two counters, one that counts up to 4Gb, and another that counts those 4Gigs (how many times overflowed first counter). It’s hard to tell from your message whether you use the other counter or not. Some radius servers automatically support this, if you have to check whether yours does or not.

This is according to RFC. This is in the manual!

I am using freeradius and .28 and i’m not seeing MT use the gigawords attribute in the packets.

turn on radius debug logs on the router, and send us the log to see what radius packets the router is sending.

Why not just reboot the AC on a weekly basis, at 3:00am?
That would renew all pppoe sessions;
Andre

cos rebooting is a Microsoft solution, and thats not really a solution.

Are the gigawords only sent in RADIUS accounting messages once they exceed the 4gb wrap-around, you’ll then get a 1 gigaword + the remainder.

I use RADIUS & Mikrotik fine, and accounting works well beyond 4gb (this is with Radiator RADIUS)