If I use a bridge to perform traffic sniffing like man in the middle will the bridge add a delay? And what word should I use delay or latency?
1
-
If you want zero delay, use a tap -- the signal is electrically (or optically) replicated, so you see exactly what was sent (errors and all) [note: they're expensive, despite the $5 worth of logic inside them]– RickyCommented Jan 8, 2019 at 16:19
Add a comment
|
2 Answers
Hi and welcome to Network Engineering.
As for "delay" vs "latency": The terms are not always used consistently. Some hints may be found here.
I think generally, the term latency is used when looking at end-to-end times for one direction, which essentially are composed of the sum of all propagation, serialization, buffering (and possibly processing) delays introduced by the various components along the path from source to destination (and back, if one wants to talk about round trip times (RTT) ). So you may say that a bridge adds some delay to the overall latency.
(next section edited after a helpful comment) A bridge, when compared to a direct cable, will add at least once the serialization delay of the given network medium (of the bridge's egress side), after processing it, to send the frame's bits out again on the egress side. Of course, one amount of serialization delay is added per direction, and since the majority of use cases requires (at least some) data to flow in either direction, the bridge will eventually add serialization delay twice.
Also see this question and wiki.geant.org for its table about serialization delays).
In your case, some additional buffering and processing delay will occur due to the "man in the middle thing". How much that will be is entirely up to the processing capacity of the given bridging software on the given platform, and the various features and modules the frame is being subjected to.
answered Jan 8, 2019 at 9:59
-
1Haven't had my coffee so may not be thinking straight, but does adding a bridge necessarily add two times the serialization delay? Obviously it will always add one serialization delay (unless there's some sort of cut-through going on), but the "sending" serialisation happens in parallel with the next receiver's deserialisation, (which was always going to happen anyway), so isn't it only effectively one extra delay in total? Sorry if that's not very clear...– psmearsCommented Jan 8, 2019 at 13:44
-
1@psmears The serialization delay when the bridge sends out the frame at the far end will occur in any case, agreed. As for the receiving side... Let's imagine a otherwise identical "direct" cable bypassing the bridge, where the same bit sequence is sent synchronously, but bypassing the bridge. In the cable, bits just propagate down the line, while the bridge is waiting for the last bit to start processing... Oh. you're right, Thanks! Time for an edit, then. Commented Jan 8, 2019 at 14:17
-
The serialization delay is at wirespeed, so it is not much of a delay. Most modern enterprise-grade switches will switch at wirespeed, so any delay is very, very small, probably caused by congestion and queuing on an oversubscribed interface.– Ron Maupin ♦Commented Jan 8, 2019 at 16:19
Yes, a bridge / switch adds some delay to a frame - in the order of 1 to 20 µs.
For switches you usually speak of latency - the delay between receiving a frame and forwarding it out another port. A switch requires some time to receive the destination address and make the forwarding decision. Store-and-forward switches (the common kind) need to receive the entire frame before starting to forward. High-speed cut-through switches can get below 1 µs. Edit: as @kasperd has correctly pointed out, cut-through is only possible with source and destination ports at the same speed or stepping down.
-
3Worth noting that cut-through only achieves optimal performance when incoming and outgoing links run at the same bitrate. And it might be that no vendor even bothered to implement cut-through for mixed bitrate scenarios.– kasperdCommented Jan 8, 2019 at 14:12
-
2@Kasperd Cisco, for their Nexus 3000 series, claims "cut-through" for identical speeds and speed-stepdown scenarios (40G--> 1/10G), but not for speed-stepups (1/10G -> 40g) . cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/… Commented Jan 8, 2019 at 14:29
-
@kasperd & Marc'netztier'Luethi - Absolutely, thx. Cut-through with stepping up is impossible since you quickly run out of data (unless you now the frame length which you don't).– Zac67 ♦Commented Jan 8, 2019 at 18:12
-
@Zac67 The length is known on some frames but not on all frames. (And after reading how that works I am sort of regretting looking it up in the first place.)– kasperdCommented Jan 8, 2019 at 19:02