+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Возможна ли ситуация, что подряд выходит из строя 3 роутера?

Возможна ли ситуация, что подряд выходит из строя 3 роутера?, RouterOS

inteq

Guest

01.06.2020 08:55:00

Привет! У меня есть FTTH-точка, где интернет периодически пропадает на время от 10 секунд до 2 минут, в случайные моменты, от 1 до 4 раз в день. В логах ничего — никаких сбоев интерфейса. Источник питания — онлайн-UPS. Первый маршрутизатор: RB4011. Так как роутер пару раз падал, я подумал, что именно он вызывает эти случайные отключения интернета. Поменял его. Второй роутер: RB1100AHx4. Новый патч-корд. Сбои продолжились. Купил ещё один. Третий роутер: RB1100AHx4. Новый патч-корд. Отключения остались. Самое смешное, что провайдер утверждает, что на ONT всё в порядке, ошибок не видят. Интересный момент: когда они впервые сказали, что с соединением всё нормально и ONT давно онлайн, я просто отсоединил оптоволоконный кабель на 5 минут, оставив ONT включённым. Потом, когда я снова открыл заявку, они опять сказали то же самое. Представляете? Вопрос в том: у кого из вас была такая невезуха — подряд три бракованных роутера?

inteq

Guest

23.06.2020 18:59:00

Подытожим: 3 RouterBOARD в чисто маршрутизируемой конфигурации, без NAT, без DHCP, без STP, даже проверяли без моста — случаются случайные потери пакетов длительностью от нескольких секунд до минуты. Сделали тест с одной настройкой интерфейса с публичным IP, без маршрутизации и всего прочего — тоже случайные потери пакетов. Компьютер с сетевой картой Intel — без маршрутизации, просто с публичным IP, и никаких потерь пакетов. Тот же компьютер, но с дополнительной сетевой картой Intel и установленным IPFire. Та же конфигурация, что и на 3 RouterBOARD: маршрутизация без NAT и DHCP. Ни одного потерянного пакета. Один из «проблемных» RouterBOARD отправили в другое место, но с включёнными NAT и DHCP — потерь пакетов не было. Немного странно, но не настройка NAT/маскарадинга и использование только маршрутизации может вызывать потери пакетов на RB1100AHx4? Минимальная конфигурация, при которой всё равно случаются случайные потери пакетов. Настроен только один интерфейс. Без NAT и всего остального.

# jun/18/2020 21:53:08 by RouterOS 6.47
# software id = ASE2-1E2N
# model = RB1100x4
# serial number = 91D80A0C859E

/interface ethernet switch port
set 0 default-vlan-id=0
set 1 default-vlan-id=0
set 2 default-vlan-id=0
set 3 default-vlan-id=0
set 4 default-vlan-id=0
set 5 default-vlan-id=0
set 6 default-vlan-id=0
set 7 default-vlan-id=0
set 8 default-vlan-id=0
set 9 default-vlan-id=0
set 10 default-vlan-id=0
set 11 default-vlan-id=0
set 12 default-vlan-id=0
set 13 default-vlan-id=0
set 14 default-vlan-id=0
set 15 default-vlan-id=0

/interface list
add name=WAN
add name=Local

/ip neighbor discovery-settings
set discover-interface-list=Local

/interface list member
add interface=ether1 list=WAN
add interface=ether2 list=Local

/ip address
add address=x.x.206.92/24 interface=ether1 network=x.x.206.0

/ip dns
set servers=1.1.1.1

/ip firewall filter
add action=drop chain=input comment="Drop invalid " connection-state=invalid
add action=accept chain=input comment="Accept established and related" connection-state=established,related
add action=accept chain=input comment="Accept icmp" protocol=icmp
add action=drop chain=input comment="Drop everything else" in-interface-list=!Local

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes

/ip route
add distance=1 gateway=x.x.206.1

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/system clock
set time-zone-name=Europe/Bucharest

/system logging
set 3 action=disk

/system routerboard settings
set auto-upgrade=yes

/tool mac-server
set allowed-interface-list=none

/tool mac-server mac-winbox
set allowed-interface-list=Local

Dude аутaж:

hostclub

Guest

23.06.2020 20:55:00

Если кто-то еще скажет, что Mikrotik в этом плане не отстой… Я вижу, что роутеры Mikrotik на ARM CPU имеют проблем больше, чем на Tilera. Учитывая, что следующее поколение роутеров Mikrotik будет только на ARM… жду тёмные времена для Mikrotik.

Sob Guest	#4 0 23.06.2020 23:06:00 Можешь попробовать отключить правило «drop invalid». Вряд ли в этом дело, но раз в твоей конфигурации больше ничего нет…

sindy

Guest

24.06.2020 06:32:00

Что показывает команда /interface ethernet print stats на проблемном объекте? Что происходит, если поставить простой коммутатор между оборудованием провайдера и WAN-интерфейсом 1100 там (статистика показывает только ошибки приема на локальном интерфейсе, но не может показать ошибки приема на другом конце кабеля)? Мне кажется, это проблема совместимости интерфейсов.

inteq

Guest

24.06.2020 09:16:00

@sob Я пробовал без правила Drop invalid, как советовал @tippenring здесь http://forum.mikrotik.com/t/stop-making-customers-lab-rats/140660/29 — без изменений. @sindy Придётся переустановить RB1100AHx4, чтобы проверить /interface ethernet print stats, но если не ошибаюсь, там были ошибки RX, заметные на экране статистики интерфейсов в Winbox. Протестирую с простым коммутатором и сообщу результаты. Ещё хотел отметить, что проверял несколько портов, затронув все три коммутатора на RB, чтобы максимально исключить неисправность порта. Тестировал на ether1, 6 и 11. Также пробовал снизить частоту CPU с 1400 до 1200 — без изменений. Всем спасибо за ответы.

nje431

Guest

24.06.2020 12:00:00

Знаю, что это пальцем в небо, но попробуй отключить 1000/half в режиме автоопределения скорости. Чип коммутатора не поддерживает эту опцию, а если у твоего провайдера есть такая… Я у себя отключил везде, и с тех пор соединение стало намного стабильнее. Хотя, может, мне просто кажется.

mkx

Guest

16.07.2020 05:35:00

Это запущено на вашем пограничном шлюзе? Первый хоп, который показывает traceroute, уже роутер за устройством, с которого запускается traceroute. Если это ваш пограничный шлюз, то значит, что ваша линия дает сбой. При таком количестве разных устройств с одинаковыми симптомами это может быть действительно проблема в линии... или в оборудовании провайдера. Вот почему мне нравится держать часть оборудования провайдера у себя дома — тогда линия между оборудованием провайдера и моим пограничным шлюзом четко определена и легко заменяема (патчкордом).

sindy

Guest

24.06.2020 13:41:00

Меня не волнует, используешь ли ты Winbox, WebFig или командную строку для проверки статистики Ethernet-порта. Но если ты видишь любые Rx-ошибки на Ethernet, то смысл искать потерю пакетов где-то в другом месте практически отсутствует. Rx-ошибка означает, что пакет уронили сразу при приёме с линии, и точка. На Ethernet нет автоисправления — пакет с неправильным CRC просто не пропускают. Я не имел в виду заводской брак на одном порте (или чипе свитча) модели 1100. Я говорил о проблеме проектирования — электрической несовместимости портов 1100 и порта устройства провайдера или, как бы ни показалось это странным, механической несовместимости между разъёмами патчкорда и одного из устройств. У меня есть несколько заводских патчкордов (то есть не обжатых своими руками), которые не работают в моём hAP ac lite, но отлично идут в моём ПК. Другие патчкорды из того же заказа, отличающиеся только цветом кабеля, работают в обоих устройствах.

inteq

Guest

#10

25.06.2020 01:43:00

Переустановил третий RB1100AHx4 сегодня вечером и не пришлось ждать дольше двух часов до первого прерывания. На этот раз оно длилось 2 минуты, как сообщил Dude. Пока использовал 4 разных заводских обжатых Ethernet-кабеля и один Cat 6, сделанный мной.
/interface ethernet print stats, снятые после первого случая, показывают:

Статистика после 11 часов работы:

quackyo

Guest

#11

26.06.2020 08:45:00

Скорее всего, у вашего провайдера проблемы. Но на всякий случай попробуйте отключить мониторинг вашего роутера через Dude. У меня были проблемы с RB1100AHx4, которые, по всей видимости, вызваны именно мониторингом через Dude.

sindy

Guest

#12

26.06.2020 10:42:00

На самом деле на стороне 1100 вообще нет ошибок приема. К сожалению (или к счастью?), это всё равно не означает, что проблемы с L1 нет. Поэтому, если можешь поставить простой свитч между 1100 и портом провайдера — сделай это. Если проблема останется, оставь этот простой свитч и вместо 1100 подключи что-то, что ты уже проверял и что работает, чтобы убедиться, что сам свитч не конфликтует с оборудованием провайдера.

inteq

Guest

#13

17.06.2020 07:42:00

Извиняюсь за повтор, но ситуация странная. Установил второй RB1100AHx4 (тот, что куплен после первого RB4011) в другом месте. Тот же провайдер, та же технология FTTH. Прошло уже 2 недели, и всё абсолютно стабильно. Потерь пакетов вообще нет. Настроил ПК с intel NIC вместо третьего RB1100AHx4 в проблемном месте, разрешив только входящий ICMP. Чтобы сымитировать трафик, каждые 10 минут запускаю speedtest-cli. Уже 2 дня — ни одной потери пакета, и при входящем, и при исходящем трафике. Мониторю с двух внешних точек с помощью инструмента, который пингует каждую секунду с таймаутом в 1 секунду. Ни одного потерянного пинга. С обоими RB1100AHx4 за эти 2 дня я бы уже потерял сотни пингов. Совсем не знаю, что и думать по этому поводу.

anav

Guest

#14

17.06.2020 17:53:00

Понимаю твою боль. У меня похожие проблемы с RB450Gx4, только ещё более коварные — уже больше двух лет, но я списывал это на особенности интернета (гарантия давно закончилась). Значительные потери пакетов при трассировке до шлюзов обоих моих провайдеров. Win MTR показывает потери. Поток трафика явно имел промежутки без передачи и приёма, но при этом в логах роутера не было ни слова о том, что он был недоступен. Я только что сделал переустановку и выложу результаты трассировки до шлюза ISP, WinMTR до google.ca, а также снимок с пробелов, который я сделал раньше — там видно, что у одного провайдера пробелов нет, а у другого они огромные. Никаких изменений! Сначала использовал прошивку 6.46.6, сейчас — 6.45.9, разницы нет!
https://imgur.com/1y5Gd9s
https://imgur.com/DYPJGH4
https://imgur.com/OHdK0RH

Sob

Guest

#15

17.06.2020 18:34:00

@anav: Твои данные о потере пакетов вводят в заблуждение. Это может быть один длинный провал, как на твоём графике, да. Но если запустить тест дольше, картина будет намного лучше. Провайдеры тоже могут ограничивать скорость ICMP. Невозможно годами пользоваться соединением с постоянной потерей пакетов в 40 или 60%. Но я бы всё же винил провайдера, а не роутер. Конечно, если такое происходит с двумя роутерами, это уже подозрительно. В любом случае, ты сам сказал, что у тебя будет другой роутер, так что на всякий случай можешь сбросить этот, сделать минимальную конфигурацию (только два подсети и больше ничего) и протестировать в своей локальной сети: подключи к нему один компьютер и запусти копирование чего-то большого между ним и устройством в другой подсети (основной LAN). Посмотри, будут ли тогда такие же провалы.

mkx

Guest

#16

16.07.2020 08:26:00

Я упоминал border gateway (без буквы P)… В сложных сетевых схемах может быть несколько маршрутизаторов, но обычно только один — это border gateway/router, который служит точкой разграничения между вашей локальной сетью и остальной частью интернета. В любом случае, я бы сказал, что проблема в ONT или в оптоволокне между ONT и провайдером… Особенно учитывая, что вы специально сделали разрыв связи (отключили оптическое соединение) в контролируемых условиях, а провайдер при этом утверждает, что всё в порядке…

sindy

Guest

#17

16.07.2020 08:47:00

Единственный аргумент против этого предположения в том, что тест с устройством, не связанным с RouterOS, как описано в посте №2, не показал никаких проблем в течение двух дней, но я считаю этот аргумент достаточно убедительным. @inteq, что будет, если просто пинговать шлюз с arp-ping=yes и интервалом 100 мс вместо использования traceroute?

inteq

Guest

#18

15.07.2020 19:46:00

Это уже начинает становиться совсем абсурдно. Я поставил четвёртый Mikrotik на объекте — RB1100AHx4 Dude Edition. Проблема всё равно остаётся. Купил лицензию P-Unlimited CHR и поставил RouterOS внутри ESXi на сервер Supermicro с Intel X722 NIC. Проблема всё та же.

Настроил Netwatch, чтобы при неудачном пинге по трём целям запускался скрипт traceroute и записывал лог для каждого инцидента:
:execute {/tool traceroute 1.1.1.1 duration=5} file=("traceroute 1.1.1.1 from ".[/system identity get name] . " on " . [:pick [/system clock get time] 0 8] . " - " . [:pick [/system clock get date] 7 11] . [:pick [/system clock get date] 0 3] . [:pick [/system clock get date] 4 6])

Генерируется имя файла: traceroute 1.1.1.1 from ros-esxi on 13:23:33 - 2020jul15.txt (не смог разобраться, как отформатировать дату — приходится скачивать файл через ssh из-за двоеточий в времени).

Когда проблема возникает, содержимое файла почти пустое, что немного странно:

Начинаю подозревать, что это место какое-то проклятое.

sindy Guest	#19 0 15.07.2020 20:11:00 Неудивительно, если тебе поручили подключить руины Поенари к интернету.

inteq Guest	#20 0 16.07.2020 05:59:00 Без BGP. Просто провайдер > ONT > Mikrotik. Прямое подключение IP на одном порту и подсеть на другом порту. Netwatch и скрипт запущены на Mikrotik. Простая схема

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры