Перейти к содержимому
Калькуляторы

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

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

 

p.s. *** broadcom.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

P.S.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.