Category Archives: software

Quick Set Preview

Just a couple of quick screen shots of the new “Quick Set” mode available in some of the newest releases.

As you can see the dropdown box top left lets you select the mode for the device and puts all the basic configuration options in one place.

AP mode:

 

And CPE mode:

The addition of a signal strength graph over time is nice and handy for keeping track of the nearby networks you’re going to borrow internet from  check connections for when testing this out.

 

We mentioned this earlier in thebrotherswisp podcast if you missed it, looks like it’s going to make the entry level setup a whole lot easier for those new to MikroTik.

Installing ntop on CentOS 6/Redhat with NetFlow

MikroTik supports exporting NetFlow traffic data via /ip traffic-flow, which can be read using free or paid software.
This guide shows you how to setup ntop (a free option) on a fresh CentOS 6 (or RedHat) install and assumes you have setup a CentOS 6 server that has a connection to the internet.

Continue reading Installing ntop on CentOS 6/Redhat with NetFlow

Queue outside please!

New toys you say?

More gadgets Q?

 

Noticed this little gem in the MikroTik wiki this morning while reviewing Queue Types.

Note: Starting from v5.8 there is new kind none and new default queue only-hardware-queue. All RouterBOARDS will have this new queue type set as default interface queue

only-hardware-queue leaves interface with only hw transmit descriptor ring buffer which acts as a queue in itself. Usually at least 100 packets can be queued for transmit in transmit descriptor ring buffer. Transmit descriptor ring buffer size and the amount of packets that can be queued in it varies for different types of ethernet MACs.

Having no software queue is especially beneficial on SMP systems because it removes the requirement to synchronize access to it from different cpus/cores which is expensive.

multi-queue-ethernet-default can be beneficial on SMP systems with ethernet interfaces that have support for multiple transmit queues and have a linux driver support for multiple transmit queues. By having one software queue for each hardware queue there might be less time spent for synchronizing access to them.

Note: having possibility to set only-hardware-queue requires support in ethernet driver so it is available only for some ethernet interfaces mostly found on RBs.

Note: improvement from only-hardware-queue and multi-queue-ethernet-default is present only when there is no “/queue tree” entry with paticular interface as a parent.

What does this mean in laymans terms?

1. The only-hardware-queue will be available initially only for Routerboard devices and perhaps some other supported ethernet chipsets in the future.

2. The basic interface queueing is removed from being passed to the CPU and done on the interface hardware directly which should result in a net performance increase.

3. For SMP (x86 boxes with multiple CPU cores) machines with high end interfaces (1GB, 10GB) there is a queue type that allows a queue to be broken up across multiple CPU cores to match the multiple TX and RX chains offered on these interfaces.

Bridging ESX Virtual Switch Networks using MikroTik and EoIP/Vlan/VPLS

This is a bit of a different post based on some configuration I did just recently to enable the bridging of a Virtual Switch between 2 ESX hosts.

There is an VMWare option for this called a “VMware vSphere Distributed Switch” however this requires one of the higher end licencing packages so isn’t available on the free or basic packages, but there are many different uses you might have for this,  from simply creating a temporary bridge while you migrate servers to a remote host, or in my case, creating a bridge network across 2 hosts that use a RouterOS vm as the gateway/firewall for the servers. Continue reading Bridging ESX Virtual Switch Networks using MikroTik and EoIP/Vlan/VPLS

Welcome to the jungle, mind all the bugs.

After discussion on the unofficial MikroTik mailing list, I’ve decided to create a bugtracker for helping keep a list of known outstanding MikroTik bugs.

I would’ve hoped that MikroTik could do something like this themselves to help out those of us relying day to day on the ability to keep a network running, however until such time I feel I (as well as others) am forced to take these alternative measures.

Those of you who are interested in contributing are welcome to join and/or follow at http://bugs.mikrotik-routeros.com

I’ve included a basic guide to using the bugtracker here: http://www.mikrotik-routeros.com/?page_id=228

Please feel free to comment and make suggestions.