Google Compute Engine

RouterOS Virtualization
1

I tried running CHR on Google Compute Engine however it does nothing. Are all the required drivers included in CHR?. The instance does start, and transition to the “running” state, however CHR doesn’t seem to output to the serial console so there’s no indication beyond “Booting from Hard Disk 0…”. The CPU utilization stays at 100%, network packets are received but none are transmitted.

Is there anything else I can do?

2

How did you build your image? Here are the requirements for a GCE image.

I am thinking of trying one of these soon, so I’m interested in how yours turns out.

3

How did you build your image?

These are the detailed steps to reproduce what I did:

  1. Download the raw disk image archive from Mikrotik
    wget http://download2.mikrotik.com/routeros/6.37.2/chr-6.37.2.img.zip
  2. Unzip the archive
    unzip chr-6.37.2.img
  3. Expand the image size to 1GB
    truncate --size=1G chr-6.37.2.img
  4. Create the image archive for Google GCE
    mv chr-6.37.2.img disk.raw
    tar -Sczf chr-6.37.2-image.tar.gz disk.raw
  5. Create a bucket to store image archives
    gsutil mb gs://cloud-hosted-router-images
  6. Copy the new image to the bucket
    gsutil cp chr-6.37.2-image.tar.gz gs://cloud-hosted-router-images
  7. Create an image for GCE from the archive
    gcloud compute images create “chr-6-37-2”
    –family=cloud-hosted-router
    –description “Mikrotik Cloud Hosted Router (CHR) is a RouterOS version intended for running as a virtual machine.”
    –source-uri “https://storage.googleapis.com/cloud-hosted-router-images/chr-6.37.2-image.tar.gz”
  8. Create an instance
    gcloud compute instances create “chr-1”
    –zone “us-central1-c”
    –machine-type “f1-micro”
    –image-family=cloud-hosted-router

The result is a “running” (as reported in the console) instance however it outputs nothing to the serial console (beyond GCE’s “Booting from Hard Disk 0…”) and does not respond to anything on the network interface (console reports incoming packets but 0 outgoing).

4

CHR on Google Cloud needs some love from our devs to work.

5

We would love to see it.

6

Sadly, this will become reality only with the release of RouterOS v7.x

Current kernel does not have a version of the VirtIO that is required to run on the Google infrastructure.

7

Is there any timeline for RouterOS v7.x?

8

Nope

9

In step 6. Exit next error

Copying file://chr-6.37.2-image.tar.gz [Content-Type=application/x-tar]…
ResumableUploadAbortException: 403 Caller does not have storage.objects.create access to bucket cloud-hosted-router-images.

Help please .. I’m new to the topic

10
11

There will be some way to install mikrotik on google :confused: :open_mouth:

12

We need newer kernel - so v7, sorry. Without the kernel, we do not have critical KVM/VirtIO stuff required for the Google service. As that code that we needed to backport relies on features available in the newer kernel.

13

Hi,

Any update about this? i really need this to work.

Thank You

14

There are several answers in this topic. They are all the same. Until RouterOS v7 exists, there can be no support for this. Since there is no v7, there are no updates on this.

15

Well, v6.42rc30 is out there, let’s continue :slight_smile:

Have anyone had a luck to run RouterOS smoothly? I had to decrease MTU of ether1 to 1460 to be able to connect to the router (on 1500, both SSH and WinBox hang when big packets go over the connection).

UPD: Googled for this post from Paul Nash (Product Manager, GCE, Google) on November 14, 2016: “The 1460 MTU is configured due to additional header space required inside Google’s network. It is a difficult thing to change, but something that we’re looking at.”

So, seems like you must set MTU to 1460…

16

Works fine, we even wrote a manual:
https://wiki.mikrotik.com/wiki/Manual:CHR_GCE

17

Yep, I deployed it by that manual, but couldn’t connect (SSH hung after showing ‘MikroTik’ logo, WinBox hung on ‘Downloading plugins’) until I lowered MTU to 1460. I checked another VM (Linux one), it has 1460 too, so looks like that’s normal practice for GCP.

18

We didn’t lower the MTU and it worked fine here. I can add it to the manual as optional step.

19

Yep, packets should be defragmented, but it wasn’t working for me. Anyway, I think it’s better to lower the MTU to avoid unnecessary fragmentation even if it’s working in some cases.

And concerning 1360: it’s about the traffic inside IPSec tunnel (in case of VPN), so for pure router 1460 should be good enough.