deep_admin

Как же нет в вики? В разделе RADIUS клиента ищите атрибут Framed-Route - http://wiki.mikrotik.com/wiki/Manual:RADIUS_Client - хотя его можно отправлять и отдельной командой по telnet/ssh/API. Адреса куда и для чего отправлять берутся из RADIUS-запроса. Угу, только в вашем случае не сработает, ибо dhcp-server на микротике принимает только вот эти атрибуты: http://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server и вот еще оттудаже: Note: Currently DHCP server requires real interface to receive raw ethernet packets. It cannot function correctly on dummy (empty bridge) interface. то есть никакого ip-unnumbered + dhcp/radius неполучится

теоретик детектед. типичная ситуация - небольшая оператор в мухосранске, пул /21 - 2048 адреса, абонентов 3000. Абонентов онлайн ~1500. Если делать то, что вы предлагает(статик роут на порт), то нужно, чтобы IP-адресов было не меньше, чем абонентов, т.е. фактически преимущество динамической выдачи(ради экономии IPv4) никак использовать в вашей схеме нельзя. Да и не только у небольших операторов такая ситуация. И середнячок и крупняк в аналогичных условиях есть. И, кстати, то что вы предлагаете на Cisco делается абсолютно без каких-либо геморроев(статик роуты и редистрибьюция статик роутов в какой-нибудь IGP никаких сложностей на Cisco никогда не вызывало). Это у вас теоретик детектед. Написал же при выдачи адреса прописывать статический маршрут, следовательно если абонент более 10 минут не активен и вышло время аренды адреса, он удаляется вместе с маршрутом и может быть выдан другому абоненту. Выдачей и удалением адресов занимается биллинг, он все знает про всех. Собственно статический маршрут в пределах своей железки, для других устройств он уже не статический=) Покажите кусок конфига dhcp-сервера на микротике который после выдачи лизы прописывает роут на выданный адрес. В вике от микротика такого нет

Самый бюджетный вариант 1сv8 сервера - линукс с постре от 1с. Линуксовая версия пускает до 12 клиентов. Ключики в режиме толстого клиента с юзерских компов.

У вас в оспф бекбоне сколько роутов? А если радио начинает флапаться, что тогда происходит? Не понял у вас вплс - между мт базой и мт цпе? Значит на базе пппое-сервер?

Схемы такие же, как и с вланами, только не коммутаторы а маршрутизаторы используются. Из дополнительных плюсов можно всегда нагружать резервные каналы, даже не симметричные. В случае вланов они либо не используются, либо надо в бондинг объединять. Но если они разнесены то последнее сделать не получится. У еойпи на мт есть проблемы, начинаются дропы на скоростях выше 20мбит, ядерный кот нашел и разжевывал, можно по форуму поискать. С мплс (вы же имеете ввиду vpls?) тоже не все гладко. Точнее со скоростью распространения ldp меток с использованием ospf как igp. Кстати в вашей схеме vpls'ы терминируются с абонентских cpe в ядро или с отдельного роутера на каждой бс?

Вланы предназначены для передачи в пределах кабельной сети локальных масштабов. Все что больше требует применения других технологий, основанных на IP. Потому что при "длинных" сегментах велика вероятность потери пакета по пути следования. Доказательств тут много, особенно при переводе сетей L2 на транспорт L3. Пиковая пропускная способность не увеличивается из-за накладных расходов, зато практически полностью исчезают потери пакетов и большие колебания задержки. Вы конкретику давай, а не пространные рассуждения. Всеж по мплс/еоайпи вы собираетесь гонять езеренет, какая разница? Пример схемы включения с мплс приведите.

Есть конкретные доказательства дропов тегированного трафика в радио?

ну если только в этом проблема :) Мне достаточно смотреть в registration. Хотя вообщето много работы за меня делает dude.

Да ладно, на вики мтика все расписано: база ap-bridge, клиенты если нужен бриджинг station-bridge, wds везде disabled. http://mum.mikrotik....ess-2012-PL.pdf страница 34 802.11n and WDS • 802.11n frame aggregation can’t be used together with WDS • Max transmit speed drops from 220Mbps to 160Mbps using WDS (UDP traffic) • Station-bridge has the same speed limitations as Station-wds • Avoid using WDS or use Nstreme/Nv2 wireless protocol to overcome this limitation Попробуйте двух клиентов в режиме station-bridge подключить=) Всмысле? то есть вы хотите сказать что база в ap-bridge и более одного клиента в station-brdige не будут работать?

Да ладно, на вики мтика все расписано: база ap-bridge, клиенты если нужен бриджинг station-bridge, wds везде disabled. http://mum.mikrotik.com/presentations/PL12/workshop-wireless-2012-PL.pdf страница 34 802.11n and WDS • 802.11n frame aggregation can’t be used together with WDS • Max transmit speed drops from 220Mbps to 160Mbps using WDS (UDP traffic) • Station-bridge has the same speed limitations as Station-wds • Avoid using WDS or use Nstreme/Nv2 wireless protocol to overcome this limitation

ТС прав в том что проблема имеет место, к сожалению бридж в микротике наследует все глюки бриджа в линуксе. Запоминаем что это не свитч и ingress-filtering'а там нет, мак если попал в таблицу коммутации, то он сразу берется в расчет. Как вариант - если вам нужны тегированнае вланы - используйте только их и на свитче перед базой порт оставляйте в транке. В ubnt или любом другом устройстве с линукс-based прошивкой поведение аналогично. Еще совет - неиспользуйте wds, на клиенте поставьте station-bridge. Кончайте пороть чушь, я предоставил достаточно информации. Сейчас по третьему кругу пойдем. Конфигурацию слить невозможно, winbox постоянно отваливается из-за флуда в управляющем VLAN-е. При физическом отключении точки от коммутатора - флуд чудесным образом прекращается. В понедельник попаду на объект и еще раз сделаю сброс/настройку, но это будет бессмысленное повторение повторенного. Будем менять, к сожалению, на UBNT, и заказывать НЕ на WMD.ru. Ну так и разбирайтесь с флудом внутри сети=) микротик то тут при чем? Зафильтруйте на бридже все маки, разрешите только те, которые нужно и флуд в сторону радиосети идти не будет. Последнее время различные роутеры, компьютеры и прочая техника, подключенная к сети, любят рассылать различный флуд, то DHCP IPv6 гуляет по 5-6 тысяч пакетов в секунду, то тысяча маков на клиентском порту появляется, естественно у коммутаторов и беспроводных устройств сносит крышу от такого и получается флуд внутри сети по всем вланам. Делайте авторизацию по PPPoE, транспорт внутри магистральной сети по IP, никаких вланов - и проблем возникать не будет. Может у меня не бывает проблем с микротиком, потому что сеть грамотно организована и спланирована, авторизация по PPPoE и весь трафик кроме него заблокирован? Многие любят радиоканалы использовать как замену кабельным линиям, делая сеть на L2 в десятки пролетов, естественно работает такая конструкция плохо и постоянно вылезают различные неприятности. Фильтра в бридже на мт проблему не решат полностью. Да, форвардинга фреймов не будет, но маки то попадать в таблицу будут! Проверьте сами поменяв мак на подключенном к МТ устройстве на такой же как у МТ, например.

Антенны с обоих сторон - офсетные параболы 1.2 м с векторовскими облучателями. Кабеля (Belden H-1000) в точке 2 метра полтора, в точке 1 - метра 3. Для начала постройте профиль трассы, хотя бы в гугл-земле. Может вам мешают не только деревья. Также подумайте о мачте с берега реки - может вы переплюните деревья с одной стороны по высоте.

у вас очень низкий уровень сигнала для такого линка. Или нет прямой видимости или банальная несведенка. Расчеты дают примерно -68дб на антеннах с КУ 24дб. Офсетки 1.2 с нормальными облучателями дают усиление около 30дб. Сигнал в таком случае должен быть около -56. Вобщем проверяйте сначала ВЧ-часть.

/int wire scan 0 duration=10 не оно?

В 10 мгц будет в идеале 10-12 мбит, в 5 мгц 5-6 мбит. О 15 юзерах на сектор можно забыть сразу. В реале на 5мгц дай-бог 3мбита на сектор получить. Причем одинакого хреново что у мтика, что у убнт. На 10мгц - все прекрасно.