News items for tag network - Koos van den Hout

Yesterday I learned that ISC DHCP server will be end of life at the end of this year. For a package I started using around 1998 with one of the first versions I expected a bit more announcement time. At the same time I'm so used to using ISC dhcp server in my home network I never subscribed to any mailing list or other announcements about ISC dhcp server, it's just there, I can configure it to do what I want including supporting pxe booting systems for installation or diagnostics or supporting special dhcp options for APC AP7920 rackmount power distribution units. And all the virtual lans of my home network.

ISC suggests using Kea DHCP server to replace it in most server implementations. Kea DHCP server should be able to get a lot of configuration data from databases and allow for dynamic updates of the configuration. That is an improvement over ISC dhcp as it is at the moment, which needs a full restart for every change.

So time to peek at Kea DHCP server. I don't think ISC dhcp server will be unavailable after 31 December 2022 but I don't expect updates anymore and when a good replacement is normalized I expect ISC dhcp server to slowly fall away from linux distributions.

Currently it's not even available for Debian or Devuan stable or oldstable strangely enough. I wonder what happened there. But there are distribution packages for debian buster at Cloudsmith - Repositories - ISC - Internet Systems Consortium (isc) - kea-2-3 (kea-2-3) - Packages / format:deb.

Time to install the latest and let apt fix the dependencies:

koos@testrouter:~$ sudo dpkg -i isc-kea-dhcp4_2.3.1-isc20220928105532_amd64.deb isc-kea-dhcp6_2.3.1-isc20220928105532_amd64.deb isc-kea-common_2.3.1-isc20220928105532_amd64.deb 
Selecting previously unselected package isc-kea-dhcp4.
(Reading database ... 46609 files and directories currently installed.)
Preparing to unpack isc-kea-dhcp4_2.3.1-isc20220928105532_amd64.deb ...
Unpacking isc-kea-dhcp4 (2.3.1-isc20220928105532) ...
Selecting previously unselected package isc-kea-dhcp6.
Preparing to unpack isc-kea-dhcp6_2.3.1-isc20220928105532_amd64.deb ...
Unpacking isc-kea-dhcp6 (2.3.1-isc20220928105532) ...
Selecting previously unselected package isc-kea-common.
Preparing to unpack isc-kea-common_2.3.1-isc20220928105532_amd64.deb ...
Unpacking isc-kea-common (2.3.1-isc20220928105532) ...
dpkg: dependency problems prevent configuration of isc-kea-dhcp4:
 isc-kea-dhcp4 depends on libboost-system1.67.0; however:
  Package libboost-system1.67.0 is not installed.
[..]
koos@testrouter:~$ sudo apt install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libboost-system1.67.0 liblog4cplus-1.1-9 libmariadb3 libpq5 mariadb-common
  mysql-common
The following NEW packages will be installed:
  libboost-system1.67.0 liblog4cplus-1.1-9 libmariadb3 libpq5 mariadb-common
  mysql-common
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
Need to get 760 kB of archives.
After this operation, 4,001 kB of additional disk space will be used.
[..]

Looking at the sample configuration makes me think I can do this with a text-based configuration (it's actually JSON) and get it going fast. For my home network that is probably the best solution. Kea does have options to use MariaDB or PostgreSQL backends for storage which does look really nice for my home network but at the same time adds a dependency and a layer of complexity.

I can see IPAM systems totally going to Kea DHCP and give a full interface on managing the databases directly including APIs for adding/removing objects as they are added in other systems.

In my time at Utrecht University computer science I wrote a script to search Cisco switches for a given ethernet address and respond with the port. This could be used to trace things on the network, which helped on incidents in progress.

This script was based on the typical things Cisco switches do with vlan CAM table lookups and the best implementation. CAM stands for Content Addressable Memory: memory optimized for doing lookups by certain content. In the case of a network switch a 6-byte MAC address plus 2-byte vlan id will be used to do a lookup of the 2-byte interface number where it was last seen, and this lookup is done in hardware.

This CAM table is accessible via SNMP, and the funny part is the MAC address for the lookup is also encoded as SNMP identifier. I could get the whole CAM table via snmpwalk but as I only want to lookup 1 MAC address it is way faster to go directly from MAC address to interface number. After that the interface number is translated to an interface name and that name is usually something recognizable to a network engineer.

When I started using managed switches at home from Netgear I adapted the script at home and enhanced it for Netgear switches.

I recently added a third netgear switch when upgrading the fiber to the shed and I updated the script to learn about the new switch.

I noticed the interface names are quite different over the generations of netgear switches.

The oldest switch is a Netgear GSM7224. The interface name from a query is "Unit: 1 Slot: 0 Port: 15 Gigabit - Level".

The second switch is a Netgear GS716Tv2. The interface name from a query is "Slot: 0 Port: 11 Gigabit - Level".

The newest switch is a Netgear GS310TP. The interface name from a query is "GigabitEthernet9".

The Unit: 1 in the GSM7224 suggests some option for stacking multiple switches, but I can't find any mention of that option in the on-line documentation.

The other fun part I notice is interface names never showing the fact that they are actually an SFP interface with an SFP in them. The port status for a port with an SFP is not different from the status for a copper cable at gigabit.

I got around to doing the upgrade of the fiber to the shed network I had on my mind today.

A friendly network layer 1 engineer had some leftover Cisco SFP modules and the netgear GS310TP and netgear GS716Tv2 switches accepted these without any issue. So the layer 1 network link came up fine.

The layer 2 link with vlan support took me a few hours, somehow I managed to get confused with vlan tagging, vlan tagged only frames and the primary vlan id. I haven't done this in a while and I sort of copied the configuration from another port which may be less than optimal too. I had to run through the house a number of times to get the configuration right, wireless devices can't access the managed switches. At least I got the whole configuration working in the end. I think I can add other vlans to the link too (I want the option of a wireless access-point in the shed).

Putting the switch, the power supply for the switch, the raspberry Pi, the power injector for the 1-wire measurement network and all network cables and fiber in the plastic box I bought for this work was a bit of work, it just fits (so a wireless access point will have to live outside that box..). But it's all in there and the box is closed again. It's just not airtight anymore with the new holes for power, fiber, network cable, gps antenna cable and 1-wire network. I may need to stuff the holes with foam or something similar to keep insects from crawling into the box.

Everything works now and the measurements from the solar inverter are coming in!

I used the raspberry pi in the shed to do a wifi scan, to get an idea of the usage of the 2.4 GHz wifi band as seen in the shed.

This finds 18 to 22 networks, with our own network not as the strongest network. As you can imagine most channels have multiple networks on them. And the overlap in wifi channels makes this worse: the networks on channel 2 see interference from those on channel 1.

From the list of networks, with names and address information removed, just leaving signal strength and channel / frequency:

-93 dBm, ch   1, 2412 MHz
-91 dBm, ch   1, 2412 MHz
-92 dBm, ch   1, 2412 MHz
-72 dBm, ch   1, 2412 MHz
-92 dBm, ch   1, 2412 MHz
-88 dBm, ch   1, 2412 MHz
-92 dBm, ch   1, 2412 MHz
-91 dBm, ch   2, 2417 MHz
-80 dBm, ch   2, 2417 MHz
-90 dBm, ch   3, 2422 MHz
-94 dBm, ch   4, 2427 MHz
-93 dBm, ch   5, 2432 MHz
-94 dBm, ch   5, 2432 MHz
-80 dBm, ch   6, 2437 MHz
-94 dBm, ch   8, 2447 MHz
-95 dBm, ch   8, 2447 MHz
-94 dBm, ch   9, 2452 MHz
-95 dBm, ch   9, 2452 MHz
-77 dBm, ch  10, 2457 MHz
-84 dBm, ch  11, 2462 MHz
-93 dBm, ch  11, 2462 MHz

This is a right mess. If I ever want reliable wifi in the back garden/shed I will have to have an extra access-point there. This option of having wireless vlan(s) available in the shed has influenced the choice in switch for the shed.

In the project to upgrade the connectivity to our shed I ordered a switch with sfp slots: a netgear GS310TP. The choice is to have the same brand as in other places in the network so I can select compatible SFP modules easily. With this switch I also have vlan support so I can have a wifi access point in the shed if I want.

The current fiber to the shed network is working fine but only gives the Raspberry Pi based NTP server network at a speed of 100 mbit.

The link is working fine but the next device with network problems due to unreliable wifi is showing up: the solarpanel inverter in the shed is sometimes unreachable for my solar inverter monitoring using modbus/tcp and that means I 'miss' measurements. The propetairy monitoring that solaredge does can deal with interruptions in reachability and upload older data, but the modbus/tcp monitoring I use can only access real-time data.

My first plan was to look at industrial switches because of the extended temperature and humidity ranges in the shed. But having both 'industrial' and 'sfp slot' costs a lot of money.

My next thought is to put all the possibly sensitive electronics in one case and hope the temperature and humidity inside that case stay within a reasonable range. This thought is based on the fact that the Raspberry Pi based NTP server functions fine in a not very closed wooden box without being affected by temperature or humidity.

I continued my slow migration of statistics to Influxdb/Grafana and added the network traffic. I've been gathering this for ages in rrdtool, my earlier view was that I've been using rrdtool for network and other statistics since October 2002 so it is a bit of a change.

I updated the perl scripts that fetch network traffic statistics over SNMP to also add the data to influxdb. And it was simple to create a dashboard with that data. The overview pages with data for all interfaces for one measured host also link to detail pages per interface which also show the number of errors.

Today I had time to prepare for the final fiber route in the utility closet and after that it was time to go into the crawlspace again and replace the fiber with the 15 meter length singlemode fiber. Good preparations helped the fiber pulling to go fine.

Next stage was to mount both fiber optic transceivers in such a way that they protect the fiber from damage. At last it was time to add UTP cable for the last part at both ends and soon the right lights were blinking and the link was up.

So now the weather reporting for Weatherstation Utrecht Overvecht is a lot more reliable and on time again, and the time service from my time server is always available.

Fiber may be overkill for this path, but on the other hand the fiber that came out of the pipe between the shed and the crawlspace was quite wet so my best guess is utp cable would need special precautions to not get water in it.

I talked about the latest developments in the fiber to the shed project with someone who has more experience in home fiber network and the suggestion was to order a 15 meter single mode lc-lc patch cable to have one cable from shed to the switch. I ordered such a cable at fs.com and added an 100base-LX SFP so the fiber can terminate directly in the downstairs switch.

Now waiting for the equipment to arrive, and there will be more work in the crawlspace in my near future.

Update 2020-02-04: The ordered fiber and SFP arrived late in the afternoon. Fast service from fs.com. It was shipped via DHL Express and they tried several times to remind me to pick a DHL shop to pick up the package but currently I'm not going anywhere most working days so my doorstep is a perfect delivery address.

Update 2020-02-05: After several tries it is clear my netgear switches have SFP slots that do not want to work with a 100base-LX SFP module. So one step back to the plan with two fiber-optic transceivers.

The first part of the fiber path has been done.

Today I gathered all the tools to work on this project and removed most of the contents of our shed to work in there.

When I started digging in the shed I soon noticed the plastic pipe from the shed to the crawlspace of our house takes a 45 degree angle first and the next 45 degree angle is under the garden. I was not going to do that much digging so the plan had to be adjusted. The working solution was to pull the fiber through one of the old heating pipes. So my wife pushed a wire-pulling cable through one of the heating pipes while I was laying in the crawlspace waiting for it to show up. When we tried the second heating pipe it did show up, and pulling the fiber back to the shed worked fine. I did put some tape around the connectors to make sure they wouldn't hook behind something and I made sure the bit of rope that was pulling on the fiber was actually pulling on the main fiber and not on the connectors. The fiber came up in the shed nicely.

I wanted to hang the fibre in the crawlspace, since it could get damaged easily lying on the in the sand down there. I installed an electricity pipe hanging under the floor beams. After that there was still a bit of length to get to the nearest switch but not enough fiber left, so I had to leave that hanging for when I get a connector for an extension.

While I was in the crawlspace I made sure some other cables were mounted better, since the mess down there annoys me a bit. And I don't want other maintenance in the crawlspace to have a chance of disconnecting important things.

So the project isn't finished yet, but there is serious progress. It feels like I almost spent as much time making sure I had the right tools available and cleaning and storing them again as I spent actually working on it!