Understanding Local Access Networks and Ethernet

In this video we begin looking at local access networks. In particular we look at link layer MAC addresses and ARP, the address resolution protocol, as well as different versions of the Ethernet protocol. Let's get started. Alright continuing on in chapter 6 we have talked about the problems of multiple access to shared channels and now we're going to get down to some more details of link layer protocols starting with how they handle addressing. MAC addressing works significantly differently than IP addressing. But just as a reminder, the IP address is 32 bits and it's used for Layer 3 forwarding. And Layer 3 forwarding is based on longest prefix matching. The MAC addresses, which are the Layer 2 addresses, are used locally. In the context of IP, a MAC address is only significant within one subnet. And at this point, almost all Layer 2 technologies use a 48-bit MAC address, and these addresses are embedded in the network interface card, and there may or may not be some way to change them via the software. If we need to write out a MAC address, we do it in the following format with pairs of hexadecimal digits. The hyphens in between the pairs of digits are just for convenience, and in some cases are replaced with colons. One digit in hex represents four bits in binary, so these 12 characters represent the 48 bits of the MAC address. Alright, so here we have an example LAN and we're looking at the MAC addresses of the interfaces connected to that LAN. Now we note that in the IP addresses shown, they all share the same prefix, which is a requirement for longest prefix matching to work. However, the MAC addresses share no such constraint. In fact, they look pretty much random and have nothing in common with one another. In fact, the first few bits of the MAC address identify its manufacturer, and the rest of the bits are set either serially or randomly by the device manufacturer. So we can't require that the MAC addresses on a LAN have any particular relationship to one another. And what this implies is that when we need to forward frames to a particular MAC address, we can't do any form of longest prefix matching because we don't have that type of relationship between the addresses. Instead, we must do exact matching only when forwarding frames to a particular MAC address. So where do we get MAC addresses? Well, the manufacturers get them from the IEEE. So the IEEE assigns them in blocks. which is why the first 12 bits of the MAC address identify the manufacturer, although large manufacturers will have multiple of these prefixes known as OUIs, and then that manufacturer can use all of the addresses within that block. So just like there's nothing in your social security number that would tell someone how to find directions to your house, there's nothing in the structure of the MAC address that would help us find out how to get a packet to that host. The advantage to this is portability. The MAC address goes with the device. It doesn't have to change when it connects to a new network. This is in contrast to IP addresses which stay with the network and when a device leaves one network and connects to another one, its IP address changes. So our next problem is how do we find out what MAC address to use as a destination to a frame? The device knows its own MAC address to use in the source field and we've talked about how a host can use DNS to find out the IP address that it needs to send the IP packet to. But how does it find the MAC address used in the destination field of the layer 2 frame? That relies on a protocol called ARP, the address resolution protocol. And this is another distributed database lookup type function, but instead of mapping from a hostname to an IP address, it maps from an IP address to a MAC address. So every node on a network has to maintain an ARP table, or a mapping of the IP address MAC address pairs that it's aware of. And like most other mappings we've seen, There's a TTL after which this entry is considered stale and removed from the table. A common default for this TTL is 20 minutes. Now let's see how we populate this table. So we have host A and they want to send a datagram to host B. We assume that host A has already found out the IP address for host B and now it needs the MAC address. When it looks in its ARP table, it doesn't have a mapping for that IP address. So A will send out a broadcast ARP message. And just like the broadcast address in IP is the all ones address, the broadcast address in layer two is the all ones address. So all Fs in hexadecimal. So this layer two message says, who has this destination IP address that A is looking for? And every node on the local network will get this broadcast message. And whichever one has that address should reply using its own MAC address. So the frame has a source MAC address and inside has a source IP address and a target IP address. Now B receives this message and says, oh, that's my IP address. So it responds back using an ARP response that includes its MAC address. It knows what MAC address to send this back to due to the contents of the original message. And so it has the mapping between its IP address and MAC address. A can then update its ARP table with the contents of this message, and then it can send out all the frames that it needs to to that destination MAC address. So that process is fine if A and B are on the same subnet. However, these broadcast frames, the all ones MAC address, don't get forwarded by routers. So it's only devices that are on the same subnet that would hear this query. So if we have a topology like this one with a router in between A and B, if A were to send out an ARP request for B's IP address, it would never reach B because the router will not forward the ARP request. This is a good thing because it allows the network to scale. If ARP requests were forwarded by routers, there would be so many of them propagating around networks that they would consume too much bandwidth. So instead, when A looks at B's address, it can compare it to its own and its subnet mask and understand that B is in a different subnet. So A will not send out an ARP request for B's address. So here's our scenario. A is on the subnet with all 1s in the prefix, and B is on the subnet with all 2s in the prefix. A has already found B's address through DNS. A also knows the address of the first hop router. This is A's gateway, which is either programmed in by the administrator or learned through DHCP. A also knows R's MAC address. Now, how does that happen? Well, because A knows the IP address of its gateway, it can send an ARP request for that IP address and get the gateway router's MAC address. So with all that information in hand, how does A get B's MAC address? A is able to go ahead and create a datagram with B's destination IP address. But when it gets to layer 2, it's going to use the MAC address of the gateway router as the destination. Remember we said layer 2 addresses only have significance within the local subnet. Even if A knew B's MAC address, if it used it as the destination here, no one on A's subnet would know how to get that frame over to B. So from a layer 2 perspective, the router is the destination for the frame. And not just any MAC address on the router, it is specifically the MAC address of the router's interface on A's subnet. So this frame is sent over the router, which as we know is a Layer 3 device, and it passes up the stack there, and it's passed all the way up to the IP layer, meaning the Layer 2 frame is completely removed from this packet before forwarding happens. Then when the IP layer is going to send this out the other interface, it's creating a whole new frame. So the fields in this frame need to have no relation to the fields in the Layer 2 frame that A sent out. In fact, this could be a completely different Layer 2 technology altogether. The new frame header now has the router's interface on B's subnet as the source MAC address, and it has B's MAC address as the destination for the layer 2 frame header. How did it get that? Well, the router can issue an ARP request for B. Any layer 3 device can issue ARP requests. But it is highly likely that the gateway router would have B's MAC address cached, because B probably has sent traffic to the gateway router already. So the router is all set to transmit the frame onto B. When B's network interface receives the frame, it's able to extract the IP datagram and pass it on at the stack. Alright, now that you know just enough about MAC addressing and ARP to be dangerous, let's explore Ethernet in a little more detail. Ethernet is the dominant LAN technology today. Certainly there have been others in the past, but at this point there are few, if any, real competitors to Ethernet in this space. Its success is largely due to the simplicity of the design, using the CSMA-based protocol. And this has also helped it keep up with the speed race, with up to 400 gigabits per second possible today. Ethernet interfaces also tend to support multiple speeds, so if you have two devices with different speed capabilities, they're still able to talk just at the speed of the lower device. The early versions of Ethernet were literally a bus, meaning one long coaxial cable with multiple computer interfaces tapped into it. So this bus architecture might run the length of a hallway in a building or something like that. When we draw this architecture, we typically do something like this with a shared line and multiple lines coming off of it. As time progressed, the long bus cable running down hallways was replaced with a device called a hub, but the function was the same. It was still a shared medium. However, by the end of the 90s, switches were becoming more and more common, and switches were an active device in the middle of the Layer 2 network, which was able to break up the collision domain and create point-to-point links between the switch and every individual host. So by the time Ethernet reached 1 gigabit speeds, the shared bus model was no longer in use. For switched networks, when we're drawing the Layer 2 architecture, we put the switch in the middle and draw the point-to-point links to each host. These point-to-point links are full duplex, and so there's no collisions in a fully switched Layer 2 network. As we saw before, collisions are the source of significant inefficiency in these networks, and so eliminating them greatly increases the possible utilization even on busy Layer 2 networks. Here we have the Ethernet frame, which includes an 8-byte preamble. This is because the clocks of devices on an Ethernet network are not synchronized with one another. So as it receives the frame, it's able to read the known pattern and synchronize its clock to the bit timings and then successfully read the rest of the frame. We then have the destination and source address, these are the MAC addresses, followed by the type. The Ethernet type, commonly referred to as the Ether type, provides the demultiplexing function. This is analogous to an IP protocol number or a transport layer port number. The type tells us what's in the payload. So there's one type for an IPv4 packet and another type for an IPv6 packet and other types for routing protocols that run directly on top of layer 2 and another type for ARP and for any other message that runs directly over layer 2 instead of inside of IP. So we have 12 bytes of addressing for the two MAC addresses combined. And every time the adapter receives a message, it looks to see if it matches its MAC address and the destination address, in which case it will pass it up based on the type field. Or it looks for the broadcast address, in which case it will also pass it up based on the type field. Any frame that doesn't meet one of those criteria is discarded. This is known as a broadcast and select model. The interface may see many frames that it doesn't actually need to process. Some other types that have run over Ethernet in the past include the Novell IPX protocol and the AppleTalk protocol. both of which have since become obsolete and replaced with IP. At the end of the frame we have a trailer containing the CRC bits for the cyclic redundancy check. Again this is just an error check and so if an error is detected the frame must be dropped. Similar to IP, Ethernet is unreliable and connectionless. There's no handshaking or congestion establishment between NICs that communicate with one another and there's no acknowledgements or negative acknowledgements sent. So if any frame does get dropped, Whether due to a collision or a failed error check, it's up to the higher layers to handle any type of retransmission. Ethernet's MAC protocol is the CSMA-CD with binary backoff that we described in a previous video. There have been many different Ethernet standards over time, because not only has Ethernet supported many different speeds over the years, it has also supported different physical media. And the Ethernet standard covers not only the framing and the protocol, but the parameters of the physical interfaces supported. So some of these have been the coaxial cables that we talked about before, with physical taps. Today it's commonly the RJ45 ports containing four copper twisted pairs. But Ethernet also runs over fiber optics, and these may be single mode or multi-mode fiber optics. So we can differentiate the standards by speed and by medium, and all the ones listed here are just for 100 megabits per second. So you can imagine that there are similar versions for 1 gigabit, 10 gigabit, 40 gigabit, etc. That wraps up our discussion of addressing an Ethernet. In the next video we'll move on to talking about Layer 2 switches as well as VLANs. See you then! We hope you enjoyed this video. If you found it to be useful, please click the like button. To be notified when more videos are posted for this class, please subscribe to our channel and click the bell.

But just as a reminder, the IP address is 32 bits and it's used for Layer 3 forwarding. And Layer 3 forwarding is based on longest prefix matching. The MAC addresses, which are the Layer 2 addresses, are used locally. In the context of IP, a MAC address is only significant within one subnet.

And at this point, almost all Layer 2 technologies use a 48-bit MAC address, and these addresses are embedded in the network interface card, and there may or may not be some way to change them via the software. If we need to write out a MAC address, we do it in the following format with pairs of hexadecimal digits. The hyphens in between the pairs of digits are just for convenience, and in some cases are replaced with colons.

One digit in hex represents four bits in binary, so these 12 characters represent the 48 bits of the MAC address. Alright, so here we have an example LAN and we're looking at the MAC addresses of the interfaces connected to that LAN. Now we note that in the IP addresses shown, they all share the same prefix, which is a requirement for longest prefix matching to work.

However, the MAC addresses share no such constraint. In fact, they look pretty much random and have nothing in common with one another. In fact, the first few bits of the MAC address identify its manufacturer, and the rest of the bits are set either serially or randomly by the device manufacturer.

So we can't require that the MAC addresses on a LAN have any particular relationship to one another. And what this implies is that when we need to forward frames to a particular MAC address, we can't do any form of longest prefix matching because we don't have that type of relationship between the addresses. Instead, we must do exact matching only when forwarding frames to a particular MAC address. So where do we get MAC addresses? Well, the manufacturers get them from the IEEE.

So the IEEE assigns them in blocks. which is why the first 12 bits of the MAC address identify the manufacturer, although large manufacturers will have multiple of these prefixes known as OUIs, and then that manufacturer can use all of the addresses within that block. So just like there's nothing in your social security number that would tell someone how to find directions to your house, there's nothing in the structure of the MAC address that would help us find out how to get a packet to that host. The advantage to this is portability. The MAC address goes with the device.

It doesn't have to change when it connects to a new network. This is in contrast to IP addresses which stay with the network and when a device leaves one network and connects to another one, its IP address changes. So our next problem is how do we find out what MAC address to use as a destination to a frame?

The device knows its own MAC address to use in the source field and we've talked about how a host can use DNS to find out the IP address that it needs to send the IP packet to. But how does it find the MAC address used in the destination field of the layer 2 frame? That relies on a protocol called ARP, the address resolution protocol. And this is another distributed database lookup type function, but instead of mapping from a hostname to an IP address, it maps from an IP address to a MAC address.

So every node on a network has to maintain an ARP table, or a mapping of the IP address MAC address pairs that it's aware of. And like most other mappings we've seen, There's a TTL after which this entry is considered stale and removed from the table. A common default for this TTL is 20 minutes. Now let's see how we populate this table.

So we have host A and they want to send a datagram to host B. We assume that host A has already found out the IP address for host B and now it needs the MAC address. When it looks in its ARP table, it doesn't have a mapping for that IP address. So A will send out a broadcast ARP message.

And just like the broadcast address in IP is the all ones address, the broadcast address in layer two is the all ones address. So all Fs in hexadecimal. So this layer two message says, who has this destination IP address that A is looking for?

And every node on the local network will get this broadcast message. And whichever one has that address should reply using its own MAC address. So the frame has a source MAC address and inside has a source IP address and a target IP address.

Now B receives this message and says, oh, that's my IP address. So it responds back using an ARP response that includes its MAC address. It knows what MAC address to send this back to due to the contents of the original message.

And so it has the mapping between its IP address and MAC address. A can then update its ARP table with the contents of this message, and then it can send out all the frames that it needs to to that destination MAC address. So that process is fine if A and B are on the same subnet.

However, these broadcast frames, the all ones MAC address, don't get forwarded by routers. So it's only devices that are on the same subnet that would hear this query. So if we have a topology like this one with a router in between A and B, if A were to send out an ARP request for B's IP address, it would never reach B because the router will not forward the ARP request. This is a good thing because it allows the network to scale.

If ARP requests were forwarded by routers, there would be so many of them propagating around networks that they would consume too much bandwidth. So instead, when A looks at B's address, it can compare it to its own and its subnet mask and understand that B is in a different subnet. So A will not send out an ARP request for B's address.

So here's our scenario. A is on the subnet with all 1s in the prefix, and B is on the subnet with all 2s in the prefix. A has already found B's address through DNS. A also knows the address of the first hop router. This is A's gateway, which is either programmed in by the administrator or learned through DHCP.

A also knows R's MAC address. Now, how does that happen? Well, because A knows the IP address of its gateway, it can send an ARP request for that IP address and get the gateway router's MAC address.

So with all that information in hand, how does A get B's MAC address? A is able to go ahead and create a datagram with B's destination IP address. But when it gets to layer 2, it's going to use the MAC address of the gateway router as the destination. Remember we said layer 2 addresses only have significance within the local subnet. Even if A knew B's MAC address, if it used it as the destination here, no one on A's subnet would know how to get that frame over to B.

So from a layer 2 perspective, the router is the destination for the frame. And not just any MAC address on the router, it is specifically the MAC address of the router's interface on A's subnet. So this frame is sent over the router, which as we know is a Layer 3 device, and it passes up the stack there, and it's passed all the way up to the IP layer, meaning the Layer 2 frame is completely removed from this packet before forwarding happens.

Then when the IP layer is going to send this out the other interface, it's creating a whole new frame. So the fields in this frame need to have no relation to the fields in the Layer 2 frame that A sent out. In fact, this could be a completely different Layer 2 technology altogether.

The new frame header now has the router's interface on B's subnet as the source MAC address, and it has B's MAC address as the destination for the layer 2 frame header. How did it get that? Well, the router can issue an ARP request for B. Any layer 3 device can issue ARP requests. But it is highly likely that the gateway router would have B's MAC address cached, because B probably has sent traffic to the gateway router already.

So the router is all set to transmit the frame onto B. When B's network interface receives the frame, it's able to extract the IP datagram and pass it on at the stack. Alright, now that you know just enough about MAC addressing and ARP to be dangerous, let's explore Ethernet in a little more detail. Ethernet is the dominant LAN technology today. Certainly there have been others in the past, but at this point there are few, if any, real competitors to Ethernet in this space.

Its success is largely due to the simplicity of the design, using the CSMA-based protocol. And this has also helped it keep up with the speed race, with up to 400 gigabits per second possible today. Ethernet interfaces also tend to support multiple speeds, so if you have two devices with different speed capabilities, they're still able to talk just at the speed of the lower device. The early versions of Ethernet were literally a bus, meaning one long coaxial cable with multiple computer interfaces tapped into it.

So this bus architecture might run the length of a hallway in a building or something like that. When we draw this architecture, we typically do something like this with a shared line and multiple lines coming off of it. As time progressed, the long bus cable running down hallways was replaced with a device called a hub, but the function was the same. It was still a shared medium.

However, by the end of the 90s, switches were becoming more and more common, and switches were an active device in the middle of the Layer 2 network, which was able to break up the collision domain and create point-to-point links between the switch and every individual host. So by the time Ethernet reached 1 gigabit speeds, the shared bus model was no longer in use. For switched networks, when we're drawing the Layer 2 architecture, we put the switch in the middle and draw the point-to-point links to each host.

These point-to-point links are full duplex, and so there's no collisions in a fully switched Layer 2 network. As we saw before, collisions are the source of significant inefficiency in these networks, and so eliminating them greatly increases the possible utilization even on busy Layer 2 networks. Here we have the Ethernet frame, which includes an 8-byte preamble. This is because the clocks of devices on an Ethernet network are not synchronized with one another. So as it receives the frame, it's able to read the known pattern and synchronize its clock to the bit timings and then successfully read the rest of the frame.

We then have the destination and source address, these are the MAC addresses, followed by the type. The Ethernet type, commonly referred to as the Ether type, provides the demultiplexing function. This is analogous to an IP protocol number or a transport layer port number. The type tells us what's in the payload. So there's one type for an IPv4 packet and another type for an IPv6 packet and other types for routing protocols that run directly on top of layer 2 and another type for ARP and for any other message that runs directly over layer 2 instead of inside of IP.

So we have 12 bytes of addressing for the two MAC addresses combined. And every time the adapter receives a message, it looks to see if it matches its MAC address and the destination address, in which case it will pass it up based on the type field. Or it looks for the broadcast address, in which case it will also pass it up based on the type field. Any frame that doesn't meet one of those criteria is discarded.

This is known as a broadcast and select model. The interface may see many frames that it doesn't actually need to process. Some other types that have run over Ethernet in the past include the Novell IPX protocol and the AppleTalk protocol. both of which have since become obsolete and replaced with IP.

At the end of the frame we have a trailer containing the CRC bits for the cyclic redundancy check. Again this is just an error check and so if an error is detected the frame must be dropped. Similar to IP, Ethernet is unreliable and connectionless.

There's no handshaking or congestion establishment between NICs that communicate with one another and there's no acknowledgements or negative acknowledgements sent. So if any frame does get dropped, Whether due to a collision or a failed error check, it's up to the higher layers to handle any type of retransmission. Ethernet's MAC protocol is the CSMA-CD with binary backoff that we described in a previous video.

There have been many different Ethernet standards over time, because not only has Ethernet supported many different speeds over the years, it has also supported different physical media. And the Ethernet standard covers not only the framing and the protocol, but the parameters of the physical interfaces supported. So some of these have been the coaxial cables that we talked about before, with physical taps. Today it's commonly the RJ45 ports containing four copper twisted pairs. But Ethernet also runs over fiber optics, and these may be single mode or multi-mode fiber optics.

So we can differentiate the standards by speed and by medium, and all the ones listed here are just for 100 megabits per second. So you can imagine that there are similar versions for 1 gigabit, 10 gigabit, 40 gigabit, etc. That wraps up our discussion of addressing an Ethernet. In the next video we'll move on to talking about Layer 2 switches as well as VLANs.

See you then! We hope you enjoyed this video. If you found it to be useful, please click the like button. To be notified when more videos are posted for this class, please subscribe to our channel and click the bell.

Transcript for:Understanding Local Access Networks and Ethernet

Transcript for:
Understanding Local Access Networks and Ethernet