2022-05-12 Generations of Netgear switches and interface names
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.
2022-05-11 The fiber to the shed network has been upgraded
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!
2022-02-25 Why the wifi in the shed is probably unreliable
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 MHzThis 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.
2022-02-22 Shed switch ordered
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.
2022-02-08 Upgrading the fiber to the shed network
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.
2021-09-05 Network traffic statistics in Influxdb/Grafana
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.
2021-02-06 Fiber to the shed: final stage, first light and link up
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.
2021-02-02 Fiber to the shed: small change of plans
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.
2021-01-30 Fiber to the shed: actual digging and crawling
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!
2021-01-15 Fiber to the shed: testing the fiber optic transceiversItems with tag network before 2021-01-15
I wanted to get an idea whether the network over the fiber optic transceivers is reliable. So at the moment our dining room table looks like a network lab. For testing networks there is iperf. I found out the Raspberry Pi 3B+ can't keep up with 100 Mbit/second UDP packets, so I searched for a speed where the Pi performs ok. This turns out to be 30 mbit, at higher speeds there is packet loss. I also had to reduce packet size to avoid fragmentation which costs CPU. I use IPv6 because that's what I'm used to. It turned out later the maximum speed without loss is higher with IPv4 than with IPv6. Server on the raspberry pi:koos@raspberrypi:~ $ iperf --version iperf version 2.0.9 (1 June 2016) pthreads koos@raspberrypi:~ $ iperf -s -V -u ------------------------------------------------------------ Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 160 KByte (default) ------------------------------------------------------------Test without fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - raspberry pikoos@wozniak:~$ iperf --version iperf version 2.0.9 (1 June 2016) pthreads koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c .. ------------------------------------------------------------ Client connecting to .., UDP port 5001 Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ .. [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec [ 3] Sent 321430 datagrams [ 3] Server Report: [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec 0.004 ms 0/321430 (0%)Test with fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - fiber optic transceiver - fiber - fiber optic transceiver - utp - raspberry pikoos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c .. ------------------------------------------------------------ Client connecting to .., UDP port 5001 Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec [ 3] Sent 321430 datagrams [ 3] Server Report: [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec 0.007 ms 0/321430 (0%)Trying with IPv4 shows that packet loss starts to occur above 45 mbit. This is an interesting difference. But the important conclusion is that there is no packet loss over the fiber path. There may be a bit more latency, but that's not a surprise. As a last test I looked at purely ping traffic using IPv6. Without fiber in the path:koos@wozniak:~$ ping -c 100 -i 0.2 -q .. PING ..(.. (2001:xxxx)) 56 data bytes --- .. ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20192ms rtt min/avg/max/mdev = 0.567/0.680/0.866/0.063 msWith fiber in the path:koos@wozniak:~$ ping -c 100 -i 0.2 -q .. PING ..(.. (2001:xxxx)) 56 data bytes --- .. ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20191ms rtt min/avg/max/mdev = 0.625/0.738/0.828/0.046 msThis also shows a bit more latency over fiber. The extra latency is probably due to the fiber optic transceivers containing a network switch.