tokra Опубликовано 28 декабря, 2010 · Жалоба Всем доброго времени суток!!! Сейчас, все чаще появляются сообщения в сети о грядущем переходя на ipv6, в связи с окончанием свободных ipv4. Вот мне, как простому смертному, стало интересно, как провайдеры будут нарезать нам полосу. Посмотрев в lartc, понял, что в Linux с этим все находится на зачаточном уровне. Про freebsd, не скажу, но думаю, что не многим лучше. Думаю эта тема интересна не одному мне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marikoda Опубликовано 28 декабря, 2010 · Жалоба IMHO к моменту перехода на IPv6 нешейпленные 10 гигабит на квартиру за 100 рублей будут обычным делом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tokra Опубликовано 28 декабря, 2010 · Жалоба IMHO к моменту перехода на IPv6 нешейпленные 10 гигабит на квартиру за 100 рублей будут обычным делом. Ну это конечно светлое будущее, но все же надо готовиться к реалиям. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 28 декабря, 2010 · Жалоба Незнаю насчет линуха, но во фре смотрел. Вообщем-то все готово, во всех основных случбах поддержка уже есть в полном объеме. Пробоема больше в пользователях, с их древним оборудованием, да в и-нете, который тоже не торопится на v.6 прыгать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 28 декабря, 2010 · Жалоба С точки зрения процессора обработка ipv6 выглядит намного хуже, в плане производительности. Боюсь жуниперы и циски с их custom ASIC поднимутся на этой ниве снова и здорово потеснят софтроутеры. Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 28 декабря, 2010 (изменено) · Жалоба К тому времени как понадобится - думаю ситуация может изменится. Изменено 28 декабря, 2010 пользователем Hawk128 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marikoda Опубликовано 28 декабря, 2010 · Жалоба С точки зрения процессора обработка ipv6 выглядит намного хуже, в плане производительности. Боюсь жуниперы и циски с их custom ASIC поднимутся на этой ниве снова и здорово потеснят софтроутеры.Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае Если помечтать, то могут сделать роутеры на CUDA или же в чипы сетевых карт встроят offload. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 декабря, 2010 (изменено) · Жалоба А кто нас заставляет делать классификацию сразу по всем байтам ipv6-адреса? Достаточно выделить различающееся двойное слово, поменять смещение и все будет по-старому. Изменено 28 декабря, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
m0xf Опубликовано 28 декабря, 2010 · Жалоба С точки зрения процессора обработка ipv6 выглядит намного хуже, в плане производительности. Боюсь жуниперы и циски с их custom ASIC поднимутся на этой ниве снова и здорово потеснят софтроутеры.Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случае Если учесть, что перед сравнением адреса выполняется ещё десяток тысяч команд (ядро ОС, драйвера и .т.д.), то усложнение сравнения почти ни на что не повлияет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 декабря, 2010 (изменено) · Жалоба Кроме того, хороший шейпер ничего не сравнивает, а использует IP-адрес (или его часть) как ключ хэша для определения номера класса, поэтому даже для IPv6 сложность классификации будет O(1). Хэширование с помощью u32 и фряшный pipe tablearg все равно будут актуальны. Оснований для паники нет. Изменено 28 декабря, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 января, 2011 · Жалоба Если ipv4 - 32bit, и скажем все поле можно обработать одним CMP и это будет атомарная операция в большинстве случаев, то с 128bit все грустно, SIMD это совершенно не то, в данном случаедва cmp на х64там кроме адреса ещё много чего проверяется, бывает и по несколько раз одно и тоже, потому никакого существенного падения производительности не будет. Даже наоборот, в ипв6 контрольная сумма для IP заголовка не рассчитывается, вроде, это большая экономия. Потом роутеры/наты не занимаются фаргментацией/дефрагментацией пакетов - это тоже исключает кучу проверок. А на самом деле, многие тут сидят на дефолтном ядре собранном с -O0 и дебагом, на чём прилично теряют в производительности, им уж точно разницы никакой ИП 4 или 6. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 1 января, 2011 (изменено) · Жалоба А на самом деле, многие тут сидят на дефолтном ядре собранном с -O0 и дебагом, на чём прилично теряют в производительности, им уж точно разницы никакой ИП 4 или 6. По поводу якобы большого увеличения производительности из-за сборки с оптимизированными флагами компилятора -- это гентушная пропаганда. Выигрыш будет, но незначительный, процентов 5 от силы. Изменено 1 января, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 2 января, 2011 · Жалоба По поводу якобы большого увеличения производительности из-за сборки с оптимизированными флагами компилятора -- это гентушная пропаганда. Выигрыш будет, но незначительный, процентов 5 от силы.Не факт, иначе бы кодеки не собирали с -O3 :)Но даже если и так, то потери от перехода с ИПв4 на в6 будут ещё меньше. А дефолтное ядро ещё и кучей ненужного обычно напичкано, что не только жрёт память но и доп обработки добавляет не нужные, как минимум на старте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tokra Опубликовано 2 января, 2011 · Жалоба А все же чем конкретно будете шейпить ipv6 трафик. По вашему мнению tc & dummynet готовы к этому? Или будете использовать готовые железячные решения? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 2 января, 2011 · Жалоба ng_car? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 2 января, 2011 · Жалоба А все же чем конкретно будете шейпить ipv6 трафик. По вашему мнению tc & dummynet готовы к этому? Или будете использовать готовые железячные решения? dummynet вполне себе готов. dst-ip6/src-ip6/flow-id в маске можно задать. А ng_car'у вообще все равно, какой ip трафик через него ходит. Вот с netflow пока есть небольшая проблема :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 2 января, 2011 · Жалоба Посмотрев в 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 всегда медленней. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 2 января, 2011 · Жалоба Netflow готов. По крайней мере flowd и softflow 9-ю версию держат точно. MPD не проверял, но по описанию - он на ng_netflow, а тот уже вроде держит. Так что проблем нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 2 января, 2011 · Жалоба Netflow готов. По крайней мере flowd и softflow 9-ю версию держат точно.Оба на libpcap MPD не проверял, но по описанию - он на ng_netflow, а тот уже вроде держит.Пока только в виде экспериментальных патчей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 2 января, 2011 · Жалоба И чем pcap плох? Работает быстро, нагрузка никакая... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 2 января, 2011 · Жалоба И чем pcap плох? Работает быстро, нагрузка никакая... Тем, что userland-решение. При больших пакетрейтах теряет пакеты и грузит систему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 3 января, 2011 · Жалоба И чем pcap плох? Работает быстро, нагрузка никакая...Тем, что userland-решение. При больших пакетрейтах теряет пакеты и грузит систему. +1 а они будут обязательно - я о пакетрейтах больших! надо ядрёное решение было бы неплохо если бы допилили ipt_Netflow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 5 января, 2011 · Жалоба было бы неплохо если бы допилили ipt_NetflowЯ писал ему, спрашивал насчёт полной попы с 2,6,37 ядром. Я поддерживаю проект как маинтайнер, но я в данный моментне разрабатываю новыех версий для новых ядер и не планирую в ближайшее время (т.е. не поддерживаю как разработчик). Рекомендую пользоваться старыми преверенными ядрами, они вполне функциональны. А остальные особо не занимаются разработкой а ждут манны небесной. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marikoda Опубликовано 10 января, 2011 · Жалоба т.е. ipv6 там и не планируется? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 10 января, 2011 · Жалоба Не планируется. Всё пропало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...