deep_admin
-
Публикации
237 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем deep_admin
-
-
2.При выдачи адреса клиенту создается статический маршрут, который указывает что адрес клиента находится на нужном порту. Например 123.123.3.5 на интерфейсе ether6
теоретик детектед. типичная ситуация - небольшая оператор в мухосранске, пул /21 - 2048 адреса, абонентов 3000. Абонентов онлайн ~1500. Если делать то, что вы предлагает(статик роут на порт), то нужно, чтобы IP-адресов было не меньше, чем абонентов, т.е. фактически преимущество динамической выдачи(ради экономии IPv4) никак использовать в вашей схеме нельзя. Да и не только у небольших операторов такая ситуация. И середнячок и крупняк в аналогичных условиях есть.
И, кстати, то что вы предлагаете на Cisco делается абсолютно без каких-либо геморроев(статик роуты и редистрибьюция статик роутов в какой-нибудь IGP никаких сложностей на Cisco никогда не вызывало).
Это у вас теоретик детектед. Написал же при выдачи адреса прописывать статический маршрут, следовательно если абонент более 10 минут не активен и вышло время аренды адреса, он удаляется вместе с маршрутом и может быть выдан другому абоненту. Выдачей и удалением адресов занимается биллинг, он все знает про всех. Собственно статический маршрут в пределах своей железки, для других устройств он уже не статический=)
Покажите кусок конфига dhcp-сервера на микротике который после выдачи лизы прописывает роут на выданный адрес. В вике от микротика такого нет
-
Самый бюджетный вариант 1сv8 сервера - линукс с постре от 1с. Линуксовая версия пускает до 12 клиентов. Ключики в режиме толстого клиента с юзерских компов.
-
Никогда не замечал подобных проблем, если где-то канал упадет, то трафик сразу переключается на другой. Если даже произойдет кратковременный обрыв, то он будет меньше, чем при использовании RSTP.
У вас в оспф бекбоне сколько роутов?
А если радио начинает флапаться, что тогда происходит?
На базах если это микротик, и на отдельных микротиках, если базы других производителей.
Не понял у вас вплс - между мт базой и мт цпе? Значит на базе пппое-сервер?
-
Вы конкретику давай, а не пространные рассуждения. Всеж по мплс/еоайпи вы собираетесь гонять езеренет, какая разница?
Пример схемы включения с мплс приведите.
Схемы такие же, как и с вланами, только не коммутаторы а маршрутизаторы используются. Из дополнительных плюсов можно всегда нагружать резервные каналы, даже не симметричные. В случае вланов они либо не используются, либо надо в бондинг объединять. Но если они разнесены то последнее сделать не получится.
У еойпи на мт есть проблемы, начинаются дропы на скоростях выше 20мбит, ядерный кот нашел и разжевывал, можно по форуму поискать.
С мплс (вы же имеете ввиду vpls?) тоже не все гладко. Точнее со скоростью распространения ldp меток с использованием ospf как igp.
Кстати в вашей схеме vpls'ы терминируются с абонентских cpe в ядро или с отдельного роутера на каждой бс?
-
Есть конкретные доказательства дропов тегированного трафика в радио?
Вланы предназначены для передачи в пределах кабельной сети локальных масштабов. Все что больше требует применения других технологий, основанных на IP. Потому что при "длинных" сегментах велика вероятность потери пакета по пути следования.
Доказательств тут много, особенно при переводе сетей L2 на транспорт L3. Пиковая пропускная способность не увеличивается из-за накладных расходов, зато практически полностью исчезают потери пакетов и большие колебания задержки.
Вы конкретику давай, а не пространные рассуждения. Всеж по мплс/еоайпи вы собираетесь гонять езеренет, какая разница?
Пример схемы включения с мплс приведите.
-
VLAN по радио ущербная технология. Если взять например базу с предоставлением каждому клиенту трафика в своем влане, то она (база) должна сама снимать метки и посылать каждому клиенту предназначенные ему данные. Если же передавать просто трафик по радио с кучей вланов, то делать это можно только в пределах одного пролета. На последующих скорость передачи данных уже падает, растут задержки, особенно при потерях данных.
Поэтому в радиосети лучше использовать туннели EoIP или MPLS, пусть будет немного накладных расходов, зато никаких проблем с пробрасыванием вланов и ловлей глюков. И легко резервные каналы добавлять, да и переключение на резерв будет происходить незаметно для клиентов.
Есть конкретные доказательства дропов тегированного трафика в радио?
-
На базе не будут WDS интерфейсы создаваться, как вы будете управлять трафиком и наблюдать за активностью клиентов?
ну если только в этом проблема :)
Мне достаточно смотреть в registration. Хотя вообщето много работы за меня делает dude.
-
А если вам надо будет 2-х клиентов к базе подключить, как тогда быть? Вообще WDS отключать=)
Да ладно, на вики мтика все расписано: база 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 не будут работать?
-
А если вам надо будет 2-х клиентов к базе подключить, как тогда быть? Вообще WDS отключать=)
Да ладно, на вики мтика все расписано: база 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 в десятки пролетов, естественно работает такая конструкция плохо и постоянно вылезают различные неприятности.
Фильтра в бридже на мт проблему не решат полностью. Да, форвардинга фреймов не будет, но маки то попадать в таблицу будут! Проверьте сами поменяв мак на подключенном к МТ устройстве на такой же как у МТ, например.
-
Это я в курсе что уровень низкий.
Как я писал ранее:
Вот по поводу прямой видимости есть сомнения...
С одной стороны все хорошо - высокий берег реки, с горки практически стреляю и за рекой равнина.
А с другой стороны антенна висит на уровне третьего этажа и поднять выше некак.
В бинокль на горизонте видна посадка с деревьями более высокими чем уровень подвеса антенны.
Поэтому в 5 ГГц экспериментировать пока не хочется.
Антенны с обоих сторон - офсетные параболы 1.2 м с векторовскими облучателями.
Кабеля (Belden H-1000) в точке 2 метра полтора, в точке 1 - метра 3.
Для начала постройте профиль трассы, хотя бы в гугл-земле. Может вам мешают не только деревья.
Также подумайте о мачте с берега реки - может вы переплюните деревья с одной стороны по высоте.
-
у вас очень низкий уровень сигнала для такого линка. Или нет прямой видимости или банальная несведенка. Расчеты дают примерно -68дб на антеннах с КУ 24дб. Офсетки 1.2 с нормальными облучателями дают усиление около 30дб. Сигнал в таком случае должен быть около -56.
Вобщем проверяйте сначала ВЧ-часть.
-
/int wire scan 0 duration=10
не оно?
-
10-5MHz - если построить сеть 2,4 ? какие недостатки? - тарифы 1-2мб , 15 юзеров ,. база mikrotik клиенты ubnt loko
В 10 мгц будет в идеале 10-12 мбит, в 5 мгц 5-6 мбит. О 15 юзерах на сектор можно забыть сразу.
В реале на 5мгц дай-бог 3мбита на сектор получить. Причем одинакого хреново что у мтика, что у убнт. На 10мгц - все прекрасно.
-
тем не менее 150 мегабит по внутреннему тесту, да и как Вы заметили в зоне нашего линка присутствуем еще один линк на близких частотах, правда мы не знаем чей, к сожалению линк проходит через крыши и зона френеля снизу закрыта складками местности и деревьями, не смотря на прямую видимость, антенны висят на мачтах, использованы диши на 30 децибел
Посчитайте сначала свою трассу на http://nporapira.ru/sections/4/articles/28 (Расчет энергетического бюджета)
Вбиваем:
частота: ну пусть будет 5100
расстояние: 4км
мощность передатчика: пусть будет 17дб (хотя в рокетах более 20дб)
усиление антенны передатчика/приемника: 30дб
потери в кабеле и разъемах: оставляем 1.5дб
чувствительность приемника: -70
считаем: -44.6дб
ваш уровень: -52 -54 дб
Либо сильно мешают деревья, либо антенны смотрят в разные стороны. Часто такая ошибка бывает что одна антенна смотрит верно, а вторая отстраивается по боковому лепестку первой.
-
50 мегабит мерялись iperf`ом , закачкой файлов по ftp, в то время как встроенный спидтест рокетов показывал по 140-147 мегабит
Судя по 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 на клиенте.
-
Опубликовано · Изменено пользователем deep_admin · Жалоба на ответ
каналы были разные,
я если честно грешил на коммутаторы (DES 1005), к которым подключал DAP 1150,
поскольку в эти коммутаторы были подключены рабочие станции
на прямую патчкордом два DAP не соединяли
вывод сделал потому, то до DES 1008 и одного из DAP использовал DIR 300, было еще хуже.
Кстати, насколько я знаю в mesh, подобное падение скорости тоже заметно после двух хопов
Смотрите - основная проблема падения скорости в обычном вай-фае из-за потерь пакетов. Протокол TCP при увеличении времени ожидания аck-пакета подтверждения сегмента (или его потери и соответственно переповторах) начинает уменьшать окно - соответственно падает скорость. Проверьте скорость UDP-протоколом - такого сильного падения быть не должно.
50 мегабит мерялись iperf`ом , закачкой файлов по ftp, в то время как встроенный спидтест рокетов показывал по 140-147 мегабит
Судя по 140 мбитам ширина полосы у вас 40 мгц. А расстояние и уровень сигнала каков?
1) Колдуйте с версией прошивки - в последних сильно увеличилась скорость одной tcp-сессии.
2) Проверяйте минимум на 20 параллельных tcp-сессиях ну или на udp
3) Покажите с какими ключиками вы запускали с двух сторон iperf
-
deep_admin возможно, не спорю,
тогда еще вопрос из-за чего наблюдалось падение скорости при увеличении числа хопов
При правильном выборе и установке антенн, а также соблюдении взаимовлияния частот падений быть не должно на 2-3 хопах при стандартных методах тестирования (пинги,прокачки,iperf). На большем кол-ве хопов из-за отсутствия единого источника синхронизации (которого нет в вай-фае) будет задержка существенно скакать. Это уже будет заметно на глаз.
Если у вас на 2-х хопах было снижение скорости более чем на 30-50% то точно есть проблема. Проверьте не на одном или соседних каналах работают точки.
длинк, микротик, можно и убнт приплести, тоже как то раз видел в идеальных условиях прямой видимости как рокеты по 50 мегабит гоняли...
Тут кстати очень просто проверить: берем 2 устройства, выкручиваем на столе максимальную производительность. Например для рокетов при работе 2-х чейнов в 20 мгц мксимальная сквозная прокачка (throughput) на уровне 105-110мбит полудуплекса (скорость на радио 130Mbit). Ставим рокеты в линк и крутим антенны и меняем каналы пока не добьемся хотя бы 100мбит. Если видите 50мбит макс - ищем проблему (неправильно собраны или установлены антенны - не сведены например, или хреновые пигтейлы).
-
SaaB95 я может не так выразился, про микротик вообще не говорил, что не буду использовать
Скажу больше, именно от вас узнал, что он в природе существует, и за что благодарен
и он ляжет в один из вариантов.
что касается Dlink, это не приговор, да есть опыт, да знаю его приколы некоторые,
и я не агитирую обеими руками за него.
Однако, осмелюсь возразить вам в том, что 22 Мбит/с на столе
Зимой мы колдовали над DAP 1150, скорость была до 40 - 45 мбит при одном прыжке
20-25 Мбит при двух прыжках, и около 15 Мбит при трех прыжках
это что касается мостов
Saab95 имеет ввиду 45мбит при ширине полосы 20мгц без всяких турбо итд. Без аггрегации фреймов на стандартном 802.11 это к сожалению невозможно. То что вы получали на длинке это было в полосе 40 мгц.
-
если честно, я думал делать на двух частотах
на 5 и 2,5 ГГц
5 ГГц это транспортная сеть
2,5 ГГц это для клиентов
Подключать аппаратоно следующим образом:
столбе весит от 2 до 3 точек:
Одна работает в режиме репитера для моста на выбранной частоте
Вторая в режиме точки доступа для клиента в режиме выбора лучшего канала
Третья если есть в режиме точки доступа для следующего репитера если есть необходимость
В каждом мосту своя частота, свой SSID свой ключ
Согласен про прикол с падением скорости при ретрансляции знаю
поэтому ретрансляторов будет минимальное количество, антенны на транспортной сети будут yagi по 20 dBi 20 град
на клиентов - сектора по 16 dBi 120 град
Либо придется делать mesh сеть на базе MAP Planet
Примерно так
Вы считали взаимовлияние секторных антенн друг на друга? У вас же обычный коллизионный вай-фай, базы не синхронизированы, при 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 -
Повесил 3 базы с секторными антеннами MTI 120 градусов.
С одной точки запустил передачу данных, на других анализатор спектра, он вообще не показал излучения от базы, которая передавала информацию:
Передача велась на частоте 5675MHz. Расстояние между антеннами 2.5 метра.
Просевший noise floor -95 на 5675 и 5680 - не оно?
ЗЫ: То что базы друг друга плохо видят это еще ничего, зато на 2-х из 3-х баз будет хорошо видно UL активного клиента попадающего в край сектора :)
MikroTik CCR-1036
в Mikrotik коммутаторы и маршрутизаторы
Опубликовано · Изменено пользователем deep_admin · Жалоба на ответ
Угу, только в вашем случае не сработает, ибо 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 неполучится