faq обучение настройка
Текущее время: Вс июл 27, 2025 23:22

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 6 ] 
Автор Сообщение
СообщениеДобавлено: Ср сен 14, 2011 14:58 
Не в сети

Зарегистрирован: Пн фев 18, 2008 18:32
Сообщений: 36
Model: DES-3526
Firmware: Build 6.00.B51
HW Rev: A4

При невыясненных обстоятельствах, запрос по dot1qVlanCurrentEgressPorts (1.3.6.1.2.1.17.7.1.4.2.1.4) на DES-3526 некоторые записи содержат STRING вместо HEX-STRING:

Код:
# snmpwalk -v2c -c stats 172.16.128.119 1.3.6.1.2.1.17.7.1.4.2.1.4
SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.1056.1 = Hex-STRING: 00 00 00 00
SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2633.20 = Hex-STRING: AD 10 91 40
SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2658.21 = Hex-STRING: 02 E0 00 40
SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2681.23 = STRING: "@
                                                     D@"
SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2705.24 = Hex-STRING: 00 00 00 40
SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2722.25 = Hex-STRING: 00 00 00 40

Изображение


При этом добавить в этот багнутый VLAN новый порт тоже нельзя. В остальные VLAN'ы, отдающиеся как HEX, порты добавляются.
Также не получается локализовать, как и по какой причине коммутатор начинает отдавать ответ не в том виде.


Возникновение бага:

  • Коммутатор живёт нормально:
    # snmpwalk -v2c -c stats 172.16.128.46 1.3.6.1.2.1.17.7.1.4.2.1.4
    SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.1055.1 = Hex-STRING: 00 00 00 00
    SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2712.20 = Hex-STRING: 5F 08 2A 40
    SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2737.21 = Hex-STRING: 00 00 00 40
  • Добавляем 14 порт в VLAN [20]
    DES-3526:admin#config vlan vlanid 20 add untagged 14
    Command: config vlan vlanid 20 add untagged 14
    Success.
  • Кирдык:
    # snmpwalk -v2c -c stats 172.16.128.46 1.3.6.1.2.1.17.7.1.4.2.1.4
    SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.1055.1 = Hex-STRING: 00 00 00 00
    SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2712.20 = STRING: "_
    *@"
    SNMPv2-SMI::mib-2.17.7.1.4.2.1.4.2737.21 = Hex-STRING: 00 00 00 40

- Если вот эту белиберду перевести в HEX, то таки да, получится нормальная маска.
Код:
$buggy = '_ *@'; // форум убивает некоторые из этих символов, поэтому код не выдаст ожидаемого результата
$clear = '';
for($i=0; $i<strlen( $buggy ); $i++) {
    $clear.= str_pad( dechex( ord( $buggy{$i} ) ), 2, "0", STR_PAD_LEFT);
}
// Теперь $clear будет содержать 5F0C2A40

- Актуальный, на момент возникновения бага, конфиг я сохранил, могу предоставить при необходимости.
- Добавлять порт в VLAN через telnet или через SNMP - неважно. Результат один и тот же.
- Много коммутаторов с этой же прошивкой работают корректно.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Ср сен 14, 2011 15:46 
Не в сети

Зарегистрирован: Пт май 05, 2006 16:52
Сообщений: 4181
Откуда: default
попробуйте ключик -Ox
и какая у вас версия snmp ?


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Ср сен 14, 2011 17:45 
Не в сети

Зарегистрирован: Пн фев 18, 2008 18:32
Сообщений: 36
terrible писал(а):
попробуйте ключик -Ox
и какая у вас версия snmp ?

Да, с -Ox ответ идёт в HEX-строках даже для "битой" записи.
Но проблема актуальна для скриптов, работающих с коммутаторами. Используются php-функции snmpwalk(), snmprealwalk() и дополнительных параметров они не принимают. В MG-Soft MIB Browser'e также нет опции по выставлению режима принудительного формата принимающей строки. Поправьте меня, если я ошибаюсь.

На сервере NET-SNMP version: 5.3.2.2
Как посмотреть в MG-Soft'e, к своему стыду, не нашёл.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Чт сен 15, 2011 08:10 
Не в сети

Зарегистрирован: Пт май 05, 2006 16:52
Сообщений: 4181
Откуда: default
Haran писал(а):
terrible писал(а):
попробуйте ключик -Ox
и какая у вас версия snmp ?

Да, с -Ox ответ идёт в HEX-строках даже для "битой" записи.
Но проблема актуальна для скриптов, работающих с коммутаторами. Используются php-функции snmpwalk(), snmprealwalk() и дополнительных параметров они не принимают. В MG-Soft MIB Browser'e также нет опции по выставлению режима принудительного формата принимающей строки. Поправьте меня, если я ошибаюсь.

На сервере NET-SNMP version: 5.3.2.2

Да, всё верно. Вылечить данную проблему я тоже достаточно упорно пытался, однако так и не нашёл вменяемого решения.
Вышел из ситуации через exec ('snmpwalk -v 2c -c ... ',$res); с последующим парсингом результатов выполнения snmpwalk. Всё это, включая парсинг запихнул в отдельную функцию, и уже её использовал вместо нормального snmpwalk, с snmpget, snmprealwalk и snmpset пришлось сделать тоже самое.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Чт сен 15, 2011 08:57 
Не в сети

Зарегистрирован: Пн фев 18, 2008 18:32
Сообщений: 36
terrible писал(а):
Да, всё верно. Вылечить данную проблему я тоже достаточно упорно пытался, однако так и не нашёл вменяемого решения.
Вышел из ситуации через exec ('snmpwalk -v 2c -c ... ',$res); с последующим парсингом результатов выполнения snmpwalk. Всё это, включая парсинг запихнул в отдельную функцию, и уже её использовал вместо нормального snmpwalk, с snmpget, snmprealwalk и snmpset пришлось сделать тоже самое.

Я работаю только с Untagged и Egress масками. И что характерно, для snmpset() этого не требуется, т.е. можно записывать snmpset ( $ip, 'private', .1.3.6.1.2.1.17.7.1.4.3.1.2.23, 'x', '02E00040', 1000000, 3 ) даже если 23 VLAN отдаёт эти странные символы. Запишется корректно. А вот с чтением я поступаю так:

Код:
<?php

// Очищаем ранее полученную маску $egress_mask от всех не-шестнадцатиричных символов
$egress = preg_replace('/[^0-9A-F]+/i', '', $egress_mask );

// Если после этой очистки $egress будет пустой или содержать менее 8 символов,
// считаем, что свитч вернул ненормальную строку вместо HEX-строки.
// -----
// Эта проверка не очень надёжная и лучше получать маски через realwalk и
// проверять тип полученных данных (STRING: или HEX-STRING:)
if( empty( $egress ) || strlen( $egress ) < 8 ) {
   $egress = normalize($egress_mask);
}


function normalize( $mask ) {

   $mask_length = strlen($mask);
   $result      = '';

   if( $mask_length > 0 ) {
      for( $i=0; $i<$mask_length; $i++ ) {

         // str_pad приводит результат конвертации символа к двухсимвольному виду
         // потому что dechex() обрезает leading zeroes
         $result.= str_pad( dechex( ord( $mask{$i} ) ), 2, "0", STR_PAD_LEFT);

      }
   }
   return $result;
}

?>


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Чт сен 15, 2011 08:59 
Не в сети

Зарегистрирован: Пн фев 18, 2008 18:32
Сообщений: 36
Таким образом, можно считать, что отдача такой маски - ошибка коммутатора. Не сказать, чтобы очень критичная, но крайне неприятная в некоторых ситуациях, когда мониторинг и управление происходит через внешние решения. Requesting a bugfix :)


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 6 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB