[tokra]

Всем доброго времени суток!!!

Сейчас, все чаще появляются сообщения в сети о грядущем переходя на ipv6, в связи с окончанием свободных ipv4.

Вот мне, как простому смертному, стало интересно, как провайдеры будут нарезать нам полосу.

Посмотрев в lartc, понял, что в Linux с этим все находится на зачаточном уровне. Про freebsd, не скажу, но думаю, что не многим лучше.

Думаю эта тема интересна не одному мне.

[marikoda]

IMHO к моменту перехода на IPv6 нешейпленные 10 гигабит на квартиру за 100 рублей будут обычным делом.

[tokra]

IMHO к моменту перехода на IPv6 нешейпленные 10 гигабит на квартиру за 100 рублей будут обычным делом.

Ну это конечно светлое будущее, но все же надо готовиться к реалиям.

[Hawk128]

Незнаю насчет линуха, но во фре смотрел. Вообщем-то все готово, во всех основных случбах поддержка уже есть в полном объеме.

 

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

[nuclearcat]

С точки зрения процессора обработка ipv6 выглядит намного хуже, в плане производительности. Боюсь жуниперы и циски с их custom ASIC поднимутся на этой ниве снова и здорово потеснят софтроутеры.

Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае

[Hawk128]

К тому времени как понадобится - думаю ситуация может изменится.

Изменено 28 декабря, 2010 пользователем Hawk128

[marikoda]

С точки зрения процессора обработка ipv6 выглядит намного хуже, в плане производительности. Боюсь жуниперы и циски с их custom ASIC поднимутся на этой ниве снова и здорово потеснят софтроутеры.

Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае

Если помечтать, то могут сделать роутеры на CUDA или же в чипы сетевых карт встроят offload.

[photon]

А кто нас заставляет делать классификацию сразу по всем байтам ipv6-адреса? Достаточно выделить различающееся двойное слово, поменять смещение и все будет по-старому.

Изменено 28 декабря, 2010 пользователем photon

[m0xf]

С точки зрения процессора обработка ipv6 выглядит намного хуже, в плане производительности. Боюсь жуниперы и циски с их custom ASIC поднимутся на этой ниве снова и здорово потеснят софтроутеры.

Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае

Если учесть, что перед сравнением адреса выполняется ещё десяток тысяч команд (ядро ОС, драйвера и .т.д.), то усложнение сравнения почти ни на что не повлияет.

[photon]

Кроме того, хороший шейпер ничего не сравнивает, а использует IP-адрес (или его часть) как ключ хэша для определения номера класса, поэтому даже для IPv6 сложность классификации будет O(1). Хэширование с помощью u32 и фряшный pipe tablearg все равно будут актуальны. Оснований для паники нет.

Изменено 28 декабря, 2010 пользователем photon

[Ivan_83]

Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае

два cmp на х64

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

 

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

Потом роутеры/наты не занимаются фаргментацией/дефрагментацией пакетов - это тоже исключает кучу проверок.

 

 

А на самом деле, многие тут сидят на дефолтном ядре собранном с -O0 и дебагом, на чём прилично теряют в производительности, им уж точно разницы никакой ИП 4 или 6.

[photon]

А на самом деле, многие тут сидят на дефолтном ядре собранном с -O0 и дебагом, на чём прилично теряют в производительности, им уж точно разницы никакой ИП 4 или 6.

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

Изменено 1 января, 2011 пользователем photon

[Ivan_83]

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

Не факт, иначе бы кодеки не собирали с -O3 :)

Но даже если и так, то потери от перехода с ИПв4 на в6 будут ещё меньше.

 

А дефолтное ядро ещё и кучей ненужного обычно напичкано, что не только жрёт память но и доп обработки добавляет не нужные, как минимум на старте.

[tokra]

А все же чем конкретно будете шейпить ipv6 трафик. По вашему мнению tc & dummynet готовы к этому? Или будете использовать готовые железячные решения?

[Hawk128]

ng_car?

[littlesavage]

А все же чем конкретно будете шейпить ipv6 трафик. По вашему мнению tc & dummynet готовы к этому? Или будете использовать готовые железячные решения?

dummynet вполне себе готов. dst-ip6/src-ip6/flow-id в маске можно задать. А ng_car'у вообще все равно, какой ip трафик через него ходит.

 

Вот с netflow пока есть небольшая проблема :)

 

[vitalyb]

Посмотрев в lartc, понял, что в Linux с этим все находится на зачаточном уровне

tc фильтрам без разницы, они по маске работают - в доке написано как матчить v6 внутри v4 - http://lartc.org/howto/lartc.adv-filter.ipv6.html . Нативный v6 - вообще тупо по смещениям. Добавить в userspace несколько ipv6 "удобств" для удобства - не проблема вообще.

 

Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно,

128 пока не надо, 64 - максимум.

 

Не факт, иначе бы кодеки не собирали с -O3 :)

Кодек, ядро и, скажем, фаерфокс - это три большие разницы с т.з. оптимизации. -O3 в ряде случаев значительно медленней, чем -Os, и наоборот. А -O0 всегда медленней.

 

[Hawk128]

Netflow готов. По крайней мере flowd и softflow 9-ю версию держат точно. MPD не проверял, но по описанию - он на ng_netflow, а тот уже вроде держит. Так что проблем нет.

[littlesavage]

Netflow готов. По крайней мере flowd и softflow 9-ю версию держат точно.

Оба на libpcap

 

MPD не проверял, но по описанию - он на ng_netflow, а тот уже вроде держит.

Пока только в виде экспериментальных патчей.

[Hawk128]

И чем pcap плох? Работает быстро, нагрузка никакая...

[photon]

И чем pcap плох? Работает быстро, нагрузка никакая...

Тем, что userland-решение. При больших пакетрейтах теряет пакеты и грузит систему.

[Lynx10]

И чем pcap плох? Работает быстро, нагрузка никакая...

Тем, что userland-решение. При больших пакетрейтах теряет пакеты и грузит систему.

+1

а они будут обязательно - я о пакетрейтах больших!

надо ядрёное решение

было бы неплохо если бы допилили ipt_Netflow

 

[disappointed]

было бы неплохо если бы допилили ipt_Netflow

Я писал ему, спрашивал насчёт полной попы с 2,6,37 ядром.

 

Я поддерживаю проект как маинтайнер, но я в данный момент

не разрабатываю новыех версий для новых ядер и

не планирую в ближайшее время (т.е. не поддерживаю как

разработчик).

 

Рекомендую пользоваться старыми преверенными ядрами,

они вполне функциональны.

А остальные особо не занимаются разработкой а ждут манны небесной.

[marikoda]

т.е. ipv6 там и не планируется?

[vitalyb]

Не планируется. Всё пропало.