deep_admin

Не реально так как tcp порт 179 может занять только одно приложение Да, но на роутере как минимум 2 IP-адреса :)

просто так работать не будет, есть конечно проекты vrf под линукс (под другие никсы нету), но со стороны зебры самой поддержки нету по-моему гораздо проще еще один тазик поставить

О. Спасибо. Пример избавил меня от плясок с бубнами в процессе написания этого повторно :) Теперь осталось либо побороть rp-pppoe в CentOS красивым образом, либо скачать Ubuntu 6.06 TLS сервер и получить счастье. /me боится, что в Ubunt'е тот же баг :-S ftp://ftp.samba.org/pub/ppp/ppp-2.4.4b1.tar.gz ставится,собирается,работает как часики и кернел-мод пппое и радиусклиент

а чем не подходит такой вот способ шейпинга на ppp? http://www.opennet.ru/tips/info/811.shtml при правильном расчете burst очень даже неплохо работает

балансировка + резерв: делите свой префикс на куски, на каждый обязательно создаете свой route-object (чтоб аплинки пропустили) и анонсируете в каждый из каналов кусок+агрегат, например: сеть 192.168.0.0/23 делим на 192.168.0.0/24 и 192.168.1.0/24 и анонсим первый канал: 192.168.0.0/24 и 192.168.0.0/23 во-второй, соответственно: 192.168.1.0/24 и 192.168.0.0/23 Эти всем достигается балансировка входящего трафика; исходящий балансируете сами подкрашиванием входящих префиксов опять же - симметрии при таком способе не добиться

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

боюсь что ничего у вас не получиться, для такого pps роутерборда просто не хватит

на линксисе с openwrt vtun с шифрофанием - получалось не более 2мбит/с, без шифра - почти network-max, но это только один туннель кстати еще нюанс: с агрегацией при загруженном эфире времени может не хватать на пропуск больших пакетов (мы ж склеиваем маленьикие пакетики в суперпакет ?), а вот обычный вайфай еще кое-как будет работать (ретрансмит + фрагментация) еще: при поллинге базовая должна очень быстро опрашивать всех клиентов, и чем быстрее, тем лучше будет реагировать алгоритм распределения на ней, но есть обратная сторона: опрос то будет вестись маленькими пакетиками и очень часто !:) PS: примерно так работает frottle, кстати на 11b еще жить можно, для 11g frottle - верная смерть

именно поллинг и получается причем полезен как и на магистралях, так и в раздаче, а все из-за ассиметричной природы мак-уровня вай-фая, особенно когда много встречного трафика интересно посмотреть в сторону vtun+tap в бридже на точке, именно там можно и поуправлять поллингом (есть исходники), заодно избавимся от проблемы nat25 :)

ну конечно же, а об оборудовании aperto, alvarion, radwin итд на каждом столбе баннеры висят ! Все только длинк/планет :)Я не хочу никого защищать, я просто их покупаю, ставлю и делаю бизнес, и меня цена/качества более чем устраивают. Если блюбоксы вдруг исчезнут - наступит полная задница, в этом ценовом диапазоне вариантов (p2p до $1K) просто нет (микротики на украине сложно купить) Обижать других не красиво, тем более необоснованно (можете сделать выборку по моим постам)

Как правило у фирменного карлнета радиомодули представляют собо PCcard и и при установке в слот прилегают к чипсету (оторый сам по себе грееться) а при внешней высокой температуре устройство банально зависает и у вас срабатывет watcdog так что тут нет ничего сверх естественного. ЗЫ Сори за офтопик.. не удержался Я ж не спорю, просто тут говорили о плохом качестве сборки блюбокса :) Кстати карлнеты гораздо дороже обходятся. Мне, как обычному пользователю, не важно что там внутри, просто хотелось бы что бы оно работало...

Хочется конкретики, потому как имею совершенно обратный опыт с блюбоксами, то бишь - крайне положительный. Любая беспроводная железка нуждается в настройке и если правильно настроена то ведет(или не ведет) себя согласно заявленным парметрам. Вот блюбоксы именно так и ведут себя. Кстати, имел опыт с разными РРС, там процесс настройки гораздо более сложный, иногда часами долбаясь на крышах, задумываешься: "и какого я за этот комплект релеек отвалил 5-8Кбаксов ???". еще пару положительных слов в сторону блюбокса: что б там не говорили о плохом качестве сборки, но в одном ящике лежит синяя коробочка и фирменный карлнет, так вот при 58-60 градусов карлнет начинает постоянно ребутаться, блюбоксу хоть бы хны. И это не единственный случай!

а 2 айпи адреса зачем? неужели статика и впн? бррр... на биллинг не похоже, все эти лампочки больще напоминают консоль примитивного мониторинга

в заголовке пакетов нетфлоу 5-й версии есть штампы начала/конца потока, номер последовательности (16 байт смещения по хедеру пакета), так что потерю и нарушение последовательности фловов отследить легко. http://support.packeteer.com/documentation...low5-header.htm

Если у вас терминалы статические (не перемещаются между базовыми станциями), то wlan-контроллер вам не нужен, просто цепляете каждый терминал на лучшую по сигналу станцию. Если же они бегают, этот контроллер необходим для прозрачного роуминга между станциями без разрыва ассоциации. Без него могут быть неприятные ситуации ввиде залипания арп-таблицы итд Все модели апешек, которые вы указали - не ентерпрайз класса, вам надо смотреть как минимум на proxim orinoco ap-700/ap-4000

Видел я уже именно эту схему, и человека знаю для начала предлагаю заменить серваки с виндой и трафик инспектором на линукс+пппое - должно сразу полегчать

посмотрите сюда: http://wl500g.info/showthread.php?t=4154 из-за перебоев с питанием у нас умирали асусы, там кривоватый pmon, может запороть флешину при этом с линксисами такого никогда не было

а что там побеждать? в опенврт pppoe-relay есть в дефолтном репозитории, ставишь и работает.

Уберите iptables вообще, используйте tc filter для пометки трафика. Сетевые карты Intel, лучше гигабитные, дровы под них должны быть собраны с NAPI.

Это тазывается тайминг проблема или ack проблема. Даже при включении 5.5 или 11 мегабит в б стандарте более 2 км начнутся проблемы так как у овисов ack таймауты выставлены на 2 км. Так шо вам надо или работать на 2 мегабитах в б стандарте(там что то около 16 км получается без проблем) или менять на овисах прошивку. Вроде разработчики прошивок для rtl8186 в новых версиях победили ack проблему. Так что я думаю имеет смысл попробовать их прошивки влить на овис. Ну или усисок несколько мегават :) В овислинках 5460 нет проблемы тайминга в последних 3-х прошивках, там он выставлен по-умолчанию в 0 (автомат) и есть окошко где можно свое значение вводить. Я очень сомневаюсь что 1-ватный манус может работать в g режиме, очень рекомендую убрать его и работать только в b (выставить b жестко на ориноке)

все есть, надо поставить нужные пакеты лучше попрбуйте ipcad и забирайте с него по rsh или netflow, на флешку часто лучше не писать Вланы понимаются by-default чипом, 8021.q вкопилен в ядро, так что просто vconfig и вперед. С нумерацией вланов проблем не встречал по крайней мере на линксисах.

Такая проблема у всего 802.11b/g wifi без исключения, потому как по стандарту АП работает с тем маком который к нему ассоциирован. Различные расширения стандарта типа WDS или турбоселовский SEC эту проблему решают.

Whiterussian - это типа кодовое название прошивки openwrt. Я пробовал в продакшн почти все версии от RC2 до RC5. Последняя вполне стабильна, на железе версии WRT54GL ведет себя превосходно.

А есть рускоязыная ссылка? Может сайт запомнили? Если чесно - английский даже не напрягает, поэтому русский сайт не искал

>Смысла в этом нет. Если юзверь неприконектился, тогда и трафика от него не будет, соответственно и >нечего считать. Еще как есть - видно четкое соответствие между сессией пользователя и его неаггрегированным трафиком. Просто в голове летает мысля о быстрой и индивидуальной тарификации пользователя. >Я вобщем сейчас пробую реализовать вот такой вариант: коллектор - всё инсертит в БД. больше он >ничего не делает. >Наверное по крону, потом видно будет. Будет запускаться парсер БД. Он во время запуска загрузит в >себя все тарифы, пользователей и виды трафика. >Затем начинает, обсчитывать временную таблицу. >По завершению, обработанные записи он удалит. >Но сразу всплывает идея, а что, если коллектор заставить раз в несколько минут загружать в себя >данные из БД (тарифы, пользователи и виды трафика). >И на основе полученных данных пришедший Netflow обрабатывать и укладывать в БД, не простым >инсертом, а апдейтом. Т.е. сразу же делать агрегацию трафика. Лучше отделить мухи от котлет, во-первых если коллектор что-то типа циски, то сразу облом. Во-вторых, даже если это тачка с линуксом/фрей, то на ней (а это роутер) надо иметь либы коннектора к БД, хотя бы того же mysql'а, плюс расход памяти/ресурсов под загрузку всего этого. Уж лучше пусть роутер роутит и файрволит. >А вот ещё какой вопрос, нужна ли в БД информация о том, с какого шлюза пришли данные о трафике?? Обязательно, ведь фактически привязка юзера это коллектор-интерфейс-ipадрес.