RB2011. Потеря пакетов при пинге себя.

Обсуждение оборудования и его настройки
Ответить
Gintoki
Сообщения: 9
Зарегистрирован: 05 ноя 2015, 12:49

Доброго времени суток всем!
Камрады, прошу помощи. Имеется следующая ситуация: Mikrotik RB2011 в офисе в качестве основного шлюза, pptp/ipsec-сервера, dns, dhcp etc. В общем, стандартно всё.
Имеются периодические проблемы с сетью. Как с wi-fi, так и с проводной (выяснилось на днях, так-то все на wi-fi).
Впервые было замечено, что роутер - при попытке пинговать самого себя - теряет пакеты и пинг высокий (в нормальном состоянии 0мс).
Отсюда вопрос - могут какие-либо настройки повлиять на роутер, вызвав такую ситуацию? Или же это скорее всего аппаратный дефект?

Код: Выделить всё

ping interface=br-local 192.168.13.1
sent=3220 received=3152 packet-loss=2% min-rtt=0ms avg-rtt=23ms max-rtt=71ms

Код: Выделить всё

[admin@MikroTik] > ip address print   
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         INTERFACE                                                                                                             
 0   192.168.13.1/26    192.168.13.0    br-local       

Код: Выделить всё

[admin@MikroTik] > interface bridge print 
Flags: X - disabled, R - running
 0  R name="br-local" mtu=auto actual-mtu=1400 l2mtu=1598 arp=proxy-arp arp-timeout=auto mac-address=E4:8D:8C:19:6A:FB protocol-mode=none priority=0x8000
      auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m

Это сегодня так(было, как минимум раз, и больше потерь пакетов). Обычно всё нормально - 0мс и без потерь.
Информация о роутере и режиме его работы(температура, например):

Код: Выделить всё

[admin@MikroTik] > system health print                 
         voltage: 24.2V
     temperature: 30C

Код: Выделить всё

[admin@MikroTik] > system resource print 
                   uptime: 1w2d22h11m29s
                  version: 6.37.3 (stable)
               build-time: Nov/28/2016 11:11:46
              free-memory: 91.0MiB
             total-memory: 128.0MiB
                      cpu: MIPS 74Kc V4.12
                cpu-count: 1
            cpu-frequency: 600MHz
                 cpu-load: 18%
           free-hdd-space: 109.7MiB
          total-hdd-space: 128.0MiB
  write-sect-since-reboot: 107904
         write-sect-total: 3077321
               bad-blocks: 0%
        architecture-name: mipsbe
               board-name: RB2011UiAS-2HnD
                 platform: MikroTik

Код: Выделить всё

[admin@MikroTik] > system resource cpu print 
 # CPU                                                               LOAD         IRQ        DISK
 0 cpu0                                                                 14%          8%          0%


DmNuts
Сообщения: 120
Зарегистрирован: 18 май 2016, 18:33
Откуда: Иркутск

Что в логах?
Пробовали на пустой конфигурации пинги слать (сбросить в blank, проверить, откатить обратно)?


Gintoki
Сообщения: 9
Зарегистрирован: 05 ноя 2015, 12:49

В логах ничего интересного, на первый взгляд. Помимо основных, добавлял ещё 'inteface, debug', 'system, debug'.
Сбрасывать конфиг и пробовать на дефолтном не довелось. Роутер постоянно в работе. Если только на выходных может выдаться возможность.


EdkiyGluk
Сообщения: 241
Зарегистрирован: 21 сен 2014, 08:34
Откуда: 34
Контактная информация:

Я бы подумал, что петля в сети (причём петля может быть и по воздуху... я так один раз остановил работу своего офиса на час, пока не понял что за дела такие)
Ваершарком просканить сеть на предмет броудкастового шторма. Или где-то какой-то проводочек неДоОбжат и сводит сеть с ума. Может плохая работа это не причина, а следствие..... Хотя нэтИнсталлом я бы по нему прошёлся)))
И ещё вопрос - как при этом ведут себя пинги между остальными устройствами в сети? т.к. у меня была примерно такая же ситуация. Сейчас постараюсь по возможности кратко рассказать.

============================
Делали монтаж видеоНаблюдения. Меняли одни камеры на другие... Камеры поставили.. всё ок.... Протестировал работу камер через впн... Уже собираемся уходить... БАХ... сетка начинает медленно, но верно ложится..... Пинг по воздуху до роутера около 1000... потом пинговаться вообще перестал... Другие устройства пингуются так же..... Думали думали - нашли растоптанную витуху... Заменили.. всё живёт... ГАХ... тоже самое... 4 часа репу чесали... Меняли свичи, меняли микротик на другой.... В итоге - когда тестировал последнюю камеру через впн, не отключился от её вебМорды на удалёнке и она постоянно гоняла трафик... Нагрузка на проц при этом от 15 до 50, но стоило закрыть браузер на той стороне и всё пришло в норму. Ситуацию удавалось воспроизвести несколько раз. И именно через вебМорду если на камеру зайти, через CMS всё ок. Простая нагрузка VPN трафиком (гонял бэндсвич тестом через впн к удалённому компу на винде) к такому не приводила, а вот именно эта камера и именно через вебМорду - нагибала сеть по полной..... Ваершарк никаких барабашек не показывал, всё ок.....


Аватара пользователя
Vlad-2
Модератор
Сообщения: 2531
Зарегистрирован: 08 апр 2016, 19:19
Откуда: Петропавловск-Камчатский (п-ов Камчатка)
Контактная информация:

Кстати, на счёт петель в сети, с пару прошивок назад - сделали в прошивке защиту от петель -- Loop-Protect опцию,
и она есть не только для ether портов,но и для виланов тоже.
Я включил её, правда интервалы не 5 минут как по дефолту идут, а поменьше сделал,
и как в пургу (чаще) или когда дёргаются (замыкают) свитчи у местного провайдера - сразу
микротик порт в защиту переводит, отключает его и потом опять включает.
Советую применить опцию, думаю при грамотном использовании - будет польза.



На работе(ах): 2xCCR1016-12G, RB3011UiAS и hAP lite (RB941)
Дома: CCR1016-12G, RBcAP2n (standalone), RB wAP LTE kit
Для тестов(под рукой): RB3011UiAS, hAP mini (RB931) и что-то ещё по мелочи
MTCNA
MTCRE
Gintoki
Сообщения: 9
Зарегистрирован: 05 ноя 2015, 12:49

EdkiyGluk писал(а):Я бы подумал, что петля в сети (причём петля может быть и по воздуху... я так один раз остановил работу своего офиса на час, пока не понял что за дела такие)
Ваершарком просканить сеть на предмет броудкастового шторма. Или где-то какой-то проводочек неДоОбжат и сводит сеть с ума. Может плохая работа это не причина, а следствие..... Хотя нэтИнсталлом я бы по нему прошёлся)))
И ещё вопрос - как при этом ведут себя пинги между остальными устройствами в сети? т.к. у меня была примерно такая же ситуация. Сейчас постараюсь по возможности кратко рассказать.


Сегодня сеть вела себя более-менее. При пинге самого себя из ~2000 пакетов потерялось 17 и средний пинг был порядка 15мс. (хотя и это не нормально ни разу, я считаю)
Пинг других клиентов оказался вообще отличным. Каждому было отправлено ~150 пакетов. Ни одной потери, единичные всплески до 200-250мс. Но среднее время составило 3-7мс.
Вопрос про недообжатый провод - какую он может играть роль при пинге самого себя? Ведь всё действие, насколько я понимаю, происходит внутри одной микросхемы. Пакеты пределов роутера не покидают.

Vlad-2 писал(а):Кстати, на счёт петель в сети, с пару прошивок назад - сделали в прошивке защиту от петель -- Loop-Protect опцию,
и она есть не только для ether портов,но и для виланов тоже.


Спасибо за это. Решил сразу включить эту опцию.

Ps. Кстати, VPN-клиенты не жалуются на высокий пинг или сильные потери пакетов. Может, конечно, внимания не обращают просто. Хотя, через VPN клиенты не весь трафик гоняют (снимают чекбокс "использовать основной шлюз в удалённой сети"), а только локальные ресурсы пользуют - git, redmine, ssh на сервера. Тут можно и не заметить просто этого.


Gintoki
Сообщения: 9
Зарегистрирован: 05 ноя 2015, 12:49

Проблема решена. Спешу поделиться с общественностью!)
Дело было в шейпере. В глубины шейпинга траффика я никогда не углублялся. Разницу между типами очередей представлял весьма поверхностно. Поэтому, делая ограничение скорости пользователям, выбрал Simple Queue с типом default-small. Когда пользователь забивал выделенный ему лимит канала - срабатывал шейпер и начинал дропать лишнее (что в буфер не умещалось). Для юзера это выглядело как страшные лаги инета и чудовищные потери пакетов вплоть до 40%.
Сейчас сменил тип очереди на pcq-upload-default/pcq-download-default. Стало намного лучше. Потери (вроде бы)прекратились, пинг при забивании канала в большинстве случаев становится равномерным ~80-100мс. Хотя по-прежнему и всплески бывают до 2с.
В общем и целом я рад, что дело было не в железе. Особенно если учесть, что гарантия истекла :-)
Всем спасибо за помощь в решении этой проблемы! :-):


Ответить