quinta-feira, 30 de maio de 2013

Lançamento do Cisco Packet Tracer 6.0.1

Olá Pessoal.

Vocês devem estar lembrados que há algum tempo foi lançada a versão 6.0.0.0045 Beta do Cisco® Packet Tracer, inclusive fiz um artigo sobre algumas das novas funcionalidades intitulado "Servidor de Terminais no Packet Tracer 6 Beta". Esses dias a Cisco® disponibilizou no repositório oficial da Academia Cisco a nova versão 6.0.1.0011 com a correção de alguns bugs. Eu particularmente ainda não cheguei a fazer testes nessa versão recém-lançada, por isso fiquem à vontade para relatar as experiências de vocês.




A nova versão do simulador da Cisco® já está disponível para download na seção "Downloads e Laboratórios do  Livro", para Windows e Linux Ubuntu. Baixem essa nova versão e façam seus testes, afinal juntos fica mais fácil relatar novas funcionalidades e dificuldades/bugs. Os laboratórios do meu livro são todos compatíveis com essa nova versão, por isso não deve haver problema nenhum em fazer a atualização.

Abraço.

Samuel.

domingo, 26 de maio de 2013

Autoconfiguração de Endereços IPv6 (SLAAC)

Olá Pessoal.

Percebi que os artigos sobre IPv6 têm chamado bastante a atenção dos leitores do blog. Por isso, na medida do possível, estarei aumentando a carga de artigos sobre o assunto. Melhor ainda, estou trabalhando na escrita de um livro totalmente dedicado a IPv6 que será lançado no mercado ainda esse ano! Aguardem e por enquanto aproveitem os artigos...

Uma das novidades mais interessantes do IPv6 é a possibilidade de toda uma rede de computadores se autoconfigurar sem a necessidade de utilização de um serviço de DHCP ativo em algum servidor. Essa forma de autoconfiguração é denominada Stateless Address Autoconfiguration, mais conhecida como SLAAC. Esse método não mantém nenhum registro dos endereços atribuídos (stateless) e é automaticamente atribuído nos hosts (autoconfiguration), daí a origem do seu nome.

O processo de autoconfiguração dos endereços em redes baseadas no IPv6 consiste basicamente em duas etapas: (i) configuração do prefixo e (ii) configuração do sufixo de host. A primeira etapa é possível porque os hosts aprendem o prefixo da rede através das mensagens ICMPv6 Tipo 134 (RA) anunciadas pelos roteadores, conforme pode ser observado na figura abaixo. Reparem que no contexto do IPv6 os roteadores ganham evidência por causa dessa funcionalidade, o que valoriza ainda mais o profissional de infraestrutura.
 

Depois de aprendido o prefixo da rede, fica faltando apenas determinar o sufixo que será utilizado nos últimos 64 bits do Host-ID (sufixo de host). O sufixo de host é automaticamente gerado a partir do endereço físico (MAC) da interface de rede. O detalhe é que o MAC tem apenas 48 bits, por isso é aplicada uma função de expansão denominada IEEE EUI-64 (Extended Unique Identifier) no endereço físico que preenche os demais 16 bits através de um algoritmo padronizado, processo que pode ser observado na figura abaixo.


 Então vamos utilizar a figura acima como exemplo para entender o algoritmo da função de expansão EUI-64 que basicamente consiste em 3 etapas. A primeira etapa consiste em pegar o endereço físico de 48 bits e separá-lo em dois blocos iguais de 24 bits. A segunda etapa consiste em adicionar os algarismos hexadecimais FFFE (mais 16 bits) entre os dois blocos, de maneira que o endereço foi expandido para 64 bits. Ainda não acabou, falta a terceira etapa que consiste em inverter o sétimo bit do primeiro byte para 1 (destacado em preto), uma flag indicando que o endereço é administrado localmente. 

Depois de aplicada essa função de expansão, basta anexar o prefixo da rede ao identificador de host e já existe um endereço global unicast automaticamente atribuído à interface, o que permite conexão local e no contexto da Internet! Antes do endereço automaticamente gerado ser efetivamente atribuído à interface é aplicada a funcionalidade de detecção de endereços duplicados do NDP.

Embora as empresas possam optar por atribuir o endereço através de outros mecanismos, o SLAAC será extremamente útil para facilitar o processo de atribuição de endereços na Internet das coisas!
 
Abraço.

Samuel.

sexta-feira, 17 de maio de 2013

Servidores DHCPv6 em Redes IPv6

Olá Pessoal.

Muito se fala da visível diferença que existe nos endereços IPv4 (32 Bits) e IPv6 (128 Bits), o que permite uma quantidade de endereços de ordem astronômica com o "novo" protocolo - 340 undecilhões de endereços possíveis! Porém, pouco se fala das VÁRIAS outras diferenças que existem entre os protocolos. O IPv6 é um protocolo novo e que, portanto, possui muitas particularidades bem diferentes do seu antecessor - o tradicional IPv4.

Por exemplo, quando pensamos na questão da atribuição dos endereços, o "novo" IPv6 permite que essa configuração seja realizada de diversas maneiras, tais como:

  • Autoconfiguração Stateless (SLAAC)
  • Configuração Estática
  • Configuração Estática EUI-64
  • DHCPv6 Stateful
  • DHCPv6 Stateless

Seria necessário um artigo para cada uma dessas técnicas, então esse artigo será focado apenas nas principais diferenças entre o DHCPv6 nas modalidades: (i) Stateful e (ii) Stateless. Aproveitarei a oportunidade para mostrar as diferenças na configuração de um serviço DHCP em roteadores Cisco para ambientes IPv4 e IPv6.

No IPv4 o tradicional serviço de DHCP (Dynamic Host Configuration Protocol) é definido na RFC 2131 e diz respeito à distribuição automática de endereços em uma rede TCP/IPv4 através de um servidor reponsável por executar uma instância de um serviço DHCP. É nesse servidor em que o administrador irá criar um escopo definindo o intervalo de endereços que será distribuído para as máquinas, bem como outras configurações importantes: gateway da rede, servidores de resolução de nomes (DNS), opções, etc.

Nesse caso cabe ao servidor manter uma tabela com o registro dos clientes, seus respectivos endereços atribuídos e seu tempo de empréstimo (lease). Uma vez que o servidor é responsável por manter essa tabela com o "estado" dos clientes associando os endereços físicos das máquinas (MAC) com os endereços lógicos atribuídos (IP), então dizemos que esse é um serviço de natureza stateful, ou seja, é mantido um registro de informações.

A sua configuração através de um roteador Cisco é bastante simples, bastando a entrada de alguns poucos comandos para fazê-lo. Vamos observar o cenário da figura abaixo em que temos uma rede 192.168.221.0 /24, sendo que todas as máquinas estarão configuradas para obter o endereço dinamicamente e o roteador será responsável por executar o serviço DHCP. As configurações necessárias seriam as seguintes:



01. Router(config)# ip dhcp excluded-address 192.168.221.1 192.168.221.30
02. Router(config)# ip dhcp pool NOME-ESCOPO
03. Router(config-dhcp)# network 192.168.221.0 255.255.255.0
04. Router(config-dhcp)# default-router 192.168.221.1
05. Router(config-dhcp)# dns-server 192.168.221.2

Na primeira linha definimos quais endereços devem ser excluídos do escopo que será posteriormente criado, uma vez que esses endereços serão atribuídos estaticamente porque são reservados para os servidores. Na segunda linha foi dado um nome para o escopo que irá compreender os endereços da rede informada na terceira linha, sendo que nas linhas 4 e 5 são informados os endereços que as máquinas deverão utilizar como gateway e DNS. Pois bem, até aqui bem simples! 

Acontece que quando pensamos em IPv6 as coisas mudam bastante. Primeiro porque nativamente as redes IPv6 têm suporte ao processo de autoconfiguração stateless em que as próprias máquinas são capazes de formar seu endereço através de duas etapas: (i) a máquina determina seu identificador de host (sufixo) a partir do endereço físico da interface (MAC) e (ii) a máquina determina seu identificador de rede (prefixo) através de anúncios emitidos pelo roteador através de um protocolo de descoberta de vizinhança (NDP). Em um próximo artigo escreverei detalhadamente sobre o processo de autoconfiguração dos enredeços IPv6...

Por conta disso, via de regra, um servidor DHCP seria algo dispensável em redes IPv6 e agora o roteador da infraestrutura se torna um elemento ainda mais importante. Apesar disso, o DHCPv6 é definido na RFC 3315 e pode existir em duas modalidades: (i) stateful e (ii) stateless

A modalidade stateless é aquela em que o servidor não mantém um registro dos endereços atribuídos aos clientes porque agora as máquinas irão formar automaticamente seu endereço a partir do endereço físico da interface de rede (MAC) e através dos anúncios dos prefixos dos roteadores. Nessa modalidade cabe ao servidor DHCPv6 informar apenas os endereços complementares, tais como: DNS e/ou Opções. Vale destacar que a funcionalidade stateless é muito útil para informar automaticamente os servidores DNS da rede, afinal em IPv6 o serviço DNS é fundamental para amenizar a "complexidade" do endereço de 128 bits.

Estamos falando de uma versão bastante simplificada do DHCP que não consome muitos recursos do "servidor" e que utiliza como base o processo de autoconfiguração! Para exemplificar como seria a configuração desse serviço, vamos observar o cenário da figura abaixo que é apenas uma reprodução da figura anterior num ambiente TCP/IPv6 em que temos a rede 2001:DB8:CAFE::/64.




O processo de configuração do DHCPv6 Stateless consiste em criar e configurar o "escopo" (linhas de 1 a 3), destacando que é importante ativar o serviço DHCPv6 na interface conectada à LAN que receberá os endereços dinâmicos (linha 7) e informar aos hosts que as informações complementares devem ser aprendidas pelo serviço DHCPv6 (linha 8), através da ativação da flag O (other-config-flag).

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
03. Router(config-dhcp)# domain-name labcisco.com.br
03. Router(config-dhcp)# exit
04. Router(config)# int f0/0
05. Router(config-if)# ipv6 enable
06. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
07. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
08. Router(config-if)# ipv6 nd other-config-flag
09. Router(config-if)# end

Embora não seja recomendado pela Cisco e nem todos os roteadores suportem, ainda existe uma versão stateful do DHCPv6 para aqueles que precisam manter o registro dos endereços dinamicamente atribuídos e que querem determinar o escopo explicitamente. Normalmente essa modalidade será empregada em servidores Linux e Windows Server. O processo de configuração do DHCPv6 Stateful no roteador ficaria:

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# address prefix 2001:DB8:CAFE::/64 lifetime 1800 60
03. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
04. Router(config-dhcp)# exit
05. Router(config)# int f0/0
06. Router(config-if)# ipv6 enable
07. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
08. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
09. Router(config-if)# ipv6 nd managed-config-flag
10. Router(config-if)# exit

Reparem que agora tivemos que configurar na interface (linha 9) uma opção que instrui os clientes a receber todas as configurações de endereço via DHCPv6 (stateful), procedimento feito através da ativação da flag M (managed-config-flag). Além disso, na linha 2 o prefixo é explicitamente configurado.

Por fim, o segiunte comando poderia ser utilizado para fins de verificação:

Router# show ipv6 dhcp pool

Esse artigo mostra que as diferenças entre os protocolos IPv4 e IPv6 estão muito além do formato do endereço utilizado. O IPv6 é um protocolo que possui muitas particularidades que não existiam no seu antecessor, motivo pelo qual precisamos disseminar suas funcionalidades e qualificar mais profissionais preparados para lidar com o novo protocolo.

Abraço.

Samuel.

segunda-feira, 13 de maio de 2013

IPv6 no Café da Manhã

Olá Pessoal.

Em 28 de maio, no período da manhã, estarei no NIC.br (Núcleo de Informação e Coordenação do Ponto BR) para participar como membro da mesa no evento "IPv6 no Café da Manhã" que será realizado na sede do NIC em São Paulo. Há 50 vagas para participação presencial, sendo que o evento também será transmitido via Internet. Os interessados podem obter maiores detalhes sobre as inscrições presenciais ou sobre a transmissão online através do link oficial da notícia em: http://ipv6.br/cafe/


Na oportunidade do evento representantes de várias universidades estarão compondo uma mesa para compartilhar experiências, casos de sucesso e dificuldades em relação ao novo protocolo da Internet. O NIC.br me convidou para falar sobre o processo de inclusão do IPv6 na matriz curricular dos cursos de Graduação e Pós-Graduação em Redes de Computadores da UNIMEP, bem como sua adequação às recomendações internacionais do IPv6 Forum no processo de obtenção da ceritificação dos cursos da universidade.

Obs.: Para quem ainda não conhece, é importante destacar que o NIC.br é a autoridade local de abrangência nacional na hierarquia da governança da Internet, que desde dezembro de 2005 implementa as decisões e projetos do Comitê Gestor da Internet no Brasil (CGI.br).

Abraço.

Samuel.

quarta-feira, 8 de maio de 2013

Mensagem ao Leitor do Blog - Resultado de Sorteio

Olá Pessoal.

No dia 01/02/2013 escrevi uma mensagem para todos os leitores assumindo o compromisso de sortear um exemplar do meu livro autografado para os membros do blog quando atingíssemos a marca de 100 pessoas na nossa comunidade técnica. Quem não estiver lembrado ou não acompanhava o blog nessa época, o anúncio foi intitulado "Mensagem ao Leitor do Blog".


Pois bem, como promessa é dívida e recentemente ultrapassamos a marca dos 100 membros cadastrados, hoje (08/05/2013) realizei o sorteio onde todos os membros cadastrados tinham seu nome presente. O leitor premiado foi:

- Thiago Pimentel, do Rio de Janeiro

Já fiz contato com o Thiago solicitando que ele me envie os dados completos do endereço onde deseja receber seu exemplar autografado do meu livro intitulado "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes". 

Agora que esse sorteio foi realizado acho que já podemos pensar no próximo, não é mesmo? Pois bem, então vamos pensar grande! Assim que atingirmos a marca de 200 membros cadastrados no blog (isso mesmo, nada menos que 200), irei sortear um novo exemplar do meu livro autografado. Talvez demore um pouco para ultrapassarmos essa marca, mas há de acontecer e agora vocês já sabem que o sorteio realmente será realizado! ;-)

Se cada usuário cadastrado no blog indicá-lo para um colega da área que tenha interesse em redes/telecom e tecnologias Cisco, então é possível que o próximo sorteio ocorra logo. Espero que vocês estejam gostando do conteúdo aqui publicado e peço que todos colaborem com o crescimento desse espaço, afinal não é fácil mantê-lo atualizado! Aliás, estou trabalhando em alguns projetos e em breve trarei novidades bem interessantes para vocês...

Colaborem, divulguem, COMENTEM, COMPARTILHEM...
 
Abraço.

Samuel.

sábado, 4 de maio de 2013

Interpretação dos Resultados do Ping

Olá Pessoal.

Esse é mais um artigo que escrevo atendendo a pedido dos leitores do blog. Existem várias ferramentas de monitoramento de redes no mercado, sendo que todas elas, de alguma forma, retornam algumas métricas importantes de desempenho em redes, tais como: vazão em bps, latência (atraso), jitter (variação da latência no tempo), etc. A mais comum de todas essas ferramentas e que certamente faz parte da vida cotidiana de TODO profissional de redes é o "bom e velho" ping - presente em praticamente todas as caixas e sistemas operacionais!

Apesar de parecer simples, o ping vai MUITO além de simplesmente confirmar se há comunicação com um host remoto qualquer - ele também traz alguns valores importantes para determinar o desempenho de uma rede. Para cada linha de resposta echo-reply do ICMP (protocolo utilizado por trás do ping) ele traz o valor do atraso fim-a-fim na comunicação (latência), conforme pode ser observado no primeiro destaque em vermelho da figura abaixo.

Também ao final da sequência de respostas ele traz um resumo estatístico com os valores mais baixo, médio e alto da latência nos parâmetros rtt min/avg/max. Ele ainda mostra qual foi a porcentagem de perda de pacotes que, normalmente, não deve exceder 2%. Valores de perda de pacotes acima de 5% são indicativos de que está havendo algum problema na rede, que pode ser desde o cabeamento até a aplicação em si! É importante destacar que no Linux ele calcula o jitter (parâmetro denominado mdev no ping). Essas informações podem ser observadas no segundo destaque em vermelho da figura abaixo.


Não existe um valor único de latência que seja referência para todas as redes, por isso estarei mostrando alguns valores referenciais aceitáveis para algumas das tecnologias mais comuns que são: (1) Rede Local, (2) Internet via TV a Cabo, (3) xDSL, (4) Dial-Up e (5) Links de Longa Distância Privativo.

1) Em redes locais cabeadas a comunicação deve ter excelente desempenho, haja vista a proximidade entre os dispositivos e a boa qualidade da infraestrutura de cabeamento de propriedade da empresa. É esperado que a latência em redes locais não ultrapasse 10ms (recomendado) ou é tolerável até 30ms (não recomendado). Quanto mais dispositivos intermediários existirem entre duas máquinas, naturalmente maior será essa latência porque cada dispositivo intermediário terá algum mecanismos de tratamento dos quadros;

2) Um valor ideal de latência para links de Internet via Cable Modem seria algo entre 30ms e 50ms. No entanto a arquitetura da rede é compartilhada através de barramentos nas vizinhanças e a rede tende a sofrer mais com instabilidade em momentos de muito acesso, o que pode implicar em latências maiores que 100ms; 

3) A latência ideal para a tecnologia xDSL seria algo em torno de 70ms. O que acontece é que essa tecnologia é muito popular porque aproveita a infraestrutura de cabeamento da rede telefônica, motivo pelo qual muitas operadoras acabam vendendo mais conexões do que suas centrais suportam. Essa situação pode implicar em latências de 100ms ou mais, o que é comum de acontecer no Brasil;

4) A conexão discada naturalmente é aquela que apresenta pior desempenho porque utiliza a rede pública de telefonia comutada (PSTN) através da modulação do sinal digital do computador em sinal analógico (audio), ou seja, simplificando, conversão dos dados em som. Por isso a latência dessa tecnologia pode facilmente ser bem superior a 250ms;

5) Os links de longa distância privativos mais profissionais, ou seja, aqueles normalmente utilizados pelas empresas devem apresentar excelente desempenho. Normalmente os contratos desses links têm cláusulas de SLA em que a operadora se compromete a entregar uma qualidade mínima com base em parêmetos pré-definidos. Normalmente esses links também não devem exceder 10ms (recomendado), mas pode ser tolerável latência de até 20ms ou 30ms (dependendo do contrato); 

Lembrem-se de que essas informações são referenciais, ou seja, nenhum desses valores deve ser aceito como REGRA! Há outros fatores que vão interferir diretamente na latência, principalmente quando pensamos em links de longa distância. Por exemplo, em situação ideal o sinal percorre um cabo metálico a aproximados 200.000 km/s (quase 2/3 da velocidade da luz). Isso quer dizer que você terá resultados diferentes na sua empresa se pingar um servidor localizado no Brasil e outro na China! ;-) Por isso antes de verificar o desempenho da rede é necessário estabelecer os critérios que serão utilizados para fazê-lo, criando uma metodologia homogênea que não interfira nos resultados!

Outro detalhe importante é que vejo as pessoas testando a velocidade da conexão de Internet em casa e sempre muito preocupadas com a tal largura de banda ou taxa de transmissão (em bps), no entanto tão importante quanto a largura de banda é a latência. Por exemplo, vamos pensar na seguinte situação:

Cenário 1: Ana contratou uma Internet xDSL de 25M
- Teste de Desempenho: Taxa de Transmissão de 19M; Latência de 190ms;

Cenário 2: Beto contratou Internet Cable de 10M
- Teste de Desempenho: Taxa de Transmissão de 8M; Latência de 60ms;

Na sua opinião qual dos dois cenários é melhor?
A resposta correta é: Cenário 2

Acontece que mesmo a Ana tendo mais largura de banda para acessar mais informação, o estado do link está MUITO pior do que o do Beto que possui menos da metade da largura de banda. No entanto, o retorno das requisições de Beto será muito mais rápido do que da Ana. É isso que explica porque um link de 2M na empresa em que você trabalha tende a ter desempenho muito melhor do que a Internet de 10M da sua casa!!! As latências dos links de longa distância privativos são muito menores do que as latências das conexões residencias!  

Compreenderam? Espero que sim... 

O jitter, por exemplo, é uma métrica extremamente importante para ambientes que possuem aplicações multimídia de "tempo real", como voz e vídeo. Os administradores de ambientes que possuem essas aplicações devem sempre estar atentos não somente à latência que representa o atraso na entrega dos pacotes, mas principalmente ao jitter. A latência mostra o desempenho real da rede naquele exato momento, enquanto que o jitter mostra seu comportamento ao longo do tempo, ou seja, define o grau de estabilidade da rede.

Pegando o exemplo do ping da figura acima que apresenta jitter de 15ms, esse seria um valor alto para uma rede local cabeada (ethernet), mas é um valor comum em redes sem fio pela própria natureza mutável do ambiente. Lembrem-se que as comunicações sem fio estão sujeitas a interferência de vários fatores externos, por isso o sinal tende a oscilar com maior frequência - o que as faz mais instáveis do que as redes cabeadas.

Uma evidência prática de que o jitter é ainda mais prejudicial para aplicações multimídia do que a própria latência é que normalmente o recurso comumente utilizado para minimizar o efeito do jitter consiste na utilização de buffers (pequenas memórias eletrônicas) nos dispositivos para armazenar os pacotes e, somente então, entregá-los "sem" jitter ao usuário, conforme pode ser observado na figura abaixo.


O problema é que essa "solução" implica no aumento da latência, o que mostra a preferência pelo aumento na latência se houver diminuição do jitter. Obviamente que o alinhamento dessas duas métricas (latência e jitter) acaba sendo um exercício de balança e o bom senso é fundamental para assegurar o bom desempenho das aplicações. De nada adianta eliminar totalmente o jitter se a latência ficar muito alta. O valor ideal do jitter vai variar em função da latência do link.

Por exemplo, no contexto de um link de longa distância xDSL (acesso à Internet) que tem em média de 50ms a 100ms, um jitter de até 15ms ou 30ms pode ser aceitável. Por outro lado, no contexto de uma rede local em que a latência máxima é 10ms, esses valores seriam inaceitáveis - principalmente se existirem aplicações multimídia de "tempo real".

A gente costuma utilizar como medidas de referência para latência em aplicações multimídia o limite de até 150ms para bom desempenho (recomendado) e valores entre 151ms até 400ms para desempenho tolerável (não recomendado), sendo que qualquer valor acima de 400ms é INACEITÁVEL!!!


Quem diria que uma ferramenta tão simples quanto o ping seria na realidade tão poderosa, não é mesmo? ;-) Esse é um dos motivos de eu sempre dizer aos meus alunos que na área de networking é crucial entrender os fundamentos por trás da tencologias, muito mais até do que saber operacionalizar. O ideal é "casar" as duas coisas: fundamento e prática!

Espero que esse artigo seja útil não apenas no dia-a-dia de vocês, mas principalmente no sentido de "abrir a mente" para a necessidade do profissional dessa área conhecer os fundamentos daquilo que está operacionalizando!

Abraço.

Samuel.