Forum automatisme

[Mode bouteille à la mer]

La question est vague mais mon problème tout autant ^^

Sur mon site j'ai environ 300 API qui sont en mode DHCP. J'ai régulièrement des problèmes de com entre eux et le centre de contrôle qui reçoit des synthèses défauts des APIs.

J'ai constaté que certains API galèrent à obtenir leur adresse IP sur le réseau. Impossible d'identifier une version de firmware ou un modèle d'API. Je me suis donc tournée vers le réseau... Et là on m'a envoyée dans mon bureau et j'ai été privée de sortie , enfin presque.

En bref, le réseau est pour moi une boite noire. Je ne connais rien de sa structure et je n'ai la main sur rien. Concrètement, quand je "veux" connecter un API sur le réseau, je fais une demande au client en explicitant le nom de mon API, son type d'API, l'adresse MAC, la version de FW, la pièce où il se trouve, si il y a déjà une prise réseau d'installée et si oui leur nom. Et mon client envoie cette demande au service IT qui lui me crée un accès.
Je peux ensuite consulter sur des pages web faites par le service IT les détails associés à mon automate : à savoir tout ce que j'ai déclaré ainsi que l'adresse IP, masque, passerelle, etc associé à mon API.

Et c'est tout pour mes actions.

La plupart du temps, ça marche sans problème et de temps à autre, impossible de savoir pourquoi, un automate n'arrive pas à prendre son adresse... Ou il y arrivait et n'y arrive plus. Comme je l'ai dit, je n'ai pas trouvé de point commun dans ces plantages : aucun point commun concernant la localisation, aucun point commun concernant le modèle, pas de point commun de firmware et toutes les config de tous les API sont les mêmes (en même temps, j'ai le choix entre rentrer une adresse IP ou cocher la case DHCP et rentrer un nom d'API et le nom de domaine... Difficile d'innover).
Face à ça, mon constructeur me demande... mon architecture réseau ! Mais comme c'est pas moi qui gère le réseau.... On tourne pas du tout en rond.

J'ai déjà un peu exploré les pistes type carte réseau HS mais le soucis c'est qu'une fois repassé en IP fixe, l'automate fonctionne nickel. Donc ça colle pas vraiment.
J'ai un peu tout essayé ce qui était possible : hard reset, rechargement complet FW + config + programme. Des fois ça marche, des fois pas... (je kiffe ce genre de panne)

Je me suis donc tourné vers mon client qui a vérifié que les adresses MAC correspondaient entre ce que je lisais dans l'automate et ce qui était entrée chez IT et il a fait... un ping en DHCP sur les équipements concernés. C'est à dire qu'il a tapé "ping F0867M01OAP2" au lieu de "ping 128.141.75.243" dans la console. Et comme la console traduit F0867M01OAP2 en 128.141.75.243 et que 128.141.75.243 c'est bien l'adresse qui a été attribué à F0867M01OAP2, pour lui tout va bien côté IT.

Bref, si vous avez une idée...

PS : le cierge à Saint Jude, c'est déjà fait... pour le moment pas de résultats.

Kallysto a écrit : ↑10 août 2017, 08:48Bref, si vous avez une idée...PS : le cierge à Saint Jude, c'est déjà fait... pour le moment pas de résultats.

Il faut tout passer en IP fixe, le DHCP cépabien

JC

Je rejoins JC87, autant d'automates en DHCP, c'est du suicide.

C'est un problème purement réseau, ton automate n'y est pas pour grand chose. A tout les coups le DHCP alloue l'adresse à un autre équipement, et readresse le tien.

Par contre bon courage avec le service info pour leur faire fixer 300 adresses

Tu peux surement affecter une adresse IP a partir de l'adresse MAC des automates , dans ce cas c'est une modification du coté réseau
L'informatique dans ta utilise surement un soft comme GLPI pour la gestion de parc info c'est peut etre applicable aux API

J'en ai pas assez dit sur le réseau.

En fait tous les équipements qui sont déclarés sur le réseau auprès du service IT se voient attribuer une adresse IP "fixe" dans le sens où elle ne change "jamais", enfin "rarement". En fait elle change quand le service IT fait des modifs car ils n'ont plus assez d'adresse IP dispo sur leur réseau. Donc il faut des modifs de Vlan en changeant du coup les masques et les sous réseaux et les passerelles (du coup on l'a systématiquement dans le baba pour la com).

Pourquoi je reste en DHCP alors, c'est parce je suis pas forcément informée de ses putains de modif de merde.
En septembre dernier, j'ai été informée le jeudi à 14h pour une permutation qui devait avoir lieu le lundi à 8h.... et qui concernait l'ensemble du site car ils faisaient une refonte complète du réseau... soit 500 machines en tout Ils nous avaient oublié dans l'envoi des mails.... (et pas le droit de bosser le WE... et mon chef allait pas demandé une dérogation pour LEUR connerie)
D'autres ont eu lieu dans certains bâtiments et j'ai jamais été prévenue... On a découvert le truc quand on s'est pris une chasse parce que ça marchait pas et qu'il n'y avait pas eu d'alarmes... bah non, le VLAN ne nous reconnaissait plus et ne laissait plus l'OPC récupérer les synthèses d'alarmes, donc forcément on est pas au courant.

Donc on a dit, on passe tous les API sur le second réseau, le réseau technique, qui lui n'a jamais été tripoté jusqu'à présent et qui est physiquement séparé du réseau général.
Problème, le réseau technique n'est pas dans tous les bâtiments et IT demande des sous au service dont on dépend pour chaque installation du réseau technique... du coup on ne le fait que pour les équipements ultra sensibles.

Bref, en fait mes API demande au réseau leur adresse IP mais c'est "toujours la même". En bref, elle ne change que rarement mais quand elle change, c'est un tel bordel qu'il est préférable d'être en DHCP.

En plus de ça, il n'y a pas de règle pour la com inter automate. C'est "au besoin". C'est à dire que par exemple, on a une sous stat dont la sonde de T° extérieure est morte, personne ne sait où elle se trouve (véridique), on va chercher la valeur dans l'automate du bâtiment d'à côté. C'est du temporaire définitif au final car le client ne voit pas pourquoi on sortirait une nacelle pour essayer de retrouver une sonde ou pour tirer du câble pour en poser une nouvelle alors que ça marche avec celle d'à côté.
Du coup, je dois faire de la com en DHCP car si je dois retrouver à chaque fois quels API ont de la com et lesquels se sont lire dedans "à la sauvage", je suis pas couchée.
Moi j'aurai bien un système pour le savoir, mais... c'est pas moi qui installe ou fait installer tous les API du coup y a pas mal d'info qui me parviennent pas... même si c'est moi qui me retrouve avec la merde derrière.

Voilà pourquoi j'ai presque tout le monde en DHCP.

Mais j'arrive pas à identifier pourquoi certains APi n'arrivent plus à prendre leur adresse tout d'un coup. En plus celle-ci n'a pas forcément changée entre temps.

krank a écrit : ↑10 août 2017, 10:47 Tu peux surement affecter une adresse IP a partir de l'adresse MAC des automates , dans ce cas c'est une modification du coté réseau
L'informatique dans ta utilise surement un soft comme GLPI pour la gestion de parc info c'est peut etre applicable aux API

C'est ce qui est fait, l'adresse est fixée à partir de l'adresse MAC de l'automate.

Et j'ai aussi régulièrement le problème quand on bascule de réseau... Les APIs prennaient leur adresses sur le réseau générale, on demande une bascule sur le réseau technique, elle est acceptée, les mecs viennent faire les modifs dans les armoires de brassage. Mes automates se voient attribuer une nouvelle IP sur le réseau technique et y a pas moyen qu'ils la prennent ! Pourtant, rien d'autres n'a changé. Et les déclarations étaient OK avant le changement. Et si on les passe en fixe, tout marche donc c'est pas le brassage.
j'ai un bâtiment de 20 APi comme ça qui m'a planté dans les doigts juste avant mes congés ! C'est le client qui a voulu migré, pas moi. Je suis pas suicidaire moi. Lui non plus vous me direz, puisqu'il ne fait qu'appuyer sur le bouton et c'est moi qui me démerde avec derrière.

pas simple !

Ils utilisent très probablement des baux statiques. Le protocole DHCP est bien utilisé, mais c'est toujours la même adresse qui est affectée.

Vu la simplicité du protocole DHCP, je ferai un petit coup de sniffer :

- Créer un TAP ethernet (ex : http://www.instructables.com/id/Make-a- ... twork-Tap/). Ca te permet d'écouter tout ce qui passe sur un cable.
- Se brancher et lancer wireshark pour voir les trames.
- Démarrer l'automate (qui devrait faire sa demande d'adresse au boot).
- Isoler les trames DHCP et voir ou ça coince.

Ronan

Je vais essayer ça sur le prochain... en espérant ne pas me faire tej du réseau. Je checkerai la charte info avant quand même... Sont assez parano comme ça.

ça risque de pas etre simple d'analyser avec wireshark vu la taille du réseau.
ça risque de bombarder de partout