quarta-feira, 13 de julho de 2016

Configuração de MultiLink PPP em Roteadores Cisco

Olá Pessoal,

O MultiLink PPP (MLPPP) é uma tecnologia padronizada na RFC 1990 e na RFC 2686 que permite agregar múltiplos links físicos de longa distância (do tipo PPP) através de uma única interface lógica equivalente à soma das capacidades dos links individuais. Trata-se, portanto, de um recurso interessante para obter um link lógico de alta velocidade e com maior disponibilidade a partir de múltiplos links de baixa velocidade. Uma vez que o MLPPP requer configuração coerente em ambas as pontas com a informação de quais interfaces físicas devem ser logicamente agrupadas, não é possível utilizar esse recurso para agregar múltiplos links físicos que sejam providos por diferentes operadoras.

O pré-requisito óbvio para configurar MLPPP é a existência dos links físicos PPP. A configuração do MLPPP é bastante simples, já que basta criar uma interface virtual do tipo multilink que receberá o endereço IP da rede ponto-a-ponto, além de ser referenciada como grupo lógico em cada uma das interfaces físicas. Tomando por base a topologia ilustrada na figura acima, as configurações necessárias estão destacadas abaixo em amarelo. As demais configurações consistem no estabelecimento dos links PPP, assunto abordado em outro artigo intitulado "Configuração de Link WAN PPP em Roteadores Cisco"

R1(config)# username R2 password SENHA
R1(config)# interface s2/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface s2/1
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface multilink 1
R1(config-if)# ppp multilink
R1(config-if)# ip address 203.0.113.1 255.255.255.252

R2(config)# username R1 password SENHA
R2(config)# interface s2/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface s2/1
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface multilink 1
R2(config-if)# ppp multilink
R2(config-if)# ip address 203.0.113.2 255.255.255.252

Depois de realizadas as configurações do MLPPP, é possível observar que uma nova interface virtual do tipo multilink passa a compor a relação de interfaces do roteador. Também é possível observar na tabela de roteamento que a rede ponto-a-ponto entre os dois roteadores está diretamente conectada através da interface lógica multilink, ao invés das interfaces físicas do tipo serial.

R1# show ip route
Codes: (...)
Gateway of last resort is not set

     203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C       203.0.113.2/32 is directly connected, Multilink1
C       203.0.113.0/30 is directly connected, Multilink1

O comando abaixo é específico para MLPPP e bastante útil para identificar quais interfaces físicas compõem o agrupamento lógico multilink, além de apresentar o status dessas interfaces. Nesse exemplo, é possível observar que ambas as interfaces físicas seriais estão operacionais.

R1# show ppp multilink 
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:01:22, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 6 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x16 received sequence, 0x17 sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se2/0, since 00:03:25
    Se2/1, since 00:02:22
No inactive multilink interfaces

Para verificar a disponibilidade do agrupamento lógico, basta desativar qualquer uma das interfaces físicas seriais para simular um falha qualquer no link. Mesmo em caso de queda de um dos links físicos, a interface lógica se mantém disponível através do(s) outro(s) link(s) físico(s). Por exemplo, temos a seguinte saída após desativar a interface s2/1 em R2:

R1# show ppp multilink
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:03:16, total bandwidth 1544, load 1/255
  Receive buffer limit 12000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 12 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x22 received sequence, 0x39 sent sequence
  Member links: 1 active, 1 inactive (max not set, min not set)
    Se2/0, since 00:05:20
    Se2/1 (inactive)
No inactive multilink interfaces

Façam seus testes...

Samuel.

terça-feira, 5 de julho de 2016

Configuração de Link WAN PPP em Roteadores Cisco

Olá Pessoal,

PPP (Point-to-Point Protocol) é uma tecnologia padronizada na RFC 1661 e que consiste em um conjunto de protocolos da camada de enlace (layer-2) para controle de links de longa distância. Assim como a tecnologia Ethernet possui protocolos adicionais de suporte no contexto das redes locais (por ex. STP), a tecnologia PPP possui vários outros protocolos complementares. As duas principais categorias de protocolos complementares são:

  • Link Control Protocol (LCP): Esse protocolo implementa as funções de controle em nível de enlace (layer-2) de maneira totalmente independente do protocolo de rede utilizado nas camadas superiores, afinal o PPP é independente da tecnologia de rede utilizada em layer-3. As funções de controle estão relacionadas a diversos aspectos da conexão que envolvem o estabelecimento, configuração e verificação do link, além da autenticação (opcional);

  • Network Control Protocol (NCP): Na realidade o NCP é uma categoria de protocolos de controle que contém vários sub-protocolos, de forma que cada sub-protocolo está associado com uma tecnologia de rede layer-3 específica. Exemplos comuns de sub-protocolos dessa categoria são o IP Control Protocol (IPCP), o IPv6 Control Protocol (IPv6CP) e o Cisco Discovery Protocol Control Protocol (CDPCP).

Outra característica importante do PPP é a autenticação das partes envolvidas na comunicação. No contexto de um link de longa distância (WAN), o processo de autenticação é importante para que as interfaces seriais de dois roteadores provem suas identidades antes de estabelecer o link. Dois protocolos de autenticação utilizados em conjunto com o PPP são o PAP e o CHAP, sendo que o procedimento de configuração de ambos é basicamente o mesmo. O PAP não é seguro porque faz o envio do usuário e da senha como texto simples (sem criptografia), enquanto que o CHAP é considerado mais seguro pela forma como faz a troca de mensagens entre as partes (hash MD5).

A topologia exibida na figura abaixo será utilizada para exemplificar a configuração de um link WAN PPP entre dois roteadores Cisco. Observem que propositalmente os dois roteadores serão configurados com endereços IP pertencentes a diferentes sub-redes, algo que a princípio faz parecer impossível a comunicação entre os dois roteadores. No entanto, a surpresa é que depois de configurado o link WAN PPP entre R1 e R2 a comunicação ocorre com sucesso. Por que isso acontece?


Antes de responder essa questão, vamos às configurações necessárias para estabelecer o link PPP. Um detalhe na configuração da autenticação é que em R1 deve ser criado um usuário na base local equivalente ao hostname de R2 e vice-versa. O nome do usuário a ser autenticado deve ser exatamente o nome de host que foi configurado no roteador da outra ponta, caso contrário a autenticação falhará.

R1(config)# username R2 password SENHA
R1(config)# interface s0/3/0
R1(config-if)# ip address 203.0.113.1 255.255.255.255
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# no shut

R2(config)# username R1 password SENHA
R2(config)# interface s0/3/0
R2(config-if)# ip address 198.51.100.1 255.255.255.255
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# no shut

Uma vez configurado o laboratório proposto, agora podemos voltar à discussão das razões pelas quais o ping entre os dois roteadores funciona mesmo quando as interfaces seriais são configuradas com endereços em diferentes sub-redes. Se utilizássemos o mesmo cenário para configurar uma WAN entre os roteadores R1 e R2 através de links seriais com encapsulamento HDLC (padrão), o ping não funcionaria com as duas interfaces seriais configuradas com endereços em sub-redes diferentes. Isso ocorreria porque os roteadores R1 e R2 não teriam uma rota diretamente conectada que fosse comum a ambos, ou seja, seria impossível direcionar a saída do tráfego ponto a ponto. 

Esse comportamento padrão muda bastante quando configuramos o encapsulamento para PPP, já que os protocolos de controle da categoria NCP são responsáveis por tratar automaticamente das informações de roteamento. No contexto do IPv4, o IPCP do PPP automaticamente adiciona uma rota de host (/32) apontando para o endereço IP do roteador vizinho. Essa característica pode ser observada nos destaques em amarelo das tabelas de roteamento listadas abaixo. 

Em R1 o PPP criou uma rota de host apontando para R2 (198.51.100.1/32):

R1> show ip route
Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/32 is subnetted, 1 subnets
C 198.51.100.1/32 is directly connected, Serial0/3/0
203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C 203.0.113.0/30 is directly connected, Serial0/3/0
L 203.0.113.1/32 is directly connected, Serial0/3/0

R1> ping 198.51.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/8 ms

Em R2 o PPP criou uma rota de host apontando para R1 (203.0.113.1/32):

R2> show ip route
Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 198.51.100.0/30 is directly connected, Serial0/3/0
L 198.51.100.1/32 is directly connected, Serial0/3/0
203.0.113.0/32 is subnetted, 1 subnets
C 203.0.113.1/32 is directly connected, Serial0/3/0

R2> ping 203.0.113.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/7 ms

Apesar de ser possível utilizar endereços em sub-redes diferentes, essa prática não é recomendada. Um problema decorrente dessa prática não recomendada é que não será possível executar protocolos de roteamento dinâmico entre R1 e R2, já que para formar a vizinhança de roteamento é necessário que os roteadores compartilhem a mesma sub-rede. Ou seja, sua rede não estará totalmente operacional mesmo que o resultado do ping seja um sucesso! Esse recurso do PPP  é denominado Peer Neighbor Route e pode ser manualmente desativado em sub-modo de configuração da interface serial através do comando "no peer neighbor route". Tenham cuidado com esse detalhe e procurem seguir as boas práticas que recomendam utilizar uma sub-rede /30 em links ponto-a-ponto.

Façam seus testes...

Samuel. 

quarta-feira, 22 de junho de 2016

Lançamento do Cisco Packet Tracer 7.0

Olá Pessoal,

Hoje a Cisco anunciou oficialmente para a comunidade NetAcad o lançamento da nova versão do simulador Cisco Packet Tracer 7.0 (7.0.0.0202), disponível para download no repositório oficial da Academia Cisco (www.netacad.com). Dessa vez o simulador foi disponibilizado nas versões 32-bits e 64-bits em sistemas operacionais Windows e Linux. Na nova versão foram corrigidos vários bugs e adicionado/melhorado suporte a alguns recursos, além de novos dispositivos.


Os novos dispositivos podem ser observados na figura abaixo e estão relacionados principalmente a redes industriais no contexto de Internet of Things (IoT). Outra novidade é a possibilidade de integrar blocos de programação em Python e JavaScript nos dispositivos de IoT. Também houve mudança na interface do simulador, particularmente no agrupamento de dispositivos na paleta de componentes. Na sequência trago uma relação das melhorias anunciadas:

  • Melhoria no Servidor HTTP
  • Melhoria na Área de Trabalho da Topologia Física
  • Melhoria no Suporte a PoE
  • Suporte ao Recurso SPAN/RSPAN
  • Suporte ao Protocolo LLDP
  • Suporte a L2NAT
  • Precision Time Protocol (PTP)
  • Resilient Ethernet Protocol (REP)
  • Suporte a IoT (Internet of Things)
  • Novos Dispositivos

Fonte: Cisco Networking Academy

Os requisitos mínimos de sistema para executar o simulador são os seguintes:

  • Microsoft Windows (7 / 8.1 / 10) ou Linux Ubuntu (12.04 32-bits / 14.04 64-bits)
  • CPU Pentium 4 (2.5 GHz)
  • 512MB RAM
  • 400MB de Espaço em Disco
  • Resolução de Vídeo de 800x600

Está mantido o procedimento de login na inicialização do software que foi novidade na versão anterior (6.3.0008). Como já comentei no lançamento da versão anterior, o objetivo do login é priorizar os alunos matriculados em cursos das academias oficiais do programa Cisco Networking Academy (NetAcad). Para aqueles que não são alunos oficiais do programa NetAcad, ainda existe uma opção de login para visitantes (guest login) em que o usuário deve esperar por 15 segundos toda vez que inicializa o software antes de ser lançado para o simulador com algumas limitações de recursos. Embora ainda não seja possível afirmar, é natural de se pensar que a inserção da autenticação nessa nova versão do simulador seja um indicativo de que a Cisco pode restringir o acesso ao software em próximas versões somente para alunos da NetAcad, o que garantiria que as aulas seriam ministradas somente por instrutores oficiais habilitados pela Cisco. 

Como é de costume, também estou disponibilizando a nova versão do simulador Cisco Packet Tracer para download na seção "Downloads & Laboratórios" do blog (para Windows e Linux). Baixem essa nova versão e relatem suas experiências com a ferramenta. 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. Vale lembrar que os laboratórios criados nas versões mais recentes do Packet Tracer não são compatíveis com as versões anteriores. Por isso é sempre recomendado que os alunos tenham a versão mais recente do simulador instalado em suas máquinas.

Fiquem atentos...

Samuel.

terça-feira, 21 de junho de 2016

Instalação do Cisco WebEx no Linux Ubuntu 16.04

Olá Pessoal.

O WebEx é uma poderosa ferramenta desenvolvida pela Cisco para realização de reuniões através da Internet em tempo real. O WebEx combina compartilhamento da área de trabalho (desktop sharing), compartilhamento de arquivos, compartilhamento de quadros brancos, conferência via telepresença, conferência via rede telefônica para permitir a participação na reunião através de um telefone convencional, entre vários outros recursos bastante úteis. Esses recursos combinados permitem aos apresentadores e participantes fazerem quase tudo o que se pode fazer pessoalmente. 




Sua instalação e configuração no Mac OS e no Windows é bastante simples e intuitiva, assim como em dispositivos móveis Android e IOS. No entanto, esse mesmo procedimento no Linux é mais complicado porque infelizmente ainda são muitas as restrições de suporte da ferramenta para esse sistema operacional. No Linux o WebEx é suportado apenas no navegador Firefox 32-bits. Para instalar o Firefox (32-bits) no Linux Ubuntu 16.04 e algumas bibliotecas complementares que melhoram sua interface gráfica podem ser utilizados os comandos abaixo no terminal:

$ sudo apt-get install firefox:i386
$ sudo apt-get libcanberra-gtk-module:i386 gtk2-engines-murrine:i386 libxtst6:i386

O WebEx é uma ferramenta baseada em Java, então é necessário instalar o Java no Linux e o plugin IcedTea para que o Firefox seja capaz de executar applets:

$ sudo apt-get install default-jre
$ sudo apt-get install icedtea-plugin

Feito isso, o Java deve estar operacional no Firefox. Na opção Menu>Add-on>Plugin deve ser verificado se o plugin está devidamente habilitado. Agora é possível acessar sua conta no WebEx (www.webex.com) para organizar as reuniões remotas. Ao tentar abrir a primeira reunião será criado o sub-diretório oculto ".webex" no diretório home do usuário (~/.webex). Caso os recursos de áudio e desktop sharing não estejam funcionando, o que é bem provável de ocorrer nessa etapa, então será necessário digitar o comando abaixo no diretório home do usuário que instalou o WebEx. Dentro desse diretório, o usuário deve procurar por sub-diretórios com números, por exemplo no formato 12_1524:

$ cd ~/.webex/XX_XXXX
$ ldd *.so | grep "not found"

A saída do referido comando listará as bibliotecas que ainda precisam ser instaladas no sistema para que o WebEx funcione com suporte a todos os seus recursos. A partir da saída desse comando é possível utilizar o apt-file para localizar os nomes dos pacotes que contêm as bibliotecas que estão faltando:

$ apt-file search nome_biblioteca.so
$ sudo apt-get install nome_biblioteca

Obs.: Caso o apt-file não esteja instalado, basta digitar apt-get install apt-file

Após todos esses passos, basta reiniciar o Firefox (32-bits) e hospedar uma nova reunião para verificar se a ferramenta está totalmente operacional, exemplo trazido na figura abaixo que mostra a interface gráfica da ferramenta com conexão de áudio. 


Embora esses procedimentos sejam suficientes para resolver os problemas em boa parte dos casos, cada máquina tem suas particularidades de hardware e software. Caso sua experiência de configuração da ferramenta seja diferente, fique à vontade para compartilhar com os demais membros da comunidade nos comentários deste post. 

Façam seus testes...

Samuel. 

sexta-feira, 17 de junho de 2016

Engenharia de Tráfego de Entrada no Protocolo BGP

Olá Pessoal,

Vimos em artigos anteriores que manipular os atributos do protoclo BGP para forçar o balanceamento do tráfego de saída ou mesmo para aplicar outras políticas de engenharia de tráfego é uma ação bastante objetiva, uma vez que a origem do tráfego será algum roteador no nosso próprio AS e que, portanto, está sob nosso domínio administrativo. No entanto, é bem mais subjetiva a tarefa de balancear o tráfego de entrada que vem da Internet, já que nesse caso não temos controle sobre o tráfego entrante que está sob gestão de outras entidades externas. 

Este é mais um artigo sobre configuração do protocolo BGP e novamente, por conveniência, irei me basear no laboratório 33 do livro LabCisco (2a Edição), cuja topologia adapatada pode ser observada na figura abaixo. Dessa vez o objetivo é apresentar os procedimentos necessários para dividir o prefixo da empresa em duas metades mais específicas que serão anunciadas por dois provedores (upstream) para forçar o balanceamento de tráfego de entrada. 


Vamos assumir que o AS 60 possui o prefixo 198.51.16.0/21 para anunciar na Internet. Observem que o referido AS está conectado através de dois provedores (upstream), representados pelo AS 40 e AS 50. Sob a ótica do roteador R1 (no AS 123) que receberá os anúncios vindos do AS 60, o comportamento padrão do BGP é que teremos dois caminhos possíveis para alcançar o prefixo anunciado, sendo um através de R4 (vizinho eBGP) e outro através de R3 (vizinho iBGP) indo para R5 (vizinho eBGP de R3). 

Os dois caminhos possíveis irão constar na tabela BGP de R1, no entanto o BGP escolherá como melhor caminho aquela rota aprendida pelo vizinho eBGP, o que fará com que todo tráfego de saída destinado ao AS 60 passe unicamente pelo AS 40. Do ponto de vista do R6 no AS 60, todo o tráfego de entrada chegará apenas através de um dos upstreams disponíveis, ou seja, sem nenhum balanceamento. 

Para contornar essa limitação, é possível explorar uma característica comum dos protocolos de roteamento que sempre preferem aquelas rotas mais específicas com prefixos maiores. Por exemplo, tomando esse comportamento padrão como base, os prefixos 203.0.113.0/25 e 203.0.113.128/25 sempre serão preferidos do que a agregação deles no bloco 203.0.113.0/24. É possível utilizar essa lógica no contexto do cenário proposto e forçar o balanceamento do tráfego de entrada apenas fazendo a "quebra" do prefixo 198.51.16.0/21 em duas metades /22, ou seja, em 198.51.16.0/22 e 198.51.20.0/22. Depois de dividir o prefixo original em duas metades, o R6 deve ser configurado da forma apresentada abaixo para anunciar uma metade /22 em cada upstream, forçando o restante da Internet a buscar os destinos da empresa através de dois caminhos, ainda que de forma assimétrica em termos de carga de tráfego. 

01. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/21 
02. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/22
03. R6(config)# ip prefix-list to-AS50 permit 198.51.16.0/21
04. R6(config)# ip prefix-list to-AS50 permit 198.51.20.0/22
05. R6(config)# router bgp 60
06. R6(config-router)# network 198.51.16.0 mask 255.255.248.0
07. R6(config-router)# network 198.51.16.0 mask 255.255.252.0
08. R6(config-router)# network 198.51.20.0 mask 255.255.252.0
09. R6(config-router)# neighbor 10.0.6.1 remote-as 40
10. R6(config-router)# neighbor 10.0.6.1 prefix-list to-AS40 out
11. R6(config-router)# neighbor 10.0.7.1 remote-as 50
12. R6(config-router)# neighbor 10.0.7.1 prefix-list to-AS50 out
13. R6(config-router)# end
14. R6# clear ip bgp all 40 soft
15. R6# clear ip bgp all 50 soft

Depois de realizadas essas configurações em R6, é possível visualizar apenas aqueles anúncios que estão sendo enviados para os vizinhos R4 (no AS 40) e R5 (no AS 50). Observem que cada vizinho recebe apenas uma metade /22 do bloco completo /21 para forçar o balanceamento do tráfego de entrada, já que os roteadores da Internet irão optar por alcançar os destinos correspondentes à primeira metade 198.51.16.0/22 através do AS 40 e por alcançar os destinos correspondentes à segunda metade 198.51.20.0/22 através do AS 50. Observem, ainda, que para fins de disponibilidade o bloco completo /21 é anunciado para os dois upstreams, o que garante que haverá alcançabilidade a todos os destinos mesmo em caso de falha de um dos upstreams

R6# show ip bgp neighbor 10.0.6.1 advertised-route
BGP table version is 20, local router ID is 6.6.6.6

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.16.0/22   0.0.0.0                  0         32768 i
*> 198.51.16.0/21   0.0.0.0                  0         32768 i

Total number of prefixes 2 



R6# show ip bgp neighbor 10.0.7.1 advertised-route

BGP table version is 20, local router ID is 6.6.6.6

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.16.0/21   0.0.0.0                  0         32768 i
*> 198.51.20.0/22   0.0.0.0                  0         32768 i

Total number of prefixes 2 


Em R2 no AS 123 é possível observar como os demais roteadores da "Internet" lidam com os anúncios que configuramos em R6. Na tabela BGP de R2 fica evidente que cada metade /22 pode ser alcançada através de diferentes caminhos, o que força o balanceamento do tráfego de entrada em R6. Também é possível observar a existência do bloco completo /21 na tabela BGP. Nesse ponto é importante lembrar que a lógica dos protocolos de roteamento dinâmico é que caminhos mais específicos sempre serão preferidos em detrimento a prefixos menores que foram agregados. Ou seja, mesmo que o bloco /21 exista na tabela BGP de R2, a preferência será por alcançar os IPs de destino a partir das rotas /22 que são mais específicas.

R2> show ip bgp
BGP table version is 30, local router ID is 2.2.2.2

   Network          Next Hop            Metric LocPrf Weight Path
*>i198.51.16.0/22   10.0.1.1                 0    100      0 40 60 i
* i198.51.16.0/21   10.0.2.2                 0    100      0 50 60 i
*>i                 10.0.1.1                 0    100      0 40 60 i
*>i198.51.20.0/22   10.0.2.2                 0    100      0 50 60 i

Façam seus testes...

Samuel.

terça-feira, 7 de junho de 2016

Boas Práticas de Filtragem BGP em IPv4 e IPv6

Olá Pessoal,

Este artigo tem por objetivo chamar a atenção para algumas recomendações e exemplos de boas práticas de filtragem de prefixos no BGP que são de grande interesse para aqueles responsáveis por um AS e que queiram impedir o recebimento de rotas inesperadas que sequer deveriam existir na Internet, mas que podem aparecer em decorrência de erros de configuração ou mesmo de ataques. A topologia abaixo é bastante simples, mas suficiente para exemplificar as configurações deste artigo.

Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv4 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| 0.0.0.0      /08 | Rede Zero     | 6890 |
| 10.0.0.0     /08 | Privado       | 1918 |
| 100.64.0.0   /10 | CGNAT         | 6598 |
| 127.0.0.0    /08 | Loopback      | 6890 |
| 169.254.0.0  /16 | Link Local    | 3927 |
| 172.16.0.0   /12 | Privado       | 1918 |
| 192.0.0.0    /24 | IETF          | 6890 |
| 192.0.2.0    /24 | Documentação  | 5737 |
| 192.168.0.0  /16 | Privado       | 1918 |
| 198.18.0.0   /15 | Benchmark     | 2544 |
| 198.51.100.0 /24 | Documentação  | 5737 |
| 203.0.113.0  /24 | Documentação  | 5737 |
| 224.0.0.0    /04 | Multicast     | 5771 |
| 240.0.0.0    /04 | Classe E      | 1700 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. É comum utilizar prefix-list para esse fim pela flexibilidade de informar não apenas os prefixos exatos, mas também uma faixa de prefixos que sejam menores ou igual (le) do que determinado valor de referência. A última regra permite o recebimento de qualquer prefixo menor do que /24 (0.0.0.0/0 le 24), uma prática recomenda porque impede o recebimento de anúncios fragmentados que sejam maiores do que /24. Depois de criar a lista em R1, é necessário aplicá-la na entrada da vizinhança BGP com R4.

!-- Criação do Filtro via Prefix-List
R1(config)# ip prefix-list FILTRO-ENTRADA deny   0.0.0.0/8       le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   10.0.0.0/8      le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   100.64.0.0/10   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   127.0.0.0/8     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   169.254.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   172.16.0.0/12   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.0.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.2.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.168.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.18.0.0/15   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.51.100.0/24 le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   203.0.113.0/24  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   224.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   240.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA permit 0.0.0.0/0       le 24

!-- Aplicação do Filtro no Vizinho eBGP
R1(config)# router bgp 100
R1(config-router)# neighbor 203.0.113.2 remote-as 200
R1(config-router)# neighbor 203.0.113.2 prefix-list FILTRO-ENTRADA in
R1(config-router)# end
R1# clear bgp all 200 soft

É interessante aproveitar o assunto e fazer um paralelo com esse mesmo procedimento no contexto do protocolo IPv6. Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv6 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| ::          /0   | Default       |      |
| ::          /128 | Sem Endereço  | 4291 |
| ::1         /128 | Loopback      | 4291 |
| ::ffff:0:0  /96  | IPv4 Mapeado  | 4291 |
| 0100::      /64  | Descarte      | 6666 |
| 2000::      /3   | Global        | 3587 |
| 2001::      /32  | Teredo        | 4380 |
| 2001:10::   /28  | ORCHID        | 4843 |
| 2001:db8::  /32  | Documentação  | 3849 |
| 2002::      /16  | 6to4          | 3056 |
| fc00::      /7   | Unique Local  | 4193 |
| fe80::      /10  | Link-Local    | 4291 |
| ff00::      /8   | Multicast     | 4291 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA-v6 em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. Observem nos comandos abaixo que nem todas as redes reservadas da tabela acima aparecem explicitamente nas regras, já que a sequência de permissões e negações apresentada é suficiente para garantir a filtragem delas. Com base no filtro abaixo, somente são permitidos prefixos IPv6 iguais ou menores do que /48, uma boa prática para evitar o recebimento de prefixos fragmentados.

ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2001::/32
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001::/32      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001:db8::/32  le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2002::/16   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2002::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   3ffe::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2000::/3       le 48   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   ::/0           le 128

Caso o laboratório estivesse configurado com endereços IPv6, essa prefix-list poderia ser aplicada em um vizinho eBGP (2001:db8:cafe::40) através dos comandos abaixo. Uma diferença no contexto do IPv6 é que as políticas do BGP devem ser aplicadas no sub-modo de configuração da address-family IPv6. O leitor interessado na configuração de BGP através de IPv6 pode recorrer ao laboratório 34 do livro ou mesmo ao artigo intitulado "Peering IPv6 no Roteamento BGP".

!-- Exemplo de Aplicação do Filtro na Address Family IPv6
R1(config)# ipv6 unicast-routing
R1(config)# router bgp 100
R1(config-router)# neighbor 2001:DB8::2 remote-as 200
R1(config-router)# address-family ipv6 unicast
R1(config-router-af)# neighbor 2001:DB8::2 route-map FILTRO-ENTRADA-v6 in
R1(config-router-af)# neighbor 2001:DB8::2 activate

Há várias fontes de distribuição de filtros pradrões na Internet que tem por objetivo tornar a Internet um espaço mais seguro. Uma fonte interessante é do Team Cymru que atualiza sua relação de prefixos a cada 4 horas e que contempla, inclusive, aqueles prefixos alocados às  autoridades regionais da Internet (RIR) que ainda não foram atribuídos para nenhum AS. Vale à pena conferir o link abaixo...


Façam seus testes...

Samuel.

quarta-feira, 1 de junho de 2016

Limitando o Aprendizado de Prefixos no Protocolo BGP

Olá Pessoal,

Este é mais um artigo sobre configuração do protocolo BGP e novamente, por conveniência, irei me basear no laboratório 33 do livro LabCisco (2a Edição), cuja topologia pode ser observada na figura abaixo. Dessa vez o objetivo é apresentar os procedimentos de configuração necessários para limitar o aprendizado de prefixos a partir de um vizinho qualquer. 

Essa ação é importante porque a tabela de roteamento da Internet possui aproximadamente 600.000 prefixos atualmente. Esteja ciente de que a tabela completa terá milhares de entradas porque é muito comum existirem múltiplas rotas em direção ao mesmo prefixo. Além disso, caso uma empresa esteja conectada à Internet através de dois links, ou seja, esteja pareada simultaneamente com dois ISPs, então seu roteador de borda receberá duas vezes mais rotas aprendidas através de diferentes roteadores.

Por conta dessa grande quantidade de rotas, para receber a tabela completa seria recomendado, por exemplo, um Cisco 3925 ou preferencialmente um ASR 1002-X. Esses equipamentos não são baratos, principalmente os roteadores da família ASR. A escolha final vai depender não apenas da capacidade em armazenar e processar a tabela de roteamento, mas também da vazão dos links que implica na quantidade de pacotes por segundo (pps) que trafegarão através das interfaces do roteador. Por isso é importante estar atento às especificações do roteador para ter certeza de que o equipamento será adequado para as necessidades da empresa.

A recomendação para amenizar o "problema"do custo dos reoteadores é que o ISP envie apenas uma rota default, caso a empresa não tenha interesse em praticar engenharia de tráfego, ou apenas a tabela parcial com aquelas rotas originadas pelo próprio provedor. O que aconteceria se repentinamente, por qualquer motivo, a operadora começasse a anunciar mais rotas do que estava previsto para sua caixa aguentar? É nesse contexto que a limitação de aprendizado de prefixos pode ser um recurso bem útil!

Obs: Esse problema também poderia ser facilmente resolvido através da inserção de um filtro de entrada que permita apenas aquelas rotas previamente previstas de serem anunciadas pelo ISP.

Como o cenário é mais complexo do que realmente seria necessário para demonstrar essa simples configuração, utilizarei como referência apenas o roteador R1 da empresa detentora do AS 123. As linhas apresentadas abaixo são necessárias para limitar o aprendizado de prefixos em R1 através de R4 .

R1(config)# router bgp 123
R1(config-router)# neighbor 10.0.4.2 remote-as 40
R1(config-router)# neighbor 10.0.4.2 maximum-prefix 10 50 restart 2
R1(config-router)# end

Observem no destaque em amarelo que o primeiro parâmetro de maximum-prefix representa o limite de prefixos que será permitido na vizinhança, de forma que em caso de violação desse limite o roteador será forçado a terminar a sessão BGP. Neste exemplo, limitamos o aprendizado a 10 prefixos, lembrando que no laboratório há 7 prefixos sendo anunciados por R6. O segundo parâmetro define uma porcentagem que, quando atingida, fará com que o roteador passe a registrar mensagens de log alertando que a quantidade de prefixos recebidos está próxima do limite anteriormente definido. Por fim, o parâmetro restart define o tempo (em minutos) para que uma nova sessão BGP seja restabelecida depois de uma queda por motivo de violação ao limite de prefixos. 

Após essa configuração, o roteador R1 está recebendo 7 prefixos do limite de 10, condição que corresponde a mais que 50% e implica no registro de mensagens de log para alertar o administrador. Neste ponto, o sistema do R1 passa a exibir a seguinte mensagem no console:

%BGP-4-MAXPFX: No. of prefix received from 10.0.4.2 (afi 0) reaches 7, max 10

Na sequência, apenas para mostrar que a configuração funciona, adicionarei e anunciarei novas rotas em R6 (omitido), para que o limite de anúncios em R1 seja propositalmente violado. Observem abaixo a saída das mensagens de console em R1 quando o vizinho BGP ultrapassa o limite de anúncios permitidos.

%BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.4.2 (afi 0): 11 exceed limit 10
%BGP-5-ADJCHANGE: neighbor 10.0.4.2 Down BGP Notification sent

Obs.: Também é possível adicionar o parâmetro warning-only para que apenas mensagens de log sejam exibidas e/ou registradas pelo sistema, sem que a vizinhança BGP seja terminada. No entanto, a ação de terminar a sessão BGP ao receber rotas além daquilo que foi pré-definido pelo administrador é importante para não comprometer o desempenho do roteador. Lembrem-se de que a recepção repentina de milhares de rotas certamente demandaria uso de memória e de processamento, sendo a capacidade da caixa pode não ser adequada para lidar com rotas além da previsão. 

Simples assim, façam seus testes...

Samuel.