What is a Network Administrator Anyway?

07/20/2000

We've seen the terms "system administration" and "network administration," in the title of this column for example. There are some obvious system administration tasks, such as installing or upgrading system software like the kernel or libraries and managing user accounts and disks space, so you probably have some idea of what a system administrator does. What does a network administrator do, and how do you differentiate between system administration and network administration? Bear with me while I think out loud on the subject, and perhaps we'll have some idea by the end of this column.

In a small environment, the difference is fairly moot -- the same person or team will probably fill both roles anyway. In large IT environments, perhaps a large web-hosting company or a large ASP, the question has relevance. There will be enough work to have teams of systems administrators and teams of network administrators, and at some time it will be necessary to work out who is going to do what, to what, and when.

OK, I'll let you in on a little secret ... I don't know the answer to the question I've posed. Those of you familiar with the Linux Network Administrators Guide (NAG) who know that I've worked on the 2nd edition might find this claim amusing, but it's true. Working on the NAG was what started me thinking on this subject, trying to decide what is and what isn't relevant to network administration in a Linux environment. I've looked for some good examples of duty statements or role descriptions and just haven't found any that I thought really offered a useful definition. Worse still, if you start asking people what they think on the subject, you'll end up with a baffling array of responses and positions on the subject that'll likely confuse you.

I'm not going to attempt to define the role of the network administrator in this column. Instead I'll share my thoughts on the subject and add a dash of the larger context of telecommunications management in the hope that you might make some sense of it.

The International Telecommunications Union (ITU) is a consortium of telecommunications companies worldwide who have, among other things, defined a series of recommendations that describe how a telecommunications management network (TMN) should be operated. The ITU members have adopted a model of management functions that I think is of interest to us because it provides a framework that we can use to understand the role of the network administrator. This function model is often referred to as the FCAPS model after the initials of each of the major functions it describes. I'm not going to describe the TMN or even the FCAPS model in any detail; instead, you'll have to be content with my very high level summary of the FCAPS functions and a pointer to recommendation M.3400 at the ITU web site for more information.

TMN function

Naive description

Fault

Management: Fixing what is broken.

Configuration

Management: Controlling the operational parameters of something so it works the way you want.

Accounting

Management: Knowing who is using how much of what, and maybe billing them for it.

Performance

Management: Making sure it all works acceptably quickly.

Security

Management: Controlling who can do what.

The idea is that just about any network management task can be said to belong to one of those management functions. For example, plugging a patch-lead back in after it has fallen out is fault management, introducing a firewall onto your network is a security management task, and assigning an IP address to a network card is a configuration management task. Thinking about the FCAPS functions for a while may lead you to the conclusion that the model could be equally well applied to the role of the system administrator. Indeed, this is probably true. Perhaps the difference between the aystem administrator and the network administrator is not in what they do, but in what they do it to.

The network administrator manages networks, so what is a network made of? The network obviously includes the routers, switches, modems, and data services like ISDN lines and ATM, frame relay, or ADSL links, but where does the network end? The hosts on which the user accounts and application servers reside certainly participate in networking, especially in a TCP/IP environment where they're the only devices actually implementing the TCP protocol. Are the hosts network too?

We know that our postgres database and X11 servers are pieces of computing infrastructure, but clearly at least parts of them also fall within the definition of network infrastructure. The network interface card, the protocol implementations, and the network addresses used are all obvious network components. This strongly suggests that the network administrator has a role to play in managing at least some aspects of computing hosts when they are network connected. This is probably a good thing for the NAG but not so great from the perspective of trying to differentiate between the roles of the system administrator and the network administrator.

The gray line

The network administrator controls network addresses, protocols used, and the network interfaces because these are all obviously network components. The network administrator will also control routing, name resolution, and assignment of TCP and UDP socket numbers because, again, these are all pretty clearly network specific components. From an application perspective, they are all fairly low level functions.

One potential problem should already be apparent. In the Linux security model, it is necessary to possess root user privileges to actually configure any of these things. You must have root privileges to configure network interfaces, add or delete routes, or configure IP filtering, address translation, or traffic prioritization. Even ignoring the fact that we might have to recompile a kernel in order to effect network administration, we're already in potential conflict with the system administrator, as we require the same level of system privilege as they do to do our work. This can complicate security procedures and make management of change on the system difficult. Most environments I've seen rely on trust to make this work and hope that nobody does the wrong thing. One possible technical solution to this might be to have a network user or more generic access control lists so that particular kernel function calls can be reserved for execution only by network administrators. This would require significant kernel change and is some time off.

A second problem exists. What about all those other low-level types of applications like mail transport agents, web servers, NFS, NIS, SNMP daemons, and the like? Who should be responsible for configuring those? They make life difficult because they are network applications. My personal view is that all of those applications, with the possible exception of the SNMP daemon, should be managed by the system administrator, not the network administrator. I believe this because none of those directly impact the ability of the host computer to actually communicate on the network and are therefore not directly network related. They're all applications of the network without being applications for the network. Opinions vary, and I've certainly met a number of people who disagree.

If you're casually looking for work, or thinking of recruiting someone for your team, give some thought to the job title and what you actually think it means. There might just be other people out there spending time wondering about the same thing :-)

Terry Dawson
is the author of a number of network-related HOWTO documents for the Linux Documentation Project, a co-author of the 2nd edition of O'Reilly's Linux Network Administrators Guide, and is an active participant in a number of other Linux projects.