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мгц - все прекрасно.

Посчитайте сначала свою трассу на http://nporapira.ru/sections/4/articles/28 (Расчет энергетического бюджета) Вбиваем: частота: ну пусть будет 5100 расстояние: 4км мощность передатчика: пусть будет 17дб (хотя в рокетах более 20дб) усиление антенны передатчика/приемника: 30дб потери в кабеле и разъемах: оставляем 1.5дб чувствительность приемника: -70 считаем: -44.6дб ваш уровень: -52 -54 дб Либо сильно мешают деревья, либо антенны смотрят в разные стороны. Часто такая ошибка бывает что одна антенна смотрит верно, а вторая отстраивается по боковому лепестку первой.

Судя по 140 мбитам ширина полосы у вас 40 мгц. А расстояние и уровень сигнала каков? 1) Колдуйте с версией прошивки - в последних сильно увеличилась скорость одной tcp-сессии. 2) Проверяйте минимум на 20 параллельных tcp-сессиях ну или на udp 3) Покажите с какими ключиками вы запускали с двух сторон iperf прошивка свежайшая 5.5 ширина 40 мГц Station MAC Device Name Signal / Noise, dBm Distance TX/RX, Mbps CCQ, % 00:27:22:хх:хх:хх ххх -51 / -91 2.1 miles (3.3 km) 270 / 270 98 точная юстировка до конца пока правда не произведена, о чём говорит разница в 2 децибела по каналам Chain 0 / Chain 1: -52 / -54 dBm а ключики iperf -s -c без каких либо ухищрений с ключами -P -w -d, да и закачка по ftp и http показала те же результаты Крайне странно с такими уровнями и на таком расстоянии внутренний тест должен дать порядка 200мбит полудуплекса. Посмотрите насколько падают радиоскорости когда вы запускаете встроенный тест, причем проверяйте последовательно transmit/receive. Шумы в -91 подразумевают наличие других точек на соседних каналах. Пробуйте как изменится скорость при смене частоты. Кстати какие антенны у вас и как смонтированы? (то есть нет ли сзади антенны бетонной стены, не через крышу ли проходит линк итд) Дефолтные значение иперфа подразумевают очень маленький буфер для tcp. Вы просто не раскачиваете свой канал. Для tcp: одна сторона: iperf -s -w 256k другая: iperf -c IP -w 256k -P 20 -t 100 -i 2 Для udp: iperf -s -u iperf -c IP -u -P 20 -t 100 -i 2 -b 200M Для дуплексного теста добавляете -d на клиенте.

Смотрите - основная проблема падения скорости в обычном вай-фае из-за потерь пакетов. Протокол TCP при увеличении времени ожидания аck-пакета подтверждения сегмента (или его потери и соответственно переповторах) начинает уменьшать окно - соответственно падает скорость. Проверьте скорость UDP-протоколом - такого сильного падения быть не должно. Судя по 140 мбитам ширина полосы у вас 40 мгц. А расстояние и уровень сигнала каков? 1) Колдуйте с версией прошивки - в последних сильно увеличилась скорость одной tcp-сессии. 2) Проверяйте минимум на 20 параллельных tcp-сессиях ну или на udp 3) Покажите с какими ключиками вы запускали с двух сторон iperf

При правильном выборе и установке антенн, а также соблюдении взаимовлияния частот падений быть не должно на 2-3 хопах при стандартных методах тестирования (пинги,прокачки,iperf). На большем кол-ве хопов из-за отсутствия единого источника синхронизации (которого нет в вай-фае) будет задержка существенно скакать. Это уже будет заметно на глаз. Если у вас на 2-х хопах было снижение скорости более чем на 30-50% то точно есть проблема. Проверьте не на одном или соседних каналах работают точки. Тут кстати очень просто проверить: берем 2 устройства, выкручиваем на столе максимальную производительность. Например для рокетов при работе 2-х чейнов в 20 мгц мксимальная сквозная прокачка (throughput) на уровне 105-110мбит полудуплекса (скорость на радио 130Mbit). Ставим рокеты в линк и крутим антенны и меняем каналы пока не добьемся хотя бы 100мбит. Если видите 50мбит макс - ищем проблему (неправильно собраны или установлены антенны - не сведены например, или хреновые пигтейлы).

Saab95 имеет ввиду 45мбит при ширине полосы 20мгц без всяких турбо итд. Без аггрегации фреймов на стандартном 802.11 это к сожалению невозможно. То что вы получали на длинке это было в полосе 40 мгц.

Вы считали взаимовлияние секторных антенн друг на друга? У вас же обычный коллизионный вай-фай, базы не синхронизированы, при 17дб мощности передатчика точки и 16дби ку антенны на вскидку расстояние между ними для обеспечения эмс должно измерятся километрами! А вы говорите через несколько столбов. Такая сеть умрет в коллизиях от аплинк-каналов качающих клиентов. Если уж от длинка вас не переубедить, то хотя бы займитесь антеннами. Для транспортной сети вам необходимы направленные антенны с максимально возможным коэф. усиления и минимальными боковыми и задними лепестками. Если нет возможности подобрать что-то из Mars'a посмотрите хотя бы на Jiruos или KBT. С секторными антеннам на 2.4 все плохо. Серьезные производители антенн с нормальными характеристиками на этот диапазон не делают. Выбор биллинга сильно зависит от метода идентификации и авторизации абонента. Определитесь как и вам подскажут что.

1) Выставьте наклон антенны в 0 градусов (у нее родной даунтилт 4 градуса - это написано в инструкции) 2) вынесите антенну так чтоб сзади ничего небыло - у вас типичная переотраженка

2 slv700: пост ни о чем, в первой части вы призываете уйти от л2 на л3,ссылаясь на переповторы фреймов, во второй - себе противоречите. Да, у TC проблема, но не в радио, а в незнании архитектурном. Я бы предложил начать со стандартных cisco guid'ов, сразу исчезнут такие понятия как "центральный роутер", "центральный сервер" или "головной свитч". По поводу инструментов диагностики на тех же рокетах вы ой как не правы, просто не все могут их интерпретировать. Например, отладка для радио: athstats wifi0 17145 recv error interrupts 2 recv eol interrupts 596 global txmit timeout interrupts 397 tx max bf in use 103 tx failed 'cuz too many retries 73550 tx frames with no ack marked 1931411 tx frames with an alternate rate 66695777 total frames received 3590128 rx ack frames 144770 rx too short frames 367 rx invalid frames from mcast src 39 tx rssi of last ack 16316301678 total number of bytes received 79372547459 total number of bytes transmitted rssi of last ack[ctl, ch0]: 39 rssi of last ack[ext, ch0]: 38 34 rx rssi from histogram [combined] rssi of last rcv[ctl, ch0]: 34 rssi of last rcv[ext, ch0]: 33 660190 beacons transmitted 3052 periodic calibrations Antenna profile: [0] tx 0 rx 66695777 [1] tx 57509673 rx 0 6542 netdev queue was full and stopped 1 hw resets was done 1 layer 80211 initiated resets 11n stats 80657487 total tx data packets 43059763 tx when h/w queue depth is low 37597724 tx pkts when h/w queue is busy 590015089 tx schedule ac queue empty 49088550 tx unaggregated frame completions 8280041 tx aggregated completions 80657487 tx block ack window advanced 2201947 tx block ack window retries 80657487 tx block ack window additions 80657483 tx block ack window updates 80657483 tx block ack window advances 2201947 tx retries of sub frames 6028826 tx frames not aggregated 31568933 tx aggr good completions 2201947 tx aggr unacked subframes 1511199 tx aggr old frames requeued 66695777 rx pkts 62884250 rx aggregated packets 700860 rx non qos-data frames 2 rx sequence resets 1188277 rx old packets 44 rx duplicate pkts 60993155 rx block ack window advanced 60995069 rx pkt completions 64 draining tid buf queue on error 2 tid paused 2 tid resumed TXQ[1]:BE tx 82931879 xretry 370 fifoerr 0 filtered 0 no buffs 0 draintxq 0 lcount 0 inusemx 394 TXQ[3]:VO tx 68701 xretry 23 fifoerr 0 filtered 0 no buffs 0 draintxq 0 lcount 0 inusemx 1 0.00 tx unaggregated excessive retry percent 0.00 tx aggregated long retry percent 0.00 tx aggregated excessive retry percent 2.73 tx aggregate subframe retry percent 0.00 tx aggregate subframe excessive retry percent Для L2 и L3 - все соответствующие инструменты тоже есть в дефолтной прошивке (линукс же): ifconfig, tcpdump, tc, brctl и тд Надежность сети на вышеприведенном железе (radwin,redline,motorola) конечно выше, но не из-за якобы инструментов диагностики. 2TC: чтобы выровнять скорость на магистралях (уменьшить ее потери) - добейтесь сначала уменьшения джиттера между хопами, хотя бы до 2-3мс. Для этого пробуйте играться размером суперфрейма агрегации, локом рейтов ну и выключить аирмакс. А также проверяйте езернет (рокеты ой какие капризные в этом плане)

почему нельзя? XM.v5.5-beta9.11320.111223.1732# iwpriv wifi0|grep -i amp AMPDU (1006) : set 1 int & get 0 getAMPDU (1006) : set 0 & get 1 int AMPDULim (1007) : set 1 int & get 0 getAMPDULim (1007) : set 0 & get 1 int AMPDUFrames (1008) : set 1 int & get 0 getAMPDUFrames (1008) : set 0 & get 1 int

Просевший noise floor -95 на 5675 и 5680 - не оно? ЗЫ: То что базы друг друга плохо видят это еще ничего, зато на 2-х из 3-х баз будет хорошо видно UL активного клиента попадающего в край сектора :)