Mikrotik: пропадает пинг до шлюза по кабелю. В чем может быть причина?

Question

[Spotegg]

Есть Mikrotik RB3011UIAS-RM, прошивка 6.47.10 stable, 2 WAN от двух разных провайдеров, адрес микрота 192.168.1.1, бридж 192.168.1.1/23. Во всех кабинетах стоит неуправляемый коммутатор, в который приходит кабель канал передачи данных (КПД) от провайдера. В эти неуправляемые коммутаторы в кабинетах подключены точки cAP ac и через CAPSMAN они работают в бесшовной сети. Микрот по DHCP раздает адреса всем клиентам.
Порты микрота:
eth1 - WAN от провайдера №1
eht2 - WAN от провайдера №2
eth5 - канал передачи данных(КПД) к провайдеру №1.
eth9 - напрямую подключенный компьютер 192.168.0.30

• комп 192.168.0.30 (подключен напрямую в микрот eht9) пингует и шлюз 192.168.1.1, и принтер 192.168.1.230 и точку 192.168.0.253 всегда
  
• ноут 192.168.1.101 (подключен по wifi к точке, которая подключена к коммутатору, который через КПД подключен к роутеру) пингует и шлюз 192.168.1.1, и принтер 192.168.1.230 и точку 192.168.0.253 всегда
  

НО периодически в течении рабочего дня

• комп 192.168.0.40 (подключен к коммутатору, который через КПД подключен к роутеру) перестает пинговать шлюз 192.168.1.1, но при этом пингует принтер 192.168.1.220 и точку 192.168.0.252, которые находятся в другом кабинете(этот кабинет тоже подключен через КПД)
  
• ноут 192.168.1.100 (подключен к коммутатору, который через КПД подключен к роутеру) перестает пинговать шлюз 192.168.1.1, но при этом пингует принтер 192.168.1.220 и точку 192.168.0.252, которые находятся в другом кабинете(этот кабинет тоже подключен через КПД)
  

И такая картина во всех кабинетах. Посреди дня компьютеры в кабинетах, подключенные по кабелю перестают пинговать шлюз. При чем в одном кабинете комп №1 пингует шлюз, но стоит ему уйти в сон или передернуть кабель в ethernet разъем, как тут же пинг до шлюза пропадает. Получается, что часть компов в одном и том же кабинете какое-то время с инетом, а часть компов/ноутов(вышли из сна, или ноут вернулся с обеда) без него. И в конце концов инет пропадает по кабелю во всех кабинетах, которые подключены по КПД. В это же время у компа, подключенного напрямую в микротик пинг до шлюза есть и интернет тоже.

После 19-20 вечера(основная часть сотрудников БЦ уходит) пинг сам по себе появляется по всех кабинетах без каких-либо перезагрузок микротика или неуправляемых коммутаторов.

Провайдер приезжал тестировал, охренел с этой проблемы и сказал, что дело в микротике или в какой-то петле. Сказал, что их КПД чистый L2, и с ним никаких проблем нет. При этом провайдер посмотрел настройки микротика и сказал, что все вроде бы ОК.

Сегодня мы по очереди посреди дня выключали/включали на 5 мин коммутаторы во всех кабинетах(пытаясь найти петлю или взбесившееся устройство) и пинговали шлюз с другого кабинета - пинга так и не было.

Понятно, что сеть на неуправляемых коммутаторах плоха, но тут такие особенности БЦ, что они не дают прокладывать свою СКС, а заставляют пользоваться текущей. Учитывая все вышесказанное, какие могут быть варианты решения проблемы? Петли вроде как нет, в логах микрота никаких ошибок, провайдер говорит с их КПД все в порядке... Посоветуйте пожалуйста куда копать.

Answer 1

[hint000]

Посоветуйте пожалуйста куда копать

Копайте в сторону конфликта IP-адресов (выдаваемых по DHCP).
Например, когда 192.168.1.100 перестанет пинговать шлюз, то попробуйте со шлюза пинговать 192.168.1.100.
И с разных других компьютеров пинговать 192.168.1.100.
И если такой пинг пройдёт, то отключите (физически) 192.168.1.100 от сети и снова проверьте пинги до него с разных компов.
Вдруг обнаружите, что кто-то по этому адресу отвечает, даже когда комп отключен от сети.

Comments

[Spotegg]

Попробую, но пинг пропадает к шлюзу со всех компов в разных кабинетах(напомню, что каждый кабинет подключён к микроту через свой КПД провайдера). Разве конфликт 1-2 устройств может так положить сеть? В микротике в разделе leases наблюдал conflict, но на 1 мак-адресе и не всегда этот конфликт появлялся, когда возникает проблема с пингом шлюза

[hint000]

Spotegg, теоретически проблема может быть в кривой настройке на стороне провайдера. Конфликты могут быть с устройствами не из вашей сети, это могут быть устройства другого клиента провайдера. И сколько устройств конфликтуют пока неизвестно. Сейчас важно установить, имеет ли место сам факт конфликта. А если имеет место, то найти MAC-адреса конфликтующих устройств и сравнить с MAC-адресами ваших устройств.

[fpir]

сравните arp cash компа который пингует шлюз и arp cash компа который не пингует. Возможно в сети появляется устройство адресом шлюза. А вообще, очень странная схема локальной сети. У провайдера в сети такие приколы бывают, он сам плохо знает, что там у него творится. А ещё учитывая, что подавляющее большинство его сотрудников не понимают сети на уровне масок.....

Answer 2

[Zzzz9]

В схеме, черная дыра с надписью "Провадер#1", вы не справитесь без участия сторонних сил.

Comments

[Spotegg]

Провайдер присылал 2 специалистов, которые полдня вместе с нами проверяли все, попутно общаясь с со своими инженерами. По итогу они развели руками - наш КПД работает, ваши точки через capsman работают по КПД, значит с ним проблем нет.
Они выяснили, что если отключить бридж или выключить на нем RSTP, то пинги появляются, но потом через пару часов снова пинг пропадает

Answer 3

[Дмитрий]

Сколько всего устройств в сети, с учетом WiFi-клиентов? У провайдеров может быть ограничение на количество mac-адресов, одновременно допустимых в L2 VPN. Поэтому всегда лучше на концах таких каналов держать какие-то свои маршрутизаторы, которые будут инкапсулировать передаваемый трафик. Хорошо бы уточнить у провайдера у провайдера этот момент.
Если есть техническая возможность, попробуйте точки CAP использовать в этом качестве (завернув трафик локалки например в EoIP), хотя бы для теста, у них два проводных интерфейса, насколько я помню. Кстати CAPSMAN в зависимости от настроек тоже может инкапсулировать трафик WiFi-клиентов.

Comments

[fpir]

Честно говоря, только недавно узнал про такую фигню, как EoIP на микротиках, как раз в ходе разбора похожего факапа. Нет, дело было не в EoIP, но он создал условия, при которых факап стал возможным. Я-бы не стал его никому советовать.

[Дмитрий]

fpir, почему? Технология в принципе нормально работающая. Если понимать, что есть ограничения и возможные подводные камни.

[fpir]

Дмитрий, при EoIP у вас более одного дефолтного шлюза в одной подсети, не вижу в этом преимуществ, зато полно вариантов, как всё поломать. Просто, как синяя изолента, но не стоит её использовать без крайней необходимости.