Archive for the ‘Mikrotik RouterOS’ Category

RouterOS slow learning BGP routes with Winbox open

Thursday, April 28th, 2011

After banging my head against a wall waiting for a RouterOS powered router to re-learn the 330,000 routes that currently make up the global routing table, I was surprised to find that seemingly Winbox slows the learning of BGP routes to a crawl. Closing Winbox allowed the router to process the entire global routing table in the normal minute or so, including passing through some complex filters.

It would seem that in RouterOS 4.x at least, the router is pushing details of all learned routes to any Winbox clients connected and slowing itself to a crawl in the process. I haven’t had a chance to verify if this affects all versions of RouterOS 4.x yet or test it on RouterOS 5.x

Changing the MAC address of a VLAN interface in Mikrotik RouterOS

Saturday, July 3rd, 2010

Do you want to change the MAC address of a VLAN interface in Mikrotik RouterOS? Are you baffled by the fact that although the VLAN interface has a MAC address property inherited from the parent Ethernet interface, it isn’t editable?

Well, you’re in luck, it isn’t actually impossible to give your VLAN interface a different MAC address to it’s parent interface, you just have to go about it in a somewhat roundabout way by making what is effectively a virtual Ethernet interface and bridging it to the VLAN interface. You then add your layer 3 IP functions to the bridge interface instead of to the VLAN interface.

First, you need to create a bridge and give it a name, then add the VLAN interface who’s MAC address you want to change to the bridge as a port. Finally, set the “auto-mac” property on the bridge to “no” and then change “admin-mac” property for the bridge to be whatever you want your new MAC address to be

/interface bridge add name=newmac disabled=no auto-mac=no admin-mac=”00:00:00:00:00:00″
/interface bridge port add bridge=newmac interface=vlan1

RouterOS v4.x and BGP

Wednesday, January 20th, 2010

Just a quick heads up for those using upgrading from RouterOS 3.x to 4.x and using BGP to announce a default route to any of your peers; you need to set “default-originate” to “always” or “if-installed” for each peer you have configured in RouterOS if want to announce the default route to. This setting is off by default in v4.x so can cause havoc when you upgrade! 🙁

On the warpath

Sunday, August 3rd, 2008

Hey, guess what? In typical Edward style, it has been ages since I updated this thing and I still haven’t got the site working fully or using a custom skin. I have an excuse… I am busy/lazy (take your pick!) 😉

I got back from going to see “The Dark Night” a couple of hours ago. It’s a bloody good film but ‘m annoyed that I saw the plot twist coming right from the start – being a bit of a batman fan, I recognised the character as soon as a bloke called Harvey showed up with what correctly I guessed a double headed coin that he uses to “make his own luck” 😉

When I got back I set about unlocking Naomi’s old Sony Ericcson phone that she kindly gave me to replace my ageing Panasonic GD67 (circa 2003 and a hand me down via Matt) that does interesting things including randomly turning itself off.

6 weeks ago I requested a NUC (network unlock code) from Vodafone which they said would take between 5 days and 6 weeks to generate. So I patiently waited and when 6 weeks rolled around on Friday, I sent them a very angry e-mail telling them to pull their collective fingers out. This morning I got a reply telling me that they had generated a new code on the 24th of June (4 days after I had e-mailed them jumping through numerous hoops to prove that I hadn’t stolen the phone from Naomi) but that they “forgot” to e-mail it to me.

Incompetence or company policy not to co-operate with NUC requests? I’d go for the second one personally.

Phone unlocked, I set about learning how to use it and telling Naomi it was finally working. It seems quite nice but it’s such a change it’s going to take a lot of getting used to. At least it’s well built (unlike the Panasonic) and has fairly intuitive menus (unlike the Panasonic). It’s still not a patch on my 2G iPhone though 😉

My good mood was destroyed shortly after my unlocking success when I attempted to order a pair of power supplies from Rapid Electronics (you don’t get a link you bunch of incompetent tits!). My order was very simple, 2 power supplies delivered to one address but billed to another. Yet, despite providing a text field for your billing address, it’s not editable. At first I thought this was a browser issue so I changed from Safari to Firebox but still it didn’t work, They seem to want me to call their sales line for what is clearly a complicated procedure for them (instead of standard everywhere else) so instead I sent them an indignant e-mail telling them to learn how to build web-sites. I don’t expect that it will make the blindest bit of difference but it calmed me down somewhat.

If anyone from Rapid is reading this, the solution to your problem involves a 9mm bullet and the head of everyone in your web design department 😉

In an attempt to restore my mood (or possibly swing me ever deeper into a pit of despair) I set about the task of conducting a post-mortem on the two RouterBOARD 433AH boxes that were playing up when I tried to put them in Node4 almost a month ago.

At the time, one of the power supplies decided to fry itself and then the box running on the remaining power supply started behaving erratically. When setting it up I had been able to log into it fine but now my SSH session would hang as soon as the management shell spawned after authenticating.

Because of this we made the decision that we couldn’t trust any of the equipment and aborted the install until we had been able to examine what the problem was.

After about five minutes I managed to work out the really stupid and annoyingly simple reason for the SSH sessions hanging… there is an incompatibility between Mac OS X’s Terminal.app and the management shell in RouterOS version 3.x. The simple fix for this is to re-seize the Mac OS X terminal window as soon as you log in. This forces some kind of refresh which fires the RouterOS management shell back into life.

It seem that MikroTik have no intention of fixing this annoying bug and are blaming it on Apple instead 🙁

With that fixed (or at least explained), as soon a I can order some power supplies from a slightly more competent supplier than Rapid then maybe we can finally get this equipment installed.

One good thing did come out of the problems with the RouterBOARDs, I stumbled across the wiki page detailing the new support for Xen virtulization in RouterOS 3.11, a fantastic feature that I’ve been campaigning for for a long time but somehow missed the announcement for! I will have to have a play with it some time, but for now my bed beckons as tomorrow, more DIY awaits… 🙁