Prefix List, Distribute List e Route Maps

Olá Pessoal Boa Tarde, hoje vou tratar sobre prefix-list, distribute list route maps e alguns exemplos..espero que gostem, lembrando que o mesmo post pode ser encontrado no meu blog pessoal https://ciscoandlinux.wordpress.com/2018/02/28/prefix-list-distribute-list-e-route-maps/

Prefix List

Os prefix list , servem para poder fazer match de redes, ou grupos de redes. Ao igual que as access list elas tem números de sequência. A execução é feita do menor ao maior número de sequência, e também existe um deny implícito no final. Geralmente você utiliza de duas formas: Primeira forma de utilização:

ip prefix-list Nome_Prefix_List seq Numero_Sequencia deny|permit a.b.c.d/len

O formato acima é utilizado quando se deseja fazer match de uma rede específica. Aqui a variavél "len", é a máscara da rede. Exemplo: Gostaria de fazer match da rede 192.168.100.0/24

ip prefix-list MINHA_REDE seq 5 permit 192.168.100.0/24

Segunda forma de utilização:

ip prefix-list Nome_Prefix_List seq Numero_Sequencia deny|permit a.b.c.d/len ge X le Y

Aqui "len", somente me indica quantos bits vou fazer match do endereço de rede a.b.c.d. "X" me diz qual é o valor mínimo da máscara de rede, e "Y" qual é o valor máximo da máscara de rede. Os acrônimos ge e le, significam "greater ou equal", maior ou igual e "less or equal", menor ou igual. 

Exemplo: Gostaria de fazer match de toda a classe B, classful: Analisando o primeito octeto:

Classe B : 1000 000 - 128
           1011 111 - 191

Somente me interessa fazer match dos primeiros 2 bits. E como a máscara de uma classe B classful é de 16 bits, então minha prefix-list ficaria:

ip prefix-list CLASSEB_FULL seq 5 permit 128.0.0.0/2 ge 16 le 16

E se eu quiser fazer match de toda a ClasseB incluindo subnetting: Ao incluir subnetting a máscara de rede para uma classe B pode variar de 16 até 32.

ip prefix-list CLASSEB_SUBNET seq 5 permit 128.0.0.0/2 ge 16 le 32

Outro exemplo:

Gostaria de fazer match de todas as redes.

Ao querer fazer match de todas as redes, não me interessa nenhum bit então ficaria 0.0.0.0/0. Me interessa todas as possivéis máscaras de rede então preciso utilizar um "le 32", que se traduz em considera todas as máscara de redes menores ou iguais a /32. Minha prefix list ficaria:

ip prefix-list ALL_NETWORKS seq 5 permit 0.0.0.0/0 le 32

Distribute List

As distribute-list serve para filtrar rotas, sejam elas rotas que estou recevendo (in), ou rotas que estou enviando (out).


 


Da figura acima, o Roteador R1, foi configurado com uma distribute-list do tipo IN para filtrar a rota ROTA2, o resultado é que R1 não instala dita rota na sua routing table, e em consequência não propaga a rota para seus vizinhos. Do outro lado R1 foi configurado com uma distribute-list do tipo OUT entre R1 e R2 para filtrar a ROTA2, o resultado é que R1 instala na sua routing table ambas as rotas, porém ele somente envia a ROTA1 para o seu vizinho R1. Uma observação a ser feita aqui, para os protocolos Link State, como OSPF e IS-IS, eles utilizam uma base de dados de topologia LSDB para poder obter informação sobre os links do seus vizinhos, de tal forma que todos os roteadores precisam ter a mesma informação para poder ter uma topologia consistente. Então em um protocolo Link State, quando você aplica uma distribute-list você somente esta filtrando as rotas da routing table e não da LSDB. Vamos ver um exemplo, utilizemos o protocolo RIP que é bem simples
de utilizar:


  

No diagrama de rede acima, todos os roteadores executam RIPv2. Vejamos as tabelas de roteamento:

R1:

R1(config-router)#do sh ip route rip | Inc ^R
R 1.1.1.0 [120/1] via 172.16.1.2, 00:00:12, Ethernet0/2
R 1.1.2.0 [120/1] via 172.16.1.2, 00:00:12, Ethernet0/2
R 1.1.3.0 [120/1] via 172.16.1.2, 00:00:12, Ethernet0/2
R 4.4.4.0 [120/1] via 172.16.1.2, 00:00:12, Ethernet0/2
R1(config-router)#

R2:

R2(config-router)#do sh ip route rip | Inc ^R
R 1.1.1.0 [120/2] via 192.168.100.1, 00:00:18, Ethernet0/0
R 1.1.2.0 [120/2] via 192.168.100.1, 00:00:18, Ethernet0/0
R 1.1.3.0 [120/2] via 192.168.100.1, 00:00:18, Ethernet0/0
R 4.4.4.0 [120/2] via 192.168.100.1, 00:00:18, Ethernet0/0
R 10.10.10.0 [120/1] via 192.168.100.1, 00:00:18, Ethernet0/0
R 172.16.1.0 [120/1] via 192.168.100.1, 00:00:18, Ethernet0/0
R2(config-router)#

R3:

R 1.1.1.0 [120/2] via 10.10.10.1, 00:00:11, Ethernet0/1
R 1.1.2.0 [120/2] via 10.10.10.1, 00:00:11, Ethernet0/1
R 1.1.3.0 [120/2] via 10.10.10.1, 00:00:11, Ethernet0/1
R 4.4.4.0 [120/2] via 10.10.10.1, 00:00:11, Ethernet0/1
R 172.16.1.0 [120/1] via 10.10.10.1, 00:00:11, Ethernet0/1
R 192.168.100.0/24 [120/1] via 10.10.10.1, 00:00:11, Ethernet0/1

Os três roteadores recebem as rotas de loopback. Vamos filtrar agora em R1, as rede de loopback0,1,2 de R4, para isso vamos utilizar uma prefix-list em conjunto com uma distribute list. Analisemos os endereços de LoopBack:

1.1.1.1 - 1.1.0000 0001.1
1.1.2.1 - 1.1.0000 0010.1
1.1.3.1 - 1.1.0000 0011.1

Dessa forma me interessa fazer match aos primeiros 22 bits, e uma máscara de 24 bits. Vou ter duas linhas na prefix-list a primeira para filtrar as loopback (deny), e a segunda para permitir o resto.

ip prefix-list LOOPBACKS seq 5 deny 1.1.0.0/22 ge 24 le 24
ip prefix-list LOOPBACKS seq 10 permit 0.0.0.0/0 le 32

Aplicando em R1:

R1(config-router)#distribute-list prefix LOOPBACKS in
R1(config-router)#do sh ip route rip | Inc ^R
R 4.4.4.0 [120/1] via 172.16.1.2, 00:00:17, Ethernet0/2
R1(config-router)#

Como esperado em R1 somente aparece a rota para a rede 4.4.4.0. Vejamos em R2 e R3:

R2#sh ip route | inc ^R
R 4.4.4.0 [120/2] via 192.168.100.1, 00:00:24, Ethernet0/0
R 10.10.10.0 [120/1] via 192.168.100.1, 00:00:24, Ethernet0/0
R 172.16.1.0 [120/1] via 192.168.100.1, 00:00:24, Ethernet0/0
R2#

R3#sh ip route rip | inc ^R
R 4.4.4.0 [120/2] via 10.10.10.1, 00:00:09, Ethernet0/1
R 172.16.1.0 [120/1] via 10.10.10.1, 00:00:09, Ethernet0/1
R 192.168.100.0/24 [120/1] via 10.10.10.1, 00:00:09, Ethernet0/1
R3#

As rotas também não aparecem em R2,R3 isso porque R1 não as propago para eles. Vejamos outro exemplo, dessa vez vamos filtrar as rotas de forma que R2 não receba as mesmas.

R1(config-router)#distribute-list prefix LOOPBACKS out ethernet 0/0
R1(config-router)#

Mandamos um clear ip route *, para atualizar. Vejamos como ficaram as rotas:

R1:

R1(config-router)#do sh ip route rip | Inc ^R 
R 1.1.1.0 [120/1] via 172.16.1.2, 00:00:23, Ethernet0/2
R 1.1.2.0 [120/1] via 172.16.1.2, 00:00:23, Ethernet0/2
R 1.1.3.0 [120/1] via 172.16.1.2, 00:00:23, Ethernet0/2
R 4.4.4.0 [120/1] via 172.16.1.2, 00:00:23, Ethernet0/2
R1(config-router)#

R2:

R2#sh ip route | inc ^R
R 4.4.4.0 [120/2] via 192.168.100.1, 00:00:14, Ethernet0/0
R 10.10.10.0 [120/1] via 192.168.100.1, 00:00:14, Ethernet0/0
R 172.16.1.0 [120/1] via 192.168.100.1, 00:00:14, Ethernet0/0
R2#

R3:

R3#sh ip route rip | inc ^R
R 1.1.1.0 [120/2] via 10.10.10.1, 00:00:04, Ethernet0/1
R 1.1.2.0 [120/2] via 10.10.10.1, 00:00:04, Ethernet0/1
R 1.1.3.0 [120/2] via 10.10.10.1, 00:00:04, Ethernet0/1
R 4.4.4.0 [120/2] via 10.10.10.1, 00:00:04, Ethernet0/1
R 172.16.1.0 [120/1] via 10.10.10.1, 00:00:04, Ethernet0/1
R 192.168.100.0/24 [120/1] via 10.10.10.1, 00:00:04, Ethernet0/1
R3#

Como esperado, R1 esta filtrando as rotas na saída para R2 :).

Route Maps

As route-maps, vendría a ser como uma sequência de condicionais "if....then". Cada condição na route-map tem um número de sequência. A ordem de execução da route map é do menor ao maior número de sequência, similar as access-list. As route-map tem as ações de deny/permit similar as access-list, assim como um deny implícito no final. O deny e o permit de uma route-map tem um significado diferente dependendo se você vai utilizar para filtering, redistribution, PBR. As route maps, oferecem opções que não são possíveis via access-list, como por exemplo modificar os atributos de BGP. Vejamos um exemplo, para o caso de filtering: Vou trocar o protocolo para OSPF em vez de RIP

Rx:
Rx(config)#no router rip
Rx(config)#router ospf 1
Rx(config)#network 0.0.0.0 255.255.255.255 area 0

Em R4 Modificar as interfaces de LoopBack para point-to-point

R4(config)#int loX
R4(config)#ip ospf network point-to-point

Rotas em R1, R2 e R3:

R1:

R1(config-router)#do sh ip route ospf | Inc ^O 
O 1.1.1.0 [110/11] via 172.16.1.2, 00:02:22, Ethernet0/2
O 1.1.2.0 [110/11] via 172.16.1.2, 00:02:22, Ethernet0/2
O 1.1.3.0 [110/11] via 172.16.1.2, 00:02:22, Ethernet0/2
O 4.4.4.0 [110/11] via 172.16.1.2, 00:02:22, Ethernet0/2
R1(config-router)#

R2:

R2(config-router)#do sh ip route ospf | Inc ^O
O 1.1.1.0 [110/21] via 192.168.100.1, 00:02:49, Ethernet0/0
O 1.1.2.0 [110/21] via 192.168.100.1, 00:02:49, Ethernet0/0
O 1.1.3.0 [110/21] via 192.168.100.1, 00:02:49, Ethernet0/0
O 4.4.4.0 [110/21] via 192.168.100.1, 00:02:49, Ethernet0/0
O 10.10.10.0 [110/20] via 192.168.100.1, 00:03:11, Ethernet0/0
O 172.16.1.0 [110/20] via 192.168.100.1, 00:03:11, Ethernet0/0
R2(config-router)#

R3:

R3(config-router)#do sh ip route ospf | Inc ^O
O 1.1.1.0 [110/21] via 10.10.10.1, 00:00:32, Ethernet0/1
O 1.1.2.0 [110/21] via 10.10.10.1, 00:00:32, Ethernet0/1
O 1.1.3.0 [110/21] via 10.10.10.1, 00:00:32, Ethernet0/1
O 4.4.4.0 [110/21] via 10.10.10.1, 00:00:32, Ethernet0/1
O 172.16.1.0 [110/20] via 10.10.10.1, 00:00:42, Ethernet0/1
O 192.168.100.0/24 [110/20] via 10.10.10.1, 00:00:42, Ethernet0/1
R3(config-router)#

Vou utilizar uma route-map para filtrar as rotas de loopback em R1: Primeiro vou definir uma prefix-list que faça match com as redes de loopback que vamos filtrar:

ip prefix-list FILTERING_ROUTEMAP seq 5 permit 1.1.0.0/22 ge 24 le 24

E a route-map ficaria:

route-map FILTERING deny 5
 match ip address prefix-list FILTERING_ROUTEMAP
!
route-map FILTERING permit 10

Interessante notar que quem faz o "deny" é a route-map, por isso que na prefix-list colocamos "permit". A última linha da route-map vai deixar passar o resto das redes. Aplicando em R1:

R1(config)#router ospf 1 
R1(config-router)#distribute-list route-map FILTERING in 
R1(config-router)#

Vejamos a routing table:

R1#sh ip route ospf | Inc ^O
O 4.4.4.0 [110/11] via 172.16.1.2, 00:00:32, Ethernet0/2
R1#

R2#sh ip route ospf | Inc ^O
O 1.1.1.0 [110/21] via 192.168.100.1, 00:00:39, Ethernet0/0
O 1.1.2.0 [110/21] via 192.168.100.1, 00:00:39, Ethernet0/0
O 1.1.3.0 [110/21] via 192.168.100.1, 00:00:39, Ethernet0/0
O 4.4.4.0 [110/21] via 192.168.100.1, 00:00:39, Ethernet0/0
O 10.10.10.0 [110/20] via 192.168.100.1, 00:00:39, Ethernet0/0
O 172.16.1.0 [110/20] via 192.168.100.1, 00:00:39, Ethernet0/0
R2#

R3#sh ip route ospf | Inc ^O
O 1.1.1.0 [110/21] via 10.10.10.1, 00:00:55, Ethernet0/1
O 1.1.2.0 [110/21] via 10.10.10.1, 00:00:55, Ethernet0/1
O 1.1.3.0 [110/21] via 10.10.10.1, 00:00:55, Ethernet0/1
O 4.4.4.0 [110/21] via 10.10.10.1, 00:00:55, Ethernet0/1
O 172.16.1.0 [110/20] via 10.10.10.1, 00:00:55, Ethernet0/1
O 192.168.100.0/24 [110/20] via 10.10.10.1, 00:00:55, Ethernet0/1
R3#

A distribute-list funcionou ela filtro as rotas em R1, porém R2 e R3 continuam com as rotas de loopback. Isso acontece porque agora o protocolo de roteamento é um link state, e a distribute-list somente apago as rotas da RIB em R1 e não da LSDB, a verdade não existe mecanismo de apagar na LSDB. Se vocês analisarem a LSDB de R1 ela provavélmente contem os LSAs das loopback, vamos verificar:

R1#sh ip ospf database router adv-router 4.4.4.4 | Inc (Link ID) 
 (Link ID) Network/subnet number: 1.1.1.0
 (Link ID) Network/subnet number: 1.1.2.0
 (Link ID) Network/subnet number: 1.1.3.0
 (Link ID) Network/subnet number: 4.4.4.0
 (Link ID) Designated Router address: 172.16.1.2
R1#

Eles estão lá na LSDB. Agora modificamos nossa topologia para utilizar a route-map para redistribuição:


   


A configuração de R1 ficaria:

R1#sh run | section router
router ospf 1
 network 10.10.10.1 0.0.0.0 area 0
 network 192.168.100.1 0.0.0.0 area 0
router rip
 version 2
 network 172.16.0.0
 no auto-summary
R1#

Agora gostariamos de redistribuir únicamente a rota 4.4.4.0/24 do RIP para o OSPF, e tambem queremos tagear as rota com o valor de 120. A prefix-list a utilizar seria:

R1(config)#ip prefix-list R4_LOOPBACK4 seq 5 permit 4.4.4.0/24 
R1(config)#

E a route-map:

route-map RIP->OSPF permit 5
 match ip address prefix-list R4_LOOPBACK4
 set tag 120

O deny implícito da route-map vai se encarregar de não redistribuir as outras rotas. O "set" irá tagear as rotas redistribuidas com o valor de 120 vejamos as rotas em R2 e R3:

R2#sh ip route | Inc ^O
O E2 4.4.4.0 [110/20] via 192.168.100.1, 00:00:18, Ethernet0/0
O 10.10.10.0 [110/20] via 192.168.100.1, 00:10:56, Ethernet0/0
R2#

R3#sh ip route | Inc ^O
O E2 4.4.4.0 [110/20] via 10.10.10.1, 00:00:29, Ethernet0/1
O 192.168.100.0/24 [110/20] via 10.10.10.1, 00:29:37, Ethernet0/1
R3#

Vejamos se o tag foi setado:

R2#sh ip route 4.4.4.0 
Routing entry for 4.4.4.0/24
 Known via "ospf 1", distance 110, metric 20
 Tag 120, type extern 2, forward metric 10
 Last update from 192.168.100.1 on Ethernet0/0, 00:01:53 ago
 Routing Descriptor Blocks:
 * 192.168.100.1, from 192.168.100.1, 00:01:53 ago, via Ethernet0/0
 Route metric is 20, traffic share count is 1
 Route tag 120
R2#

Beleza!..Por hoje é isso ai, vocês podem brincar com route-maps para PBR ou para BGP por exemplo.

Abcs Jose          

FUNDAMENTOS DE IOS-XR - UTILIZANDO A FAMILIA ASR 9000 COMO ROUTER DE BORDA

Descrição:

Os roteadores da família Cisco ASR tem ganho cada vez mais espaço entre os Provedores de Internet brasileiros. Isto se deve tanto aos preços cada vez mais acessíveis destas caixas quanto ao crescente poder de processamento que elas entregam. Há uma carência de profissionais capacitados a operar equipamentos baseados em IOS-XR, o qual possui muitas diferenças do IOS tradicional, os cursos oficiais são muito escassos e de custo elevado. Este curso visa capacitar o aluno a operar um roteador com IO-XR, configurar roteamento estático e dinâmico, criar filtros e listas de controle de acesso, além de implementar CG-NAT e guarda de logs.

Metodologia E-Doing (Aprenda Fazendo):

Os alunos irão construir um cenário a partir do zero, levantando todas as configurações, de modo a ter um exemplo de Sistema Autônomo BGP Multi-homing com Roteador de Borda Cisco ASR virtualizado no ambiente EVE-ng.

Conteúdo Programático:

Aula 01 - Introdução ao IOS XR , Configuração Básica e criação de ACLs
Aula 02 - Roteamento Estático e Dinâmico, Protocolo OSPF em área única e múltiplas áreas
Aula 03 - Protocolo BGP - vizinhanças iBGP e eBGP, Atributos BGP
Aula 04 - Route Filtering – Politicas AS-IN e AS-OUT (IPv4 e IPv6), NAT 444 e guarda de logs

Diferenciais:

Uso do Emulador EVE (Emulated Virtual Environment) que permite a criação de cenários Multivendor com soluções de dezenas de fabricantes. Os alunos poderão baixar e criar seu próprio servidor local, de modo a utiliza-lo para testes e homologação de cenários de Redes Reais.

Periodo:

Dias 02, 03, 04 e 05/04/2018 - das 08:00 as 17:00 - com intervalo de 01 hora para almoço e coffee-breaks nos períodos da manhã e tarde

Investimento:

R$ 1.356,00 (Não Associado ANID)
R$ 1.156,00 (Associado ANID)

Mini-Curriculum do Instrutor:

·Adilson Aparecido Florentino é Tecnólogo em Processamento de Dados pela Universidade Mackenzie e Especialista em Redes de Computadores pela FASP - Faculades Associadas de São Paulo. Atua como Instrutor Cisco desde 2001, primeiro no Programa Cisco Network Academy e atualmente como Instrutor Cisco CCSI # 33706.Possui as Certificações CCNA RS, CCNA Voice, CCNA Security, CCNA Wireless, CCDA, CCDP e CCNP RS.

·Fundador e CEO da EAMSOFT Consultoria e Treinamento em Informática Ltda. Atuou como Professor Universitário em diversas Instituições de Ensino tais como FATEC, IFSP, UNICID, FIAP e IBTA. Prestador de SErviços para o NIC.br nos cursos de IPv6 e Boas Práticas em BGP

·Autor do Livro IPv6 na Prática - primeiro livro em português sobre o tema. Consultor independente atuando em várias empresas em Projetos de Rede e treinamento utilizando roteadores Cisco, Juniper e Mikrotik

Vagas Limitadas! garanta já a sua clicando aqui.

Lab-LD - conheça a Rede Nacional de Laboratórios de Tecnologia contra a Lavagem de Dinheiro

O Laboratório de Tecnologia contra Lavagem de Dinheiro (LAB-LD) é resultado da meta 16 da Estratégia Nacional de Combate à Corrupção e à Lavagem de Dinheiro - Enccla 2006, que previa a necessidade de “implantar laboratório modelo para a aplicação de soluções de análise tecnológica em grandes volumes de informações e para a difusão de estudos sobre as melhores práticas em hardware, software e a adequação de perfis profissionais”.

O LAB-LD foi instalado em 2007, por intermédio de convênio entre o Ministério da Justiça e o Banco do Brasil, dentro da estrutura do Departamento de Recuperação de Ativos e Cooperação Jurídica Internacional (DRCI) da atual Secretaria Nacional de Justiça e Cidadania (SNJ).
A motivação para a criação do LAB-LD surgiu da observação, pelos órgãos participantes da Enccla, de que as investigações de casos de lavagem de dinheiro ou corrupção envolviam quebras de sigilo bancário de inúmeras contas, além de sigilos telefônico e fiscal, abrangendo grandes períodos.

Isso gerava uma grande massa de dados a ser analisada e, muitas vezes, as investigações e análises financeiras eram conduzidas sem a necessária especialização técnica.

Como o projeto deste primeiro LAB-LD foi bem-sucedido, o Ministério da Justiça e Segurança Pública, por intermédio do DRCI/SNJ, iniciou em 2009 a replicação do modelo para outros Órgãos Estaduais e Federais. O conjunto destes Laboratórios forma a Rede Nacional de Laboratórios de Tecnologia (Rede-Lab), hoje presente em todos os estados brasileiros.

A REDE-LAB

Instituída pela Portaria SNJ nº 242 de 29 de setembro de 2014, a Rede Nacional de Laboratórios de Tecnologia (REDE-LAB) é o conjunto de Laboratórios de Tecnologia contra Lavagem de Dinheiro instalados no Brasil.

Sua principal característica é o compartilhamento de experiências, técnicas e soluções voltadas para a análise de dados financeiros, e, também, para a detecção da prática da lavagem de dinheiro, corrupção e crimes relacionados.

O LAB-LD instalado no Ministério da Justiça e Segurança Pública, no DRCI/SNJ, é o órgão gestor da REDE-LAB, servindo como unidade modelo e, também, definindo as ações de aprimoramento dos demais Laboratórios.

Atualmente, a REDE-LAB conta com 58 unidades, sendo 45 em operação e outras 13 em instalação.

A contribuição da Tecnologia da Informação no Combate a Corrupção no Brasil

A REDE-LAB já contribuiu, desde a sua criação, para a recuperação de cerca de 44 bilhões de reais. O investimento na infraestrutura necessário para manter o projeto ativo representa menos de 1% deste valor. Atuando na Análise de dados, ligações e localização de celulares e muito mais, a Rede tornou possível realizar com muito mais rapidez e precisão o levantamento de Informações necessárias para que a Operação Lava-Jato pudesse se tornar o que é hoje.

Fontes:
www.justica.gov.br/sua-protecao/lavagem-de-dinheiro/LAB-LD

https://noticias.uol.com.br/cotidiano/ultimas-noticias/2018/01/15/rede-de-laboratorios-investiga-lavagem-de-dinheiro-no-brasil-em-dez-anos-foram-r-44-bilhoes.htm

Saiba onde estão os Root Servers DNS espalhados pelo mundo

Os Servidores DNS raiz estão espalhados por todo o mundo e são responsáveis pela tradução de nomes em primeiro nível -Quando sua máquina local não tem em cache um IP (v4 ou v6) para um determinado nome, ela solicita a tradução do mesmo para um Servidor DNS local, este, por sua vez, pode fazer uma consulta ao Servidor Raiz mais próximo na Internet para resolver o nome. Hoje são 13 Servidores diferentes mantidos por 12 Instituições independentes. Quer dizer que se um Servidor Raiz cair, um bom pedaço da Internet vai ficar sem tradução de nomes? Nda disso, como podemos ver no mapa acimna. Alguns Servidores Raiz tem mais de 100 espelhos ou instâncias espalhadas pelo Globo. No Brasil, inclusive, temos várias instâncias instaladas.

Servidores Raiz usam Endereços AnyCast para se tornarem conhecidos. Isso quer dizer que o mesmo endereço IP pode ser anunciado em diferentes localidades. A Instância mais próxima responde as Consultas. Hoje a maioria destes Servidores suportam tanto IPv4 quanto IPv6, mas ainda temos Resolvers IPv4 Only.

Para saber mais a respeito dos Servidores DNS Raiz, visite: http://www.root-servers.org/

Have Fun!!!

SNMP

Olá Pessoal Boa Tarde, hoje vou falar sobre SNMP, que é um protocolo de gerenciamento bastante utilizados em dispositivos de redes.

Também convido vocês a visitar o meu blog pessoal https://ciscoandlinux.wordpress.com/, onde estarei postando tópicos relacionados à certificação CCNA R&S...

SNMP é o acrônimo de Simple Network Management Protocol, como seu nome diz ele é um protocolo de gerenciamento, utilizado para coletar e ou receber informação de um elemento gerenciado.

SNMP armazena informações do elemento em uma pequena base de dados chamada de MIB, Management Information Base. A MIB é uma coleção de informação organizada hierárquicamente, dados como CPU, Memora, Quantidade Interfaces etc podem ser armazenadas na MIB.

Existem dois tipo de objetos dentro de uma MIB, escalares e tabulares. Objetos escalares estão associados a uma única instância, enquanto objetos tabulares contem várias instancias agrupadas em tabela.

Exemplo, um objeto escalar pode ser a data desde quando um dispositivo esta rodando, p.e sysUpTime, a única instância que temos é o tempo transcurrido.

jose@rejane:~/CCIE$ snmpwalk -v 2c -c public 192.168.200.1 SNMPv2-MIB::sysUpTime
SNMPv2-MIB::sysUpTime.0 = Timeticks: (55858) 0:09:18.58
jose@rejane:~/CCIE$

Um objeto tabular pode ser as interfaces de um roteador, onde cada linha da tabela é uma instancia, e cada coluna uma variavél, p.e ifTable.

jose@rejane:~/CCIE$ snmptable -v 2c -c public 192.168.200.1 IF-MIB::ifTable
SNMP table: IF-MIB::ifTable

ifIndex ifDescr ifType ifMtu ifSpeed ifPhysAddress ifAdminStatus ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ifInDiscards ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts ifOutDiscards ifOutErrors ifOutQLen ifSpecific
 1 Ethernet0/0 ethernetCsmacd 1500 10000000 aa:bb:cc:0:2:0 up up 0:0:01:59.02 23733 212 ? 0 0 2 34321 251 ? 0 0 ? ?
 2 Ethernet0/1 ethernetCsmacd 1500 10000000 aa:bb:cc:0:2:10 up up 0:0:02:09.90 0 0 ? 0 0 0 4928 32 ? 0 0 ? ?
 3 Ethernet0/2 ethernetCsmacd 1500 10000000 aa:bb:cc:0:2:20 down down 0:0:00:11.38 0 0 ? 0 0 0 0 0 ? 0 0 ? ?
 4 Ethernet0/3 ethernetCsmacd 1500 10000000 aa:bb:cc:0:2:30 down down 0:0:00:11.40 0 0 ? 0 0 0 0 0 ? 0 0 ? ?

Dentro da MIB cada objeto tem um identificador, chamado de OID Object Identifiers. Um OID indentifica de forma única um objeto dentro da MIB.

A MIB é organizada de forma hierárquica, onde cada nível representa uma "organização".



Se diz que uma MIB é como se fosse uma árvore, que vai se expandendo na medida que descemos os níveis.

Na árvore da MIB o OID, identificaria a folha onde queremos procurar alguma informação. O OID é
formado pela concatenação dos diferentes níveis da MIB pelos quais passamos até chegar na folha desejada.

Exemplo se queremos ir para a folha da Cisco, precisamos ir para o OID="iso.org.dod.internet.private.enterprise.cisco", numericamente o equivalente seria OID="1.3.6.1.4.1.9".

Uma empresa privada que desenvolve uma MIB, solicita e lhe é assignada um número dentro do OID="iso.org.dod.internet.private.enterprise".

Os OIDs dentro da MIB, são definidos nos chamados arquivos MIBs, geralmente tem extensão .my ou .mib , eles são disponibilizados pelo fornecedor.

Dentro de um elemento gerenciado via SNMP, esta sendo executado o que se chama de SNMP Agent, agente SNMP, que é um software que se encarrega de coletar à informação do elemento e ir armazenando os valores na MIB. O agente SNMP responde quando um servidor chamado de SNMP Manager, gerente SNMP, executa alguma query na MIB via comando SNMP. O agente SNMP também tem como função enviar eventos que acontecem no elemento ao SNMP Manager, ditos eventos são chamados de traps.

Algumas das operações básicas utilizadas em SNMP, para poder ler e escrever na MIB são:

• GET - Serve para ler o valor associado a um determinado OID.
• GETNEXT -  Serve para ler o valor do próximo OID.
• SET - Serve para modificar o valor associado a um determinado OID.
• TRAP - Quando um evento ou erro acontece no elemento gerenciado o agente SNMP envia um "trap" ao gerente SNMP.
• RESPONSE - é o resultado que o agente SNMP devolve ao gerente SNMP, depois de uma operação GET,GETNEXT, ou SET. Quando é GET, GETNEXT ele devolve o valor solicitado, quando é SET ele devolve o valor modificado.

O protocolo SNMP, utiliza UDP e as portas 161 e 162. A porta 161 são para as operações de GET, SET, RESPONSE e a 162 para os TRAPs.

Um gerente SNMP, se encarrega de coletar informação SNMP de diferentes fornecedores, Cisco, Juniper, Arista etc. Para isso ele precisa saber qual OID pertence à qual fornecedor , também precisa saber como decodificar as traps que chegam. Para isso são utilizados os arquivos MIB disponibilizados pelo fornecedor, as quais precisam ser carregadas no Gerente SNMP. O Gerente SNMP também recebe o nome de NMS Network Management Station.
Existem três versões de SNMP:

• SNMPv1 - é a versão inicial do protocolo SNMP RFC-1028, não é utilizado nenhum tipo de encriptação para enviar os dados, somente autenticação via um string de texto chamado de "community". SNMPv1 utiliza variavéis tipo contador de no máximo 32 bits, o que nos tempos atuais não é muito aplicavél. Como já falado ele utiliza UDP portas 161/162.
• SNMPv2c - é a versão mais utilizada nos dias de hoje, a diferençã básica é com SNMPv1é que agora existem contadores de 64 bits.
• SNMPv3 - essa versão traz grande melhoria em termos de segurança, agora encriptação das mensagens SNMP é possivél, assim como diferentes niveis de segurança. Explicarei esses detalhes um pouco mais adiante.

Agora que temos uma base teórica, vamos configurar o SNMPv2c e SNMPv3 em um roteador de teste:

O Manager SNMP será minha laptop.

Configurando SNMPv2c

SNMPv2c precisa autenticar via um string chamado de "community", além disso um pode configurar o acesso à MIB somente de leitura ou de leitura e escritura.

R1(config)#snmp-server community CISCO rw 
R1(config)#

A community utilizada é "CISCO" e vamos liberar o acesso à MIB de leitura e escrita rw.

Agora vou coletar informação do objeto sysName, ele é um objeto que existe dentro de qualquer elemento gerenciado via SNMP, o OID do sysName "1.3.6.1.2.1.1.5.0" faz parte de uma MIB chamada SNMPv2-MIB que é uma MIB padrão.

jose@rejane:~/CCIE$ snmpget -v 2c -c CISCO 192.168.200.1 1.3.6.1.2.1.1.5.0
iso.3.6.1.2.1.1.5.0 = STRING: "R1"
jose@rejane:~/CCIE$

Beleza, eu também posso em vez de utilizar o OID númerico, utilizar o nome do OID. Para isso eu preciso carregar a MIB no Manager, para propósitos de teste eu vou carregar a MIB OSPF-MIB e vou coletar informação do objeto tabular ospfAreaTable

jose@rejane:/usr/share/apps/snmpb/mibs$ snmptable -v 2c -c CISCO 192.168.200.1 OSPF-MIB::ospfAreaTable
SNMP table: OSPF-MIB::ospfAreaTable

ospfAreaId ospfAuthType ospfImportAsExtern ospfSpfRuns ospfAreaBdrRtrCount ospfAsBdrRtrCount ospfAreaLsaCount ospfAreaLsaCksumSum ospfAreaSummary ospfAreaStatus ospfAreaNssaTranslatorRole ospfAreaNssaTranslatorState ospfAreaNssaTranslatorStabilityInterval ospfAreaNssaTranslatorEvents
 0.0.0.0 none importExternal 1 0 0 1 13093 sendAreaSummary active ? ? ? ?
jose@rejane:/usr/share/apps/snmpb/mibs$

Caso seja de interesse, eu estou utilizando os comandos Linux, "snmpget" para obter o valor de um OID específico, "snmpwalk" para poder obter os valores de toda uma árvore de OIDs, e "snmptable" que me traz os valores de um objeto tabular.

A grande maioria das vezes, o acesso a um elemento gerenciado é via um Manager ou NMS, então podemos ajustar o acesso via uma access-list.

R1(config)#ip access-list standard ACESSO-NMS 
R1(config-std-nacl)#permit host 192.168.200.2 
R1(config-std-nacl)#exit
R1(config)#snmp-server community CISCO rw ACESSO-NMS
R1(config)#

Agora vamos configurar os "traps", de forma a que R1 enviara ao Manager, no caso minha laptop, um evento que tenha acontecido em R1. O evento que vamos simular é a queda do OSPF entre R1 e R2:

R1(config)#snmp-server enable traps 
R1(config)#snmp-server host 192.168.200.2 traps CISCO
R1(config)#

Eu configurei o roteador para enviar qualquer trap, para o host 192.168.200.2 com o community CISCO, é possivél escolher quais traps queremos que sejam enviadas; quem sabe seja de nosso interesse somente o envio de traps BGP p.e

R1#sh snmp host 
R1#sh snmp host Notification 
host: 192.168.200.2 udp-port: 162 type: trapuser: CISCO security model: v1
R1#

R1#debug snmp packet  
R1#
R1#*Feb 19 18:40:27.859: SNMP: Queuing packet to 192.168.200.2
*Feb 19 18:40:27.859: SNMP: V1 Trap, ent ospfTrap.2, addr 192.168.200.1, gentrap 6, spectrap 2  
ospfGeneralGroup.1 = 192.168.200.1  
ospfNbrEntry.1 = 192.1.1.2  
ospfNbrEntry.2 = 0  
ospfNbrEntry.3 = 192.1.1.2  
ospfNbrEntry.6 = 1*Feb 19 18:40:28.113: SNMP: Packet sent via UDP to 192.168.200.2
*Feb 19 18:40:28.365: SNMP: Queuing packet to 192.168.200.2
*Feb 19 18:40:28.365: SNMP: V1 Trap, ent ospfTrap.2, addr 192.168.200.1, gentrap 6, spectrap 12  
ospfGeneralGroup.1 = 192.168.200.1  
ospfLsdbEntry.1 = 0.0.0.0  
ospfLsdbEntry.2 = 1  
ospfLsdbEntry.3 = 192.168.200.1  
ospfLsdbEntry.4 = 192.168.200.1
*Feb 19 18:40:28.368: SNMP: Queuing packet to 192.168.200.2
*Feb 19 18:40:28.368: SNMP: V1 Trap, ent ospfTrap.2, addr 192.168.200.1, gentrap 6, spectrap 13  
ospfGeneralGroup.1 = 192.168.200.1  
ospfLsdbEntry.1 = 0.0.0.0  
ospfLsdbEntry.2 = 2  
ospfLsdbEntry.3 = 192.1.1.1  
ospfLsdbEntry.4 = 192.168.200.1

De debug, Podemos ver os traps sendo enviados ao NMS.

Configurando SNMPv3

SNMPv3, adopta um modelo de segurança mais robusto, permitindo modelos de autenticação melhores e privacidade dos dados. SNMPv3 permite:

• Integridade da Mensagem
• Autenticação
• Encriptação

Framework de Segurança definido em SNMPv3:

Quando foi desenvolvido SNMPv3 tentou-se procurar uma relação entre as três versões de SNMP, v1, v2c e v3. Dessa forma foram definidos os seguintes modelos de segurança:

• Modelo SNMPv1
• Modelo SNMPv2c
• Modelo SNMPv3

Além disso foram definidos também três níveis de segurança:

• noAuthNoPriv - A autenticação é feita somente via usuário, não existe encriptação.
• authNoProv - Existe autenticação via MD5 ou SHA, não existe encriptação.
• authPriv - Existe autenticação MD5 ou SHA, e encriptação DES,3DES, AES.

Os modelos SNMPv1 e SNMPv2c somente suportam o nível "noAuthNoPriv". Enquanto que SNMPv3 suporta os três níveis de segurança.

Grupos os grupos definem as políticas de acesso à MIB, isso é feito via views, e as views contem os objetos da MIB as quais queremos ter acesso. O modelo e o nível de segurança é definido no Grupo.

Usuários um usuário é sempre atachado a um grupo, e é dele que herda o modelo e nível de segurança, porém qual tipo de autenticação, MD5 ou SHA, e qual modelo de encriptação, DES, 3DES ou AES, é definido por usuário.

Um pode configurar por exemplo SNMPv2c utilizando o framework de segurança definido em SNMPv3, porém nesse caso o usuário vendria a ser a "community".

Vamos configurar SNMPv3 em nosso roteador R1:

Configurando o grupo NMSACCESS, com acesso à todas as MIBs para leitura e com um nível de segurança authPriv:

R1(config)#snmp-server group NMSACCESS v3 priv 
R1(config)#

Configurando o usuário NMS1 pertencente ao grupo NMSACCESS com autenticação SHA e encriptação DES. O usuário NMS1 vai ter dois passwords um para autenticação e outro para encriptação, no exemplo eu escolhi CISCO123.

R1(config)#snmp-server user NMS1 NMSACCESS v3 auth sha CISCO123 priv des CISCO123 
R1(config)#

Vejamos alguns comandos show para verificação:

R1#sh snmp group 
groupname: ILMI security model:v1 
contextname:  storage-type: permanent
readview : *ilmi writeview: *ilmi 
notifyview:  
row status: active

groupname: ILMI security model:v2c 
contextname:  storage-type: permanent
readview : *ilmi writeview: *ilmi 
notifyview:  
row status: active

groupname: NMSACCESS security model:v3 priv 
contextname:  storage-type: nonvolatile
readview : v1default writeview:  
notifyview:  
row status: active

R1#

R1#sh snmp user 
User name: NMS1
Engine ID: 800000090300AABBCC000200
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: NMSACCESS
R1#

Fazemos um teste de coletar o OID sysName:

jose@rejane:/var/log$ snmpget -v 3 -l authPriv -u NMS1 -a SHA -A CISCO123 -x DES -X CISCO123 192.168.200.1 1.3.6.1.2.1.1.5.0
iso.3.6.1.2.1.1.5.0 = STRING: "R1"
jose@rejane:/var/log$

Podemos também utilizar uma view, para restringir o acesso a alguns objetos da MIB, vamos restringir o acesso somente aos objetos OSPF da MIB:

R1(config)#snmp-server view OSPF ospf
R1(config)#snmp-server group NMSACCESS v3 priv read OSPF write OSPF 
R1(config)#

Fazendo o teste novamente de obter o sysName:

jose@rejane:/var/log$ snmpget -v 3 -l authPriv -u NMS1 -a SHA -A CISCO123 -x DES -X CISCO123 192.168.200.1 1.3.6.1.2.1.1.5.0
iso.3.6.1.2.1.1.5.0 = No Such Object available on this agent at this OID
jose@rejane:/var/log$

Dessa vez nao consegui :(... Vamos testar coletar dados do OSPF:

jose@rejane:/var/log$ snmptable -v 3 -l authPriv -u NMS1 -a SHA -A CISCO123 -x DES -X CISCO123 192.168.200.1 OSPF-MIB::ospfAreaTable
SNMP table: OSPF-MIB::ospfAreaTable

ospfAreaId ospfAuthType ospfImportAsExtern ospfSpfRuns ospfAreaBdrRtrCount ospfAsBdrRtrCount ospfAreaLsaCount ospfAreaLsaCksumSum ospfAreaSummary ospfAreaStatus ospfAreaNssaTranslatorRole ospfAreaNssaTranslatorState ospfAreaNssaTranslatorStabilityInterval ospfAreaNssaTranslatorEvents
 0.0.0.0 none importExternal 2 0 0 3 84562 sendAreaSummary active ? ? ? ?
jose@rejane:/var/log$

Beleza!, a coleta de dados de OSPF esta OK..Você pode utilizar views não somente em SNMPv3 também pode em SNMPv2.

Agora vamos configurar o envio de traps encriptados:

R1(config)#snmp-server enable traps
R1(config)#snmp-server host 192.168.200.2 traps version 3 priv NMS1 
R1#sh snmp host 
Notification host: 192.168.200.2 udp-port: 162 type: trap
user: NMS1 security model: v3 priv
R1#

R1(config)#
*Feb 20 16:50:25.648: %OSPF-5-ADJCHG: Process 1, Nbr 192.1.1.2 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1(config)#
*Feb 20 16:50:55.652: SNMP: Queuing packet to 192.168.200.2
*Feb 20 16:50:55.652: SNMP: V2 Trap, reqid 1, errstat 0, erridx 0 
 sysUpTime.0 = 804133 
 snmpTrapOID.0 = ospfTrap.2.2 
 ospfGeneralGroup.1 = 192.168.200.1 
 ospfNbrEntry.1 = 192.1.1.2 
 ospfNbrEntry.2 = 0 
 ospfNbrEntry.3 = 192.1.1.2 
 ospfNbrEntry.6 = 1

Da para brincar com access list também para restringir o acesso de ips ao roteador en SNMPv3.

Por hoje é isso pessoal espero que tenham gostado do post!!.

Abçs e Obrigado
Jose CCIE#35681

CCNA 200-125 - Curso Presencial em SP - Março de 2018

Uma excelente oportunidade para aqueles que residem na cidade de São Paulo e região, estão abertas as inscrições para o Preparatório CCNA 200-125 em março de 2018. Vagas Limitadas!!!

O curso ocorre em São Paulo - Capital. São apenas 10 vagas, à um valor promocional de R$ 1.590,00

O curso será ministrado de segunda a sexta, das 09:00hs às 18:00hs, com intervalo de 1 hora para almoço e coffee-breaks. O pagamento pode ser parcelado em até 12x via PagSeguro.

◦Carga Horária: 40 horas

◦Quando: dias 19/03, 20/03, 21/03, 22/03 e 23/03, sempre das 09:00hs às 18:00hs

◦Onde: Rua Marquês de Itu, 408 - Conjunto 24 - Vila Buarque - São Paulo - SP (próximo a Estação República do Metrô)

◦Quanto: R$ 1.590,00 (Podendo ser parcelado em até 12X via PagSeguro)

◦Diferenciais: Incluso no valor do investimento acesso ao Curso CCNA Routing & Switching em Modo Gravado via ambiente Portal de Treinamentos NetFindersBrasil (o acesso é liberado logo após a confirmação do pagamento do curso e se estende por 120 dias após o término do curso presencial).

Conteúdo Programático:

Aula 01
Introdução as Carreiras Cisco
Apresentando o Exame 200-120
Modelo de referência ISO-OSI
O modelo de referência TCP/IP
Switching e VLANs
Configuração de Switches (Security, VLANs, Etherchannel)

Aula 02
Endereçamento IPv4
Subredes
Variable Lenght Subnet Masks (VLSM)
Classless Interdomain Routing (CIDR)
IPv6
Subredes IPv6

Aula 03
O sistema operacional Cisco IOS
O processo de licenciamento do IOS 15
Apresentação do Cisco Configuration Professional (CCP)
Gerenciamento básico de uma rede
Autenticação local de usuários
SNMPv2 e v3
Cisco Netflow
Syslog
Listas de Controle de Acesso (ACLs)

Aula 04
O processo de roteamento IP
Roteamento IP Estático
Roteamento IP dinâmico (RIPv1 e RIPv2)
Roteamento IP dinâmico – EIGRP
Roteamento IP dinâmico – OSPF multi-area
Sumarização de rotas (configuração)
Roteamento IPv6 estático
Roteamento IPv6 dinâmico – RIPng
Roteamento IPv6 dinâmico -OSPFv3
Roteamento IPv6 dinâmico – EIGRP

Aula 05
Protocolos WAN (HDLC / PPP, PPP Multilink / PPPoE / Metro Ethernet)
Conceitos de QoS
First Hop Redundancy Protocols - HSRP
Prática de Cenários para o exame: Laboratórios

◦IMPORTANTE: Os alunos deverão trazer notebook para a realização dos laboratórios utilizando o EVE-ng.

Os interessados podem garantir sua vaga efetuando a compra do curso no botão abaixo:

Maiores Informações: adilson.aflorentino@eamsoft.com.br

◦Inscrições por tempo limitado. São apenas 10 vagas. Garanta já a sua !!!

MultiLink PPP

Olá Pessoal Bom Dia, hoje decidi mudar de tópico, e em vez de ver python vamos tratar algum tópico de networking, especialmente tópicos do CCNA.

 

 

MultiLink PPP

 

Multilink PPP, RFC-1990, é uma tecnologia que permite agregar vários links físicos PPP em um único link lógico chamado de Multilink.

 

 

 

Dessa forma podemos obter um link com uma maior largura de banda, redundante, e com balanceameto de carga.

 

O MLPP vai fragmentar o pacote IP, encapsular cada fragmento com um cabeçalho PPP e vai enviar  os fragmentos por todos os links simultaneamente (balanceamento de carga em camada 2), ditos fragmentos tem uma ordem de sequência, e o MLPP irá utilizar essa sequência para juntar os fragmentos e poder obter o pacote IP original.

 

 

 

Para poder configurar um MLPP, é preciso configurar tanto do lado do cliente como da operadora, então não podemos ter MLPP com links de operadoras diferentes.

 

 

Vejamos um exemplo:

 

Precisamos configurar um MLPP nos roteadores R1 e R2, sendo que temos três links seriais.

 

Configurando PPP nas interfaces seriais, a configuração é a mesma para os dois:

 

Rx(config)#int se0/0

Rx(config-if)#encapsulation ppp

Rx(config-if)#no shut

Rx(config)#int se0/1

Rx(config-if)#encapsulation ppp

Rx(config-if)#no shut

Rx(config)#int se0/3

Rx(config-if)#encapsulation ppp

Rx(config-if)#no shut

 

Criando a Interface Multilink 1, em ambos os roteadores:

 

R1(config-if)#int multilink 1

R1(config-if)#ip address 192.168.100.1 255.255.255.0

R1(config-if)#

 

R2(config-if)#int multilink 1

R2(config-if)#ip address 192.168.100.2 255.255.255.0

R2(config-if)#

 

Adicionando as interfaces Seriais, ao multilink group:

 

Rx(config-if)#int se0/0

Rx(config-if)#ppp multilink group 1

Rx(config-if)#int se0/1

Rx(config-if)#ppp multilink group 1

Rx(config-if)#int se0/3

Rx(config-if)#ppp multilink group 1

 

 

Verificando a interface Multilink em R1:

 

R1#sh ppp multilink

 

Multilink1, bundle name is R2

  Endpoint discriminator is R2

  Bundle up for 00:01:33, total bandwidth 4632, load 1/255

  Receive buffer limit 36000 bytes, frag timeout 1000 ms

    0/0 fragments/bytes in reassembly list

    0 lost fragments, 1 reordered

    0/0 discarded fragments/bytes, 0 lost received

    0x6 received sequence, 0x6 sent sequence

  Member links: 3 active, 0 inactive (max not set, min not set)

    Se0/1, since 00:01:33

    Se0/0, since 00:01:33

    Se0/3, since 00:00:03

No inactive multilink interfaces

R1#

 

Interessante notar que o bundle name é o do roteador da outra ponta R2, também podemos ver que a largura da banda do Multilink é de 4632Kb, exatamente 3 vezes a largura da banda de cada link serial individual 1544Kb. O comando também nos mostra quais são os links ativos, e quais fazem parte do Multilink.

 

Verificando as rotas:

 

R1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

 

Gateway of last resort is not set

 

     1.0.0.0/24 is subnetted, 1 subnets

C       1.1.1.0 is directly connected, Loopback0

     192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks

C       192.168.100.0/24 is directly connected, Multilink1

C       192.168.100.2/32 is directly connected, Multilink1

R1#

 

As rotas também estão OK, sendo que elas aparecem como diretamente conectadas pelo Multilink.

 

Agora vamos fazer um teste de fazer shutdown em uma interface serial do R2 e deixar um ping rodando no R1:

 

R2(config-if)#int se0/1

R2(config-if)#shut

 

R1#ping        

Protocol [ip]:

Target IP address: 192.168.100.2

Repeat count [5]: 10000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10000, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.....................

.......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 96 percent (852/880), round-trip min/avg/max = 4/20/52 ms

R1#

 

 

No momento que eu fiz o shutdown na interface Se0/1 de R2, o ping falhou e demorou aprox uns 30segundos em voltar, o ping voltou exatamente quando a interface Se0/1 de R1 ficou em down.

 

Esse valor de 30segundos é devido ao “keepalive”, a cada 10segundos é enviado um pacote de keepalive, e é preciso de 3 keepalive não recebidos para dar a interface serial como down.

 

Quando Se0/1 de R2 caiu, R1 ficou esperando 3 keepalive via sua interface Se0/1, enquanto isso o Multilink ficou em um estado de transição, passados os 30segundos, R1 considera a interface Se0/1 dela como down e o Multilink coloca a interface como inactive, imediatamente o ping volta a funcionar.

 

R1#sh ppp multilink

 

Multilink1, bundle name is R2

  Endpoint discriminator is R2

  Bundle up for 00:18:16, total bandwidth 3088, load 1/255

  Receive buffer limit 24000 bytes, frag timeout 1000 ms

    0/0 fragments/bytes in reassembly list

    1 lost fragments, 3916 reordered

    1/60 discarded fragments/bytes, 0 lost received

    0x2D74 received sequence, 0x2D7E sent sequence

  Member links: 2 active, 1 inactive (max not set, min not set)

    Se0/0, since 00:18:16

    Se0/3, since 00:16:46

    Se0/1 (inactive)

No inactive multilink interfaces

R1#

 

 

Vamos testar modificando o keepalive para um valor menor, uns 2 segundos, vamos fazer essa mudança unicamente na interface Se0/1, que é a interface que estamos testando, de ambos roteadores:

 

R1(config-if)#int se0/1

R1(config-if)#keepalive 2

R2(config-if)#int se0/1

R2(config-if)#keepalive 2

 

Testando novamente:

 

 

R2(config-if)#int se0/1

R2(config-if)#shut

 

R1(config-if)#do ping      

Protocol [ip]:

Target IP address: 192.168.100.2

Repeat count [5]: 10000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10000, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!.

Success rate is 98 percent (630/637), round-trip min/avg/max = 4/20/44 ms

R1(config-if)#

 

Dessa vez o tempo que ficamos sem conectividade foi menor, aprox 6 segundos :)

 

 

Para ver como os pacotes estão sendo fragmentados podemos utilizar o comando debug:

 

R1#ping

Protocol [ip]:

Target IP address: 192.168.100.2

Repeat count [5]: 10

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/4 ms

R1#

R2#debug ppp multilink fragments

Multilink fragments debugging is on

R2#

*Mar  1 00:25:01.959: Se0/1 MLP: O frag 800000A2 size 166 encsize 4

*Mar  1 00:25:01.959: Se0/0 MLP: O frag 400000A3 size 169 encsize 4

*Mar  1 00:25:15.335: Se0/1 MLP: I frag 400000A5 size 60 encsize 4

*Mar  1 00:25:15.335: Se0/3 MLP: I frag 800000A4 size 58 encsize 4

*Mar  1 00:25:15.335: Se0/3 MLP: O frag 800000A4 size 58 encsize 4

*Mar  1 00:25:15.335: Se0/1 MLP: O frag 400000A5 size 60 encsize 4

*Mar  1 00:25:15.339: Se0/0 MLP: I frag 800000A6 size 58 encsize 4

*Mar  1 00:25:15.339: Se0/3 MLP: I frag 400000A7 size 60 encsize 4

*Mar  1 00:25:15.339: Se0/0 MLP: O frag 800000A6 size 58 encsize 4

*Mar  1 00:25:15.339: Se0/3 MLP: O frag 400000A7 size 60 encsize 4

*Mar  1 00:25:15.343: Se0/1 MLP: I frag 800000A8 size 58 encsize 4

 

 

Do resultado do debug, podemos ver que fragmentos estão chegando por todos os enlaces ppp individuais.

 

 

 

Caso seja necessário utilizar autenticação PAP ou CHAP, os comandos de autenticação deveram ser inseridos na interface Multilink.

 

Autenticando bidireccionalmente (2-way) com PAP:

 

R1(config)#username ROUTER2 password cisco

R1(config)#int Multilink 1

R1(config-if)#ppp authentication pap

R1(config-if)#ppp pap sent-username ROUTER1 password cisco

R1(config-if)#

R2(config)#username ROUTER1 password cisco

R2(config)#int Multilink 1

R2(config-if)#ppp authentication pap

R2(config-if)#ppp pap sent-username ROUTER2 password cisco

R2(config-if)#

R2(config-if)#

 

 

 

Bom por hoje é isso aí, espero que tenham gostado do post.

 

Abcs

Jose CCIE#35681