:: Redes de Computadores | Cursos | Certificações | Dicas | Notícias | Tutoriais | Nossas Experiências ::
Acesse via RSS/Feeds: http://netfindersbrasil.blogspot.com/feeds/posts/default
Siga-nos no X: https://x.com/NETFINDERSBR
3 de ago. de 2009
Capitulo 2 - Spanning-Tree ToolKit
Ufa !!! Este post deu trabalho !!!
Estudando no capitulo 2 do material de ARCH, Alta disponibilidade na camada 2, me deparei com um conteúdo abordado na prova de BMSN --> Spanning-Tree !!!
Uma rápida revisão:
Spanning-Tree Protocol evita a ocorrência de loops na camada 2, elegendo um Switch como Root Bridge e mantendo ativos apenas os links que formam o melhor caminho para esta raiz, deixando os caminhos redundantes bloqueados.
Podemos ter um único processo STP rodando para todas as VLANs (Commom STP), um processo STP independente para cada VLAN (Per VLAN STP) ou um processo STP para múltiplas VLANs (Multiple STP).
Neste Post, tratamos do PVSTP (padrão Cisco)e as maneiras de tornar o protocolo mais eficiente, com os recursos chamados de Spanning-Tree ToolKit.
A maior critica ao STP original é a sua lentidão. Para remover uma interface do estado blocking para forwarding, os seguintes timers são usados:
20 segundos de Blocking para Listening (Max-age Timer)
15 segundos de Listening para Learning
15 segundos de Learning para Forwarding (Forward Delay)
Para minimizar o problema, a Cisco criou duas "gambiarras":
UplinkFast: esta feature se baseia na definição de um "Uplink Group" através do qual é escolhida imediatamente uma nova root bridge, economizando os 30 segundos gastos no Forward Delay.
BackBoneFast: quando ocorre uma falha num link indireto, não conectado diretamente ao Switch local, este se declara o novo Root Bridge e demora até 20 segundos (Max-Age) para que o caminho para a verdadeira raiz seja descoberto. BackboneFast elimina este tempo.
Para sanar definitivamente este enorme delay no aprendizado das alterações na topologia do PVSTP, o IEEE criou o Rapid Spanning-Tree (RPVSTP).
Nesta nova versão, existem apenas 3 estados (discarding, learning e forwarding) e as features do UplinkFast e BackBoneFast já foram incorporadas.
Tanto no PVSTP quanto no RPVSTP entretanto, existem falhas que necessitam de configurações adicionais para serem sanadas.
Estas falhas se baseiam no comportamento das interfaces quando do recebimento ou não das BPDUs (Bridge Protocol Data Units) uma espécie de protocolo de hello que anuncia as mudanças de Topologia a cada 2 segundos, por padrão.
LoopGuard: Imagine o que aconteceria se uma interface em estado blocking parasse de receber BPDUs de um vizinho, isto poderia ocorrer devido a uma falha no link tornando-o unidirecional (o vizinho continuaria a enviar BPDUs, mas a interface diretamente conectada não consegue receber). A interface iria para o estado de Forward e criaria um looping de camada 2.
Para sanar isto, o recurso de LoopGuard coloca a interface que não está recebendo as BPDUs num estado chamado de "Inconsistent STP", similar ao estado Blocking, evitando que o Loop ocorra.
RootGuard: Definir qual será a Root Bridge pode ser manipulado alterando-se a prioridade do Switch (quanto menor a prioridade, maior a chance de ser Root). Mas se um novo Swtch for acrecentado com uma prioridade menor, ou com prioridade igual ao Root Bridge atual, mas com um MAC address menor. Este novo Switch se tornaria a raiz e alteraria toda a topologia atual.
Para evitar isso, as portas que possam interligar estes novos Switches devem ter configurado o recurso de RootGuar, que coloca estas interfaces num estado de "Root Inoonsistent", similar ao estado de Learning, que impede a mudança de topologia, voltando depois a interface para o estado forward.
BPDUGuard : Este recurso está ligado a configuração do Spanning-Tree PortFast, que geralmente é aplicado a interfaces de acesso (que conectam Servidores e Estações de Trabalho) e faz com que estas interfaces permaneçam em Forward.
Quando uma destas portas recebe BPDUs (por exemplo, de uma estação Linux que emula o funcionamento de uma Bridge) isto pode alterar a topologia da Rede. Para evitar isto, o recurso BPDUGuard desativa a interface colocando-a em ERRDISABLE. (depois será necessário ativar a interface manualmente).
Isto resume muito superficialmente os recursos que formam o SpanningTree ToolKit. Para saber como configura-los, acesse os links abaixo relativos ao material no Cisco.com:
LoopGuard
RootGuard
BPDUGuard
UpLinkFast
BackBoneFast
PortFast
Assinar:
Postar comentários (Atom)
Um comentário:
Olá amigos,
Parabéns Adilson pelo ótimo resumo sobre spanning-tree. Pessoalmente, considero este tema um tanto complexo, talvez por ter tido uma evolução construída em cima de consertos, adaptações e como você bem colocou: “gambiarras”... Mas o que achei mais legal foi a figura indicando onde devem ficar o loopguard, o rootguard, o uplinkfast, o bpdu guard... perfeita!
Um abraço,
Sandro Leite.
Postar um comentário