s.lobanov Опубликовано 8 августа, 2011 · Жалоба Прочитав тему http://forum.dlink.ru/viewtopic.php?f=2&t=143005&start=15 решил прогнать через 3200-18 гигабит трафик, один сервер подключил к одному гигабитному порту, второй к другому. Иногда(~раз в минуту) возникает небольшое кол-во дропов. Собственно вопрос в том, есть ли какие-то счётчики в этом свитче, которые показывают сколько дропнулось пакетов не из-за CRC? Когда соединяю два сервера патчкордом или через другой свитч(edgecore), то дропов нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
detx Опубликовано 8 августа, 2011 · Жалоба покажи show error и show util ports Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 августа, 2011 · Жалоба В show error было пусто, show util ports завтра гляну, ip-управление для этого свитча не сделал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 8 августа, 2011 · Жалоба а какой хоть трафик гонялся ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 9 августа, 2011 · Жалоба а какой хоть трафик гонялся ? Уффф, блин. Да мне кажется, это не важно. Теперь точно покупать эту дрянь не будем (3200) - проблемы с хэшем, на гигабите спотыкается - что дальше? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 августа, 2011 · Жалоба Гонялся tcp-трафик, дропалось небольшое кол-во пакетов на самом свитче. Сейчас некогда заниматься этой проблемой, к сожаленью. Как дойдут руки, исследую проблему подробнее(на udp-трафике). Ещё есть мысль погонять через него мультикаст(~500мбит) с одного GE на другой GE и поджойнить с FE-шных портов, тем более что есть "аппаратный" анализатор мультикаста. В принципе, для не-реалтайм трафика пофигу небольшие дроп-рейты, проблема интересна тем, кто предоставляет сервисы voip и iptv. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 10 августа, 2011 · Жалоба Я подозреваю тут как в школьном учебнике задача о двух трубах. Вливается чуть быстрее чем выливается и происходят потери из-за переполнения буфера. Страшно ли это? При нагрузке порта в "полку" потери пакетов могут происходить. В нормальной эксплуатации такого допускать никто не станет. Таки буфер могли бы сделать и побольше... Интересно, этот буфер общий или отдельный по портам? Если общий - руки оторвать за экономию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 10 августа, 2011 · Жалоба Если общий - руки оторвать за экономию. буфер общий, просто в нормальных ISP весь трафик считается и ограничивается по полосе неким вышестоящим устройством(допустим BRAS), которое как раз регулирует подачу(полисит/шейпит), . единственный сервис который BRAS может не давать это IPTV. в наших реалиях бёрсты постояны, т.к. много нелимитированного сервиса. в предыдущей модели (DES-3526) буфер был 16Мб, но это была SDRAM память, и такие ситуации приводили только к увеличению задержки(но не дропу). в новых же чипах эта память SRAM in SoC, быстрая, но очень дорогая, 16Мб не впаяешь. p.s. *** broadcom. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aserder Опубликовано 10 августа, 2011 · Жалоба Может прошивку поменять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 10 августа, 2011 · Жалоба Может прошивку поменять. шутить изволите? тут как бы речь о железной проблеме, которая может стать куда более проблемной нежели штатная хренотень с хешами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 10 августа, 2011 · Жалоба в наших реалиях бёрсты постояны, т.к. много нелимитированного сервиса. Это как же надо набрать абонентов чтобы они съели 1 Гбит аплинка коммутатора на несколько минут? Тут надо уже агрегированные порты делать к ядру. Дать 2 Гбит. А вообще, если Ваш берст достиг 1 Гбит к ядру и начались дропы - дропы от коммутатора в этом случае будут незначительными на фоне дропов от берстов, которые уже, считай, в гигабит не поместились. Они уже отрезаны где-то. Потому как я не верю, что все абоненты выдали чистое эталонное значение нагрузки 1 Гбит и только один коммутатор гадит. P.S. Экземпляр коммутатора с более медленными тактами попался? Или тут какая-то ошибка, приводящая к тому, что промежутки между пакетами больше? Смена прошивки может и поможет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 августа, 2011 · Жалоба Может прошивку поменять. шутить изволите? тут как бы речь о железной проблеме, которая может стать куда более проблемной нежели штатная хренотень с хешами. Ну вообще говоря, от софта могут зависеть аппаратные фичи. В той же cisco есть несколько режимов распределения tcam - либо под одни задачи, либо под другие(сам "пощупал" на cat2960 и me3600). Чисто теоретически, буфер тоже может быть перераспределяемым. Хотя конкретно в этом случае я сомневаюсь, что можно подконфигурить какие-то регистры чипа, чтобы избежать дропов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 августа, 2011 · Жалоба Я подозреваю тут как в школьном учебнике задача о двух трубах. Вливается чуть быстрее чем выливается и происходят потери из-за переполнения буфера. Я тоже склоняюсь к этому вариант, т.е. получается, что сетевуха сервера генерирует электрические импульсы чуть-чуть быстрее, чем свитч сериализует на out-интерфейсе и буфер медленно, но верно наполняется и в какой-то момент переполняется. Теперь возвращаясь к изначальному вопросу этого топика, мне хотелось бы увидеть этот процесс с помощью счётчиков. Т.е. я либо должен увидеть % заполненности буфера, либо счётчик дропов из-за переполнения буфера. Далее, увидев этот счётчик, я хочу помоделировать различные ситуации, приближенные к реальным и посмотреть, когда он может переполнится. Например, в случае с общим буфером, нужно ограничивать число мультикаст-групп, которое позволено join-ить на 1 FE-порт. Если же out-буфер на каждый порт свой, то в принципе пофиг, дропы будут только у того абонента, кто извращается таким образом. С другой стороны, указано, что имеется по 4 очереди на порт, в моём понимании это подразумевает наличие 4ёх out-буферов ненулевой длины на каждый порт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...