I did a short presentation at the spring 2020 roundtable of the UK IPv6 Council. The talk was about a case study I did with my NTP server listed in the NTP Pool project: For 66 days I captured all NTP requests for IPv6 and legacy IP while analyzing the returning ICMPv6/ICMPv4 error messages. (A much longer period than my initial capture for 24 hours.) Following are my presentation slides along with the results.
I am participating in the NTP Pool Project with at least one NTP server at a time. Of course, I am monitoring the count of NTP clients that are accessing my servers with some RRDtool graphs. ;) I was totally surprised that I got quite high peaks for a couple of minutes whenever one of the servers was in the DNS while the overall rate did grow really slowly. I am still not quite sure why this is the case.
For one month I also logged all source IP addresses to gain some more details about its usage. Let’s have a look at some stats:
Genau das Richtige für mich: Viele Statistiken bzgl. des ADS-B Empfangs. Konkret laufen diese dump1090-tools lokal auf dem Raspberry Pi und werten das Log von dump1090-mutability aus. (Siehe meinem letzten Post zur Installation von dump1090.) Vorallem die Statistiken über die Anzahl der empfangenen Flugzeuge sowie den Empfangsbereich sind einfach zu verstehen und sehr interessant.
Die Installation dieser Tools ist ebenfalls sehr einfach – nur wenige Befehle. (Auch wenn ein alter Raspberry Pi 1 B dann über 30 Minuten zum Ausführen braucht.) Ziemlich out-of-the-box werden dann im 5 Minuten Takt neue RRDtool Grafiken erzeugt. Los geht’s:
I want to talk about a fun fact concerning my blog statistics: Since a few years I have some “CLI troubleshooting commands” posts on my blog – one for the Palo Alto Networks firewall and another for the FortiGate firewall from Fortinet. If you are searching on Google for something like “palo alto cli commands” or “fortigate troubleshooting cli” my blog is always listed amongst the first 2-4 results.
But for some reasons the article for Fortinet has much more hits. I don’t know why but I have two different ideas. What do you think?
Since almost two years I am running a RIPE Atlas Probe in my server room. It resides in an own security zone on a Palo Alto firewall (which also powers the probe via its USB port :)). With this post I publish a few traffic statistics about the RIPE Atlas Probe.
I am very interested in statistics about the usage of IPv6 on Internet routers and firewalls. The problem is, that most routers/firewalls do not have unique SNMP OIDs for IPv4 and IPv6 traffic, but only the normal incoming/outgoing packet counters per interface. Therefore I am using two independent ethernet ports and cables between my outer router and my first firewall, one for IPv4-only and the other one for IPv6-only traffic. Now I have independent statistics for each protocol and can combine them in one summary graph. (Though I know that this will never be a “best practice” solution…)
After my Tcpdump script for storing MAC-IPv6 address bindings via the Duplicate Address Detection messages (link) and an analysis of the realibility of them (here), I had the idea of a Linux script that analyzes the Tcpdump output for obtaining some IPv6 address statistics. It should not show concrete bindings between MAC- and IPv6-addresses, but the number of different kind of IPv6 addresses, such as link-local or global-unicast addresses, built with or without EUI-64, etc.
In the following, I will present my script and will show the results after running it through the DAD logs of a whole month (March 2014) in a BYOD-WLAN with more than 100 clients.