LINUX.ORG.RU
ФорумAdmin

Свитч перестаёт нормально работать при подключении роутера

 , ,


0

1

Здравствуйте товарищи!

Вопрос не столько по администрированию Linux-систем, сколько по сетям, и их отладке и настройке с помощью Linux-систем :)

Исходные данные:

В организации есть:

  • Неуправляемый свитч на 48 портов (марку и модель записать забыл, добавлю позже, сейчас пишу уже из дома), к которому подключены по проводам некоторое количество рабочих станций на Linux, MacOS и Windows.
  • Роутер MikroTik hEX RB750Gr3 (на RouterOS), через который заходит интернет
  • Несколько Wifi-тарелок MikroTik подключённые также к свитчу

Настроено это всё по мануалам из интернета, знания у меня в сетях чуть выше чем «продвинутый пользователь», никаких научных степеней по MTCNA конечно нет. Всевозможные «защиты от взлома» постарался настроить (например эти: https://habr.com/ru/post/424433/), веб-морду из интернета закрыл, так же как и все остальные службы.

Проблема:

Долгое время работало прекрасно, но в какой-то момент стало просто тупо пропадать подключение, и даже не через WiFi а прямо по проводам. То всё работает, то не работает ничего, не пингуется ни соседний ПК, ни сам роутер на 192.168.1.1, не идёт трассировка никуда, а то и вовсе arp -a ничего не возвращает.

Что было сделано для анализа:

  • Попробовал перезагрузить роутер и свитч несколько раз - не помогло. Точнее помогало, но ненадолго, минут на 10.
  • Проанализировал логи роутера, а также всех WiFi-тарелок. Ничего опасного или даже интересного там не было.
  • Проанализировал записи /system sheduler, /ip proxy, /ip socks, /ppp secret роутера - ничего не нашлось.
  • Два ноутбука подключил короткими проводами непосредственно к свитчу, на одном поднял сервер iperf, на другом запустил простенький скрипт:
# Бесконечно проверять скорость с частотой раз в 0.5 секунды
while true; do iperf -c 192.168.1.121 -p 5001 -i 0.5; done

При подключении ноутбуков к свитчу скорость по iperf то была около 100 МБит, но временами, раз в несколько секунд, резко просаживалась до нуля или почти до нуля, после чего снова возрастая до 100МБит.

  • Попробовал подключить эти два ноутбука к свободным выходным портам роутера - там никаких просадок скорости не было, всё отлично.
  • Достал маленький свитч на 5 портов, воткнул его проводом в большой свитч, переткнул два ноутбука в маленький свитч - точно также, просадки скорости.
  • Отключил провод соединяющий маленький свитч с большим, т.е. ноутбуки остались сидеть на маленьком свитче в одиночестве, и скорость, естественно, не проседала а шла стабильно около 100МБит. При повторном подключении мелкого свитча к большому - скорость снова начинала периодически проседать.

Итого я сделал вывод, достойный капитана очевидность, о том, что похоже проблема в свитче, я слышал о каких то flood-ах сети (хотя и не очень представляю принципов), и подумал, что может какой-то ПК не даёт жить остальным.

  • Стал отключать потребителей от большого свитча, тем временем глядя на то как меняются показания iperf.

  • Обнаружил, что iperf начинает стабильно показывать почти 100 МБит когда отключён САМ РОУТЕР.

  • Ещё раз перепроверил все настройки роутера в которых я что-то понимал, долго и вдумчиво посмотрел на те, которых я не понимаю.

  • Пробовал подключать роутер не напрямую в большой свитч, а «сквозь» маленький. Безрезультатно.

  • Параллельно прогуглил весь интернет, но похоже я даже не могу сформулировать вопрос так чтобы найти его на английском (на русском и подавно)

Ну и собственно, сотрудники разошлись, и проблема стала сходить на нет, когда осталось совсем мало народу, проседание скорости были уже не до 0 а до 60-70 МБит, и проблему больше не получалось воспроизвести.

Что хотелось бы понять (но не получается):

  1. Бывают ли такие flood-атаки (пусть даже и не «специальные») которые могут привести к такому поведению свитча?

  2. Какими инструментами можно это проверить? Как их найти? Я конечно пробовал включить wireshark, но в сети такой объём пакетов, что понять в них что-то можно только статистическим анализом, сдампив несколько гигов этих пакетов, и написав скрипты для анализа, что я наверное буду делать в случае если вообще ничего больше не поможет.

  3. Как можно проверить что в свитче есть проблема? Как его можно «отладить» если он неуправляемый? На мысль что дело не в нём меня навело то, что при подключении его к новенькому 5-портовому свитчу, он его «заражал» своим странным поведением. Но может это он как-то неверно реагирует на передаваемые данные и сам устраивает какой-то flood?

  4. Может быть есть какие-то «кривые» пакеты которые могут приводить к таким результатам? Откуда они могут браться? Как их обнаружить, как отладить?

Понимаю что на эти вопросы я должен знать ответы изучив стек сетевой стек TCP/IP до основания, устройство низкоуровневых протоколов и т.д., но я не сетевик, поэтому прошу помощи у более опытных товарищей.

Посмотри объем широковещательного трафика (запусти wireshark без promiscous режима).

А вообще, рекомендую поменять свитч на управляемый (из бюджетных SNR’ы хорошо себя показывают).

Harliff ★★★★★ ()
Ответ на: комментарий от Harliff

Посмотри объем широковещательного трафика

Спасибо, попробую

А вообще, рекомендую поменять свитч на управляемый

Всегда считал что «управляемый свитч» это что-то крутое для Data-центра, не для маленькой офисной сети, а тот что есть - он уже есть :) Да, посмотрел, варианты есть и не особо дорогие, попробую двинуться в этом направлении

MihanEntalpo ()
Ответ на: комментарий от MihanEntalpo

Всегда считал что «управляемый свитч» это что-то крутое для Data-центра, не для маленькой офисной сети

Для 5 компьютеров - да, для 30 - уже лучше брать управляемый.

Harliff ★★★★★ ()

Возможно напишу и глупость. Но косвенно навеяло поведение при arp spoofing. Без управляемого свитча, единственное что приходит в голову мониторить arp и изменения на оконечном оборудовании. Так же вы написали что отключали пользователей сегментами. После отключения каждого сегмента отправляйте свитч в ребут.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)

Всё зависит от модели свича. Если там дохлый пакетный буфер, то не удивительно, что широковещательный трафик кладет его на лопатки. Тупые свичи нужны для подключения оконечных клиентов. Связывать ими какие-то элементы агрегации или, упаси Боже, ядра сети - не стоит. От слова совсем.

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

Например все клиенты указывают шлюзом роутер, а он делает куда-то ICMP-редиректы, которые игнорируются клиентами, но сильно повышают объемы трафика в сети(лечится либо донастройкой клиентов, либо отключением ICMP-редиректов на роутере).

То всё работает, то не работает ничего, не пингуется ни соседний ПК, ни сам роутер на 192.168.1.1, не идёт трассировка никуда, а то и вовсе arp -a ничего не возвращает.

Хм, хотя не, похоже просто засран чем-то сегмент, скорее всего широковещательным трафиком. Но на петлю не похоже, там обычно arp хоть какой-то виден. Хотя без tcpdump-а или wireshark-а это всё опять же - гадание на кофейной гуще.

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от MihanEntalpo

Всегда считал что «управляемый свитч» это что-то крутое для Data-центра, не для маленькой офисной сети, а тот что есть - он уже есть :)

Стоит различать неуправляемые(«тупые»), L2-свичи и L3-свичи. L3-свич - это как раз для датацентров, по сути это практически многопортовые роутеры(правда роутеры ценового сегмента для датацентров зачастую умеют несколько больше, но для простоты понимания такой аналогии достаточно). А вот L2-свич даже в небольшой сети(25-50 компов) вполне может дать выигрыш по производительности. Как минимум тем что у них обычно пакетные буфера больше чем у тупых свичей.

Ну и ловить(и чинить) петлю управляемым свичом обычно гораздо проще. Но это преимущество обычно работает когда сеть одна, а свичей несколько. Тогда в ворохе тупых свичей найти петлю можно только последовательно отключая порты - ибо никакого интерфейса борьбы или даже сигнализации а-ля «петля тут!» непредусмотрено.

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от upcFrost

Пардон, оговорился. Правильнее будет говорить «Управляемый L2-свич». Прежде всего с возможность работы с VLAN через консоль/веб-интерфейс. Про то что хабы не выпускают уже лет 15 я как бы в курсе.

И нет, может я и странный, но старенькие Compex-ы, где VLAN-ами можно было управлять путем тумблеров-перемычек сбоку свича(sic!) я управляемыми L2-свичами не считаю.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от anc

навеяло поведение при arp spoofing

После отключения каждого сегмента отправляйте свитч в ребут.

Самое интересное то, что отключение роутера от свитча мгновенно улучшает ситуацию.

Сегодня попробую помониторить широковещательные пакеты. Может и правда роутер начинает забивать сеть ARP-пакетами со скоростью света. Пока всё работает хорошо, сбоев нет (как вчера пропали с уходом сотрудников, так и не вернулись пока).

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

MihanEntalpo ()
Ответ на: комментарий от MihanEntalpo

Самое интересное то, что отключение роутера от свитча мгновенно улучшает ситуацию.

Я поэтому и написал про arp spoofing. Ситуация достаточно похожа. Если это так то надо искать устройства в сети которые этим занимаются. Роутер тут не причем.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от MihanEntalpo

Всегда считал что «управляемый свитч» это что-то крутое для Data-центра, не для маленькой офисной сети

Статистика трафика по портам полезна всегда, наличие возможности отзеркалировать любой порт на порт, где у тебя компьютер с wireshark тоже штука полезная.

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

AS ★★★★★ ()
Ответ на: комментарий от MihanEntalpo

как вчера пропали с уходом сотрудников, так и не вернулись пока

А сотрудники точно сегодня те же, что и вчера? Может, кто-то заболел и не вышел на работу?

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

А сотрудники точно сегодня те же, что и вчера? Может, кто-то заболел и не вышел на работу?

Пришли всё те же. Даже больше чем вчера. За весь день проблема не повторилась ни разу.

Видимо я принес достаточную жертву богам хаоса просидев половину рабочего дня в серверной коморке, и они решили что достаточно.

Причин почему всё наладилось объективных не вижу :)

Также буду ждать повторения.

MihanEntalpo ()