Jump to content
Local

tambu

Muggles
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

2 Обычный

About tambu

  • Rank
    Пролетал Мимо

Recent Profile Visitors

182 profile views
  1. tambu

    ZTE C220 и fan-модуль TFANF

    распиновка кабеля на TFANF RJ45 DB9-M 1,2 XX 3 бзел 2 4,5 син 5 (земля) 6 зел 3 7,8 XX вопрос решен
  2. tambu

    ZTE C220 и fan-модуль TFANF

    вы можете прозвонить кабель и дать распиновку?
  3. tambu

    ZTE C220 и fan-модуль TFANF

    Ну а вы сами то подключали?
  4. tambu

    ZTE C220 и fan-модуль TFANF

    Имеется в хозяйстве OLT ZTE C220 с блоком вентиляторов TFANF (Fan-F-ZS-BJ) Есть ли у кого информация, какой кабель нужен для управления вентиляторами с OLT, может есть распиновка? Заранее благодарен.
  5. tambu

    ZTE C220

    Коллеги, подскажите распиновку или маркировку шнура управления FAN-модуля для OLT ZTE C220. Может уже обсуждалось, найти инфу не удается.
  6. tambu

    Вопросы по ZTE C320

    Вставлю свои 5 копеек. На столе 2 OLT ZTE C320 1. Прошивка 1.2.5p2 2. Прошивка 1.2.5p3 На тесте 1 ONU ZTE F601 и 5 Alcatel I-010G ONU ZTE F601 работает на обоих ОЛТ, то есть как с 1.2.5p2 так и 1.2.5p3. Алкатели - не заработали на 1.2.5p3, но работают на 1.2.5p2 Гпон карты: GTGOE и GTGOG На "проблемную" OLT влил 1.2.5p2 + патчи, алкатели завелись. ZXAN#show version-running PhyLoc FileType VerType VerTag BuildTime VerLength -------------------------------------------------------------------------------- 1/1/1 GTGOE MVR V1.2.5P2 2013-09-23 01:52:53 1886523 1/1/1 GTGOE FW V1.2.5P2 2013-11-12 01:50:15 4372300 1/1/1 PM FW V1.2.5P2 2013-09-22 22:22:22 934 1/1/1 GTGOE BT V1.2.3P3 2012-10-24 14:17:00 387020 1/1/4 SMXA MVR V1.2.5P2 2013-09-23 07:34:16 13989282 1/1/4 SMXA BT V4.0.0 2013-12-18 14:28:28 524288 ZXAN#show patch-running Loc FileName PatchTag OperateTime PatchState ------------------------------------------------------------------------------- 1/1/1 gtgoev125p2t6_r2.pat 2.0 2015-02-26 19:16:42 ACTIVE 1/1/1 gtgoev125p2t6_r4.pat 2.0 2015-02-26 19:16:44 ACTIVE 1/1/4 smxav125p2t6_r1.pat 2.0 2015-02-26 19:16:02 ACTIVE 1/1/4 smxav125p2t6_r2.pat 2.0 2015-02-26 19:16:02 ACTIVE 1/1/4 smxav125p2t6_r3.pat 2.0 2015-02-26 19:16:03 ACTIVE 1/1/4 smxav125p2t6_r4.pat 2.0 2015-02-26 19:16:03 ACTIVE 1/1/4 smxav125p2t6_r5.pat 2.0 2015-02-26 19:16:03 ACTIVE Сразу хочу сказать, что с этими алкателями были проблемы на OLT ZTE C220 (проблемы с отвалами, статус LOS, LOFi и т.д.) Они нормально работают не со всеми модулями, это как выяснилось на тесте касается и ZTE C320 тоже. Модуль с которым онушки работают корректно: Vendor-Name : Hisense Vendor-Pn : LTE3680P-BH+ TxPower : 5.226(dbm) С более слабыми модулями начинаются проблемы в виде отвалов алкателей (LOS, LOFi), причем OLT может отдать LOS, но при этом терминал будет работать. Думаю эта информация кому-то пригодится. Инструкция для загрузки прошивки: http://ngoptics.com.ua/materials/reference_information/proshivka-olt-zte-c320/ Прошивка 1.2.5p2t6 + патчи: http://files.dp.ua/file?source=17122617341831447521
  7. tambu

    ZTE OLT - опрос по SNMP - уровни

    ну эта мысль то меня уже посетила, но как-то это кривовато получается...
  8. tambu

    ZTE OLT - опрос по SNMP - уровни

    помогите разобраться. SNMPv2-SMI::enterprises.3902.1015.1010.1.1.1.1.1.4.811089920 = Hex-STRING: C4 C9 EC 00 64 50 На основе чего формируется идентификатор ону: 811089920 ? Что-то ничего в голову дельного не приходит.
  9. tambu

    ZTE C220, локалка через ONU, DHCP

    Проблема решена и не связана с работой ПОН сети. Тему можно закрыть.
  10. tambu

    ZTE C220, локалка через ONU, DHCP

    лимита нет. Я даже специально указывал на ону mac limit-num eth_0/1 no-limit, но это видимо дефолтный параметр, т.к. в конфиге общем этого пункта я не увидел Но я думаю, если бы маки не пролазили, то я вообще не увидел бы даже DHCPDISCOVER
  11. имеется OLT ZTE C220 PhyLoc FileType VerType VerTag BuildTime VerLength -------------------------------------------------------------------------------- 0/0/8 GCSAS MVR V1.2.3P1 2013-02-28 03:22:00 7962100 0/0/8 GCSAS BT V1.2.3 2012-10-16 18:01:28 432832 0/0/11 EPFCB MVR V1.2.3P1 2013-02-28 05:04:28 1903865 0/0/11 EPFCB BT V1.2.3 2012-10-16 17:23:15 333344 0/0/14 EIG MVR V1.2.3P1 2013-02-28 04:26:36 609714 0/0/14 EIG BT V1.2.3 2012-10-16 17:12:04 325232 решили использовать ONU для доступа в Интернет небольшой локальной сети. Для этого была подключена NGPON ONU NGN-02E. После включения локалки через ONU всё заработало, почти. Некоторые абоненты получают адреса через DHCP, а некоторые нет. В логах DHCP сервера наблюдаем примерно следующую картину: Dec 31 10:07:02 mega dhcpd: DHCPDISCOVER from 54:04:a6:5d:3c:9d via 10.13.20.1 Dec 31 10:07:02 mega dhcpd: DHCPOFFER on 10.13.20.110 to 54:04:a6:5d:3c:9d via 10.13.20.1 и так до бесконечности. То есть запрос на получение параметров от абонентского устройства есть, а ответ он уже не получает. Это подтверждает факт просмотра трафика снифером. Подключившись "до ПОН сети", параметры по dhcp сразу же пришли. Если подключиться "за ПОН сетью", имеем то, что выше. При этом некоторые абоненты таки получают сетевые настройки. Что примечательно, есть абоненты, работающие через персональные ONU, то есть в классической схеме и там нет никаких проблем с DHCP. Единственное логическое объяснение всему этому поведению я вижу в том, что где-то подрезается трафик. Такие же ONU у нас используются в связке с OLT BDCOM P3310 в такой же схеме (локалка включена через ONU) и всё работает без каких-либо нареканий. Конфиги: interface epon-olt_0/11/1 p2p mode group onu 64 type NGN-02E mac c4c9.ec00.6450 ip-cfg static loopback-detection enable interface epon-onu_0/11/1:64 admin enable ems-autocfg-request disable encrypt direction downstream enable vport 1 switchport mode hybrid vport 1 switchport vlan 11-12,15,100-101,200 tag vport 1 switchport vlan 500 tag vport 1 pon-onu-mng epon-onu_0/11/1:64 auto-config compatibility enable mode CTC vlan port eth_0/1 mode trunk vlan-list 11,12,15,100,101,200,500 interface-loopdetect eth_0/1 activate На ONU пробовал менять режим работы с вланами на hybrid, trunk, transparent. Что можно предпринять в данной ситуации? Возможно кто-то с подобной проблемой сталкивался. Заранее спасибо за ответ.
  12. tambu

    P3310 SNMP CPU80%

    у нас от BDCOM всего одна ОЛТ. В моем случае у всех абонентов всё работало штатно, но нагрузка на процессор была повышенная. Вобщем спустя час как я написал тут на форуме, чудным образом нагрузка CPU упала до 10-15% как и была изначально. EPON#show cpu CPU utilization for one second: 11%; one minute: 10%; five minutes: 9% EPON#show task | include SNMP SNMP 80867e50 8490b430 128 809aa344 8490af50 848f26e0 860001 PD 4.63 5121380
  13. tambu

    P3310 SNMP CPU80%

    имеется ОЛТ P3310 BDCOM(tm) P3310B Software, Version 10.1.0B Build 29333 Copyright by Shanghai Baud Data Communication CO. LTD. Compiled: 2015-7-21 17:47:52 by SYS_29333, Image text-base: 0x80008000 ROM: System Bootstrap, Version 0.3.4, Serial num:00313004721 System image file is "Switch.bin" (RISC) processor with 131072K bytes of memory, 8192K bytes of flash Base ethernet MAC Address: fc:fa:f7:3a:4a:66 snmp info: product_ID:228 system_ID:1.3.6.1.4.1.3320.1.228.0 случилась у нас петля c абонентской ону NGPON, нашли, устранили. В момент возникновения петли загрузка проца начала колебаться от 65% до 80% делаю show task CPU utilization for one second: 75%; one minute: 72%; five minutes: 71% P - Pending D - Delay R - Ready S - Suspend E - Estimated NAME ENTRY TID PRI PC Stk Ptr SP lmt ERR.NO ST CPU invoked ------------------------------------------------------------------------------- tLog 8099e244 87326200 000 809b4e88 873260e8 87324e80 000000 P 0.00E 0 IDLE 8037e450 87324c60 255 8037e458 87324c38 87324870 000000 R 31.44E 159387 RCVR 8037f048 873150c0 060 809b4e88 87314d80 87305370 000000 P 0.00 0 ATDT 8037f12c 872fd130 180 809b4e88 872fcdd8 872f53e0 000000 P 0.00 0 bcmD 8070b7d0 872f4ee0 128 8094e47c 872f4c20 872f1190 000000 P 0.00 0 bcmL 80741ae4 8723fd20 128 8094e47c 8723f8f8 8723bfd0 3d0004 PD 6.18 4817 bcmC 80808688 8721d190 128 8094e47c 8721cea0 87219440 3d0004 PD 0.64 2359 bcmT 809bf134 872166e0 128 8094e47c 87216418 87212990 000000 R 1.61 133642 bcmX 809bd3a0 872124d0 128 8094e47c 872121f0 8720e780 000000 P 0.00 0 bcmL 8052889c 869fb460 128 8094e47c 869fb120 869f7710 3d0004 PD 0.51 38835 bcmR 804ad3b4 869da730 200 8094e47c 869da460 869d69e0 3d0004 PD 1.05 11232 root 80010750 8677e520 030 809af10c 8677e498 8677a530 000000 S 0.00E 0 DM 802e3dec 8623ebd0 128 809b4e88 8623e890 86236e80 000000 P 0.00 0 OIR 802f0c08 8622e940 060 809b4e88 8622df78 8621ebf0 000000 P 0.00 0 WARN 802cc708 8787f7b0 128 809b0594 8787f718 8787d7c0 000000 D 0.00E 90 FILT 802ae464 86080270 128 809b0594 8607ff90 86078520 3d0002 D 0.05 9378 L2T3 802973b8 86078060 060 8094e47c 86077d90 86068310 000000 P 0.01 705 L2T2 802973b8 86067e50 090 8094e47c 86067b80 86058100 000000 P 0.00 0 L2T1 802973b8 86057c40 128 8094e47c 86057970 86047ef0 000000 P 0.00 0 L2T0 802973b8 86047a30 180 8094e47c 86047760 86037ce0 000000 R 5.21 162527 TSTP 808d32b4 860069c0 128 809b4e88 86006660 86002c70 000000 P 0.12 2131 Ttrk 802b2198 85ffaa30 128 809b4e88 85ffa6f8 85ff6ce0 000000 P 0.00 0 Tdtx 801462bc 85feeaa0 128 809b4e88 85fee758 85fe6d50 000000 P 0.00 0 GARP 80164a60 85fdde60 128 809b4e88 85fddb28 85fda110 000000 P 0.00 0 GVRP 80166cc0 85fae3d0 128 809b4e88 85fae098 85faa680 000000 P 0.00 0 EAPS 80151f64 85fa0fb0 060 809b4e88 85fa0c78 85f9d260 000000 P 0.00 468 IPFA 80336134 85f9cda0 128 809b4e88 85f9ca40 85f99050 000000 P 0.02 2345 IPSL 80336004 85f98b90 128 809b4e88 85f98830 85f94e40 000000 P 0.02 937 ARPT 80325ea0 85f94980 128 8094e47c 85f94698 85f84c30 3d0004 PD 0.03 2290 MYIP 8031ab38 85f546f0 128 809b4e88 85f54348 85f449a0 3d0004 PD 0.00 8 BCMP 8015c4c0 85f42f10 128 809b4e88 85f42b80 85f3f1c0 000000 P 0.00 94 DHSN 801359e0 85e530e0 128 809b4e88 85e52d80 85d53390 000000 P 0.00 10 MLDS 80404a58 85cd23c0 128 809b4e88 85cd2088 85cce670 000000 P 0.00 470 SLOG 8038e2ac 859b6f70 128 809b4e88 859b6bb8 859b3220 000000 P 0.00 34 STRL 8038e874 859b2d60 128 809b4e88 859b2a20 859af010 000000 P 0.00 6 _USM 80925364 859a6250 128 809b4e88 859a5f18 859a2500 000000 P 0.00 0 TELD 8090a1f0 859a2040 128 809b4e88 859a1ca0 8599faf0 3d0002 P 0.00 181 RADU 80441278 859975b0 128 809b4e88 85997278 85995060 000000 P 0.00 0 TAC+ 80902128 85994b60 128 809b4e88 85994820 85992610 000000 P 0.00 0 TMRG 808b2bb0 859920d0 128 8094e47c 85991de8 8598e380 3d0004 PD 0.00 0 IMST 80216c64 8493eba0 060 809b4e88 8493e848 8491ee50 3d0004 PD 1.05 21446 IMRX 80217034 8491c910 180 809b4e88 8491c5b8 84914bc0 000000 P 0.00 0 tLed 80010348 84914700 130 809b0594 84914678 84913710 000000 D 0.00E 939 SNMP 80867e50 8490b430 128 809aa344 8490af50 848f26e0 860001 PD 44.62 154777 OLT 803ca154 848d7d20 128 809b4e88 848d7628 848cffd0 000000 P 0.00 37 MCST 803b5c34 846483d0 128 809b4e88 84648098 84644680 000000 P 0.00 471 HONU 80056908 8461d640 180 809b4e88 8461d2e0 846198f0 000000 P 0.00 50 LCHG 8007065c 84619430 128 809b0594 84619180 846156e0 000000 D 0.00 468 SNMK 8086c460 842f7240 128 809b0594 842f6f98 842f34f0 000000 D 0.05 469 SNMT 8086c4c4 842f3030 128 809b0594 842f2d88 842ef2e0 000000 D 0.00 15 THAL 8001b040 848f0000 128 809b0594 848efbe8 848ec2b0 000000 D 0.20 12878 HTTP 8016a040 8428edb0 128 809b4e88 8428ea78 8425d060 000000 P 0.00 0 SNTP 808aae3c 848eb6f0 128 809b4e88 848eb2d8 848e99a0 000000 P 0.00 18 RMON 80368b34 848e7420 128 809b4e88 848e70e8 848e36d0 000000 P 0.00 0 TFTP 809167a8 848e3210 128 809b4e88 848e2a40 848df4c0 000000 P 0.00 0 TFTS 80916f64 848df000 128 809b4e88 848de7e0 848db2b0 000000 P 0.00 0 TMIB 8091582c 84248a20 128 809b4e88 842486e0 84246cd0 000000 P 0.00 0 SSHD 808b6280 84226790 128 809b4e88 84226458 8421ca40 000000 P 0.00 0 _NTM 8037597c 8421c580 055 809b0594 8421c2c8 84214830 000000 R 0.35 46887 tty0 8039675c 84214370 128 809b0594 84213bf8 84204620 3d0002 D 0.11 8784 CONS 802f869c 841df080 045 809b0594 841dedb8 841db330 000000 D 0.02 2930 CHCK 8037f454 841d30f0 180 809b0594 841d2df8 841d13a0 000000 D 0.05 72 HTTD 801b9164 83c051c0 128 809aa344 83c04ae0 83b6f470 860001 PD 0.00 233 Tty0 8039675c 83b15b50 128 8037ff3c 80bace28 83b05e00 3d0002 R 0.06 1665 INTR 00000000 81444cf0 000 00000000 00000000 00000000 000000 13.12E 46888 видно, что процесс SNMP загружает проц почти на 50%. Ребут головы, блокировка епон портов ничего не дала. Прошивка самая новая. Честно говоря, что с этим делать - не совсем ясно. Всё остальное оборудование работает штатно, никаких аномалий не увидел. Пробовал различные манипуляции с настройками снмп, вплоть до отключения какого-либо опроса ОЛТ через snmp. Возможно кто-то с подобной проблемой сталкивался, прошу совета. Спасибо
×