1.1Cas de dépannage
1.1.1 A Ping échoue parce que le paquet ICMP contient une somme de contrôle incorrecte
Symptôme de défaut
Un commutateur fonctionne comme une passerelle pour se connecter à des terminaux tels que le système de contrôle d'accès et les PC. Le commutateur ne parvient pas à envoyer un terminal.
Analyse des causes
Les paquets ICMP Echo Reply retournés par le dispositif pair portent une somme de contrôle incorrecte. La vérification du protocole échoue, provoquant une panne de ping.
Procédure de dépannage
1.Méthode 1 :
Lorsqu'un commutateur apprend correctement les entrées ARP, recueille des statistiques de trafic pour vérifier si les paquets de demande et de réponse d'Echo ICMP sont envoyés et reçus par le commutateur. Vous pouvez également capturer des paquets :
Figure 1-1Capture de paquets
Les informations de paquets capturées montrent que les paquets de réponse ICMP ont un checksum incorrect. incorrect dans la figure 1-3indique une somme de contrôle incorrecte.
2. Méthode 2 :
Exécutez la commande display icmp statistics avant et après l'opération de ping pour visualiser le champ bad checksum. Vérifiez si le nombre de paquets d'erreur de contrôle à la couche de protocole ICMP continue d'augmenter.
<HUAWEI> display icmp statistics
Input: bad formats
0 bad checksum
3
echo
8 destination unreachable
0
source
quench
0
redirects
0
echo
reply
0 parameter
problem 0
timestamp request
0 information
request 0
mask
requests
0 mask
replies
0
time
exceeded
0 timestamp reply
0
Mping
request
0 Mping
reply
0
Output:echo
0 destination unreachable
0
source
quench
0
redirects
0
echo reply 8
parameter problem 0
timestamp request
0 information
reply 0
mask
requests
0 mask
replies
0
time
exceeded
0 timestamp
reply 0
Mping
request
0 Mping
reply 0
Les informations précédentes reflètent un nombre croissant de paquets d'erreur de contrôle.
Solution
Vérifiez si les paquets ICMP retournés par la pile de protocole sur le dispositif pair ont un format correct.
1.1.2Les dispositifs directement connectés ne peuvent pas s'interposer à cause d'une entrée ARP statique incorrecte
Symptôme de défaut
Le client remplace un appareil sur le réseau en direct avec le commutateur A .Figure 1-4 montre le nouveau réseau. Le commutateur A et le commutateur B ne peuvent pas se couper l'un l'autre, et le statut de voisin OSPF sur le commutateur A est Exchange. Après que le commutateur A est remplacé par le dispositif original, le défaut est rectifié.
Figure 1-2Les dispositifs directement connectés ne peuvent pas s'interposer les uns les autres
Analyse des causes
1.Le dispositif d'origine peut pincer le commutateur B, indiquant que le lien entre les deux dispositifs fonctionne correctement. Le commutateur A et le commutateur B sont directement connectés, de sorte que le défaut n'est pas causé par des problèmes de routage. La faute peut être causée par des erreurs dans l'apprentissage ARP.
2. Exécuter la commande display arp all sur switch A pour vérifier si le commutateur A a appris l'entrée ARP du commutateur B.
<SwitchA> display arp all
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE
INTERFACE VPN-INSTANCE
VLAN/CEVLAN
------------------------------------------------------------------------------
1.1.1.1 0025-9e80-2494 I
- Vlanif20
1.1.1.2 0025-9e80-248e
18 D-0 GE1/0/1
33
------------------------------------------------------------------------------
Total:2
Dynamic:1 Static:0
Interface:1
Les informations précédentes montrent que le commutateur A a appris l'entrée ARP de switch B.
3. Exécuter la commande display arp all sur le commutateur B pour vérifier si le commutateur B a appris l'entrée ARP de switch A.
<SwitchB> display arp all
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE
INTERFACE VPN-INSTANCE
VLAN/CEVLAN
------------------------------------------------------------------------------
1.1.1.2
0025-9e80-248e I -
Vlanif20
1.1.1.1 0016-ecb9-0eb2 S--
GE1/0/1
33
------------------------------------------------------------------------------
Total:2 Dynamic:0
Static:1 Interface:1
Dans la table ARP, l’adresse IP 1.1.1.1 fait la correspondance avec l’adresse 0016-ecb9-0eb2. Le SSI d'entrée ARP, indiquant une entrée ARP statique. Dans les tables ARP des deux commutateurs, l'adresse IP 1.1.1.1 mappe différentes adresses MAC.
L'entrée ARP statique (numéro de port IP + MAC +) a été configurée sur le commutateur B avant le réglage du réseau, et n'a pas été mise à jour après le réglage du réseau ; par conséquent, le commutateur A ne peut pas pincer le commutateur B.
Procédure de dépannage
1. Exécuter la commande system-view sur le commutateur B pour entrer dans la vue du système.
2. Exécuter la commande undo arp static ip-address pour supprimer l'entrée ARP statique incorrecte.
Après que l'entrée ARP statique est supprimée, switch A peut ping switch B. Une nouvelle entrée ARP statique doit être configurée pour empêcher les attaques ARP.
3. Exécuter la commande arp static ip-address mac-address vid vlan-id interface interface-type interface-number pour configurer l'entrée ARP statique correcte.
Après les configurations précédentes, le commutateur A peut démarrer avec succès le commutateur B. Exécuter la commande display ospf peer pour vérifier l'état du voisin OSPF. Le voisin OSPF est en état Full.
<SwitchA> display ospf peer
OSPF Process 1 with Router ID
11.11.11.105
Neighbors
Area 0.0.0.0 interface 1.1.1.1(Vlanif33)'s
neighbors
Router ID: 2.1.1.1.168.10.2 Address:
1.1.1.2
State: Full Mode:Nbr is Master
Priority:
1
DR: 1.1.1.2 BDR: 2.1.1.1 MTU:
0
Dead timer due in 34
sec
Retrans timer interval:
8
Neighbor is up for
00:28:17
Authentication Sequence: [ 0 ]
Résumé
Si une entrée ARP statique est configurée sur un dispositif, modifier l'entrée ARP après les modifications d'adresse MAC. Si le commutateur B est un périphérique non-Huawei et que vous ne pouvez pas vous connecter au commutateur B pour vérifier la configuration, le commutateur B du commutateur A et configurer la fonction de miroir pour analyser les paquets transmis entre le commutateur A et le commutateur B. Vérifiez si les adresses MAC de destination des paquets sont correctes.
Le commutateur 1.1.3A peut être bloqué mais ne peut pas être accessible à distance
Symptôme de défaut
Dans Figure 1-5. Switch C peut ping VLANIF 20 de commutateur A, mais le commutateur C ne peut pas accéder au commutateur A à l'aide de Telnet.
Figure 1-3 Le commutateur A peut être bloqué mais ne peut pas être accessible à distance
Analyse des causes
1.Le commutateur prend en charge la fonction de réponse ICMP rapide. Cette fonction permet au commutateur de répondre rapidement au paquet de demande d'écho ICMP destiné à sa propre adresse IP.
Ce problème peut être causé par la fonction de réponse ICMP rapide sur le commutateur A. Si la réponse ICMP rapide est activée sur le commutateur A, le commutateur A peut rapidement répondre aux paquets de demande ICMP même si le commutateur A n'a pas de route destinée à 2.1.1.1. Le commutateur C peut utiliser avec succès le commutateur A, indiquant que le lien entre le commutateur C et le commutateur A est normal, mais la route peut être anormale. Par conséquent, vous devez vérifier s'il y a une route accessible depuis le commutateur C vers le commutateur A.
2. Exécuter la commande tracert 1.1.1.1 sur le commutateur C pour vérifier les routes depuis le commutateur C vers le commutateur A.
<SwitchC> tracert 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1), max hops: 30 ,packet length: 40
1 2.1.1.2 10 ms 1 ms 1 ms
2 * * *
Les informations précédentes montrent qu'il y a une route accessible depuis le commutateur C vers le commutateur B, mais pas de route accessible depuis le commutateur C vers le commutateur A. La cause possible est que la route vers 2.1.1.1 n'est pas configurée sur le commutateur A ou est configurée incorrectement.
3. Exécuter la commande telnet 2.1.1.2 sur switch C pour se connecter au commutateur B, et exécuter telnet 1.1.1.1 sur le commutateur B pour se connecter au commutateur A. Les opérations Telnet sont couronnées de succès, ce qui indique que la configuration Telnet sur le commutateur A est correcte.
4. Exécuter la commande display ip routing-table 2.1.1.1 sur switch A pour vérifier la table de routage. Dans la table de routage, l'entrée de correspondance la plus longue correspondant à l'adresse IP de destination 2.1.1.1 est vide. Exécuter la commande undo icmp-reply fast sur le commutateur A pour désactiver la fonction de réponse ICMP rapide. Le commutateur C ne fonctionne pas sur le commutateur A.
Dans une conclusion, le commutateur C peut ping switch A parce que la fonction de réponse ICMP rapide est activée sur switch A. Switch C échoue à ping switch A parce que le commutateur A n'a pas de route vers 2.1.1.1.
Procédure de dépannage
1. Exécuter la commande system-view sur le commutateur C pour entrer dans la vue du système.
2. Exécuter la commande ip route-static 2.1.1.0 255.255.255.0 1.1.1.2 pour configurer une route statique vers 1.1.1.2.
Ensuite, le commutateur C peut accéder au commutateur A à l'aide de Telnet.
1.1.4a switch undergoes an ARP attack and cannot be pinged
Symptôme de défaut
Dans figure 1-6, Les fonctions de commutation en tant que passerelle, Switch _ 1 (commutateur modulaire) est souvent hors de gestion, et les utilisateurs sur Switch _ 1 sont déconnectés fréquemment. Il y a un retard lorsque Switch _ 1 frappe le commutateur ou l'opération de ping échoue. Les services sur Switch _ 2 sont normaux, et Switch _ 2 peut ping la passerelle avec succès.
Figure 1-4 Le commutateur A subit une attaque AR******e peut pas être bloqué
Analyse des causes
Switch _ 1 reçoit des paquets ARP avec une adresse MAC source fixe. Les périphériques utilisateur ne peuvent pas envoyer ou recevoir des paquets ARP.
Procédure de dépannage
Effectuez les opérations suivantes sur Switch _ 1 :
1.Vérifier si l'utilisation de l'unité centrale est élevée.
<Switch_1> display cpu-usage
CPU Usage Stat. Cycle: 10 (Second)
CPU Usage : 82% Max:
99%
CPU Usage Stat. Time : 2010-12-18 15:35:56
CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.
L'utilisation du CPU atteint 82%.
2.Voir les entrées temporaires ARP pour vérifier si l'apprentissage ARP est normal.
<Switch_1> display arp
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE VPN-INSTANCE
INTERFACE
VLAN/CEVLAN
------------------------------------------------------------------------------------------------------
10.137.222.139
00e0-fc01-4422
I - Eth0/0/0
10.137.222.1 0025-9e36-e8c1
20
D-0 Eth0/0/0
10.137.222.100 0025-9e80-b278
6
D-0 Eth0/0/0
10.137.222.99 00e0-4c77-b0e1
9
D-0 Eth0/0/0
10.137.222.173 000f-3d80-cba4 18
D-0 Eth0/0/0
10.137.222.34 0025-9e36-e8c1
1
D-0 Eth0/0/0
10.137.222.172 0016-ec71-ea8c
7
D-0 Eth0/0/0
10.137.222.35 0025-9e36-e8c1
18
D-0 Eth0/0/0
10.137.222.179 0014-2ae2-3128 20
D-0 Eth0/0/0
10.137.222.38 0025-9e36-e8c1
17
D-0 Eth0/0/0
10.137.222.175 0014-2261-2b22
1
D-0 Eth0/0/0
50.1.1.3 Incomplete
1
D-0 GE5/0/0
500/-
50.1.1.2 Incomplete
1
D-0 GE5/0/0
500/-
6.1.1.2
00e0-fc01-4422
I - Vlanif6
10.0.0.139
00e0-fc01-4422
I - Vlanif10
192.0.0.4
00e0-fc01-4422
I - Vlanif192
20.1.1.1 00e0-fc01-4422
I - Vlanif200
192.168.2.2
00e0-fc01-4422
I - Vlanif100
------------------------------------------------------------------------------------------------------
Total:16
Dynamic:10 Static:0 Interface:6
Le champ MAC ADDRESS de deux entrées ARP sont incomplètes, indiquant des entrées temporaires. Certaines entrées ARP ne peuvent pas être apprises.
3.Vérifiez si le commutateur souffre d'une attaque ARP.
A.Voir les statistiques sur les paquets de demande ARP envoyés à l'unité centrale.
<Switch_1>display cpu-defend arp-request statistics all
Statistics on mainboard:
------------------------------------------------------------------------------------------------------------------
Packet Type Pass(Bytes)
Drop(Bytes) Pass(Packets)
Drop(Packets)
-----------------------------------------------------------------------------------------------------------------
arp-request
67908288
0
1061067
0
------------------------------------------------------------------------------------------------------------------
Statistics on slot 4:
------------------------------------------------------------------------------------------------------------------
Packet Type
Pass(Bytes) Drop(Bytes)
Pass(Packets) Drop(Packets)
------------------------------------------------------------------------------------------------------------------
arp-request
80928 44380928
2301 693450
------------------------------------------------------------------------------------------------------------------
Statistics on slot 5:
------------------------------------------------------------------------------------------------------------------
Packet Type
Pass(Bytes) Drop(Bytes)
Pass(Packets) Drop(Packets)
------------------------------------------------------------------------------------------------------------------
arp-request
N/A
N/A
0
0
------------------------------------------------------------------------------------------------------------------
Statistics on slot 6:
------------------------------------------------------------------------------------------------------------------
Packet Type
Pass(Bytes) Drop(Bytes)
Pass(Packets) Drop(Packets)
------------------------------------------------------------------------------------------------------------------
arp-request
N/A
N/A
0
0
------------------------------------------------------------------------------------------------------------------
Il y a un grand nombre de paquets de demande ARP sur la carte dans la fente 4.
B.Configurer la source d'attaque pour identifier la source d'attaque.
<Switch_1>system-view
[Switch_1]cpu-defend policy policy1
[Switch_1-cpu-defend-policy-policy1]auto-defend enable
[Switch_1-cpu-defend-policy-policy1]auto-defend attack-packet sample 5
//One packet is sampled out of five sent packets. A small
sampling rate will consume many CPU resources.
[Switch_1-cpu-defend-policy-policy1]auto-defend threshold 30
//The packets of which the rate reaches 30 pps are
considered attack packets. If there are many attack sources, reduce this value.
[Switch_1-cpu-defend-policy-policy1]undo auto-defend trace-type source-ip
source-portvlan
//Identify the attack source based on source MAC address.
[Switch_1-cpu-defend-policy-policy1]undo auto-defend protocol 8021x dhcp
icmp igmp tcp telnet ttl-expired udp
//Identify the attack source of the ARP attack.
[Switch_1-cpu-defend-policy-policy1]quit
[Switch_1]cpu-defend-policy policy1
[Switch_1]cpu-defend-policy policy1 global
C.Voir les informations de source d'attaque.
[Switch_1]display auto-defend attack-source
Attack Source User Table (MPU):
------------------------------------------------------------------------------------------------
MacAddress
InterfaceName Vlan:Outer/Inner
TOTAL
------------------------------------------------------------------------------------------------
0000-0000-00db
GigabitEthernet2/0/22
193 416
------------------------------------------------------------------------------------------------
L'adresse MAC de la source d'attaque est 0000-0000-00db, qui est connectée à GigabitEthernet2/0 / 22
Si l'adresse MAC a une entrée ARP correspondante, exécutez la commande display arp | include 0000-0000-00db pour vérifier son adresse IP.
Solution
l Configurez une liste noire.
#
acl number 4000
rule 10 permit type 0806 ffff source-mac 0000-0000-00db
ffff-ffff-ffff
#
cpu-defend policy 1
blacklist 1 acl 4000
//Add the users with specified characteristics to the
blacklist through an ACL. The switch discards the packets from the users in
blacklist.
#
cpu-defend-policy 1
cpu-defend-policy 1 global
#
l Configurez l'action de traçage de la source d'attaque.
#
cpu-defend policy policy1
auto-defend enable
auto-defend threshold 30
undo auto-defend trace-type source-ip source-portvlan
undo auto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired
udp
auto-defend action deny
//Set the attack source tracing action. The switch
discards all attack packets within the default interval, 300s.
#
cpu-defend-policy policy1 global
cpu-defend-policy policy1
#
1.1.5 VPN PE ne peut pas se mettre l'un à l'autre
Symptôme de défaut
Dans figure 1-7 deux interfaces de loopback sont créées sur deux PEs respectivement. Les interfaces Loopback1 sur les PE sont des interfaces réseau public, avec les adresses IP 1.1.1.1/32 et 1.1.1.2/32 respectivement. Les interfaces Loopback2 sont liées à l'instance VPN et ont des adresses IP 10.1.1.1/24 et 10.1.1.2/24 respectivement. Les PEs ne peuvent pas échanger des routes VPN et ne peuvent pas s'entraider.
Figure 1-5 PE ne peuvent pas s'entraider
Analyse des causes
Lorsqu'un dispositif a deux routes vers la même destination, une route directe et une route BGP, le dispositif utilise de préférence la voie directe pour créer une entrée de routage VPN locale. Le ping échoue parce qu'aucune route BGP n'existe dans la table de routage VPN.
Procédure de dépannage
1. Exécuter la commande display ip routing-table sur PE1 et PE2 pour vérifier les routes vers le segment de réseau distant. Vous pouvez trouver que les routes vers le segment de réseau distant de Loopback1 existent dans la table de routage.
2. Exécuter la commande display ip routing-table vpn-instance vpn-instance-name sur PE1 et PE2 pour vérifier les routes dans le routage VPN table La table de routage VPN n'a qu'un route 10.1.1.0/24 Direct qui est la route vers le loopback2 du dispositif local. En outre, le masque d'adresse IP a 24 bits mais pas 32 bits.
Dans ce cas, les adresses de Loopback2 des deux PE sont sur le même segment réseau. Bien que chaque PE ait reçu la route VPN, le PE considère que la route BGP est la même que la route directe parce que son adresse Loopback2 est sur le même segment réseau que celui de la loopback2 distante. Le dispositif utilise de préférence la voie directe pour créer une entrée de routage VPN locale. Les PEs ne s'échangent pas parce qu'aucune route BGP n'existe dans la table de routage VPN.
Solution
Exécutez les commandes suivantes sur PE1 et PE2 :
1. Exécuter la commande system-view pour entrer dans la vue du système.
2. Exécuter la commande interface loopback loopback-number pour entrer la vue de l'interface Loopback2.
3. Exécuter la commande ip address ip-address { mask | mask-length } pour configurer une adresse IP pour Loopback2 et changer la longueur du masque d'adresse IP à 32 bits.
Conclusion
Lorsque deux mêmes itinéraires sont destinés à un segment de réseau, le dispositif ne met à jour qu'un seul d'entre eux à la table de routage VPN.
1.1.6 Le commutateur Huawei échoue de Ping le commutateur Non-Huawei C3750
Symptôme de défaut
Comme le montre la figure 1-8, le commutateur est directement connecté à C3750 Ils ont mis en place une relation de voisinage OSPF par l'intermédiaire du VLAN 200 et font connaître les routes du VLAN 100 et du VLAN 300 aux extrémités distantes. Le serveur de surveillance (172.19.2.2) effectue des opérations de ping pour détecter si le serveur (172.19.3.2) est online
La figure 1-6 Huawei switch échoue au ping le C3750 directement connecté
Une panne de ping se produit environ toutes les 18 heures, et est récupérée après 0,5 heures, affectant le service de surveillance.
Analyse des causes
Route aging on C3750 est anormale, de sorte que la route 172.19.2.0 sur le segment network vers le serveur de surveillance est perdue, provoquant une panne de ping.
Procédure de dépannage
1.Vérifier les statistiques du trafic. Les paquets de demande ICMP du serveur de surveillance peuvent être correctement envoyés par Switch mais Switch ne reçoit pas de paquets de réponse ICMP. Le problème peut se produire sur C3750.
2.Afficher les informations de routage sur C3750 Lorsque le problème se produit, l'itinéraire vers le segment de réseau où le serveur de surveillance est localisé disparaît. Par conséquent, les paquets de réponse ICMP retournés sont rejetés par C3750
Lorsque le problème se produit, les deux LSA de réseau suivant existent dans les informations LSDB sur Switch, mais n'existent pas sur C3750.
Type LinkState ID
AdvRouter Age Len
Sequence Metric
Network 172.19.5.1
172.19.1.250 1256 32
80000208 0
Network 172.19.5.1
172.19.99.10 3600 32
800026C9 0
Basculer les inondations la LSA annoncée par 172.19.99.10 à tous les voisins. Lors de la réception de cette LSA, le C3750 supprime la LSA annoncée par 172.19.1.250 et provoque une perte de route dans le calcul de la route. Après 30 minutes, le commutateur (172.19.1.250) met à jour les LSA et annonce ses propres LSA Network à C3750. Puis les routes sur C3750 sont récupérées.
Attention aux points suivants :
− Le protocole OSPF définit trois éléments essentiels dans un LSA : Type, LinkStateID et AdvRouter Par conséquent, Switch estime que les LSA annoncées par 172.19.99.10 et 172.19.1.250 sont différentes. C3750 peut considérer que les deux LSA sont les mêmes ; par conséquent, il écrase la LSA annoncée par 172.19.1.250 avec la LSA annoncée par 172.19.99.10 En outre, le temps de vieillissement de la LSA annoncée par C3750 est de 3600 ; c'est pourquoi C3750 vieillit cette LSA, provoquant une perte de route.
− La LSA annoncée par 172.19.99.10 a un drapeau DC.
Type : Network
Ls id : 172.19.5.1
Adv rtr : 172.19.99.10
Ls age : 3600
Len : 32
Options : DC E
seq# : 800026c9
chksum : 0xd55
Net mask : 255.255.255.0
Attached Router 172.19.99.10
Attached Router 172.19.8.1
Selon RFC 1793 lorsque DoNotAge bit (le plus haut bit dans le champ Age) est défini à 1, cette LSA n'a pas besoin d'être supprimée, même si l'annonceur n'est pas disponible.
Quand ces LSA ont-elles été supprimées ?
Le problème se pose lorsque toutes les conditions suivantes sont remplies :
-La LSA a existé dans le LSDB pour au moins 3600s.
-Il n'y a pas d'itinéraire accessible à l'annonceur LSA.
Solution
l Changez les types de voisins OSPF sur Switch et C3750 à P2P, afin d'éviter les interférences de LSAs incorrectes.
l Changez les adresses IP des interfaces entre Switch et C3750 Cela peut également éviter les interférences de LSAs incorrectes.
