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.

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. 

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.

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 deny   2001:db8::/32  le 128
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 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 prefix-list 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...

http://www.team-cymru.org/bogon-reference-http.html

Façam seus testes...

Samuel.

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.