The following is a short but useful script which allows your system note to output recent info regarding router health and/or other details you might be interested in.
Special thanks to Werner Venter for showing me the ‘Cool Console‘ script which was modified and extended upon for this post.
IPv6 prefix delegation support comes to PPPoE in RouterOS version v5.10* so for those of you ready to jump onboard this release, here’s my attempt at a best-practice way to set it all up.
IPv6 has been around in RouterOS for a while now, but the specific feature that was introduced is called “DHCPv6 Prefix Delegation” which allows RouterOS to receive a prefix (or a bunch of framed routes if you’re more familiar with that terminology) that it can then distribute out itself.
This means for someone like myself, using IPv6 with my local Internet Service Provider becomes relatively straightforward, with no more need for tunneled IPv6 connections. Continue reading IPv6 over PPPoE – RouterOS v5.10
A quick scriptlet I whipped up for a friend tonight to allow them to retrieve an IP addess from a specific PPPoE interface.
Handy for updating DynDNS entries among other things.
:local wanip [/ip address get [/ip address find where interface=pppoe-wan] address]; :set wanip [:pick $wanip 0 ([:len $wanip]-3) ]; #whatever you want to do with said IP goes here :put $wanip;
Obviously update pppoe-wan with your interface name 😉
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.