Some years ago I wrote a blog post called “Basic syslog-ng Installation“. While I used it myself quite often in my labs or at the customers’ sites, it shows only basic UDP transport which is both unreliable and insecure. So, let’s have a look at a fresh installation of syslog-ng with TLS support for security reasons. However, TCP and UDP as transport are covered as well for the support of legacy systems.
I was missing a generic layer 4 ping in my toolbox. Initially searching for a mere TCP ping, I have found Nping which completely satisfies my needs and gives so much more. ;)
What’s a layer 4 ping, and why? –> A normal ping (= ICMP echo-request) reveals whether the destination IP address, that is: the mere server/VM, is up and running. That’s great for a layer 3 networker since routing to and from the destination is already working. However, it does NOT reveal whether or not a service at layer 4 (TCP or UDP) is up and running as well. That’s what a layer 4 ping is about: sending TCP SYNs to the port in question, waiting for a “SYN ACK” (port is listening) or “RST”/no reply (port is not available). Common use cases: Waiting for a service to start again after an upgrade, or waiting for new firewall policies (to allow or deny) a certain port.
Probably the biggest prejudice when it comes to IPv6 is: “I don’t like those long addresses – they are hard to remember.” While this seems to be obvious due to the length and hexadecimal presentation of v6 addresses, it is NOT true. In the end, you’ll love IPv6 addresses in your own networks. This is why – summed up in one poster:
I am currently working on a network & security training, module “OSI Layer 4 – Transport”. Therefore I made a very basic demo of a TCP and UDP connection in order to see the common “SYN, SYN-ACK, ACK” for TCP while none of them for UDP, “Follow TCP/UDP Stream” in Wireshark, and so on. I wanted to show that it’s not that complicated at all. Every common application/service simply uses these data streams to transfer data aka bytes between a client and a server.
That is: Here are the Linux commands for basic lab, a downloadable pcap, and, as always, some Wireshark screenshots:
You have a running NTP server with a static IP address? What about joining the NTP Pool project by adding your server to the pool? You will give something back to the Internet community and feel good about it. ;)
It doesn’t matter if you’re running a Raspberry Pi with GPS/DCF77 on your home, or a fully-featured NTP appliance such as the ones from Meinberg on your enterprise DMZ. Just a few clicks and your server will be used by the NTP Pool’s round-robin DNS. Here’s a simple tutorial:
Monitoring a Meinberg LANTIME appliance is much easier than monitoring DIY NTP servers. Why? Because you can use the provided enterprise MIB and load it into your SNMP-based monitoring system. Great. The MIB serves many OIDs such as the firmware version, reference clock state, offset, client requests, and even more specific ones such as “correlation” and “field strength” in case of my phase-modulated DCF77 receiver (which is called “PZF” by Meinberg). And since the LANTIME is built upon Linux, you can use the well-known system and interfaces MIBs as well for basic coverage. Let’s dig into it:
Beyond monitoring Linux OS and basic NTP statistics of your stratum 1 GPS NTP server, you can get some more values from the GPS receiver itself, namely the number of satellites (active & in view) as well as the GPS fix and dilution of precision aka DOP. This brings a few more graphs and details. Nice. Let’s go:
Now that you’re monitoring the Linux operating system as well as the NTP server basics, it’s interesting to have a look at some more details about the DCF77 receiver. Honestly, there is only one more variable that gives a few details, namely the Clock Status Word and its Event Field. At least you have one more graph in your monitoring system. ;)
Wherever you’re running an NTP server: It is really interesting to see how many clients are using it. Either at home, in your company or worldwide at the NTP Pool Project. The problem is that ntp itself does not give you this answer of how many clients it serves. There are the “monstats” and “mrulist” queries but they are not reliable at all since they are not made for this. Hence I had to take another path in order to count NTP clients for my stratum 1 NTP servers. Let’s dig in:
Now that you have your own NTP servers up and running (such as some Raspberry Pis with external DCF77 or GPS times sources) you should monitor them appropriately, that is: at least their offset, jitter, and reach. From an operational/security perspective, it is always good to have some historical graphs that show how any service behaves under normal circumstances to easily get an idea about a problem in case one occurs. With this post I am showing how to monitor your NTP servers for offset, jitter, reach, and traffic aka “NTP packets sent/received”.
My lab rack of 2019 consists of multiple Cisco routers and switches, as well as Juniper ScreenOS firewalls for routing purposes, a Palo Alto Networks firewall, a Juniper SRX firewall, a server for virtualization and some Raspberry Pis. That is: This rack can be used for basic Cisco courses such as CCNA or CCNP, or for even bigger BGP/OSPF or IPsec VPN scenarios since those ScreenOS firewalls are perfect routers as well. Of course, everything is IPv6 capable. Having some PoE-powered Raspberry Pis you can simulate basic client-server connections. A Juniper SA-2500 (aka Pulse Connect Secure) for remote accessing the Lab rounds things up.
I am just writing down a few thoughts on why I have “designed” the rack in that way. It’s basically a reminder for myself. ;)
As already pointed out in my NTP intro blogpost Why should I run own NTP Servers? it is crucial to leverage NTP authentication to have the highest trustworthiness of your time distribution all over your network. Hence the first step is to enable NTP authentication on your own stratum 1 NTP servers, in my case two Raspberry Pis with DCF77/GPS reference clocks.
With Infoblox you’re almost doing everything through the WebUI on the Infoblox Grid Master. At least the daily business such as adding/changing/deleting/moving/whatever DNS, DHCP, and IPAM stuff. Even troubleshooting is almost done through this HTTPS-based GUI. However, some circumstances require the use of the CLI on an Infoblox appliance/VM, called “Remote Console Access” aka SSH. Here are the most common troubleshooting CLI commands for Infoblox DDI. Samples on how to use the IPMI/LOM features round things up: