Il bridging aggiunge ritardo?

Se uso un bridge per eseguire lo sniffing del traffico come un uomo al centro, il bridge aggiungerà un ritardo? E quale parola dovrei usare ritardo o latenza?

— nufuniliza
fonte

Se vuoi zero delay, usa un tap - il segnale viene replicato elettricamente (o otticamente), quindi vedi esattamente cosa è stato inviato (errori e tutti) [nota: sono costosi, nonostante il valore di $ 5 al loro interno]

— Ricky Beam,

Risposte:

Ciao e benvenuto in Network Engineering.

Per quanto riguarda "ritardo" vs "latenza": i termini non sono sempre utilizzati in modo coerente. Alcuni suggerimenti possono essere trovati qui .

Penso in generale, il termine latenza viene utilizzato quando si osservano i tempi end-to-end per una direzione, che essenzialmente sono composti dalla somma di tutti i ritardi di propagazione, serializzazione, buffering (e possibilmente elaborazione) introdotti dai vari componenti lungo il percorso dalla fonte alla destinazione (e viceversa, se si vuole parlare dei tempi di andata e ritorno (RTT)). Quindi potresti dire che un bridge aggiunge un po 'di ritardo alla latenza generale.

(sezione successiva modificata dopo un utile commento) Un bridge, rispetto a un cavo diretto, aggiungerà almeno una volta il ritardo di serializzazione del supporto di rete dato (del lato di uscita del bridge), dopo averlo elaborato, per inviare i bit del frame ancora dal lato dell'uscita. Naturalmente, viene aggiunta una quantità di ritardo di serializzazione per direzione e poiché la maggior parte dei casi d'uso richiede (almeno alcuni) i dati per fluire in entrambe le direzioni, il bridge aggiungerà due volte il ritardo di serializzazione.

Vedi anche questa domanda e wiki.geant.org per la sua tabella sui ritardi di serializzazione).

Nel tuo caso, si verificherà un ulteriore ritardo nel buffering e nell'elaborazione a causa di "man in the middle thing". Quanto sarà interamente dovuto alla capacità di elaborazione del software di bridging dato sulla piattaforma data e alle varie funzionalità e moduli a cui è sottoposto il frame.

— Marc 'netztier' Luethi
fonte

Non ho avuto il mio caffè quindi forse non sto pensando bene, ma l'aggiunta di un bridge aggiunge necessariamente due volte il ritardo di serializzazione? Ovviamente aggiungerà sempre un ritardo di serializzazione (a meno che non ci sia una sorta di cut-through in corso), ma la serializzazione di "invio" avviene in parallelo con la deserializzazione del prossimo ricevitore (che sarebbe sempre accaduto comunque), quindi non lo è ha effettivamente solo un ulteriore ritardo in totale? Scusa se non è molto chiaro ...

— psmears

@psmears Il ritardo di serializzazione quando il bridge invia il frame all'estremità si verificherà in ogni caso, concordato. Per quanto riguarda il lato ricevente ... Immaginiamo un cavo "diretto" altrimenti identico che bypassa il bridge, in cui la stessa sequenza di bit viene inviata in modo sincrono, ma bypassando il bridge. Nel cavo, i bit si propagano lungo la linea, mentre il bridge attende che l'ultimo bit inizi a elaborare ... Oh. hai ragione, grazie! Tempo per una modifica, quindi.

— Marc 'netztier' Luethi,

Il ritardo di serializzazione è alla velocità del filo, quindi non è un gran ritardo. La maggior parte dei moderni switch di livello enterprise passerà alla velocità dei fili, quindi qualsiasi ritardo è molto, molto piccolo, probabilmente causato dalla congestione e dalla coda su un'interfaccia con sottoscrizione eccessiva.

— Ron Maupin

Sì, un bridge / switch aggiunge un certo ritardo a un frame, nell'ordine da 1 a 20 µs.

Per gli switch di solito parli di latenza: il ritardo tra la ricezione di un frame e l'inoltro di un'altra porta. Uno switch richiede del tempo per ricevere l'indirizzo di destinazione e prendere la decisione di inoltro. Gli interruttori store-and-forward (il tipo comune) devono ricevere l'intero frame prima di iniziare l'inoltro. Gli interruttori cut-through ad alta velocità possono scendere al di sotto di 1 µs. Modifica : come ha sottolineato correttamente @kasperd, il cut-through è possibile solo con le porte di origine e destinazione alla stessa velocità o abbassamento.

— Zac67
fonte

Vale la pena notare che il cut-through raggiunge prestazioni ottimali solo quando i collegamenti in entrata e in uscita funzionano allo stesso bitrate. E potrebbe darsi che nessun fornitore si sia nemmeno preso la briga di implementare il cut-through per scenari a bitrate misto.

— Kasperd,

@Kasperd Cisco, per la sua serie Nexus 3000, rivendica il "cut-through" per identiche velocità e scenari di riduzione della velocità (40G -> 1 / 10G), ma non per i speed-stepup (1 / 10G -> 40g). cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/…

— Marc 'netztier' Luethi

@kasperd & Marc'netztier'Luethi - Assolutamente, grazie. Il cut-through con intensificazione è impossibile poiché si esauriscono rapidamente i dati (a meno che non si abbia la lunghezza del frame che non si utilizza).

— Zac67,

@ Zac67 La lunghezza è nota su alcuni frame ma non su tutti i frame. (E dopo aver letto come funziona, mi

— pento di