Download your favorite Linux distribution at LQ ISO.
Go Back > Blogs > Musings on technology, philosophy, and life in the corporate world
User Name


Hi. I'm a Unix Administrator, mathematics enthusiast, and amateur philosopher. This is where I rant about that which upsets me, laugh about that which amuses me, and jabber about that which holds my interest most: Unix.
Rate this Entry

Architecture of a switch

Posted 07-02-2018 at 10:25 AM by rocket357

I was setting up smokeping in a docker container on a recently-repurposed machine on my home network, as I recently downsized from a Cisco 3560 core switch to two Ubiquiti US-8s (primary reasoning: the US-8 handles vlans like a champ, and I can run them both on my battery bank with a lighter wattage impact than the 3560). Smokeping was reporting some odd numbers which illustrates a quirk about switches/routers designed for management purposes, so I thought I'd write here about the effect and what it means. (Note, the same phenomenon could be observed on the 3560, albeit to a lesser extent).

First, let's start simple. Two devices on the same subnet/vlan on the same switch. Smokeping reports the following times:

smokeping server to fileserver: ~200 usec average
smokeping to US-8 switch: ~1.2 ms average

Ok, traffic from smokeping traverses the US-8 to get to the fileserver, so how can it take 6 times longer to get to the *switch* than it does the fileserver?

Before I answer that, let me also state that the same can be seen on both of my ISP links. I have hard-coded to route across ISP1's link, and hard-coded to route across ISP2's link. Both are pinged, along with the modems and gateways the ISPs have provided. On *both* ISPs, I see ~750 usec to my edge router, ~1.3 ms to the modems, ~12 ms to the gateways, and then ~10 ms to and ~8 ms to Are my ISPs pulling the wool over my eyes?

Actually, managed switches have something dumb switches don't...a control plane (both have a data plane, of course, to handle traffic that traverses the switch). The control plane is where the switch's IP "resides", and is responsible for responding to pings directly to the switch/router. Most switches have ASICs in place that perform MAC lookups and "switching decisions" very rapidly, meaning packets going *through* the switch take the fast path to their destination. Packets that target the switch itself, however, have to be handled by the control plane, which tends to be very underpowered (to that point, how often do configuration changes take place on switches? Usually they get an initial configuration, then perhaps a port gets adjusted here and there as services are added and removed from the network topology).

The answer here (aside from the possibility that my ISPs are being "less than honest") is that the data plane and control plane operate at different "speeds".

So next time you run a traceroute and see a single hop with high latency or dropping packets, don't jump to the conclusion that the single hop is causing the observed network issue (packets that exceed TTL are handled by the control plane). If the packets **after** that hop are dropping/high latency as well, *then* you can make that claim.

Hope that helps clear up a bit of confusion on a common topic seen in networking =)
Posted in Uncategorized
Views 1642 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 08:30 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration