Диагностируем сетевую проблему по показаниям счетчиков

Когда вы сдаете медицинские анализы, можете ли вы самостоятельно расшифровать их? Лично я — нет. Даже если я буду знать отдельные показатели (например, уровень сахара) и их нормальные значения, картину в целом я не пойму. А вот врач сможет. Почему врач сможет, а я нет? Потому что он не просто знает, что это за показатели, но и умеет интерпретировать их значения в совокупности.
К чему я веду: посмотрите на скриншот и попробуйте сделать выводы из показаний этих счетчиков.

Нужно не перечисление: название счетчика — описание счетчика — показания счетчика. Вроде: Tx Collision — это счетчик коллизий со значением 13 958. Это неинтересно.
mikrotik tx stats
Интересно, какую информацию мы можем получить из совокупности показаний этих счетчиков. И это должна быть информация, которая явным образом не отображена в счетчиках. Пример: На основе того, что срабатывают счетчики коллизий, можно сделать вывод, что интерфейс работает в полудуплексном режиме. Эта информация явным образом не указана, но мы ее получили. Но это банальный вывод.
На самом деле по скриншоту можно определить наличие серьезной сетевой проблемы и даже сказать, из-за чего она возникла и что надо сделать для ее устранения. И сразу скажу, что если пара устройств работает в полудуплексном режиме, то это условная норма, а не «серьезная сетевая проблема». Ответ вроде «перевести оба устройства для работы в дуплекс» будет неинтересным.
1
Интерфейс осуществляет отправку трафика. Вывод сделан на основании того, что на вкладке Tx имеются показания счетчиков, отличные от нулевых.
2
На этом и на противоположном интерфейсе используются разные способы связи. Такой вывод сделан на основании того, что:
  • счетчик Tx Late Collision имеет значение, отличное от нулевого;
  • значение счетчика Tx Collision значительно превышает значение счетчика Tx Unicast. Несмотря на то что на счетчики «обычных» коллизий редко можно ориентироваться, здесь имеется явно аномальное соотношение показаний этих счетчиков.
3
На интерфейсе, для которого приведен скриншот, используется полудуплексный способ связи. Вывод сделан на основании того, что при использовании полнодуплексного способа связи обнаружение коллизий не работает и, как результат, счетчики коллизий будут иметь нулевые значения даже при наличии коллизий.
4
На противоположном интерфейсе используется полнодуплексный способ связи. Вывод сделан на основе совокупности выводов 2 и 3.
5
На интерфейсе, для которого приведен скриншот, и на противоположном интерфейсе используется статическое определение параметров соединения. Вывод сделан на основании того, что переход интерфейса в состояние Running при рассогласовании способов связи невозможен при автоопределении параметров соединения.
Распространено ошибочное мнение, что по показаниям счетчика Tx Late Collision можно определить, что имеется проблема с кабелем или имеются наводки. При проблемах с кабелем значение счетчика Tx Late Collision, как правило, не увеличивается, а с противоположной стороны начинают увеличиваться значения счетчиков Rx FCS Error и Rx Align Error. Смотрите скриншот.
Rx Stats
P. S. Разумеется, в моем углубленном онлайн-курсе по коммутации, еще больше информации о счетчиках и работе с их показаниями
Хотите научиться работать с MikroTik? В этом поможет углубленный курс по администрированию MikroTik. Получите демо-доступ к этому курсу бесплатно.