quinta-feira, 27 de março de 2014

Como Funciona a Internet

Olá Pessoal

Nesta postagem estou compartilhando mais uma série de vídeos do NIC.br, dessa vez sobre o funcionamento da Internet. Os vídeos são intitulados "Como Funciona a Internet?" e explicam de maneira bem simples alguns dos conceitos básicos mais importantes. Estarei incorporando as próximas partes da série neste post, assim a sequência fica mais organizada. Acompanhem...

Samuel.







Planejamento de Endereçamento IP

Olá Pessoal.

Gostaria de compartilhar com vocês a primeira parte de mais um dos vídeos produzidos pelo amigo Moreiras do NIC.br (e sua equipe). O vídeo é intitulado "Como Fazer um Bom Endereçamento IP" e traz uma visão geral sobre o processo de planejamento de endereçamento IP, cujo objetivo é tornar o ambiente mais escalável e mais fácil de gerenciar. À medida que novas partes forem publicadas, estarei incorporando nessa postagem para manter o conteúdo mais organizado. Acompanhem...

Samuel.



sexta-feira, 21 de março de 2014

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.

sábado, 15 de março de 2014

A Hora Certa na Internet Brasileira

Olá Pessoal.

Gostaria de compartilhar com vocês mais um vídeo produzido pelo amigo Moreiras do NIC.br, intitulado "A Importância da Hora Certa na Internet e o NTP.br". Esse vídeo aborda de maneira sucinta (e clara) o motivo pelo qual é importante que o horário dos dispositivos da Internet estejam sincronizados e explica como o NTP.br ajuda nesse processo. Podemos setar o horário dos dispositivos manualmente, mas esse método é pouco confiável e pode implicar em sérios problemas de gerenciamento e monitoramento, principalmente em relação a logs.




O vídeo explica que o NTP.br é um serviço público nacional disponibilizado pelo NIC.br, em parceria com o Observatório Nacional, que provê a sincronização do horário oficial brasileiro através de servidores gratuitos rodando o NTP (Network Time Protocol). Aproveito a oportunidade do tópico para trazer ao leitor o passo-a-passo de como configurar um roteador/switch da Cisco com o protocolo NTP para utilizar os serviços disponibilizados pelo NTP.br. Essa configuração é bastante simples e pode ser rapidamente realizada através das seguintes linhas de comando:

01. Router# conf t
02. Router(config)# ntp server 200.160.7.186
03. Router(config)# clock timezone BR -3 0 
04. Router(config)# clock summer-time BRV recurring 3 Sun Oct 0:00 3 Sun Feb 0:00
05. Router(config)# service timestamp debug datetime msec localtime show-timezone year
06. Router(config)# service timestamp log datetime msec localtime show-timezone year

No roteiro acima foi utilizado o servidor "a.st1.ntp.br" (do NTP.br) que responde pelo IP 200.160.7.186 (linha 2). O relógio dos equipamentos trabalha sincronizado com o UTC de cada região (o padrão é 0) e por isso precisamos da terceira linha para setar o UTC do Brasil (que é -3).

O NTP não trata da questão do horário de verão, ou seja, quando entramos ou saímos do horário de verão o relógio não é alterado. Por isso informamos a linha 4 para fazer os ajustes manuais referentes ao nosso horário de verão nacional. Como exemplo, em 2013/2014 o horário de verão teve início no terceiro domingo de outubro (20/10/2013) e terminou no terceiro domingo de fevereiro (16/02/2013). 

Nas linhas 5 e 6 informamos ao IOS que passe a anexar o horário sincronizado em todos os seus registros de log e debug, uma boa prática que pode facilitar muito na detecção de problemas a partir da leitura de logs. Reparem que essas linhas são opcionais e não são necessárias para o funcionamento do NTP, no entanto essa prática é realmente muito recomendada!

Abraço.

Samuel.

quarta-feira, 12 de março de 2014

Aniversário de 25 Anos da Web

Olá Pessoal.


A data de hoje (12/03) representa os aniversários de 25 anos da World Wide Web (WWW) e de 20 anos do W3C, entidade que trabalha nos padrões adotados na Web. Aproveito a ocasião para replicar aqui as palavras de Jari Arkko, presidente do IETF: 

"Nos últimos 25 anos a Web demonstrou o incrível poder dos padrões abertos na conexão das pessoas e como potencializador da inovação, uma vez que a Internet cresceu e evoluiu a ponto de conectar bilhões de pessoas e dispositivos em todo o mundo. O IETF está emocionado em celebrar esse sucesso notável e aguarda ansioso pelos próximos 25 anos!"



Foi em 12 de março de 1989 que Tim Berners-Lee, físico e cientista da computação britânico, publicou um artigo com sua ideia onde apresentava uma maneira fácil de organizar e acessar dados através do conceito de "flechas" e "círculos", fazendo referência, respectivamente, a hyperlinks e páginas. Essa idéia de páginas com hypertexto daria origem à World Wide Web (WWW) que se transformaria no fenômeno mundial que atualmente conecta bilhões de pessoas. 

Depois de 25 anos do sucesso da Web, a preocupação atual do seu criador é assegurar o caráter multissetorial (multistakeholder) à estrutura de governança da Internet, para que haja ampla participação dos diversos setores da sociedade e de todos os países do mundo. Tim Berners-Lee defende  a necessidade de uma Carta Magna para proteger a Internet, assegurarando sua independência e os direitos dos usuários.

Ele é um dos defensores assíduos da neutralidade da rede e vê com preocupação o "ataque" dos governos e das grandes empresas ao ecossistema neutro e aberto da Internet. Segundo o criador da web: "Precisamos de uma constituição global, uma declaração de direitos!". Esse posicionamento está alinhado ao entendimento recente da ONU (maio de 2011) que defende a Internet como um direito fundamental dos seres humanos.  

Me parece que não há maneira mais adequada de comemorarmos esses 25 anos da Web do que dar crédito ao seu criador e refletir um pouco sobre essa preocupação. Às vezes é difícil para algumas pessoas justificar a necessidade de a Internet possuir mecanismos para protegê-la, já que naturalmente, sem ser direito fundamental ou possuir legislação própria, ela se tornou a rede consolidada que é hoje. Acontece que agora, amplamente disseminada e conectando bilhões de pessoas, ela é alvo de muitos interesses, haja vista os acontecimentos recentes envolvendo a agência de segurança norte-americana (NSA). Por isso é importante garantir que a Internet continue aberta e neutra, além de proteger a privacidade dos usuários. Nós, na codição de usuários da rede, deveríamos ser os maiores interessados na defesa dos padrões abertos e da neutralidade da rede.

Por fim é sempre válido chamar a atenção do leitor para que não haja confusão entre Internet e Web. Embora sejam são conceitos muito próximos, não são a mesma coisa. A Internet diz respeito à infraestrutura física e aos protocolos de baixo nível, criados por Vint Cerf e Robert Kahn em 1981, que permitem a interconexão em escala global. Por outro lado a Web diz respeito a um dos serviços que rodam nessa infraestrutura - por sinal, o serviço mais relevante atualmente! 

Pois bem, comemoremos com nosso exercício de reflexão...

Abraço.

Samuel.

domingo, 9 de março de 2014

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.

domingo, 2 de março de 2014

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.