Перейти к содержимому
Калькуляторы

LHG XL 5 ac PTP тонкая настройка

2 часа назад, xabarov сказал:

Все верно. А в 70 ГГц распространение радиоволн лучше, чем в 60 ГГц,

а можно доковыряться до слов? ))))) как бы не распространение лучше, а затухание в нашей среде обитания меньше ........

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Корпич

 

Что за калькулятор используете ? 

Какой сигнал я должен видеть на антенне для полосы в 80МГц?

14 часов назад, Saab95 сказал:

На микротике радио настраивается достаточно просто - свести антенны, убавить мощность до адекватных значений, провести тесты пропускной способности в каждом направлении по UDP для определения максимальных канальных скоростей, если CCQ не 100,

Для AC  все так же ? Дополнительно ничего не нужно ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

20 часов назад, Saab95 сказал:

TCP тоже будет ни о чем, т.к. в транспорте ни чем от UDP не отличается, если надо канал загрузить. Пингов нет потому что они там шли с периодическими потерями, т.к. абоненты догружали канал под завязку, как я ранее и писал 300-350 реального трафика пропускает. В моменты, когда все дома сидели там 300-320М бегало. Сейчас лето никого дома нет.

 

И да, до канала и после стоят роутеры, в канале только 4 мак адреса передаются. Если через радиоканал кучу маков гонять, ясно дело скорость снижается.

Можно поподробнее про зависимость производительности радиомоста от количества передаваемых через него маки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 часов назад, xabarov сказал:

Покажите этот абонентский трафик "в полном объеме". Или просто повторите тест с ТСР. Не сложно ведь? 

Поверил Саабу , заказал 2шт 922е платы с интегрированным  ac. О результатах отпишу.

А снятые платы на ремонт дохлых  sextant-g потрачу если влезут

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, XGate сказал:

Можно поподробнее про зависимость производительности радиомоста от количества передаваемых через него маки?

+

Мне тоже очень интересно, т.к. для резерва оптики ни о каких роутерах в разрыве речи не может идти. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

@LostSoul 

 

Ваш конфиг с Nstream помог, реально в Nstream работает лучше, TCP тест "устаканился" и теперь ровный график без скачков. Так же получается BTest выдает 120 Мегабит дуплекс. И 200Мбит симплекс.  Какие результаты получились у Вас ? 

1.thumb.png.536e22035178da8aa6d2469cf914cf51.png

 

Это так же подтверждает и тест iperf. 

 

iperf3 -c 100.64.100.13 -P 15 -t 30

[SUM]   0.00-30.00  sec   656 MBytes   183 Mbits/sec  951             sender
[SUM]   0.00-30.00  sec   651 MBytes   182 Mbits/sec                  receiver

iperf3 -c 100.64.100.13 -P 15 -t 30 -R


[SUM]   0.00-30.00  sec   728 MBytes   204 Mbits/sec  734             sender
[SUM]   0.00-30.00  sec   720 MBytes   201 Mbits/sec                  receiver

 

Ночью попробую реальный трафик пустить. В целом уже не плохо. 

 

Почему-то через Nstream сигналы стали хуже, это нормально?

 

2.thumb.png.416d1fa29c8e60a6a6f445114979220b.png

 

Конфиг получился такой:

 

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode band=5ghz-onlyac basic-rates-a/g="" channel-width=20/40/80mhz-Ceee disabled=no \
    frequency=5825 frequency-mode=superchannel guard-interval=long ht-basic-mcs=mcs-15 ht-supported-mcs=mcs-15 hw-retries=15 installation=outdoor mode=bridge \
    nv2-preshared-key=secret nv2-security=enabled radio-name="" rate-set=configured ssid=Ivanova supported-rates-a/g="" vht-basic-mcs=mcs0-9 \
    vht-supported-mcs=mcs0-9,mcs0-9 wds-default-bridge=bridge1 wds-mode=dynamic wireless-protocol=nstreme wps-mode=disabled
/interface wireless nstreme
set wlan1 disable-csma=yes enable-nstreme=yes framer-policy=exact-size

/queue type
set 0 pfifo-limit=500
set 1 pfifo-limit=500
set 2 kind=pfifo pfifo-limit=500
set 9 pfifo-limit=500

 

Есть что еще можно "подкрутить" ? 

Изменено пользователем divxl

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сигнал стал "хуже" потому что у Вас запустилась модуляция MSC8, или потому что другая погода, или другое время суток, или ...

Я бы ограничил максимальную модуляцию MSC8 или даже 7. Девятая  все равно по сигналу не включается, а попытки перехода на неё могут быть.

Ну и попытаться поднять сигнал подстройкой антенны.

 

зы

Что за калькулятор используете ? 

 

таблица уровней сигнала 802.11 Data Rates & SNR Requirements 

pps 

попробуйте сузить полосу до 40 (Се) возможно пропускная не уменьшится

Изменено пользователем Корпич

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

23 часа назад, divxl сказал:

Ваш конфиг с Nstream помог, реально в Nstream работает лучше, TCP тест "устаканился" и теперь ровный график без скачков. Так же получается BTest выдает 120 Мегабит дуплекс. И 200Мбит симплекс.  Какие результаты получились у Вас ? 

Для меня все эти параметры радио на 20% китайская грамота.

Благодарствуйте пользователя a25k03 и slv700 , за то что довел a25k03 и спровоцировал на демонстрацию того, что человека с прямыми руками любая техника боится.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 23.06.2020 в 09:42, divxl сказал:

Для AC  все так же ? Дополнительно ничего не нужно ?

Для АС надо на вкладке HT MCS снять все галочки, на Data Rates так же снять все галочки A/G, и только внизу скорости для АС убрать 9 скорость, как писали выше.

 

В 23.06.2020 в 10:27, XGate сказал:

Можно поподробнее про зависимость производительности радиомоста от количества передаваемых через него маки?

Всем известно что на маленьких пакетах пропускная способность снижается. И по этой же причине тесты по TCP всегда показывают меньшую скорость, т.к. в одну сторону идут пакеты 1500 байт, а в другую подтверждения на 64 байта. То есть если на 1500 канал пропускает 300М, то на 64 байт канал пропустит 50М, а 300+50/2 это всего 175М трафика. На L2 каналах, когда в них идет трафик большого количества абонентов, например 100 человек, то каждый абонент генерит ARP, по каналу идет вообще не несущий смысловой нагрузки трафик, например ipv6 и прочий мусор. Весь он обычно мелкими пакетами и он только своим присутствием занимает порядка 10-15 процентов всей пропускной способности. Добавляем сюда еще и ошибочный трафик, который не должен попадать в канал из центра сети, но по неким причинам туда заруливает, тогда падение скорости оказывается еще большим.

 

Если зайти на вкладку hosts бриджа, то можно посмотреть, что со стороны влан адаптера или wds маков меньше, чем на самом деле передается, просто беспроводной адаптер не изучает их больше 128 там нельзя увидеть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 23.06.2020 в 17:24, divxl сказал:

 

Ваш конфиг с Nstream помог, реально в Nstream работает лучше, TCP тест "устаканился" и теперь ровный график без скачков. Так же получается BTest выдает 120 Мегабит дуплекс. И 200Мбит симплекс. 

 

Попробуйте полосу 40 МГц, скорее всего пропускная способность останется примерно такой же. Если так, то нет смысла засирать вдвое больше спектра. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

19 часов назад, Saab95 сказал:

Если зайти на вкладку hosts бриджа, то можно посмотреть, что со стороны влан адаптера или wds маков меньше, чем на самом деле передается, просто беспроводной адаптер не изучает их больше 128 там нельзя увидеть.

@Saab95

 

Это очень важная информация, зашел в hosts посмотрел и охринел. :-)
Благодарю вас!

 

У меня релейки до деревень построены на bridge и station wds. В деревне ставлю AP, на клиентских точках настраиваю pppoe-client на главный pppoe-сервер.
Есть смысл на AP подкрутить чтоб маков уменьшить? Если да что именно посоветуйте подкрутить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если у вас PPPoE клиент на абонентской антенне, а по кабелю ему уже раздается серая сеть, то количество маков и так минимально.

Делать PPPoE сервер на БС не очень правильно, лучше на БС беспроводной адаптер сбриджевать с EoIP туннелем, и его протянуть в центр на PPPoE сервер, где для каждого туннеля создадите свой PPPoE сервер прямо на туннеле.

В этом случае выделяете служебную серую адресацию для антенн моста, и один адрес для антенны БС, между адресом БС и центром и поднимаете EoIP туннель. В этом случае у вас будет L2 сеть между абонентами и БС, а дальше все побежит уже по L3. То же самое и с мостами - там будет совсем маленький сегмент. По такой схеме ранее работало огромное количество БС с клиентами, сейчас уже меньше осталось антенн, т.к. большая часть абонентов на оптику пересела.

 

Кроме всего такая схема позволяет легко делать резервные каналы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 24.06.2020 в 23:54, Saab95 сказал:

Всем известно что на маленьких пакетах пропускная способность снижается. И по этой же причине тесты по TCP всегда показывают меньшую скорость, т.к. в одну сторону идут пакеты 1500 байт, а в другую подтверждения на 64 байта. То есть если на 1500 канал пропускает 300М, то на 64 байт канал пропустит 50М, а 300+50/2 это всего 175М трафика. На L2 каналах, когда в них идет трафик большого количества абонентов, например 100 человек, то каждый абонент генерит ARP, по каналу идет вообще не несущий смысловой нагрузки трафик, например ipv6 и прочий мусор. Весь он обычно мелкими пакетами и он только своим присутствием занимает порядка 10-15 процентов всей пропускной способности. Добавляем сюда еще и ошибочный трафик, который не должен попадать в канал из центра сети, но по неким причинам туда заруливает, тогда падение скорости оказывается еще большим.

 

Если зайти на вкладку hosts бриджа, то можно посмотреть, что со стороны влан адаптера или wds маков меньше, чем на самом деле передается, просто беспроводной адаптер не изучает их больше 128 там нельзя увидеть.

А где-то подробнее этот вопрос можно почитать, может испытания есть какие? Я потыкал ради интереса доступный мне мост от убнт и МТ и в целом проблемы не увидел. Да, при тесте пакетами размером 64 скорость заметно ниже, однако если этот же мост параллельно догрузить "обычными" пакетами (1500), то суммарно мелких+стандартных пакетов он прокачивает ровно столько же сколько и только стандартными без мелких. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

23 минуты назад, XGate сказал:

он прокачивает ровно столько же сколько и только стандартными без мелких. 

Видимо у вас пакинг включен. Это увеличиаает задержки

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

25 минут назад, LostSoul сказал:

Видимо у вас пакинг включен. Это увеличиаает задержки

Возможно, однако на Ubnt AF5XHD вообще не нашел переключателя под это дело. Мобыть автоматизировано как-то у них

Изменено пользователем XGate

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, XGate сказал:

А где-то подробнее этот вопрос можно почитать, может испытания есть какие?

Тут дело когда все идет в виде реального абонентского трафика. По сути если за каналом 10-20 человек, они не создадут такой пакетной нагрузки, а когда за каналом 150-200, и сам этот радиоканал как бы пропускает 300М, то вот тут и вылезают все прелести пакетной нагрузки. Что по тесту как бы 300 проходит, а реально абоненты столько выкачать не могут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 25.06.2020 в 20:23, Saab95 сказал:

Кроме всего такая схема позволяет легко делать резервные каналы.

Как бы вы делали резерв IPoE  QinQ схем  в радио ? 

 

При условии, что BRAS не Mikrotik. 

Изменено пользователем divxl

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

22 часа назад, divxl сказал:

Как бы вы делали резерв IPoE  QinQ схем  в радио ? 

 

При условии, что BRAS не Mikrotik. 

У нас ранее было много таких каналов. Когда в центре стоял железный брас или некая циска, на которую должны были приходить вланы абонентов. Перед ней ставили микротики, с них поднимали EoIP туннели до каждой абонентской антенны, и через L3 транспортную сеть все шло на эти центральные микротики, где EoIP бриджевался с нужным вланом с QinQ и уходил на брас. Никаких проблем не возникало, ну если только не брать в расчет пакетный оверхед.

 

В дальнейшем брасы и циски переводили на схемы авторизации по IP адресу, и терминация IP полностью уходила на микротик.

Кто не знает авторизация по IP адресу на брасах работает следующим образом - как только поступает новый IP адрес на брас (пакет с этим IP), брас через радиус спрашивает у биллинга пускать его, или нет, какую скорость ограничить. После уже устанавливается ограничение и права доступа, и абонент может работать в интернете.

По сути в такой схеме биллинг работает с двумя связками, первая это брас, который спрашивает соответствие IP адреса с привязкой к абоненту, а вторая это микротики на сети, которые запрашивают по имени интерфейса выдачу IP адреса. По сути это то же самое, что и гнать все вланы и весь L2 в центр, только как бы разнесенная по местности. Жалко что мало кто такую схему вообще реализовывает. Она очень удобная.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Saab95

 

Такой вопрос, на AP "Default Forward" желательно отключать или нет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, x-rayd сказал:

Такой вопрос, на AP "Default Forward" желательно отключать или нет?

не сааб, но насколько помню опция к p2p отношения не имеет.  если ее снять, то между клиенты перестанут слышать друг друга напрямую ( изоляция между собой ) , за исключением тех, кто будет в wirless access list  прописан с индивидуальным перекрытием этой опции ( или через радиус )

 

 

В 03.07.2020 в 11:08, Saab95 сказал:

которые запрашивают по имени интерфейса выдачу IP адреса

как они ее запрашивают то? hotspot -- radius ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.07.2020 в 17:35, x-rayd сказал:

Такой вопрос, на AP "Default Forward" желательно отключать или нет?

Эта опция работает только при подключении клиентов без WDS, например когда клиенты это смартфоны и ноуты. И эта галочка запрещает пропуск данных между ними.

Если сеть работает с WDS, то эта галочка ни на что не влияет, если надо блокировать трафик то нужно делать средствами фильтр бриджа.

 

В 07.07.2020 в 21:11, LostSoul сказал:

как они ее запрашивают то? hotspot -- radius ?

Просто по радиусу. Если, например, схема влан на пользователя, то можно настроить выдачу IP адресов не из локального пула, а через радиус, и микротик сформирует запрос на радиус сервер, где будет указан IP адрес микротика, откуда пришел запрос, и имя интерфейса, например vlan_199, тут радиус или там биллинг смотрит по базе, кто там за абонент на этом микротике с вланом 199, и выдает ему нужный IP адрес.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Saab95

 

А можно работать на AP без WDS и будет на клиентских антеннах работать PPPoE клиент?

Или все таки посоветуете на бридже фильтровать?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 03.07.2020 в 11:08, Saab95 сказал:

EoIP туннели до каждой абонентской антенны

eoip.thumb.png.645d9e2b5a9e010a53f8fb203ec43a87.png

 

Получается в моем случае создается EoIP между двумя микротиками перед резервными антеннами PtP и перед  BRAS они бриджуются с SVLAN. 

Между двумя Mikrotik HEX пробрасываю VLAN с серой адресацией для работы этого EoIP, я правильно понял ? Тем самым мы сокращаем количество маков в бридже антенн ? 

И по MTU что выходит? QinQ 1504 это все в EoIP Overhead 42 байта 1546 и опять в транспортный VLAN 1550, так ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 часа назад, x-rayd сказал:

А можно работать на AP без WDS и будет на клиентских антеннах работать PPPoE клиент?

Или все таки посоветуете на бридже фильтровать?

Нужно работать всегда в WDS, учитывая то, что PPPoE это чистый L2 протокол, без WDS точка доступа занимается трансляцией мак адресов, это увеличивает нагрузку, уменьшает производительность, а так же может создавать разного рода неведомые глюки.

 

/interface bridge filter
add action=drop chain=forward in-bridge=bridge_5GHz in-interface=!eoip-tunnel1 out-bridge=bridge_5GHz out-interface=!eoip-tunnel1

Вот такое правило заблокирует весь трафик. Тут bridge_5GHz это бридж, куда добавляются клиенты по радио при подключении к базовой станции, eoip-tunnel1 это туннель в центр сети, где расположен PPPoE сервер, вместо него можно влан указать, если привыкли к ним. Суть в том, что IP управления и вообще всему другому нечего делать в абонентской части сети.

 

Кроме этого правила в бридж нужно добавить еще 3 по направлению в сторону выходного интерфейса - разрешить pppoe-session и pppoe-discovery, а после все остальное дропать. Тем самым вы оградите и центр от неведомых глюков.

 

4 часа назад, divxl сказал:

Получается в моем случае создается EoIP между двумя микротиками перед резервными антеннами PtP и перед  BRAS они бриджуются с SVLAN. 

Ага.

 

4 часа назад, divxl сказал:

Между двумя Mikrotik HEX пробрасываю VLAN с серой адресацией для работы этого EoIP, я правильно понял ? Тем самым мы сокращаем количество маков в бридже антенн ? 

Не так, между этими микротиками вы обеспечиваете IP транспорт, что бы с одного можно было попасть на другой, между этими IP и поднимаете EoIP туннель. Этим вы убираете мусор и уменьшаете сегменты сети для поиска неполадок, если они будут возникать.

 

4 часа назад, divxl сказал:

И по MTU что выходит? QinQ 1504 это все в EoIP Overhead 42 байта 1546 и опять в транспортный VLAN 1550, так ?

EoIP на транспорте использует 1500 байт, поэтому трафик большими пакетами начнет фрагментироваться.

 

По сути вам нужно вынести терминацию сразу на микротик после ПОНа, то есть на нем приземлить все абонентские вланы, и уже подать в центр по IP. Либо поднять на нем PPPoE сервер, и терминировать абонентов, пуская их в центр по IP. Ограничения скорости, что бы не загружать оборудование периферии, можно вынести так же в центр. Это самая лучшая и отказоустойчивая схема, полностью убирает все проблемы L2, такие как флуд, коллизии маков, кольца, LACP и т.п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

38 минут назад, Saab95 сказал:

Нужно работать всегда в WDS, учитывая то, что PPPoE это чистый L2 протокол, без WDS точка доступа занимается трансляцией мак адресов

Какой бред а.

Достаточно режим station-bridge поставить чтоб не транслировал

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.