Recv-Limit, Xmit-Limit

RouterOS General
1

Lo all,

Just a couple of questions regarding the above…

Whilst the documentation does not show this (so I am guessing already I am out of luck), is there a way to get a “Combined-Limit” perhaps as a feature request for 2.9

Using the above attributes… What happens when either Recv-Limit or Xmit-Limit is reached? Are the user disconnected, or does the MT simply stop to Recv or Xmit additional traffic over the Interface?

Lastly, using FreeRadius and the various Counting modules in it, did anyone manage to get Recv-Limit & Xmit-Limit to operate successfully with FreeRadius and the SQLCounter modules?

2

Combined limit… jesus man.. just enter the Tx/Rx limits you want and be done with it… You can’t design software to please every whim of every user.

When either limit (tx/rx) is reached there is some sort of algorithm that backs the traffic down below the limits. I don’t know the specifics as its probably knowledge owned by MT and not for public knowledge. The user doesn’t notice any kind of service interruption it just slows their traffic down to the limits provided in the queue. It’s seamless to the end user.

I have not used RADIUS to set queues for users personally, but yes, it can be done.

Read read read the manual! :wink:

3

By now, I more than likely have the manual memorised.

I need a way to limit a interface to a maximum amount of data transfered (i.e., the user can only download 1GB). Then the user must be disconnected and the account be suspended. And this needs to happen in realtime…

Now, I can do the above based on Radius Accounting data, but the problem there is that the user’s traffic counts will only be calculated when they log in - hence, if the user is limited to 1GB he can very much download 15GB before he disconnects, and there is nothing the system can do to fix that (except fail the next login attempt). This will therefore not solve my problem, as there will already be 14GB of “unpaid” for traffic on t he system.

Thus, the only alternative is to limit the amount of traffic on the NAS (ala MT). From a Radius perspective, I can send the Recv-Limit and Xmit-Limit attributes with the correct values, without a problem. However, I need to know WHAT the MT does when this value is reached.

Even if MT just “slows down” the port as you stated below, what is the use of Recv-Limit and Xmit-Limit then if the user can go above the prescribed rates?

Just for the record, I am not talking SPEED here, I am talking about limiting the actual number of bytes received / transmitted over a Interface (more than likely PPTP Tunnels).

4

I’m sorry I must’ve miss interpretted what you wrote.. I thought you were talking about limiting bandwidth..

Not total data transfered.. This is done through AAA (Authentication Authorization and Accounting) and should be configurable on the RADIUS server.. I can’t give you the specifics on that, as I’ve yet to setup my own. But this can be done w/ MT.

5

Yeah, that’s what I thought :slight_smile:

Recv-Limit, Xmit-Limit (according to the manual) does limit the total number of bytes, whilst Rate-Limit limits the speed. So I do have the right attributes in question. It also doesn’t make my request for a Combined-Limit that insane does it?

Cmit, MT Guys, Anyone??? What happens… PLEASE tell me the port is disconnected when the limit is reached??? PLEASE :slight_smile:

6

Well… :wink:

I think you can’t EXACTLY achieve what you want, but “nearly” :wink:

The setup should be like this (rough plot):

Authentication/accounting via RADIUS server. Have a database on the RADIUS server where you store user accounts, their allowed traffic limit and a column for “traffic left this billing period”. Initialise the “traffic left” with “allowed traffic per billing period” (e.g. 1 GB).

When a users authenticates successfully, send Access-Accept attributes “Recv-Limit” and “Xmit-Limit” set to the “traffic left this period”. This will close the connection when either upload or download reaches the “traffic left” limit.

You have to execute a script on the RADIUS server each time a user logs out (this can be done with FreeRADIUS, for example). This script should subtract the accounted volume from the “left traffic” and store the new “left traffic” in your database. On the next login the user gets those limits as new “Recv-Limit” and “Xmit-Limit”.

The “fuzzy” part is that in theory (totally equal up- and download constantly) the users could use up twice their “left traffic” in the last connection. The problem is that there is no attribute “Traffic-Limit” or the like (which is available for the same principle based on online time - the attribute “Session-Timeout”) to limit the cumulated up- and download…

Hope I have been clear enough to describe the way to go. You can of course try to optimize the values you send as Recv-Limit and Xmit-Limit. For example (if you offer lower upload speed than download) you could set the Xmit-Limit to 30% of the “left traffic” and the Recv-Limit to the remaining 70% or whatever you come up with.
If you absolutely want to make sure nobody goes over the 1GB (or whatever) limit, you will have to set the attributes so that the sum of both is the users’ “left traffic”. But this will almost surely lead to the situation that a user can’t use all of his traffic in “one” connection, but would have to reconnect more often as he get nearer a zero in his “left traffic”…

7

Hi again :slight_smile:

Ok, well I’ve had a busy night… 10:30AM and I must still go to bed. I even stumbled on a small “bug” (if you can even call it that) in FreeRadius.

Basically, Recv-Limit and Xmit-Limit is what I want. I never doubted that to begin with. MT already use allot of “non-standard” attributes for their radius, this is why you MUST use their own dictionary with any radius server you operate. Thus, I still say that a ‘Total-Limit’ for combined up and down traffic is not something that is out of the question. It will DEFINATELY be a feature well worth the effort to code it.

As far as the situation goes… I’m not going to go into the technicalities TO much (it’s DAMM complicated). Basically, what I ended up doing was using the rlm_perl module on FreeRadius, and have it calculate the data used - data allowed. The difference, is what Recv-Limit and Xmit-Limit should be. Thus, I determine the correct values in real time, and pass the correct values on to the MT. The MT knows exactly when to disconnect the user, and thus no “traffic stealing” can take place.

This is a MAJOR thing to implement. At this stage, my rlm_perl script to handle the AAA seperately from FreeRadius is about 1,000 lines of pure perl, and I am JUST doing the Authentication section - haven’t even touched Accounting, Duplicate Users, etc etc etc. Once this is all finished and working, I’ll see and perhaps CONSIDER to donate it to MT for the hotspot manager or something to that effect. I’m sure there will be a definate need for it.

To overcome the “combined” traffic issue (untill MT gives me a Total-Traffic attribute :slight_smile:) I will be using some sort of algorythm similar to what you described yes. Total = (up + down)/2 and then work out the ratio between the tx/rx speed and the up/down bandwidth value. I think that’s pretty much the closest that I can get at this stage as far as a ‘real-time’ system goes. The ideal situation would be just to get the Attribute inside MT though :laughing: Sure, with the above people won’t be able to get “all” their bandwidth on the last session, but I think I should be able to get pretty close with the correct maths. Averages is something that comes to mind as well.

Thanks for all the help :slight_smile: You guys and allot of other guys in the world has been very helpfull to getting me to overcome a really big problem.

8

Righty. The saga semi continues :slight_smile:

Re the bandwidth split, a relatively easy way to do this (not 100% accurate though)

512/256k users per example:
512+256 = 768k in total

Recv-Limit = (TotalBandwidth - UsedBandwidth)/768256
Xmit-Limit = (Totalbandwidth - UsedBandwidth)/768512

The sum of Recv-Limit and Xmit-Limit will never be higher than TotalBandwidth - UsedBandwidth, so I should be in the clear.

Now, on to the next issue. I am using MT 2.8.24 for my test / development NAS. For some reason, the MT sends Accounting-Stop requests twice to the Radius server… Can anyone allaborate why?

rad_recv: Accounting-Request packet from host 192.168.1.254:1028, id=98, length=275
        Service-Type = Framed-User
        Framed-Protocol = PPP
        NAS-Identifier = "nas.domain.com"
        NAS-Port = 51
        NAS-Port-Type = Virtual
        User-Name = "testy@prepaid.domain.com"
        Calling-Station-Id = "192.168.1.10"
        Called-Station-Id = "192.168.1.254"
        MS-CHAP-Domain = "prepaid.domain.com"
        Acct-Session-Id = "8100001c"
        Framed-IP-Address = 198.18.1.212
        Acct-Authentic = RADIUS
        Acct-Session-Time = 5
        Acct-Input-Octets = 5265
        Acct-Input-Packets = 27
        Acct-Output-Octets = 110
        Acct-Output-Packets = 9
        Acct-Status-Type = Stop
        Acct-Terminate-Cause = User-Request
        NAS-IP-Address = 192.168.1.254
        Acct-Delay-Time = 0
        Mikrotik-Attr-9 = 0x707265706169642e63656e657267796e6574776f726b732e636f6d
  Processing the preacct section of radiusd.conf

rad_recv: Accounting-Request packet from host 192.168.1.254:1028, id=98, length=275
        Service-Type = Framed-User
        Framed-Protocol = PPP
        NAS-Identifier = "nas.domain.com"
        NAS-Port = 51
        NAS-Port-Type = Virtual
        User-Name = "testy@prepaid.domain.com"
        Calling-Station-Id = "192.168.1.10"
        Called-Station-Id = "192.168.1.254"
        MS-CHAP-Domain = "prepaid.domain.com"
        Acct-Session-Id = "8100001c"
        Framed-IP-Address = 198.18.1.212
        Acct-Authentic = RADIUS
        Acct-Session-Time = 5
        Acct-Input-Octets = 5265
        Acct-Input-Packets = 27
        Acct-Output-Octets = 110
        Acct-Output-Packets = 9
        Acct-Status-Type = Stop
        Acct-Terminate-Cause = User-Request
        NAS-IP-Address = 192.168.1.254
        Acct-Delay-Time = 16777216
        Mikrotik-Attr-9 = 0x707265706169642e63656e657267796e6574776f726b732e636f6d
  Processing the preacct section of radiusd.conf

The only difference between the packets, is the Acct-Delay-Time. I am currently looking to see what the relavence of this Attribute is, but why does MT send it twice? Because I receive the Accounting Stop request twice, this means that I will subtract the used bandwidth in the terminated session twice - and thus, it is not the desired result.

At the moment, I am using Acct-Delay-Time = 0 as a parser to only process the first Accounting-Stop request, but I am not sure whether or not this will 1) be accurate, and 2) whether Acct-Delay-Time will always be 0 for the first of the two requests…

Can anyone perhaps give some info again? I’m pretty sure this is not a Radius issue, it is the actual MT sending the Accounting Stop request twice (two actual packets), thus there is not allot on the Radius side I can do to fix this.

Thanks everyone :wink:

9

Probably the “got it” answer from your RADIUS to MikroTik (acknowledgement that Accounting-Packet was successfully received) arrives too late, so MikroTik sends it again…

Regarding handling of those duplicates: You should use the Acct-Session-Id, which is a unique id for each session (and therefore is the same for your two duplicate Stop packets). Using this you can absolutely be sure if two stop packet belong to the same session or not.