O Protocolo Spanning-Tree - Parte 1

Introdução

Uma característica básica das redes derivadas da tecnologia Ethernet é a vulnerabilidade a loops de comutação. Um loop de comutação ocorre quando há uma ligação cíclica entre dispositivos, fazendo com que quadros sejam duplicados e/ou retransmitidos sem controle, até a exaustão dos recursos.

A proteção mais comum contra essa situação indesejável é o uso de alguma variante do protocolo Spanning-Tree (802.1d ou, também, STP). O objetivo desse protocolo é identificar as ligações cíclicas ("loops") na rede, e desativar seletivamente algumas das conexões.

O protocolo STP é usado em dispositivos que trabalham na camada 2 do modelo OSI (Enlace de Dados). Isso inclui as chamadas pontes de rede (bridges) e switches. Para efeito deste texto, usaremos sempre que possível o termo "bridge", mais geral.

Loops de comutação

Quando uma ligação cíclica é feita numa rede baseada em tecnologia Ethernet, sem que alguma proteção seja utilizada, ocorre o chamado loop de comutação. Ocorre que o cabeçalho do quadro Ethernet prevê apenas controles de origem, destino e tipo de conteúdo do quadro, não havendo nenhum controle capaz de determinar se ele já está trafegando na rede há tempo demais (como o campo TTL do cabeçalho IP).

Quando uma bridge recebe um quadro em uma porta, ela inclui o endereço de origem do quadro em sua tabela MAC, associado com a porta de origem, e em seguida consulta em sua tabela MAC se o endereço de destino do quadro é conhecido. Caso não seja, ou o quadro seja um quadro de broadcast, a bridge copia o quadro para todas as portas ativas (exceto a porta por onde o quadro foi recebido), num procedimento chamado encaminhamento por difusão.

Caso contrário, o quadro é copiado para a porta associada. Supondo que a rede está funcionando normalmente, esse quadro eventualmente chegará a seu destino, o que fará com que um quadro de resposta seja gerado. Esse quadro, ao retornar, terá os endereços de origem e destino invertidos com relação ao quadro original, e encontrará a tabela MAC preenchida com o endereço da estação que originou o primeiro quadro, permitindo certamente que ocorra encaminhamento direto. Ao mesmo tempo, a porta onde o segundo quadro é recebido é anotada e associada ao endereço de destino, permitindo que nas próximas trocas de quadros, não seja mais necessário fazer o encaminhamento por difusão.

Vídeo: Encaminhamento normal de quadros

O problema é que, devido ao encaminhamento por difusão, pode ocorrer que algumas das cópias do quadro sejam encaminhadas de volta para a mesma bridge, seja pela mesma porta, seja por outras. E como o protocolo Ethernet não controla o tempo de vida do quadro, cada uma dessas cópias será novamente encaminhada, num processo sem fim --- um loop. Isso consome banda de rede e capacidade de processamento da bridge, o que já é ruim. Mas pode piorar!!!

Quando o quadro duplicado é unicast (um quadro destinado a exatamente um endereço de destino), eventualmente a bridge vai aprender para onde deve enviar esse quadro, e o loop vai se resolver sozinho, ficando apenas o gasto de recurso. Mas quando o quadro é de broadcast (ou seja, destinado a todas as máquinas da rede), o loop nunca será desfeito, e, pior, de acordo com a quantidade de ligações cíclicas ativas, ele pode ser multiplicado de forma exponencial e explosiva, gerando uma situação chamada tempestade de broadcast. Nessa hora, a rede fica totalmente tomada, incapaz de transmitir dados legítimos, e você não vai conseguir acessar a configuração das bridges para recuperar o controle. Perdeu, playboy.

Vídeo: Tempestade de Broadcasts

Um pensamento simples seria: se a ligação cíclica cria esse tipo de problema, então é simples: basta não fazer ligações cíclicas! Não, como diria Murphy, nada é tão simples como parece. Às vezes, ligações cíclicas são desejáveis. E às vezes, você pode fazer uma ligação cíclica sem perceber.

Em que situação é desejável ter uma ligação cíclica? Por exemplo, quando você quer oferecer redundância de caminhos dentro de sua rede. Imagine que você tem uma rede entre duas casas, um switch em cada casa, e um cabo de rede ligando esses dois switches (por favor, nada de "varal de rede" --- faça uma infraestrutura decente...). O que acontece se esse cabo oxida, ou rompe? Você fica sem interligação entre as duas casas, até que conserte o cabo, ou instale um novo.

Pra não ter que esperar, você simplesmente instala dois (ou três, ou quatro) cabos entre os dois switches. Se um deles quebrar, você ainda tem o(s) outro(s). Pronto, você fez uma ligação cíclica, de propósito. E você quer (talvez precise) que ela funcione, dia e noite, sem precisar conectar e desconectar cabos.

Outra situação, o faixineiro está limpando a sala de telecomunicações, quando esbarra em um cabo, derrubando-o. Instintivamente, ele vai pegar o cabo, e conectá-lo de volta no primeiro lugar onde ele encaixe (de boa fé!!!). O que ele não sabe, é que a outra ponta desse cabo já está ligada no mesmo switch (ou em algum outro da sala). Pronto, uma ligação cíclica fechada sem intenção.

Seja qual for o motivo da ligação cíclica, você quer (1) ser capaz de identificar se ela ocorreu; (2) ser capaz de "abrir" esse ciclo, impedindo o loop de comutação; e (3) quer que isso ocorra automaticamente. É aí que entra o protocolo Spanning-Tree (STP) e suas variantes, que começamos a ver no próximo artigo da série.

Até lá.