4

Let us say I have switch S with 4 ports, PA, PB, PC, and PD, to which I have connected 4 hosts, A, B, C and D with the MAC addresses AA:AA:AA:AA:AA:AA, BB:BB:BB:BB:BB:BB, CC:CC:CC:CC:CC:CC and DD:DD:DD:DD:DD:DD respectively, in the same order. Now let us say switch, S has got the MAC address table created after packets been transmitted between the host.

The MAC address table would look somewhat like this-


AA:AA:AA:AA:AA:AA -----> PA

BB:BB:BB:BB:BB:BB -----> PB

CC:CC:CC:CC:CC:CC -----> PC

DD:DD:DD:DD:DD:DD -----> PD

Now let us say, i swap the hosts C and D. So after swapping, host C connects to port PD and host D connects to port PC. But the MAC address table with the switch remains the same; (assumption: there are no frames transmitted from either hosts, C and D to rebuild the MAC address table)

Now, if host A wants to send data to host C, then data transmitted by host A would reach the switch, S and then switch looks up its MAC address table and figures out that the destination MAC address in the frame is CC:CC:CC:CC:CC:CC (of host C) is connected to port PC and forwards the frame on its PC port. But once the frame reaches the host connected to port PC, which is host D (since we had swapped) would reject the frame. Since its NIC card compares its own MAC address DD:DD:DD:DD:DD:DD with that of the destination MAC address CC:CC:CC:CC:CC:CC. And packet would get dropped.

  1. Please confirm me if my understanding of this scenario is correct.

  2. Secondly, if the packet was reached to a wrong host and got dropped. And the source host things that i had sent the data to the intended host. How does this problem be addressed in networking.

  • When you disconnect the PCs from the switch interfaces, the switch will purge any MAC addresses for those interfaces, so any traffic destined for those PCs will be flooded to all interfaces as unknown unicast traffic. – Ron Maupin Mar 16 '18 at 12:48
  • @ronmaupin which is a fun fact for all those that use ports as some kind of security thing and then wonder that there are situations where others get their super secure traffic – PlasmaHH Mar 16 '18 at 17:11
  • @RonMaupin How does the switch gets to know that one of the host which has been connected to one of its port got removed? – Darshan L Mar 16 '18 at 17:33
  • If you disconnect the device connected to a switch interface, the interface goes down. There will be no carrier so the interface see that and it shuts itself down. You can see this with switches and devices that have link lights. – Ron Maupin Mar 16 '18 at 17:37
  • @RonMaupin Yes, i understand from layman's perspective, we can identify whether the link is up/down through link light. However, on the technical front, how the NIC card gets to know that the host connected to it has been removed. What is the protocol which is responsible for this? Looks like there should be some signals been passed from the host end. Otherwise, it is impossible for the NIC card to identify this, as it is just a piece of copper wire connected to the NIC card on the switch. (As the link light starts blinking when the other end of the copper wire is connected to the host) – Darshan L Mar 16 '18 at 18:00
6

Your understanding is correct, but your assumption that "no frames transmitted from either hosts, C and D." is likely wrong.

Gratuitious ARP precisely address this concern. From Wireshark.org:

The networking stack in many operating systems will issue a gratuitous ARP if the IP or MAC address of a network interface changes, to inform other machines on the network of the change so they can report IP address conflicts, to let other machines update their ARP tables, and to inform switches of the MAC address of the machine.

Even without Gratuitous ARP

  • if the machine is set to DHCP, then the DHCP request will triger the update
  • even if set to static, most operating systems tend to send many, many kind of traffic even when not solicited, like automatic updates for example.
6

Further to JFL's answer, many devices will send gratuitous ARP when the link comes up; switches correspondingly should invalidate their MAC table for a given port when the link state changes. In your example, when you swap devices C and D on their ports PC and PD, when the cables are removed the link should go down and the switch should remove their addresses from the table.

If you swap the MAC addresses (by reconfiguring) on a system which doesn't send a gratuitous ARP, a switch might send the frames out of the wrong port until a transmission triggered an update. (TCP retransmissions for example.) Switches also remove MAC addresses which are too old, so eventually it would be pruned in any case.

A switch with a good algorithm should notice transmissions to a MAC address which isn't replying and remove it from the table, just like aging out. It's a good experiment to try on different switches if you can get a host to behave in this way.

  • you're right, I forgot about the fact the switch will dismiss the entry for a port that shut down (although I'm not sure that all switches do it, it should be true for most devices that are on-topic on this site). – JFL Mar 16 '18 at 12:04
  • It's a while since I torture-tested switches, but it certainly used to be the case that the premium manufacturers were very much better than cheaper ones for the peculiar edge case failure modes. – jonathanjo Mar 16 '18 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.