Como os Switches processam seus frames?

Olá!

Esse é um tópico bem curtinho mas não menos importante para entendermos os Swicthes. O básico do seu funcionamento já sabemos, mas o objetivo aqui é vermos cada vez mais profundamente suas características.

Entendendo essas formas de processamento podemos designar a melhor forma de operação para a nossa topologia e saber o que é mito ou não. hehe

Bom, preciso deixar claro que os termos usados se baseiam em Cisco, pois estou estudando para a CCNA, mas outros fabricantes possuem os mesmo conceitos podendo trocar alguns nomes...

Basicamente os Switches possuem três formas de processamento de frames:

- Store-and-Forward - A padrão em quase todos os switches.

- Cut-through - A que eu menos indico.

- Fragment-free - Bem inteligente.

Store-and-forward

Como já dito acima, esse é o padrão em quase todos os switches (pelo menos nos que conheço). Nesse formato de processamento o swicth irá trasmitir os frames para a porta de destino apenas quando todos os fragmentos desse frame chegarem no switch e forem analisados. É a forma mais segura e confiável para um switch trabalhar. Da para fazer uma analogia com um servidor proxy, o qual só retransmite o site para o destinatário depois que todos os frames chegam e o proxy consegue montar o pacote completo. A única desvantegem desse modo de processamento em relação aos outros é referente à latência. Como ele espera que todos os frames cheguem para depois transmitir isso pode causar uma pequena latência. Mas na prática isso não é problema hoje em dia, pois nossas LANs dificilmente atuam em toda sua capacidade e ainda assim temos velocidades bem altas.

Portanto, é a forma de processamento mais indicada para a maioria dos casos.

Cut-through

Essa é uma opção que na minha opinião não vale a pena. Em um frame ethernet o endereço MAC sempre vem bem no ínicio do frame (nos primeiros bytes). Em um swicth isso é mais do que necessário para ele tomar a decisão de que porta transmitir o frame. Assim que consegue ler o MAC de destino já começa a retransmitir os fragmentos desse frame. Isso causa uma latência realmente muito baixa na comunicação. Os frames serão restransmitidos assim que possível. O problema desse modo é que cada cabeçalho de frame possui um campo chamado FCS que fica mais ao final do cabeçalho. Esse campo tráz um hash de todo o frame no momento em que ele foi gerado. Na outra ponta o dispositivo calcula novamente esse hash e compara com o resultado que veio no campo FCS. Caso seja igual significa que o frame foi transmitido com sucesso e está íntegro. Caso contrário o frame foi corrompido no caminho.

Como nesse modo o Swicth nem chega a ler o campo FCS, o frame é retransmitido mesmo estando corrompido causando uma transmissão desnecessária e consequentemente perda de desempenho na comunicação. Na minha opinião não vale a pena esse ganho na análise do cabeçalho perdendo com transmissões corrompidas. NÃO recomendo.

Fragment-free

Esse é um kra legal. Considero um intermediário entre o Store-and-forward e o Cut-through.

Ele não espera todos os fragmentos e nem lê apenas o DST MAC. Na verdade ele espera os primeiros 64 Bytes de um frame, os quais contém todo o cabeçalho. Dessa forma ele consegue ler informações de MAC e ainda verificar a integridade do cabeçalho evitando a restransmissão de pacotes corrompidos. Talvez seria interessante em estruturas de Cluster sobre LAN.

Conclusão: Usar sempre que possível o primeiro modo - Store-and-forward - pois ele satisfaz praticamente todas as necessidades sem causar perdas consideráveis no desempenho da nossa rede. Na pior das hipóteses use o Fragment-free mas jamais o Cut-throug.

Abração!