Routeros 7 long term когда выйдет

Sysadminium

Из этой статьи вы узнаете как правильно выполнять обновление и даунгрейдинг RouterOS на роутерах MikroTik, а также разберём ветки релизов.

Оглавление скрыть

Ветки обновлений RouterOS

Для начала разберёмся с ветками обновлений операционной системы RouterOS, их 4 штуки:

Development. В этой ветке релизы выпускается по мере необходимости. Релизы содержат непротестированные изменения. Эта ветка подойдёт только для тех, кто готов протестировать новые функции.
Testing. Здесь релизы выпускается каждые несколько недель. Они проходят только базовое тестирование, и не должны применяться в продакшене.
Stable. Эта ветка содержит протестированные релизы, которые выпускается каждые несколько месяцев. Эти релизы содержат как исправления ошибок, так и новые функции.
Long term. В этой ветке релизы выпускаются редко и включают только самые критичные исправления. При этом обновления в рамках ветки с одним номером (6.48, 6.48.1, 6.48.2, 6.48.X) не содержат новых функций. Когда Stable релиз выходит уже некоторое время и кажется достаточно стабильным, он переводится в Long term, заменяя более старый релиз, который перемещается в архив.

Теперь разберём как версии RouterOS выпускаются и переходят с ветки на ветку. Допустим выпустили они Stable версию 6.48. И продолжают её улучшать, добавляя функциональность и исправляя ошибки. Так появляются версии 6.48.1, 6.48.2, 6.48.3, 6.48.4. И тут они решают что 6.48.4 уже достаточно стабильный релиз и создают версию 6.48.5 но уже в ветке Long term.

Теперь работа происходит сразу в двух ветках. В ветке Long term происходит только исправление найденных ошибок, так появляются версии 6.48.6, 6.48.7.

А в ветке Stable появляется новый стабильный релиз с новыми функциями 6.49. И он начинает развиваться, появляются релизы 6.49.1, 6.49.2, 6.49.3 и так далее.

Затем они решают что релиз 6.49.7 достаточно стабилен и создают релиз 6.49.8 в ветке Long term. При этом предыдущий 6.48.7 переводят в архив.

То есть в ветке Long term выпуски 6.48.6 и 6.48.7 исправляют найденные ошибки. А версии 6.48 и 6.49 добавляют функциональность.

Просмотр доступных обновлений

Если ваш роутер имеет выход в интернет, и на нём настроен dns. То посмотреть, какая у вас ветка и версия RouterOS, а также есть ли доступные обновления, можно с помощью следующей команды:

> /system/package/update/check-for-updates channel: stable installed-version: 7.6 latest-version: 7.12 status: New version is available

У меня, как видим:

Канал — stable;
Установленная версия — 7.6;
Доступная для установки версия — 7.12.

Ну а если у вас на роутере нет интернета, то можем просто посмотреть текущую версию RouterOS:

> /system/package/print Columns: NAME, VERSION # NAME VERSION 0 routeros 7.6

Смена ветки обновлений

Если вы хотите поменять ветку обновления, то выполните такую команду:

> /system/package/update/set channel=long-term

Вместо long-term вы можете указать stable, testing, или development.

Обновление RouterOS

Обновить RouterOS можно двумя способами: онлайн или офлайн:

Онлайн обновление — это когда роутер сам скачивает обновление, обновляется и перезагружается.
Офлайн обновление — это когда вы скачиваете файл обновления, загружаете этот файл на роутер и обновляете его.

Онлайн обновление

Если ваш роутер имеет выход в интернет и на нём настроены dns, то он может обновиться самостоятельно скачав обновления с репозитория MikroTik. Для этого выполните команду:

> /system/package/update/install

Скачается последняя версия из текущей ветки RouterOS и установится, затем ваш роутер перезагрузится.

Офлайн обновление

Дополнительно вы можете скачать обновление с сайта mikrotik.com.

Чтобы понять какое обновление скачивать, выполните команду:

> /system/resource/print uptime: 3w3d18h43m32s version: 7.6 (stable) build-time: Oct/17/2022 10:55:40 free-memory: 198.1MiB total-memory: 256.0MiB cpu: QEMU cpu-count: 2 cpu-frequency: 3693MHz cpu-load: 0% free-hdd-space: 950.1MiB total-hdd-space: 968.1MiB write-sect-since-reboot: 1600 write-sect-total: 1600 architecture-name: x86_64 board-name: x86 platform: MikroTik

Из вывода посмотрите на тип архитектуры: architecture-name: x86_64. У меня виртуальная машина с установленной RouterOS. Если у вас железный MikroTik, то архитектура может быть: mmips, mipsbe, arm, и другие.

Также в выводе посмотрите на текущую версию и ветку: version: 7.6 (stable). Это позволит вам определиться с версией обновления.

На сайте выбираете обновление для вашей архитектуры и скачиваете его. Затем загружаете этот файл на роутер. И после того, как файл будет загружен, вам останется лишь перезагрузить ваш роутер и система на нём обновится автоматически. После обновления файл обновления будет удалён с устройства.

Даунгрейдинг

Возможно ли установить более старую версию RouterOS? — Да, но только до заводской версии. Проверить заводскую версию можно с помощью следующей команды:

> /system/resource/print uptime: 4w4d18h21m5s version: 6.49.6 (stable) build-time: Apr/07/2022 17:53:31 factory-software: 6.45.9

Это ограничение, само собой, только для железных роутеров MikroTik.

Для выполнения даунгрейдинга скачиваем файл обновления для нужной версии процессора. Например была Была 7.11.1 будет 7.11. Закидываем на устройство файл обновления. И выполняем команду:

/system/package/downgrade

Ваш роутер понизит версию RouterOS и будет перезагружен.

Итог

Из статьи вы узнали про ветки релизов RouterOS и как производить обновление или даунгрейдинг RouterOS на роутерах MikroTik.

Дополнительно можете почитать справочные страницы на help.mikrotik.com:

Upgrading and installation
Downgrading RouterOS

Другие статьи по теме MikroTik доступны : здесь.

Обновление и даунгрейдинг RouterOS

Имя статьи
Обновление и даунгрейдинг RouterOS

Из этой статьи вы узнаете как правильно выполнять обновление и даунгрейдинг RouterOS на роутерах MikroTik, а также разберём ветки релизов

Routeros 7 long term когда выйдет

Wed Jul 20, 2022 5:39 pm

Dear all, about 6 weeks ago I moved most of my routers from 7.2.3 to 7.1.5, which was offered in the «long-term» channel. The the hope was to avoid crashed routers when updating in the (not so. ) «stable» channel.
Now I get this. Can some kind soul explain what’s going on here?

You do not have the required permissions to view the files attached to this post.
Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 5:50 pm

That is correct, there NEVER HAS BEEN a version 7 Long Term software/firmware offering yet.

Furthermore the latest Stable Version is 7.4, if you want use vers7.

Frequent Visitor
Topic Author
Posts: 85 Joined: Sat Oct 19, 2013 4:14 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 6:11 pm

That is correct, there NEVER HAS BEEN a version 7 Long Term software/firmware offering yet.

Furthermore the latest Stable Version is 7.4, if you want use vers7.

Well, 7.1.5 was definitely offered in the long-term channel in early June. This is why I installed it.

Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 6:26 pm

That is correct, there NEVER HAS BEEN a version 7 Long Term software/firmware offering yet.

Furthermore the latest Stable Version is 7.4, if you want use vers7.

Well, 7.1.5 was definitely offered in the long-term channel in early June. This is why I installed it.

It was offered as long-term to make people with v7-only devices slightly less irritated. I’m sure some slightly more recent version (e.g. 7.2.3) will appear as long-term soon enough.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 6:30 pm

The fact that it hasnt been there for a long time indicates it wasnt really, and some overzealous webmaster probably got his peepee slapped no doubt for posting it.

Frequent Visitor
Topic Author
Posts: 85 Joined: Sat Oct 19, 2013 4:14 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 6:36 pm

OK, so versions showing up in the long-term channel might or might not be long-term. My bad, I guess I should have known this.

Frequent Visitor
Topic Author
Posts: 85 Joined: Sat Oct 19, 2013 4:14 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 7:08 pm

I just moved 4 non-critical routers 7.1.5 -> 7.4. Suprisingly, they all survived it.
Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Jul 20, 2022 7:16 pm

Good to hear! It was a one time-mistake 7.15, its not the norm.
Easy to tell because a long-term version stays on the board for a long time.

just joined
Posts: 16 Joined: Fri Feb 12, 2021 12:51 pm Location: Czech Republic

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 1:59 am

That is correct, there NEVER HAS BEEN a version 7 Long Term software/firmware offering yet.

Furthermore the latest Stable Version is 7.4, if you want use vers7.

so «stable» had to rollback to 7.1.5 for 1:1 nat port forward to work again and tor not take ages to connect.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 3:15 am

Dont know, dont care, use vers 7.4 for most stable version 7 functionality if you want to use ver7.
Forum Guru
Posts: 9209 Joined: Mon Apr 20, 2009 9:11 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 4:01 am

Breaking simple NAT, well, it’s not impossible, but quite unlikely. Too many people use that, so if it happened, there would be many unhappy users in release thread. You wouldn’t miss them. Now problem with something else that would result in behaviour that could seem as broken NAT, that’s more likely. What exactly it might be, it’s hard to tell. If you want to know, post all details (config, description) in new thread and maybe there will be something obvious.

Forum Guru
Posts: 1056 Joined: Wed Oct 22, 2014 9:23 am Location: Oberhausen, Germany Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 3:19 pm

Thought this is the url that RouterOS uses to check. Looks like it is not.
Does anybody know the correct url?

Forum Guru
Posts: 1056 Joined: Wed Oct 22, 2014 9:23 am Location: Oberhausen, Germany Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 7:07 pm

In general I think this is a bad decision.

I have a number of production devices, that run RouterOS 7.x already. I did test the functionality and was happy with it. However not receiving updates at the moment is bad news.

Those who install RouterOS 7.x should be aware, that some features are missing or incomplete. But a channel that does not provide «.0» releases would be nice anyway.

Well, going to stable then. Sooner or later.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 7:07 pm

Dont know what you are talking about??
I have a hex router on 7.24rC and when I put select upgrade on the router it finds 7.4 .

Forum Guru
Posts: 1056 Joined: Wed Oct 22, 2014 9:23 am Location: Oberhausen, Germany Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 7:22 pm

Don’t know what you are talking about.
This thread is about long-term branch and I expressed my displeasure that there will be no 7.3.2 release for long-term.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 21, 2022 9:47 pm

Sorry too much bratworst today, or did someone stick you on a hook ;-PP

Why do you think there is a fricken rule that each version that comes out has to have a long term. dont make shit up!!

I have been using 6.48.6 long term for many moons, no such 6.49 copy. The world didnt come to end, Surprize.

Forum Guru
Posts: 11763 Joined: Tue Feb 25, 2014 12:49 pm Location: Italy Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 1:46 am

I have migrated approx 3900 machines on the last weeks from. 6.46.8 (long-term) to 6.48.6 (long-term) after months of testing.
I have another 200 machines to finish all the migration from 6.46.8 / 6.47.10 to 6.48.6 (long-term)

And probably all devices are keeped to that version for years.

I’m forced to use v7 to one RB5009UG+S+ with 7.2.3 and I think I never update that device, as long as it works.

I use future v7 versions only when I’m forced to do that because the factory firmware is 7.x

Forum Guru
Posts: 2984 Joined: Sun Aug 24, 2014 3:14 am Location: Bogota Colombia Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 2:06 am

i am also in 6.48.6 for most devices, recently testing 6.49.6 on some CRS 317 trying to resolve a specific issue about rate limiting (without success)

Frequent Visitor
Topic Author
Posts: 85 Joined: Sat Oct 19, 2013 4:14 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 2:22 am

Well, v7 was so far simply a nightmare for customers and probably ruined quite a bit of Mikrotik’s reputation. Can you imagine: I ran dozens of v6 «stable» routers on auto-update for years, just once some wireless links broke due to changes in frequency allocations of regulatory domains. It’s not a critical installation, and downtime for a day is not a disaster, but I would never (!) risk this with v7. I hope the company management is aware of the disaster, investigated what went wrong when rolling out v7 and reacted accordingly.

Forum Guru
Posts: 9209 Joined: Mon Apr 20, 2009 9:11 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 2:26 am

It’s simple. RouterOS has different channels, where long-term should be the most stable of all. So if 7.1.5 was there for a while (which many would agree was premature) and someone installed it, it may be a little disappointing to see that MikroTik changed their mind and now there’s really no long-term version yet. First part of it is «so what the hell is the thing I installed?!». Second worry can be about updates. Those are generally good, especially security ones you’d expect in long-term branch. So someone might fear that if there’s bug in this «fake» long-term version, there won’t be fix for it. But I wouldn’t worry about that too much. There’s not that many security bugs in the first place. And if some really bad one came up, MikroTik can easily release something in long-term channel. It’s not like there’s some rigorous process for that, they basically promote some version to long-term from time to time, after the base version wasn’t too disastrous for a while. And eventually there will be «real» long-term version to replace 7.1.5.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 6:46 am

It’s simple. RouterOS has different channels, where long-term should be the most stable of all. So if 7.1.5 was there for a while (which many would agree was premature) and someone installed it, it may be a little disappointing to see that MikroTik changed their mind and now there’s really no long-term version yet. First part of it is «so what the hell is the thing I installed?!». Second worry can be about updates. Those are generally good, especially security ones you’d expect in long-term branch. So someone might fear that if there’s bug in this «fake» long-term version, there won’t be fix for it. But I wouldn’t worry about that too much. There’s not that many security bugs in the first place. And if some really bad one came up, MikroTik can easily release something in long-term channel. It’s not like there’s some rigorous process for that, they basically promote some version to long-term from time to time, after the base version wasn’t too disastrous for a while. And eventually there will be «real» long-term version to replace 7.1.5.

Sob, you have such little faith in the software processes of MT LOL. Your theory (a very poor one) on how or if they have a process for deciding long term versions is the stuff of trashy tabloids.
Your lowing the quality of this thread! ;-PPPP

MikroTik Support

Posts: 26089 Joined: Fri May 28, 2004 11:04 am Location: Riga, Latvia

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 10:55 am

There is nothing «long term» about 7.1.5.
It was one of the first usable v7 releases, so it was put there, to avoid «404 not found» message, but 7.4 is MUCH more stable in all regards.

Forum Guru
Posts: 1056 Joined: Wed Oct 22, 2014 9:23 am Location: Oberhausen, Germany Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 11:30 am

So why not collect some really important fixes from 7.4 and push a 7.3.2 release in long-term? That is what used to happen in V6 times.

MikroTik Support

Posts: 26089 Joined: Fri May 28, 2004 11:04 am Location: Riga, Latvia

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 12:57 pm

Yes, this will happen, when there is a stable enough version.
Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 3:10 pm

Thank you Sir, do not be pressured by squishy avatars, to ejaculate a long term v7 firmware prematurely.

@sob —> » Stable enough «, see there is a thorough vetting process and a QA department!!

Forum Guru
Posts: 11763 Joined: Tue Feb 25, 2014 12:49 pm Location: Italy Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 3:12 pm

@anav. who brought you something alcoholic from Italy as a gift.
Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Jul 22, 2022 3:13 pm

Sorry I was aiming for that expressive flamboyant Italian persona! Dry/sober, and no coffee yet, perhaps that is the issue!

Member Candidate
Posts: 121 Joined: Wed Dec 17, 2014 11:44 am Location: the land of the long white cloud Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 28, 2022 6:14 am

Is v7.4 stabler than v7.3.1 ?
Forum Guru
Posts: 4584 Joined: Tue Apr 13, 2021 2:14 am Location: Belgium

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 28, 2022 4:16 pm

Is v7.4 stabler than v7.3.1 ?
Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Jul 28, 2022 5:43 pm

Is v7.4 stabler than v7.3.1 ?

Yes, it should be. Is it? Only time will show.

7.4 is first release of minor version series, so no bug fixes there yet (since it contains some new features, it’s pretty inevitable to find some bugs eventually). 7.3.1 is a bug-fix release of 7.3 containing bug-fixes . plus 7.4 was only released recently while 7.3.1 is out somewhat longer . and any nasty bugs would be reported already. Also any notable instability.

just joined
Posts: 6 Joined: Sat Mar 03, 2018 11:09 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Aug 11, 2022 1:31 am

Yes, this will happen, when there is a stable enough version.

Oh my gosh. so what is the current version?
I have to use v7 because CCR2004 need it! I put long-term version to this, and I want to forget for long time about upgrade – I don’t have time for it.
Ok, maybe 7.4.1 is much more stable as 7.1.5. but 7.4.2 will be more stable again.
In MT it looks like in M$: new features — new bugs. fixing bugs, next fix bugs. new version. and? Over and over again. Nightmare!

I like MikroTik because it is cheaper than other vendors, and has a lot of functions. but I hate the software releases.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Aug 11, 2022 3:29 am

You hate inanimate objects or even less tangible code. Suggest therapy.

MikroTik Support

Posts: 26089 Joined: Fri May 28, 2004 11:04 am Location: Riga, Latvia

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Aug 11, 2022 10:25 am

Sorry Joseph, is this your first time using «software»? All software programs have versions and each version either fixes bugs, or adds features. Not sure, maybe wikipedia has an article on how this works.

Forum Guru
Posts: 1353 Joined: Mon Sep 23, 2019 1:04 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Aug 11, 2022 10:56 am

We like it more when it has more fixes than new bugs/features (that come with bugs)
But progress has to be made, so we take what we get

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Aug 11, 2022 6:06 pm

No different from any other vendor, when I worked on zyxel equipment, there were many bugs they never fixed at all.
MTs supout system and reporting and frequent updates are heads and tails above anything else I have experienced ( except for their app updates. )

just joined
Posts: 6 Joined: Sat Mar 03, 2018 11:09 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Mon Aug 15, 2022 9:23 pm

Sorry Joseph, is this your first time using «software»?

No, it isn’t. but is it a race?
Any of version couldn’t be really stable, because it was replaced with new, with new bugs :-/

In my opinion the replacement is to fast. more options, more features. but nothing solid!

Forum Guru
Posts: 9209 Joined: Mon Apr 20, 2009 9:11 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue Aug 16, 2022 1:26 am

There are different ways how to do this. MikroTik chose approach closer to rolling release. There’s slower long-term channel, but even that gets (did in v6) updates every few months, with big feature jumps. So if you’re looking for something to install and then get only bugfixes for next five years or so, it’s nowhere near it.

If they did something like that, it would become more and more stable, that would be the good thing. But many people would miss new features. There’s also new hardware that might require bigger changes. If they add them to old branch, they risk breaking something. If they don’t and release new super-long-term branch, people will complain that they can’t have same version on all devices (well, they could, but not the old one they like). Same for different features that many people would surely be begging to have, «oh please, just add X to this otherwise perfect old branch!», I can already hear it. Eventually they’d end up with too many parallel super-long-term branches. That’s not very good either.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue Aug 16, 2022 3:48 am

Nicely stated Sob, and on this topic we can agree LOL, they cannot please everyone including the Josephs of this world. as for other negative nellies, just dont cry me a juniper, crisco or any other vendor river as if they walk on water.

Frequent Visitor
Posts: 88 Joined: Thu Nov 03, 2016 2:39 am Location: Athens, Greece Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue Aug 16, 2022 7:45 pm

I see some new routers like CCR2004 (arm 64) use the long term but newer ones same model come with v7. I am planning on getting a couple of CCR2116 very soon but I want the stability of a long term release. I see however that only v7 is supported according to the specs. Will I be able to downgrade to long term v6 even if I loose some hardware functionality just like CCR2004?

just joined
Posts: 6 Joined: Sat Mar 03, 2018 11:09 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue Aug 16, 2022 8:20 pm

Ok Sob, you have good arguments

So there were earlier two channels for that: «stable» and «long-term». At my home and less critical customers, I use stable version, but sometimes it makes little problems.
From «long-term» version I expect a really stable operation without errors, when I can do upgrade on the devices only overnight.

As of today, there is no long-term version, and sometimes I’m confused if I should upgrade to a newer version. as it may have critical flaws.

Forum Guru
Posts: 11763 Joined: Tue Feb 25, 2014 12:49 pm Location: Italy Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue Aug 16, 2022 8:28 pm

As long as it works (and there are no known vulnerabilities, which due to the incompetence or distraction of those who configure the router are exposed on the Internet), why update?
All my device on production (+4000) have 6.48.6 except 10-20 devices that I still do not have update (6.46.8/6.47.10), and 1 because I can not install v6 (RB5009)

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue Aug 16, 2022 8:58 pm

My home router is on 6.48.6 and my devices behind router use 7.4.1 for wireguard mainly (best of both worlds) and to ensure that I can transition seamlessly to 7.X long term when it arrives. Probably at the same time Normis sheds 5-10 pounds, has anyone else noticed that when he lived in the red car he was slimmer. Profits must be too high.

Forum Guru
Posts: 9209 Joined: Mon Apr 20, 2009 9:11 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Aug 17, 2022 7:26 am

On the other hand, problem with current way of doing «long term» branch is that it’s not really long-term, unless you understand that as 4-8 months, which is roughly how often minor version increased in v6. If you’re after stability and safety, in a way that you can confidently update remote router very far from you, it doesn’t really work that well. It’s much better than «stable» branch, especially than new minor versions x.y(.0). Once it hits long term branch, it was already in stable one for few months, so it’s not bad as far as bugs go. But sometimes there can be changes in behaviour that can bite you. Not often, but it can happen.

Perfect example is how they recently changed handling of routing marks in either 7.2 or after (I don’t remember right now). It has «good» potential to break things. Actually, it’s extreme example, because AFAIK it wasn’t even in changelog, at least in understandable way. And even if it was, someone will always overlook it. There’s no long term v7 now, but it there was, it would probably one day appear there. So you’re happily upgrading to keep safe, and bam, you’re locked out. Not something you expect from long-term branch.

Maybe it would be good idea to make some super-long-term branch(es) with mainly security updates. Let’s say once a year select what’s in long term branch and promise to provide security updates to that for few years. If some horrible security hole is discovered, then fix only that and release x.y.z.1, x.y.z.2, etc. And anyone happy with feature set of z.y.z could simply stay on that branch and be sure it’s safe. Advantage over just staying on some older version without known security problems would be that you wouldn’t need to actively watch it, you’d know that x.y.z.? is safe for next X years. It’s quite possible that there would actually be no such updates, if no security problems were found, so it might not even be too difficult to do. I’m not completely sure about it, it’s just a thought.

As it is now, long term branch is the most safe and mostly fine. But if you do it for living, you should be watching all, preferably every development version, and if you see something you don’t like, then scream very loudly as soon as possible.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Aug 17, 2022 2:07 pm

Now we are in the weeds of this or that and perfection will never be reached, so in summary, the route MT has chosen is no worse than any other. Live with it and go in peace, or drink lots of cheap Czech liquor ;-P

Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Aug 17, 2022 3:41 pm

.. cheap Czech liquor ;-P
No need to fuss around, it’s got a name: Becherovka.
Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Aug 17, 2022 9:02 pm

Okay everybody knows the baddest liquor in Europe is zganje !
Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Aug 17, 2022 11:01 pm

Okay everybody knows the baddest liquor in Europe is zganje !

What you googled is a generic word for «spirit» Plus you copy-pasted wrong spelling, it should be žganje. However, if you’re after the baddest liquor in Europe, then look for degvīns.

Forum Guru
Posts: 18585 Joined: Sun Feb 18, 2018 11:28 pm Location: Nova Scotia, Canada Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Wed Aug 17, 2022 11:12 pm

Heheh, Well google sometimes is not your friend. I am just a tourist, not a guru LOL.
Member Candidate
Posts: 105 Joined: Tue Jun 15, 2021 1:23 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Apr 27, 2023 7:01 pm

by mkx » Wed Jul 20, 2022 5:26 pm
I’m sure some slightly more recent version (e.g. 7.2.3) will appear as long-term soon enough.

More seriously, it there any plan to release a long-term 7.x any time soon-ish (let’s say, in 2023) or at least a roadmap? We’re getting more and more pressure from Management on this topic.

Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Apr 27, 2023 7:18 pm

by mkx » Wed Jul 20, 2022 5:26 pm
I’m sure some slightly more recent version (e.g. 7.2.3) will appear as long-term soon enough.

There’s a dot misplaced in my (quoted) post . what I meant was 7.23

SIncerely, it’s completely unclear (to me) when we’ll see a v7 long-term. I can only guess that Mikrotik devs’ ToDo list for v7 has plenty of yet unchecked items and I would expect them to focus on development for now . and only later to shift focus towards long term stability.

Member Candidate
Posts: 105 Joined: Tue Jun 15, 2021 1:23 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Thu Apr 27, 2023 8:53 pm

Honestly, I can understand that testing takes time, especially for a completely new release like the 7.x. If they published a long-term version that was not stable enough, we would be among the first to complain. But it’s the lack of communication/roadmap in this regard that I really don’t understand.

MikroTik Support

Posts: 26089 Joined: Fri May 28, 2004 11:04 am Location: Riga, Latvia

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 8:27 am

What will change if we rename any random release to long-term? It’s only a name. If you think 7.8 is stable enough to be called that, just use it, no matter what it’s called

Forum Guru
Posts: 11763 Joined: Tue Feb 25, 2014 12:49 pm Location: Italy Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 10:58 am

What will change if we rename any random release to long-term? It’s only a name. If you think 7.8 is stable enough to be called that, just use it, no matter what it’s called

For me a long-term for v7 is v7.7, with 2 BGP full tables and 2x 2Gbit lines do not give any problem.

Member Candidate
Posts: 105 Joined: Tue Jun 15, 2021 1:23 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:03 am

It’s only a name. If you think 7.8 is stable enough to be called that, just use it, no matter what it’s called

C’mon man! I can’t believe you just wrote that! Please tell me you had a gun pointed at you and you were forced to write that!
It’s not «only a name»! It is the result of a scientific process aimed at identifying out the most stable version among all stable releases, accros all the hardware you have. It is your responsibility as the constructor to declare a specific release as long-term, and certainly not my responsibility as a customer’s to declare any release as such (unless you give me access to all your hardware and code, then we can talk about it — but in this case I wouldn’t be a customer anymore, but an independent auditor, which would also be good option)!

Me choosing a random release because it «seems to work for me» doesn’t make it a long-term version, because another user might have another version which works for him. This method lacks of consistency! At this point, it’s like snake-oil homeopathy where one just believes that a sugar pill fits helps recovering from whatever symptoms he has «because it works for me». Well, guess what, it does not, because there is no consistency and the choice was made on a personal, subjective basis instead of an empiric, scientific approach. Period.

It’s not about renaming any random release to long-term either, but about gathering feedback from stable releases on already out in production, results from internal in-house testing and security caveats found by external, independent actors. We all understand that this takes time (although 2 years is clearly not acceptable) as I wrote above, but the complete lack of any information and visibility in this area is what’s really irritating.

No hard feelings, Normis, but honestly, how could you write that.

MikroTik Support

Posts: 26089 Joined: Fri May 28, 2004 11:04 am Location: Riga, Latvia

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:07 am

Sorry to ruin your dreams, but for most software, there is no such scientific process. It is just a matter of «less known bugs than X»

Forum Guru
Posts: 11763 Joined: Tue Feb 25, 2014 12:49 pm Location: Italy Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:13 am

Sorry to ruin your dreams, but for most software, there is no such scientific process. It is just a matter of «less known bugs than X»

I agree, without a shadow of a reasonable doubt.
Forum Guru
Posts: 4584 Joined: Tue Apr 13, 2021 2:14 am Location: Belgium

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:14 am

Statistics, maybe yes.
Science ? Nope.
Forum Guru
Posts: 1056 Joined: Wed Oct 22, 2014 9:23 am Location: Oberhausen, Germany Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:26 am

A lot of people try not to install «.0» (or even «.1«) releases in production. That is exactly what long-term releases were: stabilized point releases, that are supposed not to break installations with newly introduced features.

Handing that decision to the customer brings some extra noise. All my devices send notifications on available updates, and I do not want these for releases I do not intend to install anyway.

On the other hand. Currently we do not see point releases at all. I hope these will come back any time soon.

Member Candidate
Posts: 105 Joined: Tue Jun 15, 2021 1:23 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:29 am

Firstly, «doing so because everyone else does» is not an argument! It does not become the truth just because it is the most popular option.

Secondly, it is (sadly) true that because the Time-To-Market was significantly reduced over the past 2 decades, testing is done more and more on the customer’s prod (and actually, it applies to many more things, not just software. Just think about how many cars that are put on the market recalled somewhat later for major fixes). But at least, that’s a consistent strategy with feedback gathered from many clients.

Lastly, «It is just a matter of «less known bugs than X» «=> yes indeed! And the easiest approach to this is to fix existing bugs without adding new features (which may introduce new bugs). That is btw exactly how it is described in you own doc about releases. No one says that the long-term will be 100% bug-free, but the version whith the least bugs, in exchange to not having the latest features.

RC versions: early access to new features
stable version : good enough for most people, best compromise between stability and features
long-term: focus on stability at the price of slow integration of new features. Only bugfixes.

By lack of communication, I mean that it could also be that you decide to drop the long-term released altogether. I would not be happy, but at least it would be a clear statement. Cisco did that by discontinuing the «safe harbour» releases a couple years ago (and lost quite a few customers in highly critical sectors).

MikroTik Support

Posts: 26089 Joined: Fri May 28, 2004 11:04 am Location: Riga, Latvia

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 11:39 am

Yes, at some point MikroTik should stop adding features to a selected version, and then there should be some stabilized point releases after. At least this is how it was before. We might change something in future. Edit: yes, you seem to have noticed that v7 is a bit different, versions come out much faster, changelogs are bigger, but there are no long-term and no point releases. It’s a different approach. Maybe we need to drop long-term, it is not decided yet.

Member Candidate
Posts: 105 Joined: Tue Jun 15, 2021 1:23 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 12:15 pm

alright, these are internal, strategic decisions which have to be taken, and you guys certainly have good reasons to do so. At long as these strategic choices are communicated to the customers, there’s nothing to argue about.

Now, my 2 cts (but this is only my personal opinion): I would be very sad to see the long-term versions being dropped. Especially on professional-grade products, it is often more important to customers to have stable, mostly bug-free environments than the latest features. To me (again, personal opinion), providing only a stable, mainstream release train (+ maybe RC/Beta version) shows a clear decision from a manufacturer to leave the professional market in favor of consumer-grade products. And honestly, in case of Mikrotik, I think this would really be a waste.

Frequent Visitor
Posts: 56 Joined: Tue Mar 10, 2020 9:02 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 12:45 pm

To me it seems like the long term channel has been little more than «old and proven version». In general, I think «long term» usually implies long term support, ie continuing to receive bug and security fixes for duration of the «term», without receiving new features. There has not been an abundance of patch releases on the long term channel over the last few years, and certainly not within the same «minor» version.

As for version 7, it seems to be so heavily in development still that I don’t know whether a long term release makes sense at this time.

Member Candidate
Posts: 105 Joined: Tue Jun 15, 2021 1:23 am

Re: RouterOS 7.1.5. «long-term»: dead end?

Fri Apr 28, 2023 1:59 pm

well, development of ROS 6 seems to have stopped by end of 2021, which explains why there is no need for new bugfixes for the long-term: because no new features have been added, most bugs were already fixed in the latest 6.48.6. But it is still fully supported, from the public info available.

As you say, ROS 7 has major changes compared to ROS6, even in terms of performance, showing that there was heavy development involved (maybe almost starting from a blank sheet).

Well, let’s hope we’ll see a long-term ROS7 published in the near future.

Long time Member
Posts: 699 Joined: Mon Jan 16, 2006 6:07 am Location: Norwalk, CT Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Sat Apr 29, 2023 1:02 am

YES! Please, as soon as humanly possible, STOP adding features and just fix everything you are aware of not working and give us a very reliable long term release. You can skip all additional packages from this long term release, we don’t need zero tier, wave2 or rose support in the first long term release, in fact I imagine that most of us waiting for a long term release would prefer if support for these packages didn’t even exist yet in the long term release.

The concept and strategy behind Long Term releases being extremely stable and well tested are very important to many of us. We sell a service to customers, the customers do not care what version or platform we use to deliver that service, they only care that it is reliable and doesn’t break. Infrequent release of updates is actually a plus for uptime. What we find incredibly frustrating is when an update comes out that introduces new features that we aren’t using, and those features likely have their own bugs in them, but problems existed in the previous build are not yet fixed.

Please continue to develop your new features like Rose & wave2 in the RC build releases, but equally please don’t even release them for stable releases until you have added all the functionality you want to and are ready to focus only on fixing bugs. At that point in time when you feature lock a new function then you can release that new package for a Stable build, and transitively you should only be releasing a new stable build once all packages included / available for it have been placed in feature lock. New packages & features released to a stable build should be tested by you and devoid of all *known* bugs.

Once a new feature has gone 2 or more stable releases without ANY bug fixes, then and only then that feature should be included in the next long term release. If you only release 1 or 2 long term releases per year we would be thrilled. We don’t want frequent new long term releases, we want GOOD releases. Few if any of us wanting to use long term builds are even using things like zero tier, rose or wave2. In fact I’d go so far as to say there should almost never be any additional packages available for a long term release build, if something is not reliable enough to be included in the main OS package it should not be available for long term releases.

Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Sat Apr 29, 2023 9:29 am

We do need wave2 in v7 long-term . because a few device models require it to run their wireless interfaces. It doesn’t matter that it’s in separate package.

And similarly your post contains other BS.

Long time Member
Posts: 699 Joined: Mon Jan 16, 2006 6:07 am Location: Norwalk, CT Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Sun Apr 30, 2023 10:20 pm

We do need wave2 in v7 long-term . because a few device models require it to run their wireless interfaces. It doesn’t matter that it’s in separate package.

And similarly your post contains other BS.

my point is that no features should be in long term until they have survived multiple stable releases without any additional bug fixes. Wave2 does not currentyly meet that criteria, though someday it certainly will, and until then it should remain limited to RC or Stable releases only. Long term should be absolutely the best most reliable and bug free code, nothing less. If any feature is still being developed and improved then it should be left in either rc or stable depending on a particular subset of the features and how well tested they are. I’m not saying wave2 should forever be kept out of long term, only that I think it’s entirely appropriate for long term to have fewer features available for it while those features are being further tested and refined. There should be a tradeoff of delayed feature support in exchange for exceedingly stable long term releases. Trying to run a still being developed feature while also expecting that to work in a build tree that is supposed to be extremely reliable and stable is a textbook definition of an impossible situation.

Product life cycle should be: Come up with new idea/feature request, develop it internally, once it is devoid of any internally known bugs it gets released in a RC build (either inside the main package or additional package, depending on the feature). Once whatever number of RC builds are needed to solve any bugs that turn up after RC release are gone through and there’s no further known issues there, it gets incorporated into a stable release. This stable release should be devoid of ANY open issues or known bugs in the features included in it, but may still include fixes that were solved since the last RC build which were only tested internally. Once a feature has survived 2 or more stable releases without having any bugs turn up, then and only then should it be incorporated into a long term build. Long term builds may take a year or more to gain support for features like wave2 after they hit the stable release tree, and that should be viewed as a good thing.

edit to add, this also can tie into and help with improved support & documentation, MikroTik could segment the support queues by build, prioritizing tickets for long term builds (aka you get priority support, but only if you run the most reliable and best tested versions), and adopt a policy that all documentation also only officially applies to long term builds, that way they don’t need to update documentation for changes in stable or RC releases (but they should make available unofficial / draft documentation for them).

Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Mon May 01, 2023 8:29 am

To reply to a long post with short: there is no long-term version which contains wifiwave2. And according to previous post, there shouldn’t be one before wifiwave2 gets very stable.

Long time Member
Posts: 699 Joined: Mon Jan 16, 2006 6:07 am Location: Norwalk, CT Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Mon May 01, 2023 8:13 pm

To reply to a long post with short: there is no long-term version which contains wifiwave2. And according to previous post, there shouldn’t be one before wifiwave2 gets very stable.

there’s currently no long term version at all for v7, and the last v6 long term build was released in December of 2021, which one could argue is long enough ago to say it’s no longer current enough to be counted (especially as it contains numerous bugs relating to loading of branding files). What I’m advocating for is trying to get to a v7 long term build as quickly as possible, but not by just slapping a long term label on something already existing just for the sake of it. Disable whatever isn’t worthy of the designation long term and release whatever is. For many of us most of the additional features or packages are not used at all where we care about a long term build deployments, so delaying a release we can count on to be bug free for functionality that we don’t use is annoying.

I suspect most MikroTik installations pretty reliably fall into one of two categories, core router & infrastructure deployments where very little beyond PPPoE / L2TP / IPSEC, queues, routing and firewall functionality is ever used, and the other being edge / end deployments where end user type functions like wireless, zero tier, wireguard, containers, rose, wave2 are heavily used. I’m not suggesting there should ever be two entirely separate versions of RouterOS for these deployments with different core functions, but there would likely be little to no pushback if these additional features took even a year or two longer to make it into a long term build than the stable builds, and when they eventually do they are extremely robust and well tested.

Forum Guru
Posts: 10960 Joined: Thu Mar 03, 2016 10:23 pm

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue May 02, 2023 11:53 am

It seems to me that you’re advocating for a «politically determined» declaration of some version to be long-term. Just because you have to (management of your company is asking you?) install a new LTS version of OS to whatever infrastructure you’ve got and MT didn’t deliver one for quite a while. And you don’t seem to care about actual reasons for this.

If you only care about version which didn’t change for a while, use 7.4.1 . it’s a «dot» release, it was released in August 2022 . and you’re free to use it for next few years.
I don’t see any added value in MT declaring it LTS as MT doesn’t seem to be willing to dedicate any resources to maintaining some v7 LTS due to rapid functionality development currently going on in v7. And a lot of it has to be done, arguments that v7 has to offer at least same functionality as v6 are very well funded IMO (annd currently v7 still lacks some).

If your motivation in advocating for a v7 LTS is not what I described above, then . please explain what is it. What is wrong with 6.48.6 as LTS?

Long time Member
Posts: 699 Joined: Mon Jan 16, 2006 6:07 am Location: Norwalk, CT Contact:

Re: RouterOS 7.1.5. «long-term»: dead end?

Tue May 02, 2023 8:28 pm

If your motivation in advocating for a v7 LTS is not what I described above, then . please explain what is it. What is wrong with 6.48.6 as LTS?

you could not be further from correct. For one, I run the management of the company therefore it is me that cares about stability and reliability of our routers, and I absolutely care about the reasons I stated above. If you read what I’m advocating for, it is to once again release a long term build that only contains well tested and proven code. That definition means that new functionality should not be included into the long term release as they are not yet well tested and proven. As an example, wave2 is very much still in development and 7.9 stable that was released today included 5 new additions and 11 fixes or improvements to it, that is far from stable and proven, however regular wireless had no changes in the changelog, I would certainly consider that stable and proven. Those of us that install MikroTik as business critical infrastructure care more about stability and reliability then we do about new features, so we would prefer to see a stripped down version that has fewer features but contains fewer bugs in the code (including bugs in subsystems we aren’t using, because those could still lead to security or stability concerns). Look at the problems that came up in 7.8 with SFP compatibility, had we deployed 7.8 we could have had devices go offline that operate 2,000 miles away. When we update our routers we can’t afford to have a new bug that was introduced in the latest release cause interfaces to go offline!

There are several reasons why 6.48.6 is not an option now, Firstly it does not support new hardware (many v7 only devices now), and many older CCR1xxx routers have been discontinued so we are forced to adopt the newer CCR2xxx models for new installations. Secondly there are branding package bugs that were introduced in 6.47 that did not get fully fixed until 6.49.7 which broke several different workflows and processes for us and prevented us from using any versions from 6.46.8 to either 6.49.7 or 7.7 when v7 was finally stable enough to risk putting into production.

What’s new in 6.49.7 (2022-Oct-11 17:37):
*) branding — fixed execution of «autorun.scr» file when installing branding package (introduced in v6.47)

It’s very simple, some of us want a build that is very well tested and I for one am perfectly happy to forgo new features and added functionality for however long it takes to get them to be very robust and reliable in exchange for having a version that we can deploy to thousands of devices without needing to worry about what might break.

Routeros 7 long term когда выйдет

ОТВЕТ НА ПРЕДЫДУЩИЙ ВОПРОС

Основная масса участников проголосовала за ответ «20 Мбит/с». Но это НЕверный ответ.

Правильный ответ на предыдущий вопрос – 5 Мбит/с. Уточняю: я алкоголь не пил и каннабис не курил)

Тут я хочу вспомнить Эйнштейна, который утверждал, что все в этом мире относительно. Для начала забудем про MikroTik. Допустим, некий компьютер загружает файл. Для компьютера, который принимает этот файл, все однозначно: это загрузка. А вот для маршрутизатора, который пересылает через себя этот файл в сторону компьютера, уже не все так однозначно. Файл вначале входит в один из интерфейсов маршрутизатора, и для этого интерфейса файл является входящим потоком (загрузка), а для другого интерфейса, через который этот файл выходит, он будет уже исходящим потоком (выгрузкой). Так как один и тот же файл для одного и того же маршрутизатора может представлять собой как исходящие, так и входящие данные.

Теперь переходим к нашей задаче. Ответ «20 Мбит/с» был бы верным, если бы IP-адрес 10.11.12.139 был бы указан в параметре Target, т.к. именно относительно того, что указано в этом параметре, происходит определение того, что такое загрузка, а что такое выгрузка.

Этот нюанс часто упускают, т.к. значения входящей и исходящей скорости зачастую совпадают. И как результат, все вроде бы работает. Но ключевое тут «вроде бы».

Как говорят фокусники, следите за пальцами.

14.4K views edited 09:31

Какой формат подачи информации, по вашему мнению, является более подходящим для технического учебника в формате Wiki? Персонифицированный или обезличенный? Выберите ответ на примере одного из двух приведенных ниже предложений.

Anonymous Poll
Вы можете получить информацию о трассировке с помощью команды.
Информацию о трассировке можно получить с помощью команды.
1.6K voters 15.7K views 05:32

Посмотрите на прикрепленный выше скриншот и попробуйте объяснить, почему в списке файлов мы видим файл размером 19,6 Мбайт, несмотря на то что размер файлового хранилища – 16,3 байт?

12.3K views edited 08:21

ОТВЕТ НА ПРЕДЫДУЩИЙ ПОСТ

Файл размером 19,6 Мбайт отображен в списке файлов, но на самом деле находится он не в файловом хранилище, а в оперативной памяти. На некоторых устройствах имеется папка flash. Все то, что хранится в ней, находится в постоянной памяти, а все, что вне ее, – в оперативной памяти.

Нюансы:
1. Папка flash либо есть, либо нет. Если создать ее вручную, то это ничего не изменит.
2. Если папки flash нет, то все отображаемые файлы хранятся строго в постоянной памяти.

13.2K views edited 06:18

ОНИ НЕ ЗНАЮТ, КАК ИМ ПОЛЬЗОВАТЬСЯ

Пост не по MikroTik.

Где-то полгода назад я был на экскурсии в Библиотеке им. Ленина. Во время экскурсии мы заходили на узел связи, и экскурсовод рассказала, что современные дети не понимают, как пользоваться телефонами с дисковым набором.

Вчера я с дочерьми (10 и 12 лет) ходил на квест. Одним из заданий квеста было позвонить по указанному номеру телефона. Долго я смеялся, когда смотрел, как дети пытаются понять, как надо набирать номер. Они сразу обнаружили, что диск крутится, но не догадались, что надо вставить палец в отверстие и прокрутить диск до металлического ограничителя, и не смогли догадаться, до какого положения надо вращать диск, если вставлять палец.

13.3K views edited 08:01

ЗАДАЧА ПО ВЫКЛЮЧЕНИЮ ПРАВИЛ ФАЙРВОЛА

Администратору для диагностики сетевой проблемы потребовалось выключить все правила файрвола. Он в графическом интерфейсе выделил все правила в IP Firewall — Filter Rules и выключил их. После чего у него пропала связь с маршрутизатором. Дальнейшие попытки подключения были безуспешными.

ВОПРОС: почему у администратора пропала связь с устройством и возможность повторного подключения?

курсы-по-ит.рф
Онлайн-курс MikroTik MTCNA от официального тренера

Программа повышения квалификации «Администрирование сетевых устройств MikroTik». Обучение до уровня эксперта с нуля. 162 видеоурока и 45 лабораторных работ с авторской поддержкой.

13.1K views edited 09:28

ОТВЕТ НА ПРЕДЫДУЩУЮ ЗАДАЧУ

При, казалось бы, одновременном выключении правил в графическом интерфейсе на самом деле выключение правил происходит поочередно по принципу сверху-вниз. Таким образом, администратор вначале выключил разрешающие правила и оставил запрещающие. И, как результат, остался «отрезанным» от маршрутизатора.

Если подключение к маршрутизатору выполняется из локальной сети, то зачастую трафик такого подключения ничем не блокируется и получается выключить правила в один заход. Иногда это удается и при подключении из внешних сетей. Но я рекомендую вначале выключать запрещающие правила и только потом выключать все остальные правила.

14.0K views edited 12:05

Новая аппаратная платформа AMPERE

У компании MikroTik ожидается новая аппаратная платформа AMPERE. Она уже внесена на страницу загрузок RouterOS.

10.9K views 08:54

Какой способ агрегации каналов может балансировать кадры одного соединения между разными подчиненными интерфейсами?

Anonymous Poll
Active Backup
Balance-alb
Balance-tlb
Balance-xor
1.5K voters 11.4K views 06:23

Какие способы агрегации каналов могут использоваться только для резервирования?
Anonymous Poll
Active Backup
Balance-alb
Balance-tlb
Balance-xor
1.3K voters 12.6K views 06:24

ВЫШЛА ROUTEROS 7.12

Вся новость приведена в заголовке.

Слово fixed встречается 72 раза, а слово improved — 35 раз.

MikroTik Wiki
MikroTik Wiki | Изменения в MikroTik RouterOS 7.12.x

Подробное описание изменений в MikroTik RouterOS 7.12.x. Официальный список исправленных ошибок, добавленного функционала и прочих доработок. Дата выхода первого набора изменений – 9 ноября 2023, дата выхода последнего набора изменений – 17 ноября 2023.

13.9K views edited 13:15

ХОРОШИЙ ПОНТ ДОРОЖЕ ДЕНЕГ

Сегодня пришли два платежа за мой курс по Wi-Fi. Один платеж от Мегафона, а второй от КРОКа. Если вы не знаете, что такое КРОК, то скажу в нескольких словах: один из крупнейших системных интеграторов РФ.

12.0K views edited 11:44

АГРЕГАЦИЯ КАНАЛОВ

На устройствах под управлением MikroTik RouterOS поддерживаются семь способов агрегации каналов, названия которых можно увидеть в приведенных выше тестах.

Два способа могут использоваться только для повышения отказоустойчивости: Active Backup и Broadcast.

Пять способов могут использоваться одновременно и для распределения нагрузки между разными подчиненными интерфейсами, и для повышения отказоустойчивости: 802.3ad, Balance-rr, Balance-alb, Balance-tlb и Balance-xor.

Почти все способы балансировки при распределении нагрузки распределяют соединения, а не кадры. То есть если у нас в состав агрегированного канала входят два подчиненных интерфейса и пойдет два потока: один поток с ping (скорость ближе к нулевой), а другой с загрузкой файла со скоростью 100 Мбит/с, – то это не значит, что у нас через каждый из каналов пойдет по 50 Мбит/с. Это значит, что через один канал пойдет 100 Мбит/с, а через другой – ping, т.е. почти ничего.

Более того, ping может пойти через тот же самый подчиненный интерфейс. Более того № 2: есть вероятность, что если запустить 10 больших потоков, то все эти потоки пойдут через один подчиненный интерфейс. Это связано с тем, что выбор идет по определенному алгоритму, а алгоритм может определить, что надо отправлять все через один подчиненный интерфейс.

И только один из способов агрегации может балансировать кадры даже одного соединения через разные подчиненные линии. Это Balance-rr.

курсы-по-ит.рф
Онлайн-курс MikroTik MTCNA от официального тренера

Advanced Mode беспроводного интерфейса на оборудовании Mikrotik Router OS

Для входа в беспроводной режим понадобится зайти в раздел Wireless, открыть интересующий беспроводной интерфейс, справа выбрать опцию Advanced Mode (рис 40.1). После этого откроются дополнительные настройки.

Рис. 40.1 Переключение опции Advanced Mode

Переходим в раздел Advanced (рис. 40.2).

Рис. 40.2. Раздел Advanced

Доступные опции раздела Advanced:

Area – позволяет передавать от MikroTik, работающего в режиме клиента, от базовой станции информацию о том, где он находится, или что это за устройство. Это дополнительная информация, которая позволяет настраивать базовые станции согласно этой информации. В основном используется для операторов связи и редко используется в обычных беспроводных сетях. Опция проприетарная и работает только между устройствами MikroTik — MikroTik.

Max Station Count – максимальное количество устройств, которое разрешено для подключения к MikroTik, работающему в режиме Access Point (в режиме базовой станции), по умолчанию указано 2007 клиентов. Это количество максимально, что разрешено в стандарте Wi-Fi, из-за ограничения в заголовках кадров. Очевидно, что данное количество очень и очень велико, поэтому можно указывать 20–30 клиентов, которые будут себя комфортно чувствовать в данной Wi-Fi сети.

Distance – дистанция в километрах, в основном используется для беспроводных мостов. Опция позволяет указать дистанцию в километрах (напр. при дальности беспроводного моста в 5км, указываем 5). Есть опция dynamic – в данном случае MikroTik сам пытается определить оптимальное значение данного параметра. И опция indoors – параметр актуален для точек доступа, работающих в обычных локальных сетях.

Burst Time – время в микросекундах, которое позволяет задержать передачу клиента на какое-то время. Wi-Fi работает по очереди, т. е. в каждый промежуток времени происходит обслуживание одного клиента, изменяя значение burst time, меняется именно этот промежуток, тем самым можно увеличить производительность на определенное количество микросекунд для определенного клиента. К сожалению, параметр может негативно сказаться на работе беспроводного клиента, поэтому в большинстве случаев параметр не используется.

Hw. Retries – осуществляемое количество повторов отправки кадра до клиента при отсутствии подтверждения от клиента. Wi-fi работает таким образом, что для понимания факта прихода сгенерированного Wi-Fi сетью кадра клиенту, необходимо получение подтверждения этого прихода. В случае отсутствия подтверждения параметр Hw. Retries будет отвечать за количество попыток отправить кадр на определенной скорости. По умолчанию указано 7 попыток.

При подключении к Wi-Fi сети происходит согласование ряда параметров, в том числе определенная модуляция, и скорость работы. Если не было получено подтверждение от клиента, что до него дошел кадр, происходит 7 попыток отправить ему тот же самый кадр, если вновь не было получено подтверждение, то те же действия повторяются на более низких модуляциях, т. е. снижается скорость. Это происходит до минимального значения модуляции. Если же и на минимальном значении модуляции за 7 попыток не было получено подтверждения, через задержку, равную On Fail Retry Time, происходит последняя попытка отправки 7 раз кадров. И после этого чрез 3 секунды Disconnect Time Out, происходит сбрасывание клиента с ошибкой extensive data loss.

Данное поведение считается достаточно опасным, т. к. если происходит большое количество попыток отправить данные в беспроводной сети, это говорит о том, что клиенты очень плохо работают в беспроводной сети, и в данном случае для ускорения скидывания плохих клиентов с беспроводной сети можно установить значение Hw. Retries в 4 (например). Или, наоборот, можно указать значение большее, если клиентов немного и необходимо до последнего пытаться передать кадры.

Hw. Fragmentation Threshold – опция на аппаратном уровне указывает размер кадров для передачи в беспроводной сети. Применяется в случаях, если клиент сильно удален, либо Wi-Fi среда сильно загрязнена, можно установить минимальный порог размера кадра. Либо можно указать некое среднее значение, потому что Wi-Fi стремится передавать кадры максимального размера для увеличения производительности беспроводной сети, но в случае с плохим уровнем сигнала, или загрязненной зоной Френеля (когда присутствуют препятствия между клиентом и точкой доступа), можно попробовать решить вопрос качества маленькими кадрами.

Hw. Protection Mode – имеет 3 опции, связанные с проблемами скрытого узла. Для оптимальной работы Wi-Fi требуется, чтобы все клиенты «слышали» друг друга, но далеко не всегда это может быть осуществимо. Клиенты физически могут находиться в таких местах, что не будут слышать друг друга, и получится, что в момент, когда 1 клиент начинает говорить «слово», 2-й клиент не услышит этого и так же начнет говорить «слово», приведет к тому, что не будут услышаны ни 1-й клиент, ни 2-й. Данное явление носит название проблемы скрытого узла. Проблема может наблюдаться в случаях, если клиенты подключаются из разных комнат, или из-за двери, или просто на большом расстоянии.

Решение проблемы заключается в изменении принципа работы клиентов (установка значения опции в rts cts). Перед передачей данных клиентом, клиент отправляет RTS (Request to send) запрос на отправку данных. После получения rts-запроса точка доступа начинает рассылать CTS (Clear to send) запрос, т. е. необходимость очистки эфира и выделение времени на передачу данных клиентом. Все клиенты, получившие cts-запрос, не передают данные и не передают rts, а клиент, передавший rts-запрос, начинает передавать свои данные.

Значение опции cts to self является более «щадящим» режим работы cts. Принцип работы клиентов меняется так, что клиент, желающий передать данные, отправляет не rts-запрос, а cts-запрос. Метод считается не самым эффективным и редко помогает.

Поэтому значение Hw. Protection Mode как правило принимает значение либо rts cts, либо none (отключено).

Adaptive Noise Immunity – проприетарная опция, позволяющая адаптироваться к окружающему нас шуму. К сожалению, официальной информации об этой опции нет, поэтому можно лишь выбирать из значений: ap and client mode (использование, как в режиме клиента, так и в режиме Access Ppoint – наиболее универсальный режим), client mode (использование в режиме клиента, если беспроводной интерфейс работает в режиме клиента), none (отключено).

Preamble Mode – была изменена со стандарта 802.11n, и тогда появились так называемые короткие преамбулы, которые позволяли увеличить скорость передачи данных на ~11 %. Недостатком является то, что при работе в смешанном или в коротком режимах совместимость с некоторыми клиентскими устройствами теряется, поэтому наиболее универсальным режимом работы позволяющим работать со всеми клиентскими устройствами считается long (старый) режим работы. Соответственно, выбор происходит либо в сторону увеличения скорости передачи данных, либо в сторону максимальной совместимости с клиентскими устройствами.

Update Stats Interval – интервал времени в секундах, через который будет автоматически обновляться статус клиента в Registration Table. По умолчанию параметр не указывается, и, соответственно, значения силы сигнала и ccq обновляться не будет. Без этой опции статус обновляется тогда, когда происходит открытие раздела Registration Table. Опция полезна для снятия параметров для какой-нибудь системы автоматизации.

На этом просмотр расширенных настроек беспроводного интерфейса завершен.