Understanding networking concepts

Author: admin (Page 2 of 2)

Ethernet frame types and BPDUs

The first time I saw the structure of a Bridge Protocol Data Unit (BPDU) in Packet Tracer, I noticed something unusual in its Ethernet encapsulation. BPDUs are the type of message used by the Spanning-Tree Protocol (STP) in switches to avoid creating loops in a LAN. I will probably talk about STP later in this blog, but now I want to focus the discussion on the structure of an Ethernet frame.

The most common Ethernet frame type used today is known as Ethernet II. If you look at the traffic captured by WireShark or the PDU details shown by Packet Tracer, you will probably see the structure of an Ethernet II frame. For example, let’s look at the output of the “Outbound PDU details” of a ping message taken from Packet Tracer:

The first section of the output is named “Ethernet II” and represents the Layer-2 Ethernet frame that encapsulates the upper layers data. Let’s review the different frame fields in order, from left to right:

  • Preamble (7 bytes): bit pattern of alternating 1s and 0s for clock synchronization between the transmitter and the receiver.
  • Start Frame Delimiter (SFD) (1 byte): bit pattern 10101011 that marks the beginning of the frame.
  • Destination MAC address (6 bytes): the destination physical Layer-2 address.
  • Source MAC address (6 bytes): the source physical Layer-2 address.
  • Type (2 bytes): specifies the upper level protocol encapsulated. In this case, 0x0800 represents IPv4.
  • Data (variable length): the data or payload from the upper layers.
  • Frame Check Sequence (FCS) (4 bytes): a 32-bit CRC value for error checking.

Now let’s look at the PDU details of a BPDU packet:

Now, the Ethernet section is called “Ethernet 802.3“. The frame fields are basically the same, except for the Type field, which it is now called LEN (length) and represents the length in bytes of the data portion of the frame. Therefore, the STP protocol messages do not use the common Ethernet II encapsulation. An Ethernet 802.3 frame with LLC 802.2 encapsulation is used instead.

Ethernet II, also known as DIX Ethernet, is the version 2 of the original Ethernet implementation developed by DEC, Intel and Xerox. In the first IEEE definition of the 802.3 Ethernet standard, the Ethertype was replaced by the data length field and the protocol type was specified in an additional header using the LLC 802.2 protocol. The LLC header consists of 3 fields:

  • Destination Service Access Point (DSAP) (1 byte): represents the destination layer-3 process. In this example, the value 0x42 represents the STP protocol
  • Source Service Access Point (SSAP) (1 byte): represents the source layer-3 process: 0x42 for STP, again.
  • Control (1 or 2 bytes): represents the type of communication (unacknowledge connectionless, connection-oriented or acknowledged connectionless).

These fields are shown in Packet Tracer under the “LLC” section:

The last section called “STP BPDU” shows the fields of the BPDU message, as defined by the STP protocol.

LLC encapsulation has a variation called SNAP extension, that defines two additional fields after the control field:

  • OUI (3 bytes): 24-bit number that uniquely identifies a vendor.
  • Protocol ID (2 bytes): specify the particular protocol defined by that vendor.

For example, Cisco proprietary PVST+ protocol is encapsulated using a value of 0x00000c for the OUI field, and a value of 0x010b for the protocol ID. If both the DSAP and SSAP fields have a value of 0xAA and the control field is set to 0x03, it means that the frame is using the SNAP extension.

802.2 LLC and 802.2 SNAP framing types were used in some old technologies like FDDI, Token Ring or AppleTalk. Since IEEE approved the use of the Ethernet II in its 802.3 standard, clearly, this frame format won the battle and it is used in almost every local area network today. However, we can still see the old LLC encapsulation in some protocols like STP.

To finish the discussion about Ethernet frame types, I tried to do an experiment in Packet Tracer. It seems that Packet Tracer always shows BPDUs using LLC without SNAP extension. I created a simple topology with two switches and forced them to used the Rapid PVST+ instead of the default PVST+, by entering the IOs command: “spanning-tree mode rapid-pvst“.

Now the BPDU section is called “RSTP 802.1w”, showing that we are using the “rapid version” of the Spanning-Tree Protocol, but the LLC encapsulation shown is the same as before.

Collisions in Ethernet

In my first post of this blog, I will discuss the concept of collision in Ethernet transmissions. We all know that the use of switches instead of hubs in modern Ethernet networks has made collisions a thing of the past. But how?

When I started reading about Ethernet fundamentals, I was a little confused about the process of collision. If we think about the early days of Ethernet, it is easy to see how collisions occured. The standards 10BASE5 (Thick Ethernet) and 10BASE2 (Thin Ethernet) both used coaxial cables and were based on a bus topology. In a coaxial cable, we only have two wires: the central conductor and the outer metallic shield, both separated by a dielectric material. Since all the devices are connected to the same cable, if two devices happen to transmit at the same time, the two signals sent are mixed and a collision occur.

But, what happen in a twisted-pair cable? For example, in the old standards 10BASE-T or 100BASE-T, two pairs of cables are used. Since one pair is used for transmission and the other pair for reception, how can we get collisions? In this case, the collisions are a consecuence of the use of hubs.

Hubs are dumb devices. When a hub receives a frame, it sends the frame out all the ports except the port the frame it was received on. For example, the diagram below represents three devices connected via a hub:

If PC1 sends a frame to PC3, the hub will receive the frame on its Fa0 port and it will forward the frame out ports Fa1 and Fa2. So, PC2 will also receive a copy of the frame destined to PC3, that will be dropped. But, if PC2 also sends a frame to PC3 at the same time, the hub will forward the frame out ports Fa0 and Fa2. So, the hub will transmit two electrical signals corresponding to the frames sent by PC1 and PC2 through port Fa2 (using its transmission pairs 3 and 6). It will generate a collision, and PC3 will receive a corrupted sequence of bits.

The introduction of switches solved this problem because switches are intelligent devices that work at the layer 2 in the OSI model, and they know out which ports send the frames and when to send them. If we replace the hub in the previous topology by a switch, when PC1 sends a frame to PC3 we may find two different scenarios:

If PC3 MAC address is in the MAC address table of the switch, the frame will only be forwarded out Fa0/3. If PC3 MAC address is not in the switch MAC address table, the switch will forward the frame out all the ports except the receiving port, like a hub. In both scenarios, if PC1 and PC2 send a frame to PC3 simultaneously, the switch will not start forwarding both frames time out Fa0/3 generating a collision. One of the two frames will be stored in buffer while the other frame is being sent, therefore, collisions will never occur. In a switch, every port represents a different collision domain. Even though a port is configured in half-duplex mode, collisions will never occur as long as there is only one device connected to that port. If more than one device is connected to a switch port via a hub, then only one device can transmit at a time and collisions will need to be handled by the CSMA/CD algorithm.

Newer posts »

© 2023 Networking Tales

Theme by Anders NorenUp ↑