byteplayer

Уже писали, что зависит от железа/системы. На практике по п.1 у меня 7000/700kpps7Gbps Centos 6.7 + Xeon E5-1650 v3 @ 3.50GHz + Intel 82599ES 10-Gigabit Но уже почти в упор по железу. А можно версию ОС, версию ядра и версию акселя? А, ну да, CentOS 6.7 Там ядро её родное 2.6.X или какое-то 3.Х ? И сам аксель какой версии используете?

на паре серверов 3.2 собрал, на одном - 3.10 на пробу. и то и то стабильно работает. 1.10 А в чём принципиальное отличие 1.9 от 1.10? Что там сделано такого, без чего 1.9 уже не катит? Просто у автора есть всё собрано под Wheezy 7.9 (ядро 3.2.х), но версия 1.9, а 1.10 только в исходниках. Вот я и интересуюсь, что я получу, если я установлю готовые пакеты, и что, если соберу 1.10?

А почему не на 3.2 или не на 3.10, а и на то и на то? И какая версия акселя? Уже писали, что зависит от железа/системы. На практике по п.1 у меня 7000/700kpps7Gbps Centos 6.7 + Xeon E5-1650 v3 @ 3.50GHz + Intel 82599ES 10-Gigabit Но уже почти в упор по железу. А можно версию ОС, версию ядра и версию акселя?

Уважаемые коллеги. Может кто выскажет свои соображения, какая связка kernel + accel-ipoe считается самой стабильной для продакшена? Я по постам как бы понял, что это kernel 3.2.x + accel-1.9.0, но может я неправильно думаю? Например, поставить Wheezy 7.x + готовые пакеты accel под него с сайта разработчика -- так? Схема L2-shared без QinQ с простым ip_unnumbered + NAT. Адреса раздаёт dhcp-модуль freeradius по MAC либо option 82.

Хорошо, а что умеет этот 7301? Там ISG нормальный есть?

У меня с этим нет проблем =) Я знаю как готовить NAT на ASR (Есть опыт эксплуатации). Так чем всё это закончилось? В итоге какие BRAS применяются и какие из них обеспечивают нормальный NAT?

У кого взлетел accel c shared=1 mode=L2? Выдача адресов dhcp-модулем freeradius, авторизация freeradius. IP реальные. У меня что-то не взлетает. Есть кто, кому конфиг показать и ткнуть на бока?

А какая версия считается стабильной?

Мне нужно иметь две функции -- dlinkdes3200 и bdcomp3310b. Я так понял, что аксель с помощью луа может сформировать username, например так: для dlinkdes3200: username="c8d3a39b27d20002" (MAC свича и порт номер 2) для bdcomp3310b: username="fcfaf7c50d02057f01" (MAC OLT, влан 1407, порт номер 1) Примечание: 1. В OLT порт 1 -- это уже не физический порт, а "виртуальный порт", который соответствует LLID. 2. Номер влан играет роль, так как в моей схеме он по-сути обозначает уникальный номер физического порта -- vlan-per-epon_port. Тогда биллингу надо при первом включении абонента записывать эти данные в нужное поле, когда абонент из гостевого пула попадает на страницу регистрации. А всем неидентифицированным выдавать ай-пи из гостевого пула. Зарегистрировать себя абонент может, если знает логин и пароль к личному кабинету. Я правильно понимаю?

Я бы не отказался от примера скрипта LUA для BDCOM. Agent-Remote-Id = "MAC_OLT" (6 bytes) Agent-Circuit-Id = "vlan-id|epon-port|virtual-port" (2 bytes + 2 bytes + 1 byte) username = "MAC_OLT|vlan-id|virtual-port"

Хочу пользователей, включенных через D-Link DES-3200 и через OLT BDCOM P3310B, пускать через один и тот же BRAS accel-ipoe, но одних в одном влане, а других -- в своём. Но Agent-Remote-Id и Agent-Circuit-Id у них разные (различна как длина, так и структура), а, значит, способ формирования username у них разный. Так вот вопрос -- как быть с указанием пути к скрипту LUA для формирования username? Можно ли указать для каждого влана отдельный LUA-скрипт?

От процессора зависит, но может и по шине - хитрозадые китайцы в целях экономии на low-end материнках слоты 1х паяют через анус... Как редко используемые на полную катушку. В результате оно там больше полугигабита полудуплекса не выдает. Где-то тесты пропускной способности по сети бегали. При этом соседний 4х работает как надо. Ага, но у меня-то карта 4х в слоте 16х. То есть, по-любому должна хорошо работать.По идее так?

Ребята, а для PPTP-рутера на две карточки (одна аплинк, вторая к юзерам) достаточно поставить одну Intel 1000/PT Dual PCI-E 4x, или всё равно надо тулить их аж две и включать линки в отдельные адаптеры? Достаточно будет одной двухголовой карточки или нет? А то у меня на мамке только один PCI-E 16x слот. Если не достаточно, то надо мамку менять... Хочу перейти на схему настройки без поллинга с тюнингом стандартного драйвера, а то у меня две PRO/1000 GT и упираются в 200-240М, а потом дропают пакетики... Спасибо за ответ.

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

Ну вот я о том и речь веду, что это L3 можно на уровне L2 завернуть не на PPTP сервер ISP, а на какой-то свой. можно, если под ай-пи л3-свича будет мак пионера, а за ним тот сервер РРТРно логин и пароль должен подойти, а его надо знать, а узнать трудно, так как мрре128-шифрование.......... в общем, мы отклонились от темы.... если человеку надо динамическую балансировку РРРоЕ в локалке, то скорее всего это решаемо только с помощью проприетарных решений.... Если б это надо было РРТР, то там всё решается с помощью внутр. ДНС и настройкой round-robin резолвинга, чтоб одно и то же имя резолвилось в разные ай-пи по очереди, и юзеры б коннектились к этим разным ай-пи прибл. поровну, а тут как на мак-уровне сделать... ничего в голову не приходит...

ну а про swithport protected? Да это без разницы чем оно шифруется.. главное что на L2 мы можем делать все что хотим и в т.ч. завернуть его PPTP сессию через себя. У вас надеюсь юзера сертификатами аутентифицируются? Если нет, то всё возможно. И надо заметить продукты готовые для таких действ в публичной сети давно имеются. ps. Кстати, а чем Вы так на такое количество юзеров шифровать собираетесь? switсhport protected у меня не используется, так как если два юзера в одном свиче, то мне надо, чтоб они могли напрямую качать друг у друга, а не через роутер по РРРоЕ "на L2 всё что захочешь", но РРТР-туннель в отличие от РРРоЕ работает по L3 хоть это и более накладно для ЦПУ, но я предпочитаю РРТР и юзаю его только для инета, локалка работает на простом эзернете есть порезана на вланы, чтоб в одном влане не было много людей, всё затерминировано в свич L3 есть отдельный влан, в котором нет ни одного юзера в этом влане у меня DHCP&DDNS-сервер, РРТР-серверы и все остальные сервисы на свиче включен DHCP-relay сеть у меня в виде ромашки, в центре свич L3, в лепестках отдельные вланы с юзерами один из лепестков -- влан сервисов и доступа в инет все нужные маршруты передаются каждому клиенту по DHCP в РРТР шифрование включено в MPD правда у меня больше 300 туннелей на одном сервере не бывает, но и загрузка ЦПУ сейчас не более 10% серверы не крутые: FreeBSD 6.2-RELEASE #0: Fri Feb 9 22:22:12 EET 2007 root@rcx2.uar.net:/usr/src/sys/amd64/compile/ROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel® Pentium® 4 CPU 3.00GHz (2997.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf49 Stepping = 9 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLU SH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x641d<SSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,<b14>> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> Logical CPUs per core: 2 real memory = 1046872064 (998 MB) avail memory = 1002332160 (955 MB) ACPI APIC Table: <INTEL DG965RY > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1

у человека проблема реальная, ему там не до тренировок. гы... а про vlan-ы и switchport protected провайдер с семилетним стажем знает? только если пионер захочет завернуть через себя PPTP сессию соседа, то никаких препятствий для него не предусмотрено. Давайте только без сарказма. Если какое-то количество юзеров находится в одном влане -- любой из них может мешать нормальному доступу до РРРоЕ-сервера тем, кто в одном влане с ним. Я просто не представлял, что у человека каждый юзер в отдельном влане и этот влан гонится аж до NASов и на РРРоЕ живёт локалка. Довольно интересный подход, правда я не знаю, зачем так жёстко, ведь на много юзеров просто вланов не хватит...А насчёт завернуть сессию соседа -- это надо умудриться зароутить соседа к себе на ай-пи, который находится за роутером для обоих. Ведь соединение по РРТР устанавливается на 3-м уровне, и мой РРТР-сервер может находиться через несколько хопов от клиентов. И по умолчанию в винде вся РРТР-сессия шифруется mppe128.

Да я не против дать локалку на полной скорости. У меня так и есть! Но как она умудряется попадать в РРРоЕ?!?!Мне интересен механизм, как локальный траффик попадает в туннель, предназначеный для Интернета??? Что там за особенности топологии? Просто аж дух захватывает от интереса, как такое может быть!

Согласен, но в "жалобе на жизнь" была указана проблема локального трафика как причины необходимости балансировки. Не так ли? Зачем вообще нужна эта балансировка? Для надёжности? Для отказоустойчивости? Или просто охота потренироваться?Скажу своё мнение, как провайдера с семилетним стажем, что РРРоЕ в домашних сетях можно контролировать только если вся сеть построена на свичах с возможностью фильтрации РРРоЕ-ответов на клиентских портах. Иначе любой пионер разворачивает у себя РРРоЕ-сервер и "балансировка" уже начинается между NAS провайдера и NAS пионера. Очень неприятный процесс поиска пионера, потом неприятный процесс объяснения перед юзерами, почему не работает, почему украли пароли (ведь по умолчанию многие юзают стандартный РРРоЕ-клиент WinXP, где шифрование паролей отключено, и пионер их собирает). Мы вышли из этой ситуации переходом на РРТР-сервер, который отделён от клиентской сети L3-коммутатором, а маршрут к нему передаётся абонентам по DHCP с помощью опции static route. Я убеждён, что при правильном подходе можно обеспечивать стабильный и отказоустойчивый доступ очень большому количеству клиентов одним NAS без всякой балансировки. Есть примеры, когда через один NAS на РС бегают пару тысяч туннелей с трафиком порядка 600М. Можно и намного больше, но это уже будет какой-нибудь специальный Juniper.

Я так понял, что вся проблема возникла из-за того, что некоторые нехорошие юзеры гоняют через туннели локальный трафик. Решением данной проблемы будет просто умение поставить рейт-лимит или шейпер на каждом туннельном интерфейсе, чтобы абонент в туннеле мог качать только с той скоростью, какая предусмотрена у него в договоре. Такое реализуемо, если все логины хранятся в sql-базе и разделены на группы в соответствии с тарифными планами (скоростями). Радиус берёт из базы нужный атрибут и сообщает серверу, какое ограничение скорости установить на туннельном интерфейсе для каждого логина. Это реализуемо, если в качестве сервера доступа использовать: 1) Cisco 2) FreeBSD + mpd + ng_car 3) MikroTik RouterOS для этих трёх видов серверов доступа есть радиус-атрибуты, которые позволяют установить ограничение скорости на приём и передачу на каждый туннельный интерфейс. Я использую в наземных сетях вариант 2), а в беспроводных -- вариант 3).

Да, согласен.ZyXEL ES-2024A и ES-2108G нужно сравнивать с коммутаторами серии 30XX там и заявленный функционал идентичен. И цены близкие. Но всё-таки я люблю Зиксель. У нас в ядре городской локалки стоит ZyXEL GS-4012F, в центрах районов ZyXEL GS-3012F, на доступе клиентов -- ZyXEL ES-2024A и ES-2108G. Вопросов -- никаких! По уши довольны.