Hmm, I can’t respond with certainty about how Dell switches work, but I can make an educated guess based on how link aggregation, DHCP, and MAC address learning works in general.
MAC learning has to do with populating the MAC address table. This is achieved both with regular switchports as well as port-channel link aggregated ports. However, this has nothing to do with DHCP for either IPv4 or IPv6. DHCP is a whole different mechanism that doesn’t use MAC address tables of switches, but uses DHCP servers with scopes that correspond a MAC address with a Layer 3 address, either IPv4 or IPv6.
Can you clarify the question you are asking? What do you mean when you say DHCP behavior of IPv6?
Hi Rene,
I got a question during my lab.
Topology: A printer was connected to the Gi1/0/24 and a pc was connected to the Gi1/0/2 ports of the same C29060S switch.
Problem:
Right after the equipment been setup, pc was able to reach the printer.
Then I left the equipment idle for 3 hours and then checked the MAC address-table of the switch again. I found printer was not on the list but the pc. I ping the printer with the command ping 192.168.0.102 -t and captured the transaction by Wireshark. ARP broadcast every 60 second could be observed. However the printer just didn’t responded to it. I doubt the cause may due to printer went to sleep. So I bypassed the switch to see what would happen. A few second later the printer woke and responded to the pc. That is to say the printer would be woken if arp broadcast could reach the printer.
So, I infer my switch went to hibernation and couldn’t be woken by broadcast.
If I don’t want the switch goes to hibernation, what can I do?
It is unlikely that the switch goes into hibernation mode. If there is a switch on the market that does that, it will definitely cause many problems for many users. I believe the problem is elsewhere.
When you say you bypassed the switch, what do you mean? Did you remove the switch from the path? In order to determine if the specific switch is at fault, you must recreate the same situation. Did you find that the MAC address of the printer was not in the switch’s MAC address table, and did you check the Wireshark captures once again? If that is the case, and the switch is indeed at fault, it is not because of hibernation. I believe that the switch is either defective or is not forwarding ARP broadcasts to the printer.
Are all of these cisco switches or other vendor switches? Can you give us some more info about the specific switch that seems to be causing this problem?
Bypass means the printer and the PC were unplugged from the switch and then connected to each other directly.
Before the switch was bypassed, I found that the MAC address of the printer was not in the switch’s MAC address table. Then I ping the printer with the command ping 192.168.0.102 -t and captured the transaction with Wireshark. I found ARP broadcast every 60 seconds but the printer didn’t respond. Obviously, the switch didn’t forward the ARP broadcast to the printer.
It is unlikely that the switch is defective because have another 2 switches (WS-C3750V2-24TS and WS-C3550-24-EMI) all of them behave the same.
If you connect the printer directly to the network card of the PC, then the printer will never go to sleep. The network card will continue to send traffic to the printer, which will keep its network interface awake. It is impossible to recreate the same conditions you had with the switch in the arrangement without the switch, so you can’t make any definite conclusions.
If the switch didn’t forward the ARP broadcast to the printer, then you would see this problem with all of your hosts connected to this switch. From my understanding, this is not the case. Therefore, the problem is confined to the printer itself. To determine if the ARP broadcast is reaching the printer, I suggest you set up a SPAN to capture the traffic reaching the interface the printer is on. Once you determine if the ARP broadcasts are indeed reaching the printer or not, you can then go on to the next step of troubleshooting.
I suggest you look at this lesson to see how this is done. Let us know of your results so we can help you further in the troubleshooting process.
If you connect the printer directly to the network card of the PC, then the printer will never go to sleep. The network card will continue to send traffic to the printer, which will keep its network interface awake. It is impossible to recreate the same conditions you had with the switch in the arrangement without the switch, so you can’t make any definite conclusions.
charleswongcni:
Then I ping the printer with the command “ping 192.168.0.102 -t” and captured the transaction with Wireshark. I found ARP broadcast every 60 seconds but the printer didn’t respond. Obviously, the switch didn’t forward the ARP broadcast to the printer.
If the switch didn’t forward the ARP broadcast to the printer, then you would see this problem with all of your hosts connected to this switch. From my understanding, this is not the case. Therefore, the problem is confined to the printer itself. To determine if the ARP broadcast is reaching the printer, I suggest you set up a SPAN to capture the traffic reaching the interface the printer is on. Once you determine if the ARP broadcasts are indeed reaching the printer or not, you can then go on to the next step of troubleshooting.
I suggest you look at this lesson to see how this is done. Let us know of your results so we can help you further in the troubleshooting process.
Hey Rene
Could you use the OSI model in explaining the process of 2 hosts in the same subnet pinging each other through a switch? Im asking because in order for 1 computer to send frames to another computer, you have to configure IP Addresses. But IP addresses are layer 3 = Packets and MAC addresses are Layer 2 = Frames. So how can it be a Frame if IP is involved? What does this look like visually? Is encapsulation taking place?
Thank you
This is an excellent exercise to understand how the various layers of the OSI model interact (especially the lower layers), and how communication within a subnet differs from communication with other subnets.
Thanks Laz. I just read through it. So it is safe to say that an Ethernet frame must contain the layer 2, layer 3, and layer 4 information. When you say frame, you arent always necessarily referring to the layer 2 information but the information from the other layers is encapsulated in that frame. Am I saying this correctly?
For all communications between network hosts, it is necessary to go down the protocol stack (whether OSI or TCP/IP) which means you need to have the source and destination MACs, the source and destination IPs and the source and destination TCP/UDP ports in all headers of the respective PDUs (Protocol Data Units).
Now a note on terminology, the generic name for the entity at each layer of the stack is called a Protocol Data Unit or PDU. However, the specific names for each layer are:
Datalink layer: Ethernet frame
Network layer: IP packet
Transport layer: TCP segment or UDP datagram depending upon the protocol used.
When I refer to a frame, I am specifically referring to the entity on the Datalink layer, that is the Ethernet frame. In the notes I created, I used the names as described above. So when I refer to a frame, I’m only referring to the Ethernet frame. Does that make sense?
The edge switches from Site 1 and Site 2 are connecting via a layer 2 connection with interface eth1/1. The interfaces are configured with trunk port that allows the same VLAN.
Each site has a firewall behind the switch. Interfaces on both firewall and switch are configured with trunk port and allowed all the VLANs.
When I look into mac table learn from the interface eth1/1 from the switch, SW1 for example, it actually shows the mac address of the FW2 instead of the mac address of the eth1/1 of SW2.
There is no misconfiguration in the VLANs and interfaces as the traffic properly running between the firewalls.
Would you be able to explain it? Thanks in advance.
This is actually expected behavior. Remember that a switch will populate the MAC address table by looking at the source address of incoming frames. The frames received on Eth1/1 of SW1 are frames that were generated by FW2, and they have FW2’s MAC address in the source address field. When they pass through SW2, they are considered transient traffic and SW2 simply forwards those frames to SW1.
The only way that SW1 will also populate the MAC address table with the MAC address of SW2 will be if SW2 generates traffic itself (like a ping for example) and sends it via SW1. Does that make sense?
As you will see from the explanations, both of these types of traffic are sent out of all switchport interfaces of the same VLAN on a switch. If you have any further questions, let us know!
Hello Laz,
Does that mean that in unknown unicast, even if a frame has a specific MAC address instead of FF-FF-FF-FF-FF-FF in the destination MAC address field, still the frame will be forwarded to all the ports on a switch?
If the above statement is correct, then unknown unicast can be triggered by aged out MAC in the MAC Address Table because end hosts may still have entry for the destination MAC address in its ARP table since the ARP table gets flashed out less often than the MAC Address Table.
Let’s look at a specific example. Let’s say we have a 24-port switch that receives an Ethernet frame with a source MAC address of AAAA and a destination MAC address of BBBB. (I’m using fake MAC addresses for simplicity). Let’s also say that the switch does not have the BBBB MAC address in its MAC address table. This is unicast traffic, but because the MAC address is not in the MAC address table yet, it is considered unknown unicast.
Because the switch does not know which port the specific host is on, it will send the frame out of all of its ports that are configured on the same VLAN. The frame that is sent still has a destination MAC address of BBBB. All of the hosts on all the ports will receive that frame. The host that has the BBBB MAC address will receive it and process it while all the other hosts will drop it because it has a different destination MAC address than their own.
Once the BBBB host responds to this frame, it will send a frame with a source MAC address of BBBB. The switch receives this on its port, and can now populate the MAC address table with the BBBB MAC address and its corresponding port. Thus any frames sent to BBBB from now on are known unicast.
Can unknown unicast be triggered by aged out MAC in the MAC Address Table because end hosts may still have entry for the destination MAC address in its ARP table since the ARP table gets flashed out less often than the MAC Address Table?
Yes indeed it can. If host B hasn’t sent any data for over five minutes (which is the default aging time for entries in the MAC address table on a switch), and host A wants to send a frame to host B, host A will know that the destination MAC address should be BBBB because it knows this from its ARP table. When the switch receives this, it is considered unknown unicast traffic, because it no longer has an entry for the BBBB MAC address. Therefore it is sent out of all of the interfaces.
If host A’s entry in its ARP table had also expired, then it would send out an ARP request for the appropriate MAC. The act of sending out an ARP request may allow the switch to learn host B’s MAC address from the ARP reply, which contains host B’s MAC address.
| 
charleswongcni: