Espelhamento de Discos em Servidores Debian GNU/Linux

Olá Pessoal,

Uma prática bastante comum em servidores é a combinação de múltiplos discos físicos em arranjos lógicos denominados RAID (Redundant Array of Independent Discs), principalmente para fins de disponibilidade dos dados aramazenados em mais de um disco e também para fins de desempenho, uma vez que dados armazenados em múltiplos discos implicam em maior velocidade de leitura. 

Há diversas modalidades de RAID, sendo a mais simples delas o RAID-1 que faz o espelhamento de discos, ou seja, mantém em um segundo disco físico uma cópia exata do primeiro disco físico. Em caso de falha de um dos discos, o conteúdo continua disponível através do outro disco e o administrador pode providenciar a troca do disco defeituoso para que haja sincronização total do conteúdo no novo disco.

O RAID normalmente é implementado através de hardware, sendo gerenciado por uma controladora de discos que pode ser configurada através da BIOS (ou UEFI) da máquina antes mesmo do início de instalação do sistema operacional. Essa é a opção mais recomendada porque apresenta melhor desempenho, no entanto só está disponível em hardware particularmente desenvolvido para servidores. Como o Linux se trata de um sistema operacional aberto e gratuito, ele acaba sendo a opção natural em ambientes menores que não têm recursos para aquisição de hardware adequado para seus servidores. Nesses casos, frequentemente são utilizados computadores tradicionais que não possuem hardware apropriado com uma controladora que suporte a implementação de RAID na BIOS/UEFI.

Apesar dessa limitação de equipamento, a boa notícia é que também existe a opção de configurar o RAID por software através dos sistemas operacionais modernos, ainda que o desempenho seja pior que a solução profissional implementada por hardware. Especificamente no caso do Debian GNU/Linux, a configuração de RAID pode ser facilmente implementada durante o próprio processo de instalação do servidor, desde que a máquina tenha pelo menos dois discos físicos.

A configuração de RAID-1 na instalação do Debian consiste basicamente em criar partições idênticas nos dois discos físicos e em marcá-las com o rótulo "physical volume for RAID", ao invés de escolher um sistema de arquivos (figura 1). Depois disso é possível acessar a opção "Configure Software RAID" na própria ferramenta de particionamento do Debian e selecionar as duplas partições que serão agrupadas em RAID-1. Ao terminar de criar os agrupamentos, será possível observar o(s) novo(s) disco(s) lógico(s) do RAID na tabela de partições, onde o administrador deverá fazer a indicação do sistema de arquivos e dos pontos de montagem (figura 2).

Figura 1. Indicação de RAID em 2 Discos Físicos (Antes)

Figura 2. Particionamento de Disco Lógico RAID-1 (Depois)

A implementação do RAID-1 na instalação do Debian GNU/Linux é bastante simples, mas como lidar com o sistema operacional em caso de falha de um dos discos? Como fazer a inserção do novo disco no arranjo lógico e sincronizar os dados em ambos os discos? O objetivo desse artigo é listar as ações necessárias para recompor o RAID em caso de falha de um disco. 

Consideremos um servidor que possui dois HDs (/dev/sda e /dev/sdb) arranjados em RAID-1, cada um deles contendo 3 partições com capacidade de armazenamento apenas simbólica conforme apresentado nas figuras acima. Abaixo trago novamente o esquemático das partições:

/dev/sda1 > +/- 0.6 GB (SWAP)

/dev/sda2 > +/- 7.0 GB (/)

/dev/sda3 > +/- 1.0 GB (/home)

/dev/sdb1 > +/- 0.6 GB (SWAP)

/dev/sdb2 > +/- 7.0 GB (/)

/dev/sdb3 > +/- 1.0 GB (/home)

O RAID-1 de ambos os HDs foi configurado durante o processo de instalação do servidor Linux Debian, através da ferramenta de partição do próprio instalador (na opção Configure Software RAID), dando origem aos seguintes arranjos lógicos do tipo multi-disk (/dev/mdX):

/dev/md0 = /dev/sda1 + /dev/sdb1 (SWAP)

/dev/md1 = /dev/sda2 + /dev/sdb2 (/)

/dev/md2 = /dev/sda3 + /dev/sdb3 (/home)

Enquanto os discos estão operando normalmente, o arranjo lógico dos discos físicos em RAID-1 será responsável por realizar o espelhamento de todo o conteúdo armazenado no primeiro disco também no segundo disco, garantindo que sempre exista uma cópia de segurança dos dados. Caso haja pane em qualquer um dos discos, será necessário repor fisicamente o HD defeituoso e inserí-lo manualmente no arranjo lógico do RAID-1 para que todo o conteúdo do disco em operação possa ser sincronizado novamente no novo HD. 

Por exemplo, em caso de pane no segundo HD (/dev/sdb) será necessário:

1) Reparticionar o novo HD (/dev/sdb) com o mesmo esquema do disco em operação (/dev/sda)

root@Linux:/# sfdisk -d /dev/sda | sfdisk /dev/sdb

Feito isso, é sempre prudente verificar se o novo HD possui as mesmas partições do original:

root@Linux:/# fdisk -l /dev/sda

root@Linux:/# fdisk -l /dev/sdb

2) Adicionar as partições do novo HD (/dev/sdX#) ao RAID (/dev/mdX):

root@Linux:/# mdadm --manage /dev/md0 --add /dev/sdb1 

root@Linux:/# mdadm --manage /dev/md1 --add /dev/sdb2

root@Linux:/# mdadm --manage /dev/md2 --add /dev/sdb3

Feito isso, é possível verificar que o RAID será ressincronizado (espelhamento dos discos), de forma que o novo HD seja preenchido com uma cópia exata do conteúdo armazenado no HD original:

root@Linux:/# cat /proc/mdstat

Personalities : [raid1]
md2  :  active raid1 sda3[0] sdb3[1]
        965056 blocks super 1.2 [2/2] [UU]

md1  :  active raid1 sda2[0] sdb2[1]
        6832128 blocks super 1.2 [2/2] [UU]

md0  :  active (auto-read-only) raid 1 sda1[0] sdb1[1]
        584128 blocks super 1.2 [2/2] [UU]

A saída exibe o status de cada arranjo lógico do tipo multi-disk, sendo que o conteúdo dos colchetes destacados em amarelo exibem o status individual de cada um dos discos físicos. Por exemplo, a saída [UU] indica que ambos os HDs estão em operação, enquanto que a saída [U_] indicaria que o segundo disco físico não está em operação. 

Façam seus testes...

Samuel. 

Configuração de Ether-Channel e Trunk em Roteadores Cisco

Olá Pessoal,

Assim como a configuração de agregação de interfaces físicas é uma prática comum em links tronco (trunk) de switches para fins de disponibilidade e balanceamento de carga, essa mesma configuração é igualmente importante em roteadores que fazem roteamento inter-VLAN. Para exemplificar a configuração de uma agregação de links em roteadores Cisco, utilizarei o cenário apresentado na figura abaixo em que é necessário configurar roteamento inter-VLAN entre duas sub-redes compostas por máquinas de duas VLANs diferentes, de maneira similar ao exemplo que trago no Lab06 (intitulado Configuração de Switches e VLANs) do livro Laboratórios de Tecnologias Cisco.

A diferença é que no laboratório do livro o roteador está conectado ao switch através de uma única interface física, enquanto que nesse exemplo será configurada uma agregação lógica em duas interfaces físicas do roteadores. Essa prática não só é recomendada para fins de disponibilidade em caso de falha de um dos links, mas também para obter melhor desempenho porque múltiplas VLANs estão atreladas a um único trunk entre o switch e o roteador naquilo que chamamos de router on a stick. 

Nas linhas abaixo trago as configurações necessárias no roteador para que o roteamento inter-VLAN funcione no cenário proposto, com destaques em amarelo para aqueles comandos que remetem à configuração da agregação propriamente dita. 

Router# configure terminal

Router(config)# interface port-channel 1

Router(config-if)# exit

Router(config)# interface range g0/0 - 1

Router(config-if-range)# channel-group 1

Router(config-if-range)# no shut

Router(config-if(range)# exit
Router(config)# interface po1.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 192.168.10.254 255.255.255.0
Router(config-subif)# exit
Router(config)# interface po1.20
Router(config-subif)# encapsulation dot1q 20
Router(config-subif)# ip address 192.168.20.254 255.255.255.0
Router(config-sub-if)# exit 

Router(config)# 

Para completar esse laboratório, abaixo trago as configurações do switch:

Switch# configure terminal

Switch(config)# vlan 10
Switch(config-vlan)# name VERDE
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name VERMELHO
Switch(config-vlan)# exit
Switch(config)# interface range f0/1 - 3
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# exit
Switch(config)# interface range f0/4 - 6
Switch(config-if-range)# switchport access vlan 20
Switch(config-if-range)# exit
Switch(config)# interface range g0/1 - 2
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# channel-group 1 mode on
Switch(config-if-range)# exit
Switch(config)# 

Façam seus testes...

Samuel. 

Configuração de Suporte a Multicast em Switches Catalyst

Olá Pessoal,

A maioria das aplicações existentes em uma rede de computadores segue o modelo de comunicação cliente/servidor, ou seja, através de uma comunicação unicast (de um para um) onde os pares envolvidos sempre são uma estação cliente e outra estação servidora. No entanto, também podem existir aplicações de natureza multicast com comunicação de um para muitos, por exemplo quando existe um servidor de origem responsável por gerar conteúdo de interesse de múltiplas estações clientes (não de todas). Alguns exemplos comuns de serviços de natureza multicast são: clusterização de servidores, treinamentos online via telepresença, soluções de vigilância com câmeras IP, ferramentas de monitoramento distribuído, aplicações multimídia (áudio/vídeo), etc...

Quando existe alguma aplicação de natureza multicast na empresa é necessário preparar a infraestutura de switches para lidar de maneira apropriada com esse tipo de tráfego para otimizar sua propagação, caso contrário os switches simplesmente irão encaminhar todo o tráfego de maneira broadcast para todas as suas interfaces, oferecendo desempenho ruim porque gera mais tráfego nos links da infraestrutura. Qualquer endereço desconhecido por um switch em sua tabela MAC que não possa ser propagado para um destinatário de maneira unicast (uma única interface) ou que não tenha sido configurado com o vínculo de portas em grupo para ser propagado de maneira multicast (múltiplas interfaces) faz com que a propagação do tráfego ocorra de maneira broadcast (para todas as interfaces).

Para exemplificar o procedimento de configuração do suporte a multicast nos switches Catalyst da Cisco, a figura abaixo ilustra um cenário com dois switches que fazem parte da infraestrutura de um ambiente qualquer. Nesse ambiente existe uma aplicação multicast originando conteúdo, além de 3 estações diretamente interessadas no consumo do conteúdo da aplicação servidora, ou seja, esse exemplo caracteriza uma comunicação multicast de um para muitos. 

Por padrão os switches Catalyst vem ativados com o recurso IGMP Snooping, o que permite que os grupos multicast sejam automaticamente detectados na rede através do protocolo IGMP, sem nenhuma configuração. No entanto, se não existir um roteador multicast que seja responsável por enviar queries IGMP na rede para indagar quais máquinas conectadas em quais portas dos switches têm interesse em formar um grupo multicast, então não é possível tirar proveito do recurso IGMP de maneira dinâmica sem nenhuma configuração nos switches da infraestrutura.

Obs.: Caso o leitor tenha interesse na configuração de um roteador multicast, recomendo a leitura de outros artigos no blog que abordam os protocolos PIM-DM e PIM-SM de roteamento multicast.

Nesse exemplo em que não existe um roteador multicast, há duas possíveis soluções para configurar os grupos multicast diretamente nos switches: (1) através do recurso IGMP Querier que é suportado apenas em alguns switches mais novos ou (2) através da configuração manual de quais portas representam um grupo para uma determinada aplicação.

A configuração do querier IGMP Querier nos switches é bastante simples:

Switch-A(config)# ip igmp snooping querier

Switch-B(config)# ip igmp snooping querier

Caso os switches não tenham suporte ao recurso anterior, a solução é fazer o mapeamento manual das interfaces que pertencem a um grupo multicast. É importante saber que no IPv4 todo tráfego destinado para o intervalo de endereços que varia de 224.0.0.0 até 239.255.255.255 (Classe D) representa um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 01:00:5E:XX:XX:XX, sendo que o final representa os últimos 23 bits do endereço IPv4 (RFC 1112). Toda máquina que é origem de tráfego multicast encaminha seu conteúdo para um endereço IP multicast da Classe D que representa um grupo.

Obs.: É igualmente importante saber que no IPv6 os endereços iniciados em FF00::/8 representam um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 33:33:XX:XX:XX:XX, sendo que o final representa os últimos 32 bits do endereço IPv6 (RFC 2464).

Essa lógica de agrupamento é implementada através das próprias aplicações servidora e cliente, ou seja, a aplicação servidora utilizará um endereço multicast para alcançar seus receptores, sendo que esse endereço pode estar fixado na lógica da aplicação ou pode ser configurado pelo usuário. Por sua vez, as aplicações clientes ingressam a máquina receptora no respectivo grupo multicast por meio da configuração automática de um endereço IP de multicast sem que o usuário tenha que fazer essa configuração de endereçamento indivualmente em cada máquina receptora. Dessa forma a máquina cliente passa a responder por 2 endereços IP, sendo um endereço unicast configurado pelo administrador (manualmente ou via DHCP) e outro endereço multicast automaticamente configurado pela aplicação cliente.

No exemplo proposto o endereço multicast utilizado pela aplicação servidora para alcançar os receptores é 239.239.239.239, de forma que o respectivo MAC multicast será 01:00:5E:6F:EF:EF. A configuração manual consiste em informar no switch da esquerda que as interfaces f0/1, f0/3 e g0/1, onde estão conectados dois receptores e um switch que possui outro receptor, devem ser associadas com o endereço MAC da aplicação multicast (01:00:5E:6F:EF:EF). Da mesma forma, no switch de direita basta informar que a interface f0/1 possui um receptor conectado e associá-la com o MAC da aplicação multicast. Os comandos necessários para realizar o mapeamento estático são listados abaixo:

Switch-A(config)# mac address-table static 0100.5e6f.efef vlan 1 interface g0/1 f0/1 f0/3

Switch-B(config)# mac address-table static 0100.5e6f.efef vlan 1 interface f0/1

Fica visível que o mapeamento manual das interfaces dos switches que pertencem a um determinado grupo multicast não é muito viável em ambientes grandes que possuem vários grupos multicast, ou seja, não é nada escalável. No entanto, se o ambiente é menor e não possui um roteador multicast ou se os switches não possuem suporte ao recurso querier do IGMP, então o mapeamento manual é a opção remanescente. 

Façam seus testes...

Samuel.

Gerenciamento e Monitoramento de Redes

Olá Pessoal.

Parte das tarefas do profissional de TI é a resolução de problemas técnicos na rede de computadores, ou seja, a correção de um problema assim que ele ocorre. Porém, como em outras situações, a prevenção é melhor do que a correção, por isso é importante monitorar o ambiente. Além disso, uma rede de grande porte não pode ser gerenciada unicamente pelo esforço humano e requer o uso de ferramentas automatizadas para fazer o monitoramento dos dispositivos da infraestrutura. 

Compartilho abaixo uma série recentemente produzida pelo NIC.br com vários vídeos didáticos sobre gerenciamento de redes, onde são abordados tópicos que contemplam desde boas práticas de gerenciamento, até ferramentas de monitoramento baseadas no protocolo SNMP.

Samuel.

Tecnologia StackWise em Switches Catalyst 3750-X

Olá Pessoal.

Recentemente escrevi sobre a tecnologia StackPower suportada pelo Switch Cisco Catalyst 3750-X para melhor gerenciamento e redundância da fonte de energia elétrica (veja aqui). Nesse artigo vou discorrer brevemente sobre outra importante tecnologia suportada pelo Catalyst 3750-X para fins de empilhamento, denominada StackWise. Antes de detalhar o assunto, cabe destacar que essa tecnologia não é suportada pelos modelos Catalyst 3560-X, afinal esses equipamentos são "standalone", ou seja, não suportam empilhamento.

A principal vantagem do Switch Cisco Catalyst 3750-X é que esse equipamento é "stackable", ou seja, empilhável, o que permite que até 9 desses equipamentos sejam empilhados, de modo que em ambientes de médio porte é possível que esse modelo seja utilizado na composição do núcleo da rede (collapsed core), responsável pela agregação dos demais switches de acesso.

A tecnologia StackWise permite o empilhamento de vários switches utilizando um cabo próprio para esse fim que permite interconexão a 16Gbps ou 32Gbps. A partir dessa ligação os equipamentos físicos ficam equivalentes a um agrupamento lógico único (cluster), sendo que é eleito um switch mestre para gerenciar o empilhamento. Dois switches, por exemplo, podem ser interligados sem redundância através de um único cabo StackWise, no entanto a recomendação é que eles sejam interligados através de dois cabos em topologia de anel. A topologia de anel é recomendada para qualquer que seja a quantidade de switches empilhados, uma vez que provê maior largura de banda (32 Gbps) e redundância no que diz respeito à possibilidade de falha em um dos cabos stack.

Fonte: Cisco Systems (www.cisco.com)

Fonte: Cisco Systems (www.cisco.com)

São várias as vantagens dessa prática, a destacar a excelente escalabilidade da solução por permitir que novos switches físicos sejam incorporados ao agrupamento lógico (expansão de portas). As vantagens do StackWise não param por aí, afinal essa tecnologia também implica em simplificidade de configuração, uma vez que o elemento configurado passa a ser o grupo lógico ao invés de todos os equipamentos individuais. Todos os switches do empilhamento compartilham as mesmas informações de configuração e controle, de modo que é possível a inserção e remoção de novas unidades a qualquer momento sem interrupção da operação.

Outras vantagens são maior redundância do sistema (alta disponibilidade) e a possibilidade de criar agregações de links (etherchannel) em portas de dois ou mais dispositivos físicos, processo ilustrado na figura abaixo e muito útil (também vale dizer fantástico)! Algo parecido com isso só podia ser feito na família Catalyst 6500 de switches de grande porte, por meio da tecnologia VSS (Virtual Switching System). Com o suporte ao StackWise na família Catalyst 3750-X, essa possibilidade passa a ser viável também em ambientes de médio porte.

Obs.: Ao leitor interessado em mais informações sobre a tecnologia VSS no Switch Catalyst 6500, sugiro a leitura de outro artigo publicado no blog intitulado "VSS no Agrupamento Lógico de Switches de Agregação". 

Vamos exemplificar os procedimentos inciais de configuração de um empilhamento em um ambiente de médio porte, cuja rede possui seu núcleo colapsado através de dois Catalyst 3750-X. Depois de feitas as ligações físicas entre os switches através dos cabos adequados em topologia de anel, é importante ter certeza que ambos os equipamentos possuem a mesma versão do IOS neles instalados. A formação do agrupamento lógico (empilhamento) é automática, sendo que um dos switches será eleito a unidade mestre e outro a unidade subordinada.

O usuário pode configurar um valor de prioridade para cada switch com o intuito de determinar qual deles irá assumir o papel de mestre. Caso o administrador não faça configuração nenhuma o critério para seleção do mestre será:

1. O switch que tiver o IOS com suporte a recursos mais avançados;
2. O switch que estiver há mais tempo em operação (runtime);
3. O switch que tiver o menor MAC.

Assim, por padrão, o primeiro switch em operação será eleito mestre, informação que pode ser visualizada através do comando "show switch". Apesar desse comportamento automático, é sempre importante selecionar a prioridade de todos os switches manualmente para fins de controle do ambiente de produção, destacando que o mestre terá a maior prioridade e o menor SwitchID. Os comandos necessários para configurar o Switch1 com prioridade 5 e o Switch2 com prioridade 1 são apresentados abaixo, junto de algumas saídas com informações do empilhamento.

SW-Core(config)# switch 1 priority 5

SW-Core(config)# switch 2 priority 1

SW-Core(config)# exit

SW-Core# show switch

                                               Current

Switch#  Role      Mac Address     Priority     State

--------------------------------------------------------

 1       Master    0016.9d59.db00     5         Ready

 2       Slave     0016.4748.dc80     1         Ready

SW-Core# show switch stack-ports

  Switch #    Port 1       Port 2

  --------    ------       ------

     1          Ok           Ok

     2          Ok           Ok

SW-Core# show switch neighbors

  Switch #    Port 1       Port 2

  --------    ------       ------

      1         1            2

      2         2            1

O SwitchID é um número que identifica a unidade do empilhamento e essa informação é importante para referenciar as portas físicas de um determinado switch. Supondo que ambos os switches possuem 48 portas gigabit-ethernet, as portas físicas do SwitchID#1 estarão no intervalo de g1/0/1 até g1/0/48, enquanto que as portas físicas do SwitchID#2 estarão no intervalo de g2/0/1 até g2/0/48. Se a prioridade não for setada manualmente, há risco de que as configurações das interfaces fiquem incorretas em caso de mudança no ID dos membros do empilhamento. 

Abraço.

Samuel.

Tecnologia StackPower em Switches Catalyst 3750-X

Olá Pessoal.

Os Switches Cisco Catalyst 3750-X e Catalyst 3560-X (os novos modelos de ambas as famílias) permitem que duas fontes de força sejam acopladas no equipamento, o que provê redundância em caso de falha e que a carga consumida seja distribuída entre elas. Cabe ressaltar que a característica de balanceamento de carga com apenas duas fontes não é possível naqueles modelos de 48 portas que têm suporte a PoE+ (802.3at) por causa da demanda de 30 Watts por porta (total de 1440W).

Fonte: Cisco Systems (www.cisco.com)

Especificamente na família Catalyst 3750-X existe um recurso bem interessante denominado StackPower, viabilizando que as fontes de força de até 4 switches sejam compartilhadas entre os equipamentos de um empilhamento. Assim o sistema empilhado com StackPower pode conter até 8 fontes, sendo 2 instaladas no chassis de cada switch, além da possibilidade de inserção de fontes externas ao sistema empilhado. 

Para formar o sistema StackPower os switches são empilhados através de cabos próprios para esse fim (stack cables), permitindo o gerenciamento de um sistema lógico único composto pelo total das capacidades de carga das fontes individuais. Os switches são empilhados de 2 em 2, normalmente formando uma topologia física de anel (vide figuras abaixo).

Fonte: Cisco Systems (www.cisco.com)

Fonte: Cisco Systems (www.cisco.com)

Um diferencial é que o sistema tem inteligência para fazer o balanceamento de carga entre todas as fontes pensando não somente em maior disponibilidade, mas também na otimização do consumo de energia. Como assim maior otimização de energia? Acontece que as fontes de força apresentam maior eficiência energética quando trabalham entre 30% a 90% da sua capacidade máxima. Dessa forma, ao invés de sobrecarregar uma ou algumas fontes, é mais eficiente distribuir a carga entre todas elas a manter os níveis de carga nessas faixas, ação que reflete em economia no consumo de energia elétrica e que certamente será apreciada pela política ambiental da empresa (TI Verde). 

Outra vantagem é que em caso de falha de qualquer fonte de força do sistema, a substituição da peça pode ser realizada sem que haja interrupção na operação dos switches porque a carga total demandada pelo sistema é redistribuída entre as demais fontes operacionais. Naturalmente que é necessário que haja a carga necessária nas demais fontes para a devida manutenção do sistema empilhado. O sistema é inteligente, não faz mágica! ;-)

A carga total do sistema como um todo pode ser facilmente gerenciada através da linha de comando, especificamente com o comando "show power inline" que exibe o total de energia disponível e o total de energia consumida. Ainda através da linha de comando o sistema PowerStack pode ser setado para operar de duas maneiras, a saber:

• Modo Compartilhado (Power-Sharing Mode) - Em modo compartilhado o total equivalente à soma das capacidades individuais de cada fonte fica disponível para ser compartilhado pelo sistema, através da visão única de uma fonte lógica de força. Nesse modo nenhuma reserva de energia é feita para mitigar eventuais falhas do sistema, de maneira que a falha de uma fonte pode ocasionar na interrupção do fornecimento de energia para alguns equipamentos, caso a carga total esteja esgotada.

• Modo Redundante (Redundant Mode) - Nesse modo a carga energética da fonte com maior capacidade é subtraída do total do sistema, o que implica em menor carga disponível para alimentação dos equipamentos. No entanto, essa carga subtraída fica reservada especificamente para uso em caso de falha, o que elimina o risco de pane na alimentação dos dispositivos.

Um comando útil para gerenciamento do sistema é: "show stack-power". Esse comando exibe a topologia de switches empilhados, permitindo que o status dos seus membros seja visualizado através da referência aos seus respectivos endereços físicos (MAC). Por exemplo, o modo de operação de um empilhamento StackPower pode ser configurado através das seguintes linhas de comando:

Switch(config)# stack-power stack NOME

Switch(config-stackpower)# mode {redundant | power-sharing}

Switch(config-stackpower)# exit

Switch(config)# show stack-power

Outro recurso útil para gerenciamento é definir a prioridade dos switches ou equipamentos ligados em portas PoE. Através do comando "power priority {switch|high|low}" é possível explicitar quais switches têm maior importância sobre outros (parâmetro switch). Além disso, especificamente para os modelos com suporte a PoE, as portas podem ser classificadas com prioridade high ou low (o padrão é low). É obrigatório que os valores de prioridade do parâmetro switch sejam menores que os do parâmetro high que, por sua vez, têm que ser menores que os do parâmetro low. 

Através do comando "power inline port priority {high|low}" no sub-modo de configuração de interface é possível definir individualmente quais portas são menos importantes e, portanto, os dispositivos que serão desligados em caso de falta de energia no "banco" do sistema. O valor da prioridade pode variar de 1 a 27, sendo que números menores têm maior prioridade. 

Para entender melhor como funciona a prioridade trago um pequeno exemplo de configuração em que temos um empilhamento denominado NOME com 4 switches com os seguintes nomes e prioridades:

Switch-01: Prioridade = 1

Switch-02: Prioridade = 2

Switch-03: Prioridade = 3

Switch-04: Prioridade = 4

Queremos definir que o Switch-02 tem menor prioridade em relação aos demais e, dessa forma, deve ser desligado em caso de falta de energia no "banco" disponível no sistema, para tanto estaremos aumentando sua prioridade para o valor 5, ou seja, o menos importante dos switches. Também vamos setar o valor padrão da prioridade high para 15 e da prioridade low para 25 (apenas nesse switch).

Switch(config)# stack-power switch 2

Switch(config-stackpower)# stack NOME

Switch(config-stackpower)# power-priority switch 5

Switch(config-stackpower)# power-priority high 15

Switch(config-stackpower)# power-priority low 25

Switch(config-stackpower)# end

Samuel.

Switch Catalyst e Cluster Microsoft NLB em Modo Multicast

Olá Pessoal.

É comum as empresas agruparem seus servidores físicos Microsoft através da solução Network Load Balancer (NLB) para criar um cluster lógico equivalente à soma dos nós. Ao configurar o cluster deve ser informado um IP Virtual (Virtual IP Address) correspondente ao agrupamento lógico. 

O objetivo desse artigo é explicar a configuração do Switch Cisco Catalyst para suportar o encaminhamento otimizado de pacotes destinados ao cluster através de comunicação multicast, por isso não entrarei em detalhes do modus operandi da solução MS-NLB. No entanto, para acompanhar esse artigo é importante conhecer os possíveis modos de configuração do MS-NLB, que são:

• Unicast: É o modo padrão de operação do cluster NLB onde os endereços físicos (MAC) dos servidores são sobrescritos com um único endereço "falso" gerado pelo cluster e que é igual para todos os nós. Por causa disso é necessário um segundo adaptador de rede para a comunicação interna entre os nós do cluster;

• Multicast: É o modo de operação mais recomendado porque instrui o NLB a adicionar um endereço físico (MAC) de multicast nos adaptadores de rede de todos os hosts do cluster. Dessa forma o MAC original de cada host não é alterado e os hosts podem se comunicar normalmente entre si. Esse modo também oferece a opção de habilitar o protocolo IGMP, o que faz com que os hosts do cluster enviem uma mensagem igmp-join para o switch manifestando que são parte do mesmo grupo multicast.

A menos que os servidores físicos estejam isolados em sua própria VLAN (e sub-rede), o problema do modo unicast é que o switch faz o flood (inundação) dos pacotes/quadros destinados ao MAC do cluster MS-NLB, o que implica na propagação de todo tráfego destinado aos nós do cluster como broadcast. Isso é muito ruim para o desempenho da rede e pode causar problemas desastrosos no ambiente corporativo se os servidores físicos estiverem conectados no switch principal da rede (core) que é responsável por agregar todos os demais switches de acesso. Na figura abaixo o leitor pode visualizar esse efeito negativo comparado com aquilo que seria o ideal (clique p/ ampliar).

Caso os servidores estejam no mesmo domínio de broadcast que as demais máquinas da rede, uma prática não recomendada, então é necessário configurar o switch em que os servidores do cluster estão diretamente conectados para que haja ciência da existência dos grupos multicast. Caso haja outros switches de acesso conectados ao principal, eles também devem ser configurados para encaminhar os quadros multicast somente para a(s) interface(s) de uplink. Essa configuração pode ser feita manualmente com mapeamentos estáticos que associam o endereço MAC do cluster com as respectivas interfaces do switch que estão conectadas aos servidores.

O IGMP (Internet Group Management Protocol) é um protocolo de comunicação utilizado no IPv4 para que hosts comuns possam estabelecer um grupo lógico multicast. É comumente utilizado por aplicações de streaming de vídeo e clusters, entre outras, quando há necessidade de comunicação de "um para muitos" (grupo). Se o cluster MS-NLB foi implementado para operar no modo "IGMP Multicast", então os servidores utilizam o protocolo IGMP para que o switch aprenda dinamicamente quais portas estão conectadas aos servidores e, portanto, pertencem ao mesmo grupo multicast.

Então vamos considerar o cenário abaixo para exemplificar como o switch deve ser configurado para otimizar o desempenho da rede através de ambos os métodos dinâmico (via IGMP) e estático. Em relação à figura, é importante ficar atento aos endereços dos servidores, principalmente os endereços do cluster lógico que estão destacados em vermelho. O cluster foi configurado para operar em modo "Multicast (sem IGMP)", de modo que o MAC gerado pela solução da Microsoft fica sendo 03:bf:XX:XX:XX:XX, sendo os 32 bits X equivalentes ao endereço virtual do cluster em hexadecimal.

Em relação ao suporte do IGMP para associação dinâmica, a "boa" notícia é que não seria necessário fazer nenhuma configuração adicional no switch. Por padrão o IGMP vem ativado no equipamento e, portanto, bastaria configurar o cluster para propagar as mensagens join-igmp que, assim, o switch aprenderia em quais portas existe um grupo multicast! ;-) A má notícia é que nem todos os modelos de switches apresentam esse comportamento e há inúmeros relatos de comportamento estranho dessa funcionalidade. Por exemplo, os novos modelos Catalyst 2960-X e 3750-X, amplamente utilizados nas empresas, constroem sua lógica de encaminhamento partindo do princípio que o IP de destino pertence à faixa reservada para multicast (224. até 239.), o que conflita com a lógica do MS-NLB que opera com um endereço de destino unicast (associado a um MAC multicast do tipo 0100.5e). Muitas vezes a melhor opção acaba sendo a configuração manual, então vamos a ela...

Quanto à configuração manual, uma primeira informação importante é conhecer o endereço MAC multicast gerado pelo cluster NLB, o que pode ser visualizado na própria configuração do cluster, através do cache da tabela ARP presente em algum computador da rede (via comando "arp -a") ou mesmo através da análise dos cabeçalhos via captura de tráfego com algum software sniffer. Em posse dessa informação, basta utilizar o seguinte comando associando o endereço físico do cluster com as respectivas interfaces do switch em que os servidores estão conectados e que, portanto, têm interesse em receber tráfego destinado ao grupo multicast.

SW(config)# mac-address-table static 03bf.ca08.6464 vlan 1 interface g0/1 g0/2 g0/3

Caso os servidores sejam acessados remotamente, então o(s) roteador(es) de borda que têm acesso externo também precisam ser configurados com o mapeamento estático do ARP, responsável pela associação dos endereços IP e MAC do cluster. Embora o ARP faça essa associação automaticamente nos diversos sistemas operacionais, os roteadores Cisco não completam as requisições ARP ao NLB porque associar um endereço IP unicast com um endereço MAC multicast é contrário aos princípios da RFC. Essa configuração é simples:

Router(config)# arp 192.168.100.100 03bf.ca08.6464 ARPA

Com isso o desempenho da rede é otimizado porque seu montante de tráfego é estabilizado através da implementação de comunicação multicast com os servidores que compõem o cluster, eliminando a propagação dos broadcasts nos switches.

Abraço.

Samuel.

Tecnologia Cisco® CEF no Encaminhamento de Pacotes

Olá Pessoal.

CEF (Cisco Express Forwarding) é o nome dado à avançada tecnologia de encaminhamento layer-3 empregada na maioria dos equipamentos da Cisco. Uma definição comumente adotada pela Cisco destaca que "a tecnologia CEF otimiza o desempenho e a escalabilidade para redes com grande volumes e diferentes padrões de tráfego, como ocorre em ambientes de produção que possuem muitas aplicações web baseadas nos padrões da Internet."

Técnicamente essa é uma definição correta da tecnologia CEF, mas o que realmente isso quer dizer e como essa tecnologia implica em excelente desempenho no processo de comutação/encaminhamento de pacotes? É essa resposta o objeto de discussão desse artigo...

Antes de entrar na discussão da tecnologia CEF propriamente dita é conveniente apresentar um breve histórico da evolução das tecnologias de comutação adotadas pela Cisco, a saber:

• Process Switching
• Fast Switching
• CEF

A mais antiga e simples das técnicas de encaminhamento é denominada Process-Switching e consiste basicamente na necessidade de ação direta do processador principal na decisão de encaminhamento de cada pacote individual. Essa técnica possui desempenho ruim, ou seja, é lenta, porque cada pacote entrante em uma interface de rede passa, minimamente, pelas seguintes etapas:

1. Leitura e Retirada do Cabeçalho de Camada 2
2. Cópia do Pacote de Camada 3 na Memória da CPU (Plano de Controle)
3. Lookup no Plano de Controle e Decisão de Encaminhamento
4. Realização de Processos Complementares
5. Recálculo da Função CRC p/ Geração de Novo Cabeçalho Layer-2
6. Reencapsulamento Layer-2 do Pacote Layer-3
7. Encaminhamento do Quadro na Interface de Saída 

Acontece que todo esse processo é bastante oneroso no consumo de processamento, principalmente no que diz respeito ao lookup no plano de controle (destaque em vermelho) que envolve outros protocolos como o ARP (IPv4) ou NDP (IPv6) para descobrir o endereço físico associado ao IP do vizinho. Essa é a forma tradicional de encaminhamento adotada na maioria dos roteadores residenciais e de pequeno porte (SOHO), inclusive em vários Sistemas Operacionais terminais, o que explica esses sistemas/dispositivos não terem o mesmo desempenho de um roteador profissional. 

Uma alternativa a esse processamento individual ocorre quando uma interface de um roteador gera uma interrupção no processador principal ao receber um pacote para que a decisão de encaminhamento seja tomada com base em tabelas auxiliares (estruturas de dados) previamente armazenadas. Por enquanto essa é uma descrição bastante generalista, mas é válido associar essa segunda abordagem com as técnicas Fast-Switching e CEF.

A diferença entre as técnicas Fast-Switching e CEF consiste na forma pela qual cada uma dessas técnicas irá construir/armazenar essas estruturas de dados que serão posteriormente utilizadas no processo de decisão para agilizar o encaminhamento dos pacotes.

Através da técnica Fast-Switching o processo anterior ocorre apenas para o primeiro pacote de um mesmo fluxo. O primeiro pacote de um fluxo é copiado na memória da CPU (plano de controle) para que seja realizado o procedimento de busca (lookup) e reencapsulamento em um novo frame, afinal a cada salto mudam as informações dos vizinhos (origem/destino). A diferença é que o processamento desse primeiro pacote implica na construção de uma estrutura de dados chamada "fastswitching cache" que será consultada no processo de encaminhamento dos demais pacotes que pertençam ao mesmo fluxo (direcionados para o mesmo destino), dispensando, assim, todo o processamento anteriormente mencionado para cada pacote individual. Nessa tabela ficam armazenadas informações sobre os endereços IP e MAC do destino e sua respectiva interface de saída.

Podemos dizer que Fast-Switching também utiliza a CPU (plano de controle), no entanto o resultado da tomada de decisão de encaminhamento de um pacote implica no armazenamento em cache (plano de dados) de como alcançar um dado destino. Todos os demais pacotes direcionados para o mesmo destino são encaminhados mais rapidamente através da consulta desse cache, dispensando o processo de lookup tradicional por pacote individual. O ponto negativo é que cada novo fluxo irá requerer a intervenção do processador principal, uma vez que cada pacote encaminhado para um destino desconhecido nas tabelas de cache será marcado como "punted" e direcionado para a CPU do plano de controle, aumentando a latência de encaminhamento.

A tecnologia CEF representa uma evolução do processo de encaminhamento adotado nos roteadores para que esses dispositivos sejam capazes de encaminhar pacotes mais rapidamente com melhor desempenho. No CEF existem duas estruturas de dados principais:

• Tabela de Adjacência: Tomando como referência a tecnologia Ethernet, essa(s) tabela(s) é/são construída(s) a partir da Tabela ARP para mapear endereços IP em MAC com o objetivo de otimizar o desempenho com menos ação dos protocolos ARP/NDP. Ela também é construída para armazenar informações de endereços físicos de outras tecnologias, a exemplo de Frame-Relay, ATM, PPP, etc.

• FIB (Forwarding Information Base): É uma tabela bastante enxuta que fica armazenada no plano de dados e que é construída a partir da tabela de roteamento que, por sua vez, é construída a partir da RIB (Routing Information Base) armazenada no plano de controle do roteador. Essa tabela é construída a partir de tecnologia proprietária da Cisco e possui excelente desempenho no processo de busca a informações sobre os prefixos de rede, próximo salto e interface de saída.

Fonte: CCNP Practical Studies: Switching (Justin Menga)

Com a adoção da tecnologia CEF o tratamento dos pacotes passa pelas seguintes etapas:

1. Leitura e Retirada do Cabeçalho de Camada 2
2. Lookup na Tabela FIB (Plano de Dados)
3. Leitura na Tabela de Adjacência
4. Reencapsulamento Layer-2 do Pacote Layer-3
5. Encaminhamento na Interface de Saída

Reparem na figura que o lookup é feito no próprio plano de dados através da FIB, sem necessidade de resolução nenhuma no plano de controle. Um roteador com CEF ativo (padrão) não precisa marcar pacotes como "punted" (exceto aqueles destinados a interfaces diretamente conectadas) porque se um dado destino não estiver na FIB, então ele não existe!

Em síntese, o segredo do desempenho otimizado da tecnologia CEF é resultado direto do método proprietário adotado pela Cisco para construir a FIB no plano de dados a partir da RIB no plano de controle. Uma vez que essa estrutura fica no plano de dados, não há necessidade de consumo da CPU do plano de controle. Por fim, trago alguns comandos de visualização que devem ajudar o leitor a enxergar melhor a implementação prática desses conceitos nos dispositivos roteadores:

!--- Visualização da Tabela de Adjacência do CEF
Router# show adjacency
Router# show adjacency summary
Router# show adjacency detail
Router# show adjacency internal

!--- Visualização da Tabela FIB do CEF
Router# show ip cef

!--- Visualização do Cache do FastSwitching
Router# show ip cache [opções]

Abraço.

Samuel.

VSS no Agrupamento Lógico de Switches de Agregação

Olá Pessoal.

No desenho/projeto de redes é muito comum a interligação por pares de equipamentos redundantes para fins de disponibilidade, principalmente nas camadas mais importantes (núcleo e distribuição) que fazem a agregação das camadas mais baixas que são responsáveis pela interligação dos equipamentos terminais do usuário (camada de acesso), prática ilustrada na figura abaixo.

Apesar de essa ser uma "boa prática" de projeto extremamente importante de ser levada em consideração, ela traz consigo maior complexididade ao desenho e operação da rede, afinal são dois equipamentos redudantes e mais cabos para interligar as camadas, conforme pode ser observado no lado esquerdo (a) da figura abaixo.

O VSS (Virtual Switching System) é uma tecnologia desenvolvida especificamente para equipamentos das camadas de agregação (núcleo e distribuição) que permite combinar pares de switches físicos redundantes, criando a abstração de uma única entidade lógica do ponto de vista de gestão e operação, conforme pode ser observado no lado direito (b) da figura abaixo.

A consequência da abstração lógica do VSS é que há uma simplificação relevante na quantidade de switches físicos e também em suas ligações através de cabos. Em topologias com interligação layer-3 entre o par de switches há simplificação nas vizinhanças de roteamento e em topologias com interligação layer-2 entre os switches há garantia de inibição de loops (loop-free). As ligações entre o par VSS são feitas através de links especiais denominados Virtual Switch Link (VSL) que operam em 10Gbps ou 40Gbps, sendo comum a agregação de dois links de 10Gbps (total de 20Gbps).

O interessante dessa tecnologia é que os switches de acesso passam a enxergar o par de switches de agregação como uma única entidade lógica, independente da interligação física dos cabos. Dessa forma o switche de acesso é interligado fisicamente a ambos os switches de agregação, mas é configurado através de uma porta lógica agregada (port-channel). Do ponto de vista do par de switches de agregação, é utilizado o recurso MEC (Multichassis Ether-Channel) para associar portas físicas em diferentes switches a um único canal lógico (link agregado) e cabe à tecnologia VSS fazer o geranciamento do balanceamento de carga e da disponibilidade entre essas ligações físicas.

Ao criar um "par" VSS os switches físicos negociam seus papéis no agrupamento lógico, de forma que um assume o status de master e outro o de standby. A partir daí, do ponto de vista de gerenciamento de operação deixam de existir os dois switches físicos e passa a existir apenas uma única entidade lógica, de forma que o switch master controla o "par" VSS. Embora as funções de encaminhamento (plano de dados) continuem independentes em cada switch, o tráfego de controle que chega no switch standby é repassado para o switch master - o responsável pelo plano de controle.

Aqueles que tiverem interesse em obter mais detalhes técnicos da solução VSS podem recorrer ao Guia Oficial de Configuração da Cisco (clique no link e você será redirecionado). Esse link traz exemplos de como configurar o par de switches físicos par ativar o VSS.

Abraço.

Samuel.

Manipulação do STP na Otimização de Redes Layer-2

Olá Pessoal.

Em minhas aulas sempre costumo lembrar os alunos que a configuração das características de layer-2 (camada de enlace) em infraestruturas de redes é comumente deixada de lado por muitos profissionais da área pelo simples fato de switches serem dispositivos de natureza "plug-and-play", diferente de roteadores que requerem configuração preliminar para funcionar. Ou seja, basta ligá-los na tomada, esperar as luzes estabilizarem, e está tudo Ok! (Ah se fosse assim...)

No entanto, é um erro grave a presunção de que a natureza "plug-and-play" dos switches siginifica que não é necessário fazer nenhuma configuração nesses dispositivos. Ao contrário, há vários protocolos e configurações importantes na camada de enlace que devem receber atenção do profissoinal de infraestrutura porque comumente essa camada se torna um ponto comum de subotimização do desempenho em vista dos "relaxos" de configuração (ou desconhecimento) do administrador.

As características de layer-2 são extremamente importantes porque a tecnologia ethernet tem uma lógica de operação relativamente simplista, o que implica em desempenho ruim sem configurações específicas para melhorar seu comportamento padrão. Por exemplo, o simples fato de criar várias sub-redes layer-3 na sua empresa não quer dizer que você esteja otimizando o desempenho da sua rede porque no layer-2 continua existindo um único domínio de broadcast no qual serão propagados todos os quadros gerados, por exemplo, pelo ARP e DHCP - muito comuns nas redes atuais.

Costumo brincar em aula dizendo que o switch não é nem um pouco tímido porque qualquer encaminhamento que ele tenha que fazer e não saiba seu destino, então ele sai logo "gritando" para toda a rede (sem nenhuma vergonha) - esse é o efeito de broadcast tão ruim do ponto de vista de desempenho. No caso do exemplo anterior, é uma boa prática de projeto sempre associar uma VLAN (Layer-2) com cada Sub-Rede (Layer-3) para minimizar o efeito negativo dos broadcasts.

O objetivo desse artigo não é explicar o funcionamento das VLANS, mas falar um pouco sobre como otimizar o desempenho de redes layer-2 através da manipulação do comportamento do protocolo STP (Spanning-Tree Protocol). O STP (802.1d) e o rSTP (802.1w) são protocolos utilizados pelos switches para evitar a ocorrência de loops no caso de ligação redundante de links ou mesmo através da ligação entre switches de maneira a formar um circuito, ou seja, uma topologia que possa permitir o tráfego infinito de quadros em "círculos".

Vamos utilizar como exemplo a figura abaixo, em que temos dois switches de distribuição juntos para fins de disponibilidade conectados a um switch de acesso, um abordagem muito comum do ponto de projeto de redes. É comum os switches de acesso onde são conectados os dispositivos terminais ficarem localizados em mini-racks nas proximidades e serem conectados a ambos os switches de agregação naquilo que chamamos de camada de distribuição. Essa topologia acaba possibilitando a ocorrência de loops e para que isso não ocorra o STP entra em ação, também de maneira automática, bloqueando uma das portas. 

Parte da lógica do STP consiste na eleição de um switch raíz que ficará propagando quadros de controle (mensagem hello a cada 2 segundos) para os demais switches da rede depois que a topologia estiver estabilizada. Como caberá ao switch raiz a propagação dessas mensagens de controle em toda a infraestrutura layer-2, também é uma boa prática de projeto que esse switch seja bem escolhido no sentido de manter a simetria e o desempenho da rede, tendo, assim, a menor distância possível na propagação dessas mensagens entre os demais switches - o que otimiza o uso dos links. Nessa linha de raciocínio é sempre conveniente utilizar os switches das camadas superiores como raíz.

Reparem na figura que nenhuma porta, aparentemente, está sendo bloqueada porque todas estão com a indicação verde, ou seja, encaminhando! Se o STP é automático então uma das portas deveria ser bloqueada para evitar a ocorrência de loops, mas por que isso não aconteceu? A resposta é que isso não aconteceu porque eu mudei as configurações padrões do STP justamente para otimizar o desempenho da rede, permitindo que o tráfego das VLANs 10 e 20 seja distribuído entre os uplinks. 

Nesse cenário existem a VLAN-10 e VLAN-20 em todos os switches. O ASW está conectado através de sua interface f0/1 ao DSW1 e através de sua interface f0/2 ao DSW2 que, por sua vez, estão conectados entre si. Tenham em mente que o objetivo desse laboratório é mostrar a melhor configuração do STP, por isso não estamos preocupados com o fato de que os uplinks entre switches sejam apenas fast-ethernet (100Mbps). 

Uma primeira boa prática de projeto então seria configurar DSW1 ou DSW2 para que um seja o raíz da rede e outro seja seu backup. Isso poderia ser feito facilmente atribuindo a prioridade 0 para DSW1 e a prioridade 4096 para DSW2, lembrando que a prioridade padrão de switches é 32.768. Ok, então vamos imaginar que deixamos DSW1 como raíz e DSW2 como seu backup. Ao fazer isso todos os quadros originados na VLAN-10 e VLAN-20 em ASW seriam encaminhados apenas pela interface f0/1 (interface conectada ao switch raíz) porque sua interface f0/2 seria bloqueada para evitar loops. Seria melhor do ponto de vista de desempenho se pudéssemos utilizar ambos os uplinks para distribuir todo o tráfego e, ainda assim, em caso de falhas, teríamos a rede operacional. 

Pois bem, é por isso que estaremos tirando proveito do método PVST (Per VLAN STP) dos switches da Cisco para criar duas instâncias de topologias STP distintas, uma para a VLAN-10 e outra para VLAN-20. No contexto da VLAN-10 vamos configurar DSW1 para ser raíz e DSW2 seu backup, enquanto que no contexto da VLAN-20 vamos configurar DSW2 para ser raíz e DSW1 seu backup. Ao fazer isso, estaremos balanceando todo o tráfego das VLANs 10 e 20 entre os dois uplinks, conforme veremos nas saídas adiante. 

Apesar da descrição da solução parecer complicada a princípio, não é! Reparem que com apenas duas VLANs fica muito fácil visualizar logicamente as duas topologias distintas. As configurações de DSW1 e DSW2 irão ficar assim:

DSW1(config)# spanning-tree vlan 10 priority 0

DSW1(config)# spanning-tree vlan 20 priority 4096

**

DSW2(config)# spanning-tree vlan 10 priority 4096

DSW2(config)# spanning-tree vlan 20 priority 0

Com apenas essas configurações já conseguimos ter um ganho considerável de desempenho por causa do efeito de balanceamento porque quadros da VLAN-10 serão encaminhados pelo uplink da interface f0/1 de ASW, enquanto que quadros da VLAN-20 serão encaminhados pelo uplink da interface f0/2 de ASW. Observem nas saídas abaixo que para a VLAN-10 (destaque em amarelo) a interface f0/1 está em estado FWD (forwarding) e a interface f0/2 está em estado BLK (blocking). No contexto da VLAN-20 (destaque em azul) a situação é inversa, ou seja, a interface f0/1 está em estado BLK e a interface f0/2 está em estado FWD.

ASW#show spanning-tree vlan 10,20

VLAN0010

  Spanning tree enabled protocol ieee

  Root ID    Priority    10

             Address     000A.4148.08C5

             Cost        19

             Port        1(FastEthernet0/1)

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    36874  (priority 36864 sys-id-ext 10)

             Address     0060.2F37.1B0D

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Fa0/1            Root FWD 19        128.1    P2p

Fa0/2            Altn BLK 19        128.2    P2p

Fa0/10           Desg FWD 19        128.10   P2p

VLAN0020

  Spanning tree enabled protocol ieee

  Root ID    Priority    20

             Address     0001.6359.999D

             Cost        19

             Port        2(FastEthernet0/2)

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    36884  (priority 36864 sys-id-ext 20)

             Address     0060.2F37.1B0D

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Fa0/1            Altn BLK 19        128.1    P2p

Fa0/2            Root FWD 19        128.2    P2p

Fa0/20           Desg FWD 19        128.20   P2p

Apesar das configurações em si serem simples, o mais importante em relação ao STP e suas variações (rSTP 802.1w e MST 802.1s) é conhecer seu modus operandi para tirar proveito do melhor desenho de projeto que possa otimizar o desempenho da rede. Esse artigo é importante para reforçar aos profissionais da área de redes que, apesar de switches serem "plug-and-play", isso não quer dizer que não haja necessidade de configurá-los - um visão equivocada que pode custar caro no desempenho de uma rede.

Abraço.

Samuel.