Rintracciare un indirizzo mac di origine non valido

Ho ereditato il supporto di un sito remoto che contiene un Cisco 4500 ed è collegato a circa 2 dozzine di switch di accesso Cisco, principalmente 2960 con un paio di 3750 e 3560. Non tutti gli interruttori di accesso sono collegati direttamente al 4500: esiste un collegamento in cascata di interruttori apparentemente fatto a causa di un cablaggio inadeguato. Di recente ho notato messaggi serror sul 4500 che indicano che i frame sono stati ricevuti con un indirizzo mac di origine non valido:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

Il dispositivo collegato a Te5 / 1 è un interruttore di accesso (Cisco 3750). A sua volta è collegato ad altri 6 interruttori di accesso. Dopo un po 'di ricerche su Google sembra che il 4500 sia l'unica piattaforma Cisco che registra indirizzi mac di origine non validi. Dalla mia lettura, altre piattaforme (2960, 3750, ecc.) Sembrano inoltrare i frame ma non li registrano come non validi, né aggiungono una voce alla tabella degli indirizzi mac. Sospetto che la causa principale degli indirizzi mac di origine non validi potrebbe essere un errore, un bug del software o forse un server vmware non configurato correttamente. Quali strumenti sono disponibili sugli switch di accesso per rintracciare la porta offensiva?

cisco switch layer2

— User123456
fonte

Eliminato il mio post, non mi ero reso conto che non erano affatto visibili. Se lo switch non li inserisce in CAM, suppongo che la soluzione migliore sia eseguire la sessione SPAN sugli switch, ma anche in questo caso sarebbe difficile trovare la porta di origine. Un'altra opzione sarebbe quella di disabilitare l'unicast sconosciuto e vedere se qualcosa si rompe. Sono sorpreso che la comunicazione funzioni però. Se un host con quel MAC invia qualcosa al di fuori delle sue sottoreti, il GW dovrebbe ARP per vedere il MAC dell'host e incapsulare il frame, il GW ha strane mappature ARP?

— Daniel Dib,

Secondo supportforums.cisco.com/docs/DOC-36000 questi frame dovrebbero essere rilasciati in HW, quindi almeno non dovrebbero influenzare le prestazioni degli switch.

— Daniel Dib,

Sì, in base a quel link: "Si noti che i pacchetti con indirizzo MAC non valido verranno comunque eliminati, tutti gli altri switch Cisco Catalyst rilasciano silenziosamente questi pacchetti in HW, la piattaforma 4k genera esplicitamente un messaggio di registrazione quando viene osservato tale evento." ... ma so che questo non può davvero essere il caso dal momento che il 4500 si lamenta dei frame in arrivo su Te5 / 1 che è la porta collegata al 3750. Ciò indicherebbe che il 3750 sta inoltrando i frame con l'invalido mac sorgente nonostante ciò che dice DOC-36000.

— Utente 123456

Dividi e conquista!

— generalnetworkerror

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

Risposte:

Puoi provare se i frame possono essere bloccati usando un ACL MAC su interfacce e / o su vlan sugli switch di accesso. Applicando i blocchi in modo selettivo e verificando se i messaggi di errore sul 4500 scompaiono o meno, è possibile accedere alla fonte del traffico.

Spostare i cavi per vedere se la porta menzionata nel messaggio di errore sul 4500 di seguito potrebbe anche aiutare, ma potrebbe rivelarsi difficile in un ambiente di produzione.

— Gerben
fonte

Generalmente quando l'ho visto, proviene da una VM mal configurata (spesso ospitata su una macchina dell'utente). A seconda della situazione e dell'ambiente, possono essere difficili da rintracciare (ne ho visti molti in un'università negli edifici del dipartimento CS ed ECE che si muovevano e venivano / andavano come facevano gli studenti).

Hai già un paio di ottime risposte, ma un'altra opzione che puoi perseguire è quella di aggiungere la seguente configurazione agli switch a valle (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

Ciò eliminerà qualsiasi traffico con questo MAC piuttosto che inoltrarlo e poiché dovrebbe essere eseguito nell'hardware (salvo eventuali funzionalità / problemi che causano le ricerche MAC nel software), non dovrebbe avere un impatto negativo sulle prestazioni.

— YImparare
fonte

Grazie per questo suggerimento Ciò impedirà che i frame vengano inoltrati attraverso i trunk ad altri switch, il che è una grande vittoria. Esiste un modo attraverso i comandi di registrazione o debug per osservare una porta che elimina i frame in base a questa configurazione?

— Utente 123456

@fcorrao, purtroppo non con questa configurazione. Dovresti provare a fare ciò che Gerben ha suggerito e utilizzare un ACL MAC o il suggerimento di Dave di catturare il traffico al largo delle porte. Ma la mia opinione è che solo il dispositivo configurato male sarà influenzato negativamente, quindi o lo faranno conoscere o non si accorgeranno nemmeno di se stessi.

— Impara

Mi sembra che questo errore non influisca sulle prestazioni della rete, poiché hai scoperto i messaggi di registro da solo, piuttosto che essere inondato di reclami degli utenti. Questo mi porta a sospettare che il problema risieda in alcuni software o servizi connessi, ma parzialmente configurati o non configurati correttamente che non sono attualmente in uso.

Il tuo miglior corso potrebbe essere quello di far mentire questo cane addormentato, fino a quando alcuni utenti segnalano un problema. In alternativa, se hai tempo da perdere, puoi eseguire sessioni SPAN come suggerito da @Daniel Dib e dare un attento esame dell'output fino a quando non determini una porta o un dispositivo sospetti.

— Dave in Ohio
fonte