[nuclearcat]

Это не offloading, это было еще на 100мбитных "fxp" :-)

Myri так не считает.

http://www.myri.com/Myri-10G/10gbe_solutions.html

 

Offloads. The driver and NIC firmware implement zero-copy on the send side with all supported operating systems, and, depending on the OS, use a variety of stateless offloads, including:

 

* Interrupt Coalescing

 

Мне известны такие виды offloading-а: подсчет всевозможных контрольных сумм, сегментация tcp (теоретически не только tcp). Ни один из них для транзитного трафика нафиг не нужен.

Может расскажете, что подходящее придумали для транзитного трафика ?

_Проверка_ контрольных сумм тоже offloading, иногда транзитные пакеты имеют свойство биться, а поврежденный пакет роутить - дело неблагодарное.

 

 

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

Писюки бывают и 32-х процессорные, но несовершенство Linux/FreeBSD не даст использовать его потенциал как роутера на все 100%. Ну и не факт, что такой писюк дешевле "железного" роутера обойдется.

Они хоть и многопроцессорные, то в лучшем случае у них NUMA архитектура. Раком конечно можно разбросать прерывания с 10G на много процессоров (карточки 10G с MSI это технически умеют), но в итоге смысла в этом будет весьма мало, потому как когда встанет вопрос обмена данными между нодами - "роутеру" поплохеет. Да и самое главное - латентность памяти, шин и прочего убьют смысл установки такого рутера в магистраль. IMHO Linux-u светит перспективная роль магистрального роутера, лишь в том случае если основной рутилкой будет ASIC с TCAM, который будет оффлоадить.

Еще как вариант сделать аппаратный префетчинг нужных данных, а именно сетевых заголовков, в L2 кеш(как сделано в NPE-G1/NPE-G2), там же хранить таблицу рутинга и функций, в принципе в Linux+Blackfin сталкивался с этим, что некоторые функции и драйвера можно принудительно хранить в кеше. Но в x86 кроме prefetcht0/3, prefetchnta ничего не видел... но если делать prefetch напрямую из I/O mem - может и вышло бы чего...

[visir]

IMHO Linux-u светит перспективная роль магистрального роутера, лишь в том случае если основной рутилкой будет ASIC с TCAM, который будет оффлоадить.

Дак есть уже подобное.

На базе Linux -- маршрутизаторы с IOS XE у Cisco.

На FreeBSD -- Juniper. (там правда не совсем TCAM, но не суть)

 

[nuclearcat]

visir - в одном из источников проскакивало, что рутить можно и без TCAM, если грамотно использовать L2 cache embedded процессоров. Например у NPE-G1 - BCM1250 (512KB L2 cache), хотя у NPE-G2 RM7000A 256KB L2, 64-bit MIPS.

По спеку на RM7000A там точно есть про какой-то хитрый data prefetch, но производительность системной шины указана как max 8Gbps.

[nuclearcat]

Не углядел на диаграмме L3 cache. Интересно он есть на NPE-G2?

[visir]

visir - в одном из источников проскакивало, что рутить можно и без TCAM, если грамотно использовать L2 cache embedded процессоров. Например у NPE-G1 - BCM1250 (512KB L2 cache), хотя у NPE-G2 RM7000A 256KB L2, 64-bit MIPS.

По спеку на RM7000A там точно есть про какой-то хитрый data prefetch, но производительность системной шины указана как max 8Gbps.

А ? Что к чему...

В NPE-G2 стоит PPC (Freescale 7448), а не MIPS...

[nuclearcat]

Да, точно, MPC7448. 1MB L2 cache... многое обьясняет в таком случае...

 

[zoro]

IMHO Linux-u светит перспективная роль магистрального роутера, лишь в том случае если основной рутилкой будет ASIC с TCAM, который будет оффлоадить.

Дак есть уже подобное. На базе Linux -- маршрутизаторы с IOS XE у Cisco. На FreeBSD -- Juniper. (там правда не совсем TCAM, но не суть)

Укурсе но там Линух-Фряха управляют только платками.. а вот на платках стоят заказные процы, асики... память... все соединяется спец шинками и многое многое другое...

[visir]

IMHO Linux-u светит перспективная роль магистрального роутера, лишь в том случае если основной рутилкой будет ASIC с TCAM, который будет оффлоадить.

Дак есть уже подобное. На базе Linux -- маршрутизаторы с IOS XE у Cisco. На FreeBSD -- Juniper. (там правда не совсем TCAM, но не суть)

Укурсе но там Линух-Фряха управляют только платками.. а вот на платках стоят заказные процы, асики... память... все соединяется спец шинками и многое многое другое...

И чем это принципиально отличается от "если основной рутилкой будет ASIC с TCAM" ?)

[zoro]

я не возражаю... я дополняю :)

[visir]

я не возражаю... я дополняю :)

"Не понимаю о чем речь, но точно знаю, что Linux/FreeBSD -- рулит, а Cisco/Juniper/Alcatel/Redback/ECI/.. -- ацтой", Вы ведь именно это хотели сказать ?

[nuclearcat]

Не всегда кстати платками. Принудительное закрепление функций и собственно самого массива (хеша) роутинг таблицы в L2 кеше, передача данных (только ip заголовка) напрямую из платки по шине с малой латентностью в L2 кеш, затем возможно прямая команда сетевому адаптеру перерутить пакет на нужное направление - помоему ключевая фича... и железа особое не очень нужно изобретать, кроме как немного улучшенный сетевой адаптер.

 

[zoro]

я не возражаю... я дополняю :)

"Не понимаю о чем речь, но точно знаю, что Linux/FreeBSD -- рулит, а Cisco/Juniper/Alcatel/Redback/ECI/.. -- ацтой", Вы ведь именно это хотели сказать ?

ДА? чес слово :) у меня в качестве маршрутизатора и L3 применяются циски, делинки... в качестве натилок сервачек-Linux... в другой сети пиксик натит... раньше на линуховом "железе" все делал...

PS вообще могу сказать что все зависит от квалификации персонала... проситет я одно время вообще не понимал как к сиське подойти... а вот на линухе нормально... так вот маршрутизатор- коммутатор в руки+ Инет и на сиську можно таого откопать... а всвязи с тем что настраивается все в одном месте, то разбирание "полетов" незанимает много времени... Линух-требо лазить-настраивать смотреть множество файлов, в каждой версии производитель может из... тся и собрать пакет так как тебе и нафиг не нужно, забыть включить какую-то библиотеку в поставку... но и плюсов у линуха полно...

 

ЗЫ1 Каждому своё решение....

[corrchess]

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

Изменено 8 августа, 2008 пользователем corrchess

[visir]

Не всегда кстати платками. Принудительное закрепление функций и собственно самого массива (хеша) роутинг таблицы в L2 кеше,

И много процессоров позволяют принудительно что-то в кеше держать ? (может я от жизни отстал ? ниразу о таком не слышал)

Да и размеры кешев еще не те в писюках, но уже приближаются. Для сравнения, у Juniper в Internet processor II Forwarding Table (кстати, это дерево, а не массив с хэшами, как в старых линуксах) хранится в SSRAM (считайте кеш): ~400k префиксов влазит в 8-ми мегабайтную версию, и ~800k в 16-ти. А ведь в кеш не только FIB должен влазить...

 

передача данных (только ip заголовка) напрямую из платки по шине с малой латентностью в L2 кеш, затем возможно прямая команда сетевому адаптеру перерутить пакет на нужное направление - помоему ключевая фича... и железа особое не очень нужно изобретать, кроме как немного улучшенный сетевой адаптер.

Ну а чем это принципиально лучше того, что сегодня ?

Сетевая карта ведь сама (DMA) копирует данные в основную память, сама же их и забирает. Или я чего-то недопонимаю ?)

 

[Картуччо]

Простите, но MPLS, BGP, IS-IS, VRF, L2 туннели, PBR, QoS, FrameRelay, X25, интерфейсы Е1 и STM и много другое тоже на линухах делать будете ?

[CNick]

Не флейма ради, а что сейчас под линуксом фрей юзаеться как демон маршрутизации? Последний раз я quagga смотрел там даже несколько процессов OSPF запустить нельзя.... Может конечно это не сильно и юзаеться, но мне кажеться что если квага лучшее что есть под юниксом для роутинга, то функционал у ПК роутеров проигрывает очень сильно....

[Картуччо]

Скачайте свежий GPL, посмотрите номенклатуру плат расширения для циско, существует ли аналогичное хоть для писюков хоть для санок ? Явно же нет. Хотя конечно, тут это всё за экзотику считается :))))

[visir]

Скачайте свежий GPL, посмотрите номенклатуру плат расширения для циско, существует ли аналогичное хоть для писюков хоть для санок ? Явно же нет. Хотя конечно, тут это всё за экзотику считается :))))

Удел PC-раутеров -- это езернет, только езернет. Все остальное по мнению"РС-раутероводов" слишком дорогое и из-за этого никем не используется. :-)

L2/L3 VPN-ы по их мнению тоже никому не нужны. А клиенты, желающие купить "просто связь между офисами", -- ламеры, ее же так просто через интернет организовать! Ну а когда совсем приспичит, то прокидывают через гигантское кол-во свитчей vlan с одного конца города на другой )) А в то, что у многих крупных операторов сейчас лучше всего продается именно VPN, а не интернет, они никогда не поверят.

 

Ах, да, в последних версиях MicroTik появилась поддержка MPLS в статусе "beta". Возможно через несколько лет она станет пригодной к использованию :-)

 

Простите, но MPLS, BGP, IS-IS, VRF, L2 туннели, PBR, QoS, FrameRelay, X25, интерфейсы Е1 и STM и много другое тоже на линухах делать будете ?

Многое из этого на Linux/FreeBSD есть, кое что даже работает лучше, чем на Cisco.

 

Не флейма ради, а что сейчас под линуксом фрей юзаеться как демон маршрутизации? Последний раз я quagga смотрел там даже несколько процессов OSPF запустить нельзя.... Может конечно это не сильно и юзаеться, но мне кажеться что если квага лучшее что есть под юниксом для роутинга, то функционал у ПК роутеров проигрывает очень сильно....

У MicroTik, например, своя реализация протоколов маршрутизации. Причем, судя по содержимому бинариков, написано оно целиком на C++ :-)

[Картуччо]

Простите, но MPLS, BGP, IS-IS, VRF, L2 туннели, PBR, QoS, FrameRelay, X25, интерфейсы Е1 и STM и много другое тоже на линухах делать будете ?

Многое из этого на Linux/FreeBSD есть, кое что даже работает лучше, чем на Cisco.

Ну чтоб не быть голословным надо раскрыть наверное.

MPLS возможно на PC сервере с Linux/BSD сделать и поставить рядом с Cisco/Juniper ?

BGP есть, насколько хорошо работает не знаю. Когда-то только Quagga+OSPF приходилось использовать. IS-IS ?

L2 туннель для FrameRelay сделать можно ?

Штук 40 портов Е1 или несколько STM-1 с дроблением на сотни ченел групп на одном сервере сделать можно ?

Для QoS можно сделать окраску/перекраску трафика, очереди, приоритеты, полисинг ?

VRF как реализовать ?

 

[jab]

Ну чтоб не быть голословным надо раскрыть наверное.

MPLS возможно на PC сервере с Linux/BSD сделать и поставить рядом с Cisco/Juniper ?

BGP есть, насколько хорошо работает не знаю. Когда-то только Quagga+OSPF приходилось использовать. IS-IS ?

L2 туннель для FrameRelay сделать можно ?

Штук 40 портов Е1 или несколько STM-1 с дроблением на сотни ченел групп на одном сервере сделать можно ?

Для QoS можно сделать окраску/перекраску трафика, очереди, приоритеты, полисинг ?

VRF как реализовать ?

Ламо...

[Картуччо]

Ну чтоб не быть голословным надо раскрыть наверное.

MPLS возможно на PC сервере с Linux/BSD сделать и поставить рядом с Cisco/Juniper ?

BGP есть, насколько хорошо работает не знаю. Когда-то только Quagga+OSPF приходилось использовать. IS-IS ?

L2 туннель для FrameRelay сделать можно ?

Штук 40 портов Е1 или несколько STM-1 с дроблением на сотни ченел групп на одном сервере сделать можно ?

Для QoS можно сделать окраску/перекраску трафика, очереди, приоритеты, полисинг ?

VRF как реализовать ?

Ламо...

Я и не сомневался ;)

[visir]

Простите, но MPLS, BGP, IS-IS, VRF, L2 туннели, PBR, QoS, FrameRelay, X25, интерфейсы Е1 и STM и много другое тоже на линухах делать будете ?

Многое из этого на Linux/FreeBSD есть, кое что даже работает лучше, чем на Cisco.

Ну чтоб не быть голословным надо раскрыть наверное.

MPLS возможно на PC сервере с Linux/BSD сделать и поставить рядом с Cisco/Juniper ?

BGP есть, насколько хорошо работает не знаю. Когда-то только Quagga+OSPF приходилось использовать. IS-IS ?

L2 туннель для FrameRelay сделать можно ?

Штук 40 портов Е1 или несколько STM-1 с дроблением на сотни ченел групп на одном сервере сделать можно ?

Для QoS можно сделать окраску/перекраску трафика, очереди, приоритеты, полисинг ?

VRF как реализовать ?

Ок, попытаюсь раскрыть:

 

По интерфейсам, как уже было сказано выше, -- только езернет. Формально конечно существуют работающие карточки E1/Sync/ASync, но это не массовый продукт -- сложно достать, сложно настроить.

 

Frame-Relay в Linux когда-то был, и якобы даже работал, но ныне заброшен -- думаю, можно считать что его нету. (но, вполне вероятно, когда эта технология еще была актуальна, кто-то наставил таких роутеров и у него они работают до сих пор)

Во FreeBSD есть ng_frame_relay -- последние два-три года не обновлялся, хотя саму подсистему netgraph изрядно переколбасили... то есть его работоспособность под вопросом.

На самом деле поддержка Frame-Relay в Linux/FreeBSD просто не востребована, то есть нафиг никому не нужна.

 

IS-IS ? Появился в последних версиях Quagga. Не думаю, что этим уже можно пользоваться :-)

В OSPF/BGP присутствуют разные глюки, которые не исправляют уже много лет -- юниксоиды про них знают и старательно обходят :-)

 

QoS. В целом, все можно: и классификацию, и перемаркировку, и полисинг/шейпинг, и CBWFQ (в Linux -- HTB), и даже UBRL (в FreeBSD штатно, в Linux доустановкой ESFQ).

 

VRF. Точнее VRF-Lite -- можно, средствами PBR.

В Linux поддержка несколько таблиц маршрутизации есть с незапамятных времен, а Quagga умеет помещать маршруты в указанную таблицу.

Во FreeBSD поддержка нескольких таблиц появилась очень недавно. Раньше можно было через действие "fwd" в ipfw -- прописывать пачку правил на каждую сеть, крайне не масштабируемое решение.

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

 

MPLS. Про попытки прикрутить MPLS к FreeBSD не слышал вообще. Под Linux есть такой проект: http://mpls-linux.sourceforge.net/

По информации с первой страницы видно, что для практического применения оно еще не готово -- только побаловаться :)

Особняком тут стоит MicroTik -- это хоть и Linux, но реализации протоколов у него свои: в том числе MPLS/LDP, PPtP на уровне ядра (обычный линуксовый pptpd работает на уровне приложений) , OpenVPN на уровне ярда (обычный работает на уровне приложений), BGP, OSPF, ...

 

Еще, думаю, стоит отметить iptables и ip_conntrack в частности -- у Cisco нет функционала, аналогичного этой связке. Именно из-за нее и NAT на Linux лучше, чем на маршрутизаторах Cisco. (про ASA/PIX не в курсе). Но опять же, нельзя привязать интерфейс к отдельным цепочкам {PREROUTING, FORWARD, POSTROUTING} масштабируемым способом...

 

 

PS: надеюсь, если где-то ошибся, то меня поправят ;)

Изменено 10 августа, 2008 пользователем visir

[Картуччо]

"кое что даже работает лучше"

кроме ната не увидел.

Да и про нат, читать оригинальный пост просто смешно.

Масса провайдеров, в том числе и класса "домашних" получают гораздо более существенные результаты на 7206.

А с юниксами, может сейчас ситуацию и поправили, но ведь тоже была масса проблем в плане ната, не в количественном, а в качественном плане.

 

"На самом деле поддержка Frame-Relay в Linux/FreeBSD просто не востребована, то есть нафиг никому не нужна."

на цисках она может быть тоже многим нафиг не нужна, но тем не менее она есть и работает.

Среди "домашних" провайдеров это может и экзотика, а так, в общем, далеко не экзотика.

Изменено 10 августа, 2008 пользователем Картуччо

[visir]

"кое что даже работает лучше"

кроме ната не увидел.

Да и про нат, читать оригинальный пост просто смешно.

Масса провайдеров, в том числе и класса "домашних" получают гораздо более существенные результаты на 7206.

А с юниксами, может сейчас ситуацию и поправили, но ведь тоже была масса проблем в плане ната, не в количественном, а в качественном плане.

Говоря про НАТ, я не имел в виду оригинальный пост.

НАТ на Linux-е объективно гораздо гибче и лучше. И только на Linux-е, в FreeBSD, я бы сказал, нет нормального NAT-а...

Ну и PBR на Linux тоже очень неплох.

Изменено 10 августа, 2008 пользователем visir

[jab]

 

:-) Рассуждения похожи на возглас инвалида, рассматривающего гоночный автомобиль: "А костыли куда класть ?"