Change MikroTik RouterOS queue type

Create a new queue type

/queue type add name=fq-codel-ethernet-default kind=fq-codel fq-codel-ecn=no

Change the queue type of all wired interfaces

/queue interface set [find default-queue=only-hardware-queue] queue=fq-codel-ethernet-default

Verify the queue type was changed

/queue/interface/print where default-queue=only-hardware-queue

Wireless interfaces defaults to wireless-default and virtual interfaces defaults to `no-queue. These interface queues can be confirmed with.

/queue/interface/print where default-queue!=only-hardware-queue

Sources: [1]

Install ifupdown2 on Debian

Install ifupdown2 from proxmox no-subscription repository for Debian 64bit

apt install --yes lsb-release wget curl

wget$(lsb_release -sc).gpg --output-document=/etc/apt/trusted.gpg.d/proxmox-release-$(lsb_release -sc).gpg

echo "deb [arch=amd64 signedby=/etc/apt/trusted.gpg.d/proxmox-release-$(lsb_release -sc).gpg] $(lsb_release -sc) pve-no-subscription" > /etc/apt/sources.list.d/pve.list

echo "Package: *\nPin: origin \"\"\nPin-Priority: 50\n\nPackage: ifupdown2\nPin: origin \"\"\nPin-Priority: 500" > /etc/apt/preferences.d/pve

apt update

apt list --upgradeable

apt install --yes ethtool bridge-utils python3-mako ifupdown2

RouterOS Script: Check Google Global Cache Cluster

Open the built-in editor

/system/script/edit value-name=source check-ggc-cluster

Paste the script content

:global currentGGCcluster;

:local result;
:local data;
:local newGGCcluster;

:set result [/tool/fetch output=user url="" as-value ascii=yes];
:set data [:tostr [:pick $result [:find $result "="] [:find $result ";"]]];
:set newGGCcluster [:tostr [:pick $data ([:find $data ">"] + 2) [:len $data]]];

:if ($newGGCcluster != $currentGGCcluster) do={
    :put "SP GGC Cluster $currentGGCcluster changed to $newGGCcluster";
    :set currentGGCcluster $newGGCcluster;
    /log info "SP GGC Cluster $currentGGCcluster changed to $newGGCcluster";

Add the scheduler (policy not restricted, probably should be)

/system/scheduler/add interval=1d name=check-ggc-cluster on-event="/system/script/run check-ggc-cluster;" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

Check variable contents

/system/script/environment/print detail where name=currentGGCcluster

Add Danish NemID X.509 public certificate to RIPE Database


If you ever used the RIPE Database.

You know the following RIPE Maintainer Authentication methods is possible.

  1. SSO (a.k.a. single sign on)
  2. key-cert (GnuPG keys + X.509 certificate)
  3. MD5 encrypted passwords


  1. IF you have the danish NemID follow the guidelines here to configure NemID on your computer. And then for you email program.
  2. Go find your public certificate here and download it.
  3. Open the certificate locally on your computer and prepend every line with ‘certif: ‘ so it looks the example below. Remember the key-value pairs:
    • key-cert: auto
    • mnt-by: xyz
    • source: ripe


  • from older RIPE documentation.
key-cert: AUTO-1
certif: -----BEGIN CERTIFICATE-----
certif: Ew91ay5idC50ZXN0LXVzZXIxLzAtBgkqhkiG9w0BCQEWIHRlc3QtdXNlckBsaW51
certif: AQEArv3srxyl1QA3uS4dxdZbSsGrfBrMRjMb81Gnx0nqa6i+RziIf13lszB/EYy0
certif: PgLpQFdGLdhUQ52YsiGOUmMtnaWNHnEJrBUc8/fdnA6GVdfF8AEw1PTfJ6t2Cdc9
certif: 2SwaF+5kCaUDwmlOgbM333IQmU03l3I1ILs32RpQyZ+df/ovHNrVzeLc2P59isac
certif: bfjM2S0SXPQzHjuVLH40eOgVuXA/5LAYs51eXqwtKszSxFhqekf+BAEcRDrXmIT4
certif: e3zfiZOsXKe0UfaEABgHUMrYjsUCJ8NTMg6XiVSNwQQmXCdUbRvK7zOCe2iCX15y
certif: IE5DQyBDQTAdBgNVHQ4EFgQUzdajNaRorkDTAW5O6Hpa3z9pP3AwgZsGA1UdIwSB
certif: d2FyZSBQS0kgVGVzdGluZzEfMB0GCSqGSIb3DQEJARYQc29mdGllc0ByaXBlLm5l
certif: dIIBADANBgkqhkiG9w0BAQQFAAOBgQByg8L8RaiIz5k7n5jVwM/0oHSf48KRMBdn
certif: YdN2+eoEjVQbz48NtjbBTsOiUYj5AQWRHJrKtDQ+odbog0x7UsvhXjjBo/abJ6vI
certif: AupjnxP3KpSe73zmBUiMU8mvXLibPP1xuI2FPM70Y7fgeUehbmT7wdgqs7TEtYww
certif: PeUqjPPTZg==
certif: -----END CERTIFICATE-----
mnt-by: YOUR-MNT
source: RIPE

Afterwards you should be able to sign emails send to “RIPE Database” <> with your NemID certificate and the updates gets approved if your maintainer has authorization over the object you try to create/modify/delete.


My X.509 certificate

How-to VPN: Private Internet Access (PIA) and MikroTik Router

⚠ Information in this post is outdated since the launch of PIA’s ‘Next-Gen’ VPN network in 2020, sunsetting the then-existing set-up

First create a vpn profile to use when creating l2tp/pptp connections
to privateinternetaccess.

/ppp profile add change-tcp-mss=yes \
comment="PIA VPN" \
dns-server=, \
name=privateinternetaccess only-one=no \
use-compression=no use-encryption=required \
use-ipv6=no use-mpls=no use-upnp=no

Create the l2tp interface

/interface l2tp-client add \
comment="PIA VPN Netherlands" \ \
disabled=no name=pia-de-l2tp \
profile=privateinternetaccess \
user=[l2tp-username] \
  • [l2tp-username] Your PIA username for l2tp/pptp/socks connections beginning with ‘x’ (not ‘p’!)
  • [l2tp-password] Your PIA password for l2tp/pptp/socks connections

Create a firewall mangle rule to mark IPv4 traffic we want to
go through the VPN.

/ip firewall mangle add \
action=mark-routing \
chain=prerouting \
comment="PIA VPN Netherlands" \
new-routing-mark="PPTP RM" \
passthrough=yes \
    • <li


    Fx. or

Create the NAT rule and tell it to use the VPN interface.

/ip firewall nat add \
action=masquerade chain=srcnat \
comment="PIA VPN Netherlands" \

Create a corresponding default route to match the previous NAT
rule. Which only get used when IPv4 traffic has been marked with

/ip route add \
comment="PIA VPN Netherlands" \
disabled=yes distance=1 \
gateway=pia-de-l2tp routing-mark="PPTP RM"

Now you should see traffic from clients in the IPv4 range
of [ip-range-to-forward-through-vpn] go through the VPN.

NB: If you want to use another country apart from Netherlands. Check out Private Internet Access list of locations here: PIA VPN Tunnel Network

Git Rebase Interactive

Being new to git. You will inadvertently struggle.

  1. Having opened a pull request (PR), leaving the PR hanging for a while, picking it up Y time later, with several changes have happened in the upstream branch. You will often find yourself in need of using git rebase upstream/master ((
  2. After having rebased recent commits upon the upstream/master branch. You might want to squash your commits together, to create a cleaner pull request, and to avoid (un)intentionally blotting the git-history with miscellaneous commits, imagine:
    $ git log --graph --pretty=format:'%Cred%h%Creset %s'
    * 77464f9 Update 'filename1.txt'
    * 2a7894b Update 'File 2.txt'
    * 27a44c6 Add 'File 2.txt'
    * 4bc179b Add 'filename1.txt'
    * 8757b20 Initial commit

    Can be reduced

    pick  = use commit
    reword  = use commit, but edit the commit message
    edit  = use commit, but stop for amending
    squash  = use commit, but meld into previous commit
    fixup  = like "squash", but discard this commit's log message
    break = stop here (continue rebase later with 'git rebase --continue')
    drop  = remove commit
    $ git rebase --interactive 8757b20
    reword 4bc179b Add 'filename1.txt'
    fixup 27a44c6 Add 'File 2.txt'
    fixup 2a7894b Update 'File 2.txt'
    fixup 77464f9 Update 'filename1.txt'
    $ git log --graph --pretty=format:'%Cred%h%Creset %s'
    * 255c889 Add 'filename1.txt', and 'File 2.txt'
    * 8757b20 Initial commit
  3. If in need of deciding which commit to squash together, and were to edit the commit message. Using git rebase --interactive (commit-hash, remote-name/branch-name, or branch-name) is the lifeline.

Remember, the commit hash will change when using git rebase action. Force pushing to the remote branch to replace its contents is necessary.
git push remote-name local-branch-name:remote-branch-name --force
(e.g. git push origin master-squashed-commits:master --force).

But this approach is the recommended way in regards to using git pull-requests. Any existing pull-requests against a branch you have on your fork of the upstream repository. Will automatically use the latest available information in your fork’s branch.