Como o computador sabe para qual switch enviar o pacote?

Ele não envia para um switch em tudo. Ele o envia de qualquer interface que tenha o endereço IP e a sub-rede corretos ou, se ambos forem válidos, o que ele acredita ser mais rápido ou com menos saltos para o host.

Se as interfaces de rede tiverem endereços IP diferentes e forem segregadas por sub-rede, isso escolherá efetivamente em qual interface os pacotes serão enviados.

Cada interface também pode receber uma "métrica" ​​que basicamente indica "esta interface deve ser mais rápida" e será um número menor para interfaces mais rápidas. Você pode permitir que o sistema operacional estabeleça métricas e, portanto, interfaces preferenciais, ou você mesmo pode defini-lo nas propriedades da interface de rede.

O sistema de rede em seu sistema operacional também pode usar as informações de TTL (Time To Live) em pacotes TCP/IP para estabelecer qual link é mais curto, mas isso não é uma indicação confiável de velocidade.

Sistemas mais inteligentes podem usar balanceamento de carga e conhecimento de atrasos recentes em um link para ajustar ou substituir a métrica da interface em tempo real.

Depende do tipo de configuração que você tem.

Você pode ter duas interfaces de rede no computador, conectadas a duas redes completamente distintas. Nesse caso, os pacotes sairiam da interface determinada pelo roteamento IP e o sistema poderia ou não rotear o tráfego entre as duas redes.

Por exemplo, aqui, qualquer coisa 192.168.0.xque vai sair eth0e passar pelo switch #1. Se você também tiver uma rota padrão via, por exemplo 192.168.0.1, tudo o que não vai 10.1.2.xtambém sairá eth0para o roteador.

+----------+ 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  |---- ...
+----------+                   +------------+

A topologia acima é a mesma que você tinha nos comentários. Sem conexão entre os dois switches, ter a mesma sub-rede IP em ambas as interfaces só faria sentido se o sistema atuasse como uma ponte entre as duas redes, permitindo que todos os hosts de um lado alcançassem os outros. Hosts individuais seriam encontrados da mesma forma que um switch os encontra: rastreando onde um endereço MAC foi visto e inundando o tráfego para todas as portas se a localização do MAC de destino não for conhecida.

Sem ponte, não haveria uma maneira direta de saber qual rede usar se um aplicativo quisesse se conectar a um endereço que existe em ambos os locais. Não se trata apenas de descobrir onde está localizado um host com esse endereço, mas pode haver dois deles.

Por outro lado, se os dois switches estiverem conectados externamente (diferente de acima), é possível ter as duas interfaces de rede conectadas aos dois switches, todas na mesma rede de camada 2 e sub-rede IP, sem fazer ponte. Isso seria usado para redundância/tolerância a falhas ou largura de banda aumentada.

Isso pode ser feito com um endereço IP, se o sistema operacional manipular o failover entre as interfaces. Por exemplo, o driver de ligação do Linux pode fazer failover de forma transparente entre duas interfaces se uma estiver inoperante. O tráfego seria então enviado ao longo do link que está ativo no momento.

O balanceamento de carga geralmente não é possível aqui se os dois switches forem independentes. Mas se eles fizerem parte de uma única plataforma lógica que o suporte, você poderá executar o LACP nos dois links, equilibrando de forma transparente o tráfego nos dois links. Com o LACP, o tráfego é dividido com base no hash dos endereços de origem e destino.

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  |--------+
+----------+                   +------------+

Também pode ser feito com dois endereços IP, com o(s) aplicativo(s) lidando com a distribuição de tráfego. Isso seria semelhante a ter apenas dois hosts independentes na rede. (Pode exigir roteamento baseado em política para que o endereço IP de origem influencie a interface de saída usada.)

+----------+ 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  |--------+
+----------+                   +------------+

Observe que, embora os switches tenham endereços MAC, eles são usados ​​apenas para funções de controle e não são relevantes para o tráfego de dados. Os switches mantêm uma tabela dos endereços MAC de host que viram em cada porta e usam isso para encaminhar quadros de dados para os lugares certos. E os hosts apenas têm entradas de roteamento dizendo "tráfego para a rede N sai da interface I", ou "tráfego para a rede M é enviado para o roteador R via interface J", ou entradas de roteamento que também levam em consideração o endereço de origem. O host terá que usar ARP ou similar para descobrir o endereço MAC de destino, mas esse é o endereço MAC do host de destino , não o switch.

Além disso, "roteamento" é uma função de rede/IP/camada 3, não algo que um switch faz. Muda os quadros "para a frente", ou talvez apenas os "troque". (Eu ficaria feliz em usar o último, embora talvez alguns possam discordar.)

_{Não importa aqui se essas duas interfaces de rede estão em uma única placa (PCI / PCIe), em duas placas, integradas na placa-mãe ou conectadas via USB ou qualquer outra coisa. Apenas que são interfaces independentes completas, e não apenas conectores físicos alternativos para a mesma interface real. Por exemplo, muitos switches têm portas que possuem um conector de cobre e um soquete SFP, mas apenas um funciona de cada vez. E antigamente, uma placa de rede de 10 Mb/s geralmente tinha conectores para par trançado, Ethernet coaxial fina e D-15 AUI como alternativas.}

Nesta resposta, levo em consideração detalhes adicionais fornecidos nos comentários:

1. a topologia: (roteador--------------switch----------PC-----------switch------- ---roteador)

2. ambas as interfaces do PC estão configuradas na mesma sub-rede

Isto está errado.

O que acontece nesta configuração defeituosa (no Linux)?

A tabela de roteamento tem duas entradas para a mesma sub-rede, uma para cada interface e endereço IP de origem. Por exemplo:

# 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

Quando você tenta fazer ping em algum endereço nessa sub-rede, apenas a primeira interface é usada. Assim, você não pode alcançar o segundo roteador.

O PC aprende quais endereços MAC correspondem a um endereço IP transmitindo uma mensagem ARP. O alvo deve responder que tenho IP e meu endereço MAC é este. O PC manterá então uma tabela ARP com entradas que mapeiam IP, MAC e interface que o dispositivo respondeu.

O PC não se importa com a forma como a mensagem chega ao ponto final, desde que algum dispositivo comute o pacote para o seu destino.

A maioria dos switches tem um endereço MAC e mantém tabelas ARP. Eles encaminharão as solicitações ARP para todos os dispositivos conectados e também lembrarão de onde vem a resposta. Os hubs burros normalmente não teriam memória e continuariam transmitindo as mensagens em todas as direções.