Tag Archives: cisco

PDF de atualização do livro CCNA 5.0 para o novo CCNA 6.0

tux_cisco

Presentinho do Marco Fillipetti para comunidade 🙂 show de bola!

Conforme prometido, estou disponibilizando aqui o PDF que torna o livro CCNA 5.0 (vermelho) 100% compatível com a nova versão do exame CCNA (200-125). Basta clicar na figura abaixo.

Aproveitem e deixem aqui seu feedback e sugestões.

Abraço!

Marco Filippetti

 

5060

Trabalhando com cisco routers com “menos medo”

tux_cisco

Bom quem trabalha todo dia com routers cisco/juniper/mikrotik sabe que as vezes cheats happen… só se machuca quem joga esse é  uma dica básica mas vejo pouco usando o que pode ocasionar um problema sério em um backbone por exemplo…

Com isso em mente sempre tento antes de ativar qualquer coisa no trabalho, fazer scripts e em casos mais sérios com router cisco temos o comando salvador “reload in”  em juniper tem o commit check e mais ferramentas lindas que te salvam…

Normalmente, quase sempre você usa o reload apenas para dar boot mas ele tem outas funções uma delas em especial e é o reload in, ( tem o reload at que serve pra agendar o boot ajuda bastante faço outro post depois sobre)

Com o reload in você pode setar quantos minutos vai ocorrer um reload após você dar o comanda exemplo: reload in 2, faz com que em dois minutos seja agendado um reload, a ok show fiz uma cacá vai rebootar em 2min, mas caso eu tenha feito tudo certinho como proceder? simples, exemplo: reload cancel

Como faço para ver quanto tempo ainda tenho antes do reload? exemplo: show reload

 

Abaixo umas telas dele funcionando, bons testes !!! Note também que ele mostra certinho o start do shutdown e cancelamento do mesmo muito prático 🙂

reload-in

Configuração da Nuvem MPLS em Provedores

tux_cisco

Olá pessoal hoje trago um post um pouco mais avançado que trata várias técnologias, tais como EIGRP /BGP / VRF / e o personagem principal “MPLS”

 

Softfware utilizado para simulação : GNS3 https://www.gns3.com/ faça seu cadastro faça a instalação, adicione o IOS 36xx no post abaixo, pra quem não conhece o GNS3 ou não usou veja um video no youtube para aprender usar IDLEPC responsável por deixar o processamento dos roteadores mais baixo.

Post de EIGRP caso queira mais teoria -> http://flexpabx.com.br/blog/?p=569

 

Utilizei como base de conhecimento o livro do professor Samuel Henrque Brito, lab de configração de nuvem MPLS

Abaixo o post completo.

Observações,  passos que tomaremos neste post

  1. Configuração Básica das Interfaces e Endereços IP ( Dica Flex, faça o desenho como no post desde o inicio anote os ips no excell ou bloco ne notas para evitar conflitos mentais, ligue interfaces similares sempre exemplo fast 0/0 com 0/0
  2. Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)
  3. Criação e Associação da VRF e Configuração do RD/RT (Dica Flex, leia várias vezes o conceito dessa parte para fixar essa informação super importante.)
  4. Configuração do Roteamento EIGRP no PE e CE
  5. Configuração da Redistribuição de Rotas EIGRP e BGP ( Dica FLEX ATENÇÃO, isso aqui pode dar um crash nos leitores mas tentando ser didático e usar linguagem popular, nessa parte de nosa configuração é necessário redistribuir as rotas eigrp dentro do BGP e vice versa, acesse o BGP 200 e joguei dentro da VRF cliente 1 e 2 o eigrp e depois acesse o EIGRP 1 e jogue o BGP 200.
  6. Configuração do MP-BGP no(s) PE

Usei interfaces fast em todos routers, não vejo mais uso de serial hoje em dia, IOS utilizado Cisco IOS v12.4 Plataforma 3600

 

TOPOLOGIA-MPLS

 

Post original : https://labcisco.blogspot.com.br/2013/01/configuracao-da-nuvem-mpls-em-provedores

Esse post traz um assunto relevante no contexto atual das telecomunicações que é o MPLS.Atualmente a tecnologia MPLS (Multi-Protocol Label Switching) é comumente utilizada pelas operadoras de telecomunicações (ISP) como solução de conectividade de longa distância.
E antes de entrar na discussão técnica, uma primeira observação importante é que a configuração dessa tecnologia no ambiente corporativo (enterprise) é totalmente diferente da configuração na nuvem da operadora (ISP).
Aliás, quem possui um link MPLS na empresa sabe bem que ela é transparente, já que você simplesmente recebe a conectividade da operadora e pronto – é como se houvesse um link privado entra as unidades remotamente conectadas… Bom, então se a coisa é simples assim qual seria a razão da “novela” que se faz acerca dessa tecnologia?
A simplicidade de uns é a complexidade de outros! Os roteadores instalados na empresa cliente normalmente sequer têm noção do que é MPLS e por isso toda a complexidade da infraestrutura está na nuvem da operadora.
Diferente de outras tecnologias de Camada 2 (HDLC, ATM e Frame-Relay) que eram tradicionalmente utilizadas na longa distância (e ainda são), o MPLS surgiu como uma tecnologia de Camada 2¹/² que traz uma abordagem de operação totalmente nova: o chamado roteamento baseado em rótulos.
Essa tecnologia não utiliza mais o cabeçalho do datagrama IP na decisão de roteamento, fazendo o reencapsulamento do datagrama com um novo cabeçalho de 4 bytes que possui um rótulo de 20 bits. Toda a decisão de encaminhamento dos pacotes é determinada com base nesse rótulo, o que agiliza o processo de roteamento e permite a implementação de técnicas de engenharia de tráfego, entre outras coisas mais.
O assunto é extenso e obviamente que o meu objetivo não é substituir um bom livro sobre o assunto – por isso serei o mais objetivo possível e o foco é que vocês consigam reproduzir um cenário prático de MPLS. Vamos trabalhar com o  cenário observado na figura abaixo.
Antes de partir para a configuração, existem vários conceitos fundamentais que o leitor precisa ter em mente para entender o papel dos elementos envolvidos no cenário. Então que tal começar pelocomeço? Parece razoável… 😉
O Custormer Edge (CE) é o equipamento instalado nas unidades remotas da empresa que irão receber a solução de conectividade provida pela operadora. Outro elemento importante é oProvider Edge (PE) que se trata do roteador da operadora diretamente conectado a um (ou mais) roteador(es) do(s) cliente(s), ou seja, PEs são conectados a CEs. Por fim, o elemento P (Provider)são os demais roteadores distribuídos pela nuvem MPLS que representa a infraestrutura de rede da operadora.

Outro conceito fundamental é a tecnologia VRF (Virtual Routing and Forwarding) que traz consigo outros dois elementos igualmente importantes: o RD (Route Distinguisher) e o RT (Route Target). Através do VRF é possível criar múltiplas instâncias da tabela de roteamento, sendo que cada uma dessas tabelas virtuais é totalmente independente das demais. No contexto do MPLS é comum que cada cliente tenha sua própria VRF porque essa prática traz mais segurança e flexibilidade.

Sem as VRFs individuais o tráfego entre as sub-redes de todos os clientes da operadora iriam compor uma única tabela de roteamento, o que seria péssimo do ponto de vista de segurança. Outro benefício comum é que se torna possível que os clientes utilizem endereços de redes iguais, já que as instâncias VRF são independentes. E é muito comum que as empresas utilizem endereços privados da RFC1918 (192.168 /16, 172.16 /12 e 10 /8).

No entanto, em algum momento é necessário que as rotas entre o roteador da empresa (CE) e o roteador da operadora (PE) sejam redistribuídas para um processo BGP no PE. Isso porque deve existir um pareamento iBGP entre um PE e outro PE remoto para viabilizar na prática a chamada VPN MPLS, um túnel abstrato que só existe nas bordas da rede MPLS, já que os roteadores P sequer conhecem as várias VPNs.

Eis que surge um problema: Fica claro que é possível ter endereços repetidos através das VRFs porque elas representam tabelas de roteamento distintas, mas como fica a redistribuição das rotas iguais para o processo BGP!!!??? Isso só é possível através da adição de um identificador nas rotas para torná-las únicas que é denominado RD (Route Distinguisher). Também existe o RT (Route Target), uma community BGP que indica o membro de uma VPN, permitindo que rotas sejam importadas e exportadas das VRFs no processo de redistribuição.

Há alguns formatos para o RD/RT, sendo que sua forma mais comum consiste em:
ASN de 16 Bits + Número de 32 Bits ; Ex.: 65000:100.

No cenário apresentado nesse post teremos duas VRFs denominadas Cliente1 e Cliente2 que serão identificadas da seguinte forma:

– VRF Cliente 1, RD 65001:111, RT 65001:1
– VRF Cliente 2, RD 65002:222, RT 65002:2

Mesmo com “toda” essa carga teórica, acreditem que fui bastante sucinto e fiz o possível para “suavizar” essa postagem apresentando apenas os conceitos fundamentais. Como o processo de configuração consiste em várias linhas de comando, estarei dividindo o processo de configuração nas seguintes etapas:

  1. Configuração Básica das Interfaces e Endereços IP
  2. Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)
  3. Criação e Associação da VRF e Configuração do RD/RT
  4. Configuração do Roteamento EIGRP no PE e CE
  5. Configuração da Redistribuição de Rotas EIGRP e BGP
  6. Configuração do MP-BGP no(s) PE

As etapas 1 e 2 não dizem respeito à configuração do MPLS propriamente dito, no entanto são pré-requisitos para o cenário funcionar devidamente. Como os roteadores da empresa (CE) nao têm ciência do MPLS, eles possuem apenas configurações básicas.

1) Configuração Básica das Interfaces e Endereços IPA única configuração que merece destaque nessa primeira etapa é que estamos habilitando o encapsulamento MPLS na interface que se conecta a outro roteador da nuvem da operadora.Reparem que as interfaces que se conectam aos roteadores CE não têm essa configuração, já queo tráfego até o PE é puramente IP.

2) Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)

Essa segunda etapa também é bem básica, consistindo apenas na configuração de um protocolo de roteamento IGP qualquer na nuvem da operadora. Não há nenhum destaque especial, então apenas trarei os comandos:

3) Criação e Associação da VRF e Configuração do RD/RT

A configuração abaixo é necessária apenas nos roteadores de borda (PE), já que os roteadores da empresa (CE) não têm ciência do MPLS. Reparem que em cada roteador de borda criamos duas VRFs e informamos os valores RD/RT previamente definidos. Por fim, associamos cada VRF com sua respectiva interface (cliente).

4) Configuração do Roteamento EIGRP no PE e CE

A próxima etapa consiste na configuração de um protocolo de roteamento entre a empresa para que o provedor possa conhecer as rotas anunciadas pela empresa. Esse processo de configuração é bem simples nos roteadores da empresa (CE), no entanto há alguns comandos adicionais nos roteadores do provedor (PE) que são necessários para associar as rotas de cada cliente com sua respectiva VRF anteriormente criada.

Talvez a observação mais importante aqui é que o número de AS utilizado nos processos EIGRP do CE e PE não precisam ser iguais, uma vez que na configuração EIGRP do PE há uma sub-seção de configuração para cada VRF em que devemos informar o mesmo número utilizado no processo do roteador remoto (CE). Caso contrário, as rotas dos diversos clientes seriam todas compartilhadas na tabela de roteamento padrão, o que não é desejado…

***

(*)

(*) Obs.: No processo EIGRP dos roteadores PE que irão estabelecer vizinhança com os roteadores CE utilizamos o AS 1 para não misturar as rotas dos clientes com o processo EIGRP 200 que utilizamos nas primeiras etapas para trocar as rotas internas entre os roteadores da nuvem MPLS.  

5) Configuração da Redistribuição de Rotas EIGRP e BGP

Até agora os roteadores PE já aprenderam as rotas dos clientes diretamente conectados, no entanto não existe uma ligação entre as unidades remotas dos clientes porque o PE1 não está diretamente ligado ao PE2. Ou seja, PE1 conhece as rotas anunciadas por CE1A, mas não é capaz de receber as rotas de CE1B.

Na próxima etapa a gente vai configurar um pareamento iBGP entre PE1 e PE2 para criar a abstração do túnel da VPN/MPLS. No entanto, antes temos que configurar a redistribuição mútua entre o EIGRP estabelecido com os roteadores CE e o BGP que estará em execução nos roteadores PE.

6) Configuração do MP-BGP no(s) PE

O último passo consiste no estabelecimento do túnel virtual entre as unidades remotas da empresa para prover ao cliente a abstração de que existe uma conexão privada de longa distância (WAN) entre as unidades. Assim que essa configuração for feita, os roteadores CE1A e CE1B vão conhecer as rotas uns dos outros e a empresa terá conectividade remota!

Pronto! Depois de MUITAS linhas de comando já temos uma implementação básica de VPN/MPLS funcionando entre duas empresas clientes, cada uma com apenas duas unidades remotas. Aovisualizar a tabela de roteamento VRF Cliente1 no roteador PE1 é possível observar que a rota 192.168.2.0/24 da unidade remota foi aprendida via BGP.

PE1#show ip route vrf Cliente1

Routing Table: Cliente1
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

172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
B       172.16.3.0 [200/0] via 2.2.2.2, 00:02:37
D    192.168.1.0/24 [90/2172416] via 172.16.1.2, 00:42:44, Serial2/0
B    192.168.2.0/24 [200/2172416] via 2.2.2.2, 00:02:37

Também vamos aproveitar que tivemos todo esse trabalho para observar a tabela BGP do PE1, já que assim fica evidente a importância do identificador RD.

PE1#show ip bgp vpnv4 all
BGP table version is 17, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:111 (default for vrf Cliente1)
*> 172.16.1.0/30    0.0.0.0                  0         32768 ?
*>i172.16.3.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.1.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?
Route Distinguisher: 65002:222 (default for vrf Cliente2)
*> 172.16.2.0/30    0.0.0.0                  0         32768 ?
*>i172.16.4.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.2.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?

Agora vamos observar a tabela de roteamento do roteador CE1A instalado na empresa. Observem que ele apenas conhece a rota remota como se as unidades estivessem diretamente conectadas entre si. Essa é a grande vantagem da implementação VPN do MPLS, afinal o cliente não enxerga a nuvem MPLS.

CE1A#show 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

172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
D       172.16.3.0 [90/2681856] via 172.16.1.1, 00:08:33, Serial2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/2684416] via 172.16.1.1, 00:08:34, Serial2/0

Para finalizar esse post (que já está extenso demais), há vários comandos de exibição (show) que podemos utilizar para verificar o efeito de todas as configurações realizadas em cada uma das etapas.  Por isso deixo registrada uma relação de comandos de exibição caso o leitor queira reproduzir o cenário e sugiro uma observação detalhada das tabelas VRF e BGP.

PE1# show ip route
PE1# show ip route vrf Cliente1
PE1# show ip route vrf Cliente2
PE1# show ip bgp 
PE1# show ip bgp summary
PE1# show ip bgp vpnv4 all  
PE1# show ip eigrp vrf Cliente1 neighbors
PE1# show ip eigrp vrf Cliente2 neighbors
PE1# show ip eigrp vrf Cliente1 topology
PE1# show ip eigrp vrf Cliente2 topology  

VPN – L3VPN sobre L2TPv3 sem MPLS

tux_cisco

1      L3VPN em L2TP sem MPLS

A funcionalidade MPLS VPNs over IP Tunnels permite que seja configurado o serviço de VPN L3 sobre o backbone IP usando a tecnologia de túnel L2TPv3 multiponto ao invés do Multiprotocol Label Switching (MPLS). Como os tuneis multiponto suportam multiplos endpoints, é necessário configurar apenas um único tunnel em cada roteador PE.

1.1       Divulgação do Túnel pelo BGP entre os PEs

O Border Gateway Protocol (BGP) é utilizado para divulger os endpoints dos túneis e a subaddress family indentifier (SAFI) Essa feature introduz o tunnel SAFI e o atributo BGP SAFI-Specific Attribute (SSA). O tunnel SAFI define o endpoint do tunnel e transporta o endereço IPv4 e o nexthop do endpoint. O SAFI é identificado pelo SAFI number 64. O BGP SSA transporta o BGP preference e BGP flags, além de tunnel cookie, tunnel cookie length, e o session ID. Esses atributos permitem que o BGP distribua as informações de encapsulamento do túnel entre os roteadores PEs. O tráfego de VPNv4 é roteado através desses túneis. O next hop anunciado nos updates do BGP-VPNv4 determina qual túnel deverá ser usado para rotear o trafego..

1.2       Configurando os PEs

Um único tunnel L2TPv3 multiponto é configurado em cada PE. A VPN é criada configurando a instancia VRF normalmente. O túnel que transporta o tráfego da VPN através do backbone reside no seu proprio espaço de Endereçamento. Uma VRF chamada Resolve in VRF (RiV) é criada para gerenciar os endereçamentos do túnel. O endereçamento configurado na VRF RiV é associada com o tunnel e uma rota estática é configurada na VRF RiV para rotear o tráfego pelo túnel.
How to Configure MPLS VPNs over IP Tunnels
Para configurar o serviço de VPN L3 sobre o tunnel L2TPv3 multiponto deve-se crier a instancia VRF, criar o tunnel multiponto L2TPv3, redirecionar o tráfego Ip da VPN para o tunnel e configurar a troca de informações de VPN pelo BGP VPNv4.
 

Cenário

1.3       Objetivo

Cinco roteadores (CE1, PE1, P, PE2 e CE2) são conectados formando um backbone com 3 roteadores e dois CEs conectados. Pede-se:
•      O protocolo de roteamento de backbone PE1-P-PE2 deverá ser o OSPF na área 0 com todas as interfaces divulgadas e com mBGP no AS 1 entre os PEs para tráfego de VRFs;
•      Tanto o CE1 quanto o CE2 deverão pertencer a VRF VPN_A e deverá existir conectividade entre esses CEs;
•      Não deverá ser usado MPLS para o tráfego de dados da VRF. Deve-se usar um túnel L3VPN com L2TP;
•      O túnel deverá ter autenticação com a chave “12”.

1.4       Topologia

dl3vpn-l2tpv3
Figure-01:         Topologia

1.5       IOS utilizados

•      CE1, PE1, P, PE2 e CE2 – c7200-k91p-mz.122-25.S15.bin

1.6       Configuração dos Roteadores

1.6.1        Configurações do OSPF do Backbone

Em todos os roteadores configura-se o roteamento OSPF pelo comando “router ospf ” onde o “processo” é um numero do processo OSPF. O roteador também possui um router ID único que geralmente é a interface loopback ou então o maior endereço IP do roteador.
Para adicionar interfaces deve-se usar o comando “network

área ”. Um roteador pode ter interfaces em áreas distintas, define-se cada área pelo comando network e o tipo da área com o comando “area [type]”.

1.6.2        Configuração do MBGP

Para estabelecer uma VPN, seja lite ou não, é necessário configurar o MBGP para a troca de informações de prefixos de VPN. É necessário somente configurar o MBGP nos roteadores PEs da rede que possuem conexão com os CEs, ou seja, conectados diretamente aos sites.
O MBGP funciona como o BGP, configura-se em todos os roteadores pelo comando “router bgp ” onde o “AS” é o Autonomous System do backbone. Dentro da configuração de BGP adicionam-se os vizinhos estaticamente com o comando “neighbor remote-as ”.
Adiciona-se o IP da interface loopback como Router-ID pelo comando “bgp router-id ”.
Como os roteadores dentro do mesmo AS não divulgarão as rotas IBGP entre eles, faz-se o full-mesh de conexão MBGP ou configuram-se os roteadores centrais como Router-reflectors adicionando os demais roteadores como clientes pelo comando“neighbor router-reflector-client”.
O MBGP é configurado dentro do protocolo BGP, porém deve-se separar a família de roteamento com o comando “address-family vpnv4” e dentro da família ativar os vizinhos. Para o envio de prefixos das VPNs, deve-se habilitar o envio de community extendida com o comando “neighbor send-community extended”.
Todos os recursos como route-map, next-hop-self, router-reflector, etc. podem ser configurados dentro da família VPNv4 para manipular ou resolver problemas de roteamento.

1.6.3        Criando uma VPN VRF no BGP

Após todos os roteadores PEs da rede possuem conectividade MBGP, ou diretamente ou por router-reflector, cria-se a VPN com o comando “ip vrf ”, dentro desse comando ficam os parâmentros de marcação da VPN e das communities associadas aos prefixos daquela VPN. Configura-se o Route-Distinguisher da VPN, que deve ser único na rede, com comando “rd :”, e também se cria a community que será exportada para aqueles prefixos de rede com o comando “route-target <export|import>:”, onde “import” significa importar as rotas e “export” exportar as rotas marcadas com aquela community.
Cria-se então uma address-family dentro do BGP com o comando “address-family ipv4 vrf ” com o mesmo nome da VPN criada no “ip vrf” fora do roteamento BGP. Dentro dessa address-family são configuradas as redes que serão redistribuídas para os outros sites. Para divulgar as redes é necessário que a rede exista na tabela de roteamento interna e, ou adicionar o comando “network mask ou redistribuindo rotas para o MBGP com o comando “redistribute ”, que pode ser vinculado a um route-map para definir exatamente as rotas que serão divulgadas de um protocolo para outros sites.
Enfim, para que uma interface conectada ao CE faça parte da VPN BGP, usa-se o comando “ip vrf forwarding ” dentro da interface.

1.6.4        Criando o túnel L2TP L3 para tráfego de VPN

Para criar um túnel multiponto GRE para envio de tráfego das VRFs criadas nos PEs, cria-se uma vrf exclusiva para o transporte dos dados, geralmente chamada de “RiV” que quer dizer Resolve-in-VRF “ip vrf RiV”, dentro da VRF configura-se um RD.
Em seguida, cria-se uma interface túnel “interface tunnel ” na vrf de transporte (no caso, RiV) com um endereço IP na mesma rede do endereço IP das interfaces túnel de todos os outros PEs. Usa-se o o endereço IP da loopback como source do túnel (esse endereço tem que ser acessível pelos outros PEs) “tunnel source loopback 0”. Configura-se o tipo do túnel que deverá ser L2TPv3 multiponto para VPN L3 “tunnel mode l3vpn l2tpv3 multipoint”.
Na vizinhança com os outros PEs ou com o Router Reflector aplica-se um route-map de entrada dizendo que tudo o que é aprendido por aquele peer deve ser enviado para a VRF de transporte, a RiV. Esse route-map tem como set o comando “set ip next-hop in-vrf RiV”.
Para que o roteamento do túnel seja feito entre os PEs, deve-se configurar uma conexão MBGP em uma address-family Tunnel entre o PEs envolvidos ou com um router-reflector.
Por último, configura-se uma rota estática default apontada para a interface tunnel dentro da vrf RiV.

1.7       Observações e Bugs

2      Configuração

2.1       CE1

!
interface FastEthernet0/0
 ip address 10.10.10.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.10.10.254
!

2.2       PE1

!
ip cef
!
ip vrf RiV
 rd 12:12
!
ip vrf VPN_A
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel12
 ip vrf forwarding RiV
 ip address 12.12.12.1 255.255.255.0
 tunnel source Loopback0
 tunnel mode l3vpn l2tpv3 multipoint           ! modo do tunnel tem que ser l3vpn
 tunnel key 12
!
interface FastEthernet0/0
 ip vrf forwarding VPN_A
 ip address 10.10.10.254 255.255.255.0
!
interface FastEthernet1/0
 ip address 100.100.100.1 255.255.255.252
!
router ospf 1
 router-id 1.1.1.1
 network 1.1.1.1 0.0.0.0 area 0
 network 100.100.100.1 0.0.0.0 area 0
!
router bgp 100
 bgp router-id 1.1.1.1
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 ebgp-multihop 255
 neighbor 2.2.2.2 update-source Loopback0
 !
 address-family ipv4 tunnel
 neighbor 2.2.2.2 activate
!
 address-family vpnv4
 neighbor 2.2.2.2 activate
 neighbor 2.2.2.2 send-community extended
 neighbor 2.2.2.2 route-map RiV_RM in
 !
 address-family ipv4 vrf VPN_A
 redistribute connected
!
 address-family ipv4 vrf RiV
!
!
ip route vrf RiV 0.0.0.0 0.0.0.0 Tunnel12
!
!
route-map RiV_RM permit 10              ! o route-map aponta as rotas para dentro da vrf
 set ip next-hop in-vrf RiV
!

2.3       P

!
interface Loopback0
 ip address 9.9.9.9 255.255.255.255
!
interface FastEthernet0/0
 ip address 100.100.100.2 255.255.255.252
!
interface FastEthernet1/0
 ip address 100.100.100.6 255.255.255.252
!
router ospf 1
 router-id 9.9.9.9
 network 100.100.100.2 0.0.0.0 area 0
 network 100.100.100.6 0.0.0.0 area 0
!

2.4       PE2

!
ip cef
!
ip vrf RiV
 rd 12:12
!
ip vrf VPN_A
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel12
 ip vrf forwarding RiV
 ip address 12.12.12.2 255.255.255.0
 tunnel source Loopback0
 tunnel mode l3vpn l2tpv3 multipoint
 tunnel key 12
!        
interface FastEthernet0/0
 ip vrf forwarding VPN_A
 ip address 20.20.20.254 255.255.255.0
!
interface FastEthernet1/0
 ip address 100.100.100.5 255.255.255.252
!
router ospf 1
 router-id 2.2.2.2
 network 2.2.2.2 0.0.0.0 area 0
 network 100.100.100.5 0.0.0.0 area 0
!
router bgp 200
 bgp router-id 2.2.2.2
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 ebgp-multihop 255
 neighbor 1.1.1.1 update-source Loopback0
 !
address-family ipv4 tunnel
 neighbor 2.2.2.2 activate
 exit-address-family
 !
 address-family vpnv4
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 send-community extended
 neighbor 1.1.1.1 route-map RiV_RM in
!
 address-family ipv4 vrf VPN_A
 redistribute connected
!
 address-family ipv4 vrf RiV
!
ip route vrf RiV 0.0.0.0 0.0.0.0 Tunnel12
!        
!
route-map RiV_RM permit 10
 set ip next-hop in-vrf RiV
!

2.5       CE2

!
interface FastEthernet0/0
 ip address 20.20.20.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 20.20.20.254
!
Conteúdo salvo para uso pessoal em laboratórios, devido ao pouco conteúdo deste nível ccie provider em BR.

Autor original: Bruno Barata

Fonte: http://babarata.blogspot.com.br/

EIGRP – Básico

tux_kisuke

1        Teoria EIGRP

O EIGRP é um protocolo de roteamento de convergência rápida de fácil configuração que usa o protocolo DUAL. Tem uso de largura de banda reduzido, pois não envia updates periódicos. O EIGRP é considerado um Advanced distance Vector e usa o máximo de 255 hops e 100 de default.

Possui suporte a VLSM e classless routing com sumarização automática ou manual sendo compatível com IGRP se usar o mesmo AS. Capaz de fazer balanceamento de carga em 4 links por default ou 6 configuráveis.

Suporta todas as redes multiaccess, point-to-point e NBMA (Frame-Relay). A Métrica é composta por Bandwidth e Delay como default, mas pode usar: MTU, Loading e Reliability. É a métrica do IGRP x 256. Redes com muitos caminhos alternativos geralmente gera problemas na convergência EIGRP.

Comunicação multicast no 224.0.0.10, Hello de 5s para links maiores que 1.544MB e 60s para menor. Dead time de 3 vezes o hello. Utiliza o RTP (cisco) como protocolo de transporte confiável para envio de update;

1.1           Terminologia

  • Neightbor table: Cada router tem uma tabela com seus routers adjacentes;
  • Neighbor Address: Endereço de rede do vizinho (IP);
  • Q (Queue): Fila de pacotes esperando para serem enviados (0 é normal);
  • SRTT (Smooth Round Trip Timer): O tempo mais rápido que enviou e recebeu um pacote;
  • Hold Time: Tempo máximo até colocar o vizinho em OFF, geralmente 3x o tempo do Hello;
  • Topology table: Cada router tem uma tabela de topologia que inclui todos os caminhos aprendidos para cada protocolo;
  • Routing table: EIGRP escolhe o melhor router (successor) para um caminho e coloca na tabela de rotas;
  • Successor: O successor é o router escolhido como primeira opção para um caminho;
  • Feasible successor: Router de backup é escolhido junto com o successor (principal);
  • FD (feasible distance): Distância Possível, é a soma dos custos de todos os links até o destino;
  • AD (advertised distance): Distancia anunciada, é a soma dos custos do vizinho até o destino.

1.2           Tipos de Mensagens

  • Hello: Usados para descobrir vizinhos por multicast no 224.0.0.10 não confiável de 5 em 5s  para links maiores que 1.544MB ou de 60 em 60s para menores. Envia também o dead time (3x o tempo de hello);
  • Update: Pacotes update requer confirmação (confiável RTP) e são enviados para comunicar que um router especifico sofreu convergência. São enviados por multicast quando um novo router é descoberto;
  • Query: Pacotes que requerem confirmação (confiável RTP) e perguntam se existe um router de backup para um determinado caminho
  • Reply: Pacotes de resposta a um Query que requerem confirmação (confiável RTP), enviado por Unicast somente a quem perguntou;
  • Acknowledgment (ACK): Pacotes de confirmação enviado por unicast. Pacotes como: Update, query e reply precisam de confirmação.
  • Obs: Pacotes de confiança só são retransmitidos 16 vezes, caso contrário o vizinho é considerado Dead.

1.3           Relacionamento com Vizinhos

EIGRP envia multicasts periódicos (hello) pela interface (com IP primário, pois o secundário não forma adjacências) para descobrir vizinhos, quando outro router pertence ao mesmo AS ele recebe o hello e estabelece uma relação de vizinhos mantendo assim as informações de seus vizinhos na sua Neighbor Table.

Quando o vizinho para de responder os pacotes hello e o hold time acaba (3 vezes o tempo do hello), ele considera o vizinho não operacional, assim toda a tabela de topologia aprendida pelo vizinho é deletada e é feita uma convergência.

Os pacotes Hello são enviados de 60 em 60 segundos nos circuitos de largura de banda menor ou igual a T1 como: ISDN BRI, SMDS, etc.

O EIGRP não informa ao vizinho se as suas métricas estiverem mal combinadas, não informa a vizinhos de diferente AS e o pacote Hello é enviado com o endereço primário da interface.

Query (perguntas) são enviadas quando um router é perdido e não existe um sucessor confiável (feasible sucessor) para procurar um caminho alternativo. O router entra em modo ativo e envia queries para todos os routers vizinhos que por sua vez enviam queries para outros vizinhos menos o que lhe enviou inicialmente. Uma solução para reduzir essa propagação é a sumarização de rotas, pois raramente um router remoto precisa saber todas as rotas que são divulgadas em toda rede.

Dual envia a informação de atualização apenas aos routers que precisam, diferente do link-state que envia para todos os vizinhos.

1.4           Descobrindo um Vizinho e Definindo Melhores Rotas

  1. Um novo router A entra na rede e envia um pacote Hello pelas interfaces;
  2. Router B da rede recebe esse hello e responde com pacote update com todos as rotas que ele tem em sua tabela de rotas menos as rotas aprendidas pelo novo router A (split horizon);
  3. Router A responde com um ACK confirmando o recebimento das informações;
  4. Router A ajusta todos os pacotes de update na sua tabela de topologia associando a métrica para alcançar cada destino;
  5. Router A troca pacotes update com cada vizinho;
  6. Cada router envia um ACK de confirmação para o Router A;
  7. Quando todos os routers têm todas as rotas eles estão prontos para escolher as rotas primarias e rotas de backup para manter na Topology Table;
  8. Pelo Dual ele define melhor rota baseado no bandwidth, Delay, Reliability, Loading e MTU;
  9. Se uma rota é perdida o router entra em “Active” procurando por um feasible Sucessor, passado 3min ele volta ao normal;
  10. Se um router está muito ocupado (alto uso de memória) para responder a query e enviar reply de outros routers ou o link estiver funcionando apenas em um sentido ele se encontra em SIA – Stuck in Active.

1.5           DUAL

  • FD (Feasible distance) – Distância confiável é a soma dos custos dos enlaces para alcançar a rede de destino;
  • AD (Advertised Distance) – Distância anunciada é a soma dos custos dos enlaces para a rede de destino anunciado pelos vizinhos;
  • Sucessor – Caminho escolhido para a rede de destino;
  • FS (Feasible Sucessor) – Sucessor confiável para um caminho alternativo para a rede.

1.6           Configuração de EIGRP

  • Ative o EIGRP definindo o AS que deve coincidir com todos da rede;
  • Divulgar as redes que fazem parte do EIGRP. As redes determinam as interfaces que farão parte do EIGRP;
  • O bandwidth default da interface serial é T1 (1.544MB), para mudar use o comando bandwidth na interface;
  • Quando se configura interfaces point-to-multipoint, principalmente em Frame Relay, é importante entender que todos os vizinhos compartilham uma banda igualmente em que a soma dos links de cada vizinho é o bandwidth da serial do router, por isso é importante que a velocidade da serial seja a menor velocidade de todos os links multiplicada pelo número de sub-interfaces;
  • Na topologia point-to-point com 10 links, todos os circuitos virtuais (subinterfaces) usam o bandwidth de 1/10 da interface, isto é, se o link da interface s0 for 256, cada VC (subinterface, s0.1… s0.10) terá um BW de 25;
  • Quando uma rota é aprendida pela sub-interface de uma interface, essa mesma rota não é replicada para outra sub-interface dessa mesma interface devido ao split-horizon.

1.7           Balanceamento de Carga

  • Carga balanceada em 4 links de custos iguais por default, máximo de 6 links;
  • O balanceamento de links de custos diferentes é de acordo com a métrica da rota, e é default;
  • Quando o balanceamento é feito por links de custos diferentes os pacotes são enviados por turnos, o numero de pacotes é inversamente proporcional a métrica da rota;
  • O comando “variance” é usado para adicionar outros links de custos diferentes criando uma margem a ser considerada como load-balance;

2        Cenário

2.1           Objetivo

Seis roteadores (C1, C2, C3, R1, R3 e R6) são conectados conforme a topologia abaixo e devem ser configurados seguindo os seguintes critérios.

Todos os roteadores deverão pertencer a uma rede EIGRP com AS = 1.

Os roteadores R1 e R6 deverão redistribuir as rotas estáticas configuradas.

Os roteadores C1 deverá sumarizar as rotas vindas dos roteadores R1, porém o R6 deverá divulgar as rotas sem sumariza-las.

O roteador R3 deverá gerar uma rota default para a rede EIGRP.

Todos os roteadores deverão usar suas interfaces loopbacks como Router-ID.

2.2           Topologia

eigrp-basico

Figure-01:              Topologia

2.3           IOS utilizados

  • C1, C2, C3, R1, R3 e R6 – c7200-js-mz.123-7.T.bin

2.4           Configuração dos Roteadores

Em todos os roteadores configura-se o roteamento EIGRP pelo comando “router eigrp ” onde o “AS” é o Autonomous System que deverá ser igual em todos os roteadores do mesmo domínio. O roteador também possui um router ID único que é configurado pelo comando “eigrp router-id ” dentro das configurações de roteamento.

Uma interface fica habilitada a fazer vizinhança quando a rede pertencente aquela interface está no comando “network ” está configurado no routeamento EIGRP. Caso seja necessário divulgar a rede da interface mas não habilita-la para fazer vizinhança EIGRP, usa-se o “passive-interface ” dentro das configurações de roteamento EIGRP.

Por padrão o EIGRP sumariza automaticamente as rotas para o seu vizinho. Pode-se cancelar essa sumarização automática com o comando “no auto-summary”. Desabilitar essa auto sumarização é comum para evitar loops em redes não planejadas, porém a tabela fica maior.

No EIGRP a rota default é gerada para um vizinho configurando um endereço sumarizado 0/0 na interface com o vizinho com o comando “ip summary-address eigrp 0.0.0.0 0.0.0.0”.

2.5           Observações e Bugs

Documentação:

http://www.cisco.com/en/US/partner/docs/ios/12_2/ip/configuration/guide/1cfeigrp.html#wp1001004

2.6           Comandos Importantes de Verificação

C2#sh ip route

Gateway of last resort is 30.30.30.2 to network 0.0.0.0

D    1.0.0.0/8 [90/2681856] via 12.12.12.1, 00:19:17, Serial1/6

6.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

D       6.6.6.6/32 [90/2809856] via 23.23.23.1, 00:05:27, Serial1/7

D EX    6.2.0.0/24 [170/2681856] via 23.23.23.1, 00:05:27, Serial1/7

D EX    6.3.0.0/24 [170/2681856] via 23.23.23.1, 00:05:27, Serial1/7

D EX    6.0.0.0/24 [170/2681856] via 23.23.23.1, 00:05:27, Serial1/7

D EX    6.1.0.0/24 [170/2681856] via 23.23.23.1, 00:05:27, Serial1/7

23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C       23.23.23.0/30 is directly connected, Serial1/7

D       23.0.0.0/8 is a summary, 00:19:16, Null0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       10.0.0.0/8 is a summary, 00:19:16, Null0

C       10.10.10.102/32 is directly connected, Loopback0

12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C       12.12.12.0/30 is directly connected, Serial1/6

D       12.0.0.0/8 is a summary, 00:19:17, Null0

D    13.0.0.0/8 [90/2681856] via 12.12.12.1, 00:07:17, Serial1/6

D    60.0.0.0/8 [90/2681856] via 23.23.23.1, 00:19:17, Serial1/7

30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C       30.30.30.0/30 is directly connected, Serial1/0

D       30.0.0.0/8 is a summary, 00:23:04, Null0

D*   0.0.0.0/0 [90/2297856] via 30.30.30.2, 00:06:51, Serial1/0

C2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

2   30.30.30.2              Se1/0             12 00:08:07  184  1104  0  40

1   23.23.23.1              Se1/7             11 00:21:21   83   498  0  32

0   12.12.12.1              Se1/6             13 00:23:42  106   636  0  62

C1#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.10.10.101)

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,

r – reply Status, s – sia Status

P 6.6.6.6/32, 1 successors, FD is 3321856

via 12.12.12.2 (3321856/2809856), Serial1/7

P 0.0.0.0/0, 1 successors, FD is 2297856

via 13.13.13.2 (2297856/128256), Serial1/5

P 1.0.0.0/8, 1 successors, FD is 2169856

via 10.10.10.2 (2169856/256), Serial1/0

P 6.2.0.0/24, 1 successors, FD is 3193856

via 12.12.12.2 (3193856/2681856), Serial1/7

P 6.3.0.0/24, 1 successors, FD is 3193856

via 12.12.12.2 (3193856/2681856), Serial1/7

P 6.0.0.0/24, 1 successors, FD is 3193856

via 12.12.12.2 (3193856/2681856), Serial1/7

P 6.1.0.0/24, 1 successors, FD is 3193856

via 12.12.12.2 (3193856/2681856), Serial1/7

P 10.0.0.0/8, 1 successors, FD is 128256

via Summary (128256/0), Null0

P 10.10.10.0/30, 1 successors, FD is 2169856

via Connected, Serial1/0

P 12.0.0.0/8, 1 successors, FD is 2169856

via Summary (2169856/0), Null0

P 12.12.12.0/30, 1 successors, FD is 2169856

via Connected, Serial1/7

P 13.0.0.0/8, 1 successors, FD is 2169856

via Summary (2169856/0), Null0

P 13.13.13.0/30, 1 successors, FD is 2169856

via Connected, Serial1/5

P 23.0.0.0/8, 1 successors, FD is 2681856

via 12.12.12.2 (2681856/2169856), Serial1/7

P 30.0.0.0/8, 1 successors, FD is 2681856

via 12.12.12.2 (2681856/2169856), Serial1/7

P 60.0.0.0/8, 1 successors, FD is 3193856

via 12.12.12.2 (3193856/2681856), Serial1/7

P 10.10.10.101/32, 1 successors, FD is 128256

via Connected, Loopback0

Configuração

2.7           R1

!router eigrp 1

redistribute static

network 1.1.1.1 0.0.0.0

network 10.10.10.0 0.0.0.3

auto-summary

eigrp router-id 1.1.1.1

!

 

2.8           C1

!router eigrp 1

network 10.10.10.0 0.0.0.3

network 10.10.10.101 0.0.0.0

network 12.12.12.0 0.0.0.3

network 13.13.13.0 0.0.0.3

auto-summary

eigrp router-id 10.10.10.101

!

2.9           C2

!router eigrp 1

network 10.10.10.102 0.0.0.0

network 12.12.12.0 0.0.0.3

network 23.23.23.0 0.0.0.3

network 30.30.30.0 0.0.0.3

auto-summary

eigrp router-id 10.10.10.102

!

2.10     R3

!interface Serial1/0

ip address 30.30.30.2 255.255.255.252

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 5

!

interface Serial1/4

ip address 33.33.33.2 255.255.255.252

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 5

!

interface Serial1/5

ip address 13.13.13.2 255.255.255.252

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 5

!

router eigrp 1

network 3.3.3.3 0.0.0.0

network 13.13.13.0 0.0.0.3

network 30.30.30.0 0.0.0.3

network 33.33.33.0 0.0.0.3

auto-summary

eigrp router-id 3.3.3.3

!

2.11     C3

!router eigrp 1

network 10.10.10.103 0.0.0.0

network 23.23.23.0 0.0.0.3

network 60.60.60.0 0.0.0.3

auto-summary

eigrp router-id 10.10.10.103

!

2.12     R6

!router eigrp 1

redistribute static

network 6.6.6.6 0.0.0.0

network 60.60.60.0 0.0.0.3

no auto-summary

eigrp router-id 6.6.6.6

!

Autor original: Bruno Barata

Fonte: http://babarata.blogspot.com.br/

Curso CCNA Netfinder por R$20,00 só hoje.

tux_cisco
Esse curso não tem vinculo algum comigo ou com FLEXPABX, apenas acredito ter um bom custo por R$20,00, normalmente custa R$100,00 EAD tem 90 dias e várias questões explicadas, e outra após tudo isso tem uma prova geral e quem for melhor ganha um voucher de CCNA…MESMO que vc não ganhe, tente é de graça, eu fiz curso CCNA 1 2 3 4 na NETACAD em 2008 por R$2500,00reias
aproveite 🙂 é de graça.
FONTE: http://netfindersbrasil.blogspot.com.br/2015/06/doe-r-2000-para-o-ccna-exam-simulation.html

DEU A LOUCA NO NETFINDERSBRASIL !!! Até 30/06/2015 – quem doar doar R$ 20,00 para o CCNA EXAM Simulation Day leva de brinde o acesso ao CCNA Gravado por 90 dias.

É isso mesmo! Visando melhor preparar os candidatos a Certificação CCNA, o Blog estará oferecendo até a meia-noite do dia 30/06/2015 a possibilidade de acessar o curso Preparatório CCNA em Modo Gravado por 90 dias para todos os que fizerem sua doação de R$ 20,00 para o programa que irá pagar o Exame de Certificação CCNA ao candidato que fizer mais pontos no Simulado que será oferecido em 29/11/2015.

Sobre o Preparatório CCNA em Modo Gravado:

O curso é oferecido no formato online, com 36 horas de duração, podendo ser acessado em qualquer hora e a qualquer lugar durante 90 dias consecutivos.

◦Onde: http://www.netfindersbrasil.com.br -> Os alunos que adquirirem o curso online poderão acessar todo o material de apoio (slides e Laboratórios) em nossa plataforma Moodle

◦Quanto: O curso é oferecido por R$ 99,00 (mas até 30/06/2015 – os doadores do CCNA EXAM Simulation o levam na Faixa !)

◦Diferenciais: Laboratórios criados no Packet Tracer 6.0.1 para ilustrar os conceitos abordados e acesso/suporte online via Portal de Treinamentos NetFindersBrasil durante o curso online e pelo período de 3 meses após o término das gravações.

Instrutor: Adilson Florentino – CCNA R&S, CCNA Voice, CCNA Wireless, CCNA Security, CCNP R&S, CCAI e CCSI. Profissional com mais de 12 anos de experiência em tecnologias Cisco.

◦Certificado de participação para todos os alunos ao término do período de inscrição.

◦Carga Horária: 36 horas
12 vídeo-aulas de 02 horas cada
06 sessões de 02 horas cada com resolução de questões de Simulado para Exame CCNA 200-120

Conteúdo Programático:

Aula 01 – Modelo OSI
Aula 02 – Switching e VLANs
Aula 03 – TCP/IP e IPv6
Aula 04 – Endereçamento IP, Subredes, VLSM e CIDR
Aula 05 – Introdução ao sistema Cisco IOS
Aula 06 – Roteamento IP Básico e NAT
Aula 07 – Roteamento IP Avançado – EIGRP e OSPF
Aula 08 – Arquiteturas de Alta Disponibilidade
Aula 09 – Gerenciamento e Troubleshooting Básico
Aula 10 – Listas de Controle de Acesso
Aula 11 – Protocolos WAN
Aula 12 – Preparação para o Exame CCNA 200-120

Lembrando que os doadores também terão acesso as vídeo-aulas contendo 307 questões respondidas e comentadas como preparação para o CCNA EXAM SIMULATION DAY:

Simulado para o Exame – Sessão 01 – questões de 01 a 51
Simulado para o Exame – Sessão 02 – questões de 52 a 102
Simulado para o Exame – Sessão 03 – questões de 103 a 153
Simulado para o Exame – Sessão 04 – questões de 154 a 204
Simulado para o Exame – Sessão 05 – questões de 205 a 255
Simulado para o Exame – Sessão 06 – questões de 256 a 307

Sobre o CCNA EXAM SIMULATION DAY:

Teste seus conhecimentos e prepare-se para tornar-se um profissional certificado !

Ajude-nos a tornar o CCNA Exam Simulation Day realidade. Doe R$ 20,00 usando o botão abaixo e baixe o simulado com 307 questões para o Exame 200-120 (em inglês).

Os doadores receberão acesso ao portal de treinamentos em www.netfindersbrasil.com.br e poderão baixar o PDF com as questões para estudar, além de 06 video-aulas de 02 horas cada com a resolução das questões do Simulado.

O material encontra-se em: Biblioteca NetFinders – Material de Apoio – Simulado CCNA 200-120

Participe !