Il mirroring delle porte provoca ulteriore latenza?


9

Se sto inviando traffico dall'host A a B tramite uno switch, abilitando una porta mirror / SPAN aumenterà il tempo impiegato dai miei frame per passare da A a B?

Nb: Non sono preoccupato per il tempo impiegato dal frame con mirroring per raggiungere il mio host di monitoraggio. Mi chiedo solo se influenzerà le prestazioni della rete in un ambiente critico in termini di tempo.

Qualcuno l'ha provato? (Gradirei anche qualsiasi link a un post / articolo su questo)


1
In breve, no. Questo genere di cose accade sempre con frame che hanno destinazioni sconosciute o sono trasmissioni. In genere, la duplicazione e l'inoltro vengono eseguiti nell'hardware a velocità di filo.
Ron Maupin

1
Come ha già notato Ron Maupin, in generale no. Tuttavia, nessuno potrebbe rendere questa dichiarazione generale con alcuna garanzia in tutti i fornitori e le piattaforme. Potresti restringere questo?
YLearn

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:


7

In genere, secondo Cisco, "L'impatto sul tessuto di commutazione ad alta velocità è trascurabile".

Questo ovviamente dipende dal tuo interruttore, dalla sua struttura e dal carico sull'interruttore stesso. La porta a cui vengono inviati i dati copiati potrebbe tuttavia eliminare i pacchetti, se è stata sottoscritta in modo eccessivo. Personalmente, non ho mai sperimentato alcun tipo di danno usando il mirroring o lo SPAN.

Ecco un documento di Cisco direttamente sull'argomento su alcune delle loro linee di gatto: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41. html # anc48


1
Forse uno ha pensato di aggiungere a questo: essere più cauti con "RSPAN" o il mirroring remoto. L'inoltro di molto traffico speculare attraverso la tua rete potrebbe sovraccaricare facilmente i tuoi collegamenti. Come diceva stevieb, se si esegue SPAN / port-mirror sullo stesso dispositivo su una porta mirror dedicata, si dovrebbe andare bene.
Sebastian Wiesinger,

3

È possibile influire sulle fonti (ad es. Porte monitorate) se il traffico aggregato supera la capacità della destinazione (ad es. La porta di monitoraggio). Non ho il riferimento a cui inizialmente stavo pensando, ma eccone un altro: contropressione da una porta SPAN .

Quindi immagina di avere un server su una porta da dieci gig che vuoi SPAN su un dispositivo di acquisizione di pacchetti (o IDS / IPS, ecc.). Il dispositivo di monitoraggio è anche su un'interfaccia da dieci gig.

Ricordare che quando si imposta uno SPAN, si ha la possibilità di trasmettere SPANning (dall'interfaccia dello switch verso il server) o ricevere (dal server allo switch) o entrambi. Normalmente vorremmo vedere entrambi i lati di una conversazione, quindi sceglieremmo di SPANARE sia la trasmissione che la ricezione.

Ora immagina che il server sia molto occupato, ed entrambi i flussi di trasmissione e ricezione sono abbastanza pieni, costantemente al di sopra dei 5-gig in ogni direzione.

Ora vuoi inviare DUE stream superiori a 5 gig al dispositivo di monitoraggio tramite la porta di destinazione SPAN. Il traffico totale inviato alla destinazione SPAN è superiore a 10 gig. Ma quell'interfaccia è SOLO 10-Gig verso il dispositivo di monitoraggio. Quindi cosa succede? Ricordo che i documenti di Cisco affermavano che inizialmente i pacchetti sarebbero stati eliminati dal buffer di trasmissione dell'interfaccia verso il dispositivo di monitoraggio (ovvero il buffer di trasmissione della destinazione SPAN). Tuttavia, nel caso di flussi di traffico sostenuti di lunga durata, alla fine la capacità del commutatore di eliminare il traffico in eccesso dal buffer di trasmissione sarà esaurita (il che non ha senso e non ha senso per me), e quindi l'interruttore inizierà a utilizzare altri meccanismi per ridurre il flusso, inclusa la "contropressione" mediante 802.

E ora hai influenzato il tuo traffico di origine. Succedono cose brutte.

Questo problema è / è stato particolarmente significativo per una grande rete ad alta velocità a latenza molto bassa, che aveva molte fonti per lo SPAN. Questa è stata una considerazione importante e ha portato alla sostituzione dell'uso di sessioni SPAN con molte fonti per TAPS ottici, alimentazione di switch di aggregazione con ACL in ingresso (filtro per traffico interessante), quindi trunking quel traffico in entrata a più consumatori di pacchetti specializzati da 10 Gig (per dati esigenze di archiviazione e analisi).

Morale della storia: se hai intenzione di utilizzare molte fonti SPAN, assicurati che la larghezza di banda aggregata di ENTRAMBE tx e rx sia inferiore alla larghezza di banda del tuo dispositivo di acquisizione.

Ecco un trattato decente sull'uso delle porte SPAN

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.