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.
Continue reading Nping aka Layer 4 Ping
Another small post out of my “At a Glance” series: The different types of virtual private networks (VPNs). Looking at Site-to-Site and Remote Access VPNs.
Continue reading Types of VPN
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:
Continue reading I Love IPv6 Addressing!
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:
Continue reading Basic TCP and UDP Demos w/ netcat and telnet
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:
Continue reading Adding your NTP Server to the NTP Pool Project
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:
Continue reading Monitoring a Meinberg LANTIME NTP Server
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:
Continue reading Monitoring a GPS NTP Server
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. ;)
Continue reading Monitoring a DCF77 NTP Server
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:
Continue reading Counting NTP Clients
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”.
Continue reading Basic NTP Server Monitoring
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. ;)
Continue reading My IPv6/Routing/Cisco Lab Rack (2019)
Now that we have enabled NTP authentication on our own stratum 1 NTP servers (Linux/Raspbian and Meinberg LANTIME) we need to set up this SHA-1 based authentication on our clients. Here we go for a standard Linux ntp setup:
Continue reading NTP Authentication: Client Side
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.
Continue reading NTP Authentication: Server Side
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:
Continue reading CLI Commands for Troubleshooting Infoblox
When configuring a pool of NTP servers on a F5 BIG-IP load balancer you need to choose how to check if they are still up and running. There is no specific NTP monitor on a F5 BIG-IP that does an application layer health check (like there is for http or radius). The out-of-the-box options that can be used are only ICMP and UDP monitoring. Let’s first look at the pros and cons of using either (or both) of these monitors. Then let’s build a custom UDP monitor that does a better job at checking whether the NTP servers are still healthy.
Continue reading F5 BIG-IP Application Level NTP Health Checks