Care sunt mesajele KeepAlive de pe comutator cisco

errdisable spune că bucla, Keepalive ordonat, STP este silențios, există o furtună. Nu poate fi multicast L3 ca acest nod. Dacă, așa cum spuneți, este multicast L2, SRC = mac mac Switch, DST Mac = FF :: FF, atunci toate logic
Dar am constatat că acest cadru este vechiul SRC = DST, câmpul de tip Ethernet = 0x9000. În acest caz, dacă întrerupătorul scuipă rama din interfața sa, dispozitivul procesează rama pe cealaltă parte trebuie să se întoarcă în aceeași formă (SRC mac = DST mac) și astfel stinge interfață errdisable datorită buclei. Sau este cadru ar trebui să se schimbe într-un fel / procesat?

Va multumesc tuturor. Sa constatat că există un dispozitiv GPON furnizor de tranzit activ (pod), pe care vechiul firmware-ul îndeplinește în mod incorect cadre de date, până când sa oprit la [nu Keepalive] pe interfața

Asta-i drept, aceleași informații și am constatat că acesta este cadrul pentru verificarea eficienței protocolului. Și el a SRC mac = DST mac, dar în acest caz, în cazul în care comutatorul scuipă cadru din interfața sa, dispozitivul procesează rama pe cealaltă parte trebuie să se întoarcă în aceeași formă (SRC mac = DST pentru Mac) și interfața errdisable, respectiv, pentru a stinge din cauza pentru bucla. Sau este cadru ar trebui să se schimbe într-un fel / procesat?

Aici pare să aibă o explicație:

Un comutator nu transmite un cadru înapoi portul prin care a ajuns.
.
Când SwitchB descoperă că destinația adresa MAC a acestui cadru LOOP este învățat pe același port, acesta va renunța la cadru, mai degrabă decât transmiterea înapoi la SwitchA. Deci, într-un comportat bine de rețea comutată, cadre LOOP nu sunt transmise înapoi expeditorilor acestora pentru că ar necesita de a le trimite înapoi prin însăși portul au ajuns prin - și că este interzisă.

Pachetul LOOP-test va reveni numai în cazul în care toate switch-uri de-a lungul calea traseului său într-o altă unitate decât cea pe care a sosit pachetul expeditor. Și aceasta este bucla.