Наблюдаем интересную штуку. Стоит 3200-28, в стомегабитные порты включены клиенты, до них потери, хорошо видно на больших пакетах, например ping -s 64000. В гигабитный порт на гигабите включен 3526, в который тоже включены клиенты. До них никаких потерь нет. Пингую с с гигабитного порта 3200.
Если взять еще один 3526, включить его в гиговый порт 3200 на гигабите и переключить в него всех стомегабитных клиентов из 3200, то потери волшебным образом исчезают, и пакеты не теряются.
Это уже известная особенность 3200 или что-то новое? Прошивки пробовал разные: последний релиз и несколько новых бет.

Включение на портах Flow Control решает данную проблему.

_________________
С уважением,
Бигаров Руслан.

Действительно, включение flow control на гигабитных портах решило проблему, спасибо.

А почему с 3526 в точно такой же схеме нет подобной проблемы при выключенном управлении потоком и точно таком же трафике? Flow control не всегда можно использовать.

Изредка тоже жалуются абоненты на потери именно на коммутаторах этих.
Это рекомендация для всей серии 3200-хх ?
И включение на все портах или только на гигабитных?

На 3526 буфер больше, поэтому такой проблемы нет при тесте с пингом. Проблема появится при увеличении количества приходящих с гигабита пакетов.

flow control включать только на гигабитных.

А вот и первая проблема с flow control.
В кольце RSTP стоят рядом друг с другом DES-3200-28 и DES-3526. Соединены гигабитными портами. С выключенным FC на портах, смотрящих друг на друга, всё хорошо. Как только включаешь FC на обоих портах, начинаются жуткие потери. Куда смотреть?

Потери какого рода? sh error ports что показывает?

_________________
С уважением,
Бигаров Руслан.

Почти не ходят пинги до 3200, телнет на него тоже еле-еле ворочается, BPS/PPS на порту на порядок меньше, чем должен быть. "sh error port" на обоих портах показывает нули. Утилизация CPU на обоих свичах не больше 20%. На обоих портах автоопределение, завелось на 1000M/Full/802.3x. Соединены через MM SFP.
Сейчас залил в 3200 1.42.B001, в 3526 - 6.00-B51. Ничего не поменялось.

Дополнение: 3200-28 стоит после 3526.

Доброго дня. Провели эксперимент с DES-3200-10 (fw 1.42.B001).
В 10 и 1 порт включены по linux серверу - 1Гбит/с и 100 Мбит/с соответственно. Сервер, включенный в 10 порт посылает один icmp пакет с нагрузкой в 63638 байт. Пакет распадается на 43 фрейма по 1514 байт и один размером 42 байта. Последний фрейм теряется, но не всегда - примерно один раз на 4 проверки.
Коммутатор с default настройками, управление в отдельном vlan. При потерях счётчики пакетов на 10 порту показывают +44 RX пакета, на 1 - +43 TX, то есть последний теряется в свиче. Ошибок errors/drops коммутатор не пишет.

Выше писали что потери зависят от нагрузки - видимо всё-таки нет. Включение flow-control проблему решает - потерь нет - но использовать его не всегда возможно.

Это происходит потому, что коммутатор не может отдать пакеты на 100Мбит порт с той же скоростью, с которой они пришли в гигабитный. Поэтому пакеты и теряются, не успевают они отправляться.

Это понятно. Вопрос в другом: почему свич не сообщает о том, что он внутри себя дропнул пакет? Это кардинально усложняет диагностику и выявление проблем.
И что насчет проблемы с 3200 <-> 3526, описанной выше?

Для этого есть счётчик BufferFull Drop, он сообщает, что не хватает Buffer-ной памяти и пакетики отбрасываются.

Flow Control рекомендуется включать на клиентских портах, а не на магистральных, так как это может привести к подобным(т.е. которую Вы описали) проблемам.

Вы используете для теста ping(ICMP пакетики) большого размера, это, просто, для теста или у Вас в сети используются приложения, у которых размер пакета больше стандартного размера MTU 1500 байт?!

_________________
С уважением,
Бигаров Руслан.

Руслан, Ваш коллега несколькими постами выше написал, что flow control нужно включать на гигабитных портах. Это совершенно обратное Вашему утверждение. Кому верить?

И подскажите, пожалуйста, команду для просмотра счетчика BufferFull Drop на обсуждаемых свичах.

Большие ICMP мы используем для теста. Но это не значит, что результаты можно игнорировать. В конце концов нет разницы, прилетел это один 64к-пакет фрагментированный или в порт наливается пара сотен клиентских сессий на большой скорости.

1. Гигабитные порты - это не обязательно uplink-и!

2. sh error ports

3. Разницы нет, но всё зависит от общей нагрузки в сети и в частности магистрали и т.д.

_________________
С уважением,
Бигаров Руслан.

По гигабитным портам тогда непонятно. Если в гигабитный порт наливается трафик, который не успевает вылетать из стомегабитного, то какая польза от flow control на стомегабитном порту? pause-кадры то слать надо вышестоящему устройству с гигабитного порта.


Тут нет ничего похожего на BufferFull Drop, более того, тут одни нули.