Tag Archives: routing

CloudCoreRouter and RouterOS v6.x (linked post)

Janis M. from MikroTik was kind enough to point me to a copy of his presentation from the Russian MUM which I feel is an incredible helpful document and well worth a read by all of the current CCR users out there.

I would highly encourage anyone running (or thinking of running) CCR’s on their network to review this document, which both explains both the current workings and limitations of the CCR series and v6 or RouterOS as well as discussing what changes will be made in v7

The Tiktube video for the presentation isn’t up just yet but I’ll come back and add it when it has been uploaded by MikroTik.

Some of the most useful points cover:

  • multi-core packet processing (how packets coming into the router are handled across the 16 or 36 cores available)
  • best-practise for queue tree setups
  • pptp/lt2p/pppoe changes for packet handling
  • best-practise for processing packets on the firewall (this is reiterating old instructions, but still holds true for v6)
  • why layer-7 is the last thing you should be using when tagging packets
  • how bgp is currently single-core in v6 and how routing protocols are changing in v7

Hopefully this is enough to catch your attention, now go get reading!

CloudCoreRouter and RouterOS v6.x – Tips and Tricks (Moscow MUM Russia 2014)

Study guide: Moving up to RouterOS v6

Given v6.0 stable is now upon us I’ve taken some time to collate some of the posts I’ve been familiarising myself with over the last few weeks to understand the major changes that have been implemented in this release and how to best upgrade and make use of these.

ros-v6

I’ve tagged some videos and forum posts below with topics breakdowns for ease of review

Continue reading Study guide: Moving up to RouterOS v6

Improved Netwatch-style script.

There have been a number of improved netwatch scripts listed on the mikrotik wiki in the past however many of these are hard to understand, broken or both.

I had a request from an associate to assist them finding a solution to fall over VPN traffic from one link to another in the event of an outage; in a network configuration where it wasn’t possible to use the local upstream router as an indication of the VPNs status, so I took the opportunity to revise a netwatch script based loosely on the one located here: http://wiki.mikrotik.com/wiki/Improved_Netwatch_II

My rewrite of this allows both the “up” and “down” scripts to be called from the same place (preferably a scheduler entry) and to be extra nice I’ve commented the whole script so you’re all welcome to modify as you see fit.

Continue reading Improved Netwatch-style script.

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.

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