Network Infrastructure Support

While routing packets around is the primary function of the network, there are a number of applications that are so important to the user experience and are quite closely tied into network functionality. These applications most often they fall into the realm of the network engineer to support.

Network time protocol

It is a good idea to be sure all your routers (and hosts) use the NTP protocol to synchronize their clocks. This allows accurate time stamps in all log information, which can be quite help full in correlating events in those logs. Here is the home page for the NTP project. NTP works in with a stratum system, such that stratum 1 clock server systems synchronize themselves to some external and highly accurate clock source (gps, atomic clock). Stratum 2 servers/hosts synchronize themselves to one or more stratum 1 servers. Stratum 3 servers/hosts synchronize themselves to stratum 2. Etc. It doesn't matter that much if you are a stratum 2 or 3 or 4 server, if it is working your clock will be within milliseconds of Universal Time.

The detailed manual pages are ntpd, this is the daemon that runs to keep time synchronized. ntpq, this is a tool to query a ntp process about its status. Much more information about ntpd is available at the ntp daemon web page. This is the only good source for configuration file options.

To set up ntp on linux routers (like R1) you create a configuration file (for example /mnt/hda1/ntpd/ntp.conf) which contains the list of servers to use, and then start the ntpd daemon (/usr/sbin/ntpd) with a -g option and a -c option. The -g option tells the daemon to force the clock to the servers time at startup and then to begin synchronization with the servers. The -c option is used to point the daemon at the configuration file you created.

ntp is also supported on the cisco routers. Here is a reference to IOS documentation on how to configure ntp and other system parameters The command to set the ntp server for group XX to 10.XX.0.20 is

	ntp server 10.XX.0.20

ntp is also available on the juniper routers. Here is a reference to the JunOS docs for configuring ntp (and other system parameters) The commands to do this in JunOS (again for our fictional group X) are

system {
	ntp {
	    boot-server 10.XX.0.20;
	    server 10.XX.0.20;
	}
}

Network based logging support

It is important to allow your routers and other devices to report log information. It can be useful to collect this information in a central location. For this we can use the "SYSLOG" protocol. This is a UDP based protocol which is defined in RFC3164. Linux workstations and routers use a syslog daemon process to send logging information to a central logging system and/or a local file. Cisco routers have a set of command which configure them to use the syslog protocol to send to a syslog daemon, and control what is available for local use. Juniper routers also can be configured to send log information to a remote syslog server.

On linux systems you control how syslogd works with the syslog.conf file which is usually stored in /etc, but can be changed by specifying it on the command line that starts syslogd using the -f option. There are a number of different facilities and each facility can deal with messages of a number of priority levels.

The defined facilities are

           0             kernel messages
           1             user-level messages
           2             mail system
           3             system daemons
           4             security/authorization messages (note 1)
           5             messages generated internally by syslogd
           6             line printer subsystem
           7             network news subsystem
           8             UUCP subsystem
           9             clock daemon (note 2)
          10             security/authorization messages (note 1)
          11             FTP daemon
          12             NTP subsystem
          13             log audit (note 1)
          14             log alert (note 1)
          15             clock daemon (note 2)
          16             local use 0  (local0)
          17             local use 1  (local1)
          18             local use 2  (local2)
          19             local use 3  (local3)
          20             local use 4  (local4)
          21             local use 5  (local5)
          22             local use 6  (local6)
          23             local use 7  (local7)

and the defined priority levels are

           0       Emergency: system is unusable
           1       Alert: action must be taken immediately
           2       Critical: critical conditions
           3       Error: error conditions
           4       Warning: warning conditions
           5       Notice: normal but significant condition
           6       Informational: informational messages
           7       Debug: debug-level messages

The simplest syslog.conf file would write all messages to a single file. If syslogd was started as

	/sbin/syslogd -r -f /mnt/hda1/log/syslog.conf

and /mnt/hda1/log/log.conf contained

	*.debug		/mnt/hda1/log/logfile.all

This would accept syslog messages from the network (the -r option) and would write all facilities messages of debug or higher priority to the file /mnt/hda1/log/logfile.all

Another common syslog configuration is to simply pass all log messages to another server. If you had a central server at 10.XX.0.20 and wanted a linux router or workstation to send all messages to it your syslog.conf would be

        *.debug         @10.XX.0.20

On a cisco router you will want to have all messages timestamped with the current date and time. Also you will want to have them help in a local buffer so you can use the show log command to see the most recent ones. You will also want to send them all to a syslog server for permanent storage. You would do this:

	service timestamps log datetime		(to force current date time stamps instead of
						 uptime stamps)
	logging buffered			(to maintain a buffer locally of syslog messages)
	logging trap debugging			(to log all messages of debug or higher)
	logging facility local6			(use facility local6)
	logging XXX.XXX.XXX.XXX			(send them via syslog protocol to a syslog server
						 at IP XXX.XXX.XXX.XXX)

On a JunOS router you would use the following to log all messages of any facility of level notice or higher to a file called /var/log/messages, keeping 10 files in rotation each 1 Mbyte large.

It will also notify directly to the terminal of any logged in users of any message from any facility that sends emergency level messages.

The last stanza will force copies of all messages from any facility at any level to be forwarded to host XXX.XXX.XXX.XXX.

    syslog {        
        archive size 1m files 10;
        file messages {
            any notice;
            authorization info;
        }           
        user * {    
            any emergency;
        }           
        host XXX.XXX.XXX.XXX {
            any any;
        }           
    }

Here is the JunOS documentation page for configuring syslog.

DHCP

DHCP is the dynamic host configuration protocol. It is a extension to the bootp protocol and is currently defined in RFC2131. DHCP's job is to allow hosts who know very little about the network to make a query to the network to find out lots of important information, such as IP address, netmask, default route, and any number of other (extensible) pertinent data. The host usually just knows its hardware (layer 2, MAC) address.

When a host boots up it can make a broadcast DHCP query. If there is a DHCP server on the same network (broadcast domain) it can answer and provide the needed information to the host. If there is now DHCP server on the local network then the host can not get the information it needs.

But it is not practical to have a DHCP server on every network. Since routers exist on every network we can run dhcp helper applications on the router which will look for DHCP queries on each network and forward them to a pre-programmed DHCP server (or more than one).

On linux/quagga routers this is called dhcrelay. You run a dhcrelay process on the router and it forwards to a dhcp server. On cisco routers this is done via the

ip helper-address

command in the interface section.

To run a dhcp server process you need a host computer. On linux this would be done with the dhcpd process. You can specify on the command line startup of the process where to file the dhcpd.conf file.

The configuration file has many sections where you would tell it what IP addresses to assign to queries from which networks. You can specific specific IP addresses to be assigned to specific MAC addresses or you can create a "pool" of addresses to be assigned. You can control how long each address (or lease of address) is valid, and you can specify things like the default routers and subnet masks to assign.

DNS

DNS is a hierarchical system of "zones". A zone hierarchically organized from right (higher level zones) to left (lower sub-zones) and separated by periods. The top level zone is . (known as the root zone)

Clients make a request of 1 or more DNS servers (usually sequentially) The choice of DNS servers to use to resolve a request is given to the clients at boot time (via dhcp or programmed in)

Clients usually use UDP to make DNS requests.

A DNS resolver/server starts from the right hand side of the name in the request, and reviews its cache for information, it asks for information from servers for higher zones if none is in cache. (and it has locations of root zone servers programmed in)

Once it has the requested information it returns the answer to the client.

A DNS server can be authoritative for no zone (resolving and caching only) or it can be authoritative for one or more zones.

Each zone must have one DNS server which is the SOA (start of authority) for the zone. It also have one or more other servers which are authoritative for the zone but are not the master (SOA) for the zone.

Example:

Client asks for A (address) record of www.yahoo.com

Server get this request and notes that it has no information about the com zone, (it just started up) so it will look into its pre-supplied cache of root servers (for the . zone) and send a request to them asking who are the servers for .com zone. When it receives the reply it will cache this information and ask the servers for the .com zone who are the servers for the yahoo.com zone. It will cache this info as well then ask the servers for the yahoo.com zone for the A record (address) o www.yahoo.com. It will cache this and send a response back to the client.

If another client asks for www.yahoo.com the server checks its cache and if he data is still valid it will send it back to the client...

All data is returned with a TTL. (Time to live) in seconds. Servers invalidate the cache when the ttl expires.

Servers can be authoritative for a zone, which means they are final authority for those names within the zone.

One server is the Start Of Authority. This is the master source of all information about the zone. All other authoritative servers are just mirrors of this one.

Servers can also be caching only. They are authoritative for no names in any zones.

There are many types of data that can be specified in a zone. Some common ones are

A       - IP address data
CNAME   - Canonical name  (this is an alias)
MX      - Mail exchanger (where to send mail for this name)
NS      - who are the authoritative name servers for this domain name
SOA     - who is THE one master name server for this domain
PTR     - host name pointer records

Applications query servers automatically. What DNS servers to query is information that needs to be configured on a host. DHCP will sometimes do this.

A host can have more than one address. An application can choose to only pay attention to the first address returned or to all of the addresses returned.

Reverse DNS is used to turn numbers into names. It *is* based on the IP address. If you wanted to find the name associated with 131.94.130.219 you would query for the PTR

219.130.94.131.in-addr.arpa

and if nothing was in the cache you would query the in-addr.arpa zone for who serves the 131.in-addr.arpa zone. Then ask that server who serves 94.131.in-addr.arpa zone, then ask that server who serves 130.94.131.in-addr.arpa zone and then ask that server for the PTR record of 219.130.94.131.in-addr.arpa (caching everything along the way)

Tools to help you explore the DNS system:

nslookup
dig (unix)
host (unix)