Lucrez într-un mediu de rețea în care am câteva Cisco Switch WS-C3560X-48 și servere Linux care rulează CentOS 7.7.
Serverele Linux sunt conectate de 3 ori pe switch-urile mele: un link de administrare, un link de producție și un link ILO, deoarece rulează pe hardware HP.
Când încerc să dau ping la serverele de pe LAN-ul de administrare de la comutatorul meu Cisco, obțin următorul rezultat:
SWTCisco#ping 10.123.213.152 sursa 10.123.213.158 repeta 100
Tastați secvența de evacuare pentru a anula.
Trimiterea Echos ICMP de 100, 100 de octeți la 10.123.213.152, timeout este de 2 secunde:
Pachetul trimis cu o adresă sursă de 10.123.213.158
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!.!!!!!!!!!!.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Rata de succes este de 86 la sută (86/100), min/media/max dus-întors = 1/3/17 ms
După cum puteți vedea, am un model, întotdeauna pierd un pachet pe al 7-lea ping. Pe partea de server, pot vedea cu tcpdump că cererea icmp este primită, dar răspunsul icmp nu este trimis. În exemplul de mai jos, am ghingat de 8 ori serverul și putem vedea 2 cereri urmându-se.
root@CentOSserver:/etc/sysconfig/network-scripts# tcpdump -i gazdă eno1 10.123.213.158 -nn
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
ascultare pe eno1, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
11:37:04.770292 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, seq 0, lungime 80
11:37:04.770354 IP 10.123.213.152 > 10.123.213.158: răspuns ecou ICMP, id 134, seq 0, lungime 80
11:37:04.772624 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, secv 1, lungime 80
11:37:04.772644 IP 10.123.213.152 > 10.123.213.158: răspuns ecou ICMP, id 134, seq 1, lungime 80
11:37:04.774394 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, secv 2, lungime 80
11:37:04.774411 IP 10.123.213.152 > 10.123.213.158: răspuns ICMP ecou, id 134, seq 2, lungime 80
11:37:04.776592 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, seq 3, lungime 80
11:37:04.776606 IP 10.123.213.152 > 10.123.213.158: răspuns ecou ICMP, id 134, seq 3, lungime 80
11:37:04.789083 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, seq 4, lungime 80
11:37:04.789099 IP 10.123.213.152 > 10.123.213.158: răspuns ecou ICMP, id 134, seq 4, lungime 80
11:37:04.791466 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, seq 5, lungime 80
11:37:04.791483 IP 10.123.213.152 > 10.123.213.158: răspuns ecou ICMP, id 134, seq 5, lungime 80
11:37:04.793669 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, seq 6, lungime 80
11:37:04.822159 ARP, Solicitați cine-are 10.123.213.158 spuneți 10.123.213.144, lungime 46
11:37:06.793024 IP 10.123.213.158 > 10.123.213.152: Solicitare ecou ICMP, id 134, seq 7, lungime 80
11:37:06.793068 IP 10.123.213.152 > 10.123.213.158: răspuns ecou ICMP, id 134, seq 7, lungime 80
10.123.213.158 este adresa vlan-ului meu Cisco Switch
10.123.213.152 este adresa eno1 pe serverul Linux
10.123.213.144 este adresa ILO a unui alt server care face o solicitare arp în timp ce tcpdump-ul meu rula.
După o nouă investigație, am descoperit că problema este legată de spanning-tree. Am găzduit un pcap a ceea ce am găsit.
https://filebin.net/9x9ech3uude93sda
În pcap, putem vedea că există un pachet STP între cererea 2 icmp. Am încercat de mai multe ori și de fiecare dată, un pachet STP este locul unde ar fi trebuit să-mi găsesc răspunsul.
Pentru mine, este doar un mesaj bpdu și nu ar trebui să aibă niciun impact asupra interfeței mele GigabitEthernet0/27.
Nimic deosebit de alarmant (pentru mine) nu este vizibil în configurația spanning tree de pe cisco:
SWTCisco#sh spanning-tree vlan 28
VLAN0028
Protocolul spanning tree activat ieee
Prioritate ID rădăcină 32796
Adresa 501c.bf45.1c00
Acest pod este rădăcina
Hello Time 2 sec Vârsta maximă 20 sec Întârziere înainte 15 sec
Bridge ID Prioritate 32796 (prioritatea 32768 sys-id-ext 28)
Adresa 501c.bf45.1c00
Hello Time 2 sec Vârsta maximă 20 sec Întârziere înainte 15 sec
Timp de învechire 300 sec
Interfață Rol Sts Cost Prio.Nbr Tip
------------------- ---- --- --------- -------- ------- -------------------------
Gi0/11 Desg FWD 4 128,11 P2p
Gi0/18 Desg FWD 4 128,18 P2p
Gi0/19 Desg FWD 4 128,19 P2p
Gi0/20 Desg FWD 4 128,20 P2p
Gi0/21 Desg FWD 19 128,21 P2p
Gi0/22 Desg FWD 4 128,22 P2p
Gi0/23 Desg FWD 4 128,23 P2p
Gi0/24 Desg FWD 4 128,24 P2p
Gi0/25 Desg FWD 4 128,25 P2p
Gi0/26 Desg FWD 4 128,26 P2p
Gi0/27 Desg FWD 4 128,27 P2p
Gi0/31 Desg FWD 4 128,31 P2p
Gi0/32 Desg FWD 19 128,32 P2p
Gi0/33 Desg FWD 4 128,33 P2p
Gi0/34 Desg FWD 4 128,34 P2p
Gi0/35 Desg FWD 4 128,35 P2p
Gi0/36 Desg FWD 4 128,36 P2p
Gi0/37 Desg FWD 4 128,37 P2p
Gi0/38 Desg FWD 4 128,38 P2p
Gi0/39 Desg FWD 4 128,39 P2p
Gi0/40 Desg FWD 4 128,40 P2p
Gi0/47 Desg FWD 19 128,47 P2p
Gi1/3 Desg FWD 4 128,51 P2p
SWTCisco#sh rulează int gigabitEthernet 0/27
Configurația clădirii...
Configurație curentă: 113 octeți
!
interfață GigabitEthernet0/27
vlan de acces switchport 28
acces în modul switchport
Sfârşit
SWTCisco#sh porturi blocate spanning-tree
Nume Lista interfețe blocate
-------------------- ------------------------------ ------
Numărul de porturi (segmente) blocate în sistem: 0
SWTCisco#sh spanning-tree rezumat
Comutatorul este în modul pvst
Punte rădăcină pentru: VLAN0028, VLAN0031, VLAN3715
Protecția pentru configurații greșite EtherChannel este activată
ID-ul de sistem extins este activat
Portfast implicit este dezactivat
PortFast BPDU Guard Valoarea implicită este dezactivată
Portfast BPDU Filter Default este dezactivat
Loopguard implicit este dezactivat
UplinkFast este dezactivat
BackboneFast este dezactivat
Metoda Pathcost configurată utilizată este scurtă
Blocare nume Ascultare Învățare Redirecționare STP Activ
---------------------- -------- --------- -------- --- ------- ----------
VLAN0028 0 0 0 23 23
VLAN0031 0 0 0 12 12
VLAN0157 0 0 0 1 1
VLAN3715 0 0 0 1 1
---------------------- -------- --------- -------- --- ------- ----------
4 vlans 0 0 0 37 37
SWTCisco#sh versiunea | în RELEASE
Software Cisco IOS, Software C3560E (C3560E-UNIVERSALK9-M), Versiunea 12.2(55)SE5, SOFTWARE DE LANSAREA (fc1)
BOOTLDR: încărcător de pornire C3560E (C3560X-HBOOT-M) Versiunea 12.2(53r)SE1, SOFTWARE DE LANSAREA (fc1)
Mi-am urmărit interfața Gi0/27 în timp ce ping-ul este activ și interfața rămâne în starea FWD.
Are cineva idee de ce pierd un pachet în timp ce comutatorul trimite un cadru bdpu? Am câteva probleme în a înțelege unele funcționalități stp avansate, așa că s-ar putea să îmi lipsească ceva aici.
