• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Inventaire réseau - relation téléphone ordinateur
#1
Bonjour,

J'ai mis en place FI en version suivante :

- FI agent 2.5.1-1 (sous Debian 9)
- FI plugin glpi9.4+1.1 sous GLPI 9.4.3

La découverte des équipements réseaux se passe bien, ainsi que l'inventaire à part quelques points qui m'amènent à poster ici.


1/ Lien Téléphone IP et ordinateur dans GLPI

Sur certains ports de mes switchs, j'ai un téléphone IP sur lequel est branché un ordinateur.
Dans l'inventaire du switch, je vois sur le port que les deux équipements sont bien dessus.

Mon problème est lorsque je veux faire une recherche "inverse" :

- Je pars de la fiche de l'équipement téléphonique : dans l'onglet "Port réseau", ça me dit qu'il y a deux ports réseau mais un seul est visible (celui qu'on avait renseigné manuellement à la création de la fiche, avec l'@MAC et son IP), et aucune indication du switch et port sur lequel il est connecté.
- Je pars de la fiche de l'équipement ordinateur : dans l'onglet "Port réseau", un seul port réseau (normal), et là je vois qu'il est connecté à "Link" sur le téléphone qui va bien, mais vu que le téléphone n'indique aucune info de connexion, je ne peux pas remonter jusqu'au port du switch.

Est-ce que c'est un comportement normal, ou bien il y a quelque chose que j'ai raté ? Comment puis-je faire pour, en partant de la fiche du téléphone ou de l'ordinateur, savoir sur quel port de quel switch il est branché ? (car c'est là l'intérêt que je recherche avec FI).


2/ Certains ports switchs up mais aucun équipement connecté

Ici, j'ai le problème soit dans le cas ou un switch avec plusieurs équipements est branché sur ce port, soit dans le cas ou un seul équipement est branché sur le port, soit dans le cas d'un téléphone IP avec un ordinateur branché dessus.

Dans tous ces cas, je vois bien toutes les @MAC de ces ordinateurs dans la mac table du switch pour le port concerné, mais côté GLPI rien n'est connecté sur ce port.
Dans l'historique de ce port, je vois des équipements qui sont connectés puis dans la minute suivante qui sont déconnectés.
Dans la fiche GLPI de ces équipements, je vois qu'ils sont connectés à "N/A sur hub", "hub" étant un équipement non-géré qui apparaît dans le plugin FI, sur lequel sont connectés plus de 700 équipements quand je vais dessus.....

J'essaie de trouver la cause de ces soucis, mais je ne trouve pas de logs par rapport à ça, donc si vous avez des pistes où chercher je suis preneur.

Merci d'avance pour vos réponses !
  Reply
#2
Salut meuced,

les appareils connectés sont remontés par l'agent après un inventaire réseau et en consultant les données LLDP/CDP/EDP. Ce support n'est pas parfait et il est même partiel quand un téléphone avec un hub intégré se trouve derrière un port. Il se pourrait donc qu'on ne reconnaisse pas les données collectées dans ton cas.

On peut peut-être améliorer ce support si tu nous fournis un walk snmp de ton switch.

Sinon, peut-être que le journal de l'agent peut donner quelques informations complémentaires, mais ça ne nous sera pas très utiles.
  Reply
#3
Bonjour,

Tout d'abord merci pour ta réponse.
Je vais déjà repartir sur une base propre car j'ai pas mail bidouillé depuis.
Je vais déjà comparer correctement le xml que génère fusioninventory-netinventory en exécution manuelle par rapport à la réalité (à première vue ça semble bien...), puis je reviendrais ici en fournissant toutes les infos dispos dont le walk snmp.

Cdt.
  Reply
#4
Bonjour,

Je suis donc parti sur une base propre, et j'ai décidé de faire mes tests sur un seul switch.
J'ai donc configuré un job de découverte, avec une seule IP et.... L'équipement est systématiquement refusé lors de l'import.
Je ne trouve pas quelle règle (ou absence de règle) provoque ce comportement. Dans la liste du matériel non importé, je vois bien une ligne mais pas d'info utile.

Si je lance manuellement fusioninventory-netdiscovery sur cette IP, ça me renvoie des infos qui ont l'air correctes :



Code:
<REQUEST>
  <CONTENT>
    <DEVICE>
      <AUTHSNMP>1</AUTHSNMP>
      <CONTACT>XXXX</CONTACT>
      <DESCRIPTION>Ethernet Routing Switch 3650GTS-PWR+  HW:04       FW:6.0.0.3   SW:v6.2.1.015 BN:15 (c) Extreme Networks</DESCRIPTION>
      <DNSHOSTNAME>192.168.11.23</DNSHOSTNAME>
      <FIRMWARE>v6.2.1.015</FIRMWARE>
      <IP>192.168.11.23</IP>
      <IPS>
        <IP>127.0.0.1</IP>
        <IP>192.168.11.23</IP>
        <IP>192.168.11.255</IP>
        <IP>192.168.8.0</IP>
      </IPS>
      <LOCATION>BAT1</LOCATION>
      <MAC>60:49:c1:8d:d5:01</MAC>
      <MANUFACTURER>Nortel</MANUFACTURER>
      <SERIAL>XYZXYZ</SERIAL>
      <SNMPHOSTNAME>SWITCH1</SNMPHOSTNAME>
      <TYPE>NETWORKING</TYPE>
      <UPTIME>223 days, 18:31:47.45</UPTIME>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>


Déjà il voit bien que c'est du networking donc ça réduit les règles concernées... Mais je n'avance pas plus. Comment puis-je savoir où ça bloque ?

Cdt.
  Reply
#5
Salut,

il semble que ton équipement ne soit pas entièrement reconnu car il manque le champ "MODEL". Il doit manquer une entrée pour le sysobjectID de cet équipement dans le fichier sysobject.ids.

Peux-tu fournir l'output complet de la commande suivante ?
Code:
fusioninventory-netdiscovery --first 192.168.11.23 --last 192.168.11.23 --debug --debug >192.168.11.23.xml
  Reply
#6
Bonjour,

Voici la sortie de la commande :


Code:
# fusioninventory-netdiscovery --first 192.168.11.23 --last 192.168.11.23 --debug --debug >192.168.11.23.xml
[debug] scanning block 192.168.11.23-192.168.11.23
[debug] creating 1 worker threads
[debug] [thread 1] creation
[debug] [thread 1] #1, scanning 192.168.11.23
[debug] [thread 1] #1, partial match for sysobjectID .1.3.6.1.4.1.45.3.83.4 in database: unknown device ID
[debug] [thread 1] #1, - scanning 192.168.11.23 with SNMP, credentials 1: success
[debug] [thread 1] #1, - scanning 192.168.11.23 with netbios: no result
[debug] [thread 1] #1, - scanning 192.168.11.23 with echo ping: success
[debug2] [thread 1] #1, executing arp -a 192.168.11.23
[debug] [thread 1] #1, - scanning 192.168.11.23 in arp table: no result
[debug2] [thread 1] processed 1 scans
[debug] [thread 1] termination
[debug] All netdiscovery threads terminated


Et le fichier xml en résultant :


Code:
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <AUTHSNMP>1</AUTHSNMP>
      <CONTACT>XXXX</CONTACT>
      <DESCRIPTION>Ethernet Routing Switch 3650GTS-PWR+  HW:04       FW:6.0.0.3   SW:v6.2.1.015 BN:15 (c) Extreme Networks</DESCRIPTION>
      <DNSHOSTNAME>192.168.11.23</DNSHOSTNAME>
      <FIRMWARE>v6.2.1.015</FIRMWARE>
      <IP>192.168.11.23</IP>
      <IPS>
        <IP>127.0.0.1</IP>
        <IP>192.168.11.23</IP>
        <IP>192.168.11.255</IP>
        <IP>192.168.8.0</IP>
      </IPS>
      <LOCATION>BAT1</LOCATION>
      <MAC>60:49:c1:8d:d5:01</MAC>
      <MANUFACTURER>Nortel</MANUFACTURER>
      <SERIAL>XYZXYZ</SERIAL>
      <SNMPHOSTNAME>SWITCH1</SNMPHOSTNAME>
      <TYPE>NETWORKING</TYPE>
      <UPTIME>224 days, 15:55:50.04</UPTIME>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>

Ce qui est bizarre c'est que lors d'un précédent test (avec une autre base de test glpi mais même version) cet équipement était bien découvert et importé (l'un des cas signalé en début de ce thread provenait de cet équipement).

Je suis également en train de générer le snmpwalk complet de cet équipement, dont je t'envoie le lien en MP dès que je l'ai.

Merci.
  Reply
#7
J'ai avancé un peu sur le sujet (un tout petit peu).

J'ai ajouté dans le fichier sysobject.ids l'OID pour le modèle en question sous la forme :

Code:
45.3.83.4       Avaya   NETWORKING      Ethernet Routing Switch 3650GTS-PWR+

Du coup, la sortie debug montre un full match maintenant :

Code:
# fusioninventory-netdiscovery --first 192.168.11.23 --last 192.168.11.23 --debug --debug > aaa.xml
[debug] scanning block 192.168.11.23-192.168.11.23
[debug] creating 1 worker threads
[debug] [thread 1] creation
[debug] [thread 1] #1, scanning 192.168.11.23
[debug] [thread 1] #1, full match for sysobjectID .1.3.6.1.4.1.45.3.83.4 in database
[debug] [thread 1] #1, - scanning 192.168.11.23 with SNMP, credentials 1: success
[debug] [thread 1] #1, - scanning 192.168.11.23 with netbios: no result
[debug] [thread 1] #1, - scanning 192.168.11.23 with echo ping: success
[debug2] [thread 1] #1, executing arp -a 192.168.11.23
[debug] [thread 1] #1, - scanning 192.168.11.23 in arp table: no result
[debug2] [thread 1] processed 1 scans
[debug] [thread 1] termination
[debug] All netdiscovery threads terminated

Le xml inclue bien maintenant le modèle :

Code:
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <AUTHSNMP>1</AUTHSNMP>
      <CONTACT>XXXX</CONTACT>
      <DESCRIPTION>Ethernet Routing Switch 3650GTS-PWR+  HW:04       FW:6.0.0.3   SW:v6.2.1.015 BN:15 (c) Extreme Networks</DESCRIPTION>
      <DNSHOSTNAME>192.168.11.23</DNSHOSTNAME>
      <FIRMWARE>v6.2.1.015</FIRMWARE>
      <IP>192.168.11.23</IP>
      <IPS>
        <IP>127.0.0.1</IP>
        <IP>192.168.11.23</IP>
        <IP>192.168.11.255</IP>
        <IP>192.168.8.0</IP>
      </IPS>
      <LOCATION>BAT1</LOCATION>
      <MAC>60:49:c1:8d:d5:01</MAC>
      <MANUFACTURER>Avaya</MANUFACTURER>
      <MODEL>Ethernet Routing Switch 3650GTS-PWR+</MODEL>
      <SERIAL>XYZXYZ</SERIAL>
      <SNMPHOSTNAME>SWITCH1</SNMPHOSTNAME>
      <TYPE>NETWORKING</TYPE>
      <UPTIME>224 days, 20:31:11.66</UPTIME>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>


Mais l'import après la découverte est toujours refusé :


Code:
2019-10-01 13:18:43    Ok    Traité :0 Créé :0 Mis à jour :0
2019-10-01 13:18:38    En cours d'exécution    Import refusé [ip]:192.168.11.23, [name]:192, [entities_id]:5
2019-10-01 13:18:38    En cours d'exécution    1 périphériques trouvés
2019-10-01 13:18:38    En cours d'exécution    Import refusé [ip]:192.168.11.22, [name]:192, [entities_id]:5
2019-10-01 13:18:38    En cours d'exécution    1 périphériques trouvés
2019-10-01 13:18:37    En cours d'exécution    0 périphériques trouvés
2019-10-01 13:18:35    Démarré    3 threads 3 timeout
2019-10-01 12:21:01    Préparé


Du coup pas d'import, du coup pas d'inventaire, du coup pas de reproduction des cas cités en début de thread Big Grin
Quoique si je crée cet équipement manuellement, l'inventaire pourrait fonctionner ?

En tout cas ça avance, je commence à bien comprendre le fonctionnement de tout ça.

Merci.

Et je viens de voir qu'on pouvait rajouter une colonne dans la liste du matériel ignoré, la règle qui rejette l'import est "Global import denied"....

Toujours dans la liste des équipements ignorés à l'import, je vois que pour cet équipement les colonnes suivantes sont vides :
- Type d'élément
- Numéro de série
- UUID
- MAC
- Agent

Du coup pas étonnant que ça ne match aucune des règles pour l'import, la question est donc pourquoi ce comportement alors que le XML semblerait ok...

Merci.
  Reply
#8
Exclamation 
Le bonjour du jour... Big Grin

Alors j'ai laissé tomber pour l'instant les problèmes d'import de la découverte, en créant à la main le matériel réseau dans GLPI.

J'ai ensuite procéder à une tâche d'inventaire réseau sur cet équipement, c'est bon ça "fonctionne", et je reproduis bien du coup les cas indiqués en tout début de ce sujet, ces questions restent donc entières.

En particulier, sur un port où sont branchés un téléphone et derrière ce téléphone un PC, ne remonte dans GLPI que le téléphone sur ce port, alors que le XML d'inventaire comporte bien les @MAC de ces deux équipements telles qu'on les voit dans la mac table du switch.
Alors que pour d'autres ports dans le même cas sur ce même switch, les deux équipements remontent bien dans la fiche GLPI.

Voici ce que me sort la commande d'inventaire lancée manuellement :

Code:
# fusioninventory-netinventory --host 192.168.11.23 --credentials version:2c,community:public --debug --debug --threads 3 --timeout 3 > SWITCH1.xml

[debug] creating 1 worker threads
[debug] [thread 1] creation
[debug] [thread 1] #1, scanning 0: 192.168.11.23
[debug] [thread 1] #1, full match for sysobjectID .1.3.6.1.4.1.45.3.83.4 in database
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] #1, LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone
[debug] [thread 1] termination
[debug] All netinventory threads terminated


Le morceau de XML du port en question, le port 9 (j'ai remplacés une partie des @MAC par des 0, c'est normal), les deux adresses MAC remontent bien :

Code:
        <PORT>
          <CONNECTIONS>
            <CONNECTION>
              <MAC>00:0f:00:00:00:f9</MAC>
              <MAC>00:08:00:00:00:26</MAC>
            </CONNECTION>
          </CONNECTIONS>
          <IFDESCR>Extreme Networks Ethernet Routing Switch 3650GTS-PWR+ Module - Port 9 </IFDESCR>
          <IFINERRORS>0</IFINERRORS>
          <IFINOCTETS>2315940921</IFINOCTETS>
          <IFINTERNALSTATUS>1</IFINTERNALSTATUS>
          <IFLASTCHANGE>80 days, 17:35:42.96</IFLASTCHANGE>
          <IFMTU>1514</IFMTU>
          <IFNAME>1/9</IFNAME>
          <IFNUMBER>9</IFNUMBER>
          <IFOUTERRORS>0</IFOUTERRORS>
          <IFOUTOCTETS>2687185630</IFOUTOCTETS>
          <IFPORTDUPLEX>3</IFPORTDUPLEX>
          <IFSPEED>100000000</IFSPEED>
          <IFSTATUS>1</IFSTATUS>
          <IFTYPE>6</IFTYPE>
          <MAC>60:49:00:00:00:00</MAC>
        </PORT>


Et le port tel qu'il apparait dans GLPI (on ne voit que le TEL) :


[Image: 1570021926-port9.png]


Le détail de ce port :

[Image: 1570022035-detail-port9.png]

Sur la fiche du téléphone en question, on voit qu'il a 2 ports réseau (encadré en rouge) mais un seul apparait :

[Image: 1570021926-portsreseautel.png]

Et si on regarde en base, on voit que le deuxième se nomme "Link", il doit surement servir à connecter le PC au téléphone mais ici ça ne fonctionne pas :


[Image: 1570021926-bddporttel.png]


Dans une réponse précédente, vous parlez de découverte par LLDP. Dans le XML produit, vu que les deux @MAC sont bien présentes je me dis que l'inventaire est donc OK, et que c'est côté import dans GLPI que ça bloque... Et qu'il tente de "lier" le PC au téléphone et le téléphone au switch car le PC est bien dans "Ordinateurs" et le téléphone dans "Téléphones" côté GLPI, vu que je je vosi pas d'infos à propos de ça dans le XML d'inventaire.


Voilà donc mon problème principal, qui m'empêche de faire confiance à cet inventaire, dans un contexte d'une cinquantaine de piles à inventorier et plusieurs centaines (voir milliers...) d'équipements, si je suis obligé de faire des vérifications unitaires j'ai pas fini malheureusement... Big Grin

Si au moins on pouvait m'expliquer ce qui est censé se faire là où mon problème se produit, et si je pouvais avoir plus de logs pour vérifier ce qu'il se passe, ça serait déjà un grand pas. Lors de vieux tests il y a longtemps, dans ce genre de cas FI créait un objet hub sur lequel il branchait tous les équipements vu sur le port, comme il le fait actuellement lorsque ce ne sont que des ordinateurs par exemple.
Merci merci en tout cas pour tout le travail que les devs font sur ce logiciel libre ! Heart
  Reply
#9
Salut meuced,

déjà, j'en ai profité pour ajouter ta définition de switch dans notre sysobkect.ids.

Ensuite, les lignes "LLDP support: skipping network address: Mitel IP Phone, no chassis id, Mitel IP Phone" dans l'output de l'inventaire réseau indique clairement qu'on ne reconnait pas tes téléphones spécifiquement et qu'on va manquer d'insérer une information qui ne pourra pas être interprêter dans le plugin. L'analyse du walk que tu m'as fourni pourra peut-être nous aider à implémenter le support spécifique des téléphones IP Mitel.

Enfin, pour ton problème d'import, peux-tu vérifier côté serveur, dans le fichier files/_log/php-errors.log du dossier GLPI si tu vois des erreurs genre "undefined name"... Tu pourrais être une nouvelle victime d'un bogue identifié récemment pour lequel j'ai proposé un patch rapide mais pas optimal et je sais que David Durieux travaille à corriger le problèmes plus en profondeur.
  Reply
#10
Bonjour,

Merci pour ta réponse.

Concernant l'import, non pas d'erreur dans le php-errors.log, aucune entrée dans ce fichier lorsque je tente un import manuel du fichier XML généré.

Et aucun message non plus quand je veux faire la découverte par une tâche, je n'ai que ces logs côté interface :

Code:
2019-10-03 10:37:57    Ok    Traité :0 Créé :0 Mis à jour :0
2019-10-03 10:37:51    En cours d'exécution    Import refusé [ip]:192.168.11.24, [name]:192, [entities_id]:5
2019-10-03 10:37:51    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:51    En cours d'exécution    Import refusé [ip]:192.168.11.23, [name]:192, [entities_id]:5
2019-10-03 10:37:51    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:51    En cours d'exécution    Import refusé [ip]:192.168.11.22, [name]:192, [entities_id]:5
2019-10-03 10:37:51    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:51    En cours d'exécution    Import refusé [ip]:192.168.11.21, [name]:192, [entities_id]:5
2019-10-03 10:37:51    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:51    En cours d'exécution    Import refusé [ip]:192.168.11.20, [name]:192, [entities_id]:5
2019-10-03 10:37:51    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:51    En cours d'exécution    Import refusé [ip]:192.168.11.19, [name]:192, [entities_id]:5
2019-10-03 10:37:51    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:50    En cours d'exécution    Import refusé [ip]:192.168.11.18, [name]:192, [entities_id]:5
2019-10-03 10:37:50    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:50    En cours d'exécution    Import refusé [ip]:192.168.11.17, [name]:192, [entities_id]:5
2019-10-03 10:37:50    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:50    En cours d'exécution    Import refusé [ip]:192.168.11.16, [name]:192, [entities_id]:5
2019-10-03 10:37:50    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:50    En cours d'exécution    Import refusé [ip]:192.168.11.15, [name]:192, [entities_id]:5
2019-10-03 10:37:50    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:50    En cours d'exécution    Import refusé [ip]:192.168.11.14, [name]:192, [entities_id]:5
2019-10-03 10:37:50    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:49    En cours d'exécution    Import refusé [ip]:192.168.11.13, [name]:192, [entities_id]:5
2019-10-03 10:37:49    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:49    En cours d'exécution    Import refusé [ip]:192.168.11.12, [name]:192, [entities_id]:5
2019-10-03 10:37:49    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:49    En cours d'exécution    Import refusé [ip]:192.168.11.11, [name]:192, [entities_id]:5
2019-10-03 10:37:49    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:49    En cours d'exécution    Import refusé [ip]:192.168.11.10, [name]:192, [entities_id]:5
2019-10-03 10:37:49    En cours d'exécution    1 périphériques trouvés
2019-10-03 10:37:48    En cours d'exécution    0 périphériques trouvés
2019-10-03 10:37:46    Démarré    3 threads 10 timeout
2019-10-03 10:37:17    Préparé

Et côté fichier de logs pluginFusioninventory-rules.log (un extrait) :


Code:
2019-10-03 10:37:52 [5799@SRVLINGLPI02]
Array
(
    [ip] => Array
        (
            [0] => 192.168.11.24
        )

    [name] => 192
    [entities_id] => 5
    [itemtype] =>
)

2019-10-03 10:37:52 [5799@SRVLINGLPI02]
execute actions, data:
Array
(
    [_rule_process] =>
)

Array
(
    [rule_itemtype] => PluginFusioninventoryInventoryRuleImport
)

2019-10-03 10:37:52 [5799@SRVLINGLPI02]
execute actions: 1

2019-10-03 10:37:52 [5799@SRVLINGLPI02]
- value2

2019-10-03 10:37:52 [5799@SRVLINGLPI02]
- action denied

2019-10-03 10:37:52 [5799@SRVLINGLPI02]
Array
(
    [action] => 0
    [_ruleid] => 119

)

RuleID 119 étant la Global import denied.

Comme tu peut le voir, il prend comme nom le début de l'IP... et dans la liste du matériel ignoré, aucune @MAC et numéro de série ne remonte.

Toujours côté fichier de logs, pour chaque IP qu'il tente de découvrir il y a un fichier du type pluginFusioninventory-dial5d95b35f986a9.log , qui ressemble à ça :


Code:
2019-10-03 10:37:51 [5799@SRVLINGLPI02]
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <DNSHOSTNAME>192.168.11.23</DNSHOSTNAME>
      <ENTITY>5</ENTITY>
      <IP>192.168.11.23</IP>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>366</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>SRVLINGLPI02-2019-10-02-08-50-16</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>
  Reply
#11
Tiens, le dernier XML que tu montres ressemble plus à celui d'une découverte d'un hôte qui ne répond qu'au ping...
Peux-tu vérifier les credentials que tu as définies et associées à l'entité #5 ?
  Reply
#12
OK, concernant mes problèmes de découverte, je suis donc un boulet et je serais fouetté en place publique ou puni à courir pieds nus dans la neige...
En fait ce n'est pas sur l'entité mais sur la plage IP qu'il manquait les credentials SNMP et du coup la découverte se passe beaucoup mieux... Surement qu'à force de tout péter et refaire j'ai raté ça à un moment.... hum...

Tu peux d'ailleurs rajouter les lignes suivantes également dans le sysobjects.ids pour une variante du modèle déjà ajouté précédemment et deux autres nouveaux modèles :


Code:
45.3.83.2       Avaya   NETWORKING      Ethernet Routing Switch 3626GTS-PWR+
2272.209     Avaya    NETWORKING    VSP-7254XSQ
2272.210      Avaya    NETWORKING    VSP-7254XTQ

A noter que la branche networking d'Avaya (l'ancienne ligne Nortel qu'ils avaient racheté) a été racheté depuis peu par Extreme Networks. Je sais que sans la liste complète de ces équipements, difficile de mettre à jour. Pour ma part je remplace Avaya par Extreme dans ce fichier pour les équipements que je possède.



Par contre, les problèmes d'inventaire restent présents, mais je sais qu'avec le snmpwalk que je t'ai envoyé ça ne pourra que s'améliorer.
Donc un grand merci d'avance, et sans pression je serai attentif à la suite donnée  Smile

Et tant que j'y suis, j'ai le cas où toutes nos caméras de type "Périphériques" ne sont pas rattachées à son port du switch, ça a créé un équipement non-géré, alors que l'@MAC est la même des deux côtés.
Ici ce sont des caméras Axis, apparemment elles sont repérées en LLDP par l'agent, je vais te fournir en MP le snmp walk et le port d'un exemple, si ça peut aider à améliorer la couverture fonctionnelle de FI.

En attendant, je ferais les modifs à la main dans l'inventaire (edit : en désactivant le lldp sur le port le lien se fait bien).

Merci.
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)