Доброго дня!
Такая ситуация - есть пул DHCP, из которого коммутаторы тянут технологические IP для настройки, потом я скармливаю им конфиг с "правильным" адресом. Дискавери находит эти коммутаторы по правильному IP, все замечательно. Но через некоторое время на найденный объект навешивается интерфейс со старым технологическим IP, старые интерфейсы соответственно пропадают. Получаем ложный алярм "Node down"
Можно ли как нибудь такое поведение у Discovery отключить? Совсем отрубать configuration poll жалко.
А какой стоит primary node name у этих коммутаторов?
Имен у них нет, в primary name IP указан, вот он то и меняется ))
UPD. Был бы вполне приемлем вариант, чтобы была возможность Primary IP "прибить гвоздями" к объекту
По идее так и есть. Primary host name не должен сам по себе меняться, а primary IP может меняться только если primary host name это DNS имя. Попробуйте включить дебаг уровня 6, и после смены IP у коммутатора пришлите мне лог сервера.
Там тысячи полторы нодов, врядли влезет лог с 6-м дебагом :)
Вот что удалось увидеть в логах, касаемо одного узла:
[21-Mar-2013 13:52:39.209] NodePoller: processing node 10.255.254.96/255.240.0.0 in zone 0
[21-Mar-2013 13:52:39.209] GetOldNodeWithNewIP: ip=10.255.254.96 mac=70:72:CF:63:26:98
[21-Mar-2013 13:52:39.240] AcceptNewNode(10.255.254.96): node already exist in database with ip 10.247.5.102, will change to new
Технологический адрес 10.255.254.96, он не активен, но в арпе где-то мог остаться.
А нормальный адрес 10.247.5.102 почему то поменялся.
Вот погрепал логи касаемо того узла
Да, теперь понятно что происходит. Сервер находит где-то в ARP кэше технологический адрес, по MAC адресу находит коммутатор, и шитает, что у него IP сменился. Это делалось для мониторинга узлов с DHCP адресами, которые только на пинги отзываются. Я добавлю дополнительную проверку в этом месте, на то, какой адрес реально отвечает.
ОК, спасибо! ;)
Забыл спросить - в 1.2.7 я добавил соответствующую проверку, пропала эта проблема?