Jump to content
Калькуляторы

Shaping ipv6 трафика

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by Hawk128

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites
Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае
два cmp на х64

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

 

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

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

 

 

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

Share this post


Link to post
Share on other sites

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

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

Edited by photon

Share this post


Link to post
Share on other sites
По поводу якобы большого увеличения производительности из-за сборки с оптимизированными флагами компилятора -- это гентушная пропаганда. Выигрыш будет, но незначительный, процентов 5 от силы.
Не факт, иначе бы кодеки не собирали с -O3 :)

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

 

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

 

Share this post


Link to post
Share on other sites
Посмотрев в 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 всегда медленней.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Netflow готов. По крайней мере flowd и softflow 9-ю версию держат точно.
Оба на libpcap

 

MPD не проверял, но по описанию - он на ng_netflow, а тот уже вроде держит.
Пока только в виде экспериментальных патчей.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
И чем pcap плох? Работает быстро, нагрузка никакая...
Тем, что userland-решение. При больших пакетрейтах теряет пакеты и грузит систему.

+1

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

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

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

 

Share this post


Link to post
Share on other sites
было бы неплохо если бы допилили ipt_Netflow
Я писал ему, спрашивал насчёт полной попы с 2,6,37 ядром.

 

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

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this