TP-Link JetStream 8-Port 10GE SFP+ L2+ Managed Switch Review

For quite a while now, I’ve been utilizing a Cisco Nexus 3064PQ 10G/40G network switch to support my home lab. While the switch is a fantastic, feature-rich device, it also was designed for use in a data center environment. Thus, the switch generates a lot of heat, utilizes a lot of power, and has cooling fans that sound like turbo jets when running at full speed. Luckily, the only time that the fans run at full speed is during a reboot of the switch, but even at their lowest speed, they are quite noticeable. So finally, after putting up with the noise for a few years now, I’ve decided to replace the Cisco Nexus 3064PQ switch with smaller, fanless 10G switches. My main requirements for a new home lab switch were passively cooled and fully managed devices that include features such as a full CLI, jumbo frame support, SNMPv3, sFlow, LLDP, and static routing.

I originally began looking at Ubiquiti Unifi 8-port Aggregation (USW-Aggregation) switches for $269 USD as I already utilize other Ubiquiti Unifi equipment within my home network, but I was disappointed with the lack of features. Max power consumption for the device is also rated at 30W, which is quite high for an 8-port device.

Ubiquiti also offers the Ubiquiti Unifi Hi-Capacity Aggregation (USW-Pro-Aggregation) switch, which does include layer 3 switching, but does not include any additional features. Additionally, the device costs $899 USD, which is much too expensive as I hope to purchase a minimum of two devices to allow for redundancy within the network.

Another option that I considered was the Mikrotik CRS309-1G-8S+IN Cloud Router Switch. This device provides eight 10G SFP+ ports as well as a single 1G RJ45 POE-Input port that can be used for powering the switch. The switch can be purchased for approximately $269 USD. The device appears to be quite capable when it comes to switching performance and advanced features; however, layer 3 routing performance appears to be limited by the device’s dual-core 800 MHz processor. Maximum power consumption is a bit lower than the Ubiquiti Unifi switch and is rated at 23W. Additionally, the Mikrotik devices are known for not being the most intuitive devices to configure and manage. While this would have been a viable option, I decided to purchase a different product.

I finally decided to purchase the TP-Link TL-SX3008F JetStream 8-Port 10GE SFP+ L2+ Managed Switch. This device features eight 10G SFP+ ports, an RJ45 serial console port as well as a built-in micro-USB serial console port. The device boasts a full CLI, an intuitive web-based management interface, and is supported for management within TP-Link’s Omada SDN solution. At $229 USD, this device includes a wide array of capabilities and is cheaper than both the Ubiquiti Unifi and Mikrotik devices. Additionally, the maximum power consumption is much lower than both the Ubiquiti Unifi and Mikrotik devices at 15.5W. While these switches have been working well, not everything has been smooth sailing. I’ll discuss some of the drawbacks shortly.

Initial Setup

Getting the TP-Link setup was a bit more work than I expected, although not horribly difficult. Each of the devices arrived with version 1.0 of their firmware, so the first step was to update them to the latest release. I initially attempted to connect my laptop directly to the switches utilizing a Cisco 1G RJ45 SFP. However, the switch would not form a link. I then tested out the connection utilizing a 10Gtek 10GBase-T SFP+ to RJ-45 SFP+ Transceiver that supports 1G/2.5G/5G/10G speeds. Luckily, with this SFP+ module, the laptop successfully established a 1G connection to the switch. After setting a static IP address on my laptop of 192.168.0.2, I could successfully connect to the web-based management UI on the default IP address of 192.168.0.1.

Authenticating to the web-based management UI is accomplished by utilizing the default username and password combination that are both set to “admin”. Upon first authenticating, the switch prompted me to provide a new password for the built-in “admin” account. After providing the new password, I was presented with the main status page, where I could then navigate to the firmware update portion and upload the latest firmware.

Firmware Updates

The firmware update process took approximately 5 minutes, and based on my input, the switch rebooted using the new firmware. It should be noted that the switch supports an active/backup firmware configuration that allows you to switch between two versions of firmware that have been uploaded.

Upon reboot of the device after the firmware update, I ran into my first issue. When I attempted to log back into the default, my credentials did not work. I then attempted to use the original default username/password combination of “admin”/“admin” and was successful. It appears that something between version 1.0 and 1.4 of the firmware caused the default administrator account password to reset to default. While not a show-stopper, it was far from ideal.

Now that I’ve worked with the devices for a bit, I’ve found that after you make any changes within the web-based management interface, you must tell the device to save the changes in order for them to be permanent. I wonder now if the issue with the updated password not saving was actually due to me not telling the device to save the configuration prior to the firmware update process. While this would make sense after using the device for a bit, it would not be obvious based on the login process prompting for the change and stating that it was successfully updated prior to ever providing access to the web-based UI. I would expect that a wizard-based process forcing the password update would also persist the password change to the configuration immediately.

Upon successfully completing the firmware update, I was then able to successfully connect the switch to my existing network using the Cisco 1G RJ45 SFP+ module that previously would not work. A reboot of the switch caused the device to pull a new management IP address via DHCP, which I then used for future configuration.

Management IP, Default Route, and NTP

My next step during the process of setting up the device was to work my way through the main page of settings which brought me to the NTP settings. I found it a bit odd that it had a couple of IP addresses assigned as the default and primary NTP servers. I also found it odd that the device had not yet pulled the correct time via NTP, even though it was connected to my network and had a functional IP address assigned via DHCP. This is where I encountered my next issues with setting up these devices.

Default Route

While the switch did receive an IP address from DHCP, it did nothing with the default gateway information provided by DHCP. The switch requires that you enter the Layer 3 configuration portion of the management UI and provide it with a new static route. The static route must be defined with an IP of 0.0.0.0 and a subnet mask of 0.0.0.0. These values make sense from a routing point of view as a typical means for defining a default route into a routing table, but why the switch does not set this value for you is a mystery to me. My guess is that the switch requires this as it doesn’t differentiate between a management network IP and any other layer 3 networks defined on the switch. In fact, the process to define a static management IP address is to again access the Layer 3 configuration, browse the Interfaces portion of the configuration and update the IPv4 address assigned to the VLAN 1 interface.

NTP and DNS

As I previously mentioned, the NTP configuration already had a couple of IP addresses assigned as NTP servers by default. I found it somewhat odd that they provided out-of-the-box values and that the values were IP addresses instead of DNS names. Typically, I point most of my devices to the NIST NTP server time.nist.gov, but I found that this was not possible as the form would only allow for the entry of an IPv4 or IPv6 address. It then occurred to me that I could find no location to provide DNS servers within the switch’s management UI. It turns out that the switch does not support DNS resolution at all. Becoming mildly annoyed by this, I decided to do reverse lookups of the two IP addresses provided. The first NTP server specified was 133.100.9.2, which is located in Japan. I could not get a reverse entry for this address. The second NTP server specified was 139.78.100.163. This IP address resolves to a reverse entry of used-to-be-ntp.okstate.edu! While not totally surprised to see a vendor utilizing a private NTP server as the default on all of their devices, I was still quite disappointed with TP-Link. Additionally, the IP address owned by Oklahoma State University no longer responds to NTP requests as you would expect based on the hostname assigned to the IP address.

Spanning Tree

The next configuration item I verified was the Spanning Tree Protocol (STP) configuration. To my surprise, STP is set to disable by default on the switch. Maybe it is my ignorance, but I would expect switches to have STP enabled by default to prevent networking loops when connecting new gear. Luckily enabling STP wasn’t difficult. You first must enable it by checking the “Enable” checkbox, and then you select the mode, which can be STP, MSTP, or RSTP. However, this simply enables the service on the switch. You must then go to the STP “Port Config” portion of the management UI for Spanning Tree and enable STP on a port-by-port basis. The STP “Port Config” portion of the management UI also allows you to define typical STP port options such as priority, costs, and defining ports as edge ports.

Security

The security portion of the switch management UI is where I found many of the issues that I see as shortcomings for this device. I will walk through each area.

HTTP/HTTPS

By default, the switch has HTTPS disabled and only utilizes HTTP. I feel that this is a poor decision on TP-Link’s part, as even utilization of a self-signed certificate would be better than leaving authentication and configuration of the device in clear text via HTTP. When it comes to disabling HTTP, you only have the option to disable it completely. The device does not provide the option to redirect HTTP requests to HTTPS. While this is technically not an issue, it would be a nice-to-have feature.

The default HTTPS protocol version configured is TLS 1.2, but TLS 1.1, 1.0, and SSL 3.0 are all supported. Why the device still includes SSLv3 support is beyond me, as it has so many vulnerabilities. When it comes to the cipher suites supported, by default, the device had ciphers based on MD5, SHA1, RC4, and 3DES enabled. Since these have all been shown to be quite vulnerable to exploits, they should be disabled by default. Luckily the device also supported AES 128 and AES 256.

Additionally, the devices allow for importing custom certificates allowing for the replacement of the built-in certificate.

Telnet and SSH

Again, by default, TP-Link went with the most insecure options and left Telnet enabled by default, while SSH is disabled by default. I quickly disabled Telnet and then began to enable and configure SSH. This is where I ran into more disappointment. By default, when enabled SSH, TP-Link chose to enable support for both SSH versions 1 and 2. Again, I’m not sure why they decided to leave support for SSH version 1 enabled or why they even provided it. When it comes to the encryption algorithms supported, TP-Link enables support for AES 128, AES 192, and AES 256. However, TP-Link also enables 64-bit block encryption algorithms, including Blowfish, CAST128, and 3DES. These have all been deprecated by NIST due to their use of the 64-bit block size.

As for data integrity algorithms, TP-Link unfortunately only supports and enables, by default, HMAC-SHA and HMAC-MD5. I’ve reached out to TP-Link regarding the lack of support for modern SSH data integrity algorithms and was told that it was on the roadmap for inclusion this year.

SNMP

SNMP configuration is another place where I found the security settings to be lacking. While the switch does support configuration of SNMP version 1, 2, and 3, when configuring SNMPv3 accounts, you are limited to MD5 and SHA1 for authentication and only DES for encryption/privacy. No choices exist for SHA2 or any form of AES encryption.

Compatibility

The biggest issue that I ran into when using SFP+ modules with a 10G switch is compatibility. In the case of this TP-Link device, it appeared at first that it would not support the 1G Cisco RJ45 SFP+ module, while it did support the module manufactured by 10Gtek. This issue was resolved after updating the firmware on the switch. However, I still ran into issues. I prefer to utilize Twinax passive copper cables when connecting devices. While in most situations, my Cisco or Cisco-compatible Twinax cables functioned fine when utilized with the TP-Link switch, I did encounter an issue where I could not get a connection to work at all when it was connected to my Ubiquiti EdgeSwitch Lite 48 port switch. Occasionally, the switches would establish a link at 1Gbps whenever I would hard set the ports to 1Gbps, but they would not establish a 10Gbps link. I eventually ended up utilizing 10G SR optical SFP+ modules and fiber, which worked on the first try.

Overall Impression

The TP-Link TL-SX3008F JetStream 8-Port 10GE SFP+ L2+ Managed Switch is a very capable device at an affordable price. While it does have a few shortcomings when it comes to the implementation of various management protocols, it still performs quite well. For a home lab environment where these issues aren’t as big of a concern, the device is a great fit. I have no plans to return the devices due to these shortcomings, and ulitmately, I ended up purchasing four of them to connect up all of my equipment. While a 16-port version is available, it includes active cooling which I wanted to avoid.

I hope in time that, TP-Link will address the security implementation issues. However, due to the fact that TP-Link appears not to be keeping on top of security standards when implementing services within the switch, I would hesitate to consider TP-Link JetStream devices as secure devices that could or should be used in a business environment. Supporting and often enabling outdated security protocols by default (Telnet, SSH version 1), as well as utilizing insecure/deprecated security ciphers/hashing algorithms (DES, 3DES, MD5, SHA1), suggests that other security best practices might also be taking a back seat during the firmware development process. While I have no proof of this, I believe it is a valid concern. Additionally, I would also be hesitant to depend on their Omada SDN solution based on similar concerns that the implementation might not be based on a sound security foundation.

Share:

Search

Get Notified of Future Posts

Follow Me

Recent Posts