%\documentclass[colorBG,slideColor,troispoints,pdf]{prosper}
\documentclass[nopagebreak,ps,10pt,a5paper]{ppr-prv}% DO NOT EDIT---WILL BE OVERWRITTEN
\geometry{margin=10mm}% DO NOT EDIT---WILL BE OVERWRITTEN
%\documentclass[colorBG,slideColor,ps]{prosper}
\usepackage[toc,highlight,Tycja]{HA-prosper}

\usepackage{alltt,key,xr,cols,rcs,acro,nick,%
  graphicx,varioref,explanation,booktabs,amsmath,amstext,multicol,version}
%\usepackage[nolineno,noindent]{lgrind}
%\hypersetup{breaklinks}

\excludeversion{extra}

\newif\ifpprprvloaded
\makeatletter%
\@ifclassloaded{ppr-prv}{\pprprvloadedtrue}{\pprprvloadedfalse}%
\makeatother%

\newcommand{\positionPicture}{%
  \ifpprprvloaded
  \else
  \vspace*{-15mm}\par
  \hspace*{-13mm}%
  \fi
}
\newcommand{\positionPictureOpt}[2]{%
  \ifpprprvloaded
  \else
  \vspace*{#1}\par
  \hspace*{#2}%
  \fi
}

%\definecolor{green}{rgb}{0,1,0}

\RCS $Revision: 1.4 $

% Copyright (c) 2004 by Nick Urbanik <nicku(at)nicku.org>.
% This material may be distributed only subject to the terms and
% conditions set forth in the Open Publication License, v1.0 or later
% (the latest version is presently available at
% http://www.opencontent.org/openpub/).
                                                                                % For Prospe\renewcommand*{\bs}{\texttt{\char '134}} % Backslash `\'
%\newcommand*{\labTitle}{LDAP Directories}1
\newcommand*{\subject}{Systems and Network Management}
\newcommand*{\emphcolour}[1]{\emph{\red#1}}

\providecommand*{\RPM}{\acro{RPM}\xspace}
\providecommand*{\CD}{\acro{CD}\xspace}
\providecommand*{\IPC}{\acro{IPC}\xspace}
\providecommand*{\UID}{\acro{UID}\xspace}
\providecommand*{\GID}{\acro{GID}\xspace}
\providecommand*{\SMP}{\acro{SMP}\xspace}
\providecommand*{\API}{\acro{API}\xspace}
\providecommand*{\OK}{\acro{OK}\xspace}
\providecommand*{\IETF}{\acro{IETF}\xspace}
\providecommand*{\SMTP}{\acro{SMTP}\xspace}
\providecommand*{\ICMP}{\acro{ICMP}\xspace}
\providecommand*{\ARP}{\acro{ARP}\xspace}
\providecommand*{\IOS}{\acro{IOS}\xspace}
\providecommand*{\MS}{\acro{MS}\xspace}
\providecommand*{\POP}{\acro{POP}\xspace}
\providecommand*{\LILO}{\acro{LILO}\xspace}
\providecommand*{\HCI}{\acro{HCI}\xspace}
\providecommand*{\KDE}{\acro{KDE}\xspace}
\providecommand*{\MBR}{\acro{MBR}\xspace}
\providecommand*{\BSD}{\acro{BSD}\xspace}
\providecommand*{\GPL}{\acro{GPL}\xspace}
\providecommand*{\MB}{\acro{MB}\xspace}
% Get rid of that horrible hash mark in slide numbers in ppr-prv.cls:
\def\no{}
\setlength{\extrarowheight}{0pt}

\title{\mbox{}\blue{}Network Troubleshooting}%
\subtitle{Troubleshooting Tools}
\author{Nick Urbanik\\
  \footnotesize{}Copyright Conditions: GNU FDL (see
  \url{http://www.gnu.org/licenses/fdl.html})
  \email{nicku@nicku.org}\\
  \institution{A computing department}}
\author{Nick Urbanik \texttt{<nicku(at)nicku.org>}\\
  \footnotesize{}Copyright Conditions: GNU FDL (see
  \url{http://www.gnu.org/licenses/fdl.html})}%
%\institution{A computing department}%
\slideCaption{SNM --- Network Troubleshooting --- ver. \RCSRevision}
%%%%\Logo{\includegraphics[width=15mm]{ict-logo-smaller}}

\DefaultTransition{Wipe}
\TitleSlideNav{FullScreen}
\NormalSlideNav{ShowBookmarks}
\LeftFoot{SNM --- ver. \RCSRevision}
\RightFoot{Network Troubleshooting}

\begin{document}
\maketitle

\begin{slide}{References}
  \begin{itemize}
  \item Joseph D.  Sloan, \emph{Network Troubleshooting Tools},
    O'Reilly, August 2001, ISBN: 059600186-X, TK5105.5\,.S557\,2001
  \item Cisco's \emph{ Troubleshooting Overview} at:
    {\scriptsize
      \url{http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1901.htm}}
  \item Craig Hunt, \emph{TCP/IP Network Administration}, Third
    Edition O'Reilly, April 2002, ISBN: 059600297-1.  Chapter 13
    covers troubleshooting TCP/IP.
  \item Martin A. Brown, \emph{Guide to IP Layer Network
  Administration with Linux}, \url{http://linux-ip.net/}
\item Noah Davids, \emph{Don't forget to check your ARP cache},
  {\footnotesize
    \url{http://members.cox.net/~ndav1/self_published/The_ARP_cache.doc}}
\end{itemize}
\end{slide}

\tsection{Introduction}

\begin{slide}{Focus: Basics and Standard Tools}
  \begin{itemize}
  \item Solving network problems depends a lot on your understanding
  \item Simple tools can tell you what you need to know
  \item Example: \texttt{ping} is incredibly useful!
  \end{itemize}
\end{slide}

\begin{slide}{Troubleshooting}
  \begin{itemize}
  \item Avoid it by:
    \begin{itemize}
    \item redundancy
    \item documentation
    \item training
    \end{itemize}
  \item Try quick fixes first
    \begin{itemize}
    \item simple problems often have big effects:
    \item is the power on?
    \item is the network cable plugged into the right socket?  Is LED flashing?
    \item has anything changed recently?
    \end{itemize}
  \item Change only one thing at a time
    \begin{itemize}
    \item test thoroughly after the change
    \end{itemize}
  \item {\mbox{}\blue{}Be familiar with the system}
    \begin{itemize}
    \item \emphcolour{maintain documentation}
    \end{itemize}
  \item {\mbox{}\green{}Be familiar with your tools}
    \begin{itemize}
    \item \emphcolour{before trouble strikes}
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Troubleshooting: Learn as you go}
  \begin{itemize}
  \item Study and {\blue{}be familiar with} the \emphcolour{normal
      behaviour} of your network
  \item Monitoring tools can tell you when things are wrong
    \begin{itemize}
    \item if you know what things look like when they are right
    \end{itemize}
  \item Using tools such as Ethereal can help you understand
    \begin{itemize}
    \item your network, and
    \item \TCPIP --- better
    \end{itemize}
  \end{itemize}
\end{slide}

\tsection{Dcoumentation}

\begin{slide}{Documentation}
  \begin{itemize}
  \item Maintain an inventory of equipment and software
    \begin{itemize}
    \item a list mapping \MAC addresses to machines can be very
      helpful
    \end{itemize}
  \item Maintain a change log for each major system, recording:
    \begin{itemize}
    \item each significant change
    \item each problem with the system
    \item each entry dated, with name of person who made the entry
    \end{itemize}
  \item Two categories of documentation:
    \begin{itemize}
    \item Configuration information
      \begin{itemize}
      \item describes the system
      \item use system tools to obtain a snapshot, e.g., sysreport in
        Red Hat Linux
      \end{itemize}
    \item Procedural information
      \begin{itemize}
      \item How to do things
      \item use tools that automatically document what you are doing,
        e.g., \texttt{script}
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Documentation Tools}
  \begin{itemize}
  \item Use \texttt{script}:
\begin{alltt}
$ \textbf{script \(\sim\)/logs/logfile-$(date +%F-%R).log}
\end{alltt}
  \begin{itemize}
  \item starts a new shell
  \item all you type, all output goes into the file
  \item Add comments with \texttt{\# I tried this\ldots}
  \end{itemize}
\item Use \texttt{tee}:
\begin{alltt}
$ \textbf{arp -a | tee outfile}
\end{alltt}%$
   \item Use \texttt{sudo}: all commands are recorded in
     \texttt{/var/log/secure}
  \item Use \texttt{plod} from
    \url{http://bullwinkle.deer-run.com/~hal/plod/}
    \begin{itemize}
    \item lets you record a worksheet easily
    \item Perl, so fine on any platform
    \end{itemize}
  \end{itemize}
\end{slide}

%% \tsection{Purchasing}

%% \begin{slide}{Purchasing Equipment}
%%   \begin{itemize}
%%   \item Better to:
%%     \begin{itemize}
%%     \item spend enough for the short term (one or two years) or
%%     \item ``invest for the long term?''
%%     \end{itemize}
%%   \item Moore's Law: exponential growth in ``bang for the buck''
%%   \item Maintenance costs more for older equipment
%%   \item Count all the costs
%%   \item Conclusion: often (but not always), getting cheaper equipment
%%     to cover needs for the next two years will save money
%%   \item Buying excess capacity can waste a lot of money 
%%   \end{itemize}
%% \end{slide}

\tsectionandpart{General Troubleshooting}

\begin{slide}{Problem Solving}
  \centering%
  \positionPictureOpt{-0.045\slideWidth}{0pt}%
  %\vspace*{-0.045\slideWidth}
  \includegraphics[totalheight=0.85\slideWidth]{troubleshooting-flowchart}
\end{slide}

\begin{slide}{Identify the Problem}
  \begin{itemize}
  \item Problem is reported by a person or by software
  \item Often involves \emphcolour{communicating} with others
    \begin{itemize}
    \item Somewhat like gathering requirements in software design
    \item An \emphcolour{iterative} process
    \end{itemize}
  \item Possible questions to ask:
    \begin{itemize}
    \item What does \emphcolour{not} work?
    \item What \emphcolour{does} work?
    \item Are the things that do and do not work \emphcolour{related}?
    \item Has the thing that does not work \emphcolour{ever} worked?
    \item When the problem was \emphcolour{first noticed}?
    \item What has \emphcolour{changed} since the last time it did work?
    \item Did anything \emphcolour{unusual} happen since the last time it worked?
    \item \emphcolour{When} exactly does the problem occur?
    \item Can the problem be \emphcolour{reproduced} and if so,
      \emphcolour{how} can it be reproduced?
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Gather the Facts}
  \label{sld:gather-the-facts}
  \begin{itemize}
  \item You probably need to find out more about the problem from other
    sources, including
    \begin{itemize}
    \item Asking other people: affected users, network administrators,
      managers, and other key people 
    \item Network management systems, such as \emphcolour{Nagios}
      \url{http://nagios.org/}
    \item Tools such as Ethereal, \texttt{tcpdump}, \texttt{ntop}
      (\url{http://ntop.org/}) --- see slides starting at
      \S\ref{sld:packet-capture}
    \item Server log files
    \item Documentation about your servers and network created by
      local staff
    \item Documentation about software and hardware that are provided
      by the vendors
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}[toc=Consider Possibilities,bm=Consider Possibilities]%
  {Consider Possibilities based on Facts}
  \begin{itemize}
  \item Using the information you have gathered, try to
    \emphcolour{eliminate} some potential problems from your list.
  \end{itemize}
\end{slide}

\begin{slide}[toc=Action Plan,bm=Action Plan]{Create an Action Plan}
  \label{sld:create-action-plan}
  \begin{itemize}
  \item Start with the \emphcolour{most likely} 
    \begin{itemize}
    \item \ldots{} and those that are \emphcolour{easiest to test}
    \end{itemize}
  \item Plan needs to be \emphcolour{methodical}
  \item Plan to {\green{}change only one thing at a time}
    \begin{itemize}
    \item You can then understand the cause of the problem
    \item Aim to understand the problem so you can learn from it,
      solve (or prevent) similar problems in the future
    \end{itemize}
  \item {\mbox{}\blue{}Aim higher than just removing the symptoms!}
  \end{itemize}
\end{slide}

\begin{slide}{Implement Action Plan}
  \begin{itemize}
  \item Perform each step carefully
  \item Test to see if symptoms go away
  \end{itemize}
\end{slide}

\begin{slide}{Observe Results}
  \begin{itemize}
  \item Gather results as you change \emphcolour{each variable}
  \item Use same techniques you used in
    slide~\ref{sld:gather-the-facts}:
    \begin{itemize}
    \item Check with the key people
    \item Check with your tools
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}[toc=document,bm=document]%
  {If Solved: Document Solution}
  \begin{itemize}
  \item Record the problem and its resolution in the documentation you
    maintain for your company.
  \item Ensure others in your team can benefit from the insight you
    have gained
  \end{itemize}
\end{slide}

\begin{slide}[toc=modify action plan,bm=modify action plan]%
  {Otherwise, Modify Action Plan}
  \begin{itemize}
  \item Go back to the steps in slide~\S\ref{sld:create-action-plan}:
    \begin{itemize}
    \item Modify your action plan, selecting the next most likely
      action from your list
    \item You may have discovered more information in your
      investigation, so this can help you focus on likely causes.
    \end{itemize}
  \item If you have exhausted all the items on your list, and cannot
    think of what else to do:
    \begin{itemize}
    \item Get help from the vendor
    \item Get help from mailing lists
    \item Discuss the problem with your network of colleagues (e.g.,
      the people who are now studying with you, but who move on to
      work in a similar field!)
    \item You could even track me down and ask me!  Quite a few of my
      ex-students do.
    \end{itemize}
  \end{itemize}
\end{slide}

\tsectionandpart{TCP/IP}

\begin{slide}{OSI---TCP/IP}
  %\hspace*{-0.13\slideWidth}
  \positionPictureOpt{0pt}{-0.13\slideWidth}%
  \includegraphics[width=1.15\slideWidth]{iso-tcpip-with-protocols}
\end{slide}

\begin{slide}{IP Header---Layer 3}
\includegraphics[width=\slideWidth]{ipheader}
\end{slide}

\begin{slide}{IP Header}
\begin{itemize}
\item Version --- this is a 4-bit IP header length field that indicates
  the version of IP currently used. The current version of IP is 4
  (IPv4) but IPv6 is already being implemented experimentally and will
  be supported on future versions of the IOS.
\item IP Header Length (IHL) --- this indicates the datagram header
  length in 32-bit words.
\item Type of Service (ToS) --- ToS specifies how a particular
  upper-layer protocol would like the current datagram to be handled.
  Datagrams can be assigned various levels of importance with this
  field.
\item Total length --- this specifies the length of the entire IP
  packet, including data and header, in bytes.
\item Identification --- this field contains an integer that identifies
  the current datagram. This field is used to help piece together
  datagram fragments.
\end{itemize}
\end{slide}


\begin{slide}{IP Header (continued)}
\begin{itemize}
\item Flags --- a flag is a 3-bit field of which the 2 low-order bits
  control fragmentation. One bit specifies whether the packet can be
  fragmented; the second bit specifies whether the packet is the last
  fragment in a series of fragmented packets.
\item Time-to-Live --- this field maintains a counter that gradually
  decrements down to zero, at which point the datagram is discarded.
  This prevents packets from looping endlessly.
\item Protocol --- protocol indicates which upper-layer protocol
  receives incoming packets after IP processing is complete.
\item Header Checksum --- this field helps ensure IP header integrity.
\item Source Address --- this field specifies the sending node.
\item Destination Address --- this field specifies the receiving node.
\item Options --- this field allows IP to support various options, such
  as security.
\item Data --- this field contains upper-layer information.
\end{itemize}
\end{slide}

\begin{slide}{TCP Header---Layer 4}
\includegraphics[width=\slideWidth]{tcpheader}
\end{slide}

\begin{slide}{TCP Header}
\begin{itemize}
\item Source port and destination port --- these fields identify the
  points at which upper-layer source and destination processes receive
  TCP services.
\item Sequence number --- this field usually specifies the number
  assigned to the first byte of data in the current message. Under
  certain circumstances, it can also be used to identify an initial
  sequence number to be used in the upcoming transmission.
\item Acknowledgment number --- this field contains the sequence number
  of the next byte of data the sender of the packet expects to
  receive.
\item Data offset --- this field indicates the number of 32-bit words in
  the TCP header.
\item Reserved --- this field is reserved for future use.
\item Flags --- this field carries a variety of control information.
\end{itemize}
\end{slide}

\begin{slide}{TCP Header (continued)}
\begin{itemize}
\item Window --- this field specifies the size of the sender's receive
  window (that is, buffer space available for incoming data).
\item Checksum --- this field indicates whether the header was damaged
  in transit.
\item Urgent pointer --- this field points to the first urgent data byte
  in the packet.
\item Options --- this field specifies various TCP options.
\item Data --- this field contains upper-layer information.
\end{itemize}
\end{slide}

\begin{slide}{UDP Header---Layer 4}
  \includegraphics[width=\slideWidth]{udpheader}
  \par\bigskip\par%
  \begin{itemize}
  \item Source and Destination Port fields serve the same functions as
    they do in the TCP header.
  \item Length field specifies the length of the UDP header and data
  \item Checksum field allows packet integrity checking.  It is
    optional.
  \end{itemize}
\end{slide}

\tsectionandpart{Troubleshooting TCP/IP}

\begin{slide}{Troubleshooting TCP/IP}
  \positionPictureOpt{0pt}{-0.13\slideWidth}%
  %\hspace*{-0.13\slideWidth}%
  \includegraphics[width=1.15\slideWidth]{troubleshooting-tcpip}
\end{slide}

\begin{slide}{Troubleshooting TCP/IP}
  \begin{description}
  \item[Step 1] First, determine whether your local host is properly
    configured (for instance, correct subnet mask and default gateway
    configuration).
  \item[Step 2] Next, use the \texttt{ping} or \texttt{traceroute}
    commands to determine whether the routers through which you must
    communicate can respond.  Start with the most local router and
    progressively \texttt{ping} outwards through the Internet or use
    \texttt{traceroute}.
  \item[Step 3] If you cannot get through a particular node, examine
    the node configuration and use the various show commands to
    determine the state of the router (these include \texttt{show ip
      route}, \texttt{show ip arp}, \texttt{show
      running-configuration}, and so on.)
  \item[Step 4] If you can get to all the routers in the path, check
    the host configuration at the remote host (or get someone's help
    to do so), and check its configuration.
  \end{description}
\end{slide}

\tsection{Host Configuration}

\begin{slide}[toc=Host Configuration,bm=Host Configuration]%
  {Host Network Configuration tools}
  \begin{description}
  \item[\texttt{ps}] --- information about processes
  \item[\texttt{top}] --- dynamic information about processes
  \item[\texttt{netstat}] --- show connections and services, routing
  \item[\texttt{lsof}] --- list open files
  \item[\texttt{ifconfig}] --- shows and changes network interfaces
  \item[\texttt{route}] --- shows, changes routing table
  \item[\texttt{ip}] --- show, change, set network configuration
  \item[\texttt{arp}] --- shows MAC addresses
  \item[\texttt{nmap}] --- portscanner: shows open ports, identifies \OS
  \end{description}
\end{slide}

\begin{slide}[toc=Host Configuration,bm=Host Configuration]%
  {Checking (and Setting) Host Configuration}
  \begin{itemize}
  \item Solving Boot problems: \S\ref{sld:boot-problems-with-Linux},
    \S\ref{sld:boot-problems-with-Windows}
  \item Determine \IP address, netmask, broadcast address:
    \S\ref{sld:determine-addresses}
  \item Deterine correct \MAC $\leftrightarrow$ \IP address mapping:
  \S\ref{sld:mac-ip-mapping-1}, \S\ref{sld:mac-ip-mapping-windows}
  \item Examine routing table: \S\ref{sld:examine-routing-table}
  \item Examine access controls: \S\ref{sld:access-controls}
  \item Examine web proxy settings: check web browser
  \item Examine \DNS resolver settings: \S\ref{sld:dns-resolver-settings}
  \item Determine services provided: \S\ref{sld:services-provided},
    \S\ref{sld:using-ps-to-see-if-server-running}
  \item Determine \CPU, memory load conditions (is the server
  overloaded?) \S\ref{sld:top}
  \end{itemize}
\end{slide}

\begin{slide}[toc=Boot Linux,bm=Boot Linux]{Boot problems: Linux}
  \label{sld:boot-problems-with-Linux}
  \begin{itemize}
  \item Use \texttt{grub} to interactively boot the computer (see my
    extensive grub handout:
    {\footnotesize\url{http://nicku.org/ossi/lab/grub/grub.pdf}}) 
  \item Verify that \texttt{/etc/fstab} mounts the correct
    filesystems
  \item Use a rescue disk such as Knoppix or the Red Hat
    installation \CDROM.
  \item This gives you full access to the system and repairing boot
    problems is pretty straightforward.
  \end{itemize}
\end{slide}


\begin{slide}[toc=Boot Windows,bm=Boot Windows]{Boot problems:
    Windows}
  \label{sld:boot-problems-with-Windows}
  \begin{itemize}
  \item Use the installation Windows \CD to enter the (extremely
    limited) system repair mode.  I believe this is called the
    recovery console.
  \item Use the Linux floppy bootdisk at
    \url{http://home.eunet.no/~pnordahl/ntpasswd/} to replace the
    Administrator password
  \item Use the bootable Windows \CDROM:
    \url{http://www.nu2.nu/pebuilder/};
    \begin{itemize}
    \item Gives full access to the NTFS file system.
    \item Not as good with Windows as Knoppix is with Linux, but
      better than another reinstall.
    \item takes some time to build.
    \item Henry Leung (in A204d) has built some.
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Determine Addresses}
  \label{sld:determine-addresses}
  \begin{description}
  \item[Linux:] On Linux, these commands all show the \IP address,
    \MAC address, netmask and broadcast address for all (or the
    specified) interface.  The commands \texttt{ip} and
    \texttt{ifconfig} are in the directory \texttt{/sbin};
    \texttt{netstat} is in \texttt{/bin}.
\begin{alltt}
$ \textbf{ip addr}
$ \textbf{ip addr show eth0}
$ \textbf{ifconfig}
$ \textbf{ifconfig eth0}
$ \textbf{netstat -i}
\end{alltt}%$
\par%
\item[Windows:]\mbox{}
\begin{alltt}
C:\bs> \textbf{ipconfig /all}
\end{alltt}
\par%
\item[Cisco IOS:] these are both privileged commands, as shown by the
prompt:
\begin{alltt}
Router# \textbf{show running-config}
Router# \textbf{show ip interface brief}
Router# \textbf{show ip interface}
\end{alltt}
\end{description}
\end{slide}

\begin{slide}[bm=MAC <-> IP mapping 1]%
  {MAC $\leftrightarrow$ IP mapping --- 1}
  \label{sld:mac-ip-mapping-1}
  \begin{description}
  \item[Linux:]\mbox{}
\begin{alltt}
$ \textbf{arp -a}
$ \textbf{ip neigh show}
\end{alltt}
The lifetime of the \ARP cache entries is settable in
\texttt{/proc/\allowbreak{}sys/\allowbreak{}net/\allowbreak{}ipv4/\allowbreak{}neigh/\allowbreak{}\meta{interface}/\allowbreak{}gc\_stale\_time}
and is normally 60 seconds.
\item[Cisco IOS:]\mbox{}
\begin{alltt}
Router# \textbf{show ip arp}
\end{alltt}
  \end{description}
Note that this document:
{\footnotesize 
\url{http://members.cox.net/~ndav1/self_published/The_ARP_cache.doc}}
has a good discussion on troubleshooting \ARP.

The online book at \url{http://linux-ip.net/} has an excellent chapter
on \ARP.

\ARP is probably the most dangerously exposed protocol in a \LAN, and
can easily be subverted by tools such as \texttt{dsniff} and
\texttt{Ettercap}.   Hardcode important \ARP entries to avoid attack.
\end{slide}

\begin{slide}[bm=MAC <-> IP mapping 2]%
  {MAC $\leftrightarrow$ IP mapping --- 2}
  \label{sld:mac-ip-mapping-windows}
  \begin{description}
  \item[Windows:]\mbox{}
\begin{alltt}
C:\bs> \textbf{arp -a}
\end{alltt}
    You may wish to clear the \ARP cache on a Windows machine with:
\begin{alltt}
C:\bs> \textbf{arp -d \meta{IP address}}
\end{alltt}
or clear the entire \ARP cache with:
\begin{alltt}
C:\bs> \textbf{arp -d *}
\end{alltt}
since the Windows \ARP cache lives 10 minutes by default, a rather (too?)
long time.

It can be changed by two registry entries under
\path{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters}.
\end{description}
\end{slide}

\begin{slide}{Routing Table}
  \label{sld:examine-routing-table}
  \begin{description}
  \item[Linux:] The commands \texttt{ip} and \texttt{route} are in
  \path{/sbin}, the command \texttt{netstat} is in \path{/bin}.
\begin{alltt}
$ \textbf{ip route}
$ \textbf{route -n}
$ \textbf{netstat -nr}
\end{alltt}%$
\item[Windows:]\mbox{}
\begin{alltt}
C:\bs> \textbf{route print}
C:\bs> \textbf{netstat -nr}
\end{alltt}
\item[Cisco IOS:]\mbox{}
\begin{alltt}
Router# \textbf{show ip route}
\end{alltt}
  \end{description}
\end{slide}

\begin{slide}{Access Controls}
  \label{sld:access-controls}
  \begin{itemize}
  \item Access controls can block access mysteriously unless you think
    to check for it.
  \end{itemize}
  \begin{description}
  \item[Linux:] There are two main things to check.  The
  \texttt{iptables} command is in the \path{/sbin} directory.
\begin{alltt}
$ \textbf{iptables -L -n}
\end{alltt}%$
Note that Linux and many other \POSIX systems implement the
tcpwrappers access control in \path{/etc/hosts.allow} and
\path{/etc/hosts.deny}.  See \texttt{man~hosts.allow} and
\texttt{man~hosts.deny}.
\item[Cisco IOS:]\mbox{}
\begin{alltt}
Router# \textbf{show ip access-list}
\end{alltt}
  \end{description}
\end{slide}


\begin{slide}[toc=DNS resolver,bm=DNS resolver]{DNS resolver settings}
  \label{sld:dns-resolver-settings}
  \begin{description}
  \item[Linux:] The configuration for the resolver is
    \path{/etc/resolv.conf}.  This determines what name servers the
    system will ask.  It also tells what domain will be appended to a
    hostname.

    The \path{/etc/hosts} file is usually the first way hostname
    $\leftrightarrow$ \IP address mappings are made, but this can be
    changed in \path{/etc/nsswitch.conf}.  To ask the operating system
    for what it can see there, do:
\begin{alltt}
$ \textbf{getent hosts}
\end{alltt}%$

Linux provides three tools for troubleshooting \DNS and \DNS servers:
\texttt{dig}, \texttt{host} and \texttt{nslookup}.
\item[Windows:] See the output of
\begin{alltt}
C:\bs> \textbf{ipconfig /all}
\end{alltt}
for the names of the \DNS server the resolver will use.  Recent versions
of Windows provide the program \texttt{nslookup} to help with \DNS
troubleshooting.
  \end{description}
  See Slides starting at \S\ref{sld:dns-troubleshooting} for details
  of \texttt{dig} and \texttt{nslookup}.
\end{slide}

\begin{slide}{Checking services provided}
  \label{sld:services-provided}
  \begin{description}
  \item[Linux:] There are four main ways to check:
    \begin{itemize}
    \item Verify the processes with \texttt{ps} (see
      \S\ref{sld:using-ps-to-see-if-server-running})
    \item Verify the services that are configured to start when the
      system boots:
\begin{alltt}
$ \textbf{chkconfig --list | grep on}
\end{alltt}%$
\item Check that the service is listening on the network interface:
\begin{alltt}
$ \textbf{netstat -tua}
\end{alltt}%$
 will show all network connections to this machine.
\item The \texttt{lsof} program can be helpful in diagnosing problems
  with network services.  See~\S\ref{sld:lsof}.
    \end{itemize}

  \item[Windows:] Check network connections with
\begin{alltt}
C:\bs> \textbf{netstat -a}
\end{alltt}
  \end{description}
\end{slide}

\begin{slide}[toc=Server Running?,bm=Server Running?]%
  {Using \texttt{ps} to See If Server Running}
  \label{sld:using-ps-to-see-if-server-running}
  \begin{itemize}
  \item Is the network service running on the server?
  \item Is the web server running?
\begin{alltt}
$ \textbf{ps aux | grep httpd}
\end{alltt}%$
  \item Is the DHCP server running?
\begin{alltt}
$ \textbf{ps aux | grep dhcpd}
\end{alltt}%$
\item Is the directory server running?
\begin{alltt}
$ \textbf{ps aux | grep slapd}
\end{alltt}%$
  \item Windows: use the task manager
  \end{itemize}
\end{slide}

\begin{slide}[toc=\texttt{top},bm=top]%
  {Using \texttt{top} to see Resource Hogs}
  \label{sld:top}
  \begin{itemize}
  \item The program \texttt{top} shows:
    \begin{itemize}
    \item \emphcolour{load average} (the average number of processes
      that are ready to run, but for which no \CPU is available)
      \begin{itemize}
      \item a load average of 4 or more is ``quite high''
      \end{itemize}
    \item processes that use the most resources
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}[toc=\texttt{netstat -tua},bm=netstat -tua]%
  {\texttt{netstat -tua}: See Network Connections}
  \begin{itemize}
  \item \texttt{netstat -tua} shows all network connections, including
    those listening
  \item \texttt{sudo netstat -tuap} shows all network connections, including
    those listening, and the processes responsible
  \item \texttt{netstat -tul} shows all network listeners
  \item \texttt{netstat -t} shows only \TCP connections that are established
  \item \texttt{netstat -i} is like \texttt{ifconfig}, shows info and
    stats about each interface
  \item \texttt{netstat -nr} shows the routing table, like \texttt{route -n}
  \item Windows provides \texttt{netstat} also.
  \end{itemize}
\end{slide}

\begin{slide}{\texttt{lsof}: List Open Files}
  \label{sld:lsof}
  \begin{itemize}
  \item An amazingly useful tool
  \item Available for almost any Unix system
  \item \textbf{\texttt{lsof -i}} shows output to Internet and X.25
    files, but won't show connections that have terminated
  \item \textbf{\texttt{lsof -i@nicku.org}} will show
    only connections to that machine
  \item Can monitor progress of an FTP transfer, many, many other
    applications
  \item See manpage, \FAQ and quick start guide.
  \item Apparently, no equivalent tool available on Windows.
  \end{itemize}
\end{slide}  


\begin{slide}{\texttt{ifconfig}}
  \label{sld:ifconfig}
  \begin{itemize}
  \item \textbf{\texttt{ifconfig eth0}} --- show stats on network
    interface eth0
  \item \textbf{\texttt{sudo ifconfig lo 127.0.0.1}} --- configure the
    loopback interface, start it up
  \item \textbf{\texttt{sudo ifconfig eth0 172.19.233.5 netmask
        255.255.255.0}} --- configure eth0 with IP address
    172.19.233.5/24
  \item \textbf{\texttt{ifconfig}} --- show all configured network
    interfaces
  \item \textbf{\texttt{ifconfig -a}} --- show all interfaces, including
    those not configured yet.
\end{itemize}
\end{slide}

\begin{slide}{\texttt{route}}
  \label{sld:linux-route}
  \begin{itemize}
  \item \texttt{route -n} --- print routing table
  \item \texttt{route add 127.0.0.1} --- add a route to localhost;
  \item should have been done automatically when created device with
    \texttt{ifconfig}
  \item \texttt{route add -net 172.19.233.0} --- add a route to the
      eth0 configured on previous slide
  \item should have been done automatically by \texttt{ifconfig}
  \item \texttt{route add 172.19.64.0 gw 172.19.233.254} --- add a
    static route to network 172.19.64.0 through router 172.19.233.254
  \item \texttt{route add default gw 172.19.233.253} --- add a default
    route to 172.19.233.253 through eth0
  \end{itemize}
\end{slide}

\tsection{Cables}

\begin{slide}{Connectivity Testing: Cabling}
  \label{sld:cables}
  \begin{itemize}
  \item Label cables clearly at each end
  \item Cable testers
    \begin{itemize}
    \item ensure wired correctly, check:
    \item attenuation
    \item length --- is it too long?
      \begin{itemize}
      \item 100BaseT: less than 100m
      \end{itemize}
    \end{itemize}
  \item Is the activity light on the interface blinking?
  \end{itemize}
\end{slide}

\tsectionandpart{Ping}

\begin{slide}{Software tools: \texttt{ping}}
  \begin{itemize}
  \item Most useful check of connectivity
  \item Universal
  \item If \textbf{\texttt{ping}} hostname, includes a rough check of
    \DNS
  \item Sends an \ICMP (Internet Control Message Protocol)
  \texttt{ECHO\_REQUEST}
  \item Waits for an \ICMP \texttt{ECHO\_REPLY}
  \item Most \textbf{\texttt{ping}}s can display round trip time
  \item Most \textbf{\texttt{ping}}s can allow setting size of packet
  \item Can use to make a crude measurement of throughput---see
    \S\ref{sld:one-hop-throughput-measurement}
  \end{itemize}
\end{slide}

\begin{slide}[toc={Good \texttt{ping}, Bad \texttt{ping}?},bm={Good ping, Bad ping?}]%
  {What \texttt{ping} Result is Good, Bad?}
  \begin{itemize}
  \item A steady stream of consistent replies indicates probably okay
  \item Usually first reply takes longer due to \ARP lookups at each
    router
    \begin{itemize}
    \item After that, \ARP results are cached
    \end{itemize}
  \item \ICMP error messages can help understand results:
    \begin{itemize}
    \item Destination Network Unreachable indicates the host doing ping
      cannot reach the network
    \item Destination Host Unreachable may come from routers further away
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{How to Use \texttt{ping}?}
  \begin{itemize}
  \item Ensure local host networking is enabled first: ping localhost,
    local \IP address
  \item ping a known host on local network
  \item ping local and remote interfaces on router
  \item ping by IP as well as by hostname if hostname ping fails
    \begin{itemize}
    \item confirm DNS with \textbf{\texttt{dig}} (or
      \textbf{\texttt{nslookup}}) --- see slide~\S\ref{sld:dns-troubleshooting}
    \end{itemize}
  \item Ping from more than one host
\end{itemize}
\end{slide}

\begin{slide}{\texttt{fping}: flood ping}
  \begin{itemize}
  \item Designed to test a large number of hosts
  \item more efficient than \texttt{ping}
  \item Used extensively by monitoring software such as \texttt{mon}:
    \url{http://www.kernel.org/software/mon/}, \textbf{\red{}nagios}:
    \url{http://www.nagios.org/}
  \item take care not to flood too much!
  \item \RPM{}s are available; I built one (a long time ago) and put
    it on ictlab under $\sim$ftp/pub/redhat/contrib
  \end{itemize}
\end{slide}  

\begin{slide}[toc=hping2,bm=hping]%
  {\texttt{hping2}: ping anything with anything}
  \begin{itemize}
  \item able to send custom TCP/IP packets and
  \item display target replies like ping program does with \ICMP
    replies.
  \item Can install with
\begin{alltt}
$ \textbf{yum -y install hping2}     
\end{alltt}%$
on Fedora Core 1.
\item See \url{http://www.hping.org/}.
  \end{itemize}
\end{slide}  

\begin{slide}{\texttt{arping}: uses ARP requests}
  \begin{itemize}
  \item Limited to local network
  \item Can work with \MAC or \IP addresses
  \item use to probe for \ARP entries in router (very useful!)
  \item packet filtering
    \begin{itemize}
    \item can block \ICMP pings, but
    \item won't block \ARP requests
    \end{itemize}
  \end{itemize}
\end{slide}

\tsection{\texttt{traceroute}}

\begin{slide}{Path Discovery: \texttt{traceroute}}
  \begin{itemize}
  \item Sends \UDP packets
    \begin{itemize}
    \item (Microsoft \texttt{tracert} sends \ICMP packets)
    \end{itemize}
  \item increments Time to Live (\TTL) in \IP packet header
  \item Sends three packets at each \TTL
  \item records round trip time for each
  \item increases \TTL until enough to reach destination
  \end{itemize}
\end{slide}  

\begin{slide}{\texttt{traceroute}: How it Works}
  \begin{itemize}
  \item As \IP packets pass through each router, \TTL in \IP header is
    decremented
  \item Packet is discarded when TTL decrements to 0
  \item ROUTER sends \ICMP \texttt{TIME\_EXCEEDED} message back to
    traceroute host
  \item When \UDP packet reaches destination, gets \ICMP
    \texttt{PORT\_UNREACHABLE}, since uses an unused high \UDP port
  \end{itemize}
\end{slide}  


\begin{slide}{\texttt{traceroute}  Limitations}
  \begin{itemize}
  \item Each router has a number of \IP addresses
  \item but \texttt{traceroute} only shows the one it used
  \item get different addresses when run \texttt{traceroute} from other end
  \item sometimes route is asymmetric
  \item router may be configured to not send \ICMP
    \texttt{TIME\_EXCEEDED} messages
    \begin{itemize}
    \item get stars: \texttt{*} instead of round-trip time in
      \textbf{\texttt{traceroute}} output
    \end{itemize}
  \end{itemize}
\end{slide}

\tsection{Measurements}

\begin{slide}{Performance Measurements: delay}
  \begin{itemize}
  \item Three sources of delay:
  \item \emphcolour{transmission delay} --- time to put signal onto
    cable or media
    \begin{itemize}
    \item depends on transmission rate and size of frame
    \end{itemize}
  \item \emphcolour{propagation delay} --- time for signal to travel
    across the media
    \begin{itemize}
    \item determined by type of media and distance
    \end{itemize}
  \item \emphcolour{queuing delay} --- time spent waiting for
    retransmission in a router
  \end{itemize}
\end{slide}

\begin{slide}[toc=bandwidth and throughput,%
  bm=bandwidth and throughput]%
  {Is Bandwidth == Throughput?}
  \begin{itemize}
  \item \emphcolour{bandwidth} --- the difference between the upper
    frequency and the lower frequency that a channel can carry
    \begin{itemize}
    \item measured in Hertz
    \end{itemize}
  \item \emphcolour{throughput} --- amount of data that can be sent
    over link in given time
    \begin{itemize}
    %\item relates to all causes of delay
    \item is {\blue{}not the same as bandwidth}, which really has no
      direct meaning with digital information
    \end{itemize}
  \item bandwidth is related to throughput by the Shannon-Hartley
    Theorem; throughput $\propto$ bandwidth if signal to noise ratio
    is fixed:
    \begin{align*}
      C_{\text{max}} &= B\log_2\left(1 + \frac{S}{N}\right) \text{
        bits/sec}\\[0.7ex]
      \text{where $C_{\text{max}}$} &= \text{maximum channel
        capacity,}\notag\\
      B &= \text{bandwidth in Hz,}\notag\\
      S &= \text{signal power in W,}\notag\\
      N &= \text{noise power in W.}\notag
    \end{align*}
  \end{itemize}
\end{slide}

\begin{slide}{Quality of a Link}
  \begin{itemize}
  \item Other measurements needed
    \begin{itemize}
    \item i.e., for quality of service for multimedia
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}[toc=Throughput: \texttt{ping},bm=Throughput: ping]%
  {\texttt{ping} \emph{Roughly} Estimating Throughput}
  \label{sld:one-hop-throughput-measurement}
\begin{itemize}
\item Example: measuring throughput {\blue{}between \emphcolour{this}
    machine and \emphcolour{one remote} \blue{}machine.}
\item ping with packet size = {\red{}100 bytes}, round-trip time =
  {\red{}30ms}
\item ping with packet size = {\red{}1100 bytes}, round-trip time =
  {\red{}60ms}
\item So takes 30ms extra ({\red{}15ms one way}) to send additional
  {\green{}1000 bytes}, or {\red{}8000 bits}
\item Throughput is \emphcolour{roughly} {\blue{}8000 bits per 15ms},
  or about 530,000 bits per second
\item A \emphcolour{very crude} measurement:
  \begin{itemize}
  \item no account for other traffic, treats all links on path, there
    and back, as one.
  \item Routers sometimes send packets onwards with much higher
    priority than with which they answer pings.  See
    slide~\S\ref{sld:limitations-of-ping}.
  \end{itemize}
\end{itemize}
\end{slide}


\begin{slide}[toc=Througput: \texttt{ping} One,bm=Throughput: ping One]%
  {Throughput: \texttt{ping} One Remote Host}
\begin{itemize}
\item This can be expressed as a simple formula:
  \begin{align*}
    TP &= 16 \times \frac{P_l - P_s}{t_l - t_s} \text{\  bits per second,
      where}\\
    P_l &= \text{size of large packet} \\
    P_s &= \text{size of small packet} \\
    t_l &= \text{round-trip time for large packet} \\
    t_s &= \text{round-trip time for small packet} \\[-2ex]
    \intertext{Here we have:}\\[-10mm]
    TP &= 16 \times \frac{1100 - 100}{(60 - 30) \times 10^{-3}}\\
    &= 16 \times \frac{1000}{30 \times 10^{-3}}\\
    &= \frac{16}{30} \times 10^{6}\\
  &\approx 530{,}000 \text{ bps}\\
  \end{align*}
\end{itemize}
\end{slide}

\begin{slide}[toc=Throughput \texttt{ping} 2 remote,%
  bm=Throughput ping 2 remote]%
  {Throughput: \texttt{ping} Two Remote Hosts}
  \label{sld:ping-2-remote-hosts-throughput}
  \begin{itemize}
  \item Measure throughput {\red{}between two remote hosts}: may use
    tools like \texttt{ping}
  \item ping two locations with two packet sizes (4 pings altogether,
    minimum)
    \begin{itemize}
    \item Many ping programs calculate average ping time: better to
      make a number of pings, use the average ping time.
    \item First ping time may be longer due to the time to get an
      answer to the \texttt{arp} request
    \item May be better to ping once, then start pinging again, and
      use the average ping time.
    \end{itemize}
  \item Example:
  \end{itemize}
  \begin{tabular}[t]{@{}lll@{}}
    \toprule%
    \textbf{Address} & \textbf{RTT 100 bytes} & \textbf{RTT 1100
      bytes} \\
    \midrule%
    205.153.61.1 & 1.380\,ms & 5.805\,ms \\
    205.153.60.2 & 4.985\,ms & 12.823\,ms \\
    165.166.36.17 & 8.621\,ms & 26.713\,ms \\
    \bottomrule
  \end{tabular}
\end{slide}

\begin{slide}[toc=Throughput \texttt{ping} 2 remote,%
  bm=Throughput ping 2 remote]%
  {Throughput: \texttt{ping} Two Remote Hosts --- 2}
  \label{sld:ping-2-remote-hosts-throughput-2}
  \vspace*{-2ex}\par
  {\footnotesize
    \begin{tabular}[t]{@{}lll@{}}
      \toprule%
      \textbf{Address} & \textbf{RTT 100 bytes} & \textbf{RTT 1100
        bytes} \\
      \midrule%
      205.153.61.1 & 1.380\,ms & 5.805\,ms \\
      205.153.60.2 & 4.985\,ms & 12.823\,ms \\
      165.166.36.17 & 8.621\,ms & 26.713\,ms \\
      \bottomrule
    \end{tabular}
  }
  \par\medskip\par%
  \begin{itemize}
  \item Time difference / 2 (round trip time (RTT) $\to$ one way)
  \item Divide by size difference in bits: $8000 = 8 \times (1100 - 100)$
  \item Multiply by 1000 (ms $\to$ seconds)
  \item $\text{Mbs} = \text{bps} / 10^{6}$
  \end{itemize}
  \begin{tabularx}{\slideWidth}[t]{@{}YYYY@{}}
    \toprule%
    \textbf{Near link} & \textbf{Far link} & \textbf{Time difference}
    & \textbf{Est. Throughput}\\
    \midrule%
    205.153.61.1 & 205.153.60.2  & 3.413\,ms  & 4.69\,Mbps \\
    205.153.60.2 & 165.166.36.17 & 10.254\,ms & 1.56\,Mbps \\
    \bottomrule
  \end{tabularx}
  \begin{align*}
    3.413\,\text{ms} &= (12.823 - 4.985) - (5.805 - 1.380)\,\text{ms}\\
    10.254\,\text{ms} &= (26.713 - 8.621 ) - ( 12.823 - 4.985)\,\text{ms}
  \end{align*}
\end{slide}

\begin{slide}[toc=Throughput \texttt{ping} 2 remote,%
  bm=Throughput ping 2 remote]%
  {Throughput: \texttt{ping} Two Remote Hosts --- 3}
  \label{sld:ping-2-remote-hosts-throughput-3}
  \begin{align*}
    TP &= 16 \times \frac{P_l - P_s}{t_{fl} - t_{fs} - t_{nl} +
      t_{ns}} \quad \text{bits per second} \intertext{where:}
    P_l &= \text{\textbf{\emph{l}}arge packet size, bytes} \\
    P_s &= \text{\textbf{\emph{s}}mall packet size, bytes} \\
    t_{nl} &= \text{ping time for \textbf{\emph{l}}arger packet to the
      \textbf{\emph{n}}ear link, seconds} \\
    t_{ns} &= \text{ping time for \textbf{\emph{s}}maller packet to
      the \textbf{\emph{n}}ear link, seconds} \\
    t_{fl} &= \text{ping time for \textbf{\emph{l}}arger packet to the
      \textbf{\emph{f}}ar link, seconds} \\
    t_{fs} &= \text{ping time for \textbf{\emph{s}}maller packet to
      the \textbf{\emph{f}}ar link, seconds} \\
\end{align*}
\end{slide}

\begin{slide}[toc=Throughput \texttt{ping} 2 remote,%
  bm=Throughput ping 2 remote]%
  {Throughput: \texttt{ping} Two Remote Hosts --- 4}
  \label{sld:ping-2-remote-hosts-throughput-4}
  \vspace*{-3ex}\par%
  \scriptsize
  \begin{align*}
    P_l &= \text{\textbf{\emph{l}}arge packet size, bytes} = 1100\,\text{bytes}\\
    P_s &= \text{\textbf{\emph{s}}mall packet size, bytes} = 100\,\text{bytes}\\
    t_{nl} &= \text{ping time for \textbf{\emph{l}}arger packet to the
      \textbf{\emph{n}}ear link, seconds} \\
    &= 5.805 \times 10^{-3}\,\text{seconds}\\
    t_{ns} &= \text{ping time for \textbf{\emph{s}}maller packet to
      the \textbf{\emph{n}}ear link, seconds} \\
    &= 1.380 \times 10^{-3}\,\text{seconds}\\
    t_{fl} &= \text{ping time for \textbf{\emph{l}}arger packet to the
      \textbf{\emph{f}}ar link, seconds} \\
    &= 12.823 \times 10^{-3}\,\text{seconds}\\
    t_{fs} &= \text{ping time for \textbf{\emph{s}}maller packet to
      the \textbf{\emph{f}}ar link, seconds} \\
    &= 4.985 \times 10^{-3}\,\text{seconds}\\
    TP &= 16 \times \frac{P_l - P_s}{t_{fl} - t_{fs} - t_{nl} +
      t_{ns}} \quad \text{bits per second}\\
    &= 16 \times%
    \frac{1100 - 100}{(12.823 - 4.985 - 5.805 + 1.380) \times 10^{-3}}
    \quad \text{bits per second}\\
    &= 16 \times \frac{1000}{3.413 \times 10^{-3}}\\
    &\approx 4{,}687{,}958\\
    &\approx 4.69\,\text{Megabits per second}
  \end{align*}
\end{slide}

\begin{slide}[toc=Throughput \texttt{ping} 2 remote,%
  bm=Throughput ping 2 remote]%
  {Throughput: \texttt{ping} Two Remote Hosts --- 5}
  \label{sld:ping-2-remote-hosts-throughput-5}
  \vspace*{-3ex}\par%
  \scriptsize
  \begin{align*}
    P_l &= \text{\textbf{\emph{l}}arge packet size, bytes} = 1100\,\text{bytes}\\
    P_s &= \text{\textbf{\emph{s}}mall packet size, bytes} = 100\,\text{bytes}\\
    t_{nl} &= \text{ping time for \textbf{\emph{l}}arger packet to the
      \textbf{\emph{n}}ear link, seconds} \\
    &= 12.823 \times 10^{-3}\,\text{seconds}\\
    t_{ns} &= \text{ping time for \textbf{\emph{s}}maller packet to
      the \textbf{\emph{n}}ear link, seconds} \\
    &= 4.985 \times 10^{-3}\,\text{seconds}\\
    t_{fl} &= \text{ping time for \textbf{\emph{l}}arger packet to the
      \textbf{\emph{f}}ar link, seconds} \\
    &= 26.713 \times 10^{-3}\,\text{seconds}\\
    t_{fs} &= \text{ping time for \textbf{\emph{s}}maller packet to
      the \textbf{\emph{f}}ar link, seconds} \\
    &= 8.621 \times 10^{-3}\,\text{seconds}\\
    TP &= 16 \times \frac{P_l - P_s}{t_{fl} - t_{fs} - t_{nl} +
      t_{ns}} \quad \text{bits per second}\\
    &= 16 \times%
    \frac{1100 - 100}{(26.713 - 8.621 - 12.823 + 4.985) \times 10^{-3}}
    \quad \text{bits per second}\\
    &= 16 \times \frac{1000}{10.254 \times 10^{-3}}\\
    &\approx 1{,}560{,}366\\
    &\approx 1.56\,\text{Megabits per second}
  \end{align*}
\end{slide}

\begin{slide}[toc=Limitations of \texttt{ping},bm=Limitations of
    ping]%
    {Limitations of measuring with \texttt{ping}}
    \label{sld:limitations-of-ping}
    \begin{itemize}
    \item Most modern routers give {\blue{}high priority to routing}
      \begin{itemize}
      \item Expecially switching routers, such as the Cisco 6509 in
        our Campus
      \item Many give much {\blue{}lower priority to answering pings}
      \item The difference can be so great that the ping reply
        sometimes comes sooner from a more distant router, which
        according to our formula, indicates a {\green{}negative
          throughput!}
      \item Do not blindly apply this formula!
      \end{itemize}
    \item Measurements may not match the kind of traffic created by
      the application you support
    \item The big \emphcolour{advantages} of these \ICMP measurements
      are:
      \begin{itemize}
      \item you do not need access to the machines, and
      \item you do not need to install any special software on them.
      \end{itemize}
    \end{itemize}
\end{slide}

\begin{slide}{Path Performance: Other tools}
  \begin{itemize}
  \item Could use a tool like \texttt{pathchar}, \texttt{bing},
    \texttt{clink}, \texttt{pchar}, or \texttt{tmetric} that performs
    this calculation for you
  \item Use \url{http://www.google.com/} to locate these tools
  \item \texttt{pathchar} is only available in binary form
  \item Others in source form, need compile with commands something
  like this:
\begin{alltt}
$ \textbf{cd bing-1.1.3}
$ \textbf{make}
$ \textbf{sudo make install}
\end{alltt}%$
  \end{itemize}
\end{slide}

\begin{slide}[toc=\texttt{pathchar},bm=pathchar]%
  {Path measurement with \texttt{pathchar}}
  \ptsize{12}%
\begin{alltt}\tiny
$ \textbf{sudo ./pathchar sina.com.hk}
pathchar to sina.com.hk (202.85.139.140)
 can't find path mtu - using 1500 bytes.
 doing 32 probes at each of 45 sizes (64 to 1500 by 32)
 0 localhost (127.0.0.1)
 |   106 Mb/s,   293 us (698 us),  +q 1.18 ms (15.7 KB)
 1 172.19.35.246 (172.19.35.246)
 |    28 Mb/s,   488 us (2.10 ms)
 2 192.168.83.2 (192.168.83.2)
 3  * 1   448 798       2
 |    20 Mb/s,   273 us (3.25 ms)
 4 cw7204.vtc.edu.hk (202.40.210.220)
 |   6.8 Mb/s,   521 us (6.04 ms)
 5 210.176.123.37 (210.176.123.37)
 |    52 Mb/s,   20 us (6.31 ms)
 6 210.87.254.61 (210.87.254.61)
 |   136 Mb/s,   116 us (6.63 ms)
 7 g5-0-0.wttbr01.imsbiz.com (210.87.254.129)
 |    33 Mb/s,   0.94 ms (8.88 ms),  +q 1.48 ms (6.10 KB) *6
 8 iadvantage3-RGE.hkix.net (202.40.161.172)
 |   164 Mb/s,   45 us (9.04 ms),  +q 1.74 ms (35.6 KB) *6
 9 v005-m02.hk01.iadvantage.net (202.85.129.53)
 |   ?? b/s,   -66 us (8.88 ms)
10 202.85.129.136 (202.85.129.136)
 |   ?? b/s,   459 us (9.79 ms)
11 202.85.139.11 (202.85.139.11)
11 hops, rtt 6.18 ms (9.79 ms), bottleneck 6.8 Mb/s, pipe 9361 bytes
\end{alltt}%$
\end{slide}

\begin{slide}{Measuring Throughput}
  \begin{itemize}
  \item May use \textbf{\texttt{\red{}ftp}} to transfer a large file,
    measure time
    \begin{itemize}
    \item tests whole path
    \item problem: affected by disk \IO, \texttt{xinetd}
    \end{itemize}
  \item May use a \emphcolour{web browser} and measure download time
    \begin{itemize}
    \item Problem: may be affected by caching in the web browser
    \item May be affected by caching in web proxies
    \end{itemize}
  \item \emphcolour{Better}: measure using traffic similar to that
    created by the application.
  \end{itemize}
\end{slide}

\begin{slide}{Measuring Throughput with \texttt{ttcp}}
\begin{itemize}
  \item Use \textbf{\texttt{\red{}ttcp}}, not affected by disk \IO
  \item Consists of a client and server
  \item Need have installed at both ends
  \item Part of Red Hat Linux, Cisco \IOS
  \item Example: first, start receiver on \texttt{ictlab}:
\begin{alltt}\scriptsize
$ \textbf{ttcp -r -s}
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 172.19.32.30
ttcp-r: 16777216 bytes in 1.45 real seconds = 11285.88 KB/sec +++
ttcp-r: 9704 I/O calls, msec/call = 0.15, calls/sec = 6684.46
ttcp-r: 0.0user 0.2sys 0:01real 14\% 0i+0d 0maxrss 0+2pf 0+0csw
\end{alltt}%$
  \item Second, start transmitter on nickpc:
\begin{alltt}\scriptsize
$ \textbf{ttcp -t -s ictlab}
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> ictlab
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 1.45 real seconds = 11335.64 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 0.72, calls/sec = 1416.95
ttcp-t: 0.0user 0.0sys 0:01real 4\% 0i+0d 0maxrss 0+2pf 0+0csw
\end{alltt}%$
  \end{itemize}
\end{slide}

\tsectionandpart{iproute}

\begin{slide}{The \texttt{ip} program, iproute}
  \begin{itemize}
  \item The \texttt{ip} program in the iproute package provides
    complete control over \TCPIP networking in a Linux system
  \item Provides more networking control facilities than other \TCPIP
    implementations
  \item Supports tunneling in many forms
  \item iproute documentation is in two manuals, one for \IP routing,
    the other for tunnelling
  \end{itemize}
\end{slide}

\begin{slide}{iproute and \texttt{iptables}}
  \begin{itemize}
  \item Between these software packages, you can:
    \begin{itemize}
    \item throttle bandwidth for certain computers
    \item throttle bandwidth to certain computers
    \item fairly share bandwidth
    \item protect your network from DoS attacks
    \item protect Internet from your customers
    \item multiplex many servers into one, for load balancing or for high availability
    \item restrict access to your computers
    \item limit access of your users to other hosts
    \item do routing based on user id, \MAC address, source \IP, port,
      type of service, time of day or content
    \end{itemize}
  \item See the Linux Advanced Routing and Traffic Control HOWTO at
    \url{http://tldp.org} for details
  \end{itemize}
\end{slide}  

\begin{slide}{Traffic Measurements: \texttt{netstat -i}}
  \begin{itemize}
  \item The \texttt{netstat} program can show statistics about network interfaces
  \item Linux \texttt{netstat} shows lost packets in three categories:
    \begin{itemize}
    \item errors,
    \item drops (queue full: shouldn't happen!)
    \item overruns (last data overwritten by new data before old data
      was read: shouldn't happen!)
    \item drops and overruns indicate faulty flow control --- bad!
    \end{itemize}
  \item These values are cumulative (since interface was up)
  \item Could put a load on interface to see current condition, with
  \texttt{ping -l}, to send large number of packets to destination
  \item See the difference in values
  \end{itemize}
\end{slide}

\begin{slide}{Measuring Traffic: \texttt{netstat -i}}
  \begin{itemize}
  \item Here we run \texttt{netstat -i} on \texttt{ictlab}:
\begin{alltt}
$ \textbf{netstat -i}
Kernel Interface table\tiny
Iface  MTU Met     RX-OK RX-ERR RX-DRP RX-OVR      TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0  1500   0 407027830      0      0      0 1603191764      0      0      {\red3} BMRU
lo   16436   0   2858402      0      0      0    2858402      0      0      0 LRU
\end{alltt}%$
\item Notice that of the 1.6 billion bytes transmitted, there were 3
  overuns.
\item Next, blast the path you want to test with packets using
  \texttt{ping -l} or the \texttt{spray} program, and measure again.
\end{itemize}
\end{slide}

\begin{slide}{Traffic measurements: \texttt{ifconfig}, \texttt{ip}}
\begin{itemize}
\item \texttt{ifconfig} and \texttt{ip} give more information than
  \texttt{netstat~-i}:
\end{itemize}
\begin{alltt}\scriptsize
$ \textbf{ifconfig eth0}
eth0      Link encap:Ethernet  HWaddr 00:00:E2:35:AF:EE
          inet addr:172.19.64.52  Bcast:172.19.127.255  Mask:255.255.192.0
          IPX/Ethernet 802.2 addr:33001601:0000E235AFEE
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:407579600 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1605655688 errors:0 dropped:0 overruns:3 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3055300191 (2913.7 Mb)  TX bytes:2048217058 (1953.3 Mb)
          Interrupt:18 Base address:0xd000
$ \textbf{ip -s link list eth0}
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:00:e2:35:af:ee brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    3058362227 407610495 0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    2140511920 1605768150 0       0       0       0
\end{alltt}
\end{slide}

\begin{slide}{Getting more info using \texttt{ip}}
\begin{itemize}
\item The \texttt{-s} (\texttt{-statistics}) option to \texttt{ip}
  provides statistics.  Adding a second gives you even more:
\begin{alltt}\scriptsize
$ \textbf{ip -s -s link list eth0}
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:00:e2:35:af:ee brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets   errors  dropped overrun mcast
    3070792102 407726727  0       0       0       0
    RX errors: length    crc     frame   fifo    missed
               0          0       0       0       0
    TX: bytes  packets   errors  dropped carrier collsns
    2445799644 1606151878 0       0       0       0
    TX errors: aborted   fifo    window  heartbeat
               0          3       0       0
\end{alltt}%$
  \end{itemize}
\end{slide}

\begin{slide}[toc=Guide to \texttt{ip} 1,bm=Guide to ip 1]%
  {Quick Guide to using \texttt{ip}: set up interface}
\begin{itemize}
\item Here we set up a network interface and give it the IP address
  192.168.0.1/24:
\begin{alltt}
$ \textbf{ip link set dev eth1 up}
$ \textbf{ip addr add 192.168.0.1/24 brd + dev eth1}
\end{alltt}
\item Two important points:
  \begin{itemize}
  \item If you do not specify the netmask, a netmask of /32 is assumed
  \item \textbf{\texttt{brd +}} means obtain broadcast address by setting the host bits
  \end{itemize}
\end{itemize}
\end{slide}

\begin{slide}[toc=Guide to \texttt{ip} 2,bm=Guide to ip 2]%
  {Quick Guide to using \texttt{ip}: set up routes}
\begin{alltt}
$ \textbf{ip route add default dev eth1 via 192.168.0.254}
$ \textbf{ip route add 192.168.1.0/24 via 192.168.0.10}
\end{alltt}
  \begin{itemize}
  \item The last adds a static route to another network
  \item the first adds the default route.
  \item You can omit the device if the network can be reached through
    a particular interface without any ambiguity
    \begin{itemize}
    \item I.e., \texttt{ip} is smart enough to figure out which
      network device to use, though specifying it doesn't hurt.
    \end{itemize}
  \end{itemize}
\end{slide}

\tsectionandpart[toc=Packet Capture,bm=Packet Capture]%
{Packet Capture\\[3ex]\texttt{tcpdump}, Ethereal and Ntop}

\begin{slide}{What is Packet Capture?}
  \label{sld:packet-capture}
  \begin{itemize}
  \item Real time collection of data as it travels over networks
  \item Tools called:
    \begin{itemize}
    \item packet sniffers
    \item packet analysers
    \item protocol analysers, and sometimes even
    \item traffic monitors
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{When Packet Capture?}
  \begin{itemize}
  \item Most powerful technique
  \item When need to see what client and server are actually saying to each other
  \item When need to analyse type of traffic on network
  \item Requires understanding of network protocols to use effectively
  \end{itemize}
\end{slide}

\begin{slide}{Warning: Don't Get Sacked!}
  \begin{itemize}
  \item Be sure that your boss agrees with you capturing packets on
    your company's network
  \item People have been sacked for doing this without permission!
  \item Some have suffered long lawsuits and \emphcolour{criminal records}:
    \begin{itemize}
    \item See \url{http://www.stonehenge.com/merlyn/}, and
    \url{http://www.lightlink.com/spacenka/fors/} for a famous example
    \end{itemize}
  \item {\mbox{}\blue{}Do not invade the \emphcolour{privacy}
      \blue{}of others}
    \begin{itemize}
    \item Capturing passwords with insecure protocols such as telnet,
      ftp, http (that is not encrypted with \TLS) is very easy
      \begin{itemize}
      \item DON'T DO IT!
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{\texttt{tcpdump}}
  \begin{itemize}
  \item Available everywhere
  \item Windows: \url{http://windump.polito.it/}
  \item Syntax also used by other programs (such as Ethereal)
  \item Often it is the only tool available, so good to know
  \item Works by putting network interface into
    \emphcolour{promiscuous} mode
    \begin{itemize}
    \item normal Ethernet interface will ignore packets not addressed
      to it
    \item in \emphcolour{promiscuous mode}, will examine
      \emphcolour{all packets} that arrive, even those not addressed
      to it
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{How to use \texttt{tcpdump}}
  \begin{itemize}
  \item Can just type its name (as root):
\begin{alltt}
$ \textbf{sudo tcpdump}
\end{alltt}%$
\item \ldots{}but get a huge amount of data!
\item Can restrict the data collected using a \emphcolour{filter}
\item A filter may select addresses, protocols, port numbers,\,\ldots
\end{itemize}
\end{slide}

\begin{slide}{\texttt{tcpdump}: some options}
\begin{description}
\item[\texttt{-c } \meta{n}] capture a \underline{c}ount of \meta{n} packets then stop
\item[\texttt{-w } \meta{file}] \underline{w}rite raw data to
  \meta{file}.
  \begin{itemize}
  \item Very useful --- can filter and analyse this later with
    \texttt{tcpdump}, \texttt{ethereal} or other tools
  \item but you cannot see what you are capturing till later!
  \end{itemize}
\item[\texttt{-i } \meta{interface}] collect from \meta{interface}
  instead of lowest numbered network \underline{i}nterface
\item[\texttt{-s } \meta{bytes}] collect no more than \meta{bytes} of
  data from each packet instead of default 68 bytes
\item[\texttt{-e}] show link level info, e.g., \underline{E}thernet addresses
\item[\texttt{-x }] gives a he\underline{x}adecimal dump of packets
\item[] excluding link level data
\item[\texttt{-X}] display \ASCII as well as hexadecimal if have
  \texttt{-x} option too
\item Many more options: \texttt{man tcpdump}
\end{description}
\end{slide}

\begin{slide}{\texttt{tcpdump}  Filters: host and port}
  \begin{itemize}
  \item Show all network traffic to and from 192.168.0.1:
\begin{alltt}
$ \textbf{tcpdump host 192.168.0.1}
\end{alltt}%$
  \item Show packets to 192.168.0.1:
\begin{alltt}
$ \textbf{tcpdump dst 192.168.0.1}
\end{alltt}%$
  \item Show packets to port 68 on 192.168.0.1:
\begin{alltt}
$ \textbf{tcpdump dst 192.168.0.1 and port 68}
\end{alltt}%$
  \end{itemize}
\end{slide}

\begin{slide}{\texttt{tcpdump} filters: networks}
  \begin{itemize}
  \item Capture traffic to or from 205.153.60/24:
\begin{alltt}
$ \textbf{tcpdump net 172.19.64/18}
\end{alltt}%$
  \item can specify network as source or destination:
\begin{alltt}
$ \textbf{tcpdump src net 205.153.60/24}
$ \textbf{tcpdump dst net 172.19.64/18}
\end{alltt}
  \end{itemize}
\end{slide}


\begin{slide}{\texttt{tcpdump} filters: protocol}
  \begin{itemize}
  \item \texttt{tcpdump ip}
  \item \texttt{tcpdump tcp}
  \item \texttt{tcpdump ip proto ospf}
  \item This will catch DNS name lookups, but not zone transfers (which use tcp):
  \item \texttt{tcpdump udp port 53}
  \end{itemize}
\end{slide}

\begin{slide}{\texttt{tcpdump} filters: combining}
  \begin{itemize}
  \item This will not work as you might expect:
  \item \texttt{tcpdump host ictlab and udp or arp}
  \item Instead, need group with parentheses, and quote:
  \item \textbf{\texttt{tcpdump "host ictlab and (udp or arp)"}}
  \item many more ways of filtering: \texttt{man tcpdump}
  \end{itemize}
\end{slide}

\begin{slide}{Writing data to a file}
\begin{alltt}
$ \textbf{sudo tcpdump -c 1000 -w \(\sim\)/tmp/tcpdump.pcap}
tcpdump: listening on eth0
1014 packets received by filter
0 packets dropped by kernel
\end{alltt}%$
\end{slide}

\begin{slide}{Reading a Dumped File}
\begin{alltt}\scriptsize
$ \textbf{tcpdump -nr \(\sim\)/tmp/tcpdump.pcap arp}\scriptsize
22:32:41.751452 arp who-has 172.19.127.254 tell 172.19.127.29
22:32:41.863173 arp who-has 172.19.64.52 tell 172.19.64.63
22:32:41.863198 arp reply 172.19.64.52 is-at 0:0:e2:35:af:ee
22:32:42.082584 arp who-has 172.19.65.16 tell 172.19.125.229
22:32:43.113655 arp who-has 172.19.123.211 tell 172.19.65.2
22:32:44.635149 arp who-has 172.19.65.16 tell 172.19.127.106
22:32:44.874117 arp who-has 172.19.65.6 tell 172.19.126.174
22:32:45.147178 arp who-has 172.19.65.16 tell 172.19.126.240
22:32:45.209507 arp who-has 172.19.127.254 tell 172.19.125.127
22:32:45.212484 arp who-has 172.19.127.175 tell 172.19.125.127
22:32:45.239445 arp who-has 172.19.127.254 tell 172.19.125.212
22:32:45.455863 arp who-has 172.19.65.16 tell 172.19.126.194
22:32:45.540507 arp who-has 172.19.126.50 (44:30:54:59:43:4d)
 tell 172.19.65.10
22:32:45.562004 arp who-has 172.19.126.50 tell 172.19.65.2
\end{alltt}%$
\end{slide}

\begin{slide}{HTTP}
\begin{alltt}\scriptsize
$ \textbf{tcpdump -nr \(\sim\)/tmp/tcpdump.pcap port http}
22:43:32.633636 192.168.25.9.14075 > 172.19.64.52.http:
 S 1015952778:1015952778(0) win 6144 <mss 1460> (DF)
22:43:32.633693 172.19.64.52.http > 192.168.25.9.14075:
 S 1929920485:1929920485(0) ack 1015952779 win 5840
 <mss 1460> (DF)
22:43:32.635828 192.168.25.9.14075 > 172.19.64.52.http:
 P 1:590(589) ack 1 win 6144 (DF)
22:43:32.635906 172.19.64.52.http > 192.168.25.9.14075:
 . ack 590 win 6479 (DF)
22:43:32.636758 172.19.64.52.http > 192.168.25.9.14075:
 P 1:217(216) ack 590 win 6479 (DF)
22:43:32.636982 172.19.64.52.http > 192.168.25.9.14075:
 F 217:217(0) ack 590 win 6479 (DF)
22:43:32.639080 192.168.25.9.14075 > 172.19.64.52.http:
 R 590:590(0) ack 217 win 0 (DF)
\end{alltt}%$
\end{slide}

\begin{slide}{\texttt{tcpdump}: When reading TCP}
  \begin{itemize}
  \item format:
  \item src > dst: flags data-seqno ack window urgent options
  \item Flags are some combination of S (SYN), F (FIN), P (PUSH) or R
    (RST) or a single `\texttt{.}' (no flags).
  \item The first time tcpdump sees a tcp 'conversation', it prints
    the sequence number from the packet.
  \item On subsequent packets of the conversation, the difference
    between the current packet's sequence number and this initial
    sequence number is printed.
  \end{itemize}
\end{slide}

\begin{slide}{Window}
  \begin{itemize}
  \item \texttt{win} \meta{nnn} specifies data window the sending host
    will accept in future packets
    \begin{itemize}
    \item I.e., the maximum number of bytes
    \end{itemize}
  \item \TCP flow-control:
    \begin{itemize}
    \item host reduces this number if congested or overloaded
    \item will sometimes set to 0 to temporarily halt incoming traffic
      in this connection
    \end{itemize}
  \end{itemize}
\end{slide}

\tsectionandpart[toc=Ethereal,bm=Ethereal]%
{Ethereal\\King of the Packet Analysers!\\Available for Linux, Unix,
  Windows}

%% \begin{slide}{Ethereal}
%%   \begin{center}
%%     King of the Packet Analysers!
%%   \end{center}
%%   \begin{center}
%%     Available for Linux, Unix, Windows
%%   \end{center}
%% \end{slide}

\begin{slide}{Ethereal}
  \begin{itemize}
  \item Ethereal can read data captured by \texttt{tcpdump}, e.g.,
\begin{alltt}
$ \textbf{ethereal -r tcpdump.pca}
\end{alltt}%$
  \item or File $\to$ Open
  \item Can capture data itself
  \item Uses same filter language as \texttt{tcpdump}
  \end{itemize}
\end{slide}

%% \newcommand{\positionPicture}{
%%     \vspace*{-0.15\slideWidth}\par
%%     \hspace*{-0.1\slideWidth}%
%% }

\begin{wideslide}[toc=Ethereal Screenshot,bm=Ethereal Screenshot]{}
  \positionPictureOpt{-0.1\slideWidth}{-0.1\slideWidth}%
  \includegraphics[scale=0.5]{Screenshot-Ethereal-big-top-frame}
\end{wideslide}

\begin{slide}[toc=Ethereal Screenshot,bm=Ethereal Screenshot]{}
  %\includegraphics[width=\slideWidth]{Screenshot-Ethereal-capture}
  \positionPictureOpt{-0.15\slideWidth}{-0.1\slideWidth}%
  \includegraphics[scale=0.5]{Screenshot-Ethereal-capture}
\end{slide}

\begin{slide}{You can expand any protocol:}
  \setlength{\fboxsep}{0.4pt}
  \begin{itemize}
  \item If we click on the \fbox{+} next to \texttt{Bootstrap Protocol}, we
    can see the details of the DHCP Request:
  \end{itemize}
\end{slide}

\begin{wideslide}[toc=Ethereal 2,bm=Ethereal 2]{}
  %\includegraphics[width=\slideWidth]{Screenshot-Ethereal-1-big-middle-window}
  \positionPictureOpt{-0.1\slideWidth}{-0.1\slideWidth}%
  \includegraphics[scale=0.5]{Screenshot-Ethereal-1-big-middle-window}
\end{wideslide}

\begin{slide}{Display Filters}
  \begin{itemize}
  \item Note the box at the bottom of Ethereal for display filters
  \item Select only some of the packets captured for display
  \item see man ethereal and search for DISPLAY FILTER SYNTAX
  \item Different syntax than the syntax for capture filters
  \item Example:
  \item \texttt{ip.src==172.19.64.52 and ip.dest==172.19.64.57}
  \end{itemize}
\end{slide}

\begin{slide}{Tools $\to$ Follow TCP Stream}
  \begin{itemize}
  \item Can view the contents of an entire \TCP stream conversation, in
    \ASCII or in hexadecimal.
  \item Be careful not to invade your customers' privacy.
  \item Can use to check if a communications stream is
    \emphcolour{really} encrypted
\end{itemize}
\end{slide}

\begin{slide}[toc=Ntop,bm=Ntop]{Ntop: monitoring data at a point}
  \begin{itemize}
  \item The Ntop program:
    \begin{itemize}
    \item listens on a network interface
    \item puts an Ethernet interface into promiscuous mode and
    \item displays statistics through a web interface
    \end{itemize}
  \item Shows:
    \begin{itemize}
    \item percentages of protocols,
    \item which machines generate most traffic
    \item which traffic is purely local, which traffic comes from
      outside, which traffic goes from inside to outside of network
    \end{itemize}
  \end{itemize}
\end{slide}  

\begin{slide}[toc=Ntop,bm=Ntop]{Ntop: Installing}
  \begin{itemize}
\item Installation is pretty easy. On my Fedora Core 1 machine:
\end{itemize}
\begin{alltt}\footnotesize
$ \textbf{rpmbuild --rebuild ntop-3.0-0.src.rpm}
$ \textbf{sudo rpm -Uhv /home/nicku/RPM/RPMS/i386/ntop-3.0-0.i386.rpm}
$ \textbf{ls -l /etc/ntop.conf*}
-rwx------  1 root root 13203 Apr 27 03:47 /etc/ntop.conf.sample
$ \textbf{sudo cp -a /etc/ntop.conf.sample /etc/ntop.conf}
$ \textbf{sudo emacs /etc/ntop.conf &}
# temporarily comment out the line --daemon
$ \textbf{sudo  /usr/bin/ntop @/etc/ntop.conf -A}
$ \textbf{sudo service ntop start}
\end{alltt}%$

  \begin{itemize}
\item Then open the web browser on \path{http://localhost:3000/}
  \end{itemize}
\end{slide}

%% \begin{slide}{Ntop RPM}
%%   \begin{itemize}
%%   \item I have made an RPM package of \texttt{ntop}
%%     \begin{itemize}
%%     \item it's the best one available, or at least it was when I made
%%       it \texttt{:-)}
%%     \end{itemize}
%%   \item Can get from
%%     \path{/home/nfs/redhat/contrib/ntop-2.1.51-20021031nu2.i386.rpm}
%%     \begin{itemize}
%%     \item source rpm is there too
%%     \end{itemize}
%%   \item Or search for it on \url{http://rpmfind.net/}
%%   \item Note that you will be prompted for a password when you install it.
%%   \end{itemize}
%% \end{slide}

\tsectionandpart[toc=Switched Networks,bm=Switched Networks]%
{Switched Networks\\[3ex]Using Ethereal, \texttt{tcpdump},
  Ntop \\in a switched network}

\begin{slide}[toc=Port Monitoring,bm=Port Monitoring]%
  {Port Monitoring: Switched Networks}
  \label{sld:port-monitoring}
  \begin{description}
  \item[Problem:]\mbox{}
    \begin{itemize}
    \item a switched network is really a point-to-point network
    \item You cannot normally capture the unicast traffic from other
      hosts on a single switch port
    \item {\mbox{}\blue{}How do you use Ethereal, \texttt{tcpdump} or
        Ntop to monitor traffic between a number of hosts?}
    \end{itemize}
  \item[Solution:] many switches support \emphcolour{port monitoring},
      where one port can monitor all traffic on a specified VLAN
    \item[Example:]\mbox{}
    \begin{itemize}
    \item Cisco 3500XL switches provide the
      \textbf{\texttt{port monitor}} command:
    \item \textbf{\texttt{port monitor vlan VLAN1}}
    \end{itemize}
  \end{description}
\end{slide}

\begin{slide}{How monitor one machine?}
  \begin{itemize}
  \item You are asked to check out a server on a switched network: The
    switch does not support port monitoring
    (\S\ref{sld:port-monitoring}), or you do not have administrative
    access to the switch: what to do?
  \item Use a small hub, and use a notebook running the capture software
  \end{itemize}
  \centering%
  \includegraphics[width=0.6\slideWidth]{hub-switch-monitor.eps}
\end{slide}

\begin{slide}{Are switched networks secure?}
  \begin{itemize}
  \item Is all unicast traffic on one port of a switch private?
  \item No, there are tools (\texttt{dsniff} and \texttt{Ettercap})
    freely available to automate \ARP spoofing and man-in-the-middle
    attacks, that provide various ways to compromise switch security.
  \end{itemize}
\end{slide}

\tsectionandpart{Port Scanning}

\begin{slide}{What is a port scanner?}
  \begin{itemize}
  \item Sends packets to various ports on a network device
  \item Best one available everywhere is nmap
  \item can identify the OS of the target machine
  \item Do not port scan arbitrary machines in your company's network
    without permission!
  \item May be interpreted as a cracking attempt
  \end{itemize}
\end{slide}

\begin{slide}{How does \texttt{nmap} identify OS?}
  \begin{itemize}
  \item \RFC{}s leave interpretation of some things up to the implementer
  \item \RFC{}s do not specify how should work if get contradictory
    flags, strange sequences of inconsistent packets
  \item Most \TCPIP implementations are not complete
  \item Every implementation of \TCPIP is different; the ``grey areas''
    are different from one \OS to another.
  \item \textbf{\texttt{nmap}} sends ``strange'' packets to the machine,
    detects how reacts, matches this against a file of \OS fingerprints
  \end{itemize}
\end{slide}

\begin{slide}{Running \texttt{nmap}: Use \texttt{xnmap}}
\begin{alltt}
$ \textbf{sudo -v}
$ \textbf{sudo xnmap &}
\end{alltt}
  \begin{itemize}
  \item Enter the \IP address of machine(s) to identify
  \item select other choices from buttons
  \item press Start
  \item \texttt{xnmap} is simply a way to easily generate command line
    options to \texttt{nmap} using a graphical interface
  \end{itemize}
\end{slide}

\begin{slide}{Uses of \texttt{nmap}}
  \begin{itemize}
  \item Identify the type of a computer that is causing trouble on the
    network
  \item Check what network services a computer is really offering
    \begin{itemize}
    \item compare with \texttt{netstat -tua} output
    \item A cracked computer may be hiding some services with trojaned
      utilities
    \item \texttt{nmap} can help you discover such services
    \end{itemize}
  \end{itemize}
\end{slide}

\tsectionandpart[toc=DNS troubleshooting,bm=DNS troubleshooting]%
  {DNS troubleshooting\\[3ex]Troubleshooting DNS Servers}

\begin{slide}{DNS troubleshooting}
  \label{sld:dns-troubleshooting}
  \begin{itemize}
  \item Suspect \DNS when get long timeouts before see any response
  \item ping name, \IP address, see if only \IP address works
  \item tools on Linux, Unix:
    \begin{itemize}
    \item \texttt{dig}, \texttt{nslookup}, \texttt{host}
    \end{itemize}
  \item tools on Windows:
    \begin{itemize}
    \item \texttt{nslookup}
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{DNS: \texttt{dig}}
  \begin{itemize}
  \item The people who write the most common name server (Bind)
    promote \texttt{dig}, deprecate \texttt{nslookup}
  \item \texttt{dig} output is in form of \DNS resource records
    \begin{itemize}
    \item can copy and paste straight into \DNS database files
    \end{itemize}
  \end{itemize}
\end{slide}  

\begin{slide}{\texttt{dig}: Checking forward DNS lookup}
\begin{alltt}
$ \textbf{dig nicku.org}\scriptsize
; <<>> DiG 9.2.1 <<>> nicku.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23568
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;nicku.org.            IN      A
;; ANSWER SECTION:
nicku.org.     60      IN      A     202.69.77.139
;; AUTHORITY SECTION:
no-ip.com.              60      IN      NS      nf1.no-ip.com.
no-ip.com.              60      IN      NS      nf2.no-ip.com.
no-ip.com.              60      IN      NS      nf3.no-ip.com.
;; ADDITIONAL SECTION:
nf1.no-ip.com.          60      IN      A       66.185.166.131
nf2.no-ip.com.          60      IN      A       66.185.162.100
nf3.no-ip.com.          60      IN      A       216.66.37.10
;; Query time: 254 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Feb 24 10:55:26 2003
;; MSG SIZE  rcvd: 154
\end{alltt}
\end{slide}

\begin{slide}{\texttt{dig}: reverse lookup           1}
\begin{alltt}
$ \textbf{dig -x 202.69.77.139}\scriptsize
; <<>> DiG 9.2.1 <<>> -x 202.69.77.139
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22117
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;;139.77.69.202.in-addr.arpa.    IN      PTR
;; ANSWER SECTION:
139.77.69.202.in-addr.arpa. 3600 IN     PTR     077-139.onebb.com.
;; AUTHORITY SECTION:
77.69.202.in-addr.arpa. 3600    IN      NS      ns2.onebb.com.
77.69.202.in-addr.arpa. 3600    IN      NS      ns1.onebb.com.
;; Query time: 310 msec
;; SERVER: 172.19.64.52#53(172.19.64.52)
;; WHEN: Mon Feb 24 11:07:04 2003
;; MSG SIZE  rcvd: 111
\end{alltt}
\end{slide}

\begin{slide}{\texttt{dig} syntax}
\begin{alltt}
\textbf{dig [\meta{options}] [@\meta{server}] \meta{name} \meta{type}}
\end{alltt}
  \begin{itemize}
  \item main option is \texttt{-x}
  \item \meta{server} is the name server to query
    \begin{itemize}
    \item by default, use first server in \texttt{/etc/resolv.conf}
    \end{itemize}
  \item \meta{name} is what you want to look up
  \item \meta{type} can be: \texttt{any}, \texttt{a}, \texttt{mx},
    \texttt{axfr}, \texttt{soa}, etc.
  \item default is to get A record(s)
  \end{itemize}
\end{slide}


\begin{slide}{\texttt{dig}: axfr (Zone Transfer)}
  \begin{itemize}
  \item \texttt{dig} can request a complete zone transfer:
\begin{alltt}\scriptsize
$ \textbf{dig @ns tyict.vtc.edu.hk axfr}
 
; <<>> DiG 9.2.2-P3 <<>> @ns tyict.vtc.edu.hk axfr
;; global options:  printcmd
tyict.vtc.edu.hk.       86400   IN      SOA     ns.tyict.vtc.edu.hk.
 nicku.vtc.edu.hk. 2004031000 3600 1800 604800 600
tyict.vtc.edu.hk.       86400   IN      NS      ns.tyict.vtc.edu.hk.
tyict.vtc.edu.hk.       86400   IN      NS      ns1.tyict.vtc.edu.hk.
tyict.vtc.edu.hk.       86400   IN      NS      dns1.vtc.edu.hk.
tyict.vtc.edu.hk.       86400   IN      NS      dns2.vtc.edu.hk.
000081667.tyict.vtc.edu.hk. 86400 IN    A       172.19.64.92
\ldots
\end{alltt}
  \item result can be copied and pasted as a master file in a DNS
    server
  \end{itemize}
\end{slide}  

\begin{slide}{\texttt{nslookup}: an interactive program}
\begin{alltt}
$ \textbf{nslookup}
Note:  nslookup is deprecated and may be removed
from future releases.  Consider using the `dig'
or `host' programs instead.  Run nslookup with 
the `-sil[ent]' option to prevent this message
from appearing.
> nicku.org
Server:         127.0.0.1
Address:        127.0.0.1#53
 
Non-authoritative answer:
Name:   nicku.org
Address: 202.69.77.139
\end{alltt}%$
\end{slide}


\begin{slide}{\texttt{nslookup}: reverse lookups}
\begin{alltt}\scriptsize
> 202.69.77.139
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
139.77.69.202.in-addr.arpa      name = 077-139.onebb.com.
Authoritative answers can be found from:
77.69.202.in-addr.arpa  nameserver = ns1.onebb.com.
77.69.202.in-addr.arpa  nameserver = ns2.onebb.com.
ns1.onebb.com   internet address = 202.180.160.1
ns2.onebb.com   internet address = 202.180.161.1
>
\end{alltt}
\end{slide}

\tsectionandpart[toc=telnet,bm=telnet]{Telnet:\\Troubleshooting Email and Other Protocols}

\begin{slide}{Email: testing with \texttt{telnet}}
  \begin{itemize}
  \item Email protocols \SMTP, \POP{}3 are text
  \item \texttt{telnet} a good tool to test them
  \item syntax:
\begin{alltt}
$ \textbf{telnet \meta{server} \meta{portnumber}}
\end{alltt}%$
  \item SMTP: port 25
  \item POP3: port 110
  \end{itemize}
\end{slide}

\begin{slide}{Test the VTC mail server:}
\begin{alltt}
$ \textbf{telnet smtp.vtc.edu.hk 25}\scriptsize
Trying 192.168.79.191...
Connected to smtp.vtc.edu.hk (192.168.79.191).
Escape character is '\^{}]'.
220 pandora.vtc.edu.hk ESMTP Mirapoint 3.2.2-GA; Tue, 25 Feb 2003
 11:15:30 +0800 (HKT)
helo nickpc.tyict.vtc.edu.hk
250 pandora.vtc.edu.hk Hello [172.19.32.30], pleased to meet you
mail from: nicku@nicku.org
250 nicku@nicku.org... Sender ok
rcpt to: nicku@nicku.org
250 nicku@nicku.org... Recipient ok
data
354 Enter mail, end with ``.'' on a line by itself
My message body.
.
250 AFF21826 Message accepted for delivery
quit
221 pandora.vtc.edu.hk closing connection
Connection closed by foreign host.
\end{alltt}%$
\end{slide}

\begin{slide}{SMTP commands for sending mail}
\begin{description}
\item[\texttt{helo}] identify your computer
\item[\texttt{mail from}] specify sender
\item[\texttt{rcpt to}] specify receiver
\item[\texttt{data}] indicates start of message body
\item[\texttt{quit}] terminate session
\end{description}
\begin{itemize}
\item Use names, not IP addresses, to specify destination
\end{itemize}
\end{slide}

\begin{slide}{Testing the VTC pop3 server 1}
\begin{alltt}\scriptsize
$ \textbf{telnet pop.vtc.edu.hk 110}
Trying 192.168.79.12...
Connected to pop.vtc.edu.hk (192.168.79.12).
Escape character is '^]'.
+OK carme.vtc.edu.hk POP3 service (iPlanet Messaging Server 5.2
 Patch 1 (built Aug 19 2002))
user nicku
+OK Name is a valid mailbox
pass \emphcolour{password}
+OK Maildrop ready
stat
+OK 1 673
\end{alltt}%$
\end{slide}

\begin{slide}{Testing the pop3 server           2}
\begin{alltt}\scriptsize
retr 1
+OK 673 octets
Return-path: <nicku@nicku.org>
Received: from pandora.vtc.edu.hk (pandora.vtc.edu.hk [192.168.79.191])
 by carme.vtc.edu.hk (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002))
 with ESMTP id <0HAU00I35H3HGL@carme.vtc.edu.hk> for nicku@ims-ms-daemon
 (ORCPT nicku@nicku.org); Tue, 25 Feb 2003 11:16:29 +0800 (CST)
Received: from nickpc.tyict.vtc.edu.hk ([172.19.32.30])
        by pandora.vtc.edu.hk (Mirapoint Messaging Server MOS 3.2.2-GA)
        with SMTP id AFF21826; Tue, 25 Feb 2003 11:16:01 +0800 (HKT)
Date: Tue, 25 Feb 2003 11:15:30 +0800 (HKT)
From: Nick Urbanik <nicku@nicku.org>
Message-id: <200302250316.AFF21826@pandora.vtc.edu.hk>
My message body.
.
dele 1
+OK message deleted
quit
+OK
Connection closed by foreign host.
\end{alltt}
\end{slide}

\begin{slide}{pop3 commands: retrieving mail}
  \begin{itemize}
  \item See RFC 1939 for easy-to-read details
  \item First, must authenticate:
  \end{itemize}
  \begin{description}
  \item[\texttt{user} \meta{username}]
  \item[\texttt{pass} \meta{password}]
  \item[\texttt{stat}] shows number of messages and total size in
    bytes
  \item[\texttt{list}] list all the message numbers and size in bytes
    of each message
  \item[\texttt{retr} \meta{messagenum}] retrieve the message with
    number \meta{messagenum}
  \item[\texttt{dele} \meta{messagenum}] delete the message with
    message number \meta{messagenum}
  \item[\texttt{quit}]
  \end{description}
\end{slide}

\begin{slide}{\texttt{telnet}: Testing Other Applications}
\begin{itemize}
\item Many network protocols are text.  \texttt{telnet} can be helpful
  in checking:
  \begin{itemize}
  \item IMAP servers:
\begin{alltt}
$ \textbf{telnet \meta{hostname} 143}
\end{alltt}%$
  \item Web servers:
\begin{alltt}
$ \textbf{telnet \meta{hostname} 80}
\end{alltt}%$
  \item Ftp servers:
\begin{alltt}
$ \textbf{telnet \meta{hostname} 21}
\end{alltt}%$
  \item Even ssh (can check version, if responding):
\begin{alltt}
$ \textbf{telnet \meta{hostname} 22}
\end{alltt}%$
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Conclusion}
\begin{itemize}
\item Check the \emphcolour{simple} things first
\item Be \emphcolour{methodical}
\item \emphcolour{Document} what you do
\item Become {\blue{}familiar} with \emphcolour{common tools}
\item Use the tools to become {\blue{}familiar} with your \emphcolour{network}
  {\green{}before troubles strike}
\item Know what is \emphcolour{``normal''}
\item Get\emphcolour{ permission} from the boss before using {\blue{}packet
  sniffing and port scanners}
\end{itemize}
\end{slide}

\end{document}
