ЧИТАЕМ АНАЛИЗЫ В предыдущем посте я дал скриншот, по которому | MikroTik сэнсэй
ЧИТАЕМ АНАЛИЗЫ
В предыдущем посте я дал скриншот, по которому предложил сделать выводы. Настало время моих ответов.
Интерфейс осуществляет отправку трафика. Вывод сделан на основании того, что на вкладке Tx имеются показания счетчиков, отличные от нулевых.
На этом и на противоположном интерфейсе используются разные способы связи. Такой вывод сделан на основании того, что:
* счетчик Tx Late Collision имеет значение, отличное от нулевого;
* значение счетчика Tx Collision значительно превышает значение счетчика Tx Unicast. Несмотря на то что на счетчики «обычных» коллизий редко можно ориентироваться, здесь имеется явно аномальное соотношение показаний этих счетчиков.
На интерфейсе, для которого приведен скриншот, используется полудуплексный способ связи. Вывод сделан на основании того, что при использовании полнодуплексного способа связи обнаружение коллизий не работает и, как результат, счетчики коллизий будут иметь нулевые значения даже при наличии коллизий.
На противоположном интерфейсе используется полнодуплексный способ связи. Вывод сделан на основе совокупности выводов 2 и 3.
На интерфейсе, для которого приведен скриншот, и на противоположном интерфейсе используется статическое определение параметров соединения. Вывод сделан на основании того, что переход интерфейса в состояние Running при рассогласовании способов связи невозможен при автоопределении параметров соединения.
Распространено ошибочное мнение, что по показаниям счетчика Tx Late Collision можно определить, что имеется проблема с кабелем или имеются наводки. При проблемах с кабелем значение счетчика Tx Late Collision, как правило, не увеличивается, а с противоположной стороны начинают увеличиваться значения счетчиков Rx FCS Error и Rx Align Error. Смотрите скриншот.
=====
Комментарии пишите не в чате @kursy_po_it, а в комментариях к посту на канале @mikrotik_sensei. Это поможет избежать путаницы и гарантирует, что ваше сообщение будет отнесено туда, куда и следует.
