Problème
Déterminer la source de la perte de paquets et pourquoi elle se produit n'est pas toujours facile. Les paquets traversent plusieurs réseaux appartenant à différents FAI et organisations sur Internet, et vous n'avez pas accès à chaque routeur du chemin pour vérifier des éléments tels que l'état du lien et la charge du CPU. De plus, la perte de paquets peut survenir à n'importe quel point le long du chemin du réseau.
Causes possibles
Il existe de nombreuses raisons pour lesquelles les paquets peuvent être perdus en cours de route. Quelques raisons courantes sont :
- Problèmes de peering FAI
- Congestion du lien
- Mauvaise configuration (réglages de la bande passante ou vitesse et duplex de la NIC)
- Défaillances matérielles
- Charge CPU élevée sur un appareil réseau
- Gestion des micro-explosions
Comprendre la perte de paquets chez Cato
Une bonne façon d'identifier la perte de paquets chez Cato est d'utiliser l'écran Analytics dans l'application de gestion Cato Management. Les graphiques Perte de paquets et Descartés montrent la perte de paquets au fil du temps et vous permettent de vous concentrer sur des périodes spécifiques. Ces graphiques sont utiles pour identifier si la perte de paquets se produit et quand elle s'est produite dans le passé. En outre, vous pouvez identifier le type de perte de paquets : perte du fournisseur ou paquet écarté par Cato.
Remarque : La taille de l'échantillon de données la plus petite dans les graphiques Analytics est de 5 secondes. Par conséquent, une micro-explosion de 5 ms sera normalisée dans les moyennes affichées et n'apparaîtra pas comme un pic dans le graphique d'analytique.
1. Perte du fournisseur
Ceci est un exemple de perte de paquets entre le Socket et le PoP. Bien que la plupart des pertes de paquets des fournisseurs soient causées par des problèmes de connectivité réseau sur le dernier kilomètre en dehors du contrôle de Cato, cela n'exclut pas nécessairement un problème lié à Cato.
Comment Cato mesure la perte du fournisseur
La perte du fournisseur est mesurée en comparant le nombre de paquets envoyés et le nombre de paquets reçus sur un lien donné à la fois sur le Socket et le PoP.
- Perte de paquets en aval est la différence entre le nombre de paquets envoyés par le PoP et le nombre de paquets reçus par le Socket, exprimée en pourcentage.
Formule :
- Perte de paquets en amont est la différence entre le nombre de paquets envoyés par le Socket et le nombre de paquets reçus par le PoP, exprimée en pourcentage.
Formule :
La façon dont Cato calcule la perte de paquets du fournisseur signifie que, même si cela peut sembler simple, vous ne pouvez pas tout de suite blâmer le fournisseur de services Internet. Il est possible que vous ayez un équipement entre le Socket et le routeur du fournisseur qui contribue à la perte de paquets, ou qu'il y ait des problèmes avec le chemin du réseau plus proche du PoP qui échappent au contrôle du fournisseur de services Internet.
2. Écarté par Cato
La perte de paquets écartée par Cato est causée par le moteur QoS de Cato. Le moteur QoS commence à écarter les paquets de faible priorité lorsqu'un lien est congestionné et à toute priorité lors des pics de trafic. La congestion se produit lorsque le débit total sur un lien correspond à la bande passante configurée pour le lien. Cato écarte également les paquets si une priorité de gestion de la bande passante est configurée avec une limite de débit strict et si le trafic correspondant à la priorité atteint la limite. La perte de paquets écartée par Cato est un comportement attendu et n'est pas nécessairement le signe d'un problème.
Tout problème lié à la perte des paquets écartés par Cato est probablement causé par une mauvaise configuration. Les applications critiques, comme la VoIP, devraient recevoir la plus haute priorité de gestion de la bande passante. Si une congestion se produit, le trafic de faible priorité est écarté par Cato, mais le trafic de haute priorité n'est pas écarté. Assurez-vous toujours que les priorités de gestion de la bande passante appropriées sont affectées au trafic.
Les Analytics fournissent une vue d'ensemble de la perte de paquets. Cependant, à moins que vous ne traitiez de la perte de paquets écartée par Cato, les analytics à elles seules ne peuvent pas vous dire ce qui cause la perte de paquets ou où elle se produit.
Comment résoudre la perte de paquets
1. Détermination de l'étendue de la perte de paquets
Quand vous commencez, il est vraiment important de découvrir qui ou quoi subit la perte de paquets. Tous les utilisateurs subissent-ils une perte de paquets sur un site, ou est-elle isolée à un seul point d'extrémité ? La perte de paquets se produit-elle sur Internet ou sur le WAN? Des sites multiples sont-ils affectés par la perte de paquets, ou un seul ? Tout le trafic est-il affecté, ou s'agit-il seulement d'une certaine application ? La perte de paquets est-elle constante, ou ne se produit-elle que de manière intermittente ?
Connaître les réponses aux questions ci-dessus peut vous aider à identifier les événements CMA associés et vous faire gagner du temps pendant le processus de dépannage. Plus vous connaissez de détails à l'avance, plus votre dépannage sera ciblé.
2. Vérification des Analytics du site - Graphique de perte de paquets
La perte de paquets apparaît-elle dans le graphique de perte de paquets des Analytics du site ? Nous avons différentes recommandations basées sur les graphiques Analytiques qui peuvent montrer la perte de paquets et les paquets écartés.
Aucune perte de paquets
Il est possible qu'il y ait une perte de paquets sans qu'elle ne soit affichée dans l'écran Analytics. Il pourrait y avoir un problème sur le réseau local, ou cela pourrait être un problème lié au PoP. Utiliser l'outil réseau de l'interface utilisateur pour ping une adresse IP côté LAN depuis le Socket peut être un bon moyen d'identifier la cause première.
Perte de paquets
Si la perte de paquets s'affiche sur le graphique, elle peut être causée par une mauvaise configuration de la bande passante. Veuillez examiner la bande passante configurée comme indiqué ci-dessous dans Vérification de la configuration de la bande passante.
Pour la perte de paquets du fournisseur, vérifiez si les baisses sont présentes uniquement lorsque des pics de trafic (explosions) se produisent. Si tel est le cas, identifiez le trafic causant les explosions à l'aide de la page d'Application Analytics. Vous pouvez limiter le trafic de l'application en l'affectant à un profil de gestion BW restrictif.
Souvent, nous verrons des cas où le débit est généralement faible, mais les pics d'explosion causent la perte de paquets. Nous devons prendre en compte que le fournisseur de services Internet a sa propre politique de gestion du trafic et, dans ce cas, il est probable que la politique de l'ISP et la politique de gestion du trafic de Cato aient des politiques d'explosivité différentes. Pour plus d'informations sur l'explosivité, voir ci-dessous Vérification des micro-explosions
3. Vérification des Analytics du site - Graphique des paquets écartés
Pour les paquets écartés par Cato, vous devez également enquêter sur les priorités de bande passante. Vérifiez le Priority Analyzer sous le tableau de bord Analytics du site pour voir quelle priorité est écartée. Vous pouvez étendre la section de priorité pour afficher les principales applications dans cette priorité. Si la perte de paquets n'affecte qu'une application spécifique, vous devrez peut-être augmenter la priorité de cette application dans les règles réseau. Rappelez-vous, le QoS de Cato est conçu pour écarter les paquets de faible priorité lorsqu'une congestion se produit, donc la perte de paquets écartée par Cato n'est pas toujours un problème.
QoS de Cato peut également écarter tout paquet, quelle que soit sa priorité, en raison d'explosions dans cette file d'attente. Ce comportement est également attendu en raison de la nature de la gestion des explosions. La page de l'Analyzer de Priorités peut être utilisée pour identifier si des explosions de trafic se produisent en même temps que les paquets ont été écartés. Pour plus d'informations, voir Priotisation du trafic dans Socket et QoS.
L'Analyzer de Priorités dans l'écran Analytics montre la perte de paquets dans les sens ascendante et descendante pour chaque priorité de QoS.
4. (Optionnel) Surveillance de l'Expérience dans le Dernier Tramo
Les clients avec une licence de surveillance de l'expérience peuvent vérifier les onglets Dernier Tramo et Performance des Applications pour d'éventuelles pertes de paquets et écartements de paquets. Les données peuvent être mises en corrélation avec les résultats de la page des analytics réseau du site pour mieux comprendre d'où provient le problème.
5. Vérification des Analytics du site - Perte de paquets dans le Dernier Tramo
Pour évaluer si le fournisseur de services Internet rencontre des problèmes, utilisez l'onglet Dernier Tramo dans l'Analytics pour vérifier tout changement de latence ou perte de paquets qui apparaît sur le lien WAN. Contrairement à la perte de paquets du fournisseur, les données du dernier kilomètre sont basées sur des tests ICMP vers des sites Web populaires. À titre de recommandation, des IP de service supplémentaires pouvant être pingées peuvent être ajoutées à la page de supervision du Dernier Kilomètre. Par exemple, s'il y a des problèmes liés à la VoIP, l'IP du serveur SIP peut être configurée comme l'une des IP.
Si une perte de paquets liée au FAI est suspectée, posez les questions suivantes à votre FAI :
- Appliquez-vous la QoS sur le trafic UDP/443 ou UDP/1337 (DTLS) ?
- Appliquez-vous une protection DoS sur le trafic UDP qui pourrait provoquer une perte de paquets vers l'IP du PoP ?
- Y a-t-il une congestion ou un processeur élevé sur votre routeur dans le chemin vers l'IP du PoP ?
- Autorisez-vous le bursting au-delà du débit souscrit ?
6. Vérification de la configuration de la bande passante
La perte de paquets peut être causée par la congestion du lien, et il est important que la bande passante pour chaque lien WAN soit configurée correctement dans l'application de gestion Cato. Assurez-vous que la bande passante configurée correspond à ce que le FAI fournit dans la configuration du site. Configurez le paramètre de bande passante de l'interface WAN de Socket selon les termes de la licence du site Cato.
Les environnements Azure/AWS n'ont pas de limitations de bande passante traditionnelles. Au lieu de cela, la bande passante du site configuré ne doit jamais dépasser la bande passante prise en charge pour le vSocket. Pour Azure, à partir de la version 21, la taille VM Standard_D8ls_v5 prend en charge jusqu'à 2 Gbps. Dans AWS, la taille de l'instance c5n.xlarge offre une bande passante supérieure à 2 Gbps. Il est important de s'assurer que la bande passante configurée du site reste dans les limites prises en charge pour des performances optimales.
Si la bande passante configurée est inférieure à celle fournie par le FAI, le moteur QoS de Cato peut commencer à supprimer des paquets lorsque la limite de bande passante configurée est dépassée. Si tel est le cas, il y a une ligne plate dans le graphique de débit Analytics du site égale à la bande passante configurée du site, ainsi que des paquets rejetés par Cato.
Ce même comportement peut se produire si la bande passante est configurée correctement mais que le lien FAI est congestionné. Bien que ce comportement ne garantisse pas un problème, il est bon de vérifier que la bande passante est correctement configurée dans cette situation.
Si la bande passante configurée est supérieure à celle fournie par le FAI, le moteur QoS de Cato ne s'active pas lorsque la limite de bande passante du FAI est dépassée, et par conséquent, le FAI peut commencer à supprimer des paquets de manière aléatoire. Si tel est le cas, vous voyez une ligne plate dans le graphique de débit Analytics du site en dessous du niveau de bande passante configuré avec une perte de paquets du fournisseur.
Les informations sur le débit et la capacité de Socket pour chaque modèle de Socket sont disponibles dans la fiche technique Socket, consultez cet article : Guides Socket X1700, X1600 & X1500.
7. Vérifiez les performances du CPU du Socket
Depuis le WebUI du socket, sélectionnez l'onglet État HW. Cela affichera l'utilisation actuelle du pourcentage de CPU pour chaque cœur. Une utilisation constante du CPU au-dessus de 90 % aura un impact direct sur les performances du socket et provoquera une perte de paquets et une grande latence. Si une utilisation élevée constante du processeur est observée alors qu'une perte de paquets se produit sur le réseau, veuillez Contacter le support.
8. Élimination des reconnexions de site
Les reconnexions du site à Cato Cloud sont une source de perte de paquets. Vérifiez Accueil > Événements pour voir si la perte de paquets correspond à des événements de reconnexion. Filtrer les événements avec le sous-type = 'reconnecté'.
Les événements de reconnexion afficheront un message expliquant la raison des déconnexions. Consulte Comprendre les événements reconnectés
9. Contourner Cato
Pour la perte de paquets sur Internet, configurez un contournement de source ou de destination pour écarter rapidement un problème avec le Cato Cloud. La méthode la plus simple pour ce faire est de configurer un contournement de source pour l'adresse IP d'un seul utilisateur dans la configuration du site et de vérifier si la perte de paquets continue. Si la perte de paquets continue, le problème peut être sur le LAN, le Socket ou le FAI, mais le problème ne serait pas lié à un PoP.
10. Exécution des tests de Ping
Lancez un ping continu entre une adresse IP source et une destination touchées par la perte de paquets. Les pings sont plus faciles à suivre et peuvent être analysés dans les captures de paquets. Lorsqu'une partie des requêtes de ping n'atteint pas leur destination, vous subissez probablement une perte de paquets et cela apparaîtra comme un délai d'attente de la requête.
L'interface utilisateur du Socket vous permet également de faire un ping par nom d'hôte ou IP avec l'outil ping. Vous pouvez sélectionner l'interface à laquelle vous souhaitez envoyer le ping, soit via Cato, soit directement via le lien WAN. Recherchez toute inconsistance dans les résultats de ping, comme perte de paquets ou latence élevée. Si la perte de paquets est présente à la fois avec et sans Cato, cela peut indiquer un problème de FAI. De plus, si l'un des liens est 4G/LTE, vous devez vous rappeler que ces liens sont plus sensibles à la perte de paquets.
L'interface utilisateur n'envoie que 10 requêtes ping, donc si vous avez besoin de plus de pings, vous devrez cliquer à nouveau sur le bouton Ping.
Remarque : Les tests de ping sont efficaces pour vérifier la santé de base du réseau, mais l'absence de perte de ping n'indique pas nécessairement une ligne propre.
11. Exécution des tests Traceroute
Traceroute est utilisé pour identifier les routeurs (sauts) entre une source et une destination. Il affichera la perte de paquets et la latence pour chacun des sauts.
Traceroute peut être exécuté depuis l'interface utilisateur du Socket avec l'outil Traceroute. Exécutez Traceroute pour trouver toute perte de paquets ou latence élevée inattendue sur l'un des sauts sur le lien WAN entre le socket et la destination. L'interface utilisateur n'envoie qu'un seul paquet pour chaque saut et montre la perte de paquets pour chaque saut. Étant donné qu'un seul paquet est envoyé, vous ne verrez que 0 % ou 100 % de perte.
Analyse des résultats de Traceroute
Soyez conscient que la perte de paquets montrée à tout seul saut n'est pas nécessairement un signe de problème. Un seul saut pourrait montrer une perte de paquets de 100 % simplement parce que l'ICMP n'est pas activé sur le routeur. Un saut peut également afficher moins de 100 % de perte de paquets sans qu'il y ait un problème en raison de la limitation de taux ICMP. Si vous voyez une perte de paquets sur un saut et 0 % de perte de paquets au saut suivant, vous êtes probablement en train d'assister à une limitation de taux ICMP.
S'il y a un problème réel de perte de paquets, il commencera à un saut et se poursuivra sur plusieurs sauts, chaque saut montrant une perte de paquets. Il est également possible que plusieurs routeurs sur un chemin contribuent à la perte de paquets, de sorte que le montant de la perte de paquets peut varier à chaque saut. Par exemple, il y a huit sauts dans la route et Traceroute affiche une perte de paquets pour les sauts 3-7.
12. Générer une charge de trafic élevée pour détecter la perte de paquets
L'écran en temps réel peut aider à détecter d'éventuels changements de débit actuels pour identifier une perte de paquets immédiate et des paquets rejetés. Utilisez l'outil speedtest du Socket pour simuler une charge élevée et reproduire la perte de paquets due à une forte demande lors du dépannage.
Les résultats du Speedtest du Socket via Cato devraient être proches de la bande passante configurée pour le lien dans l'application de gestion Cato. Notez que la surcharge de tunnel DTLS (117 octets) peut légèrement réduire le débit.
Le test saturera le lien et montrera toute perte de paquets liée au FAI sur l'écran Network Analytics. Des paquets rejetés sont attendus lors de l'exécution du test si la bande passante du lien configurée est inférieure à la bande passante fournie par le FAI.
Test de vitesse direct
Lors de l'exécution du Speedtest directement via le port WAN, le résultat en amont devrait être proche de la licence de bande passante configurée dans l'application de gestion Cato. Le Socket utilisera toujours la QoS pour le test de vitesse direct en amont selon la licence de bande passante du site. D'autre part, le résultat en aval montrera la capacité totale du FAI local.
13. Tester le lien avec iPerf
Le Socket WebUI vous permet d'utiliser l'outil iPerf pour résoudre les problèmes de performance de dernière ligne entre le Socket et le PoP connecté dans le Cato Cloud. Le Socket exécutant le client iPerf effectue le test contre le serveur iPerf exécuté sur le PoP connecté.
Exécutez le test iPerf via Cato et directement sur le WAN depuis la page des outils de l'interface du socket. Sélectionnez UDP comme protocole (pour exclure le contrôle de flux TCP), définissez la direction (en amont ou en aval), et le taux cible comme la bande passante configurée. Cet outil peut mieux confirmer que le débit sur Cato et sur le WAN est comme prévu. Soyez conscient que la surcharge du tunnel DTLS (117 octets) peut légèrement réduire le débit.
Dans l'exemple ci-dessous, nous fixons 45 Mbps comme taux cible (ce qui est la même bande passante configurée dans l'application de gestion Cato) et le taux reçu est inférieur à celui attendu avec une perte de paquets de 3,7%
14. Vérification des liens de la liaison agrégée (LAG)
La perte de paquets et la latence élevée peuvent être causées par une mauvaise configuration de l'agrégation de liens (LAG) entre le Socket et un commutateur interne. Ce problème particulier ne peut pas être détecté dans Network Analytics, mais au lieu de cela, il doit être résolu au sein du LAN. Cato ne prend en charge que le LAG statique et le pair LAG doit prendre en charge le même mode. Les discordances de configuration LAG entraîneront une perte de paquets.
Pour plus d'informations de dépannage, consultez Link Aggregation (LAG) Link Experiencing High Latency and Packet Loss
15. Vérification de la vitesse de lien du Socket
Une cause possible de perte de fournisseur est qu'un lien Socket fonctionne à moitié duplex. Cela signifie que les paquets ne peuvent voyager que dans une direction (sortant ou entrant) à la fois, ce qui réduit considérablement le débit et entraîne une perte de paquets. Tous les liens Socket doivent toujours être en full-duplex sans exception.
Assurez-vous également que les vitesses de lien WAN et LAN sont égales ou supérieures à la bande passante configurée pour un site. La vitesse du lien peut être le facteur limitant le débit. Par exemple, si la bande passante configurée d'un site est de 200 Mbps mais que le lien LAN n'a négocié que 100 Mbps full-duplex, un ordinateur connecté au Socket ne peut pas dépasser un débit de 100 Mbps.
Pour vérifier l'état du lien, connectez-vous à l'interface du Socket et visualisez le statut du lien sur la page de surveillance. L'exemple ci-dessous montre le lien WAN1 à 100 Mbps en demi-duplex.
Si vous remarquez un lien en demi-duplex ou réglé à une mauvaise vitesse, vérifiez les paramètres du port sur l'appareil auquel le lien du Socket est connecté. Assurez-vous qu'il est configuré pour auto-négociation ou qu'il correspond aux paramètres de vitesse du Socket. Tous les liens Socket sont par défaut configurés pour l'auto-négociation, mais vous pouvez forcer la vitesse sur la page de paramètres réseau.
Si les paramètres du port sont corrects sur l'autre appareil, le câble Ethernet pourrait être endommagé. Remplacez le câble par un connu bon et voyez si le duplex ou la vitesse change. Si cela ne fonctionne pas, connectez un ordinateur portable ou un autre appareil au port du Socket et vérifiez l'état du lien. Faites de même sur l'autre appareil. Si le lien du Socket atteint la vitesse attendue et le full-duplex mais que le lien de l'autre appareil ne le fait pas, vous saurez que le problème est avec l'autre appareil.
16. Vérification des IPs dupliquées
Un autre problème au niveau du Socket pouvant causer une perte de paquets est la duplication des IPs sur le réseau. Le Socket peut généralement détecter des conflits IP avec ses adresses IP d'interface configurées. Un conflit IP existe lorsque deux appareils sur le même réseau se voient attribuer la même adresse IP. Si cela se produit, vous verrez l'erreur ci-dessous sur la page de surveillance de l'interface du Socket.
L'IP dupliquée peut ne pas être détectée lorsqu'une adresse IP statique est configurée sur l'interface WAN, puisque le Socket surveille seulement passivement un conflit IP. Il ne détectera un conflit IP que si le Socket reçoit un ARP de l'appareil avec l'IP en conflit.
Une fois le problème d'IP en conflit résolu, il peut prendre jusqu'à 24 heures pour que l'avertissement disparaisse de la WebUI. Voir Conflit d'adresse IP signalé sur l'interface du Socket même après sa résolution
17. Vérification des micro-explosions
Une autre cause potentielle de perte de paquets est les micro-explosions (éclatement). Les micro-explosions se caractérisent par une soudaine augmentation de paquets ou de trames de données qui se produisent dans un laps de temps très court, durant généralement seulement quelques microsecondes à millisecondes. Dans les situations où des micro-explosions se produisent et dépassent la limite de vitesse du lien, le fournisseur de dernière ligne (FAI) peut laisser tomber le trafic excessif, entraînant une perte de paquets.
Dans le graphique ci-dessous, vous pouvez voir un exemple de perte de paquets typiques causée par des micro-explosions et l'amélioration après avoir ajusté les paramètres de valeur d'éclatement.
Dans l'exemple ci-dessus, la valeur du niveau d'éclatement a été modifiée de la valeur par défaut de 0,2 à 0,01, ce qui signifie que le Socket et le PoP appliquent un modelage plus agressif sur le trafic, résolvant ainsi le problème de perte de paquets.
Ajuster les paramètres de niveau d'éclatement pour atténuer la perte de paquets
La valeur par défaut de l'éclatement appliqué pour les directions en amont et en aval est de 0,2. Avec cette valeur, le Socket et le PoP sérialisent les paquets vers le média aussi rapidement que possible, permettant que plus d'octets soient envoyés dans les premiers microsecondes du compartiment de la période de temps. Ce réglage optimise la performance en réduisant le délai de sérialisation et la latence globale.
Dans le cadre de cette étape de dépannage, vous devez réduire progressivement le niveau d'éclatement jusqu'à ce que la perte de paquets soit atténuée. À mesure que vous réduisez la valeur du niveau d'éclatement, le Socket et le PoP appliquent un modelage plus agressif sur le trafic, lissant ainsi les micro-explosions. La plus faible valeur que vous pouvez configurer est 0,001.
La meilleure pratique pour ajuster le niveau d'éclatement est de réduire progressivement la valeur (par exemple, de 0,2 à 0,18). Après avoir réduit la valeur, surveillez l'impact en analysant la perte de paquets dans les écrans de surveillance du site temps réel ou Network Analytics. Gardez à l'esprit que les métriques du site prennent généralement quelques minutes pour être mises à jour. Continuez à réduire la valeur d'éclatement jusqu'à ce que la perte de paquets soit atténuée.
Si la perte de paquets n'est pas résolue par cette procédure, cela signifie qu'elle est causée par une autre raison que des micro-explosions. Dans ce cas, restaurez la valeur par défaut de l'éclatement de 0,2 et Contactez le support pour plus d'assistance.
Modification du niveau d'éclatement
Le niveau d'éclatement peut être ajusté pour les directions en amont et en aval. Ce réglage affecte tous les liens WAN du site.
La configuration est appliquée au niveau du site ou au niveau du compte. La configuration au niveau du site prévaut sur celle au niveau du compte.
Pour configurer le niveau d'éclatement:
- Depuis le menu de navigation, sélectionnez Ressources > Configuration Avancée pour la configuration de niveau compte ou Configuration du site > Configuration Avancée pour la configuration de niveau site.
- Sélectionnez valeur d'éclatement descendante ou valeur d'éclatement ascendante.
- Activez le réglage et ajustez la valeur entre la plage de 0,001 - 0,2.
- Cliquez sur Appliquer
- Cliquez sur Enregistrer
Remarques:
- Si l'éclatement a été préalablement ajusté par le support Cato, la valeur ajustée sera indiquée à la place de la valeur par défaut de 0,2
- Les valeurs de burstiness ne peuvent être ajustées que pour les sites Socket
- Le plus petit compartiment de données dans l'application de gestion Cato est de 5 secondes, les micro-explosions sont normalisées dans les plus petits compartiments de données et sont généralement difficiles à identifier.
0 commentaire
Vous devez vous connecter pour laisser un commentaire.