How Tos: Keeping a LAN Reliable

In the last year, there was a move to make sure the local area network or LAN to run at least have a four-nine reliability, meaning it will fail at least a couple years annually, or a several minutes monthly, or a few hours weekly, to a couple minutes daily; excluding scheduled outages on a monthly or quarterly basis for maintenance windows. 

There is no additional wide area networks or WAN or better known as the Internet connection, due to costs of paying for two ISPs. The only point of failure is administrative error, or power outages that last beyond several hours.

The LAN is mostly a machine dependent network over a user dependent network because the several users are dependent on many machines.

In the beginning days of January 2020 alone, the LAN traffic was pumping about 100 gigabytes of data, working on an archive project of all my photos I had taken in 2010s.

In 2018 and 2019, massive improvements on the reliability of the core network was done graciously. In order to achieve reliability: one must ensure the following:

  • Two forms of everything. Instances or actual separate duplicate equipment, apps, etc. For my use, I have a single firewall, with  two ports with two different switches.
  • I use two instances of DHCP servers, one using the flakey PFsense and the other on an older OS X server. The OS X instance is actually not exposed to any part of the greater Internet, in fact there is no “Router” it goes to. Instead, it’s on the same subnet as the other common machines, and basically it spits out IP addresses, that have static DNS and Internet gateways that is actually exposed. To prevent conflicts, the PFsense, and OS X runs on one series of IP address range and another set on the other instance. Essentially the PF sense handles 172.16.1.150 to 172.16.1.199 and the OS X handles 172.16.1.200 to 172.16.1.254. Dedicated static IP addresses for appliances, virtual machines and workstations and servers are below 172.16.1.149
  • Core switching is now the main functionality on the Netgear GS724Tv2, Servers are tied to the even port numbers (the bottom) acting as the access link (read more on why I chose that word) and the odd numbers (the top ports) acting as a distribution link. Some cheapo Netgear, and a Cisco Catalyst Express switch tie onto the upper ports. The bottom is for machines, the top is for end/users. Some upper ports have more VLAN access than others.

Virtual LAN notes:

  • VLANs help protect the network’s security and reliability to some applications like VOIP, or give right of way traffic to critical applications like databases, where one lag on the network could break the application, not necessarily the network itself. In fact, I learned that Cisco’s switchports are much easier to config than in Netgear. But since I have 52gig throughput throughout the switch, that $99 in 2012 dollars is still useful investment. Turning this general Ethernet switch into a more “core” based, to pump raw data and raw LAN traffic makes it more logical because the port count will probably be fully utiltlized with 8 to 10 ports for accessing the network, and up to 12 for the servers.
  • VLANs, part two: 3 Link Aggreation  Groups or LAGs group at least a couple VLANs at a time. LAG 1 is for non Internet exposed VLANs (like VOIP and test LANs), LAG 2 is more of a crossover between test and production, and LAG 1 is for the general network with exposure to the WAN. Cisco and Netgear don’t always get along. While Cisco uses some interpretations of the 802.1x (the IEEE standard for wired connectivities with multiple LANs), Netgear uses an older standard, if memory serves me.
  • The Cisco Catalyst 500 serves as a “core” switching to the routers, firewalls and other Fast Ethernet connections. This in the way keeps consistency to slower speed devices to stick with slower speed switching. For instance the HP iLO Lights Out management sub computer for remotely accessing the ProLiant servers when SHTF moments, is actually a Fast Ethernet only connection, so it makes sense to not knock out up to 4 Gigabit Ethernet possible ports.

General IP notes:

  • To ensure that these devices not chew up a lot of wattage (since these aren’t POE switches), especially during power outages, Green Ethernet is enabled on the Netgear, and only relevant ports for the Cisco are enabled. If you plug in a device on port 22, there will be no activity because the port is in shutdown mode. Shutting down or disabling physical ports when not needed also helps prevents bad guys from trying to get into your network if they so want to take a cable and get in that way.
  • Routing is not a real important thing, because 2 networks live on their own LAN and it’s not intended to talk to each other. Tend to keep intersubnet routing on management devices or the “Techies VLAN” that can be used to monitor multiple VLANs and manage them when necessary.
  • For general data traffic, especially for devices that consume, those are on the primary VLAN that a) can access the servers, and b) not provide any nefarious actions on the VLANs that are supposed to not be seen.

Power and Reliablity

  • The way it works is the core Gigabit switch is actually plugged into the servers’ UPS. As you probably remember with the VMware fails; is that it doesn’t necessarily support native devices when you plug in directly. In 2020, the move to some other virtualizer will occur, and most likely it will support some form of direct UPS. As of now, it’s tied to my Xserve, and well a Mac can survive a sudden power outage once and a while.
  • The edge, and the Cisco Fast Ethernet core switch, and a couple Cisco Routers, live on another UPS and it’s designed to handle at least an hour down after power is lost
  • It’s best to have the lower consumpting   (ones with the wall wort) on either a UPS that handles servers, or a UPS that will be designed to just handle wall worts, and check if those devices are properly connected to backup devices if say the servers go into shutdown.

It’s important to ensure there’s always a backup to the backup. The vast majority of at-home network disasters are often at the LAN level and not the WAN/ISP’s end.

Leave a Reply

Your email address will not be published. Required fields are marked *