В продолжении темы https://www.netxms.org/forum/oe-oo/invalid-network-mask-137/msg629/#msg629
Добавил маршрутизатор и в итоге получил кучу алармов о не соотвествии маски сети. Т.е. маска верно, но он почему то пишет should be.
Invalid network mask 255.255.255.252 on interface "irb.2002", should be 255.255.252.0
Здесь тоже маска верная, но он почему то считает что должно быть /22
Событие SYS_INCORRECT_NETMASK удалить не могу, отказано в доступе почем то (Невозможно удалить шаблон события: Отказано в доступе). Отключить тоже не понятно как. Терминировать все алармы тоже не получается, не выделяются по Ctrl+A и создаются в большом количестве....
Системные события нельзя удалить.
В Event Processing Policy уберите правило, которое создает алармы для этого события.
В монитор событий так же генерируются сообщения о некорректности маски. Можно ли как то глобально пофиксить чтобы сервер считал нормой маски вида 255.255.255.0 ?
Сервер ориентируется на известные ему сабнеты. Проверьте какие маски у объектов "subnet", удалите неправильные.
Quote from: Victor Kirhenshtein on November 05, 2014, 11:44:06 AM
Сервер ориентируется на известные ему сабнеты. Проверьте какие маски у объектов "subnet", удалите неправильные.
Не совсем понял у каких объектов "subnet" ? У нас маски на интерфейсах в основном 255.255.255.0 255.255.255.248 255.255.255.252 но сервер считает, что должны быть другого вида. В таблице subnets маски верные.
05.11.2014 14:13:40 corerouter Предупреждение SYS_INCORRECT_NETMASK Invalid network mask 255.255.255.252 on interface "irb.2016", should be 255.255.252.0
На интерфейсе irb.2016 висит адрес, к примеру:
address 1.1.1.1/30;
Адрес сети: 1.1.1.0
Broadcast: 1.1.1.3
Первый хост: 1.1.1.1
Последний хост: 1.1.1.2
А есть объект subnet "1.1.0.0/22" в Entire Networks?
Есть в Entire Networks 1.1.1.0/22 подсеть белых адресов. Из неё выделена мелкая /30 - в Entire Networks она висит как 1.1.1.0/30.
Ну давайте, например возьмём из rfc1918. Есть так же на роутере локальный интерфейс irb.218 с адресом 192.168.218.254/24;
05.11.2014 15:13:45 corerouter Предупреждение SYS_INCORRECT_NETMASK Invalid network mask 255.255.255.0 on interface "irb.218", should be 255.0.0.0
Возможно should be потому что он пытается задать маску ниже ? Т.е. если брать Entire Networks то там есть и 10.0.0.0/8 поэтому сервер пытается считать, что у других хостов с большими масками должна быть маска ниже ? Извиняюсь если сумбурно описал... Но хотелось бы добиться определения корректности масок на сервере.
Коллеги, всё таки не понятно, почему сервер считает маски не корректными и пытается сказать, что везде должна быть маска 255.0.0.0 то есть /8 или /22
Сейчас ситуация такая: если есть мелкие сети (они поделены на сегменты) /24 или /29 /30 то NetXMS считает что у ВСЕХ таких узлов маски должны быть ниже т.е. /8 или /22
Но отключать генерацию аларма на основе событий как то тоже не хочется, возможно же что действительно кто нибудь ошибется и укажет не допустимую маску (случайно например).
Какая версия NetXMS сейчас установлена? В 2.0-M3 мы довольно сильно переделали все что связано с адресами и подсетями - я предлагаю посмотреть сохранится ли проблема после обновления на 2.0-M3 или выше.
Quote from: Victor Kirhenshtein on April 07, 2015, 10:25:57 PM
Какая версия NetXMS сейчас установлена? В 2.0-M3 мы довольно сильно переделали все что связано с адресами и подсетями - я предлагаю посмотреть сохранится ли проблема после обновления на 2.0-M3 или выше.
Сейчас 2.0-M2, спасибо, проверим на M3.
Quote from: hsvt on April 08, 2015, 12:13:23 PM
Quote from: Victor Kirhenshtein on April 07, 2015, 10:25:57 PM
Какая версия NetXMS сейчас установлена? В 2.0-M3 мы довольно сильно переделали все что связано с адресами и подсетями - я предлагаю посмотреть сохранится ли проблема после обновления на 2.0-M3 или выше.
Сейчас 2.0-M2, спасибо, проверим на M3.
Всё равно почему то генерирует алармы.
См. скрниншот.
Настройки интерфейса System на коммутаторе:
Command: show ipif
IP Interface : System
VLAN Name : managment
Interface Admin State : Enabled
DHCPv6 Client State : Disabled
Link Status : LinkUp
IPv4 Address : 10.228.0.1/24 (Manual) Primary
Proxy ARP : Disabled (Local : Disabled)
IPv4 State : Enabled
IPv6 State : Disabled
DHCP Option12 State : Disabled
DHCP Option12 Host Name :
Почему он считает, что должна быть /8 ?
Скорее всего уже есть объект подсети с маской /8. Попробуйте его удалить и сделать configuration poll.
c 10/8 разобрались с помощью configuration pull (FULL)
QuoteЛогика работы такая: когда NetXMS находит/добавляет хост с адресом из субнета, которого еще нет, то создается новый объект субнета, и маска берется из конфигурации интерфейса нового хоста. В большинстве случаев это будет правильная маска. Все остальные хосты с интерфейсами из этого субнета проверяются на соответствие маске из уже существующего объекта субнета. Проблема возникает тогда, когда первым хостом в субнете является хост с неправильной маской, либо хост, с которого информацию получить нельзя - в этом втором случае NetXMS принимает маску равной 255.255.255.0 (/24), поскольку это один из самих распространенных вариантов. Если получилась неправильная конфигурация, то надо удалить неправильний объект субнета, и сделать конфигуратион полл хосту с правильной маской из этого субнета - тогда объект субнета будет создан заново с правильной маской.
Есть роутер Juniper, на нём висят сети uplink /24 и /22, из этих сетей нарезаны мелкие /30 /29 /28 для клиентов и они тоже висят на этом роутере на irb интерфейсах. Пробовал удалять из subnets подсети /22 /24 и делать configuration pull - всё равно netxms создаёт заново эти subnets и генерит кучу алармов про то, что у клиентов мол тоже такие маски должны быть. Как уже построить нужную логику без отключения эвента ?
У меня постоянно появляется сеть 10.0.0.0/8 и, как следствие, куча ивентов SYS_INCORRECT_NETMASK, причем ни на одном интерфейсе такой сети нет. А появляется эта сеть при опросе juniper:
Quote
> show interfaces em0 terse
Interface Admin Link Proto Local Remote
em0 up up
em0.0 up up inet 10.0.0.4/8
На juniper эта сеть по умолчанию назначается на управляющий интерфейс, в маршрутной информации эта сеть отсутствует, но по snmp, собака, отдает конфигурацию. Перевод интерфейса в unmanagement не помогает. Как netxms заставить игнорировать собирать конфигурацию интерфейса?
Quote from: Harun on October 01, 2015, 11:12:12 AM
У меня постоянно появляется сеть 10.0.0.0/8 и, как следствие, куча ивентов SYS_INCORRECT_NETMASK, причем ни на одном интерфейсе такой сети нет. А появляется эта сеть при опросе juniper:
Quote
> show interfaces em0 terse
Interface Admin Link Proto Local Remote
em0 up up
em0.0 up up inet 10.0.0.4/8
На juniper эта сеть по умолчанию назначается на управляющий интерфейс, в маршрутной информации эта сеть отсутствует, но по snmp, собака, отдает конфигурацию. Перевод интерфейса в unmanagement не помогает. Как netxms заставить игнорировать собирать конфигурацию интерфейса?
Алилуя!!! Хоть кто-то тут есть с похожей проблемой и ответил, а то разработчики опять куда то пропали... Уважаемый Harun смотрите какая штука. У меня тоже Juniper и тоже там есть em0.0 дурацкий с точно такой же конфой, причем в конфиге он не сконфигурирован,но сетка то всё равно висит. И вот зараза netxmsd создавал мне кучу алярмов из-за того что он считал у всех устройств тоже маску /8.
До недавнего времени я отключил и эвент и условия генерация и записи в журнал, но я считаю это не выход, в итоге вчера я сделал так: удалил все из Subnets и сделал юниперу Configuration pull (full) он нашёл все сети /24 /23 для коммутаторов и сверху появился 10/8, НО в этой subnets теперь только сам Juniper и с остальными свичами она перестала пересекаться.
Я даже пробовал делать em0 unit 0 disable, но это привело к плачевным результатам.
http://www.juniper.net/documentation/en_US/junos14.2/topics/task/troubleshooting/interfaces-em0-down-troubleshooting.html
http://kb.juniper.net/InfoCenter/index?page=content&id=KB27820&actp=RSS
http://www.juniper.net/techpubs/en_US/junos12.3/topics/task/configuration/routing-engine-single-initial-configuration.html
Я всё равно не понимаю логику KB, если у вас fxp0 выделенный - используйте его, ну так мы его и используем и там всё настроено для managment. Зачем он поднимает сам em0.0 не понятно, вы не пробовали случайно на нём повесить не 10/8, а например какой то из вашего диапазона?
И еще, то что я писал выше побороть алярмы на уже белые адреса /22 /24 всё равно таким способом не выходит, netxmsd сначала находит сетки (основные шлюзы) /22 /24, а каналы которые висят на irb интерфейсах /29 /30 /28 считает с ошибочной маской.
Quote from: hsvt on October 01, 2015, 12:23:49 PM
Я даже пробовал делать em0 unit 0 disable, но это привело к плачевным результатам.
Чем чревато set interfaces em0 disable?
Все таки это проблема netxms, а не juniper. Если я использую различные vrf instances с пересекающимися адресами, то огребаю ту же проблему - кучу ивентов при правильно настроенном оборудовании (неважно - juniper там или cisco), а netxms ничего не знает про vrf.
Для управления адресным пространством правильнее всего нужно делать в netxms разделение по доменам маршрутизации (что потребует нового функционала).
Или хотя бы временный костыль - возможность отключать сбор информации по отдельным интерфейсам. Первый способ (vrf) реализован например в nocproject.
Quote from: Harun on October 01, 2015, 02:40:33 PM
Quote from: hsvt on October 01, 2015, 12:23:49 PM
Я даже пробовал делать em0 unit 0 disable, но это привело к плачевным результатам.
Чем чревато set interfaces em0 disable?
Отвалились ВСЕ интерфейсы после коммита, если бы не confirmed пришлось бы лезть в консоль.
Так вы пробовали задавать на em0.0 другой IP из управления ?
Quote from: hsvt on October 01, 2015, 04:51:49 PM
Так вы пробовали задавать на em0.0 другой IP из управления ?
Нет, и не буду пытаться, так как я использую vrf, поэтому это не решит проблему.
Скажите, а это решение проблемы - https://www.netxms.org/documentation/adminguide/advanced.html#zones ?
Quote from: Harun on December 14, 2015, 01:43:51 PM
Скажите, а это решение проблемы - https://www.netxms.org/documentation/adminguide/advanced.html#zones ?
Возможно, стоит попробовать. Отпишитесь если получится раскидать по зонам.
Нет, это не решение проблемы, так как в зону целиком можно поместить только ноду, когда требуется по зонам раскидывать интерфейсы.