Legacy Ethernet

Legacy Ethernet

When mainframe computers dominated the industry, user terminals attached either directly to ports on the computer or to a controller that gave the appearance of a direct connection. Each wire connection was dedicated to an individual terminal. Users entered data, and the terminal immediately transmitted signals to the host. Performance was driven by the horsepower in the hosts. If the host became overworked, users experienced delays in responses. Note, though, that the connection between the host and terminal was not the cause in the delay. The users had full media bandwidth on the link regardless of the workload of the host device.

Facility managers installing the connections between the terminal and the host experienced distance constraints imposed by the host's terminal line technology. The technology limited users to locations that were a relatively short radius from the host. Further, labor to install the cables created inflated installation and maintenance expenses. Local-area networks (LANs) mitigated these issues to a large degree. One of the immediate benefits of a LAN was to reduce the installation and maintenance costs by eliminating the need to install dedicated wires to each user. Instead, a single cable pulled from user to user allowed users to share a common infrastructure instead of having dedicated infrastructures for each station.

A technology problem arises when users share a cable, though. Specifically, how does the network control who uses the cable and when? Broadband technologies like cable television (CATV) support multiple users by multiplexing data on different channels (frequencies). For example, think of each video signal on a CATV system as a data stream. Each data stream is transported over its own channel. A CATV system carries multiple channels on a single cable and can, therefore, carry multiple data streams concurrently. This is an example of frequency-division multiplexing (FDM). The initial LANs were conceived as baseband technologies, however, which do not have multiple channels. Baseband technologies do not transmit using FDM. Rather, they use bandwidth-sharing, which simply means that users take turns transmitting.

Ethernet and Token Ring define sets of rules known as access methodsfor sharing the cable. The access methods approach media sharing differently, but have essentially the same end goal in mind.

Carrier Sense with Multiple Access with Collision Detection (CSMA/CD)

Carrier sense multiple access collision detect (CSMA/CD) describes the Ethernet access method. CSMA/CD follows rules similar to those in a meeting. In a meeting, all individuals have the right to speak. The unspoken rule that all follows, though, is "Only one person can talk at a time." If you have something to say, you need to listen to see if someone is speaking. If someone is already speaking, you must wait until they are finished. When you start to speak, you need to continue to listen in case someone else decides to speak at the same time. If this happens, both parties must stop talking and wait a random amount of time. Only then do they have the right to start the process again. If individuals fail to observe the protocol of only one speaker at a time, the meeting quickly degenerates and no effective communication occurs. (Unfortunately, this happens all too often.)

In Ethernet, multiple access is the terminology for many stations attaching to the same cable and having the opportunity to transmit. No station has any priority over any other station. However, they do need to take turns per the access algorithm.

Carrier sense refers to the process of listening before speaking. The Ethernet device wishing to communicate looks for energy on the media (an electrical carrier). If a carrier exists, the cable is in use and the device must wait to transmit. Many Ethernet devices maintain a counter of how often they need to wait before they can transmit. Some devices call the counter a deferral or back-off counter. If the deferral counter exceeds a threshold value of 15 retries, the device attempting to transmit assumes that it will never get access to the cable to transmit the packet. In this situation, the source device discards the frame. This might happen if there are too many devices on the network, implying that there is not enough bandwidth available. When this situation becomes chronic, you should segment the network into smaller segments. Chapter 2, "Segmenting LANs," discusses various approaches to segmentation. If the power level exceeds a certain threshold, that implies to the system that a collision occurred. When stations detect that a collision occurs, the participants generate a collision enforcement signal. The enforcement signal lasts as long as the smallest frame size. In the case of Ethernet, that equates to 64 bytes. This ensures that all stations know about the collision and that no other station attempts to transmit during the collision event. If a station experiences too many consecutive collisions, the station stops transmitting the frame. Some workstations display an error message stating Media not available. The exact message differs from implementation to implementation, but every workstation attempts to convey to the user that it was unable to send data for one reason or another.

Addressing in Ethernet

How do stations identify each other? In a meeting, you identify the intended recipient by name. You can choose to address the entire group, a set of individuals, or a specific person. Speaking to the group equates to a broadcast; a set of individuals is a multicast; and addressing one person by name is a unicast. Most traffic in a network is unicast in nature, characterized as traffic from a specific station to another specific device. Some applications generate multicast traffic. Examples include multimedia services over LANs. These applications intend for more than one station to receive the traffic, but not necessarily all for all stations. Video conferencing applications frequently implement multicast addressing to specify a group of recipients. Networking protocols create broadcast traffic, whereas IP creates broadcast packets for ARP and other processes. Routers often transmit routing updates as broadcast frames, and AppleTalk, DecNet, Novell IPX, and many other protocols create broadcasts for various reasons.

Figure 1-1 shows a simple legacy Ethernet system with several devices attached. Each device's Ethernet adapter card has a 48-bit (6 octet) address built in to the module that uniquely identifies the station. This is called the Media Access Control (MAC) address, or the hardware address. All of the devices in a LAN must have a unique MAC address. Devices express MAC addresses as hexadecimal values. Sometimes MAC address octets are separated by hyphens (-) sometimes by colons (:) and sometimes periods (.). The three formats of 00-60-97-8F-4F-86, 00:60:97:8F:4F:86, and 0060.978F.4F86 all specify the same host. This book usually uses the first format because most of the Catalyst displays use this convention; however, there are a couple of exceptions where you might see the second or third format. Do not let this confuse you. They all represent MAC addresses.

Figure 1-1. A Simple Ethernet Network

To help ensure uniqueness, the first three octets indicate the vendor who manufactured the interface card. This is known as the Organizational Unique Identifier (OUI). Each manufacturer has a unique OUI value that it acquired from IEEE, the global administrator for OUI values. Cisco has several OUI values: 00000C, 00067C, 0006C1, 001007, 00100B, 00100D, 001011, 001014, 00101F, 001029, 00102F, 001054, 001079, 00107B, 0010A6, 0010F6, 0010FF, 00400B (formerly Crescendo), 00500F, 005014, 00502A, 00503E, 005050, 005053, 005054, 005073, 005080, 0050A2, 0050A7, 0050BD, 0050E2, 006009, 00602F, 00603E, 006047, 00605C, 006070, 006083, 00900C, 009021, 00902B, 00905F, 00906D, 00906F, 009086, 009092, 0090A6, 0090AB, 0090B1, 0090BF, 0090D9, 0090F2, 00D006, 00D058, 00D0BB, 00D0C0, 00E014, 00E01E, 00E034, 00E04F, 00E08F, 00E0A3, 00E0B0, 00E0F7, 00E0F9,and 00E0FE.

The last three octets of the MAC address equate to a host identifier for the device. They are locally assigned by the vendor. The combination of OUI and host number creates a unique address for that device. Each vendor is responsible to ensure that the devices it manufactures have a unique combination of 6 octets.

Unicast Frames

In a LAN, stations must use the MAC address for the Layer 2 address in a frame to identify the source and destination. When Station 1 transmits to Station 2 in Figure 1-1, Station 1 generates a frame that includes Station 2's MAC address (00-60-08-93-AB-12) for the destination and Station 1's address (00-60-08-93-DB-C1) for the source. This is a unicast frame. Because the LAN is a shared media, all stations on the network receive a copy of the frame. Only Station 2 performs any processing on the frame, though. All stations compare the destination MAC address with their own MAC address. If they do not match, the station's interface module discards (ignores) the frame. This prevents the packet from consuming CPU cycles in the device. Station 2, however, sees a match and sends the packet to the CPU for further analysis. The CPU examines the network protocol and the intended application and decides whether to drop or use the packet.

Broadcast Frames

Not all frames contain unicast destination addresses. Some have broadcast or multicast destination addresses. Stations treat broadcast and multicast frames differently than they do unicast frames. Stations view broadcast frames as public service announcements. When a station receives a broadcast, it means, "Pay attention! I might have an important message for you!" A broadcast frame has a destination MAC address of FF-FF-FF-FF-FF-FF (all binary 1s). Like unicast frames, all stations receive a frame with a broadcast destination address. When the interface compares its own MAC address against the destination address, they don't match. Normally, a station discards the frame because the destination address does not match its own hardware address. But broadcast frames are treated differently. Even though the destination and built-in address don't match, the interface module is designed so that it still passes the broadcast frame to the processor. This is intentional because designers and users want to receive the broadcast frame as it might have an important request or information. Unfortunately, probably only one or at most a few stations really need to receive the broadcast message. For example, an IP ARP request creates a broadcast frame even though it intends for only one station to respond. The source sends the request as a broadcast because it does not know the destination MAC address and is attempting to acquire it. The only thing the source knows for sure when it creates the ARP request is the destination's IP address. That is not enough, however, to address the station on a LAN. The frame must also contain the MAC address.

Routing protocols sometimes use broadcast MAC addresses when they announce their routing tables. For example, by default, routers send IP RIP updates every 30 seconds. The router transmits the update in a broadcast frame. The router does not necessarily know all of the routers on the network. By sending a broadcast message, the router is sure that all routers attached to the network will receive the message. There is a downside to this, however. All devices on the LAN receive and process the broadcast frame, even though only a few devices really needed the updates. This consumes CPU cycles in every device. If the number of broadcasts in the network becomes excessive, workstations cannot do the things they need to do, such as run word processors or flight simulators. The station is too busy processing useless (for them) broadcast frames.

Multicast Frames

Multicast frames differ from broadcast frames in a subtle way. Multicast frames address a group of devices with a common interest and allow the source to send only one copy of the frame on the network, even though it intends for several stations to receive it. When a station receives a multicast frame, it compares the multicast address with its own address. Unless the card is previously configured to accept multicast frames, the multicast is discarded on the interface and does not consume CPU cycles. (This behaves just like a unicast frame.)

For example, Cisco devices running the Cisco Discovery Protocol (CDP) make periodic announcements to other locally attached Cisco devices. The information contained in the announcement is only interesting to other Cisco devices (and the network administrator). To transfer the announcement, the Cisco source could send a unicast to each and every Cisco device. That, however, means multiple transmissions on the segment and consumes network bandwidth with redundant information. Further, the source might not know about all of the local Cisco devices and could, therefore, choose to send one broadcast frame. All Cisco devices would receive the frame. Unfortunately, so would all non-Cisco devices. The last alternative is a multicast address. Cisco has a special multicast address reserved, 01-00-0C-CC-CC-CC, which enables Cisco devices to transmit to all other Cisco devices on the segment. All non-Cisco devices ignore this multicast message.

Open Shortest Path First (OSPF), an IP routing protocol, makes routing update announcements on a specially reserved multicast address. The reserved multicast OSPF IP addresses 224.0.0.5 and 224.0.0.6 translate to MAC multicast addresses of 01-00-5E-00-00-05 and 01-00-5E-00-00-06. Chapter 13, "Multicast and Broadcast Services," discusses how these MAC addresses are derived. Only routers interested in receiving the OSPF announcement configure their interface to receive the message. All other devices filter the frame.