header image

Home lab? Yes, first steps taken! This has been in my mind for some time. Why? First for learning purposes but it has potential for more in the future. Home network lab is not a same thing than large corporate network with multiple inter-connected sites, but it is a good start, anyway!

Home lab gives me an opportunity to get my hands on real stuff to see a blink of the physical side of network planning, giving more perspective for the whole process rather than only playing with logical (or virtually simulated) network topologies in network simulation software.

Table of Contents

We are not in virtual networks anymore, this is real stuff

Just kidding, although the title has partial truth in it. We are actually expanding out from pure GNS3 virtual network environment. By playing with physical devices you can feel and see real stuff in action. You get perspective for designing proper ethernet cabling and wireless solutions. You can expand both the network and your understanding about network environments. Although having few devices hardly improves your understanding about large scale and error resistant networking, it has potential to be expanded to a direction which allows you to implement these solutions, too.

Necessary network gear I have powering up my own home lab:

post image
This is my personal serial cable for connection between my Linux computer & HP ProCurve 2650 Switch serial console port.
post image
post image
Core devices for a simple network home lab. Edge router, core/distribution layer switch, access layer switch. This is a good start, although the setup is currently very simple and has potential to be expanded in the future.

About devices & topology

I have configured Ubiquiti router for my specific home lab environment. D-Link switch is serving as core/distribution layer switch whereas HP ProCurve switch is deployed into access layer.

With this gear, I have set up several VLANs in my network environment, and my purpose is to add more configuration and devices in time. Of course, basic DMZ configuration is already done and reservation for separate (public) WLAN is considered.

I have multiple spare modems & routers available which could be added to the network topology if they add more value to the network topology and don't make it unnecessarily more complex.

The network has currently different kind of end devices in different logical subnets, depending on their role and current security policy.

Planning

Before physical deployment I had several network topology + subnet plans in my virtual environment. Most difficult parts were deciding placement of various core network devices, availability of various subnets (private & public networks), firewall policy planning and, well, port planning (which ports should be reserved for which VLANs etc.). Because we talk about a home lab environment, I think the current setup will likely change in time. I keep track of any changes in the topology. Future scalability is considered in network topology planning.

Bottlenecks

I have currently several network speed bottlenecks on my home lab environment. The reason is mostly old devices I use which do not support 1000 Mbps (or 10000 Mbps) speeds even in internal networking. These bottleneck devices must be taken into account, as they must not exist in critical points in the network topology, such as between routing/switching operations.

HP ProCurve switch is an old generation switch having, unfortunately, 48 ports operating in lower speed 10/100Base-TX for clients & other network devices, and 2 ports reserved for 10/100/1000Base-TX speeds. Let's see if these lower speeds will become bottlenecks in the future. Lower speeds are also an issue with consumer grade routers/modems I have in spare. For internal connections, gigabit ethernet ports are preferred.

Where is Cisco IOS, Juniper Junos OS??

You may argue that I should have devices from these vendors because many network enthusiasts and professional use them. I believe it. However, I guess even more important for an expert is to understand what network devices are commonly capable to do, and perform implementation solution using vendor specific approach (command syntaxes etc).What is your goal with the device of your choice? Does your device support the feature you require? How do you approach the task? Learn and understand, do not be stupid sheep.

I have used half dozen of Linux distributions. I have used Cisco IOS, DD-WRT, OpenWRT, Ubiquiti EdgeOS and D-link switch configurations. My approach has always been like I said above: you commonly know what you can do, you have a task, find your way to perform it, work it out. It's not that hard once you get familiar with systems of your choice and read documentations.

Basically, I prefer not to create a vendor lock situation, and if possible, try out multi-vendor solutions as they might be used in other network/IT environments. I am aware many vendors implement their own standards (such as non-standarized WDS+WPA2-PSK solutions, and various network protocols), creating vendor lock-in situation in the first place.

Result of my multi-vendor network configuration? Excluding WLAN, all devices play nice together, thanks to common standards and basic network features they use and have.

P.S. I have heard you can use central management alike software (SaltStack, Puppet, Chef, Ansible etc.) with some of network devices (routers, switches). Of course, that feature is interesting as it opens new possibilities for better overall network management in organizations.

Small issue: Loud fan noise of HP ProCurve switch

Because HP ProCurve 2650 Switch has pretty loud operating fan noise, I have ordered couple of 40x40x20mm Noctua NF-A4x20 FLX fans from Ebay as replacement fans. Default fans, Nidec Beta V C34636-57, are simply too loud for any office/home lab environment. Luckily, the default fans are easily replaceable, as they use generic 3-pin power socket used widely in computer industry.

This topic will be further discussed in the next post.

post image
HP ProCurve 2650 Switch case can be easily opened with a small screwdriver.