Перейти до

BDCOM ONU user mac oid snmp


Kycherr

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

Все значительно легче, конвертировать бин в хекс не нужно, оиды результат отдают в хексе. Дома вечером буду - покажу наработки

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

Все значительно легче, конвертировать бин в хекс не нужно, оиды результат отдают в хексе. Дома вечером буду - покажу наработки

 

Ок.. Цікавить Влани. І функції oper та admin status до портів

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

Получение таблицы маков на определенном интерфейсе !!С НОМЕРАМИ ВЛАНОВ (работает достаточно быстро, с онушки с 120 маками за ней инфу за 3 секунды снял)



<?php

// ---------- Get FDB By SNMP
function GetFdb ($ip, $ro, $iface) {
$session =  new SNMP(SNMP::VERSION_1, $ip, $ro);
$session->oid_increasing_check = FALSE;
$session->oid_output_format = SNMP_OID_OUTPUT_NUMERIC;
$fdb = $session->walk("1.3.6.1.4.1.3320.152.1.1.3.$iface");
$session->close();
return $fdb;
}

// END ----------



$ip = "192.168.1.10";
$ro = "public";
$iface = 52;
$fdb = GetFdb($ip, $ro, $iface);
foreach ($fdb as $oid => $fdb_mac) {
$fdb_vlan = end(explode("1.3.6.1.4.1.3320.152.1.1.3.$iface.", $oid));
$fdb_vlan = explode('.', $fdb_vlan);
$fdb_vlan = $fdb_vlan[0];
$fdb_mac = trim(end(explode('STRING: ', $fdb_mac)));
$fdb_mac = str_replace(' ',':',$fdb_mac);

echo $fdb_vlan;
echo " - ";
echo $fdb_mac;
echo "\r\n";
//echo "<br/>";
}
?>

Также некоторые важные функции:



// ----------Get PVID on port ----------

function GetPVID($ip, $ro, $iface, $port) {
$pvid = snmp2_get($ip, $ro, "1.3.6.1.4.1.3320.101.12.1.1.3.$iface.$port");
$pvid = end(explode('INTEGER: ', $pvid));
return $pvid;
}


// ---------- Get Port Mode (trunk, access, etc.) ----------

function GetPortMode($ip, $ro, $iface, $port) {
$port_mode = snmp2_get($ip, $ro, "1.3.6.1.4.1.3320.101.12.1.1.18.$iface.$port");
$port_mode = end(explode('INTEGER: ', $port_mode));
return $port_mode;
}

// END ----------



// ----------Get num ports on ONU ----------

function GetNumPorts($ip, $ro, $iface) {

$Array_num_ports = snmprealwalk($ip, $ro, "1.3.6.1.4.1.3320.101.12.1.1.8.$iface");
if(count($Array_num_ports)>0)
 foreach($Array_num_ports as $oid => $result)
 {
   $num_ports = $oid;
 }
$num_ports = end(explode("12.1.1.8.$iface.", $num_ports));
return $num_ports;
}

// END ----------


// ----------Get copper port state on ONU ----------

function OnuCopperPortState($ip, $ro, $iface, $port) {
$port_state = snmp2_get($ip, $ro, "1.3.6.1.4.1.3320.101.12.1.1.7.$iface.$port");
$port_state = end(explode('INTEGER: ', $port_state));
// 1 - Enabled, 2 - Disabled
return $port_state;
}

// END ----------


// ----------Get copper link state on ONU ----------

function OnuCopperLinkState($ip, $ro, $iface, $port) {
$link_state = snmp2_get($ip, $ro, "1.3.6.1.4.1.3320.101.12.1.1.8.$iface.$port");
$link_state = end(explode('INTEGER: ', $link_state));
// 1 - Link down, 2 - Link up
return $link_state;
}

// END ----------



Відредаговано dan_aspire
Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...
  • 1 year later...

 onuIpAddressMode 1.3.6.1.4.1.3320.101.10.1.1.52

 onuStaticIpAddress 1.3.6.1.4.1.3320.101.10.1.1.53

 onuStaticIpMask 1.3.6.1.4.1.3320.101.10.1.1.54

 onuStaticIpGateway 1.3.6.1.4.1.3320.101.10.1.1.55

 

http://www.oidview.com/mibs/3320/BDCOM-EPON-ONU.html

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

some onus does not work with command for setting ip like:

 

epon onu ip address static xx.xx.xx.xx ..... does not work and you will not have ping to onu.

You must use:

epon onu ctc ip address static xx.xx.xx.xx.....

The question is how to get the IP from snmp if we use ctc command.

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

I am doing small web application for testing. I need onu ip so i can ping with size and pattern just

for diagnostics. Other way is to take it with telnet + parsing but snmp is way better.

Also I need onu port speed oid (i can see client device 10/100/1000 mbit/s speed).

If someone can help about it ?

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

Всім доброго дня.

Чи може хтось поділитися МІВами  opIfRxPowerCurr зі сторони ОЛТа для моделей BDCOM P3608-2TE, BDCOM P3608B, BDCOM P3616-2TE, BDCOM P3600-16E?

 

Для моделей BDCOM 3310B та BDCOM 3310C маю:

.1.3.6.1.4.1.3320.9.183.1.1.5.$iface     рівень RX на ОЛТі 3310B
.1.3.6.1.4.1.3320.101.108.1.3.$iface     рівень RX на ОЛТі 3310С

Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, danmany сказав:

Всім доброго дня.

Чи може хтось поділитися МІВами  opIfRxPowerCurr зі сторони ОЛТа для моделей BDCOM P3608-2TE, BDCOM P3608B, BDCOM P3616-2TE, BDCOM P3600-16E?

 

Для моделей BDCOM 3310B та BDCOM 3310C маю:

.1.3.6.1.4.1.3320.9.183.1.1.5.$iface     рівень RX на ОЛТі 3310B
.1.3.6.1.4.1.3320.101.108.1.3.$iface     рівень RX на ОЛТі 3310С

ONU RxPower - 1.3.6.1.4.1.3320.101.108.1.3.  *0.1

ONU TxPower - 1.3.6.1.4.1.3320.101.10.5.1.5.  *0.1

ONU Transmitted power: - 1.3.6.1.4.1.3320.101.10.5.1.6.   /10

Відредаговано CoUL
Ссылка на сообщение
Поделиться на других сайтах
12 часов назад, CoUL сказав:

ONU RxPower - 1.3.6.1.4.1.3320.101.108.1.3.  *0.1

ONU TxPower - 1.3.6.1.4.1.3320.101.10.5.1.5.  *0.1

ONU Transmitted power: - 1.3.6.1.4.1.3320.101.10.5.1.6.   /10

Дякую, працює.

  • Like 1
Ссылка на сообщение
Поделиться на других сайтах
В 29.12.2016 в 17:23, sanitariu сказал:

Copper port speed which is connected to a client device (router or computer)

Не удалось у кого-то найти скорость медного порта на ону?

 

    $onuUniIfSpeedoid    = '.1.3.6.1.4.1.3320.101.12.1.1.10';

позволяет как я понял управлять скоростью, но не позволяет считать текущую.

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

BDCOM EPON
iso.3.6.1.4.1.3320.101.12.1.1.13.{логічний номер включення}.1 - для отримання поточної швидкості езер порта на ону.
100000 - 100мбіт
1000000 - гіг

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

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

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

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

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

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

Вхід

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

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

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

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

    • Від tadesky
      Продам б/в BDCOM P3616-2TE OLT . 

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

      За потреби можна комплектувати SFP Picotel EPON SFP PX++ = 600 грн/шт. 
       
      Пишіть в особисті. 
       
    • Від g-shock
      Куплю не рабочие (бракованные) ZTE ONU F601, интересует штук 20, по разумной цене.
    • Від Prodazha
      В продажі 100 шт ону.
      комплектація ону + блок живлення
      ціна 350 грн за опт.



    • Від 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 - это совпадение. Но есть подозрения, что связь все таки есть. И проблема довольно странная, ранее не встречал.
      Ещё стоит сказать, что это далеко уже не первый домовой свич, подключенный по такой схеме. Но проблема пока вылезла именно тут. В общем, хотелось бы услышать мнения опытных ребят, с чем конкретно связаны проблемы.
      Прошу не судить сильно по части некоторых решений и высказываний. Я пока не имею солидного опыта и большого багажа знаний. Но буду благодарен за помощь
×
×
  • Створити нове...