Mn2585eu10mn 0002 TCP Ip

TCP/IP addressing and routing Siemens
TCP/IP addressing and routing
Contents
1 The TCP/IP protocol suite 3
1.1 Why does TCP/IP exist? 4
1.2 What is TCP/IP? 4
1.3 The structure of the TCP/IP suite 4
2 Overview of the TCP/IP protocol layers 7
2.1 Layer 1 8
2.2 Layer 2 8
2.3 Layer 3 10
2.4 Layer 4 10
3 A TCP/IP conversation 13
4 IP addressing 17
4.1 Addressing on the network layer 18
4.2 Address classes 22
4.3 Subnetworks and subnetwork masks 32
5 Routing 41
5.1 Routing principles 42
5.2 Routing protocols 48
6 Network access layer protocols 57
6.1 Important network access layer protocols 58
6.2 Ethernet V2 60
6.3 Fiber Distributed Data Interface (FDDI) 62
6.4 Asynchronous Transfer Mode (ATM) 62
7 Internet layer protocols 63
7.1 Important internet layer protocols 64
7.2 Internet Protocol (IP) 64
7.3 Internet Control Message Protocol (ICMP) 72
7.4 The Address Resolution Protocol ARP 78
7.5 The Reverse Address Resolution Protocol RARP 78
8 Transport layer protocols 81
MN2585EU10MN_0002
1
© 2002 Siemens AG
Siemens TCP/IP addressing and routing
8.1 Introduction to the transport layer protocols 82

8.2 Ports and sockets 84
8.3 Transport Control Protocol (TCP) 90
8.4 User Datagram Protocol (UDP) 100
9 Application layer protocols 105
9.1 Introduction 106
9.2 Network terminal protocol (TELNET) 108
9.3 File Transfer Protocol (FTP) 110
9.4 Network File System (NFS) 112
9.5 Rlogin 114
9.6 The X window system based on the X protocol 116
9.7 Simple Network Management Protocol SNMP 118
10 IP based O-link 125
10.1 Basics 126
10.2 SBS/RC Implementation 128
10.3 Database parameters 133
11 Aspects of network configuration under Solaris 135
11.1 General 136
11.2 Important files for the network configuration 140
11.3 Important commands to administer a network under Solaris 142
12 Exercises 159
2 MN2585EU10MN_0002
© 2002 Siemens AG
1 The TCP/IP protocol suite
Fig. 1 the Internet
MN2585EU10MN_0002
3
© 2002 Siemens AG
1.1 Why does TCP/IP exist?

Unfortunately, the OSI model is not the only model that describes communication
processes. Parallel to the OSI’s standardization efforts, alternative techniques were
developed in the USA. They are known as TCP/IP. In 1983, the American
Department of Defense (DoD) adopted these protocols as standard. Over the past
few years, the capabilities of TCP/IP (Transmission Control Protocol/Internet
Protocol) have become well known far beyond the borders of the USA.
The reason for the popularity of the TCP/IP model is based on the great commercial
success of its implementation through the IP and TCP protocol. By using TCP/IP, two
different computer systems can exchange information, interpret it correctly and
convert it into a format that is understood by the local computer and its users.
Due to the rapidly increasing commercial interest in the Internet, a new market
opened up for TCP/IP products in the mid 90s. OSI protocols were unable to conquer
the market, but cost-effective TCP/IP implementations are available for all computer
types and sizes.
1.2 What is TCP/IP?

TCP/IP is a set of protocols that allows reliable end-to-end communication between
two hosts over different physical types of local networks. TCP/IP is independent of
proprietary networking solutions. It is supported by most manufacturers of
minicomputers, PCs, Macintoshes, mainframes and other platforms. The Internet,
which is a ”virtual network of networks”, is made possible through the use of TCP/IP
protocols.
1.3 The structure of the TCP/IP suite

A TCP/IP protocol suite defines a group of protocols used in IP-based networks.
Unlike the European OSI model, the TCP/IP reference model has 4 layers. The
TCP/IP protocols are based on communication between different systems. They are
not based on the physical structure of data networks.
The TCP/IP protocol suite (also referred to as protocol stack) is named for two of its
most important protocols: Transmission Control Protocol (TCP) and Internet Protocol
(IP).
TCP/IP standards are governed by the Internet Activities Board (IAB) and its
subcommittees the Internet Engineering Task Force (IETF) and the Internet
Research Steering Group (IRSG). The IAB maintains a list of official documents
called Request For Comments (RFC) that specify and describe TCP/IP protocols
and services.
The IAB assigns a state (standard - std-n, draft standard, proposed standard,
experimental, informational, historic) and a status (required, recommended, elective,
limited use, not recommended) to the Internet protocols that are described in the
RFCs.
4 MN2585EU10MN_0002
© 2002 Siemens AG
The OSI Model The TCP/IP Model

7 Application
Application
6 Presentation Application
Application Layer
Layer 4
5 Session
Session
4 Transport Transport
Transport Layer 3
3 Network
Network Internet Layer
Layer 2
2 Data
Data Link
Link
Network
Network Access Layer 1
Access Layer
1 Physical
Physical
Fig. 2 Comparison of the OSI and TCP/IP model
The TCP/IP Model
Application SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP

Application Layer
Layer
4
Transport
Transport Layer
Layer TCP UDP
Internet
Internet Layer
Layer ARP RARP IP ICMP
2
Network
Network Access
Access Layer
Layer IEEE IEEE IEEE IEEE
FDDI ATM
Frame
X.25 PPP
802.2 802.3 802.4 802.5 Relay
1
Fig. 3 TCP/IP protocol suite
MN2585EU10MN_0002
5
© 2002 Siemens AG
6 MN2585EU10MN_0002
© 2002 Siemens AG
2 Overview of the TCP/IP protocol layers
MN2585EU10MN_0002
7
© 2002 Siemens AG
2.1 Layer 1
The Network Access Layer corresponds to the physical and data link layers of the
OSI model and performs the same functions: It comprises data links and physical
transport services. This layer specifies procedures for transmitting data across the
network and how to access the physical medium. This interface may be packet- or
stream-oriented. The Internet Layer of the TCP/IP protocol can be implemented on
top of nearly all network interfaces.
Examples for Network Access Layer protocols are:
Serial Link Interface Protocol (SLIP), seldomly used (was replaced by PPP)
Point-to-Point Protocol (PPP), used for dial-up connections to ISP
Ethernet (802.3), media access vis CSMA/CD (10Mbit/s)
Fast Ethernet, used in most network implementations (100Mbit/s)
Fiber Distributed Data Interface (FDDI)
Token Ring, ring topology with controlled media access by so called "tokens"
Asynchronous Transfer Mode (ATM), encapsulation of IP packets in ATM cells
2.2 Layer 2
In the OSI model, the Internet Layer (also known as network or internetwork layer)
would be a network layer component. One major function of layer 2 is to release the
higher layer protocols from having to find out about the physical characteristics of the
transmission medium. The layer 2 forms a barrier between the physical layers
(architecture below) and the next highest layer, the transport protocols. Furthermore
layer 2 provides other main functions like packet addressing, delivery, fragmentation
and re-assembly. The Internet Layer protocols are:
Internet Protocol (IP), used for doing the job
Internet Control Message Protocol (ICMP), used for supervision of job success
IP is the most important protocol in this layer. It is a connectionless protocol which
does not provide reliability, flow control or error recovery. These functions must be
provided at a higher level, either at the Transport Layer by using TCP as the
transport protocol, or at the Application Layer if UDP is used as the transport
protocol. The used transport protocol depends absolutely on the requirements of the
application.
Local area networks interface with the Internet Layer via address resolution protocols
that map hardware addresses to Internet addresses:
Address Resolution Protocol (ARP), translating IP address to MAC address
Reverse Address Resolution Protocol (RARP), assigning for each MAC
address an IP address
8 MN2585EU10MN_0002
© 2002 Siemens AG
SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP
TCP UDP
ARP RARP IP ICMP
IEEE IEEE IEEE IEEE Frame

FDDI ATM X.25 PPP
802.2 802.3 802.4 802.5 Relay
Fig. 4 Network access layer protocols
TCP UDP
ARP RARP IP ICMP

FDDI ATM X.25 PPP
802.2 802.3 802.4 802.5 Relay
Fig. 5 Internet layer protocols
MN2585EU10MN_0002
9
© 2002 Siemens AG
2.3 Layer 3
The function of the Transport Layer corresponds to the transport layer of the OSI
model and provides the end-to-end data transfer. This layer manages all aspects of
data routing and delivery, multiplexing/demultiplexing, session initiation, error control
and sequence checking. Transport Layer protocols are often implemented as library
routines that are linked to specific applications. Applications are identified via port
numbers that are embedded in the Transport Layer packet headers. The Transport
Layer protocols are:
Transmission Control Protocol (TCP)
User Datagram Protocol (UDP)
TCP is a connection-oriented protocol that provides reliability, flow control, and

data stream transfers. The connection oriented service requires that a connection is
actually set up before data can be transferred from one computer to another. As soon
as the data transfer is complete, the connection is released. The connections
between applications running on different hosts will be built by logical connections, so
called virtual circuits and will be defined via sockets and other characteristics
discussed later. The data block that is transferred from TCP to IP is called a segment
and consists of the TCP protocol header and one segment of the application layer
data.
UDP is mainly used for the transmission of small volumes (e.g. name queries) of data
in local networks. It functions connectionless and provides no guarantee that the
data arrive correctly at the receiver. UDP only extends the basic IP datagram
services in so far as it transmits data to the respective application layer services. The
data block that is transferred from UDP to IP is also called datagram. A datagram
consists of the UDP protocol header and the application layer data (no
segmentation).
2.4 Layer 4
The Application Layer comprises the user processes that cooperate with other
processes on the same or different host. The lower level protocols provide services to
the Application Layer protocols and specify how application programs interface to the
network. Some Application Layer protocols are:
Domain Name System (DNS)
File Transfer Protocol (FTP)
Terminal Emulation (TELNET)
Simple Network Management Protocol (SNMP)
Simple Mail Transfer Protocol (SMTP)
Network File System (NFS)
10 MN2585EU10MN_0002
© 2002 Siemens AG
TCP UDP
ARP RARP IP ICMP

FDDI ATM X.25 PPP
802.2 802.3 802.4 802.5 Relay
Fig. 6 Transport layer protocols
TCP UDP
ARP RARP IP ICMP

FDDI ATM X.25 PPP
802.2 802.3 802.4 802.5 Relay
Fig. 7 Application layer protocols
MN2585EU10MN_0002
11
© 2002 Siemens AG
12 MN2585EU10MN_0002
© 2002 Siemens AG
3 A TCP/IP conversation
MN2585EU10MN_0002
13
© 2002 Siemens AG
A TCP/IP ”conversation” takes place between two hosts that are connected to the
Internet. Every network transaction moves down through the protocol layers on its
originating system, travels across the physical medium, and then moves up through
the same stack of protocols on the destination system.
The name of a unit of data that flows through an internet is dependent upon where it
exists in the protocol stack. In summary:
on an Ethernet it is called an Ethernet frame
between the Ethernet driver and the IP module it is called a IP packet
between the IP module and the UDP module it is called a UDP datagram
between the IP module and the TCP module it is called a TCP segment (more
generally, a transport message)
in a network application it is called a application message.
At a high level, the interaction between the TCP/IP protocol layers can be described
as follows:
At Host A, the following transactions take place:
A network operation is initiated at the Application Layer by a user command or
program. The application sends arbitrary sized blocks of information, called
messages, to the Transport Layer.
The Transport Layer receives the messages from the application, divides them
into segments of variable length (in case of TCP) or send the complete message in
one datagram (in case of UDP), adds a transport header, and passes the
segments along to the Internet Layer. This starts the encapsulation process.
The Internet Layer encloses the segments in an IP packet matching the frame
size of used physical media, adds the packet header, decides where to send the
packets, and passes the packets to the Network Access Layer.
The Network Access Layer accepts IP packets, adds the frame header and
trailer and transmits them as frames or bit streams over specific network hardware.
At host B, the frames or bit streams are received and go through the protocol layers
in reverse.
Although there are provision to open and maintain connections through the network,
TCP/IP primarily uses connectionless communication technology. Information is
transferred as a series of packets (each with a destination and source address) that
are sent through the network individually (i.e. each packet may take a separate
route). IP protocols break up files into packets (matching the Maximum Transmission
Unit MTU of the underlying network access layer) for transmission through the
network and reassemble the packets at the destination.
The figure below is a graphical representation of the TCP/IP conversation between
hosts A and B.
14 MN2585EU10MN_0002
© 2002 Siemens AG
TCP/IP Layers TCP/IP Layers
Message
Application Application
Segment/Datagram
TCP / UDP
Transport Transport
Packet
Internet Internet
Frame
Network Access Network Access

Bits
SIEMENS SIEMENS
NI XDORF NIXDORF
Internet
Host A Host B
Fig. 8 TCP/IP conversation
SUMMARY
TCP/IP is a layered set of protocols. In order to communicate between these layers,
a field is included in each data packet’s header that indicates what higher level
protocol a packet should be handed to next.
MN2585EU10MN_0002
15
© 2002 Siemens AG
16 MN2585EU10MN_0002
© 2002 Siemens AG
4 IP addressing
IP Addressing
Fig. 9 IP addressing
MN2585EU10MN_0002
17
© 2002 Siemens AG
4.1 Addressing on the network layer

Network addresses are logical addresses
Every network connection requires addresses to identify the originator and the
receiver of a message. On local area networks, devices typically have addresses that
are implemented in the hardware. These physical addresses of the data link layer are
called data link addresses or MAC addresses. The data link addresses clearly
identify each device within a network. Data link addresses on Ethernet LANs usually
consist of 48 bits. Other network types may use other addressing schemes.
In larger networks, it is impractical to deliver data based exclusively on the physical
address. To reduce network traffic and minimize delivery times in larger networks,
transfer and packet filtering methods are required.
The network layer uses logical network addresses to transfer packets to specific
subnetworks within a complex network system. To be able to identify a host on the
Internet, each host is assigned such a logical address, called IP address. The IP
address provides a uniform way of addressing all network nodes regardless of their
physical connections. The IP address is a software address that is implemented and
allocated during network configuration by a network administrator who must ensure
that each address within the overall network is unique.
The devices that evaluate this and transfer packets according to their logical
addresses are referred to as routers.
MAC addresses and networks addresses

For the physical transmission of data only the MAC address is used. Each physical
port of a device therefore has a MAC address and a network address. There are
mechanisms to find a MAC address if one knows the network address and vice versa
(discussed later).
One example of allocating a logical network name to a MAC address is:
Network address MAC address

192.52.200.51 08-00-14-35-67-32
.
SUMMARY
The 6-byte Ethernet address is unique for each interface on an Ethernet and is
located at the lower interface of the Ethernet driver
The computer also has a 4-byte IP address. This address is located at the lower
interface to the IP module. The IP address must be unique for an internet.
A running computer always knows its own IP address and Ethernet address.
18 MN2585EU10MN_0002
© 2002 Siemens AG
Problem: MAC addresses are distributed randomly all over the network,
there is no logical structure.
MAC MAC MAC MAC
Bridge MAC
MAC
Bridge Bridge
Bridge
MAC MAC
MAC MAC Bridge
MAC
Fig. 10 MAC addresses in a network
Solution: Network addresses. They have a logical structure

and can be used for the delivery of data even in big networks
Network address
Network address
MAC address
MAC address
Network address Network address

Router
MAC address MAC address
Router Router
Router
Network address
Network address Router
MAC address
MAC address
Every station
has a MAC address and
a network address
Fig. 11 Network addresses
MN2585EU10MN_0002
19
© 2002 Siemens AG
4.1.1 IP address properties

For the reasons cited, the Internet also uses logical structured addresses, so-called
IP addresses.
IP addresses consist of a network part (network identifier) and a host part (host
identifier)...
The network identifier (net ID) is assigned by a central authority, such as the
Network Information Center (NIC). The NIC tracks the net Ids to ensure that they
remain unique across the entire Internet.
The host identifier (host ID) specifies a particular host (station, node, or other
device) within a given network. The host ID is assigned by a local network
administrator. A host ID needs to be unique within its own network.
This contributes to better handling of message transmission through networks.
... which makes life easier for routers

Routers can deliver an IP packet by only evaluating the network part of the address
in the respective local network. Only the destination host in the destination network
evaluates the complete address.
4.1.2 Decimal and binary notation of IP addresses

An IP address consists of 32 bits, means 4 octets or 4 bytes. To make Internet
addresses easier for human users to read and write, IP addresses are often
expressed as four decimal numbers each representing 8 bits of the address, which
are separated by a dot. This is called dotted decimal notation. It is this type of
notation that you are probably most familiar with.
For example 144.19.74.201 is an IP address with 144.19 being the network ID and
74.201 being the host ID.
The figure below illustrates how an IP address can be expressed in binary notation
and in dotted decimal notation.
TIP
It can, however, also be useful to represent individual bytes in binary format, for
example when working with subnetwork masks.
20 MN2585EU10MN_0002
© 2002 Siemens AG
32 Bit IP Address
Network
Network Host
Host
The
Thehost
hostpart
partofofthe
theaddress
address
The
Thenetwork
networkpart
partofofthe
theaddress
address identifies
identifies identifies a certainhost
a certain host
identifies a certainnetwork
a certain network within
withinthe
thenetwork
network
Router Router
Fig. 12 Network and host part of an IP address
Byte Byte Byte Byte

Decimal
Notation 85 11 117 4
Binary
Notation 01010101 00001011 01110101 00000100
Fig. 13 IP address structure
MN2585EU10MN_0002
21
© 2002 Siemens AG
4.2 Address classes

The NIC assigns IP addresses based on five classifications: classes A, B, C, D, and
E. The purpose of dividing addresses into classes is to allow flexibility in the number
of bits that are allotted to the net ID and host ID. The first bits of the IP address, also
called Network class or Network prefix, specify how the rest of the address should be
separated into its network and host part.
Class A (/8 prefixes) – 1 byte for the network part

Each Class A network address has an 8-bit network-prefix with the highest order bit
set to 0 (Network Class) and a seven-bit network number (Net-ID), followed by a 24-
bit host-number (Host-ID). Class A networks are also referred to as "/8s"
(pronounced "slash eight" or just "eights") since they have an 8-bit network-prefix.
A maximum of 126 (27 -2) /8 networks can be defined. Each /8 supports a maximum
of 16,777,214 (224 -2) hosts per network.
Class B (/16 prefixes) – 2 bytes for the network part

Each Class B network address has a 16-bit network-prefix with the two highest order
bits set to 1-0 and a 14-bit Net-ID, followed by a 16-bit Host-ID. Class B networks are
also referred to as"/16s" since they have a 16-bit network-prefix.
A maximum of 16,384 (214 ) /16 networks can be defined with up to 65,534 (216 -2)
hosts per network.
Class C (/24 prefixes) – 3 bytes for the network part

Each Class C network address has a 24-bit network-prefix with the three highest
order bits set to 1-1-0 and a 21-bit Net-ID, followed by an 8-bit Host-ID. Class C
networks are also referred to as "/24s".
A maximum of 2,097,152 (221 ) /24 networks can be defined with up to 254 (28 -2)
hosts per network.
Class D
Class D addresses are used for multicast groups. The four most significant bits are
always set to “1110”. Multicast addresses operate in a range from 224.0.0.0 to
239.255.255.255.
Class E
Class E addresses are used for experimental purposes and are not available for
general use. The four most significant bits are always set to “1111”.
TIP
Class D and Class E addresses are never used for addressing end user devices.
22 MN2585EU10MN_0002
© 2002 Siemens AG
32 Bits
8 31
Class A 0 Net ID (7 Bits) Host ID (24 Bits)
16
Class B 1 0 Net ID (14 Bits) Host ID (16 Bits)
24
Class C 1 1 0 Net ID (21 Bits) Host ID (8 Bits)
Class D 1 1 1 0 Reserved for Multicast Addressing (28 Bits)
Class E 1 1 1 1 Reserved for Future Use (28 Bits)
Network class
Fig. 14 Network Classes
Network First Decimal Net Number of Host Number of Comments

Class Numbers in an ID Possible ID Possible
IP Address Bits Net IDs Bits Host IDs
Class A 1 through 126 7 126 24 16,777,214 Used for very
(127 is reserved large
for loopback networks
testing.)*
Class B 128 through 191 14 16,384 16 65,534 Used for
medium sized
networks
Class C 192 through 223 21 2,097,152 8 254 Used for
large
numbers of
small
networks.
Class D 224 through 239 Reserved for multicasting, i.e. the addressing of groups
of hosts in a limited area
Class E 240 through 247 Reserved for future use
Note: Two class A, B, and C host IDs are pre-assigned: the ”all bits 0” (this network)
and the ”all bits 1”(directed broadcast) number.
MN2585EU10MN_0002
23
© 2002 Siemens AG
4.2.1 Reserved IP addresses

Some IP network and host numbers are reserved for special aspects of TCP/IP
communication and may not be used for any other purpose.
The reserved IP addresses include the "all bits 0" address, the "all bits 1" address,
and the loopback address 127.0.0.1.
Host number (Host-ID) Special meaning

”all bits 0” stands for "this" A host number 0 is reserved for reference to a
network certain network ID. This means that in the network
with the network address 192.16.1.0 the IP address
192.16.1.1 is the first class C host address that
could be allocated, for example.
”all bits 1” stands for ”all” The host number consisting exclusively of ones is
hosts in a certain network reserved for directed broadcast messages to all
hosts of a certain network. For example, the class C
address 201.3.3.255 (host ID of 255) sends
messages to all hosts on network 201.3.3. It can
only be used as a destination address. These
directed broadcast messages should not be
forwarded via routers.
Network number Special meaning

(Network-ID)
”all bits 0” The network ID consisting exclusively of zeros is
classless and signifies "the current network
whose number is not known". This address is
therefore only transferred within the local network.
”all bits 1” stands for ”all” The network ID of a certain class consisting
networks in a certain exclusively of ones addresses all networks in a
network class certain network class
24 MN2585EU10MN_0002
© 2002 Siemens AG
Directed
Directed Broadcast
Broadcast to
to
SIEMEN S
NI XD OR F
DA=201.3.3.255
DA=201.3.3.255 network
network 201.3.3.0
201.3.3.0 by
by default
default disabled
disabled
192.16.1.1
192.16.1.1
Router
Network
Network addr.
addr. 192.16.1.0
192.16.1.0
DA=255.255.255.255
DA=255.255.255.255 Local
Local Broadcast
Broadcast to
to
all
all networks
networks must
must not
not be
be forwarded
forwarded
Fig. 15 Reserved addresses, Directed and Local Broadcast
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
25
© 2002 Siemens AG
Special IP addresses Special meaning

0.0.0.0 The address 0.0.0.0 is reserved and used in two
cases:
as the originator address if the host does not
know its actual address, for example, when
powering up a workstation without hard disk.
This would relate only to situations where the
source IP address appears as part of an
initialization procedure when a host is trying to
determine its own IP address. The Bootstrap
Protocol (BootP) is an example of such a
scenario.
Routers use it as destination address to
specify default routes in address lists, i.e. the
route to all networks not explicitly listed.
255.255.255.255 A limited IP broadcast address (local
broadcast) is defined to be all-ones: {-1, -1} or
255.255.255.255. The address 255.255.255.255 is
reserved as destination address for local broadcast
messages to all the hosts of a network. Packets to
this address must not be forwarded by a router.
127.x.x.x. This all bits 1 Class A address is used as a
(x can be a random number) loopback address and, if implemented, must be
used correctly to point back at the originating host
itself. In many implementations, this address is
used to provide test functions. By definition, the IP
datagrams never actually leave the host.
The class A network number 127.0.0.1 is a reserved software loopback address that
is used when a host ”pings” itself. The address 127.0.0.1 allows a host to test the
operation of the TCP/IP software without sending traffic across the network. A packet
with the loopback address is sent from the application layer to the IP layer. If the
software is working properly, the IP layer will recognize the address and return the
packet to the application layer.
Other reserved numbers are listed in RFC 1166.
26 MN2585EU10MN_0002
© 2002 Siemens AG
Application
Destination
127.0.0.1
Host A
TCP UDP
SIEMENS
NIXDORF
IP
Network Access
Fig. 16 Loopback address
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
27
© 2002 Siemens AG
4.2.2 Private IP addresses

When building their networks, many organizations do not have the requirement (or at
least they do not yet have the requirement) to route outside of their own network.
Under these circumstances the network can be assigned any IP address that the
local network administrator chooses. This practice has now been formalized in RFC
1918 - "Address Allocation for Private Internets". This RFC details the following three
ranges of addresses, which the Internet Assigned Numbers Authority (IANA) has
reserved for private networks that do not require connectivity to the Internet:
These ranges are not forwarded via any Internet router.
Range from to Amount of private network addresses

10.0.0.0 10.255.255.255 1 class A network
172.16.0.0 172.31.255.255 16 contiguous class B networks
192.168.0.0 192.168.255.255 256 contiguous class C networks
These addresses may be used by any organization without reference to any other
organization, including the Internet authorities. However, they must not be referenced
by any host in another organization, nor must they be defined to any external routers.
All external routers should discard any routing information regarding these
addresses, and internal routers should restrict the advertisement of routes to these
private IP addresses.
Any organization that elects to use addresses from these reserved blocks can do so
without contacting the IANA or an Internet registry. Since these addresses are never
injected into the global Internet routing system, the address space can
simultaneously be used by many different organizations.
The disadvantage to this addressing scheme is that it requires an organization to use
a Network Address Translator (NAT) for global Internet access. However, the use of
the private address space and a NAT make it much easier for clients to change their
ISP without the need to renumber. The benefits of this addressing scheme to the
Internet are that it reduces the demand for IP addresses so large organizations may
require only a small block of the globally unique IPv4 address space.
28 MN2585EU10MN_0002
© 2002 Siemens AG
Address
Address Range
Range Networks
Networks Address
Address Class
Class
10.0.0.0
10.0.0.0 -- 11 A
A
10.255.255.255
10.255.255.255
172.16.0.0
172.16.0.0 --
172.31.255.255 16
16 B
B
172.31.255.255
192.168.0.0
192.168.0.0 --
192.168.255.255 256
256 C
C
192.168.255.255
These addresses are intended for

private use only!
Fig. 17 Private IP addresses
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
29
© 2002 Siemens AG
4.2.3 The allocation of IP addresses
Manual allocation of addresses

Generally, a computer has a fixed address that can be allocated manually. Below you
will find examples of how addresses can be set up manually. However, there are
cases when permanent addresses are not useful. If computers are only temporarily
connected to the Internet, they do not need to be allocated a permanent IP address
that would then be unavailable for other computers.
Dynamic allocation of addresses

Due to the shortage of addresses, so-called dynamic address allocation can be used,
e.g. for dial-up connections to the Internet. As soon as a computer logs in with a
service provider, it is allocated a free IP address. As soon as the connection is
terminated, the address is then available for other computers.
Dynamic address allocation can also be used to simplify administration within a
network. An IP address can, for example, be allocated to a station when it first logs
on. This function as well as others is supported by the Dynamic Host Configuration
Protocol (DHCP).
Examples
The following diagram shows the input of an IP address under Windows NT,
Windows 9x or Windows 2000
On a SUN Solaris Workstation the command would be as follows (discussed later in

detail):
# ifconfig le0 132.76.250.55 netmask 255.255.255.0
30 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 18 Configuration of an IP address for a Windows operating system
Fig. 19 Configuration of an IP address for a Windows operating system
MN2585EU10MN_0002
31
© 2002 Siemens AG
4.3 Subnetworks and subnetwork masks

4.3.1 Reasons for introducing subnetworks
As the Internet grows, new physical networks are installed and increasing numbers of
hosts require splitting local networks into two or more separate networks. The
number of authorized IP addresses (net IDs) available from the NIC is limited. This is
one of the main reasons why in the mid 80s subnetwork addressing were introduced.
The purpose of subnetworks

Subnetworks and subnetwork masks allow the network administrator to divide a large
network into smaller subnetworks. In order to make the best possible use of the
limited address space available, subnetworks do not use any of the predefined
network classes, e.g. several officially registered class C addresses. Externally, only
one registered address should be used.
Division into subnetworks is an internal matter

Division into subnetworks is an internal matter and is carried out by the respective
network administrator. It is often important to pass on the responsibility of IP address
administration to individual departments to give them better control over their
networks. The creation of subnetworks thus simplifies network administration and
allows internal restructuring of a network without affecting larger network units or
even the entire Internet.
The subnet number is derived by dividing the host ID part of an IP address into two
parts: a subnet number and a host number. This allows one net ID to be used to
connect many subnetworks into an internetwork. The combination of subnet number
and host number is referred to as a ”local address” or ”local part”. The
combination of net ID and subnet number is called a subnet address.
Subnetworks and routers

Routers are used to link networks on the network layer. Routers are network devices
that are simultaneously connected to several (sub-) networks via a number of
interfaces. This means that for interconnectivity purposes each subnetwork must be
accessible by one dedicated router interface. The address of this interface must be
part of the subnetwork address space. Subnetworks are often based on physical
network structures. This way it is possible, for example, to treat individual Ethernet-
based LANs as subnetworks and use routers to link them.
Subnetmasks
Since a router needs to discriminate between (sub-) network part and host part,
standard class A, B, C network addresses cannot be used to differentiate between
individual subnets. In order to do this differentiation, subnet masks are used.
Subnetmasks allow the assignment of certain bits of the host part of the class A, B, C
address to be part of the subnet address.
32 MN2585EU10MN_0002
© 2002 Siemens AG
Net ID Host ID
Class A, B or C
Net ID Subnet Number Host Number
IP Address
Subnet Router SIEMEN S

NIXDORF
Subnet
Host
Routers are used to Router
connect subnetworks.
Router
Subnet The subnet structure

Each interface requires
is only visible within
a specific subnet address.
the network.
Fig. 20 Net ID, subnets and hosts
Net ID Host ID
Class A, B or C
IP Address Net ID Subnet Number Host Number
Local part/local address
Subnet address
Fig. 21 Subnet address and local address
MN2585EU10MN_0002
33
© 2002 Siemens AG
4.3.2 The subnetwork mask

The classical IP addressing architecture used addresses and subnet masks to
discriminate the host number from the subnet address. As with the IP address, the
subnetwork mask consists of four bytes, separated by dots in its written
representation.
Architecturally correct subnet masks are capable of being represented using the
prefix length description. They comprise that subset of all possible bits patterns that
have
1. a contiguous string of ones at the more significant end (The number of bits set to
"1" is also referred to as "prefix length".) which is responsible for extracting the
subnet address,
2. a contiguous string of zeros at the less significant end, which is responsible for
suppressing the host number and
3. no intervening bits .
The mode of operation of the subnetwork mask can, however, best be understood by
choosing the binary format of the mask. Each bit that is set to "1" in the subnetwork
mask will be passed through (logical AND operation) and belongs to the network part
(subnet address) of the IP address; the other bits of the IP address will be blocked,
remain for the host number and are set to "0".
Example:
Filtering the IP address 85.139.117.4 with the subnetwork mask 255.192.0.0
produces the subnet address 85.128.0.0.
In the example below, the subnetwork mask 255.192.0.0 is used to create
subnetwork 85.128.0.0 of the class A network address 85.0.0.0. Using this mask, an
other subnetwork can be created (85.64.0.0). A router may be used to link both
subnetworks.
Address classes are linked to default address masks

The standard address classes A, B, C and E are linked to default address masks.
The default subnetwork mask is always used when no subnetworks are involved. All
network ID bits are set to “1” and all host ID bits to “0”. The following table shows the
default masks for the different address classes.
Address Binary Subnetwork Mask Decimal

Class Subnetwork Mask
Class A 11111111 00000000 00000000 00000000 255.0.0.0
Class B 11111111 11111111 00000000 00000000 255.255.0.0
Class C 11111111 11111111 11111111 00000000 255.255.255.0
34 MN2585EU10MN_0002
© 2002 Siemens AG
Subnetwork Mask
Is used to:
• discriminate the host number from the network number.
• indicate the number of bits in the prefix.
Must have:
• a contiguous string of ones at the more significant end,
• a contiguous string of zeros at the less significant end, and
• no intervening bits.
Fig. 22 Subnetwork mask
Subnetwork Mask
IP Address 85 139 117 4 01010101 10 001011 01110101 00000100
Subnetwork 255 192 0 0 11111111 11 000000 00000000 00000000

Mask
Network Part
of the Address 85 128 0 0 01010101 10 000000 00000000 00000000
(Subnet address)
Host Part of the

Address 0 11 117 4 00000000 00 001011 01110101 00000100
(Host number)
Fig. 23 Mode of operation of a subnetwork mask
MN2585EU10MN_0002
35
© 2002 Siemens AG
4.3.3 IP address, subnetwork mask and default gateway
Default Gateway
When a host is willing to send it has to decide whether the destination host is in the
same subnetwork or in another one. In the latter case the default gateway must be
used to forward the IP packet. This creates interaction between IP addresses,
subnetwork mask and the so-called default gateway.
Example
Let us assume that station 85.128.0.1 wants to send an IP packet to a station that is
not part of the same subnetwork. Station 85.128.0.1 determines its own subnetwork
address by filtering its own IP address through the configured subnetwork mask.
It then determines the network address of the destination station by filtering
destination IP address using the locally configured subnetwork mask. If the two
network addresses do not match, the packet cannot be transmitted locally, but must
be forwarded to the default gateway for further transmission.
When you look at your computers network settings, the TCP/IP settings will generally
be the triple: IP address, subnetwork mask and default gateway.
36 MN2585EU10MN_0002
© 2002 Siemens AG
Router
Router
Therouter
The routerisislinked
linkedtotoall
all Nextrouter
router
Next
subnets and, in this instance,
subnets and, in this instance,
alsoforms
also formsthe
thedefault
defaultgateway
gateway
for both networks
for both networks Router
85.128.0.3
85.128.0.3
85.128.0.3
Subnet 85.128.0.0; Mask 255.192.0.0
Router
85.64.0.1
85.64.0.1
85.64.0.1
85.128.0.1 85.128.0.2
OriginalClass
Original ClassAA Subnet 85.64.0.0; Mask 255.192.0.0
Network
Network
85.0.0.0
85.0.0.0
85.64.0.3 85.64.0.2
Fig. 24 The division of a large network into two subnetworks
Fig. 25 Input mask with IP address, subnetwork mask and default gateway for a popular operating system
MN2585EU10MN_0002
37
© 2002 Siemens AG
4.3.4 Benefits of subnetting within a private network

Subnetting overcame the registered number issue by assigning each organization
one (or at most a few) network number(s) from the IPv4 address space. The
organization was then free to assign a distinct subnetwork number for each of its
internal networks. This allows the organization to deploy additional subnets without
needing to obtain a new network number from the Internet.
In the figure below, a site with several logical networks uses subnet addressing to
cover them with a single /16 (Class B) network address. The router accepts all traffic
from the Internet addressed to network 130.5.0.0, and forwards traffic to the interior
subnetworks based on the third octet of the classful address. The deployment of
subnetting within the private network provides several benefits:
1. The size of the global Internet routing table does not grow because the site
administrator does not need to obtain additional address space and the routing
advertisements for all of the subnets are combined into a single routing table
entry.
2. The local administrator has the flexibility to deploy additional subnets without
obtaining a new network number from the Internet.
3. Route flapping (i.e., the rapid changing of routes) within the private network does
not affect the Internet routing table since Internet routers do not know about the
reachability of the individual subnets - they just know about the reachability of the
parent network number.
38 MN2585EU10MN_0002
© 2002 Siemens AG
OriginalNetwork
Original Network
130.5.0.0
130.5.0.0
130.5.0.0 130.5.0.0 /19

130.5.32.0 /19
130.5.64.0 /19
Internet Router 130.5.96.0 /19
130.5.128.0 /19
130.5.160.0 /19
130.5.192.0 /19
130.5.224.0 /19
Fig. 26 Benefits for subnetting within a private network
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
39
© 2002 Siemens AG
40 MN2585EU10MN_0002
© 2002 Siemens AG
5 Routing
Router
Switch
Router Router
Router
Router
Switch
Which
Which way
way
to
to go ?
go ?
Fig. 27 Routing
MN2585EU10MN_0002
41
© 2002 Siemens AG
5.1 Routing principles

5.1.1 Introduction
Routing is the process of reading the destination network address of a datagram and
deciding where to send the datagram next, i.e. to find an available path towards a
given destination network.
The basic routing function is implemented at the Internet (IP) Layer of the TCP/IP
protocol stack. Routing is closely tied to addressing because IP packets are routed
based on their addresses.
An Internet host can function as a normal host and a router simultaneously. A host
that functions as a router has multiple network interfaces (multi-homed). All routers
are multi-homed since their purpose is to join networks or subnets. Each network
adapter on a multi-homed host has a different IP address.
There are two basic types: "direct routing" and "indirect routing".
Direct or Indirect Routing?

When a host is willing to send it has to decide whether the destination host is in the
same (sub)network as the source host. It then determines the network address of the
next destination station (router) to reach the destination host by consulting the local
host's routing table:
If the two network addresses match, the packet can be delivered locally. This is
called "direct routing".
If the two network addresses do not match, the packet cannot be transmitted
locally, but must be forwarded to the next router or the default gateway for further
transmission. This is called "indirect routing".
When a router is going to forward a packet, it must determine whether it can send
it directly to its destination ("direct routing"), or whether it needs to pass it through
another router ("indirect routing").
42 MN2585EU10MN_0002
© 2002 Siemens AG
SIEMENS
NIXDORF
SIEMENS
NIXDORF
Host A Host B
Message
Segment
TCP TCP
IP Packet IP Packet
IP IP IP
Ethernet Ethernet X.25 X.25

Frame X.25 Packet
LAN PSDN
Fig. 28 Routing takes place on Internet Layer
Input
Ports
Router
Input
Port Routing 128.0.5.4
Table
128.1.2.2 128.0.6.6
Datagramms
Routung
Process 128.0.7.2
Fig. 29 Routing
MN2585EU10MN_0002
43
© 2002 Siemens AG
5.1.2 Direct routing

If two computers are located within the same (sub-) network (IP address of source
host and destination host have the same network ID), a packet can be delivered
directly without usage of a router. The destination hardware address corresponding
to the destination IP address is determined. Afterwards, the IP packet is embedded in
an appropriate Network Access Layer frame. In IP-based LANs, the mechanism of
determining the hardware address is implemented by the so-called ARP protocol.
5.1.3 Indirect routing

We speak of "indirect routing" when the destination host is not located within the
same (sub-) network:
1. The next router's/default gateway's Network Access Layer address is determined
using the ARP protocol (see below)
2. The IP packet is embedded in an appropriate Network Access Layer
transmission frame and sent to the next router/default gateway
3. The next router/default gateway decapsulates the IP packet from the Network
Access Layer frame and makes its routing decision based on the (sub-) network
part of the packet's "destination address"
4. The router's/default gateway's interface towards the destination (sub-) network is
determined and the packet is forwarded through it using the next router's Network
Access Layer address.
Each router repeats this process. This principle is also referred to as hop-by-hop
routing.
Indirect routing also includes direct routing

The last router on the packet's way towards the destination (sub-) network must
deliver the packet to the destination host. Once again, direct routing is used in this
case.
44 MN2585EU10MN_0002
© 2002 Siemens AG
Direct routing allows the local delivery of an IP packet without using a router
IP address IP address
MAC MAC MAC
MAC MAC
The destination host is identified based on its IP

The Network Access Layer address. For addressing the destination host on
transmission method Network Access Layer, the sending host uses
is used for transfer. the destination‘s MAC address.
Fig. 30 Direct routing
This host only needs to

know the destination‘s
and the next
router‘s/default gateway‘s
The destination host is identified
IP addresses
by its IP and its MAC address
Router
Router
Router Router Router
Router
Each router decides on which

Routers are used for connections This principle is called hop-by-
interface to forward the packet on the
across network borders hop routing
next hop
Fig. 31 Indirect routing
MN2585EU10MN_0002
45
© 2002 Siemens AG
5.1.4 Routing tables

A basic router contains its ‘stored knowledge‘ in a mapping table, called basic IP
routing table, with information about four kinds of destinations.
Hosts which are directly attached to one of the networks to which the router is
attached
Hosts or networks for which the router has been given explicit definitions
Hosts or networks for which the router has received an Internet Control Message
Protocol (ICMP) Redirect message
A default destination for everything else (called: 'default router' or 'default
gateway')
An entry in a routing table contains:

the destination (sub-) network address (this is also called a "prefix"),
Next Hop Address - the IP address of the adjacent host or router to which the
packet should be sent next,
the egress port,
mostly a metric attribute. It could be the number of hops (e.g. RIP) or the overall
metric (e.g. OSPF, identical topology map for all routers) or other.
The following command can be used to read the contents of a routing table:
Command Operating System

netstat –r[n] Windows or Unix systems.
46 MN2585EU10MN_0002
© 2002 Siemens AG
Routing
Process
Routing IP Packet
Table
SA DA
IP Packets
SA DA SA DA
SA DA
192.16.3.0
192.16.3.0
Router A
Router B 192.16.4.0
192.16.4.0
192.16.1.0
192.16.1.0
192.16.2.0
192.16.2.0
Fig. 32 Routing tables and routing decision
Routing Table of Router A
192.16.1.0 directly connected Eth0

192.16.4.0 via 192.16.3.1 Eth2
Fig. 33 Routing table of router A
MN2585EU10MN_0002
47
© 2002 Siemens AG
5.2 Routing protocols

5.2.1 Static and dynamic routing
Entries in the routing table may be of different characteristic:
Static Routing
Manual configuration is used to establish entries into the routing tables. Entries of
that kind never change their values.
Dynamic Routing
Routing protocols are used for dynamic establishment and update of entries into a
routing table.
Static Routing
Example
In the example below, host A has direct routes to host B and routers D and F, and an
indirect route to host C. Router D is located between networks 128.10.0.0 and
128.15.0.0. Router D has two interfaces with an IP address allocated to each. Router
F is a located between networks 128.15.0.0 and 129.7.0.0. Router F has also two
interfaces with an IP address allocated to each.
The IP routing table of host D will contain the following entries:
Destination Subnet mask Outgoing Interface Route via

128.10.0.0 255.255.0.0 eth0 directly connected
128.15.0.0 255.255.0.0 eth1 directly connected
129.7.0.0 255.255.0.0 eth1 128.15.1.2
This is a static routing table that is created manually when the device is first
configured. Since this routing table represents only a part of the whole Internet, it is
called a router with partial routing information.
TIP
It is quite obvious that manually maintained routing tables can only be used for small
networks, and even then the burden that may result from reconfiguring a network is
considerable.
Configuration examples:
Command Operating System
route add 129.7.0.0 mask 255.255.0.0 128.15.1.2 metric 1 Windows
route add net 129.7.0.0 128.15.1.2 1 Solaris
48 MN2585EU10MN_0002
© 2002 Siemens AG
E C Net
128.10.0.0
Eth0:128.10.1.1 / 255.255.0.0
Router D
Net
Eth1: 128.15.2.4 / 255.255.0.0
128.15.0.0
Eth0:128.15.1.2 / 255.255.0.0
A B
Router F
Net
Eth1: 129.7.1.80 / 255.255.0.0 129.7.0.0
G H
Fig. 34 Network scenario
Fig. 35 The 'route add' command with Windows operating system
Fig. 36 The 'route add' command with Solaris operating system
MN2585EU10MN_0002
49
© 2002 Siemens AG
Dynamic Routing
Dynamic creation of entries in routing tables minimizes the administrative burden of
the operator. Dynamic routing uses routing protocols to exchange network
reachability and topology state information. Based on this information, routers
determine the optimal route through a network towards the destination.
Convergence time is the time required to pass information on topology changes
throughout the network.
What is an optimal route?

A route can be optimal if it uses the smallest possible metric. How the metric is
defined depends on the used routing protocol. A metric may be:
the number of hops between the current router and the destination network
the shortest physical distance
the fastest or possibly the cheapest lines
and other things …
For each physical link between routers an individual metric is implicitly or explicitly
assigned. The lower the overall metric of a route, the better.
50 MN2585EU10MN_0002
© 2002 Siemens AG
Routing Protocol
Router
Switch
Router Router
Router
Router
Switch
What
What isis
an
an optimal
optimal
route
route ??
Fig. 37 Optimal route and routing protocols
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
51
© 2002 Siemens AG
5.2.2 Dynamic routing protocols

More advanced, specialized routers use routing protocols to exchange routing
information. These routers have dynamic routing tables that are automatically
updated as the routers propagate route information to other routers. The routing
protocols provide their own transport layer on top of the IP Layer.
Routing protocols typically use one of two routing algorithms: distance-vector
algorithm (DVA) or link-state algorithm (LSA).
According to this routing algorithms there exists two basic types of dynamic routing
protocols:
distance vector routing and
link state routing.
Both types of protocols attempt to find an optimal route through the network.
5.2.2.1 Distance-Vector Algorithm (DVA)

A distance vector algorithm routing protocol uses as the name is saying a distance of
the point of viewing to the destination. RIP, a DVA routing protocol is using the hop
count as a value (metric) for the distance. Each entry in the routing table identifies a
destination host or network and gives the ”distance” to that host/network. In this case
a route is a better route when it has less hop counts between the source and
destination as another route.
Using distance vector routing, neighboring routers exchange destination network
information and the respective metric extracted from their routing tables. They use
local broadcasts for this type of information transfer.
The router compares its current routing table with the information received from its
neighbors and can thus determine whether there is a better route to the destination. If
this is the case, it can modify its routing table accordingly.
The routing table is updated if another router knows a shorter distance to a
destination or if destinations have been added or changed.
DVA is implemented in the Routing Information Protocol (RIP). RIP uses a simple
hop count as a metric to build dynamic routing tables. The hop count limit is 10.
Updates are sent every 30 seconds.
The Internet Gateway Routing Protocol (IGRP) is proprietary protocol for Cisco
System's routers. IGRP uses a composite metric and has a hop count limit of 100.
Updates are sent every 90 seconds.
52 MN2585EU10MN_0002
© 2002 Siemens AG
Distance Vector Routing (DVR)

Destination Distance Routing table contains the addresses
of destinations and the distance
192.16.1.0 1 of the way to this destination.
192.16.5.0 1
192.16.7.0 2
2 Hops
1 Hop 1 Hop
Router A Router B Router C Router D
192.16.1.0
192.16.1.0 Flow
Flow ofof routing
routing 192.16.7.0
192.16.7.0
information
information
192.16.5.0
192.16.5.0
Fig. 38 The principle of a distance vector algorithm routing protocol using hop count as a metric
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
53
© 2002 Siemens AG
5.2.2.2 Link-State Algorithm (LSA)

A link state algorithm routing protocol does not use the hop count to find the best
route. There each link connection of two router ports gets its own metric. Comparing
the metrics of two links the lower one is the better one. To find the best route to a
destination the route with the minimal overall metric is chosen.
The principle of link state routing

The principle behind link state routing is straightforward, although its implementation
can be complex:
Routers are responsible for contacting neighbors and learning their identities.
Routers construct link state packets, which contain lists of network links and their
associated metric.
Link state packets (LSP) are transmitted to all routers in a network.
All routers therefore have an identical list of links in a network, and can construct
identical topology maps.
The maps are used to compute the best routes to all destinations.
Hello packets
Routers contact neighbors by sending hello packets on their network interfaces. Hello
packets are sent directly to neighbors on point-to-point links and non-broadcast
networks. On LANs, hello packets are sent to a group or multicast IP address that
can be received by all routers. Neighbors who receive hellos from a router should
reply with hello packets that include the identity of that originating router.
Link state information
Once neighbors have been contacted in this way, link state information can be
exchanged. Link state information is sent in the form of link state packets (LSPs),
also known as link state advertisements. LSPs provide the database from which
network topology maps can be calculated at each router.
The routers run an algorithm on the link-state database, which results in a shortest-
path tree. The shortest-path tree is used to build the router’s routing table. The link-
state algorithm ensures that users get faster network responses.
LSA is implemented in the Border Gateway Protocol (BGP) and Open Shortest
Path First (OSPF) protocol.
TIP
Link state packets are sent out to all routers in the network only under following
circumstances:
When a router discovers a new neighbor or a link to a neighbor goes down
When the cost (metric) of the link changes
Basic refreshment packets are sent every 30 minutes (Link State Update=LSU)
54 MN2585EU10MN_0002
© 2002 Siemens AG
A
A specific
specific value
value for
for the
the
Link State Routing (LSR)
„metric“
„metric“ is
is valid
valid for
for
aa connection.
connection.
33 Router C
11 11 Router E
10
Router A
Router D
192.16.8.0
192.16.8.0
22
192.16.1.0
192.16.1.0
11
Router B
The
The best
best way
way from
from network
network 192.16.1.0
192.16.1.0
to
to network
network 192.16.8.0
192.16.8.0 is
is via
via
Router
Router A,
A, B,
B, D,
D, and
and EE because
because
the
the overall-“metric“
overall-“metric“ is
is minimal.
minimal.
Fig. 39 A metric influences routing decisions
Link State Routing (LSR)
SPF
LSP: LSP:
„My links to „My links to R1 and R3 are up.
R2 and R4 are up“ Routing My link to R2 is down.“
Tabelle
Router 1 Router 4
Router 2 Router 3
LSP: „My links to LSP: „My links to

R1 and R3 are up, R2 and R4 are up.“
my link to R4 is down.“
LSP....link state packet

SPF... shortest path first
Fig. 40 Principle of a link state algorithm
MN2585EU10MN_0002
55
© 2002 Siemens AG
56 MN2585EU10MN_0002
© 2002 Siemens AG
6 Network access layer protocols
MN2585EU10MN_0002
57
© 2002 Siemens AG
6.1 Important network access layer protocols

The TCP/IP protocol family runs over a variety of network media. Two important
transmission procedures in this context are communication via an Ethernet-based
local area network (LAN) and the transmission of data packets via point-to-point
connections as used for example to connect subscribers to the so-called service
platform of an Internet provider via wide area networks (WAN).
The Ethernet Standard

There are two different standardizations for the Ethernet, the IEEE-802.3 standard
and Ethernet V2 (DIX standard).
In practice, two different Ethernet protocol variants are used:
IEEE version: the variant standardized by IEEE - frequently known as IEEE, IEEE
802.2 Logical Link Control or IEEE 802.3 Ethernet.
DIX version: the proprietary variant of the manufacturers Digital, Intel and Xerox
(DIX) – this is also frequently known as Version 2 (V2) Ethernet.
For detailed differences between these standards, refer to the recommendations.
WARNING
The required version can be set on the Ethernet cards (set jumper or software). DIX
is usually set as standard since approximately 90% of installed networks use
this version. Please note that all stations in a network that wish to communicate with
each other must use the same version!
TIP
That's the reason why we discuss only Ethernet V2.
The Token Ring Standard

IEEE 802.5 derives from the IBM Token Ring network that contains a ring topology
with access control based on a token. Owing to the low market share, this standard is
not discussed further here.
The Point-to-Point (PPP) Protocol

Another important type of connection is point-to-point connections via serial
transmission lines, for instance dial-in connections (e.g. via ISDN) by a private
Internet user to the access server of his provider.
Other important applications are point-to-point connections over large distances in
data networks (X.25, ATM, etc.). Higher protocols, usually IP, should also be
transmitted on these lines.
58 MN2585EU10MN_0002
© 2002 Siemens AG
TIP
This section highlights some characteristics of common networking services and
provides a brief overview of Internet access options.
TCP/IP
Layers
MIME
Others...
Netbios
SNMP
Telnet
HTTP
TFTP
TCP,
Xwin
DNS
RPC
NFS
FTP
POP3
4 SMTP
3 TCP UDP
2 IP ICMP ARP RARP
1 Ethernet, Token Ring, FDDI, X.25, ATM, SNA, etc.
Fig. 41
MN2585EU10MN_0002
59
© 2002 Siemens AG
6.2 Ethernet V2
The wiring of Ethernet LANs may consist of:
twisted pairs (telephone wiring)
coaxial cable,
fiber-optic links for large distances.
The network devices include repeaters, transceivers, terminators and local net
interfaces (hubs).
Data is transmitted in frames of 64 (minimum) to 1518 bytes (maximum) at a
maximum speed of 10 Mb/s.
Following fields are contained inside an Ethernet V2 frame.
Ethernet destination and source address

For message delivery on LAN's the Ethernet address will be used. Ethernet devices
have a 48-bit (6 bytes) address that is encoded in the hardware.
Type Code Field

The Type Code field of an Ethernet frame header with 16 bits (2 bytes) indicates to
which higher level protocol the packet should be handed next, e.g.:
HEX 08.00 = IP
HEX 08.06 = ARP
Data field
The data field is of variable length (46 … 1500 byte) and contains the data received
from the next higher layer protocol.
Ethernet Checksum
The transmission protocol typically provides a cyclic redundancy check (CRC). The
result of that logical operation will be transmitted in the 16 bit (2 byte) Ethernet
Checksum.
Additionally the transmission protocol and guarantees collision control.
60 MN2585EU10MN_0002
© 2002 Siemens AG
Only that part will be counted
Ethernet
Destination Source Data
Frame Type Checksum
Address Address Field
Preambel Deli- (e.g. IP)
meter (4 bytes)
(6 bytes) (6 bytes) (46 ... 1500 bytes)
(2 bytes)
... which protocol is

This field defines...
included here.
Fig. 42 Ethernet frame - DIX
32 Bits
0 16 32
Ethernet Destination Address (first 32 bits)
Ethernet Destination (last 16 bits) Ethernet Source (first 16 bits)

Ethernet
Header
Ethernet Source Address (last 32 bits)
Type Code
IP Header
TCP Header
Data
Ethernet Checksum
Fig. 43 Ethernet Header
MN2585EU10MN_0002
61
© 2002 Siemens AG
6.3 Fiber Distributed Data Interface (FDDI)

The FDDI specifications define a family of standards for 100 Mb/s fiber optic
networks. The FDDI MAC specification defines a maximum frame size of 4500 bytes
for all frame fields. Every frame provides a CRC.
6.4 Asynchronous Transfer Mode (ATM)

ATM transmits data (voice, images, data, etc.) in fixed 53-byte cells consisting of a 5-
byte header and 48 bytes of data. ATM cells are available with low latency and are
therefore ideally suited for real-time audio/video transmissions.
The data is routed via virtual channels that are set up as a series of pointers through
the network. Cells on a particular virtual channel follow the same path through the
network and are delivered in consecutive order.
62 MN2585EU10MN_0002
© 2002 Siemens AG
7 Internet layer protocols
MN2585EU10MN_0002
63
© 2002 Siemens AG
7.1 Important internet layer protocols

This section presents details about the major protocols of the Internet Layer, the IP
and ICMP protocols. The ARP and RARP protocols, which are used to map local
area network addresses to IP addresses, are also discussed at this level.
The Internet Layer protocols are responsible to ensure a ”best-effort” packet delivery.
These protocols provide the addressing and fragmentation functions that are needed
to allow routers to forward packets across the network.
7.2 Internet Protocol (IP)

IP is a network layer protocol. That's why a lot of features have to be supported by IP.
The Internet Protocol (IP) is responsible for:
Fragmentation/reassembly: adaption to different maximum lengths of frames of
used Network Access Layer
Data delivery: routing of messages to the destination host with network addresses
Addressing higher protocols: there may also be several protocols that use IP
transmission services. IP must therefore be able to address higher protocols.
Transmission integrity: it should be ensured that the IP packet arrives correctly
at its destination. The recipient must determine whether the content was destroyed
during transit.
Quality of service: different applications can have different requirements as
regards quality of service
IP is a connectionless packet delivery service that provides independence of the
physical network (”virtual network view”). The IP network routes each datagram
(packet) independently. The IP protocol offers no reliability, flow control or error
recovery to the underlying network interface protocol. Datagrams may arrive out of
order, may be lost, or even duplicated. IP has no provision for re-transmitting lost or
damaged packets. It is up to higher protocol layers to provide reliability, flow control
and connections.
64 MN2585EU10MN_0002
© 2002 Siemens AG
Further requirements:
Integrity: Delivery to the correct destination
Quality of Service: Sometimes best effort is not enough
Transport Layer TCP UDP
Addressing of higher
layer protocols
Addressing of stations
Network Layer IP SIEMENS

NIXDORF
SIEM ENS
NIXDORF
Frag men tation
Data Link Layer Ethernet 802.5 X.25
Fig. 44 Tasks of the internet protocol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
65
© 2002 Siemens AG
7.2.1 IP datagram
The IP datagram is the base transfer packet in the Internet protocol suite. It has a
header potion and a data portion. The IP datagram is encapsulated (embedded)
within a frame (e.g. PPP frame, Ethernet frame, or ATM cell) that is transmitted via
the physical network.
Each IP datagram header contains a source IP address and a destination IP
address. To send a datagram to a certain IP destination, the target IP address must
be translated or mapped to a physical address for a specific network. This may
require transmissions on the network to find out the destination's physical network
address (for example, on LANs the Address Resolution Protocol (ARP) is used to
translate IP addresses to physical MAC addresses).
Fragments of a datagram all have a header, basically copied from the original
datagram, and data following it. They are treated as normal IP datagrams while being
transported to their destination. If one of the fragments gets lost, the complete
datagram is considered lost since IP does not provide any acknowledgment
mechanism, so the remaining fragments will simply be discarded by the destination
host.
The IP datagram header is a minimum of 20 bytes long and contains the fields shown
below.
66 MN2585EU10MN_0002
© 2002 Siemens AG
IP Datagramm
Physical Network IP Data End

CRC
Frame Header Header Frame Flag
Fig. 45 IP datagram
32 Bits
0 4 8 16 31
Version LEN Type of Service Total Length

D M
Identification 0 Fragment Offset
F F
IP Time to Live (TTL) Protocol Header Checksum

Header
Source IP Address
Destination IP Address
Options Padding
Data
Fig. 46 Fields for addressing stations
MN2585EU10MN_0002
67
© 2002 Siemens AG
7.2.2 All IP header fields
Field Description
VERS Version of the IP protocol. The current version is 4 (IPv4).
LEN Length of the IP header counted in 32-bit quantities (n * 32 bits or 4bytes)
Type of Service Indication of the quality of service (precedence, delay, throughput and
reliability) requested for the IP datagram. IP cannot guarantee availability of the
selected service.
Total Length Total length of the datagram, header and data, specified in bytes
Identification A unique number assigned by the sender to aid in reassembling a fragmented
datagram. Fragments of a datagram will have the same identification number.
Flags Various control flags (e.g. DF for don’t fragment, MF for more fragments)
Fragment Offset Position of fragment relative to original datagram, shows the position in
datagram, where data of a single fragment will be inserted during reassembly.
The fragment offset is measured in units of 8 bytes (0 … 8091 * 8 bytes offset
is possible)
Time to Live Specifies the time in seconds (0 … 255) this datagram is allowed to travel on
(TTL) the Internet before being discarded. Each router passed is supposed to
subtract its processing time.
Protocol Code number for the higher-level protocol to which IP should deliver the data:
Number e.g. 01 = ICMP, 06 = TCP, 17 = UDP
Header Checksum on the IP header only to guarantee error free transmission of the IP
Checksum header. If the header checksum does not match the contents, the datagram is
discarded because at least one bit in the header is corrupt, and the datagram
may even have arrived at the wrong destination. This checksum will be newly
evaluated in each intermediate router.
Source IP 32-bit IP address of the host sending this datagram
Address
Destination IP 32-bit IP address of the destination host for this datagram
Address
Options Options include Internet Timestamp, Record Route, and Stream ID. This field
is used for network testing and debugging.
Padding Variable length field that is used to ensure that the IP header length is an exact
multiple of 32 bits. If an option is used, the datagram is padded with all-zero
bytes up to the next 32-bit boundary.
Data The data contained in the datagram is passed to a higher-level protocol, as
specified in the protocol field. The amount of data that can be transmitted in
one datagram varies depending on the MTU value for the physical network
layer.
68 MN2585EU10MN_0002
© 2002 Siemens AG
32 Bits
0 4 8 16 31

D M
F F

Header
Source IP Address
Options Padding
Data
Fig. 47 IP Header fields
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
69
© 2002 Siemens AG
7.2.3 Fragmentation
In transit from one host to another, an IP datagram can cross-different physical
networks. Physical networks have a limitation for the size of the transmitted data
units, called the Maximum Transmission Unit (MTU). The MTU limits the length of
a datagram that can be placed in one physical frame.
Network MTU (bytes) Typical Frame Size (bytes)

Ethernet 1500 1014
IEEE 802.5 (16 Mb/s) 17,756 1024/4096
X.25 4080 128
IP is responsible for dividing messages to fit into the MTU of the transmission
medium. The fragments are re-assembled at the destination host. The Internet
standards suggest that networks, routers and hosts should be able to handle
datagrams up to 576 bytes without fragmentation.
The Mode of Operation of Fragmentation
Fragments of a datagram all have a header, basically copied from the original
datagram with updated fragmentation flags and fragmentation offset, and data
following it. They are treated as normal IP datagrams while being transported to their
destination. If one of the fragments gets lost, the complete datagram is considered
lost since IP does not provide any acknowledgment mechanism, so the remaining
fragments will simply be discarded by the destination host.
When fragmentation is done, the following steps are performed:
1. The DF flag bit is checked to see if fragmentation is allowed. If fragmentation is
not allowed, the datagram will be discarded
2. Depending on the MTU value, the data field is split into two or more parts.
3. All data portions are placed in IP datagrams. The headers of the datagrams are
updated copies of the original one.
4. Each of the fragmented datagrams is independently routed to the destination.
At the receiving side, the incoming fragments are identified based on the
identification field and the source and destination IP addresses in the datagram.
To reassemble the fragments, the receiving host allocates a buffer in storage when
the first fragment arrives and a timer is started. When the timer times out and not all
the fragments have been received, the datagram is discarded. The initial value of this
timer is called the IP datagram time-to-live (TTL) value.
When subsequent fragments of the datagram arrive, before the timer expires, the
data is copied into the buffer storage, at the location indicated by the fragment offset
field. As soon as all fragments have arrived, the complete original unfragmented
datagram is restored, and processing continues.
70 MN2585EU10MN_0002
© 2002 Siemens AG
32 Bits
0 4 8 16 31

D M
F F

Header
Source IP Address
Options Padding
Data
Fig. 48 Fields used for fragmentation
Fragmentation
Fragmentation
data header
Router Router
Fig. 49 Fragmentation
MN2585EU10MN_0002
71
© 2002 Siemens AG
7.3 Internet Control Message Protocol (ICMP)

When a router or a destination host must inform the source host about errors in
datagram processing, it uses the Internet Control Message Protocol (ICMP). The IP
header fields ”protocol” and ”type of service” will indicate an ICMP message
(protocol=1, type of service=0). The actual ICMP message will be contained in the IP
data field, i.e. ICMP uses IP as if ICMP were a higher-level protocol. However, ICMP
is an integral part of IP and must be implemented by every IP module.
7.3.1 ICMP characteristics

Note that ICMP is used to report some errors, not to make IP reliable. Datagrams
may still be undelivered without any report of their loss. Reliability must be
implemented by the higher-level protocols that use IP.
TIP
RFC 792 states that ICMP messages can be generated to report IP datagram
processing errors, not must. In practice, routers will almost always generate ICMP
messages for errors, but for destination hosts, the number of ICMP messages
generated is implementation dependent.
ICMP can report errors on:

any IP datagram with the exception of ICMP messages, to avoid infinite
repetitions.
on fragmented IP datagrams, ICMP messages are only sent about errors on
fragment zero. That is, ICMP messages never refer to an IP datagram with a non-
zero fragment offset field.
ICMP never report errors in response to:

datagrams with a destination IP address that is a broadcast or a multicast address
(to avoid overload of the network)
datagrams that does not have a source IP address that represents a unique host.
That is, the source address cannot be zero, a loopback address, a broadcast
address or a multicast address.
ICMP error messages (to avoid infinite repetitions).
They can be sent in response to ICMP query messages (ICMP types 0, 8, 9, 10
and 13 through 18).
datagrams with a non-zero fragment offset field.
72 MN2585EU10MN_0002
© 2002 Siemens AG
Router
ICMP
ICMP Error
Error Reports:
Reports: ICMP
ICMP Queries:
Queries:
-- Destination
Destination Unreachable
Unreachable -- Echo
Echo
-- Source
Source Quench
Quench -- Echo
Echo Reply
Reply
-- Redirect
Redirect -- ...
...
-- ...
...
Router
Fig. 50 Internet control message protocol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
73
© 2002 Siemens AG
7.3.2 ICMP messages

An ICMP message consists of the following fields:
Type field specifies the type of error message (see table below)
Code field contains the error code for the datagram reported on by the ICMP
message.
Checksum is computed based on the complete ICMP message.
Data field typically contains part of the original IP datagram for which the ICMP
message was generated.
Type ICMP Error Message Description

3 Destination unreachable If this message is received from an intermediate router, it means that a
network is unreachable.
If this message is received from the destination host, it means that the
protocol (next higher layer) specified in the protocol number field of the
original datagram is not active, or that protocol is not active on this host or
the specified port is inactive.
4 Source quench If this message is received from an intermediate router, it means that the
router does not have the buffer space needed to queue the datagrams for
output to the next network.
If this message is received from the destination host, it means that the
incoming datagrams are arriving too quickly to be processed.
5 Redirect If this message is received from an intermediate router, it means that the
host should send future datagrams for the network to the router whose IP
address is given in the ICMP message.
8/0 Echo / Echo reply Echo messages help to detect if a host is active on the network. Ping is a
monitoring technique that utilizes echo messages to find out if a destination
host is reachable and to determine round trip delays.
11 Time exceeded If this message is received from an intermediate router, it means that the
time-to-live field of an IP datagram has expired.
If this message is received from the destination host, it means that the IP
fragment re-assembly time-to-live timer has expired.
The Trace route utility uses Time Exceeded messages to determine where
in the Internet datagrams expired and pieces together a view of the route to
a host.
12 Parameter problem Indicates that a problem was encountered during processing of the IP
header parameters
13 / 14 Timestamp request / These messages are used for performance measurements and for
Timestamp reply debugging. The sender initializes the identifier and sequence number, sets
the source timestamp and sends it to the recipient. The receiving host fills in
the receive and transmit timestamps, changes the Type to Timestamp reply
and returns it to the recipient.
15 / 16 Router advertisement / Router These messages are used if a host or a router supports the Router
solicitation Discovery Protocol. Routers periodically advertise their IP addresses on
those subnets where they are configured to do so. Router messages are
sent to a all-systems multicast address (224.0.0.1 for advertisements;
224.0.0.2 for solicitations) or to the limited broadcast address
(255.255.255.255).
74 MN2585EU10MN_0002
© 2002 Siemens AG
IP Datagram
Physical
Physical Network
Network IP
IP ICMP
ICMP Data End
End
CRC
CRC
Frame
Frame Header
Header Header
Header Message
Message Frame
Frame Flag
Flag
ICMP
ICMP Header
Header
0 8 16 31
Type
Type Code
Code Checksum
Checksum Data
This
This field
field describes
describes
the
the This
This field
field contains
contains This
This field
field contains
contains
type
type of
of message,
message, additional
additional information,
information, This
This field
field is
is computed
computed information
information for
for aa
e.g.
e.g. destination
destination which
which describes
describes the
the based
based on on the
the complete
complete specific
specific ICMP
ICMP
unreachable
unreachable problem
problem in in more
more detail
detail ICMP
ICMP message
message message
message
Fig. 51 An ICMP message
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
75
© 2002 Siemens AG
7.3.3 ICMP applications
PING (Packet INternet Groper) Utility

Every TCP/IP implementation must include the ability to respond to a ping. A ping
triggers ICMP echo/echo reply messages. The ping utility is used to determine if a
TCP/IP connection to a device is functioning. A source host transmits a ping to a
destination host. If the destination host’s TCP/IP software is functioning properly, it
will return the ping to the destination host. The ping command format is as follows
(optional parameters in brackets):
ping host [packetsize][count]
Option Explanation
host IP address or host name
packetsize size of the ping message (default size 64 bytes)
count number of pings to the host
Examples:
ping 144.19.74.201 (ping of a remote host)
ping 127.0.0.1 (host self-test - loopback)
This command is available in every possible environment (UNIX, Solaris, Windows,
routers, switches, etc.). Depending on the operating system there may be other
options available.
Trace route
The Trace route program can be useful when used for debugging purposes. Trace
route enables determination of the route that IP datagrams follow from host to host.
Trace route is based upon ICMP and UDP. It sends an IP datagram with a TTL of 1
to the destination host. The first router to see the datagram will decrement the TTL to
0 and return an ICMP "Time Exceeded" message as well as discarding the datagram.
In this way, the first router in the path is identified.
This process can be repeated with successively larger TTL values in order to identify
the series of routers in the path to the destination host. Trace route actually sends
UDP datagrams to the destination host, which reference a port number that is outside
the normally used range. This enables Trace route to determine when the destination
host has been reached, that is, when an ICMP "Port Unreachable" message is
received.
TIP
These commands will be discussed later in detail.
76 MN2585EU10MN_0002
© 2002 Siemens AG
ICMP
“Destination Unreachable”
to D
e.g. Destination Port Unknown
From D: C
A Traceroute to A
Router
Router Router
Router
B D
ICMP
“Time Exceeded”
to D: ICMP
ICMP TTL expired “Time Exceeded” ICMP
“Time Exceeded” to D: “Time Exceeded”
to D: TTL expired to D:
TTL expired TTL expired
Fig. 52 Trace route
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
77
© 2002 Siemens AG
7.4 The Address Resolution Protocol ARP

Note: The ARP and RARP protocols are network-specific protocols that translate
between data link addresses (MAC addresses) and IP addresses. These protocols
are called by the IP protocol in order to resolve addressing in a local area network.
Each TCP/IP-based host computer on a local area network (LAN) has two
addresses:
Each TCP/IP-based host computer on a local area network (LAN) has two
addresses:
1. A unique data link address that is built into the network interface (e.g. Ethernet
controllers are manufactured with a built-in 48-bit address.).
2. An IP address assigned by the network administrator to the particular host
computer.
The ARP protocol uses a lookup table (ARP cache) to determine the exact data link
layer address corresponding to the IP address in a packet being routed into the LAN.
When the address is not found in the ARP cache, an ARP request message is
broadcast on a particular subnetwork. If one of the hosts recognizes its own IP
address, it sends an ARP reply message to the requesting host. The ARP reply
contains the physical hardware address of the host and source route information (if
the packet has crossed bridges on its path). The requesting host will store the
destination host’s address and the source route information in the ARP cache. All
subsequent datagrams to this destination IP address can now be translated to a
physical address.
RFC 1577 extends ARP to support ATM subnetworks.
Try it with the command:
arp -a
You will get the ARP cache table, which contains the relation between MAC
addresses and IP addresses.
7.5 The Reverse Address Resolution Protocol RARP

Some network hosts, such as diskless workstations, do not know their own IP
address when they are booted. To determine their own IP address, they use a
mechanism similar to ARP, but now the hardware address of the host is the known
parameter, and the IP address the queried parameter. It differs more fundamentally
from ARP in the fact that a RARP server must exist on the network that maintains
that a database of mappings from hardware address to protocol address must be
pre-configured.
TIP
Today RARP is seldom used. It has been replaced by other protocols like DHCP and
BOOTP.
78 MN2585EU10MN_0002
© 2002 Siemens AG
Host A
ARP Request – Ethernet Broadcast to all hosts
SIEMENS
NIXDORF
„What is the hardware address for IP address 128.0.10.4?“
ARP Reply
SI EMENS
NI X DORF
SIE ME NS
NIXDORF
Host B
IP Address: 128.0.10.4
HW Address: 080020021545
Fig. 53 How does ARP work?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
79
© 2002 Siemens AG
80 MN2585EU10MN_0002
© 2002 Siemens AG
8 Transport layer protocols
Fig. 54
MN2585EU10MN_0002
81
© 2002 Siemens AG
8.1 Introduction to the transport layer protocols

General
Application protocols do not communicate with IP directly, but instead talk to one of
two transport protocols: Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP). In turn these transport protocols pass data to IP, which encapsulates
the data into IP packets that get sent over the network. In essence the transport
protocols hide the network from the application protocols so that they do not have to
deal with packet sizing and other issues, while also shielding the network from having
to multiplex the application protocol traffic (a task that IP can leave to the transport
protocols).
Multiplexing Services
For example, both UDP and TCP provide a multiplexing service to application
protocols by way of application-specific port numbers. Essentially, port numbers
act as virtual post office boxes for messages to be delivered to within a single host,
allowing multiple applications to run on a single host concurrently. When packets
arrive at destination system, they are handed off to the transport protocol specified in
the packet, which then delivers the transport-specific message data to the port
number specified in the header of the message. In this manner, many different
applications can run on the same host, using different port numbers to identify
themselves to the transport protocols.
TCP and UDP Properties

The transport protocol that an application protocol uses is determined by the kinds of
network and application-management services that are required.
TCP is a reliable, connection-oriented transport protocol, providing error-correction
and flow control services that can compensate for IP's unreliable services.
Conversely.
UDP is an unreliable, message-centric transport protocol that offers little functionality
over IP alone.
There are many applications that need to use one of these models or the other, and
only a few applications that use both of them.
TIP
Both, TCP and UDP provide functionality that is above that offered by IP alone, and
both protocols are required to build an effective set of network applications.
82 MN2585EU10MN_0002
© 2002 Siemens AG
TCP/IP
Layers
MIME
Others...
Netbios
SNMP
Telnet
HTTP
TFTP
TCP,
Xwin
DNS
RPC
NFS
FTP
POP3
4 SMTP
3 TCP UDP
2 IP ICMP ARP RARP
1 Ethernet, Token Ring, FDDI, X.25, ATM, SNA, etc.
Fig. 55 TCP in the Layered Protocol Architecture
Transport Layer Protocols

Ports
Ports are
are
used
used to
to address
address
an
an application
application
Mechanisms
Mechanisms forfor
addressing
addressing higher
higher
layer
layer protocols
protocols
TCP: connection oriented
and reliable
UDP: not connection oriented,
not reliable
unreliable, best effort
service assumed
Fig. 56 Transport Layer Protocols
MN2585EU10MN_0002
83
© 2002 Siemens AG
8.2 Ports and sockets

The concepts of port and socket are needed to determine which local process at a
given host actually communicates with which process, at which remote host, using
which transport layer protocol. These concepts provide a way to uniformly and
uniquely identify connections and the programs and hosts that are engaged in them,
irrespective of specific process IDs.
Ports
Each Application Layer process that wants to communicate with another Application
Layer process identifies itself to the TCP/IP protocol suite by one or more ports. A
port is a 16-bit number, used by the host-to-host protocol to identify to which higher
level protocol or application program (process) it must deliver incoming messages.
There are two types of port:
Well-known: Well-known ports belong to standardized services, for example,
Telnet uses port 23. Well-known port numbers range between 1 and 1023. These
ports allow clients to be able to find servers without configuration information and
they are typically odd, because early systems using the port concept required an
odd/even pair of ports for duplex operations. Most servers require only a single
port. Exceptions are the BOOTP (Bootstrap protocol) server, which uses two: 67
and 68 and the FTP (File Transfer Protocol) server, which uses two: 20 and 21.
The well-known ports are controlled and assigned by the Internet Assigned
Number Authority (IANA) and on many systems can only be used by system
processes or by programs executed by privileged users. The reason for well-
known ports is to allow clients to be able to find servers without configuration
information.
Ephemeral (Short lived): Clients do not need well-known port numbers because
they initiate communication with servers and the port number they are using is
contained in the TCP segments/UDP datagrams sent to the server. Each client
process is allocated a port number for as long as it needs it by the host it is
running on. Ephemeral port numbers have values greater than 1023, normally in
the range 1024 to 65535. A client can use any number allocated to it, as long as
the combination of <transport protocol, IP address, port number> (so called
socket) is unique. Ephemeral ports are not controlled by IANA and can be used by
ordinary user-developed programs on most systems.
Confusion, due to two different applications trying to use the same port numbers on
one host, is avoided by writing those applications to request an available port from
TCP/IP. Because this port number is dynamically assigned, it may differ from one
invocation of an application to the next.
UDP, TCP use the same port principle. To the best possible extent, the same port
numbers are used for the same services on top of UDP and TCP. Normally, a server
will use either TCP or UDP, but there are exceptions. For example, domain name
(DNS) servers use both UDP port 53 and TCP port 53.
84 MN2585EU10MN_0002
© 2002 Siemens AG
Port Numbers
Server Client
HTTP Server HTTP Client

Port Number 80 Port Number randomly selected
UDP TCP TCP UDP TCP
IP IP
Data Link Data Link
Physical Physical
S D
D S
Fig. 57 Port Numbers
Some Well Known Port Numbers

TCP/IP
RLOGIN
BOOTP/
BOOTP/
RLOGIN
Telnet
SNMP
DHCP
WWW
SMTP
LDAP
POP3
SNMP
Telnet
DHCP
TFTP
WWW
SMTP
IMAP
LDAP
POP3
TFTP
IMAP
DNS
FTP
DNS
Layers
FTP
44
Port
20/21 23 513 25 110 143 80 389 53 69 67/68 161/162
Numbers
33 TCP
TCP UDP
UDP
EGP
EGP ICMP
ICMP OSPF
OSPF
Protocol
22 08 06 01 17 89
Numbers
ARP
ARP IP
IP RARP
RARP
0806 0800 8035

11 Type Codes or
Ethernet
Ethernet 802.3
802.3 Token
Token Ring
Ring Packet Types
Fig. 58 Some Well Known Port Numbers
MN2585EU10MN_0002
85
© 2002 Siemens AG
Some well known port numbers

Port Number Description Used by Transport Layer
Protocol
0 Reserved ------
5 Remote job entry TCP
7 Echo TCP, UDP
9 Discard TCP, UDP
11 Systat (active users) TCP, UDP
13 Daytime TCP, UDP
15 Netstat TCP, UDP
17 Quoted (quote of the day) TCP, UDP
19 Character generator UDP
20 FTP - data TCP
21 FTP - control TCP
23 TELNET TCP
25 SMTP TCP
37 Time UDP
42 Host name server UDP
43 Whois UDP
53 Domain Name Server (DNS) TCP, UDP
67 Bootstrap protocol server UDP
68 Bootstrap protocol client UDP
69 TFTP UDP
70 Gopher protocol TCP
79 Finger protocol TCP
80 World Wide Web TCP
104 X400-sending service TCP
111 Sun RPC TCP, UDP
123 Network Time Protocol (NTP) UDP
139 NetBIOS session source TCP
161 SNMP network monitor UDP
162 SNMP traps UDP
163 - 223 Reserved ------
86 MN2585EU10MN_0002
© 2002 Siemens AG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
87
© 2002 Siemens AG
Sockets
The socket interface is one of several application programming interfaces (APIs) to
the communication protocols.
Let us consider the following terminologies:
Term Description
Socket An application process uses a socket as a file handle to request
network services from the operating system.
Socket Address The triple: <protocol, local-address, local-port_number>
For example, in the TCP/IP suite: <tcp, 193.44.234.3, 12345>
Conversation Communication link between two processes. (Interprocess
Communication)
Association The 5-tuple that completely specifies the two processes that
comprise a connection:
<protocol, local-address, local-port_number, foreign-address,
foreign-port_number>
In the TCP/IP suite, the following could be a valid association:
<tcp, 193.44.234.3, 1500, 193.44.234.5, 21>
Half- Either <protocol, local-address, local-port_number> or
association <protocol, foreign-address, foreign-port_number>
which specify each half of a connection, either the local or the
remote part
The half-association is also called a socket or a transport address. That is, a socket
is an endpoint for communication that can be named and addressed in a network.
Two processes communicate via TCP sockets. The socket model provides a process
with a full-duplex byte stream connection to another process. The application need
not concern itself with the management of this stream; these facilities are provided by
TCP.
88 MN2585EU10MN_0002
© 2002 Siemens AG
Connection and Socket Pairs
Client A HTTP Server Client B

IP Addr.:10.27.51.3 IP Addr.:10.27.51.1 IP Addr.:10.27.51.2
Port Number: 1127 Port Number: 80 Port number: 1084
TCP TCP
10.27.51.3:1127 10.27.51.2:1084
10.27.51.1:80 10.27.51.1:80
Fig. 59 Connection and Socket Pairs
The socket interface is differentiated by the different services that are provided to the
applications.
The stream socket interface (SOCK_STREAM) defines a reliable connection-
oriented service (over TCP for example) with built-in flow control to avoid data
overruns. The File Transfer Protocol (FTP) is an example of an application that
uses stream sockets.
The datagram socket interface (SOCK_DGRAM) defines an unreliable
connectionless service (over UDP for example). Datagrams are sent as
independent packets. The packet delivery is not guaranteed. Packets are not
fragmented and reassembled. The Network File System (NFS) is an example of an
application that uses datagram sockets.
The Raw socket interface (SOCK_RAW) allows direct access to lower-layer
protocols such as IP and ICMP. This interface is used for testing new protocol
implementations. An example of an application that uses raw sockets is the Ping
command.
SUMMARY
TCP uses the same port principle as UDP to provide multiplexing. Like UDP, TCP
uses well-known and ephemeral ports. Each side of a TCP connection has a socket
that can be identified by the triple <TCP, IP address, port number>. If two processes
are communicating over TCP, they have a logical connection that is uniquely
identifiable by the two sockets involved, that is, by the combination <TCP, local IP
address, local port, remote IP address, remote port>. Server processes are able to
manage multiple conversations through a single port.
MN2585EU10MN_0002
89
© 2002 Siemens AG
8.3 Transport Control Protocol (TCP)

TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a
layered hierarchy of protocols, which support multi-network applications. The
Transmission Control Protocol provides services for a reliable inter-process
communication between pairs of processes in host computers attached.
Basic Data The TCP is able to transfer a continuous stream of octets in each
Transfer: direction between its users by packaging some number of octets into
segments for transmission through the IP network. In general, the
TCPs decide when to block and forward data at their own
convenience.
Reliability: The TCP must recover from data that is damaged, lost, duplicated,
or delivered out of order by the IP network. This is achieved by
assigning a sequence number to each octet transmitted, and
requiring a positive acknowledgment (ACK) from the receiving TCP.
If the ACK is not received within a timeout interval, the data is
retransmitted. At the receiver, the sequence numbers are used to
correctly order segments that may be received out of order and to
eliminate duplicates. Damage is handled by adding a checksum to
each segment transmitted, checking it at the receiver, and
discarding damaged segments.
Flow Control: TCP provides a means for the receiver to control the amount of data
sent by the sender. This is achieved by returning a "window" with
every ACK indicating a range of acceptable sequence numbers
beyond the last segment successfully received. The window
indicates an allowed number of octets that the sender may transmit
before receiving further permission.
Multiplexing: To allow for many processes within a single host system to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the IP
addresses, this forms a socket. A pair of sockets uniquely identifies
each connection.
Connections: The reliability and flow control mechanisms require that TCPs
maintain certain status information for each data stream. The
combination of this information, including sockets, sequence
numbers, and window sizes, is called a connection. A pair of sockets
identifying its two sides uniquely specifies each connection. When
two processes wish to communicate, their TCP's must first establish
a connection. When their communication is complete, the
connection is closed to free the resources for other uses.
Precedence The users of TCP may indicate the security and precedence of their
and Security: communication. Provision is made for default values to be used
when these features are not needed.
90 MN2585EU10MN_0002
© 2002 Siemens AG
TCP – Connection between Processes

Host A Inter - Process Host B
Communication
Process x Process y
…. Port m …. Reliable …. Port n ….

TCP Connection
TCP TCP
Unreliable
IP Packets
IP IP
Fig. 60 TCP - Connection between Processes
SIEMENS
NIXDORF SIEMENS
NI XDORF
Host A Host B
Application Port Port Application
TCP Virtual Circuit

TCP Connection Buffer TCP
IP IP
Network Access Network Access

Internet
Fig. 61 TCP connection
MN2585EU10MN_0002
91
© 2002 Siemens AG
8.3.1 TCP header and segment format

TCP segments are encapsulated in IP packets. The Internet Protocol header carries
several information fields, including the source and destination host addresses. A
TCP header follows the IP header, supplying information specific to the TCP protocol.
This division allows for the existence of host level protocols other than TCP.
Field Name Field Field Description

Length
Source Port 16 bits The source port number identifies the application that
generated the segment, as referenced by the TCP
port number in use by the application on the source
system and is used by the receiver to reply.
Destination Port 16 bits The destination port number identifies the application
that this segment is intended for, as referenced by the
16 bit TCP port number in use by the application on
the destination system. It identifies the application
program that should receive the packet.
Sequence Number 32 bits The sequence number identifies the first data octet in
this segment that has been transmitted. It is required
to verify that the correct order of segments is
received.
Acknowledgment 32 bits If the ACK control bit is set this field contains the
Number value of the next sequence number the sender of the
segment is expecting to receive. Once a connection is
established this is always sent.
Data Offset 4 bits The number of 32 bit words in the TCP Header. This
indicates where the data begins. The TCP header
(even one including options) is an integral number of
32 bits long.
Reserved 6 bits Reserved for future use. Must be zero.
Control Bits 6 bits URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Window 16 bits The number of data octets beginning with the one
indicated in the acknowledgment field which the
sender of this segment is willing to accept.
92 MN2585EU10MN_0002
© 2002 Siemens AG
Encapsulation of a TCP Segment
20 bytes 20 bytes variable length
IP
IP Header
Header TCP
TCP Header
Header TCP
TCP Data
Data
TCP Segment
IP Packet
Fig. 62 Encapsulation of a TCP Segment in an IP Packet
Encapsulation of a TCP Segment

32 Bits
0 16 31
1 Version IHL Type of Service Total Length
2 Identification Flags Fragment Offset

IP
3 Time to Live Protocol = 6 (TCP) Header Checksum Header
4 Source Address
5 Destination Address
1 Source Port Destination Port
2 Sequence Number
3 Acknowledgement Number TCP
4 Data Off. Reserved Flags Window Header
5 Checksum Urgent Pointer
Options and Padding
Data
Fig. 63 Encapsulation of a TCP Segment in more Detail
MN2585EU10MN_0002
93
© 2002 Siemens AG

Length
Checksum 16 bits The 16-bit field that checks the TCP header and the TCP
data.
Urgent 16 bits This field communicates the current value of the urgent
Pointer pointer as a positive offset from the sequence number in this
segment. The urgent pointer points to the sequence number
of the last octet in a sequence of urgent data. This field is
only to be interpreted in segments with the URG control bit
set.
Options variable Either a single byte containing the option number, or a
variable length field that allows the source and destination
hosts to communicate.
Padding variable All zero bytes that are used to fill up the TCP header to a total
length that is a multiple of 32 bits.
TCP Data variable The data portion in a TCP segment is optional. That means,
there are TCP segments exchanged between hosts, which
contain only the TCP header and possible options but no
data.
94 MN2585EU10MN_0002
© 2002 Siemens AG
TCP Header Fields

32 Bits
0 16 31
Source Port Destination Port
Sequence Number
TCP Acknowledgement Number

Header
U A P R S F
Data
Reserved R C S S Y I Window
Offset
G K H T N N
Checksum Urgent Pointer
Options and Padding
Data
Fig. 64 TCP Header Fields
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
95
© 2002 Siemens AG
8.3.2 TCP connections
8.3.2.1 Opening a virtual circuit

Before any data can be transferred, a connection (virtual circuit) has to be
established between the two processes.
There are two methods for requesting a virtual circuit to be opened: either an client
will request an "OPEN" so that data can be sent immediately, or a server will "OPEN"
a port in "listen" mode, waiting for a connection request to arrive from a client.
Passive OPEN
The most simple of the two methods is the passive "OPEN", which is the form used
by servers that want to listen for incoming connections. A passive "OPEN" indicates
that the server is willing to accept incoming connection requests from other systems,
and that it does not want to initiate an outbound connection. Typically a passive
"OPEN" is "unqualified", meaning the server can accept an incoming connection from
anybody.
Active OPEN
Client applications (e.g. a web browser) use active "OPEN" when making these
connection requests. An active "OPEN" is the opposite of an passive "OPEN" , in that
it is a specific request to establish a virtual circuit with a specific destination socket
(typically this will be the well known port number of the server that is associated with
the specific client). On an active "OPEN" command, the TCP will begin the procedure
to synchronize (i.e., establish) the connection at once.
Connection Establishment Protocol

The "three-way handshake" is the procedure used to establish a connection. This
procedure normally is initiated by one TCP and responded to by another TCP. The
three-way handshake reduces the possibility of false connections.
The detailed segment flow to establish a TCP connection:
1. The requesting side (normally the client) sends a SYN segment specifying the
port number of the server that the client wants to connect to, and the clients initial
sequence number (ISN). This is the sequence number of the first segment.
2. The server responds with its own SYN segment containing the servers initial
sequence number. The server also acknowledges the clients SYN by ACKing the
clients ISN plus one (next expected segment from requesting side). A SYN
consumes one sequence number. This is the second segment.
3. The client must acknowledge this SYN from the server by ACKing the servers
ISN plus one. This is the third segment.
These three segments complete the connection establishment. The virtual circuit is
now considered up and operational, with both systems now being able to exchange
data as needed.
96 MN2585EU10MN_0002
© 2002 Siemens AG
Important Fields for Virtual Circuit Set-up

32 Bits
0 16 31
Source Port Destination Port
Sequence Number
Acknowledgement Number
U A P R S F
Data
Reserved R C S S Y I Window
Offset
G K H T N N
Checksum Urgent Pointer
Options and Padding
Fig. 65 Important TCP Header Fields for Virtual Circuit Set-up
Connection Establishment Protocol
Telnet Client Telnet Server
Telnet
Telnet „Connect“
„Connect“
IP: 192.168.109.143 IP: 192.168.109.142
“SYN“ SN=50627, ACK=0
“Three-way Handshake"
“SYN“,“ACK“ SN=1690412290 , ACK= 50628
“ACK“ SN=50628 , ACK=1690412291
Fig. 66 Connection Establishment Protocol
MN2585EU10MN_0002
97
© 2002 Siemens AG
8.3.2.2 Closing a virtual circuit

Closing the connection is done implicitly by sending a TCP segment with the FIN bit
set. As the connection is full-duplex, the FIN segment only closes the data transfer in
one direction. The other process will now send the remaining data it still has to
transmit and also ends with a TCP segment where the FIN bit is set. The connection
ends once the data stream is closed in both directions.
98 MN2585EU10MN_0002
© 2002 Siemens AG
Connection Termination Protocol
Telnet
Telnet „Disconnect“
„Disconnect“
IP: 192.168.109.143 IP: 192.168.109.142
“ACK“,“FIN“ SN=1690413347, ACK= 50691

Closing the Connection
“ACK“ SN=50691, ACK=1690413348
“ACK“,“FIN“ SN=50691, ACK=1690413348
“ACK“ SN=1690413348, ACK= 50692
Fig. 67 Connection Termination Protocol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
99
© 2002 Siemens AG
8.4 User Datagram Protocol (UDP)

UDP is a connectionless protocol that is used in place of TCP when a Transport
Layer connection between the communicating application programs is not required.
UDP carries less overhead than TCP and therefore provides faster service.
UDP is suitable for applications that need message type responses such as routing
protocols (RIP, OSPF) and network timing protocols (NTP). UDP has broadcasting
capabilities that allow it to send messages to the IP network or to a subnet broadcast
address.
UDP adds no reliability, error recovery, or flow-control to IP. There are no sequence
or acknowledgement numbers. Messages can be duplicated or arrive out of order.
One may wonder why a UDP protocol exists, when it would seem that IP could serve
the same function. The reason is simple: IP doesn't do anything but get packets from
one host to another. IP doesn't provide any application interfaces or management
services.
UDP does provide these services, and it provides a consistent environment for
developers to use when writing low-overhead network applications. UDP provides a
mechanism that senders can use to distinguish among multiple recipients on a single
host machine. This called multiplexing / demultiplexing of transmitted and received
datagrams. UDP uses port numbers to direct datagrams that are being delivered
from one application to another application. The port numbers are contained in the
UDP datagrams sent to the server. Each client process is allocated a port number as
long as it needs it by the host it is running on.
100 MN2585EU10MN_0002
© 2002 Siemens AG
UDP in the Layered Protocol Architecture
Campus Campus
Client WAN Server
Router Switch Switch Switch Router
Server Client
Transport User
User Datagram
Datagram Protocol
Protocol UDP
UDP Transport
Transport Transport
Network Network Network Network
Data Link Data Link Data Link Data Link Data Link Data Link Data Link
Physical Physical Physical Physical Physical Physical Physical
• UDP is a connectionless, end-to-end unreliable protocol designed to fit into a

layered hierarchy of protocols, which support multi-network applications.
Fig. 68 UDP in the Layered Protocol Architecture
Application 1 Application 2 Application 3
Port 1 Port 2 Port 3
UDP Multiplexing/Demultiplexing
based on Port #
IP
Network Access
Internet
Fig. 69 UDP multiplexing via ports
MN2585EU10MN_0002
101
© 2002 Siemens AG
UDP Header and Datagram Format

Each UDP datagram is sent within a single IP datagram. Although, the IP datagram
may be fragmented during transmission, the receiving IP implementation will
reassemble it before presenting it to the UDP layer. All IP implementations are
required to accept datagrams of 576 bytes, which means that, allowing for maximum-
size IP header of 60 bytes, a UDP datagram of 516 bytes is acceptable to all
implementations. Many implementations will accept larger datagrams, but this is not
guaranteed.
The UDP datagram has an 8-byte header that is described in the table below:

Length
Source Port 16 bits Indicates the port of the sending process. It is the port to
which replies should be addressed.
Destination 16 bits Specifies the port of the destination process on the
Port destination host.
Length 16 bits The length (in bytes) of this UDP datagram, including the
header.
Checksum 16 bits The 16-bit field that checks the UDP header and the UDP
data.
UDP Data variable The data portion in a UDP datagram. The minimum value
that is allowed in the length field is eight. That means,
there might be UDP datagrams exchanged between
hosts, which contain only the UDP header but no data.
102 MN2585EU10MN_0002
© 2002 Siemens AG
Encapsulation of a UDP Datagram
20 bytes 8 bytes variable length
UDP
UDP
IP
IP Header
Header UDP
UDP Data
Data
Header
Header
UDP Datagram
IP Packet
Fig. 70 Encapsulation of a UDP Datagram
Encapsulation of a UDP Datagram

32 Bits
0 0 16 31
1 Version IHL Type of Service Total Length
2 Identification Flags Fragment Offset

IP
3 Time to Live Protocol = 17 (UDP) Header Checksum Header
4 Source Address
5 Destination Address
1 Source Port Destination Port UDP
2 Length Checksum Header
Data
Fig. 71 Encapsulation of a UDP Datagram in more Detail
MN2585EU10MN_0002
103
© 2002 Siemens AG
104 MN2585EU10MN_0002
© 2002 Siemens AG
9 Application layer protocols
HTTP
TP
TF
DHCP
in TELNET Finger
Rlog
P
FT S
NF
BOOTP
SM SN M
TP P
Fig. 72
MN2585EU10MN_0002
105
© 2002 Siemens AG
9.1 Introduction
The protocols reviewed so far essentially describe data transport via networks. The
following protocols describe the applications that use these transport services. In the
OSI model, these functions are allocated to layers 5 to 7; in the TCP/IP model, they
belong to the application layer. The protocols important within the scope of this
course are presented below.
Application layer protocols communicate with applications on other Internet hosts.
They therefore prescribe uniform standards for the transmission and representation
of data. These must be adhered to, regardless of the operating system for which the
applications were developed.
The implementation of application protocols can vary on different platforms (e.g.
DOS, OS/2) but all of the higher-level protocols have some characteristics in
common:
They can be user-written applications or applications standardized and shipped
with the TCP/IP product.
Each particular TCP/IP implementation will include a more or less restricted set of
application protocols.
They use either UDP or TCP as a transport mechanism. If UDP is used (less
protocol overhead but unreliable transport and no flow control), the application has
to provide its own error recovery and flow control routines.
Most of them use the client/server model of interaction. A server is a system that
offers a service to the rest of the network. A client is the requester of a service. An
application consists of both a server and a client part. Some servers wait for
requests at a well-known port so that their clients know to which IP socket they
must direct their requests. The client uses an arbitrary port for its communication.
The communication between client and server is handled with internal commands,
which are not accessible by users.
The following are brief descriptions of some common Application Layer protocols
used at the Radio Commander.
106 MN2585EU10MN_0002
© 2002 Siemens AG
Application Layer Protocols
TELNET
BOOTP
Rlogin
SNMP
DHCP
SMTP
HTTP
TFTP
NFS
FTP
TCP UDP
ICMP Internet-Protocol ARP
Network-Hardware
Fig. 73 Some protocols of the TCP/IP application layer
The Client Server Model
Client Client Client

Server
A B C
TCP/IP TCP/IP TCP/IP TCP/IP
Internet Network
Fig. 74 The client server model
MN2585EU10MN_0002
107
© 2002 Siemens AG
9.2 Network terminal protocol (TELNET)

The TELNET protocol allows a user to log on remotely to any host supporting this
protocol via a TCP/IP network. TELNET provides a standardized interface, through
which a program on one host (the TELNET client) may access the resources of
another host (the TELNET server) as though the client were a local terminal
connected to the server.
Virtual Terminal
There are many terminals that are non-compatible with each other. Each terminal can
use its own commands, e.g. to control the cursor or edit text.
The TELNET protocol is based on the concept of a virtual terminal (NVT = Network
Virtual Terminal). A virtual terminal simulates the functions of a normal terminal.
There are standardized control commands that are the same for all users of the
virtual terminal. A program must merely be written for each real terminal, which
converts the commands of the real terminal into those of the virtual terminal.
In this way, for example, a movement of the cursor to the right on the real terminal is
likewise converted into a cursor movement to the right on the virtual terminal.
Attributes of a Virtual Terminal

The fundamental attributes of a virtual terminal are:
The data representation is 7-bit ASCII transmitted in 8-bit bytes.
The NVT is a half-duplex device operating in a line-buffered mode. Generated
command lines are sent at once.
The NVT provides a local echo function. The user sees what he is writing on his
own monitor.
Additional Attributes
Most TELNET implementations do not provide graphics capabilities. Operation is
relatively Spartan, as the example shows.
Only commands of the operating system (OS) on the remote station can be executed
(Windows -> DOS commands, UNIX -> UNIX-specific commands, Routers -> Router
OS-specific commands).
TIP
TELNET is standardized in RFC 854 and uses the well-known TCP port 23.
108 MN2585EU10MN_0002
© 2002 Siemens AG
Network virtual terminal
7-bit ASCII, transmitted in 8-bit bytes
Half-duplex device in a line-buffered mode

SIEMENS SIEMENS
NIXDORF NIXDORF
Local echo function
Port 23
Operating TCP SIEMENS

NIXDORF
Operating TCP
System System
IP IP
Network Virtual
Terminal (NVT)
Negotiations
Fig. 75 TELNET and the virtual terminal
Fig. 76 An example for a TELNET session
MN2585EU10MN_0002
109
© 2002 Siemens AG
9.3 File Transfer Protocol (FTP)

File Transfer and File Administration
FTP (File Transfer Protocol) is mainly used to transfer files from one computer
system to another. In addition, files of remote systems can be administered with FTP.
Viewing the directory contents is the task of the operating system.
The principle function of FTP, therefore, is the translation of commands and display
formats, thereby establishing compatibility between different operating systems. FTP
fulfills this task using an array of defined standard network commands.
Client – Server Model

FTP is also based on a client-server model. A client can log on to a server and use
the FTP services following successful authorization.
Technical Attributes of FTP

FTP is a connection-oriented, secure file transfer protocol for ASCII, EBCDIC, and
binary data. FTP uses TCP as a transport protocol to provide reliable end-to-end
connections. The user must have a user name and a password to identify himself to
the server (remote host). The server authenticates the client before it allows the file
transfer. An FTP transaction requires two ports: a data transfer port (port 20) and a
control port (port 21). Control commands for the file transfer can be transmitted via
the control port; the actual data flow flows via the data transfer port.
Commands
The user will issue specific commands to perform FTP operations, such as:
Connect to a remote host (commands: open, user),
Select a directory (commands: cd, lcd),
List files available for transfer (commands: dir, ls),
Define the transfer mode (commands: mode, type),
Copy files to or from the remote host (commands: copy, get, put),
Disconnect from the remote host (commands: quit, close).
The server responds to the client-issued commands with 3-digit reply codes and
comments.
Anonymous FTP
Anonymous FTP sites allow public access to some file directories. The client uses
an anonymous login name and guest password, or some other common password
convention that is explained to the user during the login process.
110 MN2585EU10MN_0002
© 2002 Siemens AG
File Transfer
File Administration
SIEMENS
NIXDORF
Client FTP uses a set of standardized

unified commands Server
Fig. 77 File transfer FTP
SIEMENS SIEMENS
NIXDORF NIXDORF
FTP Client FTP Server
Data Data
Control Control
Transfer Transfer
Module Module
Module Module
Port 21 Port 20
TCP TCP
Control Data
Connection Connection
IP IP
Internet
Fig. 78 FTP connections
MN2585EU10MN_0002
111
© 2002 Siemens AG
9.4 Network File System (NFS)

However, as opposed to FTP, with NFS there is no need to use a special utility (or
commands) to access files on another system. NFS permits the creation of a virtual
file system that allows file access as if there are some extra drives (virtual drives) on
the local system. NFS is designed for heterogeneous networks (traditionally UNIX
networks, but also applicable to VMS, MVS, DOS, NetWare).
NFS is implemented by a group of processes (called daemons in UNIX).
Configuration files describe how NFS is set up on the server and on the clients.
NFS is a protocol for mounting remote file systems on a host and writing/reading of
those files. It was originally developed by Sun Microsystems.
Mounting and accessing files over the network is used when users want to access
remote files systems in the same fashion as they access local files systems, i.e. the
following I/O output functions are available:
Access (resolution of access rights)
Lookup (search for files in current directory)
Read/Write (read and write files)
Rename (change file names)
Remove (delete files)
Mkdir, rmdir (create and delete directories)
TIP
NFS is standardized in RFC 3010 and is running either on TCP using the well-known
port number 2049. It makes use of Remote Procedure Calls (RPC).
NFS in Solaris environment

At Solaris there are different configuration files dealing with NFS
Server configuration file: /etc/dfs/dfstab
contains all file systems on the server that will be automatically enabled as shared
file systems after reaching Run level 3.
Client configuration file: /etc/vfstab
contains all mount points of a client machine including all shared file systems on
NFS servers. An entry for a remote file system looks like:
<NFS server name>:<shared file system on remote host>
112 MN2585EU10MN_0002
© 2002 Siemens AG
root
NFS Server Configuration

Files
clients etc. bin
Op1 Op2 Op3
Exported and
Visible to Clients
SIEMENS
NIXDORF
File
System
UNIX MacIntosh IBM PC

Workstation (Mac OS) (MS-DOS)
VAX/VMS
NFS Client NFS Client NFS Client
NFS Client
Fig. 79
Solaris NFS server commands

Command meaning
dfshares Shows which file system on current host are enabled as
shared file systems.
dfmounts Shows which shared file systems on current host are
currently in use (mounted) by which NFS client.
showmount Shows all NFS clients which currently use (mounts) shared
file systems on current host.
share/unshare Enable/disable a file system as shared file system.
shareall/unshareall Shares/unshared all file systems listed in /etc/dfs/dfstab of a
NFS server
Solaris NFS client commands

Command meaning
mount Used to mount a shared file system enabled by the NFS
server to the file system on the NFS client..
MN2585EU10MN_0002
113
© 2002 Siemens AG
9.5 Rlogin
Rlogin is also used to login into remote hosts; its functionality is very similar to that of
TELNET. In contrast to TELNET, rlogin is typically supported in UNIX (Solaris)
environments only. One of the advantages when compared to TELNET is indeed,
that the UNIX semantic can better be transferred than with TELNET.
Rlogin has flow control capabilities, where the server can send START/STOP
sequences to throttle down the sender in case its buffer overflows.
Rlogin always uses remote echoes: The characters seen on the client's screen have
been sent by the server. By this, the user can be sure the data have reached the
server. This also is a difference with TELNET, where remote echo is an option only,
while local echo (characters typed in appear on the screen immediately without
crossing the network) is the standardized operation.
In UNIX environments it is common to set up trusted hosts: All hosts defined in a
specific file (in Solaris: $HOME/.rhosts) on a specific host are allowed to log into that
specific host without any password required.
WARNING
Obviously, the feature of trusted hosts should be used with extreme care, since
no further password protection exists.
Rlogin Operation
When login into a remote host, clients go through a rlogin connection setup
procedure, where client- and server user name as well as terminal type (VT100,
VT52 etc) as well as speed (e.g. 9600 baud) is being communicated. After successful
connection setup, data can be transmitted.
Rlogin runs on the well-known TCP port 513.
Other Remote Commands (UNIX-Specific Network Commands)
Command Meaning
rsh remote shell
rcp remote copy
rwall remote write to all users
rwho remote list of users logged in
ruptime remote display of computers that are up on the network
114 MN2585EU10MN_0002
© 2002 Siemens AG
Remote Login (Rlogin)

Features
• Flow control possible
• Remote echo
• “Trusted Hosts” possible
Fig. 80 Rlogin features
Rlogin Connection Setup
Empty character string
Client user name
Server user name
Terminal type and speed
Empty character string
Fig. 81 Rlogin connection setup
MN2585EU10MN_0002
115
© 2002 Siemens AG
9.6 The X window system based on the X protocol

The X Window system (hereafter referred to as X) is one of the most widely used
graphical user interface (GUI), or bitmapped-window display systems. It is supported
by all major workstation vendors, and is used by a large and growing number of
users worldwide. The X Window system offers more than just a raw environment. It
also offers a platform for uniquely incorporated commercial packages. In addition to
writing application software, some industry groups have created proprietary software
packages and standards for interfaces that leverage the display capabilities of the X
Window system. These packages are then integrated into applications to improve the
look and feel of them.
The three most significant commercial packages in this area are
the Open Software Foundation's MOTIF
UNIX International's Open Look.
Solaris Common Desktop Environment CDE
X Operation
Basically there are two parts communicating with each other:
The application, which gets input from the user, executes code, and sends output
back to the user. Instead of reading and writing directly to a display, the application
uses the Xlib programming interface to send and receive data to/from the user's
terminal. The station running the application is called the X client.
The user's terminal, running a display-managing software which receives/sends
data from/to the application and is called the X server.
X client and X server can be on different hosts. They use the TCP/IP protocol to
communicate over the network. Multiple X client applications can communicate with
one X server. The X server displays the application windows and sends the user
input to the appropriate X client application. The X client is notified by events from the
X server whenever other clients change something on the display. The client
applications send request messages to the X server. The X server can also send
event messages to the applications. Event messages indicate changes to the
windows and user input (mouse and keyboard).
The following elements are part of the X Window System:
X Window Manager
This is an X client program on the workstation where the X server runs. The
window manager permits windows to be resized, moved, and otherwise modified
on demand.
X Protocol
This protocol describes the format of messages exchanged between client and
server. It uses a reliable byte stream connection (TCP).
116 MN2585EU10MN_0002
© 2002 Siemens AG
The X Protocol
Application Client Application Server
Appl.
TCP/IP Network
X Server X Client
Create Window
Window Created
• X is used to implement a graphical user interface on the application client (look-

and-feel determined by window manager, e.g. MOTIF, OpenLook)
• The X protocol sends all changes with respect to the graphical output to X
server/client
Fig. 82 The X protocol
Xlib
This is a collection subroutines which translate client requests to X protocol
requests, parse incoming messages (events, replies, and errors) from the X
server, and provide several additional utilities, such as storage management and
operating system independent (portable) operations.
X Toolkits
The toolkits are facilities to implement the display layout and common user-
interface objects (buttons, menus, and scrollbars).
Widgets
These are X windows plus some additional data and a set of procedures for
operating on that data on the client-side
TIP
The X protocol (i.e. the X display Manager Control Protocol, in X terms) uses TCP or
UDP, and ports in the range of 6000-6063. It is standardized by the X consortium.
RFC 1198 mentions the relevant X consortium standards.
MN2585EU10MN_0002
117
© 2002 Siemens AG
9.7 Simple Network Management Protocol SNMP

Network management is the monitoring of a network in order to take action as
needed to deal with failures and other changes. This task involves gathering
statistical data and status information about a network.
Network management protocols allow the remote management of network devices
such as bridges, routers, and gateways.
The SNMP is one of the common protocols used to communicate management
information between the network management stations and the agents in the network
elements (such as hosts, gateways and terminal servers.
9.7.1 SNMP framework

SNMP is used for management large amount of network elements in a network. The
network management framework for TCP/IP-based Internets consists of:
SNMP agents: Each managed device contains an SNMP agent. This piece of
software is used to establish a communication between the managed object and
an SNMP management station
SNMP management station: Every-SNMP-managed network contains at least
one management station. This station is used for displaying information delivered
by the network elements, and also for typing in configuration commands to be sent
to the managed objects.
Management Information Base (MIB): Management information is stored in a
data repository on the network elements, which is called the Management
Information Base (MIB) (standardized in RFCs 1155 and 1213). The MIB defines
the objects that may be managed for each layer in the TCP/IP protocol. Examples
of objects are System Group, Interfaces Group, Address Translation Group, and IP
Group. MIBs can be proprietary or standard. A proprietary MIB requires a
proprietary network management solution.
Transfer protocol (SNMP): SNMP itself is used for transporting management
information between management stations and SNMP agents across the IP
network such as hosts, gateways and terminal servers (standardized in RFC
1157).
TIP
SNMP information is transported via UDP using port 161, trap messages use port
162. SNMP has gone over a number of iteration steps. the standards mentioned
above refer to SNMPv1. A version 2 of the standards with fundamentals
improvements with respect to security has also been devised. At the moment of this
writing, version 3 of the SNMP standard is in the process of being finalized.
118 MN2585EU10MN_0002
© 2002 Siemens AG
SNMP Framework
Management Station
Management Agent
Router
MIB
IP Network
SNMP
Fig. 83 SNMP framework
MN2585EU10MN_0002
119
© 2002 Siemens AG
9.7.2 SNMP management stations

SNMP network management stations are central devices that receive all
management-related information, or may be used to configure network elements.
Originally (SNMPv1), there was just one management station in the network. Starting
with SNMPv2, network management stations could be distributed accessing a
common database.
There is no common management station standard for a graphical user interface. A
lot of companies use their proprietary implementations. At the time of this writing,
there was, however, a quasi standard, where most network element vendors try to be
compatible with. This is HP OpenView from Hewlett Packard.
Network management station performance should be adapted to the network that is
to be managed: Network management places a high workload on the stations.
9.7.3 SNMP management agents

SNMP network management agents are programs running on every network
element. They are used as communication interfaces between the network element
and the network management station.
In SNMP frameworks, management agents are typically queried periodically by the
network management station. Typical management tasks (e.g. collection of statistical
data) is done locally on the network element. Periodically, the collected data (these
may even be pre-processed) are sent to the network management station. In
emergency cases, traps may also be sent (see "SNMP Operation" below).
9.7.4 Management Information Base (MIB)

The MIB is a data repository for management purposes and located on every
managed network element. It is used for storage of management data and queried by
the SNMP management agent.
The SNMP is organized in a treelike structure. Every node is assigned a number. The
sequence of these numbers is used to access a certain entry in the MIB (see SNMP
Operation below).
The MIB consists of a standardized and a private part. The private part contains
information that is specific to the specific network element (e.g. status of a power
supply). Private MIBs must be available in the network management station also,
otherwise these private entries cannot be accessed. MIB-II is a specific enhancement
of the Management Information Base.
Typically, a network management station contains a MIB compiler (mediation
function) that can be used to make MIB information available to the management
station, if written in standard format (ASN.1 in case of Q3). The problem here is,
however, that not all vendors make their private MIBs available in stand-alone form.
120 MN2585EU10MN_0002
© 2002 Siemens AG
SNMP Mangement: Stations and Agents

• Management Stations
– central management access point
– one or many stations
– HP OV most common as graphical user interfac
• Management Agents
– software needed on every network element
– communication interface between management
station and MIB
Fig. 84 SNMP network management stations and -agents
Management Information Base

Root
Joint ISO-
CCITT (0) ISO (1)
CCITT (2)
Other int‘l
organiz. (3)
assumed in RFC 1155 DoD (6)
IAB (1)
experiment.
Directory (1) Mgmt (2) private (4)
(3)
enterprise
MIB (1)
(1)
Interfaces Address e.g.

System (1) IP (4)
(2) Transl‘t (3) Comp. 9 (9)
Some of the ifNr (1) ifTable (2)

MIB-II groups
(RFC 1213) if Entry (1)
private MIB
ifIndex (1) ifDescr (2) ifType (3) ifMTU (4)
Fig. 85 Example structure of a MIB
MN2585EU10MN_0002
121
© 2002 Siemens AG
9.7.5 Simple Network Management Protocol (SNMP) operation
SNMP commands
SNMP is a protocol used to transport management information across the network.
The term "simple" stems from the fact that the protocol does not offer too much
functionality.
Five commands are available:
GetRequest Retrieve values for a specific object from the MIB
GetNextRequest Walk through specific portions of the MIB
SetRequest Alter the values of a specific object in the MIB
GetResponse Response from GetRequest, GetNextRequest, SetRequest
Trap Send a message to management station (SNMP trap receiver)
asynchronously
Usually, the management station queries the network elements periodically using the
GetRequest and the GetNextRequest. In the case that information must be sent
immediately, the management agent may sent information asynchronously.
Each request/set command contains information on the MIB entry to be modified or
queried. These are identified by a sequence of numbers. Each number identifies a
node in the MIB tree (e.g. 1.3.6.1.2.1.2..2.1.2.0 for the interface description in the
picture above, "0" indicating "this value").
TIP
A message in the SNMP protocol consists of a version identifier, an SNMP
community name and a Protocol Data Unit (PDU).
TIP
The Common Management Information Protocol over TCP/IP (CMOT)
is a network management architecture that has been developed to move towards a
closer relationship with the Open System Interconnection (OSI) network management
standards named Common Management Information Protocol (CMIP). In the OSI
approach the management can occur only over fully established connections
between the managers and the agents. CMOT allows management information
exchange over connectionless services (datagram).
122 MN2585EU10MN_0002
© 2002 Siemens AG
SNMP Manager SNMP

Managed System
Managed
Resources
Management SNMP Object

SNMP
Application Managed Objects
Manipulation
get_response
get_response
get_next
get_next
event
event
get
set
get
set
SNMP
SNMP Manager SNMP Manager
Messages (PDUs)
UDP UDP
IP IP
SNMP
SIEMENS
NIXDORF
Network Access Network Access Device
Fig. 86 SNMP commands
SNMP Commands
SNMP Commands
GetRequest
GetNextRequest
SetRequest
GetResponse
Trap
Command Structure (Example)
SNMP Command Position in MIB tree
Map request/response
Version (Community) PDU Request Object 1 Object 2 Object 3 ...

0 0
(1, 2, or 3) Password Type ID Value 1 Value 2 Value 3
The example is valid for GetRequest, GetNextRequest, SetRequest variable bindings

Other commands use a slightly different command structure
Fig. 87 SNMP message structure
MN2585EU10MN_0002
123
© 2002 Siemens AG
124 MN2585EU10MN_0002
© 2002 Siemens AG
10 IP based O-link
MN2585EU10MN_0002
125
© 2002 Siemens AG
10.1 Basics
This feature introduces the IP based O-link between the BSC (Base Station
Controller) and the RC (Radio Commander) as well as between the BSC and the
CBC (Cell Broadcast Center). The TCP/IP link uses Ethernet 10/100 Base T.
Operators, which currently have applied a X.25 network, now can replace their X.25
network by an IP network, which significantly speeds up the O-link. The IP based O-
link is introduced in addition to the already supported X-25 link.
TIP
The BSC supports either X.25 or IP exclusively, while the RC also supports
mixed configurations, e.g. X.25 and IP connections can be used
simultaneously.
The option of handling IP based O interfaces expands the BSC, by replacing the
existing MPCC (Microprocessor Control Circuit) and TDPC (Telephony Distribution
Processor Circuit) boards by the new versions MPCC V8 and TDPC V7. Although the
key functionality is implemented within the MPCC board, both boards have to be
exchanged as MPCC and TDPC operate closely together.
These new processor versions (MPCC V8, TDPC V7) also are needed to implement
the HC BSC, step 2 providing 900 TRXs.
126 MN2585EU10MN_0002
© 2002 Siemens AG
OMP - BSC connection:

OMAL
Via A interface (PCM lines) Via X.25 packet data network

and nailed-up connection (NUC) (switched virtual circuit) or
through the MSC point-to-point dedicated link
Via IP network (IP based O-link

between the BSC and the RC)
New in BR7.0
Fig. 88 implementation of OMAL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
127
© 2002 Siemens AG
10.2 SBS/RC Implementation

SBS implementation
The new functionality is introduced via the new MPCC board V8, which supports the
dedicated IP link to the BSC front panel connector to Ethernet 10/100 Base T. To
assure data consistency between MPCC and TDPC, both processor cards have to be
exchanged (i.e. TDPC version V7 is required). This feature is not applicable to old
BSC racks without door, where the 100Mbit/sec link would generate an unacceptable
level of electromagnetic environmental pollution – i.e. there is needed the C20 rack.
The BSC is equipped with two connectors to support either X.25 links (each
connector supports one X.25 link) or IP links in an exclusive way. In case of X.25 the
cable will be connected to the already existing IXLT (Interface X.25 – Local
Terminal), in case of IP the same connectors on top of BSC will be used to connect
to the new MPCC boards Ethernet port. Obviously this applies to both MPCC cards..
The new MPCC board does not support the interface via PCM time slots. Therefore,
there is a need for conventional IXLT cards to connect the LMT, to handle power
ON/OFF requests and to support X.25 interfaces, particularly for the purposes of
backward compatibility.
For redundancy the BSC is equipped with two MPCC boards. The MPCC board
redundancy is active/standby. The active/active configuration, which is possible for
IXLT cards is not provided by the MPCC boards.
The example illustrates the connection similar to the Y cable. The port of each MPCC
is directly connected to the same collocated router.
RC implementation
The RC supports both – the X.25 link and the IP link via an appropriate
communication board. IP and X.25 connections can be used simultaneously.
As the physical Ethernet link is a reliable connection, which is shared between
multiple hosts with or without bridges, in the first step, the Radio Commander does
not support redundancy, but it is provided by the BSC, which represents the most
important part of redundancy.
Since the RC supports both – X.25 networks and IP networks. So the system
upgrade from X.25 networks to IP networks can be done smoothly and stepwise
(BSC per BSC).
128 MN2585EU10MN_0002
© 2002 Siemens AG
Dedicated Link
MPCC Ethernet 10/100 Base T
Board To the BSC Connector
Fig. 89 MPCC board supports the IP link
LMT
LAN
LMT V.11 64Kbit/sec
IP-0 RC
X.25 Dedicated Active
IXLT-0 MPCC-0
X.25 PCM Timeslot Hub or
Switch or
BSC Router
X.25 Dedicated
IXLT-1 CBC
Standby
X.25 PCM Timeslot MPCC-1 X
Test only
Fig. 90 MPCC status and IP link
MN2585EU10MN_0002
129
© 2002 Siemens AG
The next example fully exploits the separate IP links of both the active and standby
MPCC with respect to their separate IP addresses. The redundant aspects concern
separate IP connections, e.g., separate gateways. When testing the standby MPCC
board, a complete IP network-separated connection is under test.
RC
Active
MPCC-0 IP-0
IP
BSC
Router Network
Standby
MPCC-1
X CBC
Test only
RC
Active
MPCC-0 IP-0
Router
Router
BSC IP
Network
Standby
MPCC-1 Router
X
Test only
CBC
Fig. 91 BSC - RC connection via IP network
130 MN2585EU10MN_0002
© 2002 Siemens AG
Address Handling
Two IP addresses must be uniquely defined for each BSC, as each BSC is equipped
with two MPCC boards – one active board and one standby board. The active IP
address is always related to the active MPCC copy, while the additional one is
always associated with the standby one. The RC or the CBC reaches the active
MPCC board at the BSC via the corresponding active IP address. The additional IP
address is necessary for testing purposes with respect to the standby MPCC board.
To each Ethernet port there is assigned a unique Medium Access Control (MAC)
address. The following figure shows the association between the IP addresses and
the MAC addresses. There is only one active IP address, which corresponds at
different times and in an exclusive way to two different MAC addresses.
Active M Router Stby M IP-1 Router

A IP-0 A
C C (test only) IP-1/MAC-0
IP-0/MAC-0
MPCC-0 - MPCC-0 -
0 0
IP-0 IP-0
Stby M IP-1 Active M

A
(test only) A IP-0
C IP-1/MAC-1 C IP-0/MAC-1
MPCC-1 - MPCC-1 -
1 1
Fig. 92 Address handling
MN2585EU10MN_0002
131
© 2002 Siemens AG
Availability checks by the system

The system behavior avoids link reconfigurations at best. For example, if the operator
requires the locking of the active MPCC copy, the system accepts such an instruction
only if the IP link on the other MPCC copy is available.
In addition the standby link is permanently checked by the system to inform the
operator about its availability. The link check is performed:
on operator request
automatically by the system whenever needed (e.g. before an MPCC switch)
periodically by the system.
Faulty links are indicated by the system via an appropriate message to the state and
alarm management.
132 MN2585EU10MN_0002
© 2002 Siemens AG
10.3 Database parameters

10.3.1 SBS database Implementation
The IP link is in the BSC under the object IPLI specified.
Parameter Object Range Description

Link that is used to realise OMAL.
LINKTYPE OMAL X25A, X25D, IPLI IPLI means IP link, X25A nailed up
and X25D direct connection.
Link that is used to realise CBCL.

LINKTYPE CBCL X25A, X25D, IPLI IPLI means IP link, X25A nailed up
and X25D direct connection.
String of 7 ... 15 IP address that is used for the MPCC

PRIMARYIPADDR IPLI
characters in provining service state
SECONDIPADDR String of 7 ... 15 IP address that is used for the MPCC

IPLI
characters in standby state
String of 7 ... 15 IP address of the default gateway

GATEWAY0 IPLI
characters, null connected to the MPCC copy 0
GATEWAY1 String of 7 ... 15 IP address of the default gateway

IPLI
characters, null connected to the MPCC copy 1
String of 7 ... 15
SUBNETMASK IPLI BSC subnetwork mask
characters, null
Fig. 93 Parameters for IP link
MN2585EU10MN_0002
133
© 2002 Siemens AG
10.3.2 RC database Implementation

The IP base O-link is specified at RC at new object LANCARD and already existing
object OLINK.
Parameter Object Range Description

represents the IP address of the RC
0.0.0.0 ...
ipAddress LANCARD terminal, i.e. the local IP address of
255.255.255.255
the OMP
represents the subnet mask used in

0.0.0.0 ... the network of the RC terminal, i.e.
netMask LANCARD
255.255.255.255 the locally used subnet mask of the
OMP network
IP address of the remote controlled
NE (e.g.: 10.10.105.11)
0.0.0.0 ...
remoteNsap OLINK corresponding to
255.255.255.255
PRIMARYIPADDR of IPLI in SBS
database
Port of LANCARD used for the

primaryPort OLINK LANCARD:0
OLINK
Fig. 94 Parameters for IP link
WARNING
Because of the fact that a LAN-card supports only one port, it is not possible to
create any port on the LANCARD object. All needed information like local
NSAP (IP address) has to be set during LANCARD modification.
For IP based O-link no secondary port can be specified.
134 MN2585EU10MN_0002
© 2002 Siemens AG
11 Aspects of network configuration under

Solaris
MN2585EU10MN_0002
135
© 2002 Siemens AG
11.1 General
Since the Radio Commander runs on Solaris operating system this chapter is
dedicated to the aspects of network configuration under Solaris.
11.1.1 Host
An Internet host is a device that has been assigned an Internet address and has the
proper hardware and software to run TCP/IP and connect to the Internet. A host can
also be referred to as a node.
11.1.2 Standalone machine

A standalone machine (refer to the installation procedure of OMT and omp) is a
machine, which can be used standalone. This means, the machine has its own
processor and hard disk. It can load its operating system independent from other
machines. A standalone machine can have of course a network interface. Using this
interface it is able to use resources and services in the network as fileservers and
printers.
11.1.3 Server
There are a lot of Servers possible in a network. In case of the OMC-B the term
"server" is used in conjunction with the X-term server and of course the omp. A
server is nothing more than an application running on a particular hardware, offering
services to other applications. In Solaris (and in many other operating systems) client
and server can run on the same machine.
11.1.4 X-terminal
An X-terminal is a terminal, which owns the capability to display and control a
graphical user interface. This type of terminal has in minimum a processor and RAM.
Both is used only to manage the GUI (graphical user interface). A so called X-Server
runs on an X-terminal, which is a piece of software, interfacing an application process
and the graphic card. The application mentioned above runs on another workstation.
Using the X11 protocol, an X-terminal displays the application data of a remote
application on the local screen. In case of the OMC-B a normal OMT is used as X-
term server and a Sparc 20 is used as X-terminal.
136 MN2585EU10MN_0002
© 2002 Siemens AG
X-terminal, runs the X-Server S IE M E N S

N I XD O R F
X11 messages
X-Client (Application)
Fig. 95 X-terminal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
137
© 2002 Siemens AG
11.1.5 Repeater
A repeater is a device which propagates electrical signals from one cable to another
without making routing decisions or providing packet filtering. As opposed to a bridge,
a repeater is not selective, all traffic is repeated.
11.1.6 Hub
A hub is also referred to as concentrator. It provides a star shaped network. It is the
most convenient way to make up a network. Depending on the model it is possible to
configure a hub using SNMP.
11.1.7 Bridge
One of the networking elements supported by the OMC-B is a bridge. A bridge
divides one logical network into two or more physically divided networks. So it is
possible to isolate a particular part of a network with high traffic load, to avoid that
other parts of the network slow down due to traffic which is not dedicated to the
elements of this network part.
11.1.8 Router
A router is a host with more than one network interfaces. By its routing information
the router decides via which connection an incoming packet has to be passed on. A
router can have a static routing table or a particular routing software working on the
base of a particular routing protocol. The most known routing protocols are the RIP
(routing information protocol) protocol and the OSPF (open shortest path first)
protocol (see above).
11.1.9 Gateway
A gateway interconnects different networks types at higher levels than routers. A
gateway supports address mapping from one network to another and provides
transformation of data between different network environments. A host cannot send
an IP datagram through a gateway: it can only send it to a gateway.
138 MN2585EU10MN_0002
© 2002 Siemens AG
LAN 139.7.0.0
Router
LAN 139.8.0.0
Fig. 96 Router implemented in a multihomed host
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
139
© 2002 Siemens AG
11.2 Important files for the network configuration

Some files important for the network configuration shall be discussed in the following.
11.2.1 /etc/inet/hosts
This file contains the assignments between IP address and hostname. Here you
should find all the workstations that have been configured during the OMT
installation. From the OMC point of view it is not recommended to add a workstation
manually to this file. For this, only the "Network editor" or during first installation the
"Configuration wizard" should be used. There is furthermore a link called /etc/hosts
pointing on the file /etc/inet/hosts to obtain compatibility between Solaris and other
Unix systems.
11.2.2 /etc/inet/networks
This file contains the assignment between a network's number and its name. It fulfils
the same task as the file /etc/inet/hosts but related to the networks known to a host.
This file may be used by the commands "route" or "netstat". There is furthermore a
link called /etc/networks pointing on the file /etc/inet/networks to obtain compatibility
between Solaris and other Unix systems.
11.2.3 /etc/inet/netmasks
In the case of subnetting the netmask for the network can be set in this file which will
be read during system start. In general this will be defined during the installation of
Solaris. According to the settings in that file the IP address will be subdivided into
network part and host part. There is furthermore a link called /etc/netmasks pointing
on the file /etc/inet/netmasks to obtain compatibility between Solaris and other Unix
systems.
11.2.4 /etc/defaultrouter
This file can contain a list of hostnames (defined in /etc/inet/hosts) or IP addresses. A
packet sent to a network, which has no explicit entry in the routing table, is forwarded
to one of the machines which are mentioned in this file. These machines therefore
are used by turns as default routers.
11.2.5 /etc/notrouter
By creating this file, the system administrator can forcedly disable the routing
capability of a host.
140 MN2585EU10MN_0002
© 2002 Siemens AG
Will be created automatically during OS installation and

should never be changed manually
Will be created automatically during

OS installation
Will be automatically created by

„Network editor“ or during RC
installation (ium_configuration.cfg)
Fig. 97 /etc/hosts
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
141
© 2002 Siemens AG
11.3 Important commands to administer a network

under Solaris
Solaris offers a lot of commands to administer and check a local area network. Some
of them are explained in the following.
11.3.1 The arp command

This command is used to manage the arp cache of a host. It contains the assignment
between MAC and IP address of a host.
The arp cache is volatile, that means an entry which has not been used in 20 minutes
will be erased.
The arp command can be executed as follows:
arp <hostname>
With no flags, the program displays the current ARP entry for hostname. The host
may be specified by name or by the IP address.
arp -a
Display all of the current ARP entries. The definition for the flags in the table are:
Flag Description
P Publish: address has explicitly been added by the -s option (manual entries)
S Static: not learned by the ARP protocol, these entries will not been updated
after 20 minutes
U Unresolved: waiting for ARP response, ARP request has been done
already (this is usually a transient state)
M Mapping: only used for the multicast entry 224.0.0.0
arp -d <hostname>
Delete an entry for the host called hostname. This option may only be used by the
super-user.
arp -s <hostname> <ether_address> [temp]
Create an ARP entry for the host called hostname with the Ethernet address
ether_address. The entry will be permanent (static) unless the word temp is given
in the command.
arp -f <filename>
Read the file named filename and set multiple entries in the ARP tables. Entries in
the file should be of the form:
<hostname> <ether_address>
142 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 98 arp command
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
143
© 2002 Siemens AG
11.3.2 The ifconfig command

This command is used to configure the network interfaces. The ifconfig command
sets, or checks, configuration values for network interfaces. Regardless of the vendor
or version of UNIX, the ifconfig command will set the IP address, the subnet mask,
and the broadcast address for each interface. Its most basic function is assigning the
IP address. It is used by the start scripts under /etc/rc2.d. Since this command offers
a wide range of possibilities only some examples will be given here.
ifconfig –a
displays the currently configured network interfaces and their addressing
information
ifconfig hme1 plumb
Open the device associated with the physical interface name (here hme1) and set
up the streams needed for TCP/IP to use the device. Before this is done, the
interface will not show up in the output of ifconfig -a. The device is now added to
the system configuration.
ifconfig hme1 unplumb
Destroy any streams associated with this device and close the device. After this
command is executed, the device name should not show up in the output of
ifconfig -a. The device is now removed from the system configuration.
ifconfig hme1 <IP address> [netmask <mask>] [broadcast <address>] up
starts a network interface and assigns the specified IP address to this interface.
Optionally a netmask and a broadcast address can be set. The up option enables
an interface after an ifconfig down and reinitializes the hardware.
ifconfig hme1 down
shuts down a network interface, marks an interface "down". When an interface is
marked "down", the system does not attempt to transmit messages through that
interface.
ifconfig -a broadcast +
reset each interface's broadcast address after the netmasks have been correctly
set
TIP
The ifconfig command must be used at boot time (startscripts in /etc/init.d) to define
the network address of each interface present on a machine; it may also be used at a
later time to redefine an interface's address or other operating parameters
temporarily.
The permanent setting of an interface should be done in /etc/init.d/rootusr (settings
which were given during Solaris installation)
144 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 99 ifconfig command
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
145
© 2002 Siemens AG
11.3.3 The ping command

It is a very simple but important command to verify whether a network works properly.
It can be used to find out whether a network connection or the machine itself is up or
whether the routing on this machine works properly. Also the entries in the
/etc/inet/hosts can be checked by the ping command.
Ping sends an ICMP ECHO_REQUEST packet to the destination host to elicit an
ICMP ECHO_RESPONSE from the specified host or network gateway.
TIP
When using ping for fault isolation, first ping the local host to verify that the local
network interface and also the local TCP/IP stack is running.
Command execution
/usr/sbin/ping <host> [ timeout ]
With timeout you can specify the maximum allowed response time (default: 20 sec.).
After expiration of timeout the message "no answer from <host>" appears.
/usr/sbin/ping [ -s ] [ -dlLnrRv ] [ -i interface_address ] [ -I interval ] [ -t ttl ]
<host> [ packetsize <number> ] [ count <number>]
In the following tables the most important flags, options and arguments are explained
(for further information take a look to the Solaris manpages):
Flag Description
-s if specified, ping sends one datagram per second (adjustable with -I option) and prints one
line of output for every ECHO_RESPONSE that it receives
Option Description
-v detailed messages are shown (only in the case of ICMP packets other than
“ECHO_RESPONSE”)
-R the route taken by a packet is shown (has to be used in conjunction with –v )
-i interface_address Specify the outgoing interface address to use for multicast packets
-I interval Specify the interval between successive transmissions. The default is one
second
-t ttl specifies the hops a packet can take (time to live), default is 1
Attribute Description
packetsize <number> specifies the packetsize in bytes (default: 64 bytes), can be used for check
<number> of fragmentation of used transmission media
count <number> specifies the number of “ECHO_REQUEST” send out by the ping
<number> command (default: 20)
146 MN2585EU10MN_0002
© 2002 Siemens AG
# ping Host_B
# Host_B is alive
Host_A
ICMP echo reply
ICMP echo request
Host_B
Fig. 100 Ping command
Example:
ping –svR <hostname>
will send one packet per second and will list the entire route a packet took.
Following outputs are possible:
Answer to a ping command Description
<hostname> is alive If everything is all right this message will be printed
on the screen
no answer from If there is no reply within timeout seconds (default:
<hostname> 20 seconds) after the command has been entered
this message appears, which means, that either the
interface or the workstation is down.
unknown host If a hostname is specified ( ping omp5 instead of
ping 139.7.150.50) and the message “unknown
host” appears at least the entry in the /etc/inet/hosts
file is wrong
ICMP Host/Net Unreachable This message means that the routing settings are
from gateway wrong
MN2585EU10MN_0002
147
© 2002 Siemens AG
11.3.4 The spray command

This command creates traffic on the network. As a result the number of dropped and
successful delivered packets is shown.
Command execution
/usr/sbin/spray [ -c count ] [ -d delay ] [ -l length ] <host>
The spray command sends a one-way stream of packets to host and reports how
many were received, as well as the transfer rate.
TIP
Spray is not useful as a networking benchmark as it uses unreliable connectionless
transports, (UDP for example). Spray can report a large number of packets dropped
when the drops were caused by spray sending packets faster than they can be
buffered locally (before the packets get to the network medium).
In the following table the possible options of spray are shown:
Option Description
-c count Specify how many packets to send to the destination host. The default
value of count is the number of packets required to make the total
stream size 100000 bytes.
-d delay Specify how many microseconds to pause between sending consecutive
packets. The default is 0.
-l length The length parameter is the numbers of bytes in the Ethernet frame
(including Ethernet addresses (MAC) but excluding Ethernet checksum).
When length is greater than 1514, then the IP packet sent out by spray
can no longer be encapsulated in one Ethernet packet. default value of
length is 86 bytes (the size of minimum packet size possible with spray
and UDP headers).
host destination host where the packets should be sent to, can be either a
host name or an Internet address
148 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 101 spray command
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MN2585EU10MN_0002
149
© 2002 Siemens AG
11.3.5 The snoop command

This command analyzes the individual packets exchanged between hosts on a
network. Snoop reads all the packets on an Ethernet. It does this by placing the
Ethernet interface into promiscuous mode. Normally, an Ethernet interface only
passes packets up to the higher layer protocols that are destined for the local host. In
promiscuous mode, all packets are accepted and passed to the higher layer. This
allows snoop to view all packets and to select packets for analysis, based on a filter
you define. Filters can be defined to capture packets from, or to, specific hosts,
protocols, and ports, or combinations of all these.
Command execution
snoop [options] [filter expression]
In the following table the main important options of snoop are shown (fur further
details take a look to the Solaris manpages):
Option Description
-D Display number of packets dropped during capture on the summary
line.
-S Display size of the entire Ethernet frame in bytes on the summary line.
-v Verbose mode. Print packet headers in lots of detail. This display
consumes many lines per packet and should be used only on
selected packets.
-V Verbose summary mode. This is halfway between summary mode
and verbose mode in degree of verbosity. Instead of displaying just
the summary line for the highest level protocol in a packet, it displays
a summary line for each protocol layer in the packet.
-t [ r | a | d ] Time-stamp presentation.
d (delta) format (the time since receiving the previous packet). This
is used as default.
a (absolute) gives wall-clock time
r (relative) gives time relative to the first packet displayed
-c maxcount Quit after capturing maxcount packets. Otherwise keep capturing until
there is no disk space left or until interrupted with CTRL-C.
-o filename Save captured packets in filename as they are captured.
-i filename Display packets previously captured in filename. Without this option,
snoop reads packets from the network interface.
-d device Receive packets from the network using the interface specified by
device. Usually le0 or hme0.
150 MN2585EU10MN_0002
© 2002 Siemens AG
The filter expression is used to select packets either from the network or from a
capture file. Only packets for which the expression is true will be selected. If no
expression is provided it is assumed to be true.
In the following table the main important filter expressions of snoop are shown (fur
further details take a look to the Solaris manpages):
Filter expression Description

host hostname True if the source or destination address is that of hostname.
The keyword host may be omitted if the hostname does not
conflict with the name of another expression primitive e.g.
"pinky" selects packets transmitted to or received from the host
pinky whereas "pinky and dinky" selects packets exchanged
between hosts pinky AND dinky.
ipaddr Literal addresses, both IP dotted and Ethernet colon are
recognized. For example, "129.144.40.13" matches all packets
or
with that IP address as source or destination, and similarly,
etheraddr "8:0:20:f:b1:51" matches all packets with the Ethernet address
as source or destination.
from or src A qualifier that modifies the following host, net, ipaddr,
etheraddr or port to match just the source address or port.
to or dst A qualifier that modifies the following host, net, ipaddr,
etheraddr or port to match just the destination address or port.
ip, arp, rarp True if the packet is of the appropriate protocol type.
udp, tcp, icmp True if the IP protocol is of the appropriate type.
and Perform a logical AND operation between two boolean values.
The AND operation is implied by the juxtaposition of two boolean
expressions, for example "dinky pinky" is the same as "dinky
AND pinky".
or Perform a logical OR operation between two boolean values. A
comma may be used instead, for example, "dinky,pinky" is the
same as "dinky OR pinky".
not Perform a logical NOT operation on the following boolean value.
This operator is evaluated before AND or OR
TIP
A filter expression consists of a series of one or more boolean primitives that may
be combined with boolean operators (AND, OR, and NOT).
MN2585EU10MN_0002
151
© 2002 Siemens AG
11.3.6 The netstat command

The netstat command displays the contents of various network-related data
structures in various formats. Depending on the option you select a multitude of
information can be retrieved by the netstat command. Some examples are given
below (for further information refer to the Solaris manpages):
netstat [ -anv ]
displays a list of active sockets for each protocol.
Option Description
-a Show the state of all sockets and all routing table entries.
-n Show network addresses as numbers. The netstat command normally
displays addresses as symbols (hostnames). This option may be used
with any of the display formats.
-v Verbose mode. Show additional information for the sockets and the
routing table.
netstat {[ -i ] [ -I interface ]} [ interval ]

shows the state of the interfaces.
Option / Description
Operand
-i Show the state of the interfaces that are used for TCP/IP traffic.
-I interface Show the state of a particular interface. Interface can be any valid
interface such as hme0 or le0.
interval If interval is specified, netstat displays interface information over the
last interval seconds, repeating forever.
netstat -r [ -anv ]
Option -r shows the routing table of a machine. Other options like described
above.
TIP
The routing table display lists the available routes and the status of each. Each
route consists of a destination host or network, and a gateway to use in forwarding
packets.
152 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 102 netstat command
The flags column shows the status of the route:
Flag Description
U The interface is active (up)
G Whether the route is a gateway (points to a router)
D Route is created dynamically via routing protocol by redirect messages
(RIP, RDISC)
A, B, H If the -a option is specified, there will be routing entries with flags for:
combined routing and address resolution entries (A),
broadcast addresses (B),
and the local addresses for the host (H).
MN2585EU10MN_0002
153
© 2002 Siemens AG
11.3.7 The route command

With the route command it is possible to manually manipulate the network routing
tables. These tables are normally maintained by the system routing daemon (routed)
or through default routes and redirect messages from routers.
The syntax in general is given below:
route [ -fn ] add | delete | [ host | net ] destination [ gateway [ metric ] ]
Operand
-f Flush the routing tables of all gateway entries. If this is used in
conjunction with the command described above, route flushes the
gateways before performing the command.
-n Prevent attempts to print host and network names sym-bolically when
reporting actions. This is useful, for example, when all name servers are
down on your local net, and you need a route before you can contact the
name server.
add Add a route to the routing table
delete Deletes a specific route from the routing table
host/net Routes to a particular host must be distinguished from those to a
network. The optional keywords net and host indicates whether the
destination is a single host or a network.
destination indicates the hostname or IP address of the destination host or network
gateway The gateway argument, if present, indicates the network gateway
(directly connected to the source hosts network) to which packets should
be addressed.
metric The metric argument indicates the number of "hops" to the destination.
The metric is required for add commands; it must be 0 if the destination
is on a directly attached network (direct route), and non-zero if the route
utilizes one or more gateways (indirect route).
TIP
All routes added with the route command are static routes and they are only
temporarily stored (will be lost after next reboot).
To fix any routes to the hosts routing table you have to add them to a stratscript
directly executed after /etc/rc2.d/S69inet, e.g. /etc/rc2.d/S69routes.
154 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 103 route command
Examples:
route add net <network number> <router name or address > 1
defines a static route to a network which is one hop away.
route add net 139.7.0.0 <workstation name> 0
defines a static route from a workstation to the network this workstation is connected
to.
This setting is necessary to reach the network at all.
route add default <router name or address> 1
defines a default route could be set with.
TIP
A default route will be used if a packet's address is not present in the routing table.
MN2585EU10MN_0002
155
© 2002 Siemens AG
11.3.8 The trace route tool (freeware tool)

The Internet is a large and complex aggregation of network hardware, connected
together by gateways. Tracking the route one's packets follow (or finding the
miscreant gateway that's discarding your packets) can be difficult. Trace route utilizes
the IP protocol `time to live' field of outgoing probe packets and attempts to elicit an
ICMP TIME_EXCEEDED response from each gateway along the path to some host .
The only mandatory parameter is the destination host name or IP number. The
default probe datagram length is 40 bytes, but this may be increased by specifying a
packet length (in bytes) after the destination host name.
TIP
The trace route command is not available directly after Solaris installation, because
it's a freeware tool available on the SUN homepages.
The syntax in general is given below:
trace route [-Fnvx] [-f first_ttl] [-i iface] [-m max_ttl] [-p port]
[-s src_addr] [-w waittime] host [packetlength]
Operand
-F Sets the "don't fragment bit" for the outgoing probe packets.
-n Print intermediate router/gateway addresses numerically (IP address)
rather than symbolically (hostname)
-v Verbose output. Received ICMP packets other than TIME_EXCEEDED
and UNREACHABLEs are listed.
-x Toggle checksums. Normally, this prevents trace route from calculating
checksums.
-f first_ttl Set the initial time-to-live value used in the first outgoing probe packet.
-i iface Specify a network interface to obtain the source IP address for outgoing
probe packets. This is normally only useful on a multi-homed host. (See
the -s flag for another way to do this.)
-m max_ttl Set the max time-to-live (max number of hops) used in outgoing probe
packets. The default is 30 hops (the same default used for TCP
connections).
-p port Set the base UDP port number used in probes (default is 33434). Trace
route hopes that nothing is listening on UDP port 33434 at the
destination host (so an ICMP PORT_UNREACHABLE message will be
returned to terminate the route tracing). If something is listening on a
port in the default range, this option can be used to pick an unused port
range.
156 MN2585EU10MN_0002
© 2002 Siemens AG
Fig. 104 trace route command
Operand
-s src_addr Use the following IP address (which usually is given as an IP number,
not a hostname) as the source address in outgoing probe packets. On
multi-homed hosts (those with more than one IP address), this option
can be used to force the source address to be something other than
the IP address of the interface the probe packet is sent on. If the IP
address is not one of this machine's interface addresses, an error is
returned and nothing is sent. (See the -i flag for another way to do
this.)
-w waittime Set the time (in seconds) to wait for a response to a probe (default 5
sec.)
host indicates the IP address of the destination host
packetlength specifies the packet length of the probe packets (default: 40 bytes)
MN2585EU10MN_0002
157
© 2002 Siemens AG
158 MN2585EU10MN_0002
© 2002 Siemens AG
12 Exercises
MN2585EU10MN_0002
159
© 2002 Siemens AG
160 MN2585EU10MN_0002
© 2002 Siemens AG
Exercise 1
Title: Network interface configuration
Objectives: The participant is able to configure a network interface
Pre-requisite: TCP/IP theory and Unix commands
Task
Interrogate the state and configuration data of the network interfaces of your
workstation.
Redirect the output in a file.
Remove hme0 from the system.
Add hme0 again to the system.
Interrogate again the state and configuration data of the network interfaces of your
workstation. Check above all the IP address, broadcast address and netmask !
Set the IP address, netmask and broadcast address of hme0. Hint: use the
command ifconfig with the options “broadcast” and “netmask”, if necessary refer to
the online manual of the command.
Try to ping any other host in the network. If the ping was successful, the interface
works if not, try to find out what is wrong by responding to the ping command.
MN2585EU10MN_0002
161
© 2002 Siemens AG
162 MN2585EU10MN_0002
© 2002 Siemens AG
Exercise 2
Title: Mac addresses and arp cache handling
Objectives: The participant is able to handle the arp cache
Pre-requisite: TCP / IP theory and Unix commands
Task
Check the arp cache of your machine. Ping any machine which is not in the arp
cache and check again the arp cache. What has changed ?
Check the arp cache of the omp. What is the difference to the arp cache of an OMT ?
MN2585EU10MN_0002
163
© 2002 Siemens AG
164 MN2585EU10MN_0002
© 2002 Siemens AG
Exercise 3
Title: Administration of static routes
Objectives: The participant is able to configure static routes
Pre-requisite: TCP / IP theory and Unix commands
Task
The following configuration is present:
LAN 139.7.0.0
Router:
139.7.150.99, eth0
139.8.150.99, eth1
LAN 139.8.0.0
Fig. 105 configuration example
MN2585EU10MN_0002
165
© 2002 Siemens AG
Add the new OMT to the RC configuration (using NetEditor).

Add a route to the router, which interconnects the network 139.8.0.0 and 139.7.0.0.
Check the route with the netstat command.
Test the connection. Is it possible to access the resources of the new OMT from
another OMT ?
If you would like to set the route to the router 139.7.150.99 as default, you have to
make an appropriate entry in /etc/defaultrouter.
166 MN2585EU10MN_0002
© 2002 Siemens AG

Mn2585eu10mn 0002 TCP Ip

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mn2585eu10mn 0002 TCP Ip

Uploaded by

Copyright:

Available Formats

TCP/IP addressing and routing Siemens

TCP/IP addressing and routing

8.1 Introduction to the transport layer protocols 82

1 The TCP/IP protocol suite

Fig. 1 the Internet

1.1 Why does TCP/IP exist?

1.2 What is TCP/IP?

1.3 The structure of the TCP/IP suite

The OSI Model The TCP/IP Model

Fig. 2 Comparison of the OSI and TCP/IP model

The TCP/IP Model

Application SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP

Fig. 3 TCP/IP protocol suite

2 Overview of the TCP/IP protocol layers

SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP

ARP RARP IP ICMP

IEEE IEEE IEEE IEEE Frame

Fig. 4 Network access layer protocols

SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP

ARP RARP IP ICMP

IEEE IEEE IEEE IEEE Frame

Fig. 5 Internet layer protocols

TCP is a connection-oriented protocol that provides reliability, flow control, and

SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP

ARP RARP IP ICMP

IEEE IEEE IEEE IEEE Frame

Fig. 6 Transport layer protocols

SMTP Rlogin FTP TELNET SNMP TFTP DHCP NFSP

ARP RARP IP ICMP

IEEE IEEE IEEE IEEE Frame

Fig. 7 Application layer protocols

TCP/IP Layers TCP/IP Layers

Network Access Network Access

Fig. 8 TCP/IP conversation

4.1 Addressing on the network layer

MAC addresses and networks addresses

Network address MAC address

MAC MAC MAC MAC

Fig. 10 MAC addresses in a network

Solution: Network addresses. They have a logical structure

Network address Network address

Fig. 11 Network addresses

4.1.1 IP address properties

... which makes life easier for routers

4.1.2 Decimal and binary notation of IP addresses

Fig. 12 Network and host part of an IP address

Byte Byte Byte Byte

Fig. 13 IP address structure

4.2 Address classes

Class A (/8 prefixes) – 1 byte for the network part

Class B (/16 prefixes) – 2 bytes for the network part

Class C (/24 prefixes) – 3 bytes for the network part

Class A 0 Net ID (7 Bits) Host ID (24 Bits)

Class B 1 0 Net ID (14 Bits) Host ID (16 Bits)

Class C 1 1 0 Net ID (21 Bits) Host ID (8 Bits)

Class D 1 1 1 0 Reserved for Multicast Addressing (28 Bits)

Class E 1 1 1 1 Reserved for Future Use (28 Bits)

Fig. 14 Network Classes

Network First Decimal Net Number of Host Number of Comments

4.2.1 Reserved IP addresses

Host number (Host-ID) Special meaning

Network number Special meaning

Fig. 15 Reserved addresses, Directed and Local Broadcast