The talk covers some of the operational issues which NTP has faced over the past 30 years, RFC drafts for future changes to the protocol, and Best Current Practices.
I recently wanted to look at some packet captures on my NTP pool servers and find out if any NTP clients hitting my servers use extension fields or legacy MACs. Because the overall number of NTP packets is quite large, I didn’t want to spool all NTP packets to disk then later filter with a Wireshark display filter – I wanted to filter at the capture stage.
I started searching and found that not many quick guides exist to do this in the capture filter. However, the capability is there in both tcpdump and tshark, using either indexing into the UDP header, or using the overall captured frame length. Here’s an example of tcpdump doing the former (displaying it to the terminal), and tshark doing the latter (writing it to a file):
tcpdump -i eth0 -n -s 0 -vv 'udp port 123 and udp[4:2] > 56' tshark -i eth0 -n -f 'udp port 123 and greater 91' -w file.pcap
Both of the above filters are designed to capture NTP packets greater than the most common 48-byte UDP payload. In the case of udp[4:2], we’re using the UDP header’s 16-bit length field, which includes the header itself. In the case of greater, it uses the overall captured frame length, and actually means greater-than-or-equal-to (i.e. the same as the >= operator); see the pcap-filter(7) man page for more details.
This will be a shorter, less-polished post than usual. It’s really just a way to start to bring a bit of structure to my thoughts. Feel free to add some comments or weigh in on the linked Twitter thread.
I came away from a recent PacketPushers episode, “Don’t Believe The Programming Hype” a bit disappointed that the discussion didn’t get to the heart of the matter. Then there was this tweet from Jon Langemak which kicked off some interesting discussion about the place of programming:
I find it curious that people are looking for devs and are willing to teach them networking but not networkers willing to teach them dev
— Jon Langemak (@blinken_lichten) April 23, 2017
Why shouldn’t we believe the non-programming crowd?
So here are my propositions (and some corresponding anti-propositions):
- Programming isn’t hype; programming is a fundamental IT skill. If you don’t understand the basics of computer architecture (e.g. CPU instruction pointers, registers, RAM, stacks, cache, etc.) and how to create instructions which make computers do useful things (i.e. coding), you’re not an IT professional.
- This doesn’t mean you must understand exactly how every computer architecture works, or know how to code in assembly language (or directly in hexadecimal like Mel the Real Programmer). But it does mean that if you’re confronted with a problem, you know enough fundamentals to peel back the layers, and work through the elements in each layer methodically (with the help of the documentation) to determine the component in error.
- There is no fundamental distinction between scripting and programming. Both are designed to accomplish basically the same things, at different levels of abstraction. Suggesting that someone who writes scripts to automate his or her infrastructure is not a programmer confuses the issue and does not progress the discussion.
- This doesn’t mean that vendor-originated code isn’t better than in-house scripts (sometimes it is; sometimes it isn’t), but it does mean that the value of the local process and infrastructure knowledge contained within in-house scripts mustn’t be sidelined. No off-the-shelf software “just works” without configuration or customisation of some sort, so in-house scripts are fundamentally necessary.
- The above distinction is probably just a specific instance of the generalisation that there’s a difference between builders and non-builders. This is also a non-real distinction. Every enterprise IT organisation is building something, whether they use code they’ve written themselves or rely solely on vendors. You can’t compile a data centre contract into existence or code up a WAN link; working IT systems are built both by those who create the individual components, and those who build on those components. It’s turtles all the way down; not many software vendors assemble their own motherboards or run their own chip fabs…
How did we get here?
So how did we get to this point where the concept of learning programming seems so intolerable to networking folks?
In my mind the main factor is the normalisation of proprietary software – that is, the widespread acceptance that it’s OK for software to be closed to scrutiny and not fully controlled by those who depend upon it. (On the contrary, I hold that Open Source is essential for the operational safety of functioning IT systems.) The dominance in their respective markets of Microsoft Windows on the corporate desktop & server and Apple iOS on consumer devices are no doubt the most common examples of this, but other, more egregious examples pop up routinely.
This has led to a generation of IT folks for whom the fundamentals were something akin to magic. “If I press here it does this…” The pushback against programming is only one example of this. (Another is the cargo-culting/guessing troubleshooting culture that many of us in operational roles have encountered.)
My plea to those who are pushing back against the programming trend is simply this: have a go! Programming is just building things – like you already do – just at a different level of abstraction. You might find that you like it, and it opens up a whole new range of possibilities for you.
I recognise that I write this from a biased perspective:
- When I started in IT, there were no “IT” qualifications. When I went to university, the course was still called Applied Science with a major in computing.
- My first job (while still in uni) was a programmer. After that, I was a Unix sysadmin. Back then, Unix sysadmins were expected to know C in addition to the usual scripting tools. Network engineering was a relatively late addition in my career; I didn’t start being the primary networking resource in my job until 2003, and didn’t get my CCNA until 2012. So I always approached networking from a slightly different perspective to the “average” network engineer who did his/her CCNA straight out of school.
- I’m a Free Software “true believer”; I first installed Linux from floppy disks with a distro which used kernel version 0.97. I’ve been using Linux on the desktop for almost 20 years. You can’t survive that long in the Open Source world without being able to compile (and sometimes fix!) software on a semi-regular basis.
Feel free to discuss! Either in the comments below, or shoot me some thoughts on Twitter.