How does the computer know which switch to send the packet to?

Question

As I have noticed so far, there is often a switch in local area networks, and those switches route packets based on the MAC address , now if there were two switches connected to one pc in a local network, since I have not seen a MAC address set for the switch so far, how does the pc know which switch to send the packet to?

Answer 1

It doesn't send it to a switch at all. It sends it out of whichever interface has the correct IP address and subnet or, if both are valid, whichever it believes is faster or has the fewest hops to the host.

If the network interfaces have different IP addresses and are segregated by subnet then that will effectively choose which interface the packets are sent out on.

Each interface can also be assigned a "metric" which basically states "this interface should be faster" and will be a lower number for faster interfaces. You can either let the operating system establish metrics, and therefore preferred interfaces, or you can set it yourself in the network interface properties.

The networking system in your OS might also use the TTL (Time To Live) information in TCP/IP packets to establish which link is shorter, but that is not a reliable indication of speed.

More intelligent systems may use load balancing and knowledge of recent delays on a link to adjust or override the interface metric on the fly.

Answer 2

It depends what sort of a setup you have.

You could have two network interfaces on the computer, connected to two completely distinct networks. In that case, the packets would go out of the interface determined by IP routing and the system might or might not route traffic between the two networks.

E.g. here, anything going to 192.168.0.x would go out of eth0 and through switch #1. If you also have a default route via e.g. 192.168.0.1, everything else not going to 10.1.2.x would also go out of eth0 to the router.

+----------+ eth0              
|          | 192.168.0.10/24   +------------+     { other computers   }
| computer |-------------------| switch #1  |---- { in 192.168.0.0/24 }
|          |                   +------------+     {       ...         }
|          | eth1              
|          | 10.1.2.3/24       +------------+
|          |-------------------| switch #2  |---- ...
+----------+                   +------------+

The above is the same topology as the one you had in comments. With no connection between the two switches, having the same IP subnet in both interfaces would pretty much only make sense if the system acted as a bridge between the two networks, allowing all hosts on one side to reach the others. Individual hosts would be found the same way a switch finds them: by keeping track where a MAC address was seen, and flooding the traffic to all ports if the location of the destination MAC was not known.

Without bridging, there would be no straightforward way to know which network to use if an application wanted to connect to an address that exists in both places. It'd not be just about finding where a host with that address is located, but that there might be two of them.

---

On the other hand, if the two switches are connected externally (unlike above), it's be possible to have the two network interfaces connected to the two switches, all on the same layer 2 network and IP subnet, without bridging. This would be used for redundancy/fault tolerance or increased bandwidth.

That could be done with one IP address, if the OS handles failover between the interfaces. E.g. the Linux bonding driver can transparently fail over between two interfaces if one goes down. Traffic would then be sent along the link that's currently active.

Load balancing is not usually possible here if the two switches are independent. But if they're part of a single logical platform that supports it, you could run LACP over the two links, transparently balancing traffic over the two links. With LACP, the traffic is split based on hashing the source and destination addresses.

bond0: eth0 + eth1, 192.168.0.10/24 
+----------+               
|          | eth0 (bonded)     +------------+     { other computers   }
| computer |-------------------| switch #1  |---- { in 192.168.0.0/24 }
|          |                   +------------+     {       ...         }
|          |                         |               |
|          | eth1 (bonded)     +------------+        |
|          |-------------------| switch #2  |--------+
+----------+                   +------------+

It could also be done with two IP addresses, with the application(s) dealing with traffic distribution. This would be similar to just having two independent hosts on the network. (It may require policy-based routing to have the source IP address influence the outgoing interface used.)

+----------+ eth0              
|          | 192.168.0.10/24   +------------+     { other computers   }
| computer |-------------------| switch #1  |---- { in 192.168.0.0/24 }
|          |                   +------------+     {       ...         }
|          | eth1                    |               |
|          | 192.168.0.11/24   +------------+        |
|          |-------------------| switch #2  |--------+
+----------+                   +------------+

Note that while switches have MAC addresses, they're only used for control functions, and are not relevant for data traffic. Switches do keep a table of the host MAC addresses they've seen in each port, and use that to forward data frames to the right places. And the hosts just have routing entries saying "traffic to network N goes out of interface I", or "traffic to network M gets sent to router R via interface J", or routing entries that also take the source address into account. The host will have to use ARP or similar to figure out the destination MAC address, but that's the MAC address of the destination host, not the switch.

Also, "routing" is a network/IP/layer 3 function, not something a switch does. Switches "forward" frames, or maybe just "switch" them. (I'd happily use the latter, though perhaps some might disagree.)

_{It doesn't matter here if those two network interfaces are on a single (PCI / PCIe) card, on two cards, integrated on the motherboard, or connected via USB or whatever. Just that they're complete independent interfaces, and not just alternate physical connectors for the same actual interface. E.g. many switches have ports that have both a copper connector and an SFP socket, but only one works at a time. And in times of yore, a 10 Mb/s network card often had connectors for twisted pair, coaxial thin Ethernet and the D-15 AUI as alternatives.}

Answer 3

In this answer I take into account additional details given in the comments:

1. the topology: (router--------------switch----------PC-----------switch----------router)

2. both PC's interfaces are configured in the same subnet

This is wrong.

What happens in this faulty configuration (in Linux)?

The routing table has two entries for the same subnet, one for each interface and source ip address. E.g.:

# ip route show
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.2

When you try to ping some address in that subnet only the first interface is used. Thus, you cannot reach the second router.

Answer 4

The PC learns which MAC addresses correspond to an IP address by broadcasting an ARP message. The target should respond I have IP and my MAC address is this. The PC will then keep an ARP table with entries that map IP, MAC and interface the device responded.

The PC is not bothered how the message arrives at the end point as long as some device will switch the packet to your destination.

Most switches have a MAC address and keep ARP tables. They will forward the ARP requests to all connected devices and they will also remember where the reponse comes from. Dumb hub's would typically not have memory and would just keep broadcasting the messages in all directions.