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 !
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/gu ... t#13.4.5.1
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/gu ... t#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:
Then add the following attributes in the Freeradius MySQL table 'radgroupreply'
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:
Bingo! No more weird stuff happening with radius accounting.
We use Freeradius with MySQL. To enable the Xmit-Limit and Recv-Limit attributes we had to add this to the freeradius config file:
Code: Select all
# MikroTik Attributes
VENDOR Mikrotik 14988
ATTRIBUTE Recv-Limit 1 integer Mikrotik
ATTRIBUTE Xmit-Limit 2 integer MikrotikCode: Select all
Xmit-Limit == 4000000000
Recv-Limit == 4000000000Code: Select all
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
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
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.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
How do you put this in place? the radius updates from MT dont seem to use it looking at the packetsThe 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
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!
This is according to RFC. This is in the manual!
Last edited by normis on Wed Aug 16, 2006 3:08 pm, edited 1 time in total.
-
-
agirardeau
just joined
- Posts: 4
- Joined:
keep it simple
Why not just reboot the AC on a weekly basis, at 3:00am?
That would renew all pppoe sessions;
Andre
That would renew all pppoe sessions;
Andre
-
-
joeyconcrete
just joined
- Posts: 14
- Joined:
- Location: Isle of Man, UK