Usando o Ping (Cisco)

O Ping é certamente um dos programas mais utilizados para testar a conectividade de rede. Nos roteadores Cisco é "o" programa para testar não somente se existe conectividade, mas também para nos garantir que não há erros ou problemas (leia-se: perda de pacotes, etc). Tudo começa com o ping e deve terminar com várias exclamações consecutivas (ou pontos consecutivos, no pior caso).

router#ping 10.10.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/20 ms

Se quisermos melhorar um pouco o nosso teste, podemos utilizar um ping estendido:

router#ping
Protocol [ip]:
Target IP address: 10.10.10.1
Repeat count [5]: 10
Datagram size [100]: 1000
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 1000-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/24/68 ms

Ou ainda, de forma mais rápida e resumida, o mesmo comando:

router#ping 10.10.10.1 repeat 10 size 1000

Type escape sequence to abort.
Sending 10, 1000-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/16/32 ms

Quando estamos testando conexões seriais (a.k.a. links ponto-a-ponto) é importante fazer o teste com vários padrões de dados (ou data pattern) e é aí que podemos melhorar ainda mais nossos testes, pois somente o teste com vários padrões poderá nos revelar erros mais raros, mas que também podem perturbar a vida de um administrador de rede. Os padrões mais comuns são:

• 0x0000 ou 0xFFFF: para verificar se o circuito pode lidar com "all-zeros" (ou "all-ones"). Pode indicar problemas de codificação da operadora (bz8s/ami).
• 0x4040, 0x1010, 0x8080, 0xaaaa: zeros e uns alternados utilizados para indicar problemas com circuitos mal provisionados.

Lembrando que na opção padrão o comando ping dispara pacotes echo-request com o padrão de dados 0xabcd. Para alterar o padrão, basta utilizar a seguinte opção:

router#ping 10.10.10.1 repeat 10 size 1000 data 4040

Type escape sequence to abort.
Sending 10, 1000-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet has data pattern 0x4040
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/16/36 ms

Mais informações em:

• Using the Extended ping and Extended traceroute Commands.
• Como funciona o protocolo de sinalização de links seriais (link sobre SDLC do blog IOS Hints and tricks).
  

Dica: tcpdump

Nada como matar dois coelhos com uma paulada só. Para aqueles que gostam de resumos de comandos mais usados, dicas, resumo,... essa é uma ótima dica sobre o tcpdump e muitas outras coisas... como EIGRP, BGP, IPSec, etc. As (já famosas) cheat sheets do blog Packetlife.net são excelentes (fica aqui também a dica do blog que, assim como as cheat sheets, é excelente).

Ainda sobre o tcpdump, essa cheat sheet do Packetlife.net completa a coleção daquelas que já foram indicadas em um post sobre tcpdump aqui, nele também existe algumas dicas de como utilizar o tcpdump.

Inscrições abertas para o GTER/GTS

Acontece nos próximos dias 7 e 8 de novembro em São Paulo a 26a. reunião do GTER (Grupo de Trabalho de Engenharia e Operação de Redes) em conjunto  com a 12a. reunião do GTS (Grupo de Trabalho em Segurança). Os dois grupos são coordenados por renomados profissionais da área de redes e segurança com o apoio do CGI.br (Comitê Gestor da Internet no Brasil). As duas reuniões têm como objetivo promover a discussão de assuntos relevantes para operação e administração da Internet no Brasil. O programa completo com as apresentações está disponível aqui.

Faça sua inscrição E participe !

YSTS 2.0

Estão abertas as inscrições para o YSTS 2.0 (You Shot the Sherif 2.0). Promovido e totalmente organizado pela equipe do podcast I Shot the Sherif (este que já foi comentado aqui outras vezes e está na nossa lista de links favoritos aí do lado direito) esse é um evento sobre segurança da informação que pretende reunir palestras técnicas e não-tão-técnicas para agradar a todos os gostos em um ambiente diferente, descontraído e único. Marcam presença nesta edição dois keynotes "de peso": David "h1kari" Hulton e Emmanuel Goldstein. Além de palestras com os mais renomados especialistas de segurança do Brasil.

Dica: Material sobre PCI DSS

Eduardo Camargo Neves publicou no último mês de agosto um excelente artigo sobre o padrão de segurança da informação criado pelas principais empresas operadoras de cartões de crédito (PCI Security Standards Council) chamado PCI DSS (Payment Card Industry Data Security Standard). Com a crescente utilização dos cartões de crédito como forma principal para realização de transasões eletrônicas, e consequentemente o aumento do volume financeiro total destas transações, aumenta também a quantidade de fraudes eletrônicas (ou criminosos utilizando-se do meio eletrônico para desviar recursos). A preocupação das empresas também vêm ganhando (muito) espaço no sentido da segurança e por isso foi criado o PCI DSS, na tentativa de inibir o roubo de informações pessoais que posteriormente serão utilizadas nestas fraudes.

Ainda segundo o Eduardo:"(...) Os controles estabelecidos pelo PCI Council tem a vantagem de serem simples, eficazes dentro do escopo ao qual se propõe a abordar e altamente escalonáveis. Este artigo mostra em uma visão geral, como estes padrões nasceram, quais controles são esperados e como a sua empresa pode se alinhar para um processo de certificação. (...)." [veja aqui o artigo completo]

Mais informações em:

• PCI Security Standards Council Home.
• Blog do Eduardo Camargo Neves.
• McAfee How PCI Compliance Works.

NANOG 44 Webcast

Desde ontem até o próximo dia 15 de outubro (quarta-feira) acontece em Los Angeles a NANOG 44. Como é de costume, grande parte das apresentações será transmitida via streaming (ao vivo) a partir das 9:30 PDT (13:30 BRT). A agenda e os arquivos das apresentações estão disponíveis aqui.

Dica: CCIE SP Dynamips Mini Cenários

Este post é uma forma de agradecer o Antonio Soares (CCIE No. 18473) por ter criado uma coleção completa de mini cenários (todos no Dynamips) para a maioria do conteúdo da prova do CCIE Service Provider, organizado tudo isso por assunto e publicado aqui for free!

Cisco Flexible Netflow

Lançado com a versão 12.4(9)T do IOS, o Cisco Flexible Netflow é uma atualização ao já largamente utilizado Cisco Netflow. Esta atualização permite configurações mais detalhadas e a possibilidade de fazer o cache de informações para fins específicos, como por exemplo, análises de segurança ou billing. Neste último mês de setembro, a Cisco publicou um white-paper completo descrevendo a tecnologia e como ela pode ser utilizada nas redes convergentes mais atuais :-). Consulte a documentação oficial do Flexible Netflow para mais informações sobre configuração e funcionamento desta tecnologia.

Cisco Policy-Based Routing

Policy-Based Routing (ou PBR) é uma técnica utilizada para forçar um determinado fluxo de pacotes por um caminho diferente daquele que o fluxo normalmente seguiria se estivesse sendo roteado pela tabela de roteamento padrão de um roteador. Por exemplo, assim que um fluxo chega até uma das interfaces de um roteador, este roteador deve consultar a tabela de roteamento para determinar para qual interface os pacotes deverão ser comutados e isso é o comportamento padrão de um roteador IP.

Quando utilizamos uma PBR, estamos alterando este comportamento e fazendo com que os pacotes que cheguem até uma interface, sejam comutados para uma interface diferente daquela apontada pela tabela de roteamento; e isso é configurado nos roteadores Cisco através do comando route-map e da cláusula set ip next-hop. Como exemplo, vejamos um route-map aplicado a interface Ethernet0. Todos os pacotes que chegarem a esta interface serão comutados para uma interface na rede 10.1.1.1, de forma que os pacotes possam ser encaminhados para o endereço 10.1.1.1.

route-map ENVIA_PARA_10.1.1.1
set ip next-hop 10.1.1.1

interface ethernet0
ip policy route-map ENVIA_PARA_10.1.1.1

No entanto, existem duas formas de utilizar o comando set ip next-hop e um comportamento padrão que deve ser muito bem observado durante a sua utilização:

O comando set ip next-hop irá verificar a existência do próximo salto (next-hop) válido e...
- Se o próximo salto existe na tabela de roteamento, então o pacote é encaminhado para o próximo salto especificado.
- Se o próximo salto não existe na tabela de roteamento, então o roteador utiliza da tabela de roteamento padrão para encaminhar os pacotes.

O comando set ip default next-hop também irá verificar a tabela de roteamento e...
- Se o destino existir na tabela de roteamento, encaminha o pacote utilizando as informações da tabela de roteamento.
- Se o destino não existir na tabela de roteamento, encaminha o pacote de acordo com o next-hop especificado no comando.

Para mais detalhes sobre esse comportamento e exemplos de configuração, consulte este documento da Cisco. É possivel também combinar as características de roteamento baseado em política (PBR) com as opções de tracking e IP SLA para verificar se o next-hop é alcançável ANTES de aplicar a PBR. Mais detalhes sobre a utilização desta solução aqui.

BGP AS com 4 Bytes

Tradicionalmente o número de sistema autônomo (aka AS) possui 2 bytes (ASN16 ou 2 octetos), permitindo assim que estes sistemas autônomos utilizem teoricamente qualquer número no intervalo de 1 até 65536. O número de sistema autônomo identifica uma rede (ou um conjunto de redes) que possui uma mesma política de roteamento e está sob administração de um conjunto comum de pessoas (por exemplo, um provedor de serviços Internet). Este número é utilizado pelo protocolo BGP, mais precisamente no atributo AS_PATH, que determina a que distância encontra-se uma rede, medindo essa distância pelo número de sistemas autônomos que deve-se atravessar para alcançar a rede em questão.

Com o crescimento exponencial (?) da Internet, espera-se que o esgotamento do número de AS disponível para alocação esgote-se por volta do ano de 2015, no mais otimista dos casos. Por isso foi criada uma extensão ao tradicional AS de 2 bytes para um número AS de 4 bytes (ASN32) e este padrão foi publicado oficialmente pelo IETF no RFC 4893 no início de 2007. O padrão garante a compatibilidade entre os antigos e os novos números de AS de forma a garantir a interoperabilidade entre os dois padrões, já que esta informação deve ser utilizada dentro do protocolo BGP (pelo atributo AS_PATH) que é visível através de toda Internet.

Alguns grandes fabricantes de equipamentos de rede já estão se adaptando ao novo padrão, como é o caso da Juniper que a partir da versão 9.x do JunOS já suporta ASN32. Vale lembrar que o padrão para utilização de communities dentro do BGP também será ligeiramente alterado (para a Juniper, por exemplo, o padrão para communites com o ASN32 será 334324L:132 para o ASN 334324 e target 132). A Cisco diz possuir o código para ASN32 implementado na versão 12.5T do IOS que deve estar disponível em breve.

Vale lembrar que os primeiros testes desse novo padrão foram feitos com software-routers como o openbgpd e o Quagga. Para mais informações sobre o como os fabricantes estão se preparando e os testes realizados até agora na Internet visite o Wiki AS4 sobre ASN32.

Mais informações:

• RIPE-NCC Deployment of 32 bit AS Numbers.
• Como desabilitar o ASN32 no JunOS para estabelecer uma sessão BGP com roteadores ASN16-only.
• Mudanças na política de alocação de ASN do LACNIC.
  

Configuração de portas Gigabit Ethernet

Esta noite estava vendo um outro blog sobre redes quando encontrei uma frase ao mesmo tempo trágica e engraçada (como a frase foi escrita em inglês, manterei na língua original): "Repeat after me. I will not force a switch to 1000/Full, even if some idiot insists that I should."

Essa é, com certeza, umas das discussões mais antigas que eu já vi. Alguns dizem que sim, alguns dizem que não, enfim... Apesar do assunto ser bastante comentado em diversos lugares, como por exemplo a página Techworld, muita gente custa a acreditar! :)

Por isso o meu grande amigo Thiago Siqueira fez um ótimo dever de casa há algum tempo atrás e eu gostaria de compartilhar para também ficar registrado aqui.

Acontece que no início da implementação do padrão Gigabit Ethernet (IEEE 802.3z) a especificação não era clara a respeito de utilizar auto-negociação ou configurar manualmente a interface para half ou full-duplex em portas gigabit e isso fez com que os fabricantes - talvez utilizando o mesmo código que utilizavam para portas 10/100 ou ainda por causa do comodismo em continuar configurando um novo padrão com velhos costumes - implementassem de forma diferente o padrão Gigabit Ethernet em UTP, uma herança da forma como foi definido e implementada a auto-negociação do padrão IEEE 802.3u (Ethernet 100 MBps). Com o passar do tempo, surgiu toda essa confusão.

Para o padrão IEEE 802.3 (Ethernet) o uso de auto-negociação para interfaces 1000BASE-T é MANDATÓRIO. Consulte o documento a seguir para mais informações (página 603, item A, anexo 28A, cláusula 28D.5): http://standards.ieee.org/getieee802/download/802.3-2005_section2.pdf

Muito tempo depois a possibilidade de configuração fixa para full ou half-duplex no padrão Gigabit Ethernet foi possível (e aceitável) para que garantisse a compatibilidade entre os equipamentos que seguiam o padrão (mais novos) e os equipamentos mais velhos (do início da implementação do padrão Gigabit Ethernet). Hoje todos os fabricantes implementam corretamente (ou pelo menos deveriam implementar) o padrão estabelecido pelo IEEE em 1998.