Spanning Tree Protocol (STP) II

Na primeira parte deste artigo observamos alguns motivos da necessidade de se estabelecer um protocolo que permite evitar problemas em redes locais com redundancia.

O processo STP consiste nos seguintes processos:

Cada bridge (bridges/switchs) calcula o seu Bridge ID (BID): Que é composto pelo valor ox8000+Endereço_MAC. Note que é no sistema Hexadecimal. Quanto menor for o BID maior é a sua prioridade, isso significa que se você baixar o valor 0x8100 para um valor menor que este você atribuir maior prioridade ao bridge (bridges/switchs).

Eleição dum root bridge: No inicio todos os comutadores (bridges/switchs) assumem-se como root bridge. Para que se eleja um root bridge é necessaria a troca de informações entre os comutadores (bridges/switchs). Esta troca é realizada por meio do envio de pacotes BPDU (Bridge Protocol Data Unit) entre os comutadores.

Eleição das Designated Ports: As interfaces do Root Bridge sao Designated Port.

Eleição das Root Port: Cada bridge elege a interface cujo custo cumulativo (padrão IEEE) até ao Root Bridge seja menor.

O padrão IEEE define os custos das interfaces de acordo:

Bandwidth Cost
10 Mbps 100
16 Mbps 62
45 Mbps 39
100 Mbps 19
155 Mbps 14
622 Mbps 6
1 Gbps 4
10 Gbps 2

Vamos entender melhor o processo STP pela seguinte figura:

Supondo que existam 3 roteadores (A, B e C) com os seguintes BID:

A: 0x8000+aaaa.bbbb.ccca
B: 0x8000+aaaa.bbbb.cccb
C: 0x8000+aaaa.bbbb.cccc

No primeiro passo de eleição do root bridge todos os comutadores assumem-se como root bridge visto ainda nao terem trocado BPDUs.

No segundo passo de eleição C envia um BPDU para A e B. Como o BID de A e B sao menores em relação ao BID de C este continuam a assumir que sao o root bridge (lembre-se de que quanto menor o BID maior é a prioridade).

No terceiro passo de eleição B envia um BPDU para A e C. como o BID de B é menor em relação ao de C, C assume que o root bridge (ou root ID) é B. Para A entretanto o root bridge (ou root id) continua a ser o BID de A visto que é menor em relação ao de B e ao de C.

No quarto passo de eleição A envia uma BPDU para B e C. Como B e C possuem BIDs menores em relação a A estes assumem que A é o root bridge e A naturalmente já sabe que é o root bridge.

O processo seguinte consistem em atribuir as interfaces um determinado estado para garantir que nao exista redundancia. Os seguintes estados sao possiveis:

Disabled, Blocking, Listening, Learning, Forwarding.

Elegido que está o root bridge resta eleger as Designated Ports (DP). Isso é importante porque as DP estao sempre no estado de encaminhamento. Como o root bridge já está eleito sabe-se que as portas do root bridge sao DP.

Resta apenas a eleição das Root Port (RP). As RP sao as portas dos nao root bridge cujo custo para o rot bridge seja mais baixo. As vezes o custo de 2 ou mais segmentos pode ser igual, neste caso recorre-se a  id das portas e slot das interfaces sempre levando em conta que o mais baixo leva a maior prioridade.

No exemplo acima para A como root bridge foram eleitos as interfaces 3/1 e 3/2 como DP. Para B 3/1 é a RP (mesmo por logica percebe-se que atravez de 3/1 uma frame chega mais rápido a A do que por 3/2). Para C 3/1 é eleita como RP apesar de (suponhamos) ter o mesmo custo (padrao IEEE) que a interface 3/2. Como dissemos conta o custo cumulativo e mesmo que o custo cumulativo fosse igual a interace 3/1 tem prioridade.

Por fim todas as portas que nao estao no estado DP ou RP sao colocadas no estado Bloqued para evitar os problemas em redes redundantes. Alternate (visto na figura acima) é uma port role para o protocolo RSTP. Ela é semelhante a port role bloqued do STP.

Anúncios

Distribuição de rotas default

A distribuição de rotas default é bastante importante dado que diminui a necessidade de se estabelecer rotas default em outros segmentos da rede. Os protocolos IGP possuem instruções diferentes para distribuição de rotas default:

Estabelecimento duma rota default:

>ip route 0.0.0.0 0.0.0.0 interface_saida
ou
>ip route 0.0.0.0 0.0.0.0 endereco_proximo_salto

Distribuição com protocolo RIP

>default-information originate

Distribuição com protocolo OSPF

>default-information originate

Distribuição com protocolo EIGRP

>redistribute static

O AngoLinux ainda nao “morreu”

Nunca fui um cetico em relação a adoção do AngoLinux a distribuição Angolana patrocinada pelo CNTI e baseada no Mandriva. A dada altura quando ainda era estagiario do CI/UCAN chegamos mesmo a testa-lo e o Msc Joao Leao chegou mesmo a propor que se estudasse a sua adoção no parque de maquinas do Polo Palanca. Apenas tinha um senão: Falta de suporte a hardware de 64 bits. (nao sei se já suporta) Todas as maquinas da UCAN sao 64 bits e por isso adota-se por lá (mais como uma tradição que já encontrei) o Fedora.

O AngoLinux nao deixa de ser uma distro interessante justo por se basear no Mandriva, distro que confesso nunca ter explorado mas que pelo que se diz é bem estavel.

Na verdade o AngoLinux tem sido instalado em varias instituições do país (consultar link) com maior relevancia para o sector da educação que sofre com os pesados valores das licenças do pessoal da Microsoft, o que significa haver maior margem de manobra no uso desta distro que sim, necessita de ser mais divulgada do que tem sido, porque é uma distro interessante lá isso é.

Nexus One: Um fracasso?

Nao sei se quando a google decidiu lançar o Nexus One imaginou como um produto de grande sucesso. A verdade é que os numeros anda muito aquem do esperado, muito mesmo, uma completa desilusão, um fracasso de vendas. Diz-se aí a surdina que o produto é bom é poderoso, entao o que falhou? Marketing? O google sabe fazer isso muito bem. Falta de pre-divulgação? Erro no modelo de vendas? Só eles podem dizer.

Leia mais sobre o assunto em:

http://applemania.info/?p=5095

O protocolo DHCP em roteadores Cisco I

Embora estejamos habituados a configurar servidores DHCP em estações (e isso é o recomendavel) a verdade é que também o mesmo pode ser feito a partir de roteadores Cisco.

A Cisco define o processo de DHCP (Dynamic Host Configuration Protocol) de 2 formas:

Alocação automatica – Atribuição dum endereço IP de forma permanente.

Alocação dinamica – Atribuição dum endereço IP temporariamente ou até o usuario requisitat um novo

Alocação manual –  O administrador atribui manualmente um endereço ao usuario e o DHCP trata apenas de atribuir outras configurações.

O processo de aquisição dum endereço IP por parte dum computador cliente passa pelas seguintes fases:

O cliente envia um frame broadcast DHCPDISCOVER. O roteador responde com um pacote unicast DHCPOFFER. O cliente envia um frame broadcast DHPREQUEST. O roteador responde com um pacote unicast DHCPACK ou seja um pacote ack , conforme mostra a figura acima.

Na figura abaixo é representado um diagrama simples de rede onde um servidor dhcp realiza o alocamento dos recursos de rede (endereços IP, default gateway, mascara de subrede, dominio etc) aos hosts locais:

O roteador possui a sua interface com fa 0/1 com o endereço 10.1.1.1/24. a configuração que deve ser realizada segue abaixo:

Prevenir que o endereço 10.1.1.1 e 10.1.1.20 (default gateway e dns) nao sejam alocados:

>ip dhcp excluded-address 10.1.1.1
>ip dhcp excluded-address 10.1.1.20

Criar uma Pool de endereços para ser alocado a rede local. Definir o tamanho de endereços da rede local, o default-gateway (default-router) o servidor dns e o nome de dominio:

>ip dhcp pool SNNANGOLA-REDE10
 >network 10.1.1.0 255.255.255.0
 >default-router 10.1.1.1
 >dns-server 10.1.1.20 173.1.1.1
 >domain-name snnangola.com

Em alguns casos também pode ser definido o lease time ou tempo de emprestimo de recursos de rede a um determinado host requisitante. tal pode ser feito por meio do comando lease das opções da pool de endereços:

>lease {dias [horas] [minutos] | infinito}

Tela azul trama TPA

Se estiveram atentos ao Telejornal da TPA no dia 08/03/2010 notaram que no fim da edição pelo menos duas das telas do cenario multimedia que ficam atrás do apresentador, deram um pane conhecido como tela azul.

É uma partida já conhecida do sistema operacional Windows que quando está ‘cansado’ nao se coíbe de tirar uma ‘soneca daquelas’ que só mesmo uns ‘tapas’ no botao reset ou on/off do computador resolve.

Recorde-se que a TPA tem estado a passar por um processo de renovação técnica e do pouco que eu sei também é uma boa usuaria dos sistemas Macintosh.

Spanning Tree Protocol (STP) I

O Spanning Tree Protocol (STP) definido pelo padrão IEEE 802.1d é um protocolo criado com objectivo de se evitar loops de camada 2 (redes locais).  As vezes os servidores travam, a rede fica instavel, os endereços IP nao sao alocados, os sistemas de gestão bloqueiam, as impressoras de rede para de imprimir  e lá vem a desculpa habitual da falta de sistema e toca a reiniciar tudo, como se nao existisse lógica naquele comportamento anómalo.
Bom, como iamos dizendo, a necessidade de se implementar o protocolo STP é mesmo importante em se tratando de redes criadas pela lógica de 3 camadas, a saber, acesso, distribuição e core como mostra a figura abaixo:

Uma infra como a apresentada acima representa uma implementação com links redundantes entre as 3 camadas. Esta configuração é a mais básica e correcta, mas como tal acarreta consigo os seguintes problemas:

1 –  Tempestades de Broadcasts

Ocorre quando cada switch numa rede redundante dispara frames interminantemente. Todas as portas recebem o broadcast menos a porta que enviou.

Na figura acima o host A pretende enviar uma informação para o host B. tanto o bridge A como o bridge B recebem a frame. Adicionam o endereço do host A a tabela MAC. Como o endereço MAC do host B nao consta da tabela de ambos briges (A e B) um broadcast é enviado para todas as interfaces, menos a interface do host A, fazendo com que o bridge B realize outra vez um broadcast (Tempestade de broadcast, porque o bridge A recebe um broadcast do B e o processo continua assim mesmo que o host B tenha recebido já a mensagem).
Continuando, o host B responde ao broadcast  e os bridges A e B aprendem o seu endereço e adicionam a tabela MAC. A tabela ARP do host A é preenchida duas vezes com o endereço MAC do host B. Desta vez a mensagem é encaminhada directamente para o host B, nao por meio dum unico bridge como seria normal mas por meio de 2 bridges originando então o problema abaixo:

2 – Transmissão multiplas de frames

Ocorre quando um dispositivo recebe a mesma frame mais de uma unica vez por meio de unicast. Muitos protocolos nao estão preparados para ‘entender’ isso.

3 – Instabilidade nas tabelas MAC

A instabilidade no conteúdo das tabelas MAC resulta em copias da mesma frame serem distribuidas em diferentes portas do mesmo switch.

No proximo artigo veremos que solução existe para estes problemas.