[Torin]

Привет всем.

Как вы считаете, грамотно ли проверять сегмент сети на packetlost, пингуя коммутатор доступа в этом сегменте? Или надежнее поставить пинговалку на коммутатор доступа и мониторить по ней?

[Wingman]

Смотря что за коммутатор =) Например, 3526 в нормальных условиях должны вполне отлично пингаться пакетами по 65к

[s.lobanov]

Как вы считаете, грамотно ли проверять сегмент сети на packetlost

 

не грамотно. у большинства управляемых коммутаторов есть cpu rx limit, пинг коммутатора может просто дропнуться, при этом абонентский трафик будет ходить без проблем

[KotikBSd]

А смысл? если есть лост то на магистральных портах полюбому будут ошибки, нужно просто их мониторить :) ибо лост из неба не появляется, либо трафика больше чем может пропустить порт, либо коллизии, CRC и тп.

 

А пинговать свитч - не нужно, во первых это нагрузка на цпу, а во вторых лосты будут возникать когда цпу комутатора чем-то занято, и ответа не будет.

Изменено 5 декабря, 2012 пользователем KotikBSd

[s.lobanov]

А смысл? если есть лост то на магистральных портах полюбому будут ошибки, нужно просто их мониторить :) ибо лост из неба не появляется, либо трафика больше чем может пропустить порт, либо коллизии, CRC и тп.

 

Сам видел packet loss без коллизий и ошибок. Уровень сигнала был таким, что линк поднимался/был в состоянии up, но при этом трафика как бы не было(счётчик фреймов не увеличивался). Даже смог повторить эту ситуацию в лабе с помощью управляемого аттенюатора, правда только на одном spf-модуле(какой-то брендированный, не noname), обычно всё-таки линк падал или фиксировались crc-шки

 

Так что если канал действительно важный, то лучше поставить за ним какую-нибудь железку и её пинговать

[Torin]

Не совсем понятно, что такое cpu нагружающее должен делать коммутатор доступа, чтобы у него было drop icmp packet cause cpu load? Мне кажется, что при грамотной настройке коммутатора доступа, и если вендор жестко не сэкономил на камне, не должно быть такой ситуации?! А если и есть, то наверное даже хорошо - инженер обратит внимание, увидит, что траффик ходит нормально , но есть cpu load , начнет разбираться почему.

[s.lobanov]

Не совсем понятно, что такое cpu нагружающее должен делать коммутатор доступа, чтобы у него было drop icmp packet cause cpu load? Мне кажется, что при грамотной настройке коммутатора доступа, и если вендор жестко не сэкономил на камне, не должно быть такой ситуации?!

 

Тут скорее не от настройки зависит, а больше от дизайна сети. Да, в принципе при дизайне сети, когда софт-фич у вас минимум(не используются всякие dchp-snooping, arp inspection и т.п.), то загрузка CPU почти всегда будет близка к нулю. Но даже при таком "правильном" дизайне бывают случаи, когда CPU кратковременно загружен и может всё-таки дропнуть 1-2 пинга, например осуществляется бэкап конфигурации(хотя иногда он не требуется, если он полностью генерится по базе), инженер проводит какую-то диагностику, выполняя много разнообразных команд и т.п. Потом сиди и гадай из-за чего пинги пропали...

[Negator]

А зачем вам пинги по 65к? Если в реале столько не используете?

 

Уже очень давно мониторим коммутаторы:

1.Пингом по 1450.

2.Ошибки на портах.

Ну и cacti рисует много там всякого.

 

Вполне достаточно.

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

 

p.s. Для абонентов еще наверное скоро будем регулярно складывать в базу данный по длине линков -что со свича прилетели.