Jump to content
Калькуляторы

Счётчики на dlink-3200 пропадают пакеты, вероятно из-за буфера кадров

Прочитав тему http://forum.dlink.ru/viewtopic.php?f=2&t=143005&start=15 решил прогнать через 3200-18 гигабит трафик, один сервер подключил к одному гигабитному порту, второй к другому. Иногда(~раз в минуту) возникает небольшое кол-во дропов. Собственно вопрос в том, есть ли какие-то счётчики в этом свитче, которые показывают сколько дропнулось пакетов не из-за CRC?

Когда соединяю два сервера патчкордом или через другой свитч(edgecore), то дропов нет.

Share this post


Link to post
Share on other sites

покажи show error и show util ports

Share this post


Link to post
Share on other sites

В show error было пусто, show util ports завтра гляну, ip-управление для этого свитча не сделал.

Share this post


Link to post
Share on other sites

а какой хоть трафик гонялся ?

 

Уффф, блин. Да мне кажется, это не важно. Теперь точно покупать эту дрянь не будем (3200) - проблемы с хэшем, на гигабите спотыкается - что дальше?

Share this post


Link to post
Share on other sites

Гонялся tcp-трафик, дропалось небольшое кол-во пакетов на самом свитче. Сейчас некогда заниматься этой проблемой, к сожаленью. Как дойдут руки, исследую проблему подробнее(на udp-трафике). Ещё есть мысль погонять через него мультикаст(~500мбит) с одного GE на другой GE и поджойнить с FE-шных портов, тем более что есть "аппаратный" анализатор мультикаста.

В принципе, для не-реалтайм трафика пофигу небольшие дроп-рейты, проблема интересна тем, кто предоставляет сервисы voip и iptv.

Share this post


Link to post
Share on other sites

Я подозреваю тут как в школьном учебнике задача о двух трубах.

Вливается чуть быстрее чем выливается и происходят потери из-за переполнения буфера.

 

Страшно ли это? При нагрузке порта в "полку" потери пакетов могут происходить. В нормальной эксплуатации такого допускать никто не станет.

 

Таки буфер могли бы сделать и побольше...

 

Интересно, этот буфер общий или отдельный по портам?

Если общий - руки оторвать за экономию.

Share this post


Link to post
Share on other sites

Если общий - руки оторвать за экономию.

 

буфер общий, просто в нормальных ISP весь трафик считается и ограничивается по полосе неким вышестоящим устройством(допустим BRAS), которое как раз регулирует подачу(полисит/шейпит), .

единственный сервис который BRAS может не давать это IPTV.

в наших реалиях бёрсты постояны, т.к. много нелимитированного сервиса.

 

в предыдущей модели (DES-3526) буфер был 16Мб, но это была SDRAM память, и такие ситуации приводили только к увеличению задержки(но не дропу).

в новых же чипах эта память SRAM in SoC, быстрая, но очень дорогая, 16Мб не впаяешь.

 

p.s. *** broadcom.

Share this post


Link to post
Share on other sites

Может прошивку поменять.

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

Share this post


Link to post
Share on other sites

в наших реалиях бёрсты постояны, т.к. много нелимитированного сервиса.

Это как же надо набрать абонентов чтобы они съели 1 Гбит аплинка коммутатора на несколько минут? Тут надо уже агрегированные порты делать к ядру. Дать 2 Гбит.

 

А вообще, если Ваш берст достиг 1 Гбит к ядру и начались дропы - дропы от коммутатора в этом случае будут незначительными на фоне дропов от берстов, которые уже, считай, в гигабит не поместились. Они уже отрезаны где-то. Потому как я не верю, что все абоненты выдали чистое эталонное значение нагрузки 1 Гбит и только один коммутатор гадит.

 

P.S.

Экземпляр коммутатора с более медленными тактами попался? Или тут какая-то ошибка, приводящая к тому, что промежутки между пакетами больше?

 

Смена прошивки может и поможет...

Share this post


Link to post
Share on other sites

Может прошивку поменять.

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

 

Ну вообще говоря, от софта могут зависеть аппаратные фичи. В той же cisco есть несколько режимов распределения tcam - либо под одни задачи, либо под другие(сам "пощупал" на cat2960 и me3600). Чисто теоретически, буфер тоже может быть перераспределяемым.

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

Share this post


Link to post
Share on other sites

Я подозреваю тут как в школьном учебнике задача о двух трубах.

Вливается чуть быстрее чем выливается и происходят потери из-за переполнения буфера.

 

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

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

 

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

Например, в случае с общим буфером, нужно ограничивать число мультикаст-групп, которое позволено join-ить на 1 FE-порт. Если же out-буфер на каждый порт свой, то в принципе пофиг, дропы будут только у того абонента, кто извращается таким образом. С другой стороны, указано, что имеется по 4 очереди на порт, в моём понимании это подразумевает наличие 4ёх out-буферов ненулевой длины на каждый порт.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this