Tested: VLANs in the Home Through “Dumb” Switches

Being someone who has used consumer gear for a long time, I’ve always been rather frustrated at their inconsistent or general lack of support for VLANs. Long used in corporate networks, the VLAN concept can be extremely useful for realising unusual redefinable network topologies without needing to make physical modifications to cabling or installing extra hardware.

This month, I decided that my house needed to have VLANs to prepare for the future and to make my life easier by reducing the need to run extra cabling. But most of my gear is “dumb” … so will it even work?

What is a VLAN? Why YOU might need VLANs!

On a regular home Ethernet network, all packets are “untagged” and belong to the same network. You can think of any device attached to the Ethernet network as belonging to the one giant network – to have a second “independent” network would need to have a second set of switches or cables.

The term VLAN stands for Virtual Local Area Network and is a form of partitioning that is based on insertion of one (or two in a Q-in-Q configuration) four-byte 802.11Q tag into the packet header. The presence of the tag signals the packet as belonging to a VLAN (1-4094). This allows for up to 4094 independent VLAN networks to share the same physical network (depending on the hardware)! If you want two independent networks, you can – just set each to their own VLAN number. This works as the resulting frame is still a valid Ethernet frame, just with a different Ethertype.

“So what?”, I hear you say. The applications might not seem obvious, but there are good reasons you might need this:

  • Guest network separation – this is ideal for building a separated wired network segment for equipment that guests (or untrusted computers in quarantine) might use that won’t have access to your main equipment. Combine this with Virtual APs to extend the VLAN concept into Wi-Fi without needing VLAN over Wi-Fi support (which is rare). This is more flexible than the wireless-only guest network of your average consumer AP.
  • Control equipment separation – IoT equipment, sensors, surveillance require stable bandwidth and high priority connectivity while needing to be protected against unauthorised tampering or scanning. Using VLANs can both protect your IoT from local attack and prevent local network devices from being compromised due to IoT vulnerabilities.
  • High priority Voice over IP – for similar reasons, you might want to run VoIP over a separate VLAN to avoid performance degradation from excessive broadcast network traffic and to apply QoS prioritisation.
  • Not enough cabling/cost savings – perhaps you have a distance to span where bandwidth is not an issue but needing to keep two independent networks is necessary – e.g. to extend WAN to a router and the routed local network back to the point of connection. Using VLANs would eliminate any need to run dedicated cabling for each network – if later, more cable were to be installed, VLANs could allow for bandwidth sharing of both cables in a team.

But … What About?

However, as nice and simple as this sounds, VLAN support in consumer gear is sparse and there are many ways you can break a network. Routers which aren’t VLAN aware will make creating the desired network architecture difficult – luckily for me, Mikrotik stuff is here to save the day and if not, there are also various Linux possibilities. The next problem is at the “edge”, where the endpoint gear may not be VLAN aware.

Many computers running Windows using cheaper Ethernet chipsets are only capable of running a single VLAN at a time – the main exception is Intel Advanced Networks Services capable adapters. The situation in Linux is much better, given proper driver support, but in this case, the VLAN is based on configuration, so there can be a potential for misconfiguration and security problems. There are many appliances (e.g. DVR, NVR, Gaming Consoles, SIP ATAs) that are connected to the network that have no such support.

The traditional way around this is smart switches which are VLAN aware. Smart switches would be configured with a “trunk” port where VLAN tagged frames are aggregated and forwarded and access ports which are members of one or more VLANs (depending on the unit). This scheme is known as port VLAN – the smart switch takes care of tagging and un-tagging the frames, so non-VLAN aware devices can communicate as normal. This also can enhance security when configured correctly – preventing devices from VLAN hopping by accepting only untagged frames and enforcing the tagging in a consistent manner. Unfortunately, smart switches are generally pretty expensive.

The VLAN system also doesn’t work so well with Wi-Fi adapters – while the frames are valid Ethernet frames, most Wi-Fi adapter drivers don’t support configuring VLAN IDs. Luckily, we can use Virtual APs to overcome this issue, broadcasting a separate SSID from the same radio, sharing the same channel, to access individual VLANs.

While pondering about this, the solution to the problem seemed somewhat obvious – running a pure VLAN-based network makes life with cheap equipment difficult and upgrading all my equipment was not a realistic proposition. The answer would be to run both VLAN and untagged traffic together – this is known as a hybrid trunking port. While this arrangement isn’t ideal from a security standpoint as it doesn’t protect against VLAN hopping, it should still allow me to reap the benefits of VLAN-based reconfigurability and partitioning where needed, deploying the necessary smarts only at those locations where VLAN access is needed.

There was only one catch – the 802.11Q tag adds four bytes to the Ethernet packet. This results in the regular Ethernet frame of 1538 bytes being stretched to 1542 bytes – a baby jumbo frame. These frames are in violation of regular Ethernet and consumer equipment isn’t VLAN aware so a number of possibilities can happen:

  • Equipment receiving such long frames can truncate, drop or discard the frame – if this is a switch, then connectivity to the VLAN will be problematic when packets with payloads of 1497-1500 bytes are sent as FCS errors are likely in the case of truncation or packet loss in the case of drops. If this is an end device intending to access the regular network (untagged), this should be of no consequence.
  • Equipment receiving a 802.11Q tagged frame can mangle the tag – this will possibly result in tagged frames being corrupted causing VLAN connectivity problems or VLAN to VLAN separation to be breached.
  • Equipment receiving such long frames can crash – this may happen if there are fixed length buffers and an overflow was not tested for.

Before I can go to a VLAN arrangement, I will have to test my equipment to see how it behaves. Even for a simple question such as whether “dumb” switches would pass VLAN-tagged frames, there was no consensus online with some suggestions of “catastrophes”, so I decided it would be easier just to test it.

Testing it Out

To test out the system, I added two VLANs to my hAP ac running upstairs on the main upstairs-to-downstairs link (now a hybrid trunk carrying untagged and two VLANs). These two VLANs emerged out of two ports on the hAP ac which were configured as port-VLANs connected to a Raspberry Pi each configured with a different static IP/subnet combination and a DHCP server.

This link was first terminated into the hAP mini to bridge into each of these two VLANs via the two remaining ports (i.e. simulating a port-VLAN based smart-switch). I tested using my laptop connected into each of these ports to check that I could get the corresponding IP address as expected (i.e. network separation was correct). I then tested passing the maximum ping packet with don’t fragment to another endpoint on the two VLANs to ensure the packets would pass without errors.

The maximum ping with don’t fragment is 1472 bytes – after some confusion and lots of calculation, it seems that many people calculate packet sizes differently depending on which layer they’re talking about and whether they’re talking about the whole Ethernet Frame or not. Regardless, a 1472 byte ping packet has a 1500 byte payload due to 28 bytes in the ICMP header. From there, adding the 14 byte Ethernet Header, 4 byte Frame Checksum (FCS), 8-byte Preamble and Start-of-Frame Delimiter (SOF) and 12-bytes Interpacket Delay (IPD), we arrive at the 1538 byte “maximum Ethernet frame” figure. When a single layer of 802.11Q is added, this expands to 1542 bytes.

This initial test was successful, indicating my configuration was correct and VLAN-to-VLAN separation was maintained without disrupting the untagged network thus far. Then I connected the trunk into each of the dumb switches in my collection and connected the hAP mini to an output and repeated the experiment.

TP-Link 8-Port Gigabit v7 TP-Link 8-Port Gigabit v8 D-Link 5-port Gigabit Rev. D1 Trendnet TEG-S50g Green 5-port Gigabit Skymaster 5-port Fast Ethernet Netgear DS104 Dual-Speed 10/100 Hub

To my surprise, and my delight, all the equipment seemed to pass VLAN tagged frames without any issue – the frames came out without being truncated or mangled. This means that it is actually safe to run VLAN tagged frames through dumb switches.

For the newer Gigabit switches, this is implicit due to their support for Jumbo Frames of 9KB-16KB. A slightly oversize frame is no drama for a switch that can handle this. The only question is whether its “smarts” will cause the tag itself to be mangled, but as far as I can tell, none of mine were bothered by it – although my Skymaster seemed to be a bit slower in forwarding the frame compared to the others.

For older equipment, I expected problems but I was pleasantly surprised. Part of the reason seems to be that packet length enforcement is not that strict. In older equipment, the unit would cut off equipment that was creating excessively-long transmissions to prevent tying up the media – this was known as Jabber. However, the jabber mechanism is not precise to the length of the Ethernet frame – the shortest time from Wikipedia seems to run from 25kbits which would correspond to a frame of 3125 bytes (!!) which is still much longer than the VLAN-tagged packet. The restriction will probably be whether the clocks in these units are stable enough over the longer period to decode the complete frame correctly.

Encouraged by this, I connected the hybrid trunk to my regular switch and slept soundly in the knowledge that I have VLANs in the home, at last!

My (Simplified) Network

The above (messy) schematic shows a simplified version of the present network and the main motivation for the VLAN investigation – my current router is located upstairs on the floor to be most central to the house. This places it in a location high-enough to have even visibility of the whole house, without being so high as to interfere with others and receive interference from others. In my previous investigation – at the front of the house and at the rear, the signal was a generous -55dBm, validating its position as being optimal.

The reason for it being upstairs is because of my primary WAN being a USB 2.0 connection to a tether mobile phone – this link is necessarily limited in distance due to voltage drop and signalling. By positioning the phone up high, my signal to and from the LTE BTS is improved, ensuring I get better data rates at all times.

Add to this, my current back-up WAN is based on a long-range Wi-Fi link to a Telstra Air/Fon Wi-Fi AP which I rely on to activate new SIMs or for larger software updates to avoid exhausting my LTE service. This is a secondary network which I run on a separate subnet – running this downstairs through VLAN rather than requiring all devices connect via Vitrual AP would reduce noise on the Wi-Fi channels, reduce radiation exposure and improve reliability of the link.

Because of having some legacy gear and untrusted stuff, a third VLAN was desired just to connect this untrusted stuff for “guest” use. This way, any worms or nasties would not propagate to my main machines. But they still needed access to the internet in some way – having the ability to dynamically “cut them off” at the click of a button and/or rate limit them via queues is a definite advantage.

Then I decided I was going to run some telephony at home as well – I miss having my old Asterisk server, so a voice VLAN would be nice to reduce needless broadcast traffic from affecting my (rather underpowered) SPA112 ATA.

With all of this going on – I only had one 30m Ethernet cable to run from upstairs to downstairs. Ethernet cables are cheap but if I had to buy another three … not to talk about how ugly that would look as well! VLANs to the rescue!

In this configuration, all of the “dumb” devices access the network “untagged” as that’s the only way they know how. My RasPBX and ATA do so through an hAP mini which tags them to the voice VLAN. Because my main desktop has an Intel ANS capable card, I am able to create virtual interfaces for each VLAN and untagged LAN as well. This way, I can unbind most protocols from the VLANs and bridge them into virtual machines so I have an isolated way to access/administer/diagnose devices on those VLANs (save for a VM escape attack).

But the biggest reason to have it configured this way is to prepare for the eventual arrival of HFC NBN. As the outdoor demarcation point is now installed, it comes into the ground floor of the house in a corner. If I request them to install the HFC wallplate anywhere in the house, they will very likely do an ugly surface conduit run of the cable which is a mess. Instead, if I ask them to do a back-to-back, they might be happy (at the easy work) and the result might be a bit prettier but the CPE will now be at a bad location. So I decided that I could dedicate a VLAN to the Ethernet from the CPE by using a smart switch configured as Port VLAN (the TP-Link SG105E isn’t expensive and can definitely do this) – then it can patch using a shorter lead into my existing network on a less-ugly cable route. This can also allow for another guest network access port. Of course, now all the WAN traffic will go up the hybrid trunk/access line and most of it will come straight back down (wasting bandwidth, but there’s usually no contention – 100Mbit/s WAN + ~300Mbit/s 802.11ac file-copy is still <50% utilisation) but I can maintain just one router in the network and its good vantage point.

Alternative solutions can include:

  • Ethernet over Power – but as I like listening to shortwave, I can’t handle the interference. Add to that the fact it’s expensive and slow.
  • Dedicated Ethernet from here to the router – but that’s both expensive and unsightly just stringing cable around as I normally do.
  • Wireless Bridge – definitely a possibility, but latency, packet loss trade-offs, additional Wi-Fi radiation and channel congestion are something I’d rather avoid
  • Second Router near the CPE for WAN gateway- I do have an hAP ac² so that is a possibility, but why waste another router when you don’t need it? I don’t even need a better wireless signal!

The diagram itself is a little misleading, as the hybrid trunk is connected to a dumb switch, which really doesn’t enforce any port being a member of a particular VLAN or doing any tagging/untagging. This is both a blessing (meaning all ports can join all VLANs) and a curse (meaning all ports can inject traffic to other VLANs/participate in VLAN hopping). At home, this security compromise seems acceptable – after all guests/secondary WAN/voice VLAN users will be behind port-VLAN devices, they won’t be able to attack the untagged/other VLANs. It’s moreso that the untagged users may accidentally join a VLAN if they are misconfigured and that would be my fault entirely.

Conclusion

It’s unfortunate that more consumer gear doesn’t have VLAN support, but it can be quite useful to realise rather special network topologies and save on cabling hassle where sufficient bandwidth already exists. Discovering that tagged traffic runs just fine intermixed with untagged traffic even though older switches was a blessing, that allows me to add in VLANs to my network “transparently” – only those devices that need to access the VLAN have to be connected to an intelligent smart-switch or similar device (or have their VLAN settings configured appropriately if possible). The rest of the devices on my network operate as if nothing had changed – I haven’t noticed any strange behaviour and the switches seem to be moving traffic about as expected (no constant all-port floods, loops, etc).

With the emergence of cheaper smart switches (and the potential that other switches can be modified to gain VLAN tagging facilities), it may herald a new era where VLANs start to become more common in the home.

Posted in Computing, Telecommunications | Tagged , , | 2 Comments

Tested: EDUP 11AC 1900M Dual-Band USB 3.0 Wireless Adapter (EP-AC1621)

In my quest for more wireless throughput, my hAP ac with three-stream 802.11ac wireless seemed to be the right choice. The problem was that I had absolutely no three-stream capable equipment to use with it – so I wasn’t seeing any of the benefits of that third stream. In my case, maybe I should’ve gone with the hAP ac² instead and saved the money?

So I thought I’d get myself a three-stream device just to test – hopefully one that would be a bit less problematic under Linux than the previous 802.11ac USB adapters I’ve tried. After some searching, I found some very expensive options available locally – about AU$120 which was just downright unreasonable. At that price, I’d just buy another hAP ac and use that as the adapter …

So I settled for a Chinese alternative – the EDUP EP-AC1621 for AU$45 posted after stacking all the discounts I could find. Lets see if it was worth it …

Unboxing

The unit comes in a colour print retail cardboard box. The front has an image of the adapter with its four antennas attached, making for an “imposing” half-octopus. I’ve got to wonder how well this works, especially given how closely those antennas are spaced.

The rear of the box gives the model as EP-AC1621, listing the specifications. Interestingly, it lists itself as “Draft 2.0”, which makes it sound like a pre-standard adapter. It claims support for up to 80Mhz bandwidth, although the claimed 1300Mbit/s throughput is at odds with its claims of 4T4R MIMO. In fact, it is technically a 4×4:3 – only three chains can be active at any time despite having four antennas. This isn’t necessarily a bad thing – it should be better than a 3×3:3 as it has an “extra” antenna to capture some more signal. The transmit power is 15dBm in 2.4Ghz and 12dBm in 5.8Ghz making it a little low. I wonder if this is a per-stream or total power output. There is also some strange English with the use of the word “Synchronization”.

When you open the box, you are greeted by the adapter inside a plastic tray.

Below the tray is the remainder of the accessories, including four antennas, the USB cable and driver CD.

The USB cable is especially thick and stiff, which makes it pull the adapter about. There is also a Quick Installation Guide hiding below the CD.

The adapter itself feels light and hollow. It features a glossy plastic exterior with a simple design incorporating an LED window on the top and RP-SMA connectors along the sides for the antennas. There is a microUSB3.0-B connector for power and data at the bottom, but the unit is otherwise featureless – no feet so it happily slides around.

Assembly is easy – unwrap the antennas and screw them in for your “half-octopus”. The orientation of the antennas may need some tweaking though, to maximise stream-to-stream orthogonality. Interestingly, these antennas are the same units provided with my “generic” AC1200 adapter.

Installation

The driver CD contained an outdated version of the driver:

Downloading the latest version from here, it was a simple task to run the installer and connect the unit and it was up and running. The VID is 0BDA and the PID is 8813.

Due to the RTL8814AU chipset in use, it’s slightly less sucky for use with Linux. Drivers can be found online from a number of places, however, it seems I’ve had success with zebulon2’s version. There is also a version from aircrack-ng that supports monitor and packet injection, however, I did find some instability especially on a surprise unplug.

Throughput Tests

Throughput testing was conducted using a server connected on the Gigabit Ethernet segment of the network, serving a 4GiB random-fill file over a network share. The adapters were connected to a Lenovo E431 laptop running Windows 10 through its USB 3.0 ports, while maintaining AC power connection to the charger to avoid Wi-Fi energy saving performance impacts. The network share was mapped to a drive and Cygwin was used with dd to read the file using 16MiB block size to /dev/null. The reported file throughput was used to compute actual data throughput, taking the average of three transfers. At the server, a regular process running in Cygwin “touch”-ed the random file at one second increments, invalidating any file caches on the test laptop. While iperf is generally regarded as most reliable, I found that in all cases iperf3 reported similar readings but often around 2-5Mbit/s less possibly due to its less aggressive transfer behaviour.

The throughput tests includes testing of:

Testing was based on a Mikrotik hAP ac which was serving a “live” network with other users and hAP ac² at close range only, serving a dedicated “best case” 802.11ac-only network.

The results are somewhat confusing, so lets break it down somewhat:

  • The test protocol worked, with direct GbE connection providing a reading of 954Mbit/s – close enough to the 940Mbit/s expected and is probably down to the timing errors in the dd method and rounding error of the throughput.
  • Throughput in the ideal case with the hAP ac² (supporting two spatial streams) showed all three 802.11ac adapters performed similarly, which is not expected. The single-stream USB 2.0 based TP-Link T2UHP managed to provide 268Mbit/s download, whereas the “generic” AC1200 two-stream managed 276Mbit/s and the three-stream EDUP managed 278Mbit/s. Ideally, we would expect throughput to scale (nearly) linearly with the number of spatial streams, assuming that stream-to-stream orthogonality could be maintained, thus I expected the two and three stream adapters to be able to do double of the single-stream.
  • Spot-checks seemed to show that the Broadcom two-stream 802.11ac adapter performed similarly to the single-stream TP-Link TP-T2UHP, whereas the Intel Wireless-AC 8265 was able to exceed all others even at a distance in the house.
  • I suspected USB overhead and poor drivers or chipsets may add a limitation to the achieved speed, so I tested two USB Gigabit Ethernet adapters on the Lenovo E431 using the USB 3.0 port, which was only able to achieve 320Mbit/s under the same benchmark. While this is faster than the 802.11ac, it is a long way from 1Gbit/s.
  • I verified that the hAP ac² was able to operate in two spatial streams and hAP ac was able to operate in three spatial streams to the respective adapters. Physical layer rates reported were 433.3Mbit/s for a single stream, in excess of 650Mbit/s for two streams and 975Mbit/s for three streams.
  • I expected to see something close to ~500Mbit/s in triple-stream mode and closer to ~350Mbit/s in dual-stream mode. This suggested some possibility of limitations in throughput in the Mikrotik equipment or in the compatibility between chipsets. To check this, I ensured the routers did not saturate their CPUs (they didn’t – utilisation < 50%) and tried from Mikrotik hAP ac to Mikrotik hAP ac² in bridge mode and was not able to increase the throughput over the USB adapters even at close range.

Looking only at the 802.11n/ac comparison dataset on the hAP ac:

  • It is clear that 802.11ac trounces 802.11n throughput, as expected. In some cases, throughput was close to double whereas in extreme cases, the throughput even was close to triple.
  • The single stream T2UHP is at a disadvantage compared to the others, recording slightly less throughput. This is likely due to its single-stream nature and USB 2.0 connectivity. However, despite this, it is always capable of providing better results than a dual-stream 802.11n solution (!!).
  • The unbranded generic AC1200 adapter does provide solid results, until the signal gets weak outdoors where its performance degrades to that of the single stream. This was as hypothesized in the review due to the second “vestigial” antenna. For the price, the performance is quite solid.
  • Peak recorded 802.11ac throughput for the EDUP was 273Mbit/s at close range with the hAP ac, equivalent to the two stream adapter despite being connected with three streams.
  • However, while there was no real throughput advantage with my combination of equipment at close range, at long ranges, the advantages were clear, offering about twice the throughput in the garden as the single-stream and “one-and-a-half” stream solutions. Outdoors, it was able to offer almost four times the throughput of the dual-stream 802.11n solution.

Part of the reason for the rate differences may be due to differences in antenna gains and transmit powers – while the T2UHP was able to achieve maximum MCS for the single stream at close range, the other adapters never achieved the maximum MCS at any distance. This may mean that their signals were not separated enough, the transmit signal was unclean or weak. The Realtek-based cards do not boast high transmit powers – so this may indeed be part of the reason. There may have been differences in compatibility as well between beamforming techniques. Despite this, there is another advantage of higher spatial streams – even if single-client throughput is not improved, the airtime occupied by transmissions should reduce as a function of increased physical layer rates, leaving more airtime for other clients to use. The net “system” throughput should still increase.

Further research of the expected throughput from 802.11ac solutions provides varying reports of speed – this test with an Asus RT-AC68U (four-stream) showed close-range throughput of 230-310Mbit/s (with the exception of one adapter that provided 404Mbit/s). This test by Anandtech found throughput averages which ranged from 158-464Mbit/s at close range. Another test by TBG for an intermediate distance found data throughputs ranging from about 227-342Mbit/s.

In that perspective, while the results were not at the top end of the range, it wasn’t at the bottom either. While some people have been able to achieve even higher throughputs in practice, the likelihood of this happening with “random” low-cost consumer gear seems unlikely and it may boil down to running multiple transfers concurrently.

Teardown

The plastic case is held together with clips internally that are difficult to separate without breaking. As a result, I don’t recommend taking apart the adapter as the casing will likely be partially damaged.

The board inside doesn’t occupy the whole case, instead having some clearance from the sides. The rear has some power conversion (switching) circuitry, a reference oscillator and some passive SMD components.

The opposite side features the RTL8814AU chipset, with a Skyworks SKYT85703-11 front-end module per port. The module is specified for up to 16dBm @ 1.8% EVM at HT80, MCS9. The PCB seems to have provision for a hardware WPS button that was not fitted. The USB 3.0 filtering seems to be strangely located too – one set near the chipset, the other near the connector. Much of the PCB (marked UMB814A03-3V3, dated Week 40 of 2017) isn’t strictly necessary, it seems, so the adapter could have been much more compact.

It seems that the top indicator would have functioned as a WPS button as well, but it is secured into place just as an indicator.

Conclusion

While it’s possible to buy a triple-stream 802.11ac adapter for less than the local shops might have you pay, it seems that the combination of equipment you use (e.g. laptop, adapter, access point, etc) can result in rather unusual results. In my case, through multiple tests, it seemed that the triple-stream adapter didn’t offer a big advantage over the dual-stream adapter in terms of maximum throughput where the signal was strong. Its main advantage was in weaker signal areas where it could maintain a higher throughput, suggesting there was some limitation with the AP (potentially), testing scenario or compatibility issue.

Despite this, the triple-stream adapter did connect with higher PHY rates, which should reduce air-time usage, allowing for an improvement in overall wireless system throughput. It also does have better Linux support than the ones I tested before, although it isn’t quite as stable as adapters from the 802.11n generation nor is it as convenient as it hasn’t been mainlined. The unit uses the same Realtek RTL8114AU chipset as in much more expensive units (e.g. Asus USB-AC68 ($99), D-Link DWA-192 ($89), Netgear A7000 ($99), TP-Link Archer T9UH ($79)), so it’s likely that I could have paid almost twice as much to end up with the same results.

However, as there wasn’t any gain in maximum throughput, it seems that the two-stream AC1200 solution was probably the far better value for money option depending on your needs. After all, most smartphones only ship with single-stream (or at most, dual-stream) solutions and most laptops are restricted to two streams. Triple and quad stream solutions still remain a niche category – along with commanding a higher price tag.

Posted in Computing, Telecommunications | Tagged , , , , , , , , , , | Leave a comment

Teardown: D-Link DGS-1005A 5-Port & TP-Link TL-SG1008D 8-Port Gigabit Ethernet Switch

After bathing in nostalgia looking over my old switch and hub, it’s time to come clean – there’s a place for Fast Ethernet and that was a number of years ago.

While some of the old equipment might still be serviceable and good enough for some applications, it can’t keep up with the likes of Gigabit Ethernet when it comes to bulk file transfers. Even Gigabit feels slow in an era with relatively copious SSD storage, so I thought it was a good time to get my hands on two cheap Gigabit Ethernet switches to expand the home network. Then I thought, why not take a peek inside and put up a teardown?

D-Link DGS-1005A 5-Port

The first contender comes from D-Link, the DGS-1005A 5-Port Gigabit Easy Desktop Switch which costs just AU$17. For that price, the box seems quite elegant with rather colourful design. This particular unit is hardware revision D1 and is Made in China.

The box isn’t very large at all, with the device pictured on the front. The blurb isn’t particularly inspiring – which is expected.

The unit seems to come with two years of warranty which can be upgraded to three if you register your product (and hand over some personal details, I suspect). I don’t think I’ll be needing that. The feature-set is pretty standard for modern switches – support for Energy Efficient Ethernet (EEE), 10Gbit/s switching fabric, auto-crossover, auto-negotiation, flow-control, store-and-forward architecture supporting 9720 byte jumbo frames.

Inside the box, you get the power adapter, the switch unit and some paper.

The unit has a glossy plastic finish with the brand moulded into the case on the top. The top shell is white with the bottom shell being a light grey.

The front shows the indicators for each of the Ethernet ports and power. The ports are accessed through the rear, with an all plastic Ethernet jack which won’t ground any STP cable. This is not unexpected since the adapter has no physical ground connection anyway.

One side is blank, with the other side having the DC barrel jack for a 5V 1A input.

The power adapter is branded D-Link but is made by Leader Electronics Inc. It’s certified for Australian use and resisted my squeeze-attempts at cracking its case open, so lets just take a look inside the switch.

The case is a screwless design, which can be unclipped from the sides. The top half shows some clear plastic being used as light-pipes for the indicator LEDs – when operating, the LEDs also shine through the top side of the case due to the low opacity of the plastic.

Judging from the PCB design, it seems that this same PCB is the heart of two other models – the DGS-1005D 5-Port Gigabit Unmanaged Desktop Switch and the DGS-105 5-Port Gigabit Desktop Switch (Metal Housing). For those other housings, we can see the dual-footprint LEDs which can accept bi-colour LEDs, and C32/C33 which allows for capacitive coupling to ground. Rather interestingly, the unit uses a Broadcom BCM53125 switch chip, which seems to be quite a capable unit especially because it’s used in a number of consumer routers as well as the Banana Pi R1. There is an FM25F005 512Kbit SPI Flash memory and 25Mhz clock crystal. One particular upside is a complete lack of electrolytic capacitors which can be failure-prone. Another is the use of two LEDs per port – green indicating gigabit, amber indicating 10/100Mbit/s.

The underside doesn’t have much on show, although L3 on the underside suggests that U2 is a switching DC to DC converter to derive the lower voltage for the switch chip in an efficient manner. The board is marked 8GS1005A.1D1G and GS1005A.

I dumped the flash memory and it seemed quite large for something which is practically a fixed-function device. Looking for some text, it seems that there might well be an operating system of sorts as suggested by “Too many tasks! ..\..\..\src\kernel\background.c”. The dump along with the dump from the next switch can be obtained here.

TP-Link TL-SG1008D 8-Port

Not to be outdone, TP-Link offer the TL-SG1008D 8-Port Gigabit Desktop Switch for AU$26, in a box that is distinctly colourful as well. This one claims to come with three years warranty with no registration requirement.

The front shows the unit, which has a curvy appearance like their older versions.

The bottom side has some multilingual description text and device serial number. The hardware revision is 8.0 – my other switch on my desk at the moment is the older 7.0 version which I didn’t post online due to my haste in getting it into service.

Again, the feature-set is quite similar with a non-blocking 16Gbit/s switching fabric, DSCP QoS ability, EEE support, auto-crossover, auto-negotiation and flow control.

One of the key differences is support for 15KB jumbo frames.

Switch, power supply, paper. I think I spot a pattern here.

More glossy plastic, this time in black. Just one LED on the front – the power LED.

Each port instead has its own LED in the rear, integrated into the port housing, which is also plastic and won’t provide any ground connection for STP cables.

Unlike the other unit, this unit is secured by two screws. Regardless, it’s still very light and plastic-feeling.

The unit comes with a power adapter which is rebranded. The OEM is not known, but in the past they had their brand moulded into the rear of the casing – this is not the case with the V8.0 revision. The voltage used is 9V at 0.6A, a common standard amongst TP-Link equipment but slightly less common than 9V or 12V equipment.

After the screws are removed, the case still holds firmly together because of a number of internal clips.

It opens from the underside, where we are presented with a slightly non-square PCB which cuts very closely to the holes on the edges. Silkscreen is used to keep solder connections from potentially bridging, but there is nothing mounted on the underside.

Everything is mounted above, including a pair of switching converters to generate the necssary voltage rails for the switch chips, four two-port magnetic transformers, the switch chip, an LED for power and an STMicroelectronics 24C08WP 8kbit EEPROM. Unfortunately, with the heatsink secured firmly to the chip, there was no way to get a good eye onto the chip, but judging by the legs that show, I’d guess it’s probably a Realtek of sorts.

The input has one Taicon electrolytic capacitor, which is probably slightly less desirable than having none, but seeing as it’s only filtering the DC input as bulk capacitance and not being driven hard by the output of the switching converters, it should not be an issue in the long run.

The dump of the EEPROM along with the dump of the Flash from the previous switch can be obtained here. In this case, it isn’t particularly big (that’s all the data) but it’s probably just a list of register values which doesn’t make sense without having access to the programming data for this particular chip. But it does suggest that these switches are more featureful than they are sold as.

Why Upgrade?

“If it ain’t broke, don’t fix it” is a mantra which some people follow. Given that some networking gear lasts almost forever and basic switches are practically “dumb” devices, why would you bother to upgrade if it works just fine? Well aside from potentially being more reliable, there are three major reasons I can think of.

Higher Throughput and More Ports

The main reason for my upgrade is to ensure I get more throughput especially as most of my devices have a Gigabit port already. Having more ports around the house is handy as well, as the number of devices grow and my insistence on avoiding Wi-Fi to ensure better reliability and save the “shared” Wi-Fi bandwidth for devices that really need it. It might also reduce electromagnetic radiation exposure as well.

Jumbo frame support is also something that can improve throughput by reducing overheads, although jumbo frames are rarely ever used as the whole network must support a homogeneous frame size to ensure communication is trouble-free. As a result, 4K, 8K, 9K, 15K jumbo frame support is mostly meaningless to home users who don’t run a homogeneous network that supports such large frame sizes, as we would mostly stick to the Ethernet standard MTU of 1500 bytes (payload) or 1538 bytes (physical link layer).

Lower Power Consumption through EEE and Better PSUs

As the units advertised Energy Efficient Ethernet (EEE) support and “green” abilities with a mark VI power supply, I wondered if it’s worth upgrading purely to save energy and money. As a result, I pitched the Skymaster 5-port Fast Ethernet switch against these two in an idle power no-links active power consumption test, as usually the “idle” power overhead is a significant minimum energy consumption case.

Using my Tektronix PA1000 Power Analyser and synthetic mains source, I determined the standby no-link-active power consumption of the units and computed the energy savings.

Indeed, the newer switches are much more efficient on power, but at the current rough cost of electricity, it would take around three to five years to pay off the cost of the switch in energy savings. This still makes it worth adopting as it’s “about break-even” but it’s not exactly an incentive if not for the other features a new switch would bring.

Swapping in an old TP-Link switch-mode power supply to substitute for the linear supply originally with the Skymaster, the usage fell to about 1.1949W, so about 1.3197W of energy can be saved purely by switching to a more efficient power adapter. That was rather surprising, but still, the Skymaster was consuming about twice as much power and providing slower service.

Better Switching Fabric, QoS DTCP Priorisation

All but the earliest switches have a store and forward architecture with non-blocking fabric. This means that any pair of ports can communicate at full speed, in both directions at all times – which is how a 5-port switch has “10Gbit/s” fabric and 8-port switch as “16Gbit/s” fabric. It seems unlikely that you would still be using a hub or early switch without these features, but in case you are, an upgrade might be useful. However, it’s very improbable that most homes with maybe one or two servers and mostly clients would choke up the switch fabric of an older switch.

However DTCP QoS prioritisation may be important, especially when a higher speed link is talking to a lower speed link and the output queue for the slower link becomes full. This allows the switch to intelligently choose to drop packets of lower priority to maintain quality of service, but this relies on the packets being correctly tagged in the first place. Unless your links run at high utilisation, this shouldn’t be too big of an issue.

Conclusion

Basic unmanaged switches are almost as boring as toilet paper and the blurb on the box seems to confirm this. The list of features reads like a car brochure telling you it has wheels, but that’s no problem, because that’s exactly what you need. These switches seem to target the “lowest cost” consumer segment and the plastic build is consistent with this. They do the job well enough for basic home use that there really isn’t much to complain about given the price. While we don’t know for sure if they’ll last (some power supplies are prone to failure), I’ve used TP-Link units from multiple versions back and they’re practically bulletproof.

However, a look inside shows that these switches do have some memory for configuration, suggesting the switch chip is actually more capable than just a basic switch. It seems quite likely that they might have some configurable VLAN tagging/untagging abilities, configurable queueing, possibly even rate limiting and configurable loop detection abilities. Unfortunately, without knowing the chipset and the exact format of the EEPROM/flash data, it won’t be possible to unlock these abilities, but it does explain why there are some cheaper semi-managed switches beginning to enter the market like the TP-Link TL-SG105E (which might well be something I end up getting sooner or later).

Even if you don’t need the throughput, maybe it’s still worth upgrading to save some energy with new energy efficient Ethernet standards and more efficient power adapters. The payback period may be 3-5 years for a basic switch, but you will save some electricity. If not that, then maybe the higher switching fabric bandwidth, store-and-forward architecture with QoS prioritisation in the packet queue and flow control support might help reduce packet losses for real-time applications compared to the earliest of switches and half-duplex hubs. The improved reliability of a new device may also be welcome.

Posted in Computing, Telecommunications | Tagged , , , , | Leave a comment