Приветствую.
Часто в литературе попадаются термины, объяснения которым даются не совсем внятные и понятные для меня.

Например:
1) line-rate switching (wire speed switching, то же самое? )
2) L2 aging of entries (как я понял, это применяется к механизму управления таблицей соответствия <МАC-адрес>-порт)

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

Заранее благодарю.

Насчёт первого - не скажу, т.к. определения "line-rate switching" не встречал, в отличие от "wire speed switching"... По смыслу вроде то же самое.
А "L2 aging of entries" - время устаревания MAC адресов в таблице коммутатора.

Приветствую.

Спасибо, погуглил и разобрался с терминами. Вот еще вопрос, возможна такая ситуация в свитчах, когда пакет сидит в очереди и не может быть отфрварден на др. порт по той причине, что порт назначние занят обработкой другого пакета. И пакеты постепенно копятся в буфере. Это называется head-of-line blocking (HOL blocking), но вот нигде не нашел способов борьбы/предотвращения таких ситуаций. Очевидно, что простое увеличение размера буфера проблемы не решит.

Есть каие-то идеи на этот счет?

Поищите QoS. Разные приоритеты пакетов позволяют обслуживать их по-разному. Об этом есть у меня в статье об KS8842 на моем сайте www.iosifk.narod.ru в разделе статьи.
И посмотрите на сайте ЦИТ-форум. http://www.citforum.ru/
Удачи!

Очень просто. Существует технология Flow Control - управление потоком. В случае переполнения буфера коммутатор может начать посылать специальные пакеты PAUSE (IEEE802.3x для дуплексных соединений) или искуственно создавать коллизии (Backpressure flow control для полудуплексных соединений).



QoS не защищает от переполнения буфера, а только определяет приоритеты передачи для взвешивания трафа. Единственное чем может здесь помочь QoS - это WRED (Weighted Random Early Drop), техника сброса пакетов при приближении уровня заполненности буфера к некой критической отметке.

Способов борьбы не сильно много. Буферизовать до бесконечности не получится. В итоге варианта ровно три - увеличить скорость выходного канала (не очень реально, ибо она какая есть, такая есть), либо слать поменьше, либо ронять пакеты. Последние два подхода и рассмотрим.

Первый подход. Из практических вариантов, как мне кажется, тут только flow control. По прилету пакета, который кладется в почти полный буфер, источнику пакета отсылается flow control пакет, что, мол, погоди маленько и больше не шли в течение какого-то времени. Проблема в том, что посылающий может либо проигнорировать это дело, и продолжить слать. Вторая проблема, если он таки откладывает посылку пакетов, то это также задержит пакеты предназначеные для других, потенциально доступных портов.

Второй класс - выкидываем пакеты. Вопрос - какие именно?

Вариант А: Просто выкидывать последний прилетевший пакет (tail-drop). Если буфер маленький - убивает производительность TCP - просто жуть. Все из-за того, что уронили именно последние пакеты и принимающая сторона просто не знает, потерялись ли пакеты в дороге или их вообще не посылали.Зато в железе tail-drop реализуется относительно просто. В итоге - частое явление в дешевых устройствах.

Вариант Б: выкидываем произвольные пакеты из буфера (на ум приходит RED - random early detection). Чуть лучше, чем вариант А. На TCP влияет существенно меньше. Производительность падает, но не сильно смертельно. Принимающая сторона замечает пропажу пакетов и сообщает другому концу, что неплохо бы отослать потерявшееся еще раз.
Проблема - все равно роняем без разбора. Не все протоколы это хорошо переживают.

Вариант В - QoS (Quality of Service): разбиваем буффер на несколько и сортируем входящий траффик. Очень важные, но относительно редкие пакеты кладем в один буффер, частые, но не очень важные - в другой. Полностью проблему решает не всегда, но дает хоть какой-то контроль, что же именно мы предпочитаем терять.

Большое спасибо комментарии.

Как я понимаю, нет статических методов предупреждения/избжания HOL-blocking, то есть меры должны приниматься на всех уровнях, и на низком (MAC layer) и на более высоком (IP, вот еще вычитал про ECN-Explicit congestion notification).

И еще по терминам. Часто в описаниях L2/3 коммутирующих чипов встречаются два понятия:

1) integrated (например 5-port 10/100 integrated switch)
2) multi-layer ( например Broadcom BCM5645 ...)

Что они обозначают?

romez, ты уж не обижайся, но вопросы задаёшь такие, что описаны в любой книжке начального уровня по сетевым технологиям (например - "Компьютерные сети", авторы - Олиферы). Для интереса дал поиск в википедии - даже там это есть.

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

Кстати, в Олиферовской книжке не так много информации по свитчам (у меня 2002 года выпуска), несмотря на всю ценность книги. Поэтому я разыскиваю:

Rich Seifert, издательство Wiley, 2000год.
The Switch Book: The Complete Guide to LAN Switching Technology
Gigabit Ethernet : Technology and Applications for High-Speed LANs (Addison-Wesley Professional, 1998)

В e-mule нет, в русском переводе не встречал.

"Щупали"
16 портов 10/100, управляемый коммутатор. На базе ZL50416 (Zarlink).



Если найдёшь - положи плз на ФТП. Сам почитать их хочу.

Anritsu's "Must-Have Reference For IP and Next Generation Networking"

Положил в /upload/DOCs/Networking/musthave.pdf

Что-то за обилием постов конкретные вопросы как-то замылились. Ну вот на те, которые выудил из текста:

1. Wire-speed (line-rate...) - в общем, верно - коммутация на скорости пропускной способности. При этом гарантирована коммутация кадров даже в том случае, если они поступают с пиковой загрузкой, равной пропускной способности сегмента. Задержка на прохождение кадров через коммутатор (при условии, что кадр первый и очереди свободны) здесь фактически равна следующему: время поступления кадра в коммутатор + время выдачи кадра из коммутатора (т.е. зависит только от длины кадра и пропускной способности канала), само же вычисление маршрута практически задержки не вносит. Современные коммутаторы Ethernet 10/100 обычно разруливают траффик полноценно. Вычисление маршрута кадра происходит паралелльно самому процессу приема кадра. Т.е. на момент, когда кадр закончит поступать в коммутатор, его маршрут уже известен, и он сразу может поступать на выход (если, конечно в очереди никого нет). Однако для гигабитных сетей, производители иногда лукавят - для кадров большой длины действительно пропускная способность выдерживается высокой; но если плотным потоком будут поступать кадры с минимальной длиной, то скорее всего начнут появляться "дыры" и потери.

2. По поводу переполнения выходных буферов и QoS. В коммутаторах уровня 2 обычно все Quality of Service упирается в один механизм: best effort - "наилучшее усилие". В общем, тут используется принцип приоритетов: либо по портам, либо по тэгам кадров в соответствии с IEEE 802.1Q (раньше 802.1P). На практике это означает, что существует несколько выходных очередей на каждом порту, и пакет попадает в ту или иную очередь в соответствии со своим значением приоритета. Порядок выборки кадров из очередей зависит от реализации. Я когда-то делал по-простому: на 16 приоритетных кадров проходит 1 неприоритетный. Всего, кстати, таких приоритетов в соответствии с 802.1Q может быть не более 7. Но на практике в Ethernet коммутаторах реализуют не более 2 или 4 уровней.
В случае переполнения очереди кадры приходится уничтожать. Другого решения тут нет. Да, можно использовать механизмы управления потоком, но они в Ethernet "уведомительные", и передатчик может их проигнорировать. С другой стороны, при управлении потоком блокируется входной порт, причем целиком. - и надо иметь серьезные аргументы для того, чтобы из-за переполнения очереди выходного порта целиком блокировать поступление кадров с входного порта (а если совсем правильно - то со всех входных портов, потому как на выходной порт следующий кадр может прийти с любого из входных портов, и разместить его уже будет негде) - тем самым "залипание" по выходу одного потока может привести к перекрестной блокировке всех остальных потоков, не связанных с ним. Можно, конечно, пытаться глубже анализировать трафик, использовать специальные механизмы и т.п. - но это уже не будет Layer 2 switch. Поэтому решение простое - убивать. По поводу, что именно убивать? Здесь написали про последний кадр или случайный кадр. Имхо, уничтожать надо самый "древний" кадр, который дольше всех "живет" в коммутаторе. По моему опыту, TCP в таком случае легче и гибче разруливает ситуацию, происходит меньше ретрансмиссий и быстрее настраивается интенсивность потока. Хотя, строгого статистического анализа на разных типах трафика и разных загрузках я не проводил.

3. Integrated - интегрированный. Весь коммутатор на одном чипе. В отличие, скажем, от брэндовых Cisco или 3Com, которые любят "размазывать" свои коммутаторы по чипсету: процессор, коммутирующая матрица, контроллеры интерфейсов. Хотя, слово integrated применительно к Ethernet switch controller может иногда означать еще два момента: 1. интегрированы трансиверы физического уровня PHY (Tx); 2. интегрирована буферная память пакетов в чип.

4. Multi-layer - значит, не просто layer 2 чип, т.е. коммутатор, а еще может анализировать и более высокиий уровни - маршрутизатор на уровне 3 (IP), обрабатывать транспортные протоколы уровня 4 (TCP) и т.д. В качестве примера приведу один интересный чип - ADM5120. С одной стороны, это коммутатор уровня 2, но наличие ядра MIPS и шины PCI позволяет строить на этом чипе действительно многоуровневые сетевые устройства - шлюзы, сетевые экраны, точки доступа и т.д.

5. Да, про aging еще скажу. Это действительно устаревание MAC-адресов в адресной таблице. Устаревают только динамические MAC-адреса, которым коммутатор обучился автоматически в процессе работы и анализа трафика. Рекомендованное время устаревания 300с. Эта цифра, да и сам термин более подробно освещен в стандарте IEEE 802.1D - фактическом стандарте на коммутаторы и мосты уровня 2.

Сообщение отредактировал scheme_ru - Jan 17 2006, 15:59