Categories: Linux, OpenWRT, Infrastructure, Network

Introduction

Below is a description of how a home or small-business computer network functions, and in particular it describes the role/functionality of a “router” and (hopefully) explains what the different terminology used by the router administration/configuration application means.

This article:

• assumes fundamental knowledge of computers, but no previous knowledge of computer network configuration
• provides something that can be read in 20 minutes (though fully understanding it might take longer!)
• provides only information relevant to setting up a computer network in a residential house or small office - and in particular, installing/configuring OpenWRT software on a router.

Of course, the topic of computer networks is complex: there are entire university-level courses on it, textbooks hundreds of pages thick, and official accreditation exams that last hours. This article focuses on the subset required to configure a network within a private house/apartment or small office, and goes into only as much depth as can be covered in a few pages. The information is not presented “for dummies” though - it is for readers who truly want to understand networking principles, and are willing to work for it!

As the intent is to discuss home/small-office networks, only the Ethernet networking protocol and devices commonly used with that protocol are discussed. The vast majority of data networks (outside of large commercial and ISP environments) use Ethernet.

This article also assumes that IPv4 (version 4 of the IP standard) is being used on the local network; this article might be updated later with relevant information for IPv6.

There are many sites/pages on the internet that have information about computer networking; in particular there is some excellent information on Wikipedia. However much of this focuses on individual pieces of the overall system without showing how the bits fit together (the “big picture”). Links to relevant pages are included throughout this article for those with previous networking knowledge or as follow-up reading. The best overall guide, ie alternative to this article, which I am aware of is the CTDP Networking Guide - well-written, very detailed, but slightly out-of-date. The wikipedia article on computer networks covers the same topics, but rather tersely.

The following description is far from perfect; the topic is large and complicated, and describing how it all fits together in a readable manner is hard. I apologise for the occasional references to terms not yet defined, and the (current) lack of diagrams. Nevertheless, as far as I am aware this is the only online resource that covers the whole range of relevant technologies. At the least, this should provide a good basis for further reading/research.

The OSI Model of Network Layers and Other Terminology

Different kinds of computer networks have been invented by different people at different times, and the inventors often used different terminology. Fortunately there is a document called the OSI network model which is widely used as standard terminology for networking. It is very useful to know at least the most common definitions in the OSI model as you will find these words used everywhere in network-related documentation. Sorry to start this article with some dry and abstract terminology, but it really is helpful and only the minimum is defined here…

The OSI model describes networks as having seven layers, from the most primitive to the most complex; each layer extends the capabilities of the previous layer. For this article, only the first four layers are relevant:

• Layer 1 = Physical layer (PHY): responsible for representing a single bit as an electrical (or radio, or light) signal.
• Layer 2 = Data Link Layer (DLL): responsible for transferring a small block of bytes between two computers which are nearby (on the same local network, ie not separated by a router).
• Layer 3 = Network Layer: given a network of many computers, responsible for transferring a small block of bytes between two computers which are (or can be) on different networks (and therefore potentially far apart) - ie add the concept of routing between networks.
• Layer 4 = Transport Layer: given a network of many computers
  1. support the concept of a destination application (port) not just a destination computer;
  2. ensure data is transferred to its destination reliably (ie handle packet loss); and
  3. support the concept of “a sequence of data blocks that belong together” (ie a stream of data).

We will be talking about Ethernet, IP and TCP in this article, and unfortunately they have their own terminology which does not map exactly 1:1 onto the OSI model. However the basic correspondence is:

• Ethernet (Ethernet data frames + MAC addresses): layer 1 + layer 2
• IP (Internet Protocol): layer 3
• UDP (User Datagram Protocol): layer 4 (part 1 only)
• TCP (Transmission Control Protocol): layer 4 (all parts)

Other useful terminology:

• “link” means the electrical wiring connecting one computer to another
• “station” means some device that sends or receives data across a network link. This applies to both “wired” and “wireless” networks.
• “frame” and “packet” mean almost the same thing; they refer to a smallish sequence of bytes (typically up to 1500 ¹) which are transmitted together. However the word “frame” is used when talking about the lowest-level parts of networking while “packet” is a more abstract term used when talking about higher-level networking concepts. And in practice, a “packet” of data can potentially be split up and transferred using two or more “frames” when necessary.

And most important is to discuss the meaning of the word “network” itself. This is unfortunately used in at least three ways:

• to describe something that connects a small set of computers directly without a router (aka a “broadcast domain”)
• to describe something that connects a set of computers in the same building by using routers but without needing an Internet Service Provider (aka ISP) to be involved; or
• to describe anything that connects two computers regardless of how far apart they are (usually via an Internet Service Provider).

In this article, I will try to refer consistently to the first above as “an L2 (layer2) network” or “ethernet network”, the second as “an IP network” or “LAN” (local area network) and the third as “the internet” or “WAN” (wide area network).

References:

• Wikipedia: the OSI Model

Ethernet, IP and TCP Overview

The Ethernet specification (IEEE standard 802.3) defines how to transfer bits (zeros and ones) across a physical connection, eg. as electrical signals in a pair of wires (layer 1/PHY). It also defines data frame formats (layer 2), ie how to interpret the bits at the start of a block of bits (headers), such that the rest of the block (the actual user data, aka payload) can be sent unambiguously from one station (device) to another.

Each station attached to an Ethernet network must identify itself using a unique number known as a MAC address (aka Ethernet Address or Link Layer Address) which is 48 bits long; each Ethernet packet contains the sender’s MAC address and the recipient’s MAC address. Ethernet packets of data are quite small - usually less than 1500 bytes.

The relative simplicity of the Ethernet specification means that it is cheap to build the required circuits; this simplicity also makes it a good initial building block for more sophisticated communication. However pure Ethernet has the following limitations:

• MAC addresses have to be unique on a single L2 network, but otherwise have no meaning (structure) at all. The lack of structure means that stations and switches need to keep tables of all MAC addresses on their L2 network - and this limits Ethernet to a small number of computers on each L2 network.
• Standard copper ethernet cables have a maximum length of 100 meters.
• The Ethernet packet structure is extremely simple - so provides no way to link different payloads together into a “stream of data”, to handle failures/retries etc.

To allow communication between large numbers of computers over large distances, each L2 network has at least one “router” device attached to it. This device copies data to/from one or more adjacent L2 networks - forming a larger L3 network. A block (packet) of data is forwarded from L2 network to L2 network until the data eventually ends up on the L2 network to which the recipient is attached (hence the name “internet”). The different L2 networks are not limited to also using the Ethernet protocol. However this process can not work with MAC addresses; that would require each router to have a table with an entry for every computer in the world which is obviously not possible.

The Internet Protocol (IP) defines a more sophisticated way of specifying the destination of a packet of data than an Ethernet MAC address. A MAC address is simply a unique number, while an IP address is structured as “{id}{subid}{subsubid}…{hostid}” where {id} specifies one of the world-wide “top-level” L3 networks, {subid} specifies a subsection of that L3 network, and so on until eventually a specific computer is identified. Determining how to contact these networks is not trivial - doing it efficiently requires some complex algorithms. However it is possible without needing a table holding the addresses of all computers in the internet. There is more information about IP addresses and their structure later in this article.

The User Datagram Protocol (UDP) defines a simple data-format that consists of an IP address, a “port number”, a block of user data, and a checksum. The IP address allows such packets of data to be handled by routers and forwarded through the internet (unlike a block of data with just a MAC address in it). The port-number can be used by the receiver to select a particular application to pass the data to (assuming a program has previously been started on the destination device which requested that data labelled with that ‘port number’ be passed to it). And the checksum can be used to ensure that the data has not been corrupted underway (though it provides no help in dealing with such a problem if it occurs!).

The Transmission Control Protocol (TCP) adds more headers to UDP which define the “sequence number” of each packet, and other useful things². These extra values allow a large block of data to be broken into a sequence of small packets of data by the sender, for those to be transferred individually across the network to the receiver, and for the receiver to then merge them together again at the other end. If packets of data get lost in transmission, then the receiver can detect this and ask for them to be retransmitted, etc. This is the kind of data transmission that we experience when connecting a web-browser to a remote webserver: bidirectional data transfer, where the two ends don’t need to know that the data has been transferred as many small pieces across potentially dozens of different L2 networks (and different packets might take different paths!).

However UDP and TCP data packets and their IP addresses cannot be understood by devices that are designed to handle Ethernet data (network cards and switches). When a station wishes to send a UDP or TCP packet, it builds an Ethernet frame and puts the UDP or TCP packet into the “payload” part, rather like putting a letter into an envelope. The ethernet frame is then given a suitable destination MAC address and sent out into the local ethernet (L2) network. Which MAC address is used, do you ask? Well, if the recipient is on the local L2 network then the MAC address will be the address of the computer that matches the IP address in the nested data - ie when the recipient specified by the MAC address unpacks the UDP packet from its ethernet frame it will find the nested packet has its own IP address on it. However if the recipient is not on the local L2 network, then the MAC address used will be the address of a router device on the local L2 network; that device will unpack the nested packet, and then forward it on to an adjacent L2 network. This process is described in more detail later.

While in theory devices that only need to communicate with other very nearby devices (ie don’t need to send data to devices on other networks) could choose to use Ethernet directly for communication, it is extremely rare. Applications running on devices like computers, tablets, mobile phones or smart televisions almost always send/receive data using the TCP or UDP protocol, so that the owner is free to attach the sender and receiver to the same network or not. The operating system then passes this on via Ethernet, but that is not relevant to the application.

The term network has been used above without really defining it. A station connected to a network can send messages to a specific other station, or can send a broadcast message to all stations; a “broadcast domain” is the set of stations that a broadcast will reach. Obviously, broadcasting to every computer in the world is a bad idea - and even broadcasting to every computer within a small company is probably bad; a broadcast domain is usually just a handful of stations. And in general, “L2 network” and “broadcast domain” are the same thing - a small set of stations that can see each other’s broadcast messages. An “intranet” or “internet” is a set of L2 networks joined together via shared routers so stations on separate L2 networks can communicate - but never via broadcast messages! For Ethernet, an L2 network can also be defined as the set of stations that can communicate with each other by using just MAC addresses; routers only pass data in IP format (ie with associated IP addresses) to adjacent networks.

Note that Ethernet and Internet Protocol are quite independent things. IP data can pass through “intermediate networks” which are not Ethernet - and frequently does (though not within home/small-office environments). And Ethernet “local networks” can be used to carry higher-level protocols that are not IP - though again those are not likely to be found (any more) in home/small-office setups.

See:

• Wikipedia: The Ethernet Protocol (IEEE standard 802.3)
• Wikipedia: Ethernet Frames
• Wikipedia: The Internet Protocol aka IP
• Wikipedia: User Datagram Protocol aka UDP
• Wikipedia: Transmission Control Protocol aka TCP
• Wikipedia: Internet Protocol Suite

Historical Notes on Ethernet

The original ethernet specification assumed a “shared bus” configuration, ie a single shared cable connected to multiple stations; this configuration requires “collision detection” (CSMA/CD) and thus limited data to “half duplex” operation and speeds of only up to 10MB/s. An L2 network containing “hubs” still works on this principle. However since the year 2000, almost all L2 networks use switches instead of hubs, a star-form L2 network configuration (multiple stations connect to a central switch), and work at 100Mbps or 1000Mbps. In a star-form network with a switch in the center, CSMA/CD is competely unnecessary (and you can ignore any references to it that you might see in other documents)³.

The Ethernet standard defines how to transfer data across various types of cables (coax, twisted pair, 4 twisted pairs, fibre-optic). Home networks these days always use CAT5⁴ or CAT5e cables (4 twisted pairs) - this is the only kind of cable sold at normal computer stores, so you can’t really go wrong. However if you inherit a dusty box of old computer parts, there may be older cat3 cables there in which case your network will run with max 10mb/s!

And “crossover cables” are also obsolete. Modern ethernet connections automatically detect and configure themselves appropriately - and the fastest ethernet protocols don’t have separate send/receive wires at all.

Hubs, Switches, Routers

Data flows across network cables which are connected at each end to a physical port (socket).

A “hub” is a very simple box that has several physical ports (sockets) and basically connects together the network cables that are plugged into it as if they were soldered together. It may also boost/clean-up the electrical signals that pass through it but does nothing else. In particular, data arriving via one port (ie from one cable) is forwarded to all other ports (cables). You’ll probably never see or need one of these; using a hub makes a network much slower than using a switch (see below), and is no longer any cheaper.

A “switch” (more specifically, a level-2 ethernet switch) is more sophisticated than a hub; it inspects the destination MAC address of data packets arriving on one port, and forwards the data only onto the port (cable) on which the destination station is attached. This obviously increases the average throughput of the network significantly. However to do this selective-forwarding, the switch needs to be able to “listen” for stations announcing their presence (and address), remember which port they are attached to, and then inspect each packet as it arrives and match this with its internal table of known stations (addresses). This requires moderate processing power and some memory (storage), but not a full general-purpose CPU. Processing is done only based on “ethernet frame headers”, ie MAC addresses; a switch does not understand or handle the IP or TCP/IP protocols, and therefore is limited to handling stations on the same local (L2) network (within a few hundred meters of each other). Normally, a small network consists of a single central switch to which each other device is directly connected (star layout). A larger network can be made by connecting multiple switches in series (A<->B<->C)⁵ and then connecting other devices directly to any of these switches. See: Wikipedia: Network Switch.

A “router” is a device that works with IP addresses; it is always connected to at least two L2 networks concurrently, and forwards data packets from one L2 network to another, rewriting the Ethernet (L2) addresses in the process. When a station wishes to send data to a recipient identified by an IP address, it first checks whether this address is within the range of addresses for its “local network”. If so, it can simply send an Ethernet frame with the MAC address of the recipient. However when the IP address is not local (ie is not in the range of addresses used by the local network) then the sender must instead send the data using a MAC address belonging to a router attached to the local network. The router extracts the IP packet, builds a new Ethernet frame with a new destination MAC address and transmits that onto some other network (ie where the sender cannot get to directly with simple ethernet frames). Correctly choosing the next MAC address to forward data to, and rewriting the packets, requires more CPU processing power and more memory than a switch requires; routers therefore typically have a fully-programmable CPU and significant memory. As routers must inspect and rewrite packets to correctly forward them, this is also a good place to implement network security (“firewalls”), NAT (network address translation), and similar tasks. There is more information on this process later…

Note that a switch is “invisible” to stations on the same network. Stations never talk to the switch directly⁶; the switch simply “snoops” on data going past, and forwards the packets onto the appropriate cable(s) with little or no change. A level-2 ethernet switch can be replaced with a hub (actually, one hub per VLAN configured on the switch; see later) with no effect other than reducing the available bandwidth on the network. A router is much more active; sending devices are aware of its existence and actively use it as a “forwarding agent” when the desired destination IP address is not local. In particular, a router is responsible for forwarding data from an in-home network onto the link leading to your ISP and thus out into the internet.

The boxes named “routers” which are sold for home/small-office use are typically a combination of switch and router, having both a decent CPU (for running routing logic) and a separate switch component within the same box; the switch provides two or more separate local networks (eg one leading to your ISP, and one for local devices) and the router transfers data between the networks depending on the specified IP address. Having a full CPU available in the router part also allows many other useful things to be done - particularly if you install the OpenWRT linux-based operating system on it!

A router is not necessarily a custom-made device; anything that has a decent CPU, some memory, and the ability to send data packets to two different networks can be a router. It is entirely possible to use a normal desktop PC or even a laptop as a router. However given that prices for dedicated router hardware are now so cheap, this article assumes a dedicated commercially-manufactured router. Interestingly, as technology has improved, dedicated routers are approaching low-end PCs in their capabilities (with the exception of graphics output, naturally!) - which makes things like the OpenWRT linux distribution for dedicated routers possible.

References:

• practicallynetworked: all about routers: 2005
• practicallynetworked: Bridge Types

Modems

To access the internet from your house, data needs to somehow flow out of the house and many kilometers away until it reaches equipment belonging to your Internet Service Provider (ISP). The data does not flow over cat5 copper cables using Ethernet, as it does within a house/apartment/office. The ISP therefore provides a modem device which connects on one side to whatever technology the ISP uses (cable-tv, ADSL, maybe wireless) and on the other side has an Ethernet connection.

Sometimes this modem is quite simple and just provides a single Ethernet input, in which case you can connect one single computer to it - or can connect a router to it, and then connect as many devices as you want to the router. Sometimes the ISP will provide a box which is a combination modem/switch/router (ie with multiple Ethernet inputs) - and sometimes even a modem/switch/router with wireless capability.

While having switch/router functionality built in to the modem device provided by your ISP is convenient, it also has disadvantages. This device is controlled by the ISP, and can be sent configuration commands by the ISP at any time. Having all your networked devices connected directly to this is an unnecessary security risk; it is much better to always have your own router (ideally with OpenWRT installed) which is connected to the ISP’s device even when that device itself is able to act as a switch/router. In this configuration, data “internal” to your network (between your own devices) does not go through a device owned and configured by an external party. The rules about how to handle data coming from the outside world into your network are also then controlled by yourself.

Mapping IP addresses to MAC addresses (ARP)

When a station wishes to send a packet to a specific IP address, it must first determine which MAC address to send the data to.

When a device first gets allocated its own IP address, it is also given a “subnet mask” which is effectively the range of addresses used by devices on its local (L2) network. This process is described later in “Allocating MAC and IP Addresses”. If the destination IP address is not within this range, then the sender instead chooses the address of a router from its “table of routers”, and sends the data to the MAC address of that router. This process is also described later.

However when the destination IP address is a local address (matches the subnet mask), then the Address Resolution Protocol (ARP) is used to find the MAC address for a specific IP address. Each device maintains a small table of (IP-address -> MAC address) for entries on its local network (the “ARP Cache”). If the IP address is already in the cache, then the problem is already solved. If not then the sender creates an ARP (Address Resolution Protocol) request structure containing the destination IP address and broadcasts it to all stations on the local network. The recipient (ie device which has that IP address) will send a response with its MAC address. This is cached for later reuse, and the original data is now sent labelled with the appropriate destination MAC address.

See:

• Wikipedia: Address Resolution Protocol
• Wikipedia: Gateways

Allocating MAC and IP Addresses (DHCP)

Each station in a local (L2) network must have a different MAC address, or bad things will happen. Originally, every manufacturer of an Ethernet-enabled device (eg a network card that plugs into a computer) would apply to an international group for their own MAC-address prefix. Each device they manufactured then had a unique MAC address which starts with the manufacturer’s prefix. This simple scheme ensured that every ethernet-capable device ever created would have a world-wide-unique MAC address. The world-wide uniqueness was never actually itself useful, but it certainly guaranteed that no two stations on the same network had the same id.

This approach is still generally followed, although there are now very many manufacturers, and some of those don’t allocate IDs correctly. Many modern devices also have the ability to configure their MAC address rather than being hard-wired to the address that was built in at the factory - and it is therefore possible for the owner/administrator of a network to allocate MAC addresses manually.

As noted, only stations on the same local network need unique addresses. Manufacturers should only allocate even addresses to their devices; all “odd” addresses (with the least-significant bit set to one) are reserved for use as “local ids”; an administrator can allocate such IDs to devices and know that they will never conflict with the manufacturer-allocated ID of any other station that might be connected to the network.

IP addresses are quite different; they have a hierarchical structure that indicates who is responsible for the station (rather than who manufactured it), similar to the way that the address on a postcard does: country/city/postal-code/street/house/apartment/recipient’s name. For an IP address, the first few bits describe which of a few “world-wide” organisations is responsible for this address; the next few bits tell that organisation which sub-organisation is responsible, and so on until the address eventually specifies a single responsible network-router, and that then uses a MAC address to send the data to a particular computer. Of course, in many cases the sender and recipient are within some common suborganisation so data does not have to be passed up to the global level; in particular if the sender and receiver are within the same house then the data never needs to leave the house. Nevertheless, the IP addresses are theoretically global - except as described below.

Because the IP address of a device depends on where it is (which router it is connected to), a fixed address cannot be allocated by the manufacturer. The usual way of allocating a suitable address is for one device on each network (known as a DHCP server) to be manually configured with a range of “available network addresses”. When any other device turns on (or is connected to the network), it broadcasts a request on its local network, effectively asking “somebody please tell me what address to use” (DHCPDISCOVER); the DHCP server then replies to the broadcast with a suitable address. Usually the DHCP server keeps a table of (MAC address, IP address) somewhere so that when a station which it has previously known about asks for an address it can be allocated the same address again (assuming it is not already in use); having such “stable” addresses is nice although not mandatory in most cases. Where a particular station should really have the same address each time it is turned on, an administrator can manually configure the DHCP server with the appropriate (MAC, IP) address pair to ensure that IP address is never given to any other station. An alternative is for a device to be manually configured with a fixed IP address, ie not to ask a DHCP server for an address at all - but in that case, it is the administrator’s responsibility to ensure that no other station has that address (and the address must be manually updated if the station is moved to a different router). In practice, a router usually also acts as a DHCP server for one or more of the L2 networks that it is connected to.

The DHCP server’s reply message which indicates which IP address should be used also includes the “subnet mask”, ie specifies the range of IP addresses which are “local” to that L2 network. This then allows a device to determine which addresses should be mapped to local MAC addresses via the ARP protocol and which addresses require the data to be sent via a router instead. The response also commonly specifies a list of (subnet, router-address) pairs - in a home environment, the list will contain exactly one router which is responsible for all addresses. And as noted, in a home environment the DHCP server and the router are usually the same device.

References:

• Wikipedia: DHCP

IP Addresses

An IPv4 address is a 32-bit number. Each station obtains a unique IP address either by having it manually (and permanently) configured by the administrator, or by broadcasting a DHCP request on startup and waiting for some DHCP server on the local network to specify the address the station should use.

Every router (whether a small local device or an industrial-strength device in some ISP’s datacentre) knows the range of IP addresses that it administers. The range is simply a fixed prefix: any address which starts with that prefix is handled by the router. The range a router manages is usually manually configured at the router by a network administrator. Each router then communicates with the other routers around it to tell them which range it manages, and find out which ranges they manage. The router builds a table of (range->router) called a routing table so that when it receives a message it knows which other router to pass the message on to. Eventually, the message should reach a router which is attached to the L2 network on which the actual destination station resides and the data can finally be delivered.

There are a number of ways that ip-addresses and ranges can be written (eg input into programs or printed in documentation).

An address is a 32-bit binary number, eg “010101011111111100000000000000000” but that isn’t very readable. Dividing it up into groups of 8 (bytes) is a slight improvement: “01010101.11111111.00000000.00000000”. A common convention is to write each byte in decimal format; the previous address in this “dotted decimal” format is “85.255.0.0”.

A “prefix” (ie range) can be expressed as the base address plus an integer specifying how many of the bits in the base address are “fixed” (ie the length of the prefix). As example, a range “01010101.11111111.00000000.*” can be written as “85.255.0.0/24”. Any incoming address whose first 24 bits match the base address is within the range. Decimal is perhaps not the ideal representation for ranges; a prefix “0101” would be written as “80.0.0.0/4”, and indicates a range of addresses between “01010000.00000000.00000000.00000000” and “01011111.11111111.11111111.11111111” ie between 80.0.0.0 and 95.255.255.255. The “80-95” is not initially obvious when the range is written as a decimal format, though clear when the number is written in binary. Similarly, “10000000.00000000.011*” can be written as “128.0.48.0/19” and matches any address from 128.0.48.0 through 128.0.127.255.

The smaller the “fixed” number of bits is, the more numbers are in the range; a “/8” range contains 2^24 addresses while a “/24” range contains only “2^8” (256) addresses and a “/30” range would contain just 4 addresses. Ranges can be of any desired size (though in early internet days they were limited to multiples of 8).

An alternative to the “base/prefixlen” convention for describing ranges is the “base+subnetmask” convention, where the number of fixed bits in the prefix is simply represented as a series of 1-bits. For example, rather than write “127.0.0.0/24” (first 24 bits are fixed), this can be written as “011111111.00000000.00000000.00000000” with subnet mask “11111111.11111111.11111111.00000000” or equivalently “127.0.0.0” with mask “255.255.255.0”. Syntax “/N” is simply equivalent to a subnet-mask with the first N bits being set to 1.

The IP-protocol specification defines a number of special address-ranges:

• 192.168.* (ie 192.168.0.0/16) is a “private” range. Each router must decide whether to pass on data-packets with such addresses or not. Routers at ISPs will never be configured to pass on packets with such addresses. At large companies, inter-department routers are typically also configured to block/ignore packets with the 192.168.* addresses. The result is that any department (or home-network) may allocate addresses in the 192.168.* range as it wishes for internal use, while other departments/home-networks may use the same addresses for different purposes. Because the data never “escapes” the local environment, the addresses only need to be unique within that local environment. Of course that means that computers outside that environment cannot exchange data with a computer using such an address. Some administration care is also needed to ensure that two computers within the same department/home-network never use the same address.

• 10.* (ie 10.0.0.0/8) works similarly; it is also a “private” range but a larger one. As for the 192.168.* range, ISPs will just drop (ignore) such packets. However in large companies, packets in the “10.*” range may be permitted to pass between departments while packets with 192.168.* addresses are blocked. This allows a company to allocate addresses to servers which can be accessed by any station within the company network. Of course this requires some careful administration to ensure that no two computers within the whole company ever use the same address.

• 169.254.* (ie 169.254.0.0/16) is the “auto-allocation” (APIPA) address range. If a computer starts up and requests an address via DHCP (see later) but gets no response, then it can optionally use an address from this range. There is an official (and complicated) sequence of steps the computer should perform to try to find out if some other station is using that address first. Having a DHCP server allocate addresses is better, but this approach does allow a station to start using the local network even if a DHCP server is not available. This is particularly useful in “ad-hoc networking” where a bunch of laptops or similar build a local network amongst themselves (advanced topic!).

• 127.* (ie 127.0.0.0/8) is the “local address range”. An operating-system’s network software does not permit any packets with such addresses to leave the sending computer. The primary use for such addresses is for a network-enabled client application to talk to a network-enabled server application running on the same computer even when no other networking is available. Usually each network interface in the computer gets assigned an address on system boot, starting from 127.0.0.1 and counting upwards. The address “127.0.0.1” usually can be referred to via the alias “localhost”.

See the section on NAT below for information on how to allow computers with “private” addresses to access the internet.

DHCP

The Dynamic Host Configuration Protocol is a way for a network station (eg a PC) to obtain a valid IP address when it enables networking.

In summary, the station sends out a layer-2 broadcast message containing its own MAC address, and a request for an IP address (DHCPDISCOVER). Some station attached to the same local (L2) network which is running a DHCP server program will then send back a response message to that sender MAC address containing a suitable IP address to use. It is common (though not compulsory) for the DHCP server program to be running on a router.

The address sent back will be within the address-range managed by a router attached to that L2 network.

Actually, the response also includes additional information:

• the range of IP addresses (ie address prefix, aka subnet-mask) used on the local (L2) network. As noted, the address allocated to the requester should be within this range. This range indicates to the station when it can send direct to some destination (ie when to use an ARP request), and when it needs to relay the data via some router.
• the MAC address of a “default router” to use when a computer wants to send data to an address not within the local network
• the IP address of a DNS server (or multiple servers) which can be used to map computer-names to ip-addresses (see below)

In the case of a home-network, the router that connects the internal home network to an ISP will use DHCP (as a client) to obtain a (single) external (public) address from the ISP’s available range when the router is booted. When the router also runs a DHCP server (usually the case), it then hands out addresses in the range 192.168.* or 10.* to devices within the network, and performs Network Address Translation (NAT) to allow such devices to access the “outside world” using the IP address the router obtained from the ISP; see the section on NAT below.

Domain Name System (DNS)

Dealing with IP-addresses is not convenient for humans; we want to type “myfavsite.example” not some dotted-decimal address. The Domain Name System (aka DNS) protocol defines a standard way of asking some arbitrary DNS server to map a name to an IP address. This is quite decoupled from the core of networking, ie is a layer on top whose only role is to map a name to an address. Once that is done, the networking layer uses only the numerical address for its work.

Computers typically cache recent (name->address) lookups for performance.

As noted in the section on DHCP, a router that connects a home/office network to an ISP normally uses DHCP (as a client) to get an external(public) address from the ISP when it is turned on. The ISP also usually sends back the address of a DNS server (or two), which the router then passes on to any local devices that use the router’s DHCP server to allocate their address. ISPs typically provide DNS servers for use by their customers; name lookups are very common ie generate lots of network traffic. However some ISPs have been known to use such queries to track which sites their customers are visiting, and even occasionally to manipulate the results - in particular, on lookup failures (site not found) to return a wrong address (eg the address of an advertising site) rather than returning a failure-code. It is entirely valid for a desktop user to manually override the address of the DNS server to use - some freely available and trustworthy servers are available on the internet.

Although the primary purpose of DNS is to provide a world-wide “database” of (hostname->ip-address) pairs, the fact that it is a world-wide database makes it useful for some other purposes too. DNS actually supports multiple “record types”; requests sent to a DNS server specify a (key, record-type) pair and the response is a list of matching records. A record of type “A” for a specific key holds the IPv4 address of the host with the specified name; record-type “AAAA” holds the IPv6 addresses of the specified host. Records of type “TXT” can be stored in DNS to associate arbitrary strings with a specific name (limited to about 1Kb in length); the owner of a domain-name can publish TXT records for a domain-name they own to define config-settings used by various security-protocols such as SPF, DKIM and MARC. A few other record-types are also used.

Network Ports

Both MAC and IP Addresses identify a computer - but not an application on that computer. However normally one computer wants to send data to a particular kind of application on the destination computer. And if that application sends a response, then that response data should be sent to a particular application on the original sending computer. The UDP and TCP protocols therefore created the concept of a “port”: just a 16-bit number that indicates an application on a computer.

UDP is a “one-way” protocol; data flows from a sender to a receiver and that’s it. The header of a UDP packet therefore includes a destination port only.

TCP is a “two-way” protocol. Each packet includes a destination port and an origin port. The origin port is normally auto-allocated by the sender (any value currently unused on the sending device), and added automatically to the packet header. The receiver can then send data back by placing the origin-port into the destination-port field; the sending computer’s operating system then knows which sending application to forward the received data to. As port-numbers are only 16 bits (0..65535), that does mean that a single station can only have 65535 open connections to the same destination (address, port); in practice that is seldom a problem.

A router does not normally need to look at the port# within a data packet to transfer it to the correct network, ie a port-number is mostly relevant after data has arrived at its destination station. However in the following cases the router does care about the port number:

• when handling response data for a NAT-translated request
• when receiving incoming connection requests that should be forwarded to an internal computer (eg for gaming sessions, or an internal webserver) which does not have a public address (ie which has an address in the 192.168.* or 10.* range).
• when implementing firewall rules

Note that the word “port” has two unrelated meanings: it can be a physical plug on a switch/router device, or it can be an “application identifier number” within a data packet (as discussed here).

Network Address Translation (NAT)

Normally, an ISP will only allocate one internet (IP) address to a home or office. Multiple computers may therefore need to “share” this address. This is done by having the router which acts as the “gateway” from the home network to the outside world rewrite the packets that it sends and receives. This is called Network Address Translation aka NAT.

A device on the home network wants to sends a packet to IP address “w.x.y.z”; it notices that this is not part of the range of addresses for its local (L2) network, so sends it to the router’s MAC address. The router notices that this address is for the “outside world”, and that NAT is enabled. It therefore replaces the “sender IP address” in the packet with its own IP address instead, and replaces the “origin port number” with a currently-unused port-number. The packet is then forwarded to the ISP. When the recipient gets around to sending a reply, it will send its response to the replaced address/port pair - ie the data will eventually be forwarded to the router itself. The router will then notice that the IP address is for itself (rather than a computer in one of the networks it manages), and that the port-number corresponds to a value it used during a recent NAT-rewrite. The router then modifies the incoming packet to replace the (destination,port) values with the (address,port) of the original sender, and passes the packet on to that real destination.

The result is that multiple computers within the home network can “share” a common address without needing to do anything special, in most cases. There are a few implications however:

• anonymity: the external computer cannot tell which original computer really sent a request - it just sees the router’s address. This has been an issue in several law-cases, where prosecutors have tried to claim that a specific computer was used to break a law; in general it can only be determined that some computer behind that common router performed the act. This can also mean that the remote system cannot provide personalised services based solely on the IP address. Shared addresses also interfere with the ability of commercial companies to track users (or at least individual computers) solely by their IP address.
• inaccessibility: external computers cannot initiate connections to computers within the internal network; the outgoing part needs to occur first.

The fact that incoming connections don’t work over NAT is generally good for security - computers using NAT to access the internet are by default protected from unexpected network attacks. However some systems require incoming connections; games are a common case as are some video-call software etc. Hosting an externally-accessable web-site on a computer would also be such a case, but there are addiitonal complications there (including needing a stable IP address for the router, a DNS mapping, etc). There is a somewhat-clumsy workaround for this situation; the router can be explicitly configured to forward connections to (router-address, some-port) on to a specific computer in the local network. That computer will then need to be configured with a static IP address, so the rule doesn’t break when the computer or router is rebooted. This is called “port mapping”.

Some software (eg Skype) works around the “incoming connections with NAT” issue by using a central relaying-server; both ends in the communication open a connection to the central server. Unfortunately this is inefficient for network traffic, and is potentially bad for privacy. Try an internet search for “NAT Traversal” for further information on this topic.

The newer IPv6 network protocol mostly does away with the concept of NAT; the router instead requests an IPv6 address range from the ISP, and computers within the network are then given addresses from this range. They can then potentially be addressed from outside - ie incoming connections are possible - which is convenient but has security implications. This approach also removes the “partial anonymity” provided by NAT, although there are official ways to restore this if desired.

Router Firewalls

A router can potentially refuse to pass on data that it thinks is an attack on computers on the networks it manages.

NAT inherently provides a kind of firewall for incoming data - no packet will be passed on unless it is a response to a request that originated from within the network, or is addressed to a port configured wth “port mapping”.

When NAT is not enabled, then some protective behaviour on the router can be useful. As an example, it is generally undesirable to allow computers on the internet to access “ports” associated with the old/obsolete telnet application, or with databases such as postgres/oracle. It is rare for a computer to want to allow computers from the wide internet to access such applications - but sometimes administrators can make mistakes and enable external access to such applications on their computers unintentionally. Having the router block such connections anyway is a nice safety-backup.

It can also be useful for a router to block unexpected outgoing traffic (whether NAT is enabled or not). In the case that a computer within the network is infected with a virus, this can perhaps prevent the malware from reporting back to its “control center”, or spreading to other networks. Having such traffic reported/monitored is of course even better - as a prompt to check for infected systems!

Of course, each computer on the network should also be running some kind of firewall software as well, to protect itself on a per-machine basis. A router-based firewall only blocks traffic between networks.

OpenWRT and Switches

As noted earlier, home routers typically have a switch component and a router component within a single case. The switch component is wired to a number of sockets (ports) on the outside of the case, and internally connected to the router component. The router component is then connected to another socket (port), typically labeled “WAN” which leads to the ISP. The router therefore (as usual) joins two distinct networks, copying data between them as appropriate. Interestingly, in most cases the switch and router components communicate with each other over Ethernet - ie just as if they were physically separate boxes connected with a network cable.

While a switch is simply a circuit (though a complicated one), the router part is usually a general-purpose CPU capable of running a conventional operating system. The manufacturer will provide its own software stored in flash memory within the device, but in many cases this can be replaced by the owner if desired - eg with an appropriate version of the OpenWRT Linux distribution. In either case, the device will provide some kind of configuration interface; it might have an embedded webserver that can be accessed via a web-browser or the manufacturer might provide client software that must be installed on a PC or other device to send configuration commands to the router.

The switch component within a combined (switch, router) device can be configured too; I’m not currently sure whether this is technically done via special Ethernet packets sent from router CPU to switch, or whether there is an additional communications channel (eg I2C or PCI). Regardless, the configuration process is different for each switch model. Fortunately, the OpenWRT kernel that matches this router type will come with suitable tools.

As noted earlier, a switch automatically tracks which MAC address is on which physical socket (port), and forward packets automatically without informing any attached router. Therefore two stations on the same LAN communicate using MAC addresses directly. However when a switch has multiple physical ports, it is possible to create “groupings” within which data packets will be forwarded - in effect making a single switch act as if it were several separate switches joined by the router. These groups are called “VLANs”, and under OpenWRT the switch configuration is set by using the “swconfig” commandline tool, or via the LuCI web interface. Stations on two separate VLANs can then no longer communicate directly; they must instead send Ethernet frames containing IP packets to the router’s MAC address and let the router copy the data from one network (VLAN) to another - or not, depending on firewall rules.

When the switch forwards packets on to the Router CPU, it also usually populates the VLAN header field of the ethernet packet with the id of the VLAN on which the data arrived (information about which actual port within the vlan is lost, but that does not matter). Rules in the router can then use this VLAN id during the process of deciding what to do with a data packet.

See:

• http://wiki.openwrt.org/doc/uci/network/switch
• http://en.wikipedia.org/wiki/Virtual_LAN
• http://wiki.openwrt.org/doc/techref/swconfig

On my current router, the switch component supports 6 ports. One is internal, and connects to the CPU (port#0). One is connected to a physical port which is labelled “WAN”. There are 4 additional physical ports which are labelled “LAN”, and one of the switch component’s ports is not used (no space on the case). By default, the four ports labelled “LAN” are all configured as a single VLAN, ie stations attached to any of the ports can by default send Ethernet packets to stations attached to any of the other ports without having that data pass through the router CPU. However any station attached to the WAN port is “isolated” from the other stations, ie data flowing LAN->WAN or WAN->LAN can only go via the CPU. There is nothing special about the port labelled “WAN” other than the default VLAN configuration; any other port can also be “isolated” in the same way by assigning it to a different VLAN.

Port#0 is a little special with respect to VLANs; it is implicitly in any VLAN that is defined. The router therefore sees all layer-2 broadcast packets on any VLAN. The router can also send layer-2 packets out on a specific VLAN. I’m not sure if the router labels the packets it sends with the target VLAN, or if it simply specifies a MAC address and lets the switch figure out which VLAN (which physical port) is appropriate.

Of course the WAN port will not be able to directly reach the ISP using ethernet - native ethernet electrical signals have a maximum range of a hundred meters or so, while the ISP may be many kilometers away. Therefore the WAN port will be connected to some device that uses a more robust data transfer mechanism, eg a “cable modem” (which places varying-frequency signals on a cable-television wire) or an “ADSL modem” that does something similar for telephone cabling. Or more modern, the WAN port could connect to a 3G wireless modem that sends the data wirelessly to the ISP’s nearest transmission tower. But none of that is really relevant to OpenWRT configuration; such modems can be treated as a “black box”.

Within Linux (including within OpenWRT), multiple networks can be combined together and treated as a group; this is called “bridging” and is effectively the reverse of defining a VLAN. Bridging is often used within routers to merge traffic from a wireless network and a wired network together.

Wireless Networks

The IEEE standard 802.3 (Ethernet) specifies how multiple stations connected to the same physical wire can communicate at least at a basic level (datagrams). In a similar way, IEEE standard 802.11 specifies how multiple stations nearby to each other can communicate with radio signals. The “layer 1” (PHY) part of the specifications are very different of course. However the “layer 2” (MAC) parts are reasonably similar; wireless devices exchange “data frames” which are reasonably similar to wired Ethernet frames. Like wired ethernet, each frame specifies the origin and destination stations using a 48-bit MAC address.

One significant difference between ethernet and wireless is that Ethernet works with a number of “peer” devices connected to the same shared wiring; none of the devices needs to be “in charge”. With conventional wireless networks, one device sends out special data packets (“beacon frames”) stating that it is an “access point”, and other devices communicate with it, ie a “client-server” type arrangement. There are some alternative wireless protocols for “adhoc” or “mesh” networks but these are not currently in wide use.

Another difference is that data in a wireless network is encrypted; it may be acceptable for all devices physically wired together to exchange data in “plain text” by default, but doing that over a wireless network is quite different and obviously unacceptable. However the use of encryption also enforces a client/server arrangement; a client station and its access-point (server) set up encryption keys during a “session setup phase” (aka association). In fact, the concept of a “session” is also quite different from wired ethernet, but is needed due to the much greater complexity of communicating over radio signals; a whole lot of parameters need to be agreed on in order for efficient data transfer, such as frequencies and timings.

However as with a VLAN of a wired switch, multiple wireless stations connected to the same access-point communicate with each other without passing through the router. A station may send an ARP request just as in wired ethernet, and will get a response containing the appropriate MAC address to which it should send data; the MAC address may be another wireless client attached to the same access-point or (if no connected wireless station has that address) the MAC address of an attached router. In effect, all wifi stations are on “the same network”. This means that the router has no ability to apply firewall rules to communication between stations on the same wireless network - only when a station sends data (via the access-point) to another network.

A wifi-capable router is simply one that has a separate wireless component within the same case which is connected to an antenna and can convert data to/from radio signals. This component acts as an “access point” for a wireless network, ie a hub that other client devices can connect to. As with the “switch” component that handles wired networks, a wifi access-point component has a connection to the router CPU and the router operating system comes with suitable tools to send configuration commands to the wireless component. And like a switch component, the wifi component typically communicates with the router CPU via Ethernet - as if it were an external box connected via a cable ⁷. What the router CPU then sees is normal wired ethernet frames, just as if a remote wireless station were attached via wired cable to a switch - the complexity of radio signal management is largely hidden from it.

Some wifi access-point components can only support a single SSID, ie the component’s internal configuration settings don’t allow multiple SSIDs to be loaded into it, and therefore the radio signals the component generates only ever specify a single SSID and appear to wireless clients as a “single network”. More advanced components can be configured to appear to external devices as multiple independent wireless networks working on the same frequency (but without the data collisions!).

See:

• http://en.wikipedia.org/wiki/IEEE_802.11
• Mine of Information: The Linux Wireless Network Stack

IEEE Standards

The IEEE is a society whose members publish documents defining how to implement specific technologies.

These documents are typically only available for a fee, but fortunately a few have been made available at no charge - and the WiFi standard is one of them. The specification for wireless networking can be downloaded here. However, you almost certainly do not want to read it!

Other Topics

Point-to-point protocol (PPP) is used when two computers are directly connected to each other, ie a kind of “private network” consisting of only two stations. In this case, network addresses are obviously not very relevant. However some of the other features of TCP (retry, flow-control, etc) are useful. So the PPP protocol is a kind of “simplified TCP protocol” which uses the relevant parts of TCP and ignores the routing/addressing parts. You probably won’t encounter it in home networking, but some documents and admin interfaces might use the term. In the past, routers sometimes communicated with the ISP using PPP - a classical 1:1 network.

Ethernet does not support any “Quality of Service (QOS)” functionality - ie there is no concept of priority within Ethernet itself. The operating-system-level drivers might support it, ie reorder packets that are queued but not yet sent or reorder packets received but not yet delivered to applications. Ethernet hubs and switches do not support QOS either - but routers can.

IEEE specification 802.1D: MAC bridges…

802.1X –> defines extra network management and security features. For example, it:

• defines how to set up “authentication” for devices attaching to ports on a switch
• defines how to set up encryption between a switch and the devices attached to it
• defines data packets for reconfiguring switches (eg setting up VLANs).

Books

• TCP/IP Network Administration, Hunt, O’Reilly
• Computer Netzwerke 3 ed., Schreiner, Hunser Verlag

Other useful references

• TheGeekStuff: TCPIP Fundamentals
• TheGeekStuff: Hubs, Switches, Routers
• Microsoft: Hubs, Bridges, Switches
• Linux-ip
• The DHCP specification
• Data Communication Lectures of Manfred Lindner – Part IP Technology Fundamentals

Footnotes