Перейти до

Проблема высокой загрузки CPU на P3616-2TE.


amindomao

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

Доброго вечера.

Столкнулся с проблемой высокой загрузки CPU на P3616-2TE.

BDCOM(tm) P3616-2TE Software, Version 10.1.0C Build 21324
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2014-10-9 11:8:32 by SYS_21324, Image text-base: 0x10000
ROM: System Bootstrap, Version 0.4.1
System image file is "Switch.bin"
hardware version:V1.0

Конфигурация самая простая. Один шаблон на всех. Один влан на всех. Включен dhcp-snooping, опция 82. Никакого мультикаста и т.д.

Онушки все bdcom 3024, 1005, 151C.

Симптомы такие: пользователи звонят - "почти нет скорости", пинги до самой ОЛТ по несколько секунд.

ping 10.133.248.29
PING 10.133.248.29 (10.133.248.29) 56(84) bytes of data.
64 bytes from 10.133.248.29: icmp_req=1 ttl=254 time=1972 ms
64 bytes from 10.133.248.29: icmp_req=2 ttl=254 time=968 ms
64 bytes from 10.133.248.29: icmp_req=3 ttl=254 time=501 ms
64 bytes from 10.133.248.29: icmp_req=4 ttl=254 time=2860 ms
64 bytes from 10.133.248.29: icmp_req=5 ttl=254 time=1861 ms
64 bytes from 10.133.248.29: icmp_req=6 ttl=254 time=5751 ms
64 bytes from 10.133.248.29: icmp_req=7 ttl=254 time=4752 ms
64 bytes from 10.133.248.29: icmp_req=8 ttl=254 time=8573 ms
64 bytes from 10.133.248.29: icmp_req=9 ttl=254 time=7573 ms
64 bytes from 10.133.248.29: icmp_req=10 ttl=254 time=6567 ms
64 bytes from 10.133.248.29: icmp_req=11 ttl=254 time=5560 ms
64 bytes from 10.133.248.29: icmp_req=12 ttl=254 time=4561 ms
64 bytes from 10.133.248.29: icmp_req=13 ttl=254 time=3554 ms
64 bytes from 10.133.248.29: icmp_req=14 ttl=254 time=7388 ms
64 bytes from 10.133.248.29: icmp_req=15 ttl=254 time=6383 ms
64 bytes from 10.133.248.29: icmp_req=16 ttl=254 time=5376 ms
64 bytes from 10.133.248.29: icmp_req=17 ttl=254 time=4377 ms
64 bytes from 10.133.248.29: icmp_req=18 ttl=254 time=3369 ms

С трудом удается зайти в cli и посмотреть, что таки да, загрузка CPU ~100%.

Логи при этом довольно обычные:

Jun 19 18:09:24 10.133.248.29 %OLT: Interface EPON0/4:13's OAM Operational Status: Linkfault 
Jun 19 18:09:25 10.133.248.29 %EPON-ONUDEREG: ONU fcfa.f7d8.5ee6 is deregistered on EPON0/4:13. 
Jun 19 18:09:37 10.133.248.29 Alarm DYING_GASP from ONU fcfa.f7d8.b83d port EPON0/1:32 
Jun 19 18:09:37 10.133.248.29 %OLT: Interface EPON0/1:32's OAM Operational Status: Linkfault 
Jun 19 18:09:37 10.133.248.29 Alarm DYING_GASP from ONU fcfa.f7d8.b83d port EPON0/1:32 
Jun 19 18:09:37 10.133.248.29 %OLT: Interface EPON0/1:32's OAM Operational Status: Linkfault 
Jun 19 18:09:38 10.133.248.29 %EPON-ONUDEREG: ONU fcfa.f7d8.b83d is deregistered on EPON0/1:32. 
Jun 19 18:10:36 10.133.248.29 %EPON-ONUREG: ONU fcfa.f7d8.bd09 is registered on EPON0/7:10. 
Jun 19 18:10:36 10.133.248.29 %EPON-ONUAUTHEN: ONU fcfa.f7d8.bd09 is authenticated on EPON0/7:10. 
Jun 19 18:10:37 10.133.248.29 %OLT: Interface EPON0/7:10's OAM Operational Status: Operational 
Jun 19 18:10:37 10.133.248.29 %OLT: Interface EPON0/7:10's CTC OAM extension negotiated successfully! 
Jun 19 18:17:04 10.133.248.29 %EPON-ONUREG: ONU fcfa.f7d8.5ef0 is registered on EPON0/5:17. 
Jun 19 18:17:04 10.133.248.29 %EPON-ONUAUTHEN: ONU fcfa.f7d8.5ef0 is authenticated on EPON0/5:17. 
Jun 19 18:17:04 10.133.248.29 %OLT: Interface EPON0/5:17's OAM Operational Status: Operational 
Jun 19 18:17:04 10.133.248.29 %OLT: Interface EPON0/5:17's CTC OAM extension negotiated successfully! 
Jun 19 18:19:32 10.133.248.29 Alarm DYING_GASP from ONU fcfa.f7d8.5eed port EPON0/5:11 
Jun 19 18:19:32 10.133.248.29 %OLT: Interface EPON0/5:11's OAM Operational Status: Linkfault 
Jun 19 18:19:32 10.133.248.29 Alarm DYING_GASP from ONU fcfa.f7d8.5eed port EPON0/5:11 
Jun 19 18:19:32 10.133.248.29 %OLT: Interface EPON0/5:11's OAM Operational Status: Linkfault 
Jun 19 18:19:33 10.133.248.29 %EPON-ONUDEREG: ONU fcfa.f7d8.5eed is deregistered on EPON0/5:11. 

В интерфейсе есть раздел show task, но выполнить его в момент, когда загрузка CPU высокая до сих пор не получилось. Так же не нашел описания этой команды и опций в мане.

Перезагрузка помогает на какое-то время.

Может кто-то уже решал похожую задачу?

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

Вообще странно. То что 36-ая серия ОЛТов грешит сильной нагрузкой CPU, было давно известно. И то что CLI начинает тормозить, я тоже слышал пару раз. Но при этом никогда не страдали клиенты. У BDCOM-а есть незыблемое правило "Клиент прежде всего", поэтому главное, что у абонента был Интернет, а то что админ не может зайти в консоль - это ничего страшного.

 

Если серьёзно, то посмотрите, собираете ли Вы статистику по SNMP. Если да, то отключите весь сбор статистики и включайте нужные OID-ы постепенно. Бывали случаи, когда запрос определённого OID-а вешал OLT, а иногда даже приводил к ребуту железки. Некоторые админы пользуются не только SNMP скриптами для сбора данных, но и Telnet обработчиками для сбора тех данных, по которым OID-ов нет. Если такие обработчики есть, их тоже лучше на время отключить.

 

Дальше, Вы не показали шаблон! У Вас в конце есть строчка write all? Если такой команды в шаблоне нет, то ONU каждый раз при включении будет подтягивать шаблон заново, как будто она регается впервые. А применение шаблона дело процессорозатратное.

 

Ну и на последок, начиная с версии 25841 нагрузка на CPU была уменьшена.

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

Шаблон вот такой:

!
epon onu-config-template onu
 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 141
 cmd-sequence 2 epon onu port 1 loopback detect
 cmd-sequence 3 epon onu port 1 mac address-table dynamic maximum 2
!

write all в шаблон добавлю. SNMP в целях тестирования выключу.

На последнюю прошивку обновляться пробовал, но, видимо, там где появился индекс "e", там уже надо обновлять загрузчик. В итоге, пришлось откатиться до той, что есть.

Можно как-то сбросить ifindex-config чтобы начать с чистого листа? ( просто так удалить его не получается ).

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

Дальше, Вы не показали шаблон! У Вас в конце есть строчка write all? Если такой команды в шаблоне нет, то ONU каждый раз при включении будет подтягивать шаблон заново, как будто она регается впервые. А применение шаблона дело процессорозатратное.

В шаблоне такой команды нет. Но, если я, допустим, после регистрации всех ONU сделал write all, будут ли ONU каждую регистрацию и дальше подтягивать шаблон?

 

ifindex-config таки удалился обычным delete :)

Но, после этого, поймал такой же глюк, как когда-то ловил раньше.

Появился второй шаблон:

!
epon onu-config-template onu
 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 141
 cmd-sequence 2 epon onu port 1 loopback detect
!
epon onu-config-template realip_vlan1320
 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 1320
 cmd-sequence 2 epon onu port 1 loopback detect
!

Все ONU'шки привязаны к интерфейсу по макам.

!
interface EPON0/5
 description Pole_1
 epon onu-authen-method mac
 epon pre-config-template realip_vlan1320 binded-onu-llid 2
 epon pre-config-template onu binded-onu-llid 1,3-64
 epon bind-onu mac fcfa.f796.6efb 1
 epon bind-onu mac fcfa.f7d8.5eec 2
 ------------------
 ------------------
 epon bind-onu mac fcfa.f716.4156 27
 epon bind-onu mac fcfa.f716.3f0c 28
 switchport trunk vlan-allowed 141-142,1320
 switchport trunk vlan-untagged none
 switchport mode trunk
 switchport pvid 141
 no switchport protected
 epon inner-onu-switch
!

Удаляю ifindex-config, перезагружаюсь, и наблюдаю, что в такой как выше конфигурации интерфейса ONU'шка 0/5:27 попала в vlan1320, и клиент, понятное дело, не работает.

sh running-config interface ePON 0/5:27  
Building configuration...

Current configuration:
!
interface EPON0/5:27
  epon onu port 1 ctc vlan mode tag 1320
  epon onu port 1 mac address-table dynamic maximum 2
  epon onu port 1 loopback detect

В таком случае помогает только отвязать ONU'шку от интерфейса и привязать заново под тем же номером.

В чем может быть проблема?

 

С таками шаблонами как выше, после удаления ifindex-config, перезагрузки получаю в show running-config вывод вплоть до такого:

!
interface EPON0/1:26
  epon onu port 1 ctc vlan mode tag 141
  epon onu port 2 ctc shutdown
  epon onu port 3 ctc shutdown
  epon onu port 4 ctc shutdown
  epon onu port 1 mac address-table dynamic maximum 2
  epon onu port 1 loopback detect
  epon onu port 2 mac address-table dynamic maximum 2
  epon onu port 3 mac address-table dynamic maximum 2
  epon onu port 4 mac address-table dynamic maximum 2
  epon onu port 1 ctc mcst max-group-number 128
  epon onu port 2 ctc mcst max-group-number 128
  epon onu port 3 ctc mcst max-group-number 128
  epon onu port 4 ctc mcst max-group-number 128
!

Откуда это все берется?

Ссылка на сообщение
Поделиться на других сайтах
  • 4 years later...
В 24.06.2015 в 10:28, amindomao сказал:

В шаблоне такой команды нет. Но, если я, допустим, после регистрации всех ONU сделал write all, будут ли ONU каждую регистрацию и дальше подтягивать шаблон?

 

ifindex-config таки удалился обычным delete :)

Но, после этого, поймал такой же глюк, как когда-то ловил раньше.

Появился второй шаблон:


!
epon onu-config-template onu
 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 141
 cmd-sequence 2 epon onu port 1 loopback detect
!
epon onu-config-template realip_vlan1320
 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 1320
 cmd-sequence 2 epon onu port 1 loopback detect
!

Все ONU'шки привязаны к интерфейсу по макам.


!
interface EPON0/5
 description Pole_1
 epon onu-authen-method mac
 epon pre-config-template realip_vlan1320 binded-onu-llid 2
 epon pre-config-template onu binded-onu-llid 1,3-64
 epon bind-onu mac fcfa.f796.6efb 1
 epon bind-onu mac fcfa.f7d8.5eec 2
 ------------------
 ------------------
 epon bind-onu mac fcfa.f716.4156 27
 epon bind-onu mac fcfa.f716.3f0c 28
 switchport trunk vlan-allowed 141-142,1320
 switchport trunk vlan-untagged none
 switchport mode trunk
 switchport pvid 141
 no switchport protected
 epon inner-onu-switch
!

Удаляю ifindex-config, перезагружаюсь, и наблюдаю, что в такой как выше конфигурации интерфейса ONU'шка 0/5:27 попала в vlan1320, и клиент, понятное дело, не работает.


sh running-config interface ePON 0/5:27  
Building configuration...

Current configuration:
!
interface EPON0/5:27
  epon onu port 1 ctc vlan mode tag 1320
  epon onu port 1 mac address-table dynamic maximum 2
  epon onu port 1 loopback detect

В таком случае помогает только отвязать ONU'шку от интерфейса и привязать заново под тем же номером.

В чем может быть проблема?

 

С таками шаблонами как выше, после удаления ifindex-config, перезагрузки получаю в show running-config вывод вплоть до такого:


!
interface EPON0/1:26
  epon onu port 1 ctc vlan mode tag 141
  epon onu port 2 ctc shutdown
  epon onu port 3 ctc shutdown
  epon onu port 4 ctc shutdown
  epon onu port 1 mac address-table dynamic maximum 2
  epon onu port 1 loopback detect
  epon onu port 2 mac address-table dynamic maximum 2
  epon onu port 3 mac address-table dynamic maximum 2
  epon onu port 4 mac address-table dynamic maximum 2
  epon onu port 1 ctc mcst max-group-number 128
  epon onu port 2 ctc mcst max-group-number 128
  epon onu port 3 ctc mcst max-group-number 128
  epon onu port 4 ctc mcst max-group-number 128
!

Откуда это все берется?

 

 

Здравствуйте, аналогичная проблема как и у вас.Уходит проц в 100 процентов, решили как нибудь проблему?

 

 

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

Дело настолько давнее, что уже и не помнит никто.

С тех пор таких OLT появилось еще несколько и все в порядке. Думаю, что свежие стабильные прошивки решают вопрос.

Вот тут можно посмотреть: http://ic-line.ua/download

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

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

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

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

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

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

Вхід

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

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

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

×
×
  • Створити нове...