1. 13 - Describe Switching Concepts

This blog is covering the below CCNA topics:

1.13.a MAC learning and aging
1.13.b Frame switching
1.13.c Frame flooding
1.13.d MAC address table

Components of L2 Ethernet Frame

Preamble

Preamble is basically used when we have two devices connected to each other via an Ethernet cable, the Preamble uses a continuous stream of 01010101.... this makes up 1 byte. Then we have 6 more continuous 01010101 bit stream to make up a total of 7 bytes. In terms of bits, this is 8x7 = 56 bits.

This contains no data its just a stream of bits. Why do we do this? Its used as a Synchronization mechanism. (In reality on the wire itself its electrical current or light representing the 1's and 0's)

The other side will receive these continuous 7 bytes steam and will know to synchronize its clock to be able to receive the data. It needs this head start to know that there is something on the wire

SFD

Start Frame Delimiter or SFD is after the Preamble. After both devices have synchronised their clocks, the SFD is just a 1 byte (8 bit) message. However, the difference is that its bit stream is 01010111. It ends in a double 1. This informs the other end that this is the SFD byte.

The purpose is that the host knows whatever it receives after the last 1 bit, is going to be the start of the MAC address - More specifically the destination MAC Address.

Both hosts are on Ethernet so they understand the Data-Link Layer. They know once reaching SFD the next 48 bits is Destination MAC, and the 48 bits after that is the Source MAC Address. Both sides know this because they have implemented in the code the rules/protocols of Data-Link Layer

Destination & Source MAC

We already have learnt this concept in L2 and L3 Packet Flow Fundamentals

Destination MAC Address will either be FFFF:FFFF:FFFF to represent a broadcast MAC Address or will be a specific MAC Address after ARP has been completed.

Source MAC is always known...because this host is generating the message.

Type

This is a field basically to inform of what the Upper Layer Protocol is. Remember that in Layer 3 we encapsulate the protocol into a Layer 2 Ethernet Header.

The purpose of this is basically before the prevalence of IP there were many other Layer 3 technologies. This field would differentiate it. It is also known as the EtherType. The EtherType for IPv4 is a hexadecimal value 0x0800 and 0x0806 for ARP.

It can indicate what it is carrying inside of an L2 frame whether it is IP or something else, or the length of the data field, the minimum and maximum.

Data & FCS

This is the actual data payload that is encapsulated. The minimum in Ethernet standard is 46 bytes or 1500 bytes.

All the above to type is known as the Ethernet Header. However from Data to FCS these are part of what is known as the Ethernet Trailer.

FCS is known as Frame Check Sequence. It is for Error detection to check if anything happened to the header or data. If anything has happened to the frame then it can check and discard the frame if required.

Concept of Padding Bytes

As we can see above, the application Layer generates the data, and this can be anything as long as its less than 1500 bytes to account for the other layers, lets say its 1300 bytes. Transport may be around 20 bytes, same for network layer. In total we have 1340 bytes. This satisfies the condition to be put into the data field in the Data-Link Layer.

However, what if the application layer generates around 10 bytes and transport/network generate 10 bytes respectively? We are only left with 30 bytes. ETHERNET WILL NOT carry this data. It must meet a minimum of 46 bytes.

So what happens is 16 padding bytes are added to meet this requirement to send the Layer 2 Ethernet Frame.

Why is Ethernet Data size Fixed to 46 bytes?

I do not have the exact answer but this is most likely to detect collisions. In legacy networks with hubs collisions were very common. If frames were too small then collisions could become undetectable. This 46 byte minimum allows for performing an FCS check on the ethernet frame to ensure no collisions and no errors in the frame.

For more information on collisions I will be creating a blog on CSMA/CD.

Switch Operations

This is the topology and MAC table we will be using going forward. This is assuming ARP is already complete and the switch has learnt the respective MACs on all its interfaces. Remember that a L2 switch does not do ARP.

Unicast Forwarding

This is a recap of the Forwarding operation of a L2 switch. Alice wants to Ping Bob and has the below L2 Frame:

ARP is complete so Alice sends the frame towards the L2 switch. The L2 switch sees the destination MAC in the L2 frame looks up this up its MAC/CAM table and and knows to send this to destination 01AC:CCCC:CCCC I need to forward this frame out of my Gi0/3 interface.

01AC:CCCC:CCCC will de-encapsulate the L2 Frame and then send the response and same process.

This whole process is known as Unicast Forwarding and happens after ARP has completed and the switch knows how to reach both the source and destination MAC's in its MAC/CAM table.

Flooding

In the below Alice now wants to ping David.

We have already gone over this, but the switch will receive this packet and check if it knows the destination. In this case its a broadcast frame, but in any case where the switch does not know the destination MAC address it will ALWAYS flood out the frame out of all ports EXCEPT the one it received it on.

In this case the frame will be flooded out of Gi0/2 and gi0/3. Gi0/2 is Bob who will receive the ARP request and see that the Target IP is not for him, so his CPU will drop the Frame. However, David will look into the ARP request and see it is for him and process the L2 frame, send back an ARP request and the switch will learn David's MAC in the MAC table and then full communication between Alice and David.

However, I want to stress, this doesn't just apply to ARP, anytime a host generates a frame and the switch does not know the destination of that Frame it will flood the packet out of all interfaces EXCEPT the one it received it on. The only situation outside of ARP I can think of is when a host genuinely wants to flood to all F's as the destination MAC Address.

Unknown Unicast

Linked to the above. This is where the switch does not have an entry for a MAC Address however the host has the destination MAC in its ARP Cache. This is unicast because it knows specifically which destination it wants to go to.

The L2 switch will absolutely do flooding/broadcasting for Unknown Unicast Frames because it has to learn on which port is this destination MAC.

Filtering

Filtering is the process of flooding out a Broadcast or Unknown Unicast packet out of all ports EXCEPT the one it received it on. This is useful when connected to Hubs.

Hubs are legacy devices, essentially same as a switch, however, no matter what frame reaches the Hub whether its unicast, unknown unicast, broadcast, the hub ALWAYS floods it out of all ports. There is no MAC table like a switch or any intelligence. It always does flooding.

What is interesting is when a switch is connected to a Hub. If that hub has two PC's Alice and Bob connected to it, the switch will learn two MAC addresses because both devices will be flooding to the switch

If Alice then wants to communicate to Bob, then the hub will flood it out to Bob but also to the switch. However, the switch is smart because of its MAC table to know to reach B is via the same interface I learnt it on. IT WILL NOT send it and will assume that there is a hub connected to this port, and instead Hub will flood it and it will get to Bob

This is the reasoning why a switch will flood a Broadcast or Unknown Unicast out of ALL ports EXCEPT the one it received it on. This can cause issues in virtualization which we will discuss in the future.