[#netbasic]:

Network Basics

This page refers to some resources (and may directly have some information) related to some basic network technologies and/or networking theory.

Some similar resources may include: Counting guide (for decimal, binary, and hexadecimal), basics, networking, network features.

Network Addresses

The network addresses discusses various types of network addresses. Most of the content on that page is related to network addresses that are names, meaning that the addresses can (and perhaps, in some cases, must) contain at least one letter. One of the first hyperlinks on that page refers to numeric network addresses, which covers addresses where all of the unique characters are numbers. (For example, an IPv4 address is typically written out using three periods, but the customizable portions of the addresses is a specific series of numbers.)

OSI Model

OSI Model Chart/Info

Creating Data Units (Encapsulation)

Creating Protocol Data Units (demonstrating encapsulation)

[#subnet]: subnets
Identification

An individual subnet is typically identified by its “network ID”, which is the first address in the subnet, and also a reference to the size of the subnet. For example, 192.0.2.128/25 is a specific subnet. If the double-colons at the end of an IPv6 address range are considered to be optional, then 0/8 could refer to two subnets (as there is a 0::/8 in IPv6 and a 0.0.0.0/8 in IPv4).

[#ipsubnet]: ipsubnet

See: IP subnets.

[#mksubnet]: Subnetting

It is helpful to understand what an IP subnet is. See: IP subnets.

Subnetting involves figuring out how many devices needs to be supported, and how large of a subnet is needed to support those devices. Alternatively, the process can refer to considering how many usable addresses are in a specific subnet. The term may also refer to the concepts of splitting up a network/subnet into multiple smaller subnets. A similar process is supernetting, which simply involves going the other direction, by combining multiple subnets into a larger subnet/network.

For instance, an IPv4 /28 can support up to eight addresses, of which six are generally considered to be “usable” by devices.

Tasks which might be considered common may involve:

  • Figuring out how many devices need to be supported. Then determine how large of a subnet is needed to support those devices.
  • Determine how many devices can have their own unique “usable” address for a specific subnet. Also determine how many “usable” addresses would be available in each subnet if the subnet were split into smaller subnets (using VLSM). Likewise, determining how many addresses are supported by a combined supernet.

The number of usable addresses can be calculated by:

  • Taking the number of bits in the address family (IPv4 has 32 bits, and IPv6 has 128 bits), and subtracting the number of bits used for identifying the network and subnet. (So, for a IPv4 /28 network, 32 - 28 = 4.) This is the number of bits used for the “host” portion of the address.
  • Raise 2 to the power of however many bits are used for the host portion of the address. (So, 2 4 (or written out as 2^4 when superscripting is not supported) is 8. This number represents the number of addresses in a subnet.
  • At least for IPv4, the standard is to reduce the number of addresses by two, in order to identify the number of “usable addresses”. This is because some addresses are not generally considered to be “usable” addresses: those addresses are the last address of a subnet block (which is called the IPv4 broadcast address) and the first address of the subnet block (which is called the IPv4 Network ID).
    • Note: The inability to use the IPv4 Network ID is based on a very old standard, and a desire to be compatible with equipment which was based on that standard. By the time IPv6 standards were being designed, the most common IPv4 address used for the broadcast traffic was clearly the last address of a subnet. So, there may be little need to subtract a usable address for IPv6. For that matter, IPv6 also specifies that multicast is to be used for the purposes of broadcasting, so there really shouldn't be a need to subtract off an address for a “broadcast address”. Perhaps this particular part of the process is limited to IPv4 subnets.

At least with IPv4, much of that process is often represented by the mathematical equation of 2 n-2 (or, for those who do not support superscripted writing, 2^n-2). Exponent calcuations have a higher order of precedence, so no parenthesis should be needed to tell people to calculate the power first. Some tests have wanted people to be familiar with the 2^n-2 equation, so it is good to understand.

Because of the need to subtract 2 addresses with each subnet, splitting up a subnet into smaller IPv4 subnets will end up having addresses which are not considered to be usable, while many of those addresses may be considered to be “usable” when using larger subnets. So, that is the cost of splitting a (sub)network into a larger number of smaller subnets, compared to the benefit achieved when combining subnets into larger (fewer) (sub)networks.

For some related information, see: Glossary: CIDR, Glossary: VLSM.

VLSM charts
][CyberPillar]['s VLSM chart

See: VLSM Chart.

Daniel Raffo's VLSM chart

Daniel Raffo offers an IPv4 VLSM chart. Its latest location is referenced by Daniel Raffo's page of documentation resources which hyperlinks to Daniel Raffo's VLSM chart: last octet subnetting. (Previously, Daniele Raffo's Quick References (redirection) at http://crans.org/~raffo/qrefs redirected to Daniele Raffo's Quick References at http://perso.crans.org/~raffo/quick-reference.php which offered a hyperlink to Daniel Raffo's VLSM chart at http://www.crans.org/~raffo/qrefs/vlsm-qref.pdf before some of the content moved.)

This chart shows some details for IPv4 subnets that are /24 through /30 in size. The address portions in the boxes (in the main area of the chart) represent the value used in the last octet of the “network ID” (when written out in the standard “dotted quad” format commonly used for IPv4 addresses). (The “network ID” is simply the first address of the subnet, and that address is widely considered to be “unusable”.) Much of the chart (including the Netmask representation of bits within the relevant octet of an IPv4 address, the number of subnets in the columns, and the boxes in the main part of the chart) also apply equally for /0 through /6, /8 through /14, and /16 through /22. (The chart does not show /31, likely because if an IPv4 /31 subnet is treated like other subnet sizes, then there are no “usable addresses”. 2^1-2 results in zero usable addresses.)

Cisco's VLSM chart (and similar)

This is not provided, as the material has been distributed via Cisco curriculum. This chart, although widely distributed, may be material that is covered by a copyright belonging to Cisco.

Errors were made when producing the chart. With at least one version of the document (found online), errors included:

  • .108/30 (usable addresses should be .109-110, not .107-.108). Additional errors, which are probably related, include:
    • .104/29
    • .96/28
  • .128/29 should have usable from .129 through .134, not through .130
  • .244 (usable should be .245-246)
  • .128/26 indicates that .191 is usable; actually, .190 should be the last usable address listed for that block
  • .192/26 indicates that usable is .191-.254; actually it should be .193-254

This was a version of the document that was labelled “Cisco Semester 5”. Perhaps Cisco has released a corrected version. Until information is verified, be wary that there may be errors in the chart.

The nice part is that the document is formatted to be able to be printed on a single sheet of paper. Most of the information, including the Network ID of each block, is accurate.

Another VLSM chart was seen that looks rather similar and appears to have less (and perhaps no) inaccuracies.

[#netfmdst]: Traffic destinations

Information about multiple possibilities of network destinations is in a seperate section: network traffic multi-desinations.

The information used to be located here. Following is some redirection/pointers for anybody who was looking for the information that used to be here.

[#unicast]: Unicast

Unicast traffic used to be described here. Now, see the description in the new location that discusses unicast traffic.

[#multicst]: Multicast

Multicast traffic used to be described here. Now, the basic description of multicast traffic is in a new location that discusses multicast traffic. Some of the more technical details about multicast traffic have been moved to a new section dedicated to multicast traffic details.

[#ip4mltcs]: Multicast with IPv4

Multicast with IPv4 used to be described here. Now, see the description in the new location that discusses Multicast with IPv4.

[#bdcstdoc]: Broadcast traffic

Some additional information used to be in this location. That information has been moved to broadcast addresses or its sub-section, Documentation/standards related to a “broadcast address”.

Internet Administration
Key Standards Bodies

See: Standards Bodies. These organizations may oversee standards. For example, the IETF releases the RFC documents.

Checking network communications
Connectivity

There are some ways to check for physical connectivity. For systems where “media sense” is not being useful, a hardware-based “link light” is also a common way to check the status of a connection.

[#mdiasens]: networking “Media Sense”

Newer computers will typically support “media sense”. This feature may also known as “media state”, perhaps largely thanks to the output of Windows XP's IPConfig. However, even Microsoft Windows uses the term “media sense” in the applicable registry entry that can disable the feature.

This technology might not tell a person anything that a person couldn't figure out based on the status of a “link light”. However, this may be more convenient (especially if a “link light&rdqu; is not supported).

Checking Media Sense in Microsoft Windows

WindowsNetworking article about Media Sense states, “This is normal (default) behavior in both 2000 and XP. Media Sense (added into NDIS 5.0) was built into the system to do this exact function.” Some older operating systems may simply not have this support.

Windows XP and newer
Supporting Media Sense

In Win2K/XP, this feature should be enabled by default. To disable the feature:

REG QUERY HKLM\System\CurrentControlSet\Services\Tcpip\Parameters /v DisableDHCPMediaSense
REG ADD HKLM\System\CurrentControlSet\Services\Tcpip\Parameters /v DisableDHCPMediaSense /t REG_DWORD /d 1

(MS KB 239924, WindowsNetworking article about Media Sense)

In Windows Server 2003, this may be disabled by default, at least in cluster environments. With Windows Server 2003, this can be altered with a registry value that defaults to zero:

REG QUERY HKLM\Cluster\Parameters /v DisableClusSvcMediaSense
REG ADD HKLM\Cluster\Parameters /v DisableClusSvcMediaSense /t REG_DWORD /d 1
Checking Media Sense

In Win XP, run IPConfig and check if the NIC being used shows “Media State . . . . . . . . . . . : Media disconnected” Or, graphically, the “Status” field may say “Network cable unplugged”. When using the default “Tiles” “View”, that field may show up underneath the NIC's name.)

In modern Windows, seeing any information from IPConfig about “media sense” may be required that the operating system does not believe that the media is disconnected. IPConfig may not say “Media State” at all unless it shows “Media disconnected”. (If the media is not disconnected, there may simply not be a line showing the “Media State”. That line just doesn't show up.) For those wishing to use the graphical interface, the Network Control Panel Applet may also show if media is “disconnected” or if it detects “Network cable unplugged”. That will be in the “Status” field, which might be easier to detect if using Details View. (Note that it might be true that some other status might override this, such as “Disabled”.)

Microsoft KB Q239924 discusses Media Sense a bit, and indicates that it is supported by Windows 2000 and Windows XP. With older versions of Microsoft Windows, the software may not report the status.

Checking Media Sense in Unix

In Unix, ifconfig may show a useful line that starts with the word “status”.

  • If the value of “media: ” shows Ethernet autoselect and the value of “status: ” shows “no carrier”, then that may indicate the line is disconnected. A more positive “status: ” that may show up is “active”.
  • Similarly, if the “media: ” shows IEEE802.11 autoselect, then a “status: ” of “no network” may indicate that the network card is not physically able to communicate (wirelessly) with another device until that connection is improved. In the case of wireless, such a connection may need to be set by changing some settings.
[#netlnlit]: network “link light”

These descriptions were written up separately, and may be merged...

First description

Many devices, particularly wired communications, have supported a “link light” to establish when there is a network link. Most commonly, the link light is green. There may also be an activity light, which may be typically be yellow (or yellow-green, or maybe even orange), or green. Non-green may be nicer for an activity light, as it may be easier to visually determine which light is the link light and which light is the activity light.

These lights can be very helpful for troubleshooting. Checking whether a light is lit can be quicker than seeing if a cable is plugged in. If a wire in a cable is damaged, connectivity might not work well even if a cable is plugged in. At least sometimes, a “link light” might help for such a problem to be noticed. (Note that there can be reasons, other than a bad cable, why a link light does not work. For instance, using a crossover cable when it is not necessary, in a switch that does not support auto-MDIX might result in the link light not lighting up. In that case, communication is not going to work until the problem is addressed, but the problem is not because of a physically bad cable. The same cable could be quite useful in other cases.)

On network cards, the typical location for these types of lights is right by the connector. For instance, on a RJ45-style connector, most of the connector is rather rectangular. There may be a space on the “top” of the connector for the RJ45 clip. To the left and right on the clip may be the link light and activity light. On devices like switches, which come manufacturered with support for at least a certain number of network jacks, the link lights and activity lights are typically on the front of the device. Laptops might have a “link light” fior a wired network card near some other lights, located near the keyboard (but closer to the back of the device), next ot lights like whether the computer is powered on, whether the computer is plugged into an electrical outlet, and whether Wi-Fi adapter is enabled or disbaled. (Exact details vary, often significantly, between different designs of laptops.)

The link lights typically operate very simply: on when there is a connection, and off when there is not.

The activity light is typically off when there is no network traffic being sent, and the activity light flashes on and off when there is activity. They do not flash with every bit of information: bits travel too fast for that. Sometimes, the activity lights may turn on and off so quickly that they appear to be a light glow, rather than being clearly distinct periods of being off and being on.

Second description

A “link light” is a light that is on whenever there is “link”, which has traditionally referred to a solid network connection using a physical cable. Such a light has often been placed near network jacks, although some devices like a network switch have been known to place the informational lights on the front of a device. Often, the light is near an “activity” light that may flash rapidly when activity is occurring. In such cases, a link light may often be green, and an activity light may be amber/yellow/orange, although such common occurrences standards are not absolutely universal so they aren't guaranteed.

To be clear, this is not commonly some sort of dedicated device that is different than a NIC. Rather, a multi-port NIC may commonly have a link light for each and every port.

Being able to see a link light is one way to help physically verify that there is some sort of connection. The ability to see such information via software is described by media sense.