[AlKov]

При опросе arp таблицы по snmp почему-то не вижу некоторые МАС.

В arp -an МАС присутствует.

[root@router /]# arp -an | grep -i 70:5A:B6:1D:85:8B
? (10.0.212.197) at 70:5a:b6:1d:85:8b [ether] on vlan102

[root@router /]# snmpwalk -v2c -Ox -c 'public' localhost RFC1213-MIB::atPhysAddress | grep '70 5A'
RFC1213-MIB::atPhysAddress.16.1.10.0.199.11 = Hex-STRING: 70 5A B6 D8 4E 79
RFC1213-MIB::atPhysAddress.16.1.10.0.212.183 = Hex-STRING: 70 5A B6 D8 15 8A

В чем может быть проблема? С количеством записей в арп таблице это никак не может быть связано?

arp -an | wc -l
  1757

Хотя, вроде бы запас есть

net.ipv4.neigh.default.gc_thresh1 = 2048
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192

И в dmesg тоже ничего о переполнении арп таблицы нет..

Или я не тО смотрю?

Изменено 20 марта, 2012 пользователем AlKov

[Giga-Byte]

а он успел туда попасть? всмысле во внутреннюю память демона snmp

[s.lobanov]

Надо добавить -Cc в опции snmpwalk

[AlKov]

а он успел туда попасть? всмысле во внутреннюю память демона snmp

Должен был успеть. Обычно для этого было достаточно минуты, а тут и через час пусто.

Кабы знать, где проверить..

[AlKov]

Надо добавить -Cc в опции snmpwalk

Не помогает. Дело в том, что до сегодняшнего дня все работало исправно и не один год!

Что могло глюкнуть и где причина, ума не приложу.. :(

snmpd ребутал, не помогло.

Опаньки, нашлось!

Mar 20 23:05:16 router snmpd[864]:Error allocating more space for arpcache.  Cache will continue to be limited to 1024 entries

Вот только чем лечить, пока неизвестно.. Гугль кроме "вырезки" из исходников snmpd и то, что это known issue ничего не находит..

Изменено 20 марта, 2012 пользователем AlKov

[Ivan_83]

Поправьте исходники и пересобирите, делов то.

[AlKov]

Поправьте исходники и пересобирите, делов то.

И то верно! Чего это я?! Дело за малым - выучить С++ и вперед. ;)

Ну а если серъезно - кроме секса с исходниками, другое решение существует?

Изменено 21 марта, 2012 пользователем AlKov

[Ivan_83]

Достаточно с помощью грепа найти в исходниках: "Cache will continue to be limited to", потом поискать рядом (чуть выше) слово malloc, в котором одним из аргументов будет, скорее всего КОНСТАНТА НАПИСАННАЯ БОЛЬШИМИ БУКВАМИ, потом ещё раз грепнуть её и убедится что там 1024, дальше поменять циферку и пересобрать.

Знания английского языка будет достаточно.

[s.lobanov]

Ivan_83

Да это всё ерунда, можно и за копейки фрилансера найти, главное чтоб патч приняли, а то иначе смысла нет, ну сами ж понимаете.

[Ivan_83]

Я думал автору прям щас надо :)

А так да, можно и на мозги разрабам покапать.

[AlKov]

Я думал автору прям щас надо :)

Вообщем-то, да, надо было еще вчера.. Проблема создалась довольно ощутимая.

Пока сделал костыль на php (без snmp).

Можно конечно попытаться поковырять исходники, только вот одна незадача - snmp-utils ставил yum-ом, посему исходники отсутствуют.

Где взять именно те исходники, что установлено (NET-SNMP version: 5.3.2.2)?

[s.lobanov]

AlKov

Подключить репозиторий с src. Посмотрите конфиг yum, обычно он просто выключен

[AlKov]

AlKov

Подключить репозиторий с src. Посмотрите конфиг yum, обычно он просто выключен

И?

1. не знаю, как это (подключить src в yum) сделать

2. что делать после подключения src репозитория?

3. где найти нужные параметры ./configure ?

3а. или после правки исходников ставить обычным путем (собирать rpm)? Если так, то где взять патчи для моей ОС (CentOS 5)?

 

P.S. Скачал с sourceforge исходники другой версии, глянул "внутрь".. Это оно?

  * Get rid of the header line
    */
   fgets(line, sizeof(line), in);

   i = 0;
   while (fgets(line, sizeof(line), in)) {
       u_long          tmp_a;
       int             tmp_flags;
       if (i >= arptab_curr_max_size) {
           struct arptab  *newtab = (struct arptab *)
               realloc(at, (sizeof(struct arptab) *
                            (arptab_curr_max_size + ARP_CACHE_INCR)));
           if (newtab == at) {
               snmp_log(LOG_ERR,
                        "Error allocating more space for arpcache.  "
                        "Cache will continue to be limited to %d entries",
                        arptab_curr_max_size);
               break;
           } else {
               arptab_curr_max_size += ARP_CACHE_INCR;
               at = newtab;
           }
       }

и править, как я понимаю, здесь

/*
* at used to be allocated every time we needed to look at the arp cache.
* This cause us to parse /proc/net/arp twice for each request and didn't
* allow us to filter things like we'd like to.  So now we use it
* semi-statically.  We initialize it to size 0 and if we need more room
* we realloc room for ARP_CACHE_INCR more entries in the table.
* We never release what we've taken . . .
*/
#define ARP_CACHE_INCR 1024
static struct arptab *at = NULL;
static int      arptab_curr_max_size = 0;

Интересно, как понимать последнюю фразу в комментарии - "We never release what we've taken . . ."?

[Ivan_83]

Добавить

if (NULL == at) {
arptab_curr_max_size = (ARP_CACHE_INCR * 4);
at = (struct arptab *) malloc(arptab_curr_max_size * sizeof(struct arptab));
}

 

 

Между:

 

 

   fgets(line, sizeof(line), in);

   i = 0;

 

 

Но я бы поискал багрепорты про "realloc" "alloc" для вашей версии ядра / libc

 

 

PS: код там полный капец %)

[AlKov]

Но я бы поискал багрепорты про "realloc" "alloc" для вашей версии ядра / libc

Вот-вот.. Мне тоже самое (о том, что тупо "удвоить"/"утроить"/etc.. не прокатит) сказал знакомый программер.

Так-что, будем жить с костылем :) Тем более, что работает он совсем не хуже, может даже и шустрее.