N.Leiten
-
Всього повідомлень
1 037 -
Приєднався
-
Останній візит
-
Дней в лидерах
10
Тип контенту
Профили
Форум
Календарь
Сообщения додав N.Leiten
-
-
Ребят, это ВайМакс... точно лоханулись на такие бабки, прчием конкретно.. Елси 802.11а разрешать в свободное использование, то ВайМакс будет отдыхать еще долго, с его ценами на оборудование и лицензии.
на користування РЧР України для радіотехнології „Широкосмуговий радіодоступ” стандарту ІЕЕЕ 802.16 у діапазоні радіочастот 5590-5670 Мгц. -
Насчет бриджев и управляемости - буду пробовать собрать прошивку с ebtables. В принципе проблем быть не должно, за исключением объема флешки. Буду резать сбор статистики по ipcad.
Если бриджы тоже будут нормально работать - то тоже буду писать статейку, только позже.
-
deep_admin
Привет, завтра увидимся.
Насчет бридж+ebtables - конечно. Я просто предлагаю варианты
Следующий вариант как раз таким и будет Пока есть возможность - тестирую. Особенно если учесть, что в принципе любое изменение топологии (в данном случае метода "прозрачности") никак не сказывается на абоненте .Вооот. Ну а речь как раз шла о радио, поэтому вот так и зашел разговор
.Apelsin
Почитай доки о понятиях маска, длина маски и взаимозаменяемости этих понятий. Тут на форуме есть тема где-то глубоко лежит, там всё красиво описано, с наглядными ноликами-единичками
-
mr.Scamp
эффект в принципе исправимый (я уже нашел как и уже исправил более менее
) Представь ситуацию - цепочка роутеров в режиме проксиАРП. По принципе проксиАРП роутер может ответить, что он является запрошенным Айпи только в случае, если хост с таким айпи действительно присутствует. То есть при получении запроса на определенние айпи-адреса, роутер проверяет свою таблицу АРП, елси там нет этого айпи с мак-адресом то проверяет таблицу маршрутизации (если запрошенный айпи находится на другом интерфейсе по маршруту он пытается его запросить таким же арп запросом).Теперь представь, что с одного конца сети пошел арп запрос и по цепочке в другой конец он "ретранслируетя" (на самом деле подставляются другие мак-адреса, поэтому не совсем ретрансляция), и каждый роутер проверяет свои таблицы, пока не выстроится цепочка роутеров, которые считают что нужный айпи-мак находится на одном из интерфейсов. Когда же таблицы сформировались идет голая маршрутизация, без особых задержек.
Теперь о решении этой проблемы. Линукс был бы не линукс, если бы не его функциональность и безопасность. Для безопасности в линуксе специально ввели задержку на ответ проксиАРП, в точках Г700 он равен 80. Устанавливается этот параметр в
/proc/sys/net/ipv4/neigh/DEV/proxy_delay
Я установил этот параметр значением 10, теперь максимальная задержка стала 450мс на первый пакет
Раньше была около 3500мс Пользуйтесь на здоровье.
-
По внутреннему наполнению они действительно одинаковы. Но металл в действительности значительно лучше пластика. Тем более Пластиковый корпус у планетов практически непроветриваемый, а в металле для этого есть щелочки и дырочки в боках
А при использовании на чердаках/крышах температурный режим для ADMtek чипов (они внутри этих Планетов стоят) очень критичен, в частности проскакивала инфа, что рабочая температура чипа может достигать 100 градусов Цельсия, но лучше не рисковать -
Тема не закрыта и проект не заброшен...
Примеры есть в пакете с программой. Описаны все команды.
С задачей 192 всем и 64 одному справится любой шейпер... Просто делаешь фильтр на подсеть со скоростью 192 Кбит. И фильтр на айпи со скоростью 64кбит. И будут у тебя люби бегать отдельно и не мешая друг другу. Если, конечно, я правильно понял ситуацию
-
Конечно это не совсем статья. Если надо напишу более развернутый вариант с рисунками.
А пока суть дела - перестроили два крыла сети, теперь будем приниматься за центр - провода и клиенты на них
В общем ситуация классная. Мне понравилось - оно действительно работает и даже проще чем я думал Единственное но, с которым можно смирится, но я попробую бороться.
При посылке первого пакета на хост за одним шлюзом задержка может быть (для первого пакета) до 300мс, остальные в норме. Если несколько шлюзов на пути, то задержка вырастает до 3секунд, а то и больше. Как вариант борьбы с этим явлением я вижу поднятие туннелей к каждому шлюзу от каждого шлюза и прописывать "кратчайший" маршрут к подсетям в туннель - буду пробовать. Если есть еще варианты для фантазирования - внимательно выслушаю и протестирую. О результатах сообщу.
ЗЫ. Наверное, таки буду писать статью - всё-таки никто такого еще не делал, а для бюджетного варианта - самое оно.
-
Из практики - стоят овислинки 5460 (тот же чип, процессор, только памяти больше) В режиме роутера. на проводе гирлянда из неуправляемых свитчей. Количество абонентов больше 600. Работает нормально. так что от броадкаста левого не валятся
От маршрутизации - будем тестировать. -
Учитывая, что мы рассматриваем контроллируемую бюджетную сеть. В частности На первое время, пока нагрузка небольшая, можно такой вариант пользовать...
Проводил тестирование точек г700ап. С нулевыми правилами способна роутить больше 2700 пакетов/с (больше не смог сгенерировать на целероне 600мгц). в ближайшее время буду тестировать с нагрузкой правил...
Но как идея жить может, насколько я смотрю
Можно оформить и забросить в статьи, что-то из разряда как нужно строить если мало денег -
Одиннадцать человек просмотрело
Оцените идею, как она вам.Могу дополнить, что в данном случае у клиентов выдается подсеть всей сети. И каждый абонент считает, что видит физически всю сеть, хотя на самом деле это не так.
ЗЫ. У себя точно такое уже буду внедрять. Протестировал на точке доступа с прошивкой Wive - работает
-
Scorpiy
жжешь, насчет цыски
Я себе представил картину - шесть новых русских собралось сделать сеть по подъезду, ггг.
Electric200
а что хочешь контроллировать? вполне резонный вопрос.
-
Вот идея всплыла недавно, на фоне реформирования своей сети. Решил поделиться.
1. В общем по стандартам, точнее чтобы правильно всё работало и было меньше проблем нужно строить сеть или на управляемых свитчах (достаточно дорого для начального уровня) или соблюдать топологию и строить гирлянду в надежде на будущую формацию. Естественно как вариант полной управляемости - это сеть WAN разделенная по LAN и между ними роутеры (маршрутизация третьего уровня с разделением по подсетям). Или тот же WAN, только между локальными сегментами ставить очень умные свитчи.
Это было вступление.
2. Теперь об интересном. (практика)
Чаще всего возникают вопросы - "есть у меня лока на N человек и есть за горизонтом у друга локалка с M человек - как объединить дешево".
Естественно, легко догадатся, что сразу предлагается радио. Небеспочвенно - дешево, и расстояние покрыть можно любое (компромисс скорость/расстояние, остальное дело прямых рук). Всё красиво, пока таких ситуаций не больше пяти и физических абонентов не больше сотни. Потом эта вся сеть просто переворачивается вверх тормашками и мило умирает. Управляемости ноль, зато работает Vypress и сетевое окружение
При этом по pppoe прекрасно можно раздавать интернет. А можно и по PoPToP
3. Теперь неинтересное. (теория)
Дабы не входить в споры что лучше/хуже (смотрим введение). Отказываемся от широковещательного трафика (полностью). То есть забываем о вайпрессах, насси и обязательно о сетевом окружении. Точка. К чему в данном случае мы приходим? Конечно - или роутеры или дорогие свитчи (последнее оставляем на будущее, когда в кармане будут деньги). Остаются роутеры.
Самое интересное, что роутеры подразумевают разные подсети в сегментах маршрутизации (мы должны разделять физически все сегменты, чтоб широковещательный трафик не бегал). А с ними и прописывание маршрутов у клиентов (именно прописывание, т.к. основной шлюз у нас уже в ВПН задействован для выхода в интернет). То есть мы должны прибежать к каждому абоненту, прописать статический маршрут. При этом мы обязательно теряем одну очень важную деталь – управляемость с точки зрения айпи-адресов. То есть выгодней и удобней всего иметь DHCP сервер, который автоматически всё раздаст (или по указаному мак-адресу или по диапазону). То есть при возникновении проблем – не нужно бежать к абонентам и у каждого менять айпи-адреса с маршрутами. Для сети, в которой до 100 абонентов можно и побегать (расстянув удовольствие на месяц-два). Для сети с количеством абонентов 300, 400, наконец 1000 ненабегаешься – проще подправить конфиги на сервере DHCP. (для точности стоит заметить – в больших сетях именно так всё и работает). К чему я заговорил о DHCP? Очень просто. Мы хотим строить сеть правильно с самого начала (введение), чтобы при покупке умных свитчей и реформировании сети это не сказалось на конечных абонентах и ваших нервных клетках.
4. Отступление.
Имею практику работы с маршрутизаторами и статическими маршрутами – очень неудобно ручками всё вбивать, если у тебя в цепочке стоит больше пяти роутеров. Поднимать же ospf/bgp/zebra имеет смысл, если уверен в стабильности каналов. А когда мы рассматриваем реальный вариант (пункт 2), когда дешево и сердито (очень сердито и зло, я бы сказал) строится сеть. Любой потерянный пакетик с данными о маршрутизации может завалить всю сеть. На дешевом оборудовании сложно построить радиолинк без потерь, тем более в наше время загаженных радиоэфиров.
5. Теперь о главном.
Что даёт нам роутер – он даёт возможность фаерволинга (если это линукс/бсд, то думаю и так всё понятно, а кроме *никс на эту роль ничего другое не подойдет, увы – фактор мы выбрали – дешевизна, а это и оборудование). Плюс очень вкусно использовать шейпинг – зарезал абонента на мегабит или на 10 мегабит и вполне спокойно можно предоставлять услуги дальше.
И непосредственно главное – причем здесь ProxyARP. Думаю уже и так всё понятно. Делаем сеть, например 180.22.0.0/16 и делим по сегментам. Объединяем радиолинками р2р с роутерами с proxyARP+DHCP+Shaper/Firewall и вполне вменяемая/управляемая сеть готова. На каждый сегмент, выдаем, например, /24 подсеть и маршрутизируем на роутерах куда и что надо. Самое главное – у абонентов ничего прописывать не нужно, ARP запросы прекрасно всё выполнят за вас.
6. Теперь о грустном. (специфика)
Тонкие моменты использования ВПН. Те кто знают – подтвердят: в pppoe есть проблемка – она не терпит шлюзов. Точнее терпит, правда только один и тот должен быть с pppoe-relay демоном висеть. В данной структуре сети проблематично вести ВПН-туннель основанный на pppoe в единый центр. То есть еще одно ограничение – используем PoPToP (о других VPN ничего сказать не могу – не изучал/не знаю).
7. Вывод.
Имея сеть WAN, формально с гирляндой LAN подсетей в разные стороны с роутерами в режиме ProxyARP получаем псевдо-прозрачное соединение. Имеем управляемость на границе каждого сегмента. Управляемость с точки зрения администрирования (определение айпи-подсетей, используя DHCP). И, самое главное, легкость при реформировании сети в будущем – нам не нужно бегать к абонентам, они продолжат работать и дальше.
Минусы в данной ситуации тоже есть.
Непосредственно в ВПН (выше описано). Производительность роутеров (если мы используем проводной сегмент и только провод, то PCrouter должен быть мощным, чтоб маршрутизировать нормально поток данных и поток пакетов). Но, учитывая что на практике у нас магистралью выступает радиолинк, скорость которого редко превышает 25мбит, то сполне спокойно с маршрутизацией может справится не самый последний ПиСишник. А теперь интрига – достаточно много оборудования беспроводного уже умеет режим роутера и внутри держит линукс – мысль можно продолжить… Переносим роутер, фаервол/шейпер/dhcp на точку доступа и получаем идеал сети с минимум вкладов.
8. Post Scriptum
Прошу оценить идею и высказать свое мнение/замечание.
Обращаю внимание – идея такой сети пришла в голову в связи использованием и написанием прошивки для точек доступа DWL-G700ap с роутером и всеми вышеперечисленными возможностями. Стоимость точек доступа около 50уе, что очень неплохо. Для бюджетного варианта использования как раз подходит.
-
Да, действительно были планы до сентября закончить, учитывая, что переделывать начал в июне, на том и остановился, т.к. был завален работой и мыслью об отдыхе. Отдохнуть не дали, вот теперь пашу дальше. О приблизительных сроках выхода говорить не буду, т.к. и сейчас завален работой, и в соседнем треде обещался сервер для чата закончить. Сам шейпер переписать - около недели времени. Ориентировочно ним буду заниматься сразу по завершению работы над чатом
Насчет возможности использования "гуляющего" канала - подумать можно, но не факт что получится легкой кровью это реализовать. В общем буду думать - безвыходных ситуаций не бывает.
Ну и конечно, все возможности будут опциональными. Вот пока не начал писать жду новых предложений, для того, чтоб упарвление шейпером сделать простым и понятным, а то первая версия немного с толку сбивает
-
В общем мне они так и не ответили... А исходники чата нужны, а то проект засох, насколько я смотрю...
насчет сервака, выложу скоро уже рабочую альфа версию (альфа - потому что не все функции будут работать). Я уже заколебался, там столько писанины, а времени всё нет. Щас уже некоторые функции работают и вроде бы неплохо
. -
Мдям, я пока пишу на Си, вот теперь думаю, стоит ли переходить на Си++
Фотка - супер.
-
Третья схема, ИМХО дороже будет, нежели первая. А первая - самая правильная, при правильном оборудовании. Второая сама дешевая, но неживучая при нагрузках - будете иметь проблемы, точнее проблемы будут иметь вас
и очень часто...Поэтому останавливайтесь на первой схеме, упсами запаситесь на каждый свитч и проблем точно не будет.
ЗЫ. НАсколько я понял сеть в общаге, поэтому упсы не столь важны, т.к. обычно свет выключают сразу во всем здании
ЗЫЫ. Третья схема не оправдывает тех затрат, поэтому первая. Тем более если будете пользовать упсы, то STP не нужен будет, всё и так стабильно будет работать.
-
Мне сказали, что у Д-линк саппорт лучше, да и прошивки чаще обновляют/исправляют
-
Извиняюсь, что долго не отвечал - завален работой по самое нехочу. Шейпер однозначно будет переписан. И переписан по всем швам. Уже сейчас нужна поддержка управления на основе списков и общих классов. Как упоминалось раньше - управление для динамических интерфейсов используя ip-up ip-down.
Просьба ко всем, пишите сюда что желаете увидеть в следующей версии. Шейпер обещаю написать без глюков и полностью оттестировать, естественно скрипты не прячу и всё всем будет доступно.
-
Хм, на сайте мыло не нашел, я писал на мыло, что указано в чате раздел "О программе"
-
Написал письмо авторам чата - молчат. Хотел взять у них исходники чата для ускорения работы, а в ответ тишина. У кого получилось найти/получить исходники сего чуда? А то влом свой клиент писать с нуля.
ЗЫю Чат в последней версии объявлен OpenSource проектом, только вот исходников я никак не нахожу
-
Думаю работать будет. Как доделаю - выложу обязательно с исходниками.
-
Половину сделал, щас делаю обработку протокола и легкую админку...
-
Я эти точки тестировал на скорости 18Мбит в Г диапазоне на столе, получил 2700pps и это не предел, у меня просто комп слабенький, вот и не смог выше параметр поднять... На неделе постараюсь еще протестировать в другом месте эти точки.
-
Уже начал... Судя по протоколу вполне можно будет сделать даже примитивное администрирование, плюс плагины писать, типа викторины
Следующий вариант как раз таким и будет
НКРЗ ТЕНДЕР 5 ГГц
в Мережа - бізнес
Опубліковано:
Ну для внутриофисного разрешили... Вполне реально, что разрешать и дальше...