Перейти до

BDCOM pon не пропускає CAPsMAN


Axel K

Рекомендованные сообщения

Вітаю!

 

налаштування capsman

/caps-man channel
add band=2ghz-b/g/n extension-channel=disabled frequency=2412,2437,2462 name=channel1
add band=5ghz-a/n/ac extension-channel=disabled frequency=5180 name=channel5 skip-dfs-channels=yes tx-power=40
/caps-man datapath
add bridge=Main client-to-client-forwarding=yes local-forwarding=no name=datapath1
/caps-man configuration
add channel=channel1 datapath=datapath1 max-sta-count=20 mode=ap name=cfg1 rx-chains=0,1,2,3 ssid=25 tx-chains=0,1,2,3
add channel=channel5 datapath=datapath1 hide-ssid=no mode=ap name=cfg5 rx-chains=0,1,2,3 ssid=25 tx-chains=0,1,2,3
/caps-man access-list
add action=reject allow-signal-out-of-range=10s disabled=no signal-range=-120..-85 ssid-regexp=""
/caps-man manager
set enabled=yes
/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=ac master-configuration=cfg5 name-format=prefix-identity
add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=cfg1 name-format=prefix-identity

проблема у низькій швидкості у клієнта

якщо включити local-forwarding=yes, клієнт підключається, але не отримує ір.

 

розумію, що на bdcom не вистачає налаштувань, прошу допомоги.

Відредаговано Axel K
Ссылка на сообщение
Поделиться на других сайтах
Switch#show mac address-table interface ePON 0/1:2
        Mac Address Table (Total 18)
------------------------------------------

Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
125     5291.ca3c.c38c    STATIC     epon0/1:2
1       6c68.a42b.48e1    DYNAMIC    epon0/1:2
10      48a9.8ae0.1389    DYNAMIC    epon0/1:2
125     3279.f997.e3c6    STATIC     epon0/1:2
125     7e2c.3f15.e5b9    STATIC     epon0/1:2
11      0023.6395.6713    DYNAMIC    epon0/1:2
125     62ba.497d.9bda    STATIC     epon0/1:2
11      48a9.8ae0.1389    DYNAMIC    epon0/1:2
125     6a4c.1cbf.b7e2    STATIC     epon0/1:2
125     4209.aa1e.1784    STATIC     epon0/1:2
125     e699.95ef.a4f7    STATIC     epon0/1:2
11      0023.6395.6701    DYNAMIC    epon0/1:2
11      0023.6395.6712    DYNAMIC    epon0/1:2
125     466c.d8ef.13d8    STATIC     epon0/1:2
125     62ad.132d.89d3    STATIC     epon0/1:2
125     aa8d.b381.1420    STATIC     epon0/1:2
125     70bb.e991.94c9    DYNAMIC    epon0/1:2
125     48a9.8ae0.1389    DYNAMIC    epon0/1:2

Макі, які у 125 влані з типом Static, ір можуть отримати, можуть ні.

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

Рішення, яке б підійшло з налаштуваннями BDCOM, не знайшов, тому використав "костиль".

На мікротіках підняв тунелі і трафік користувачів загнав в тунель

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

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від valexa
      Вітаю, шановне панство!
      Стикнувся з проблемою блокування наших зовнішніх IP-адрес популярними сервісами (зокрема OLX, який працює через CloudFront). Отримую помилку «403 Forbidden: Request blocked». Причина очевидна — хтось із локальної мережі флудить, через що системи захисту сайтів бачать аномальну активність і «банять» всю вихідну адресу.
      Вхідні дані:
      Мережа з декількома зовнішніми IP.
      Вихід в інет розподіляється динамічно (P2C / Load Balancing).
      Велика кількість внутрішніх («сірих») користувачів.

      Що вже пробували:
      Створення правил обмеження кількості одночасних з'єднань (conn-limit) з однієї внутрішньої IP-адреси. Результат незадовільний: при жорстких лімітах починаються проблеми з роботою IP-телефонії, онлайн-ігор та інших стійких до розривів сервісів, а при м'яких — блокування зовнішніх IP продовжується.
      Питання до спільноти:
      Як ефективно вирахувати «шкідника» в реальному часі, якщо стандартні ліміти не допомагають?
      Чи існують методи динамічного обмеження саме за частотою запитів (PPS/Rate-limit), які не «дропають» легітимні з'єднання телефонії?
      Можливо, є сенс дивитися в бік NetFlow/SNMP для аналізу трафіку, і чим це краще збирати на практиці?

      Буду вдячний за будь-які поради щодо налаштування та виявлення джерела флуду. Дякую!
    • Від tadesky
      Продам б/в BDCOM P3616-2TE OLT . 

      Повністю робочий, без нюансів, знятий після модерну.  Комплектований резервним БЖ. 
      Оціночна вартість 40 тис. грн.

      За потреби можна комплектувати SFP Picotel EPON SFP PX++ = 600 грн/шт. 
       
      Пишіть в особисті. 
       
    • Від forella
      Имеется такая ситуация.
      топология: абонент---ону---bdcom p3310---cisco 4948--- далее 2 пути, 99% идут на линуксовый шлюз, оставшиеся(избранные, назовем их так) 1% на микротик по оттдельному vlan.
      олт 13шт. каждая олт оттдельным портом на 4948 подключена. все аналогично работают как описано выше.
      наблюдается вот такая ситуация на циско:
       
      *Apr 20 03:17:28.873: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:32.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 *Apr 20 03:17:33.489: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/11 to port Gi1/5 *Apr 20 03:17:34.273: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/10 to port Gi1/11 *Apr 20 03:17:34.277: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/11 to port Gi1/10 *Apr 20 03:17:43.769: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/7 to port Gi1/11 *Apr 20 03:17:43.973: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:47.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 vlan 321 это те самые избранные, и по логам видно что связующее звено 11 порт, за ней олт. (порты 5,7,10 так же олт)
      что было сделано:
      на олт за 11 портом выключены абоненты имеющие отношение к влан 321 - флапы продолжились.
      выключены пон порты по очереди и все сразу - флапы продолжились.
      выключен порт 11 на циско - флапы прекратились.
      включен порт, но удален влан 321 на циско - флапы прекратились.
      собственно вопрос - это глюк прошивки олт, что при выключеных пон портах флапы продолжаются, либо не там ищу причину?
       
    • Від Emanon
      Приветствую форумчан. Есть проблема и суть ее такова:
      В топологии одной провайдерской сети сделали определенные изменения. Некоторые access-коммутаторы (edge core ec3528M) в домах, решили подключить по gpon-у. Тоесть, если ранее все это дело шло ветками от одного свича к другому, то теперь ответственность, за их агрегацию , частично лягла на olt bdcom gp3600.
      Если схематически : свич -> onu -> olt -> свич агрегации -> bras (accel ipoe) ну и далее уже в ядро. Onu кстати - bdcom gp1701. Вопросы о том, зачем все это и насколько целесообразно - можно оставить для другого разговора.
      А пока что хотелось бы в кое чем разобраться. Недавно, начали идти заявки от НЕКОТОРЫХ абонентов одного и того же дома с одного и того же узла с жалобой на нестабильный интернет. Это через неделю-две после изменения топологии и соответственно, переключения их коммутатора к pon-сети.
      Техник, осмотрев происходящее, заявлял что рандомно, раз в минуту-две, начинаются потери пакетов. Проверял целостность линий,  подключался напрямую ноутом. Результат один и тот же. Линк между свичом и роутером не падает. Не падает линк и между onu и свичом. Проблем с режимами (half duplex, full duplex) портов тоже не было. Если уже далеко зайти, сам домовой свич, olt, коммутатор агрегации, без проблем пингуются (правда находятся в отдельном управляющем vlan). Очевидные проблемы, вроде роста cpu и утечек памяти, в их работе не наблюдались. В логах все чисто. В мониторинге видно, что канал не нагружен (download и upload не превышают 250 Мбит как по pon так и выше, нет аномальных значений pps как для broadcast, так для unicast и multicast). Да и для остальных пользователей, кроме проблемных, не было вопросов. У всех вроде работает, кроме некоторых ребят с конкретного узла. Трасса упорно показывает, что проблемный участок как раз между роутером и bras. Логи на роутерах тоже ничего вразумительного не пишут. При этом, стоило подключить вместо абонентского tp link archer ax12, c64 или keenetic titan, какой то древний роутер, вроде dlink dir300 или tp link tl-wr841n, как все работало стабильно, без потерь. 
      Со стороны bras сессии не рвутся, но через tcpdump действительно обнаруживается, что при пинге ( как 32 байта, так и побольше) часть icmp пакетов от проблемных абонентов не доходит. 
      Менялись mac  абонентских устройств, пытались найти mac flapping, менялся mac aging, менялся абонентский ip. Без результатов. Mac таблица за onu не забивается кстати, там не более 8 устройств. Проверялись оптические уровни. Конечно, onu rx -24 и olt rx -26 - это уже почти на грани. 
      И наверное это отчасти играет роль. Но нюанс с тем, что происходит при замене роутеров, заставляет задуматься. Возможно то, что такое вылезло именно после перехода на gpon - это совпадение. Но есть подозрения, что связь все таки есть. И проблема довольно странная, ранее не встречал.
      Ещё стоит сказать, что это далеко уже не первый домовой свич, подключенный по такой схеме. Но проблема пока вылезла именно тут. В общем, хотелось бы услышать мнения опытных ребят, с чем конкретно связаны проблемы.
      Прошу не судить сильно по части некоторых решений и высказываний. Я пока не имею солидного опыта и большого багажа знаний. Но буду благодарен за помощь
    • Від ubiquiti2024
      Продам Точку доступа MikroTik RB912R-2nD-LTm&R11e-LTE
      Купив не підійшла.
      Стан новий.
      ціна 4100 грн
×
×
  • Створити нове...