All posts by Omega-00

Adding automatic rate limits to user-manager accounts.

This has been mentioned and posted in a couple of places now however I’d like to post a copy here also in the event that anyone else has further suggestions on improvements for the script, or any further questions.

Although I don’t use it much myself, many Mikrotik users would be familiar with the “user-manager” package built by mikrotik as an “all-in-one” hotspot solution for small-medium installs.

Many of the functions in this are automated, however not the addition of per-account rate limits, which would normally be based on the package purchased. Instead most sites opt to use a preset speed value on a per router basis. An alternative option to this would be to put different users in different IP pools and setup a rate-limited queue tree based on that.

I was requested to build a script for use on the main user-manager mikrotik, that would allow accounts to be assigned a rate limit based on the package someone had purchased. Once set, this speed value remains the same.

Although this is sounds like quite a simple task, there’s a lot of work saved in having something like this automated, leaving you to get back to running day to day tasks rather than having to either limit all users to the same speed or worse, keep one eye on your user list to catch any newly created accounts!

With that I mind I wrote the following basic script to allow newly created accounts to be assigned a rate-limit based on the package they purchased.

You can modify the values to match your own options and rework this to your liking.

In this example you can see that, if I user purchased a $30 package (credit-price=30000) they would be assigned a rate limit of 512k/128k, whereas a $90 purchase would get a 2M/128k limit.

#Script to add rate limit's to newly created user-manager accounts.
#Written by Andrew Cox | Omega-00 | http://www.mikrotik-routeros.com

:local counter
:local check

#Loop through all users in user-manager
:foreach counter in=[/tool user-manager user find] do={

#Check to see if comment contains "RLA" (short for 'rate limit added'). If it doesn't, this account hasn't had a rate limit set yet.
#We only check the first 3 characters, this means you can continue to use the comment field for whatever you like so long as you leave the 'RLA' untouched (if present)
:set check [:pick [/tool user-manager user get $counter value=comment] 0 3]
:if ($check="RLA") do={

#Has RLA, rate limit is already set so ignore

} else={

#Doesn't have RLA Set rate-limit based on initial purchase pricing
:if ([/tool user-manager user get $counter credit-price] ="30000") do={/tool user-manager user set $counter rate-limit="512k/128k" comment="RLA"}
:if ([/tool user-manager user get $counter credit-price] ="60000") do={/tool user-manager user set $counter rate-limit="1M/128k" comment="RLA"}
:if ([/tool user-manager user get $counter credit-price] ="90000") do={/tool user-manager user set $counter rate-limit="2M/128k" comment="RLA"}
}  }

Simple RouterOS http load/bandwidth tester

Disclaimer: I am not responsible for what you choose to do with this script and/or what damage you incur. It uses features of RouterOS in ways I have to assume they were not intended so user beware.

I wrote a little script today that allows very simple load/bandwidth testing.

Some suggested uses:
– basic testing of apache http servers on a VPS
– bandwidth testing when you’re not onsite and don’t have a remote mikrotik with enough bandwidth test to.

I recommend you don’t exceed 500 iterations on an RB1000 however if you’re using it for a bandwidth test then you should only need 4 threads or so.

If you do exceed this number, or manage to crash the console anyway,  login via winbox and run the clear script a couple of times to remove the created scheduler entries.

Server is the server you wish to connect and
File is the file you wish to download (this is not saved).
Time is how long you want to run the test for (so you can see the average bandwidth or monitor the server you’re checking against).

For example: http://www.example.tld

Server would be www.example.tld

File would be index.php or index.html or index.asp etc etc

For a bandwidth test you’d do better to look around for a reasonably sized file you can download (a linux iso on an ISP mirror would work).

#HTTP testing implementation v3
#Written By Omega-00 - December 2010

#user editable values
:local server "server.tld"
:local file "index.php"
#Recommend not running any more than 500 for RB1000/1100/800
:local iterations 500
#amount of time to run script for in seconds
:local time 60

### End of user editable values ###
:local counter

:for counter from=1 to=$iterations do={
/system scheduler add interval=1s start-time=startup name="load-test-$counter" on-event="/tool fetch keep-result=no mode=http address=$server host=$server src-path=\"$file\"; /tool fetch keep-result=no mode=http address=$server host=$server src-path=\"$file\";"
}

#wait $time seconds for threads to run
:delay $time
:foreach counter in=[/system scheduler find] do={
:if ([:find [/system scheduler get $counter name] "load-test-"] !="") do={/system scheduler remove $counter}
}

And a cleanup script in case you crash the console from setting the iterations value too high.

#Script for clearing entries in the event of script crash 

:foreach counter in=[/system scheduler find] do={
:if ([:find [/system scheduler get $counter name] "load-test-"] !="") do={/system scheduler remove $counter}
}

If there’s interest in this I might make another version of the script that can spider through a website and load multiple pages at once (increasing the effectiveness of using this as a server load tester and avoiding caching from the host machine).

Update: Version 4 of the script (uses :execute command instead of scheduler to run parallel processes)

#HTTP testing implementation v4
#Written By Omega-00 - Jan 2011

#user editable values

#Recommend not running any more than 500 for RB1000/1100/800
:local iterations 500

:local runcmd "/tool fetch keep-result=no url=\"http://example.tld/index.php\""
:local time "60"

### End of user editable values ###
:local counter
:local counter2

:log info "Run Command: $runcmd"

:for counter2 from=1 to=$time do={
:for counter from=1 to=$iterations do={
:execute $runcmd
}
:delay 1
}

Bug spotting – PPPoE and Hotspot

Came across an interesting (yet to be verified) bug today.

The info:

RouterOS v4.10 running on x86 server

Site runs both a hotspot and PPPoE server on the same interface.

Users can decide to login via the captive portal (which most do) or for those who understand and wish to use a pppoe connection, they have the option to use that instead, as it comes with a public IP.

The problem:

Support call came in saying that a user was unable to access www.google.com (which for the sake of this example we’ll say resolves to 192.0.2.1). I checked and confirmed I could indeed ping and trace to the address and put it down to a user issue, but left the ticket open to have one of our on-site techs give a try.

— later on–

Onsite tech indicated he to had become unable to access www.google.com via the pppoe login option and after getting a first hop response from the gateway the connection simply timed out.

The cause:

I’ll save you from having to hear about everything I tested and tried over the next hour however the actual cause was rather interesting.

The “hosts list” on the hotspot, had old entries from someone with an improperly configured IP address (in this case 192.0.2.1) which had tried to access the login page sometime in the past couple of days and was being held there. This meant that for users connected behind the pppoe interfaces, traffic to 192.0.2.1 was trying to go to that host RATHER than going out the correct default route.

Why? No idea.

The solution:

When the hotspot was setup (we’d reinstalled the machine just recently) it appears someone had forgotten to set the ‘idle-timeout’ value on the hotspot user-profile. This meant all these hosts were being held and the table was getting larger and larger (there were other incorrect addresses in there too).

Better solution: Provided by Mikrotik support
You have an option to allow only specific subnet to reach the HotSpot network.
Add the to ip-binding, specify subnets you would like to allow and set type=regular.
Block any other unneeded subnet by type=blocked.

Eg:

/ip hotspot ip-binding
add address=10.10.40.0/21 comment="Accept (not bypass) anything in the LAN range" disabled=no
add address=0.0.0.0/0 comment="block all else" disabled=no type=blocked

Side note: We don’t use the address-pool option on the hotspots as this causes LAN traffic to pass back (and be counted by) the router which we don’t want (as we let our users have unlimited LAN access to each other) so I’m at quite a loss as to why this routing pattern would occur.

MUM 2010 – Phoenix

For those of you who missed it, the most recent Mikrotik User Meeting (MUM) was on just a few days ago in the USA.

Videos of the presentations (which are all very interesting) are available on tiktube and I would highly recommend you check out Greg Sowell‘s presentation on Troubleshooting.

http://tiktube.com/?video=369

Greg has also just finished his Mikrotik Certified Trainer course so will be running http://mikrotikuniversity.com for those of you who would like to sharpen your mikrotik skills.

Other interesting things to come out of the conference include:

More IPv6 support (yay!)

Support for Cisco compatible GRE tunnels

Support for using a fully qualified domain name for IPSEC tunnels (removing the need for something like this: http://www.mikrotik-routeros.com/?p=29)

New hardware:

RB493G (Gigabit ports)

New Software:

Something I’ll post on more fully when I’ve seen the finished product: Flashfig, an app for installing configs on multiple routers (useful for cpe’s) simultaneously.

There’s some documentation on it already available here for now: http://wiki.mikrotik.com/wiki/Flashfig

IPv6 and Mikrotik – Using 6to4

Please note this guide assumes some basic knowledge of IPv4 and IPv6 address space.

Many of you may know of the impending doom that surrounds the IPv4 network and lack of remaining IP ranges.

The question is, how many people are actually doing anything about it? Given the slow take up worldwide I thought it worthwhile I do a post here to explain how you can get IPv6 on your network now.
No support required from your upstream ISP and without having to send your traffic half way around the world to a Hurricane Electric tunnel (hopefully).

So, what is 6to4?

From: http://en.wikipedia.org/wiki/6to4

6to4 is an Internet transition mechanism for migrating from IPv4 to IPv6, a system that allows IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 internet) without the need to configure explicit tunnels. Special relay servers are also in place that allow 6to4 networks to communicate with native IPv6 networks.
6to4 is especially relevant during the initial phases of deployment to full, native IPv6 connectivity, since IPv6 is not required on nodes between the host and the destination. However, it is intended only as transition mechanism and is not meant to be used permanently.

Continue reading IPv6 and Mikrotik – Using 6to4