[romez777 0]

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

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

 

Например:

1) line-rate switching (wire speed switching, то же самое? )

2) L2 aging of entries (как я понял, это применяется к механизму управления таблицей соответствия <МАC-адрес>-порт)

 

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

 

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

[klogg 0]

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

А "L2 aging of entries" - время устаревания MAC адресов в таблице коммутатора.

[romez777 0]

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

А "L2 aging of entries" - время устаревания MAC адресов в таблице коммутатора.

 

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

 

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

 

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

[iosifk 3]

Насчёт первого - не скажу, т.к. определения "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/

Удачи!

[klogg 0]

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

 

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

 

Поищите QoS. Разные приоритеты пакетов позволяют обслуживать их по-разному.

 

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

[xyzzy 0]

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

 

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

 

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

 

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

 

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

 

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

 

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

Проблема - все равно роняем без разбора. Не все протоколы это хорошо переживают.

 

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

[romez777 0]

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

 

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

 

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

 

1) integrated (например 5-port 10/100 integrated switch)

2) multi-layer ( например Broadcom BCM5645 ...)

 

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

[klogg 0]

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

 

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

[romez777 0]

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 нет, в русском переводе не встречал.

[klogg 0]

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

 

"Щупали" :)

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

 

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)

 

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

[klogg 0]

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

 

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

[scheme_ru 0]

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

 

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.

Изменено 17 января, 2006 пользователем scheme_ru