Mikrotik current operator error

Mikrotik current operator error Sun Feb 21, 2021 3:15 am Goodnight! I require your help as soon as possible It turns out that I have problems with the LTE band, the parameters are perfect, the internet is going very well, even from one moment to another it changes the name of the mobile operator […]

Содержание

  1. Mikrotik current operator error
  2. Re: LTE operator problem?
  3. Re: LTE operator problem?
  4. Re: LTE operator problem?
  5. Re: LTE operator problem?
  6. Re: LTE operator problem?
  7. Re: LTE operator problem?
  8. Re: LTE operator problem?
  9. Re: LTE operator problem?
  10. Re: LTE operator problem?
  11. Re: LTE operator problem?
  12. Re: LTE operator problem?
  13. Распространенные проблемы MikroTik
  14. Распространенные проблемы MikroTik
  15. Ресурсы
  16. Firewall
  17. Другие способы анализа трафика
  18. Wireless
  19. Ping, Traceroute
  20. Заключение

Mikrotik current operator error

Sun Feb 21, 2021 3:15 am

Goodnight! I require your help as soon as possible

It turns out that I have problems with the LTE band, the parameters are perfect, the internet is going very well, even from one moment to another it changes the name of the mobile operator for a series of numbers and after this the internet starts to fail and it doesn’t even give me nor 1mb of download speed .

It seems strange to me because the connection parameters do not change (according to the tab), but the moment I observe that the name of the operator is changed by a series of numbers, the internet becomes terrible

I have a router: LHG LTE6 kit (ROW)

PD: I want to highlight that I have made the firmware change to the latest version and the problem continues

Re: LTE operator problem?

Wed Feb 24, 2021 9:51 pm

150 RouterBoards in EMEA
Knowledge Base about LTE by SiB | Buy me a caffe | Telegram : http://t.me/SiB_PL

Re: LTE operator problem?

Thu Feb 25, 2021 10:25 am

I have the latest version for a few weeks, but this did not solve anything!

Also, I have noticed an incredible loss of speed even though I do a band blocking, the speed decreases from one moment to another and I have to restart the modem from the system to have a high download speed! How can i fix this?

Re: LTE operator problem?

Fri Feb 26, 2021 9:12 am

I have tried band blocking and it works for a few hours but then the problem returns . I have also used some guides to «improve» this situation with the script

/interface lte at-chat lte1 input=»AT*Cell=2,3,,37900,118″

Although in the console I have specified which cell to use, in the «Cellular» tab a different one appears

I have also tried some answers in other posts, and they have not served me at all =/


PD: What I have been able to notice is the change in the frequencies of the signal . there is a change in cells and the EARFCN is reversed, that is, they are exchanged, if before the EARFCN 38100 used cell # 118, from one moment to another the EARFCN moves to cell # 127

this is an antenna software problem??

Re: LTE operator problem?

Fri Feb 26, 2021 4:23 pm

This is strange and looks as some bug.
In my Poland networks I can connect only to that cell what I define in Cell Lock.

You discover in Cell Monitor that cells what are detected via direction & signals and. that bands what are active at lte module but they can be only 2 at ones. Means, CellMonitor is suitable when you use one band. I do in my scripts action like «set band=1,2; cell-comonitor lte1;» and after that change bands to next one like «set band=3,7; cell-comonitor lte1;» and at every 2bands I scan air.

150 RouterBoards in EMEA
Knowledge Base about LTE by SiB | Buy me a caffe | Telegram : http://t.me/SiB_PL

Re: LTE operator problem?

Fri Feb 26, 2021 11:46 pm

This is strange and looks as some bug.
In my Poland networks I can connect only to that cell what I define in Cell Lock.

You discover in Cell Monitor that cells what are detected via direction & signals and. that bands what are active at lte module but they can be only 2 at ones. Means, CellMonitor is suitable when you use one band. I do in my scripts action like «set band=1,2; cell-comonitor lte1;» and after that change bands to next one like «set band=3,7; cell-comonitor lte1;» and at every 2bands I scan air.

This is what I can see in the lte log with the bands locked to only one (using the command /interface lte at-chat lte1 input=»AT*Cell=2,3,,37900,118″)

Another problem I have with the winbox is that I have never been able to download the .log file correctly, whenever I want to see the log on my desktop to be able to see it with the notes blog, the file does not have any content written inside (it is in White)

I understand that having control of the blocked bands I can only connect to that band and that is what I want, since a single frequency in a certain physical cell is the one that gives me the desired speed, but that cell changes from one moment to another from EARFCN and it leaves me without internet or it puts me in a terrible state where I can not even download at 100kbs, although it is the same antenna, since it comes from the same physical cell and has the same RSRQ and SINR parameters, so I have to disable the band lock command (cell + EARFCN) and then reactivate it but with the new EARFCN .

PD: I’m going to disable the lock command and in a few hours I’ll be back with the .log results.

Re: LTE operator problem?

Sat Feb 27, 2021 9:23 pm

I have deactivated the band blocking and this was the result during the connection, although it seems it was made to the same cell that I made the blocking, so I don’t think that there is a different reference in the log

what if it has happened is the same as always, when restarting the connection the internet returns to a high speed, I have been using your script to cancel the inactivity and apparently this has not served at all

and now as you can see in the image below you will notice that the EARFCN of cell # 118 has been changed (which is the one I use for cell lock), this is a constant problem that got me sick

Before (Yesterday)

Later (Today)

Is this really possible? that an internet provider company can rotate the frequencies and cells?

Re: LTE operator problem?

Tue Mar 02, 2021 6:46 am

I am very tired of having to restart the mikrotik from time to time to get my internet speed back to high, otherwise it is limited to a download speed of no more than 50kbs and restarting it is the only thing that «solves» the problem but it’s only for a short period of time, then I have to restart the mikrotik again . I’m really giving up and now I’m feeling like the mikrotik antennas are useless

Re: LTE operator problem?

Tue Mar 02, 2021 9:54 pm

Unfortunately it’s hard to judge whether it is a single-piece hardware fault of your LTE modem or a firmware bug. The fact that the operator name changes into a 6-digit number means something is terribly wrong, because the number would have to be a 5-digit one if it was just a minor issue of not translating the MNC (in the ccc-oo format where ccc is country code and oo is operator (network) code) into a network name properly. Also the fact that the mapping between frequency and sector ID changes indicates a problem with RAM or with software.

So I’d definitely recommend to raise a warranty claim with whoever has sold the LHG-R to you. What you experience is not normal.

Re: LTE operator problem?

Tue Mar 02, 2021 10:37 pm

@sindy: There’s nothing going ‘terribly wrong’, it’s just a translation error. Some countries use a 3-digit MNC (mobile network code) and MCC-MNC 732-716 matches DirecTV Colombia.

@JotaOS: What is happening with the changing EARFCN is weird. An EARFCN of 38100 indicates a center frequency of 2605MHz (2.605GHz). An EARFCN of 37900 indicates a center frequency of 2585MHz (2.585GHz). In most countries, government allows a telecom operator to acquire a license for a specific frequency for a duration of 5-10 years. This frequency definitely should not change every 10 minutes.

Re: LTE operator problem?

Wed Mar 03, 2021 7:47 am

Unfortunately it’s hard to judge whether it is a single-piece hardware fault of your LTE modem or a firmware bug. The fact that the operator name changes into a 6-digit number means something is terribly wrong, because the number would have to be a 5-digit one if it was just a minor issue of not translating the MNC (in the ccc-oo format where ccc is country code and oo is operator (network) code) into a network name properly. Also the fact that the mapping between frequency and sector ID changes indicates a problem with RAM or with software.

So I’d definitely recommend to raise a warranty claim with whoever has sold the LHG-R to you. What you experience is not normal.

How can I know the health of my lte antenna? because the command / system health print or / system health set (they do not work for my LHG LTE6 kit-MIPSBE)

Although I have started to notice since I update the firmware of the equipment that my router restarts every few hours (more or less every 11 hours), but the problem of the decrease in my internet speed has always been the same, from the first day who applied my sim card, tried with infinite script to maintain a false activity in my router but nothing, also tried to update the 3 types of firmware (lte, OS, winbox) possible from mikrotik and they did not serve me at all!

Re: LTE operator problem?

Wed Mar 03, 2021 10:24 am

This command only reports temperature, power supply voltage etc. on higher grade models, which support measurement of these values in hardware. It says nothing about hardware failures (like memory issues) even on those models.

So what do the following commands output currently?

/system resource print
/system routerboard print
/system check-installation
/interface lte firmware-upgrade [find] upgrade=no

The LTE modem is a plugin module and is quite autonomous; RouterOS retrieves the values displayed using /interface lte info from it using AT commands. So also the translation of the MCC+MNC value to text is done by the LTE modem itself:

[me@myTik] > /interface lte at-chat [find] input=»AT+COPS?»
output: +COPS: (0,0,»operator-name»,7,0),(0,0,»operator-name»,7,0)

Hence it is most likely that the issue is in the modem module itself; whether it is a manufacturing fault (hardware issue of that single piece) or a software one is hard to say and it cannot be determined having just a single device to test with.

The hardware design of the Routerboard allows to script a brutal workaround of your issue: whenever it appears (which in your case seems to be indicated by the change of the current-operator value from to DIRECTVCO to 732716), you can power-cycle the LTE modem. I have to do this with various types of non-Mikrotik 3G and LTE modems that hang occasionally and no firmware upgrade can be expected for them.

The command is /system routerboard usb power-reset bus= N duration=10s. You have to find the correct N value by trying, I couldn’t find how to determine the bus number using any information provided by RouterOS, and it depends on the RB model and PCIe slot where the modem is located.

So the script would look something like

You would schedule this script to run every minute. But as said, it is a workaround, not a solution.

Источник

Распространенные проблемы MikroTik

Распространенные проблемы MikroTik

Са­мая рас­простра­нен­ная проблема MikroTik (точнее жалоба) — «у меня ничего не работа­ет», при­чем чаще все­го это неп­равда. Если у бос­са не откры­вает­ся вло­жение в пись­ме с темой «вы выиг­рали мил­лион», потому что его заб­локиро­вал анти­вирус, то нас­тра­ивать роутер в этот день вряд ли при­дет­ся.

Поэто­му один из важ­ных навыков адми­на — это уме­ние вести диалог с поль­зовате­лем и выяс­нять, что имен­но и как не работа­ет. Увы, эта статья не будет посвящена данному вопросу, так что перехо­дим сра­зу к тех­ничес­кой час­ти.

Ресурсы

Пер­вое, на что обра­щает вни­мание любой сис­темный адми­нис­тра­тор, — пот­ребле­ние ресур­сов. Бла­го WinBox выводит эти дан­ные пря­мо в глав­ном окне. А если еще не выводит — сей­час же добав­ляй их туда. Это сэконо­мит мно­го вре­мени в будущем. Тебе нуж­но меню Dashboard → Add. И кста­ти, зеленый квад­ратик в пра­вой вер­хней час­ти — это не заг­рузка про­цес­сора. Не обра­щай на него вни­мания.

Ес­ли про­цес­сор пос­тоян­но заг­ружен боль­ше 80% (в зависи­мос­ти от усло­вий это зна­чение может менять­ся, но в сред­нем давай при­мем такое чис­ло), то что‑то нелад­но. В пер­вую оче­редь смот­рим на мес­тный «дис­петчер задач», меню Tools → Profile. Тут мы уви­дим, что имен­но наг­ружа­ет CPU, и пой­мем, как дей­ство­вать даль­ше.

Дли­тель­ную ста­тис­тику по наг­рузке CPU, тра­фику на интерфей­сах и дру­гим парамет­рам мож­но уви­деть в Tools → Graphing.

Объ­ясне­ние полей вы най­дете в вики. Наибо­лее час­то встре­чают­ся DNS, Encrypting и Firewall.

  • Encrypting — роутер тра­тит мно­го ресур­сов на шиф­рование. Ско­рее все­го, у вас мно­го тун­нелей VPN и нет аппа­рат­ного чипа шиф­рования. Нуж­но поменять на желез­ку со спе­циаль­ным чипом или выб­рать более сла­бые алго­рит­мы.
  • Firewall — пря­мое ука­зание, что вы не читали мои пре­дыду­щие статьи.
  • DNS — а вот тут вас ждет кое‑что инте­рес­ное.

Сам по себе DNS-сер­вер поч­ти не наг­ружа­ет роутер в неболь­ших и сред­них сетях (до нес­коль­ких тысяч хос­тов). А исполь­зовать RouterOS в качес­тве DNS-сер­вера в боль­ших сетях не луч­шая идея. Так отку­да наг­рузка? Давай раз­бирать­ся. Если есть наг­рузка, зна­чит что‑то ее соз­дает. Веро­ятно, сер­веру DNS при­ходит­ся отве­чать на боль­шое количес­тво зап­росов. Про­верим, так ли это. Соз­дадим в фай­рво­ле пра­вило.

И теперь смот­рим в лог. Если наши пред­положе­ния вер­ны, то заметим мно­го сооб­щений с пре­фик­сом DNS. Уви­дим, с каких адре­сов и на какие интерфей­сы летят зап­росы. Ско­рее все­го, это будет интерфейс WAN. Но мы не хотим обра­баты­вать DNS-зап­росы, при­шед­шие к нам из интерне­та. Зак­роем UDP-порт 53 на интерфей­се WAN, помес­тим пра­вило в нуж­ном мес­те — и нас­лажда­емся сни­зив­шей­ся наг­рузкой. Поз­драв­ляю! Мы толь­ко что обна­ружи­ли, что были частью бот­нета, зак­рыли эту дыру и сде­лали интернет чуточ­ку чище. Подоб­ные ата­ки час­то про­водят­ся с при­мене­нием про­токо­лов, работа­ющих над UDP.

Firewall

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

Counters

В стол­бцах Bytes и Packets отоб­ража­ются количес­тво бай­тов и пакетов, обра­ботан­ных пра­вилом. Кноп­ки Reset Counters сбра­сыва­ют эти счет­чики. Теперь мож­но наб­людать, попада­ет ли тра­фик в нуж­ное пра­вило или нет.

По­лез­ной час­то ока­зыва­ется вклад­ка Connections фай­рво­ла. Тут вид­но все потоки, про­ходя­щие через роутер: их сос­тояние, количес­тво про­шед­ших бай­тов, фла­ги потока (для получе­ния под­сказ­ки дос­таточ­но навес­ти на зна­чение в стол­бце). Для боль­шей наг­ляднос­ти нуж­но добавить поля Reply Dst. Address и Reply Src. Address. В этих полях вид­но, в какой и из какого адре­са был про­веден NAT.

Connections

Фай­рвол со все­ми его фичами поз­воля­ет деталь­но дебажить весь тра­фик, про­ходя­щий через роутер. Что­бы луч­ше понимать, что про­исхо­дит во всех этих вклад­ках, нуж­но изу­чить, как пакеты про­ходят через роутер. На кар­тинке упро­щен­ная вер­сия схе­мы. Бо­лее под­робная есть в докумен­тации.

Traffic Flow

Другие способы анализа трафика

Уви­деть сос­тояние потока, его адре­са, бай­ты и про­чее — хорошо. Но фай­рвол не поз­воля­ет удоб­но и из еди­ного мес­та убе­дить­ся, что мар­шру­тиза­ция кор­рек­тна. Что­бы узнать, в какой интерфейс вылета­ет пакет, дос­таточ­но вос­поль­зовать­ся инс­тру­мен­том Torch.

Torch

Torch мож­но вос­при­нимать как некое подобие tcpdump. Здесь мож­но уви­деть VLAN ID, source/destination address/port, DSCP, битовую и пакет­ную ско­рость. Есть удоб­ные филь­тры, которые поз­воля­ют делать точ­ные выбор­ки. Если дан­ные в окне меня­ются слиш­ком быс­тро, уве­личи­вай зна­чение Entry Timeout. К сожале­нию, в одном окне он может показы­вать толь­ко тра­фик на одном интерфей­се, но ник­то не меша­ет нажать New Window и наб­людать за нес­коль­кими интерфей­сами. Если Torch не показы­вает нуж­ного тра­фика на нуж­ном интерфей­се — налицо проб­лемы с мар­шру­тиза­цией.

Torch поз­воля­ет наб­людать за потока­ми тра­фика в реаль­ном вре­мени. Но в некото­рых слу­чаях нуж­ны более деталь­ные дан­ные о тра­фике. Их поз­воля­ет получить инс­тру­мент IP Sniffer.

С его помощью мож­но уви­деть парамет­ры тра­фика и даже содер­жимое пакета.

Но иног­да тре­бует­ся более деталь­ный ана­лиз — нап­ример, что­бы убе­дить­ся, что TCP handshake успешно про­шел и дан­ные переда­ются. В таком слу­чае в переда­ваемых пакетах дол­жен при­сутс­тво­вать флаг ACK. Но искать пакеты в скуд­ном интерфей­се «Вин­бокса» неудоб­но.

И тут на помощь при­ходит все­ми любимый Wireshark — мощ­ней­ший инс­тру­мент для ана­лиза сетево­го тра­фика. В Filter ука­зыва­ем нуж­ные парамет­ры, что­бы не сни­фать все под­ряд, в General выбира­ем Filename, жмем Apply и Start. Теперь в Files на роуте­ре мож­но най­ти наш дамп, переки­нуть его на компь­ютер и открыть «Шар­ком». О нем написа­но мно­го ста­тей, поэто­му даже не буду пытать­ся писать тут, как с ним работать.

Но это лишь начало. Мож­но в реаль­ном вре­мени наб­людать за тра­фиком из Wireshark. И без вся­ких опе­раций с фай­лами! Откры­ваем «Шарк», в филь­тре пишем udp . wbr / > port wbr / > == wbr / > 37008 , на сниф­фере RouterOS во вклад­ке Streaming ста­вим галоч­ку Streaming wbr / > Enabled и впи­сыва­ем IP-адрес компь­юте­ра с запущен­ным «Шар­ком». Мож­но пос­тавить галоч­ку Filter stream, что­бы лить в «Шарк» не весь тра­фик, а толь­ко выб­ранный.

Snif-stream Shark

Лить тра­фик в сниф­фер мож­но и из фай­рво­ла. За это отве­чает дей­ствие sniff-TZSP в таб­лице Mangle. Работа­ет это по ана­логии со Sniffer Streaming, но в фай­рво­ле мож­но сде­лать более точ­ную выбор­ку пакетов для сниф­фера.

Mangle-sniff

Wireless

Са­мая слож­ная часть диаг­ности­ки — это Wi-Fi. Он и сам по себе очень слож­ная тех­нология, к тому же сре­да переда­чи дан­ных общая и все сосед­ские роуте­ры меша­ют работать тво­ему, так же как и он им. О работе 802.11 написа­на не одна кни­га, перес­казывать их я не буду. Пос­мотрим толь­ко на инс­тру­мен­ты, которые могут помочь при диаг­ности­ке.

В RouterOS их нем­ного. Самый глав­ный — вклад­ка Registration в Wireless. Здесь вид­но всю информа­цию о под­клю­чен­ных кли­ентах: MAC, уро­вень сиг­нала, качес­тво сиг­нала.

Registration

Са­мые важ­ные поля:

  • CCQ — Client Connection Quality. Чем бли­же к 100%, тем луч­ше. Ниже 60% озна­чает пло­хую связь;
  • TX/RX Signal Strength — уро­вень сиг­нала. Отличное зна­чение — от 0 до –45, при­емле­мое — от –55 до –75. Все, что меж­ду, — хорошо. Ниже –75 мож­но счи­тать отсутс­тви­ем свя­зи. По край­ней мере, я ори­енти­руюсь на такие циф­ры.
  • Signal to Noise — отно­шение сиг­нал/шум. Чем выше — тем луч­ше.

Вто­рой инс­тру­мент — логи. Собс­твен­но, этот инс­тру­мент дол­жен активно исполь­зовать­ся не толь­ко при диаг­ности­ке Wi-Fi. Если стан­дар­тных логов недос­таточ­но — прос­то вклю­чи рас­ширен­ные.

Log

Ping, Traceroute

Пер­вым инс­тру­мен­том диаг­ности­ки у сисад­мина всег­да был пинг. Но далеко не все зна­ют, сколь­ко воз­можнос­тей он в себе скры­вает.

Мно­гие стал­кивались с тем, что текст на сай­те отоб­ража­ется, а кар­тинки нет. Или скрип­ты не заг­рузились, и сайт «поехал». Это пер­вые приз­наки несог­ласован­ности MTU. С помощью пин­га мож­но про­верить этот вари­ант. Ста­вим галоч­ку Don’t fragment, выс­тавля­ем нуж­ный нам раз­мер пакета и смот­рим на резуль­тат. Если видим packet wbr / > too wbr / > large — MTU в канале ниже задан­ного нами зна­чения пакета. Умень­шаем его и про­веря­ем сно­ва. Таким обра­зом выяв­ляем мак­сималь­ный пакет, который про­ходит через сеть без фраг­мента­ции.

Ping

По умол­чанию пакет отправ­ляет­ся с роуте­ра с src address того интерфей­са, в который он вылета­ет. Быва­ет, что нуж­но его поменять. Нап­ример, при диаг­ности­ке мар­шру­тиза­ции внут­ри VPN или кор­рек­тнос­ти работы фай­рво­ла. Для это­го нуж­но запол­нить поле src address. Не забывай, что адрес дол­жен быть сущес­тву­ющим, что­бы ответный пакет вер­нулся.

При слож­ной мар­шру­тиза­ции необ­ходимо выб­рать нуж­ную Routing Table. Впро­чем, те, кто поль­зует­ся нес­коль­кими таб­лицами мар­шру­тиза­ции, и так это зна­ют.

Заключение

Не­воз­можно в одной статье и даже в нес­коль­ких кни­гах опи­сать все воз­можные проб­лемы и методы их диаг­ности­ки и решения. Для эффектив­ного дебага нуж­но понимать, как работа­ет сеть на каж­дом уров­не, ее осо­бен­ности в кон­крет­ной реали­зации — ведь не быва­ет двух оди­нако­вых сетей: рецеп­ты, работа­ющие в одной инфраструк­туре, будут бес­полез­ными для дру­гой.

Для дебага необ­ходимо понимать, как пакет про­ходит внут­ри RouterOS, а в осо­бо слож­ных слу­чаях — и знать осо­бен­ности вен­дора. И это отно­сит­ся не толь­ко к MikroTik. Луч­ший инс­тру­мент дебага — зна­ния и опыт!

Источник

Хо­рошо нас­тро­ить роутер — важ­ное дело, но иног­да это­го быва­ет недос­таточ­но и при­ходит­ся решать проб­лемы уже во вре­мя экс­плу­ата­ции. О проблемах Mikrotik и как с ними спра­вить­ся, если вы или ваш клиент использует роутер MikroTik, мы и погово­рим в данной статье.

Содержание

  1. Распространенные проблемы MikroTik
  2. Ресурсы
  3. Firewall
  4. Другие способы анализа трафика
  5. Wireless
  6. Ping, Traceroute
  7. Заключение

Са­мая рас­простра­нен­ная проблема MikroTik (точнее жалоба) — «у меня ничего не работа­ет», при­чем чаще все­го это неп­равда. Если у бос­са не откры­вает­ся вло­жение в пись­ме с темой «вы выиг­рали мил­лион», потому что его заб­локиро­вал анти­вирус, то нас­тра­ивать роутер в этот день вряд ли при­дет­ся.

Еще на тему Микротик:

  • Настройка безопасности MikroTik
  • Настройка файрвола на примере Микротика
  • Блокировка сайтов в MikroTik без Layer7 Protocols

Поэто­му один из важ­ных навыков адми­на — это уме­ние вести диалог с поль­зовате­лем и выяс­нять, что имен­но и как не работа­ет. Увы, эта статья не будет посвящена данному вопросу, так что перехо­дим сра­зу к тех­ничес­кой час­ти.

Ресурсы

Пер­вое, на что обра­щает вни­мание любой сис­темный адми­нис­тра­тор, — пот­ребле­ние ресур­сов. Бла­го WinBox выводит эти дан­ные пря­мо в глав­ном окне. А если еще не выводит — сей­час же добав­ляй их туда. Это сэконо­мит мно­го вре­мени в будущем. Тебе нуж­но меню Dashboard → Add. И кста­ти, зеленый квад­ратик в пра­вой вер­хней час­ти — это не заг­рузка про­цес­сора. Не обра­щай на него вни­мания.

Resources

Resources

Ес­ли про­цес­сор пос­тоян­но заг­ружен боль­ше 80% (в зависи­мос­ти от усло­вий это зна­чение может менять­ся, но в сред­нем давай при­мем такое чис­ло), то что‑то нелад­но. В пер­вую оче­редь смот­рим на мес­тный «дис­петчер задач», меню Tools → Profile. Тут мы уви­дим, что имен­но наг­ружа­ет CPU, и пой­мем, как дей­ство­вать даль­ше.

Дли­тель­ную ста­тис­тику по наг­рузке CPU, тра­фику на интерфей­сах и дру­гим парамет­рам мож­но уви­деть в Tools → Graphing.

Profile

Profile

Объ­ясне­ние полей вы най­дете в вики. Наибо­лее час­то встре­чают­ся DNS, Encrypting и Firewall.

  • Encrypting — роутер тра­тит мно­го ресур­сов на шиф­рование. Ско­рее все­го, у вас мно­го тун­нелей VPN и нет аппа­рат­ного чипа шиф­рования. Нуж­но поменять на желез­ку со спе­циаль­ным чипом или выб­рать более сла­бые алго­рит­мы.
  • Firewall — пря­мое ука­зание, что вы не читали мои пре­дыду­щие статьи.
  • DNS — а вот тут вас ждет кое‑что инте­рес­ное.

Сам по себе DNS-сер­вер поч­ти не наг­ружа­ет роутер в неболь­ших и сред­них сетях (до нес­коль­ких тысяч хос­тов). А исполь­зовать RouterOS в качес­тве DNS-сер­вера в боль­ших сетях не луч­шая идея. Так отку­да наг­рузка? Давай раз­бирать­ся. Если есть наг­рузка, зна­чит что‑то ее соз­дает. Веро­ятно, сер­веру DNS при­ходит­ся отве­чать на боль­шое количес­тво зап­росов. Про­верим, так ли это. Соз­дадим в фай­рво­ле пра­вило.

/ip firewall filter

add action=accept chain=input dstport=53 log=yes logprefix=DNS protocol=udp

И теперь смот­рим в лог. Если наши пред­положе­ния вер­ны, то заметим мно­го сооб­щений с пре­фик­сом DNS. Уви­дим, с каких адре­сов и на какие интерфей­сы летят зап­росы. Ско­рее все­го, это будет интерфейс WAN. Но мы не хотим обра­баты­вать DNS-зап­росы, при­шед­шие к нам из интерне­та. Зак­роем UDP-порт 53 на интерфей­се WAN, помес­тим пра­вило в нуж­ном мес­те — и нас­лажда­емся сни­зив­шей­ся наг­рузкой. Поз­драв­ляю! Мы толь­ко что обна­ружи­ли, что были частью бот­нета, зак­рыли эту дыру и сде­лали интернет чуточ­ку чище. Подоб­ные ата­ки час­то про­водят­ся с при­мене­нием про­токо­лов, работа­ющих над UDP.

Firewall

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

Counters

Counters

В стол­бцах Bytes и Packets отоб­ража­ются количес­тво бай­тов и пакетов, обра­ботан­ных пра­вилом. Кноп­ки Reset Counters сбра­сыва­ют эти счет­чики. Теперь мож­но наб­людать, попада­ет ли тра­фик в нуж­ное пра­вило или нет.

По­лез­ной час­то ока­зыва­ется вклад­ка Connections фай­рво­ла. Тут вид­но все потоки, про­ходя­щие через роутер: их сос­тояние, количес­тво про­шед­ших бай­тов, фла­ги потока (для получе­ния под­сказ­ки дос­таточ­но навес­ти на зна­чение в стол­бце). Для боль­шей наг­ляднос­ти нуж­но добавить поля Reply Dst. Address и Reply Src. Address. В этих полях вид­но, в какой и из какого адре­са был про­веден NAT.

Connections

Connections

Фай­рвол со все­ми его фичами поз­воля­ет деталь­но дебажить весь тра­фик, про­ходя­щий через роутер. Что­бы луч­ше понимать, что про­исхо­дит во всех этих вклад­ках, нуж­но изу­чить, как пакеты про­ходят через роутер. На кар­тинке упро­щен­ная вер­сия схе­мы. Бо­лее под­робная есть в докумен­тации.

Traffic Flow

Traffic Flow

Другие способы анализа трафика

Уви­деть сос­тояние потока, его адре­са, бай­ты и про­чее — хорошо. Но фай­рвол не поз­воля­ет удоб­но и из еди­ного мес­та убе­дить­ся, что мар­шру­тиза­ция кор­рек­тна. Что­бы узнать, в какой интерфейс вылета­ет пакет, дос­таточ­но вос­поль­зовать­ся инс­тру­мен­том Torch.

Torch

Torch

Torch мож­но вос­при­нимать как некое подобие tcpdump. Здесь мож­но уви­деть VLAN ID, source/destination address/port, DSCP, битовую и пакет­ную ско­рость. Есть удоб­ные филь­тры, которые поз­воля­ют делать точ­ные выбор­ки. Если дан­ные в окне меня­ются слиш­ком быс­тро, уве­личи­вай зна­чение Entry Timeout. К сожале­нию, в одном окне он может показы­вать толь­ко тра­фик на одном интерфей­се, но ник­то не меша­ет нажать New Window и наб­людать за нес­коль­кими интерфей­сами. Если Torch не показы­вает нуж­ного тра­фика на нуж­ном интерфей­се — налицо проб­лемы с мар­шру­тиза­цией.

Torch поз­воля­ет наб­людать за потока­ми тра­фика в реаль­ном вре­мени. Но в некото­рых слу­чаях нуж­ны более деталь­ные дан­ные о тра­фике. Их поз­воля­ет получить инс­тру­мент IP Sniffer.

IP Sniffer

IP Sniffer

С его помощью мож­но уви­деть парамет­ры тра­фика и даже содер­жимое пакета.

Но иног­да тре­бует­ся более деталь­ный ана­лиз — нап­ример, что­бы убе­дить­ся, что TCP handshake успешно про­шел и дан­ные переда­ются. В таком слу­чае в переда­ваемых пакетах дол­жен при­сутс­тво­вать флаг ACK. Но искать пакеты в скуд­ном интерфей­се «Вин­бокса» неудоб­но.

И тут на помощь при­ходит все­ми любимый Wireshark — мощ­ней­ший инс­тру­мент для ана­лиза сетево­го тра­фика. В Filter ука­зыва­ем нуж­ные парамет­ры, что­бы не сни­фать все под­ряд, в General выбира­ем Filename, жмем Apply и Start. Теперь в Files на роуте­ре мож­но най­ти наш дамп, переки­нуть его на компь­ютер и открыть «Шар­ком». О нем написа­но мно­го ста­тей, поэто­му даже не буду пытать­ся писать тут, как с ним работать.

Но это лишь начало. Мож­но в реаль­ном вре­мени наб­людать за тра­фиком из Wireshark. И без вся­ких опе­раций с фай­лами! Откры­ваем «Шарк», в филь­тре пишем
udp.<wbr />port <wbr />== <wbr />37008, на сниф­фере RouterOS во вклад­ке Streaming ста­вим галоч­ку
Streaming <wbr />Enabled и впи­сыва­ем IP-адрес компь­юте­ра с запущен­ным «Шар­ком». Мож­но пос­тавить галоч­ку Filter stream, что­бы лить в «Шарк» не весь тра­фик, а толь­ко выб­ранный.

Snif-stream

Snif-stream
Shark
Shark

Лить тра­фик в сниф­фер мож­но и из фай­рво­ла. За это отве­чает дей­ствие sniff-TZSP в таб­лице Mangle. Работа­ет это по ана­логии со Sniffer Streaming, но в фай­рво­ле мож­но сде­лать более точ­ную выбор­ку пакетов для сниф­фера.

Mangle-sniff

Mangle-sniff

Wireless

Са­мая слож­ная часть диаг­ности­ки — это Wi-Fi. Он и сам по себе очень слож­ная тех­нология, к тому же сре­да переда­чи дан­ных общая и все сосед­ские роуте­ры меша­ют работать тво­ему, так же как и он им. О работе 802.11 написа­на не одна кни­га, перес­казывать их я не буду. Пос­мотрим толь­ко на инс­тру­мен­ты, которые могут помочь при диаг­ности­ке.

В RouterOS их нем­ного. Самый глав­ный — вклад­ка Registration в Wireless. Здесь вид­но всю информа­цию о под­клю­чен­ных кли­ентах: MAC, уро­вень сиг­нала, качес­тво сиг­нала.

Registration

Registration

Са­мые важ­ные поля:

  • CCQ — Client Connection Quality. Чем бли­же к 100%, тем луч­ше. Ниже 60% озна­чает пло­хую связь;
  • TX/RX Signal Strength — уро­вень сиг­нала. Отличное зна­чение — от 0 до –45, при­емле­мое — от –55 до –75. Все, что меж­ду, — хорошо. Ниже –75 мож­но счи­тать отсутс­тви­ем свя­зи. По край­ней мере, я ори­енти­руюсь на такие циф­ры.
  • Signal to Noise — отно­шение сиг­нал/шум. Чем выше — тем луч­ше.

Вто­рой инс­тру­мент — логи. Собс­твен­но, этот инс­тру­мент дол­жен активно исполь­зовать­ся не толь­ко при диаг­ности­ке Wi-Fi. Если стан­дар­тных логов недос­таточ­но — прос­то вклю­чи рас­ширен­ные.

Log

Log

Ping, Traceroute

Пер­вым инс­тру­мен­том диаг­ности­ки у сисад­мина всег­да был пинг. Но далеко не все зна­ют, сколь­ко воз­можнос­тей он в себе скры­вает.

Мно­гие стал­кивались с тем, что текст на сай­те отоб­ража­ется, а кар­тинки нет. Или скрип­ты не заг­рузились, и сайт «поехал». Это пер­вые приз­наки несог­ласован­ности MTU. С помощью пин­га мож­но про­верить этот вари­ант. Ста­вим галоч­ку Don’t fragment, выс­тавля­ем нуж­ный нам раз­мер пакета и смот­рим на резуль­тат. Если видим
packet <wbr />too <wbr />large — MTU в канале ниже задан­ного нами зна­чения пакета. Умень­шаем его и про­веря­ем сно­ва. Таким обра­зом выяв­ляем мак­сималь­ный пакет, который про­ходит через сеть без фраг­мента­ции.

Ping

Ping

По умол­чанию пакет отправ­ляет­ся с роуте­ра с src address того интерфей­са, в который он вылета­ет. Быва­ет, что нуж­но его поменять. Нап­ример, при диаг­ности­ке мар­шру­тиза­ции внут­ри VPN или кор­рек­тнос­ти работы фай­рво­ла. Для это­го нуж­но запол­нить поле src address. Не забывай, что адрес дол­жен быть сущес­тву­ющим, что­бы ответный пакет вер­нулся.

При слож­ной мар­шру­тиза­ции необ­ходимо выб­рать нуж­ную Routing Table. Впро­чем, те, кто поль­зует­ся нес­коль­кими таб­лицами мар­шру­тиза­ции, и так это зна­ют.

Заключение

Не­воз­можно в одной статье и даже в нес­коль­ких кни­гах опи­сать все воз­можные проб­лемы и методы их диаг­ности­ки и решения. Для эффектив­ного дебага нуж­но понимать, как работа­ет сеть на каж­дом уров­не, ее осо­бен­ности в кон­крет­ной реали­зации — ведь не быва­ет двух оди­нако­вых сетей: рецеп­ты, работа­ющие в одной инфраструк­туре, будут бес­полез­ными для дру­гой.

РЕКОМЕНДУЕМ:
Как защититься от руткитов в Linux

Для дебага необ­ходимо понимать, как пакет про­ходит внут­ри RouterOS, а в осо­бо слож­ных слу­чаях — и знать осо­бен­ности вен­дора. И это отно­сит­ся не толь­ко к MikroTik. Луч­ший инс­тру­мент дебага — зна­ния и опыт!

Загрузка…

srv8.vpn.zaborona.help

Оперативки он почти не занимает. Так и сделал. Скрипт создал список подсетей. Потом уже сам добавил правило маркировки трафика который идет к подсетям из етого списка, а затем в маршрутах весь маркированый трафик направил в тунель все заработало. Ну VK OK Yandex mail.ru так точно )))) Спасибо.
Может кому пригодится:
Создаем шедулер для обновления маршрутов раз в 3 дня.


/system scheduler
add interval=3d name=sync_uablacklist on-event="/system/script/run sync_uablacklist" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-date=dec/06/2021 start-time=05:00:00

Создем таблицу маршрутизации

/routing table
add fib name=zaborona

Правило маркировки трафика к IP адресам из списка.

/ip firewall mangle
add action=mark-routing chain=prerouting comment="Mark to zaborona" dst-address-list=uablacklist new-routing-mark=zaborona passthrough=yes

Маршрут маркированного трафика в интерфейс забороны.

/ip route
add comment="Route to zaborona" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=zaborona pref-src="" routing-table=zaborona scope=30 suppress-hw-offload=yes target-scope=10

Ну и сам скрипт добавляем и сразу запускаем.

/system script
add dont-require-permissions=no name=sync_uablacklist owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":local apiPrefix "https://uablacklist.
    net/subnets_mikrotik_"r
    n:local tempFile "uablacklist.txt"r
    n:local listName "uablacklist"r
    nr
    n/log info "removing existing '$listName'..."r
    n:put "removing existing '$listName'..."r
    n/ip firewall address-list remove [/ip firewall address-list find list=$listName]r
    nr
    n:local i 0r
    n:local isEnd falser
    n:do {r
    n    :local apiPath "$apiPrefix$i.txt"r
    n    /log info "fetching UA blacklist registry piece ($apiPath)..."r
    n    :put "fetching UA blacklist registry piece ($apiPath)..."r
    n    :local contentLen 0r
    n    :local content ""r
    n    :do {r
    n        /tool fetch url=$apiPath dst-path=$tempFiler
    n        :set content [/file get [/file find name=$tempFile] contents]r
    n        :set contentLen [:len $content]r
    n    } on-error={r
    n        /log info "no more pieces"; r
    n        :put "no more pieces"r
    n        :set isEnd truer
    n    }r
    n    :local lineEnd 0r
    n    :local line ""r
    n    :local lastEnd 0r
    n    :local company ""r
    n    :while ($lastEnd < $contentLen) do {r
    n        :set lineEnd [:find $content "\n" $lastEnd ]r
    n        :set line [:pick $content $lastEnd $lineEnd]r
    n        :set lastEnd ($lineEnd+1)r
    n        :local entry [:pick $line 0 ($lineEnd-1)]r
    n        :if ([:pick $line 0 1] != "#") do={r
    n            :if ([:len $entry ] > 0) do={r
    n                /log info "add '$entry' subnet of '$company' to list '$listName'...";r
    n                :put "add '$entry' subnet of '$company' to list '$listName'...";r
    n                :do {r
    n                    /ip firewall address-list add list=$listName address=$entry comment=$companyr
    n                } on-error={r
    n                    /log info "failed to add '$entry' subnet of '$company' to list '$listName', probably, it's duplication error."; r
    n                    :put "failed to add '$entry' subnet of '$company' to list '$listName', probably, it's duplication error."r
    n                }r
    n            }r
    n        } else={r
    n            :set company [:pick $line 2 ($lineEnd) ]r
    n        }r
    n    }r
    n    :set i (i+1)r
    n} while (!$isEnd)"

/system/script/run sync_uablacklist


P.S. Совсем забыл. У кого в фаерволе есть правило «fasttrac connection» его придется отключить, чтоб ето нормально работало. Так как fasttrac konnection позволяет трафику миновать большую часть фаервола, то маркировка трафика будет работать не корректно, заблокированные сайты будут открываться, но медленнее. Если же «fasttrac connection» все же нужен, тогда выход пока один, прописывать маршруты прямо в /ip routes к каждой подсети из списка забороны.

I don’t know if this can be of any help:

 15:24:35 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
15:24:35 dhcp,debug,packet     Broadcast-Address = 192.168.4.255 
15:24:35 dhcp,debug,packet     Domain-Server = 192.168.4.1 
15:24:35 dhcp,debug,packet     Router = 192.168.4.1 
15:24:35 dhcp,debug,state dhcp-client on ether5 entering <error> state 
15:24:36 dhcp,debug,packet dhcp-client on wlan1 sending discover with id xxxxx413 to 255.255.255.255 
15:24:36 dhcp,debug,packet     secs = 52 
15:24:36 dhcp,debug,packet     ciaddr = 0.0.0.0 
15:24:36 dhcp,debug,packet     chaddr = xx:xx:xx:xx:xx:x8 
15:24:36 dhcp,debug,packet     Msg-Type = discover 
15:24:36 dhcp,debug,packet     Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific 
15:24:36 dhcp,debug,packet dhcp-client on wlan1 received offer with id xxxxx5413 from 192.168.1.1 
15:24:36 dhcp,debug,packet     secs = 49 
15:24:36 dhcp,debug,packet     ciaddr = 0.0.0.0 
15:24:36 dhcp,debug,packet     yiaddr = 192.168.1.11 
15:24:36 dhcp,debug,packet     siaddr = 192.168.1.1 
15:24:36 dhcp,debug,packet     chaddr = xx:xx:xx:xx:xx:x8 
15:24:36 dhcp,debug,packet     Msg-Type = offer 
15:24:36 dhcp,debug,packet     Server-Id = 192.168.1.1 
15:24:36 dhcp,debug,packet     Address-Time = 3600 
15:24:36 dhcp,debug,packet     Renewal-Time = 1800 
15:24:36 dhcp,debug,packet     Rebinding-Time = 3150 
15:24:36 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
15:24:36 dhcp,debug,packet     Router = 192.168.1.1 
15:24:36 dhcp,debug,packet     Domain-Server = 192.168.1.1 
15:24:36 dhcp,debug,packet     NTP-Server = 192.168.1.1 
15:24:36 dhcp,debug,state dhcp-client on wlan1 entering <requesting...> state 
15:24:36 dhcp,debug,packet dhcp-client on wlan1 sending request with id xxxxx5413 to 255.255.255.255 
15:24:36 dhcp,debug,packet     secs = 52 
15:24:36 dhcp,debug,packet     ciaddr = 0.0.0.0 
15:24:36 dhcp,debug,packet     chaddr = xx:xx:xx:xx:xx:x8 
15:24:36 dhcp,debug,packet     Msg-Type = request 
15:24:36 dhcp,debug,packet     Server-Id = 192.168.1.1 
15:24:36 dhcp,debug,packet     Address-Request = 192.168.1.11 
15:24:36 dhcp,debug,packet     Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific 
15:24:37 dhcp,debug,packet dhcp-client on wlan1 received ack with id xxxxxx5413 from 192.168.1.1 
15:24:37 dhcp,debug,packet     secs = 52 
15:24:37 dhcp,debug,packet     ciaddr = 0.0.0.0 
15:24:37 dhcp,debug,packet     yiaddr = 192.168.1.11 
15:24:37 dhcp,debug,packet     siaddr = 192.168.1.1 
15:24:37 dhcp,debug,packet     chaddr = xx:xx:xx:xx:xx:x8 
15:24:37 dhcp,debug,packet     Msg-Type = ack 
15:24:37 dhcp,debug,packet     Server-Id = 192.168.1.1 
15:24:37 dhcp,debug,packet     Address-Time = 3600 
15:24:37 dhcp,debug,packet     Renewal-Time = 1800 
15:24:37 dhcp,debug,packet     Rebinding-Time = 3150 
15:24:37 dhcp,debug,packet     Subnet-Mask = 255.255.255.0 
15:24:37 dhcp,debug,packet     Router = 192.168.1.1 
15:24:37 dhcp,debug,packet     Domain-Server = 192.168.1.1 
15:24:37 dhcp,debug,packet     NTP-Server = 192.168.1.1 
15:24:37 dhcp,debug,state dhcp-client on wlan1 entering <error> state 
15:24:40 system,info sntp change time Mar/27/2021 15:24:37 => Mar/27/

Thanks

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Miflash error sending sparse
  • Miflash error cannot read from port
  • Microsoft sql server error 9001
  • Microsoft sql server error 233
  • Microsoft sql server error 229

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии