Um ano e meio depois decidi voltar a estudar para o LAB.
Estive ocupado porém não parei de estudar, nesse meio tempo tive que elaborar alguns projetos e ir para alguns ramos diferentes.
Mês passado eu tirei a certificação CCNA security, fica a dica para você que já tirou o CCNA. Essa certificação é bem fácil, cai muita coisa do CCNA como access-lists com um adicional de Tacacs e Radius, além de um overview de IPsec e ASA.
Dá pra estudar em duas ou quatro semanas dependendo da sua disponibilidade e não é nenhum bicho de sete cabeças e recomendo baixar e testar o CCP Cisco Configurator Professinal pois na prova cai umas 2 ou 3 questões dele.
Basta configurar o IOU ou Dynamips para falar com sua rede local e instalar ele na sua maquina, deixo o link aqui:
CCP - Site da cisco
Essa quinzena vou tirar o CCNA Voice e logo disso vou começar a separar de novo o material para o LAB do CCIE R&S.
Quem quiser pode procurar os Workbooks do CCIE que tem um monte na net e eu recomendo fortemente usar o IOU ao invés do Dynamips, inclusive na prova do LAB a parte de troubleshooting eles usam o IOU, vocês podem procurar o IOU Live CD e usar um VMWare para rodar, fica bem bacana.
Conforme eu for fazendo os LABs daqui a uns meses eu vou postando as novidades.
sábado, 17 de agosto de 2013
quarta-feira, 7 de dezembro de 2011
O Lab !!
Infelizmente não existia disponibilidade do lab em São Paulo e o Mobile Lab só teria ano que vem no Rio, então decidi ir lá em San josé fazer a prova.
Link para ver a disponibilidade dos Labs Moveis:
https://learningnetwork.cisco.com/docs/DOC-3224
Fiquei durante esse tempo fazendo labs e estudando o material do Cisco 360, fiz um bom resumo com muitas dicas práticas e coisas que nunca pensei que me depararia. Infelizmente não estava um bom material para poder colocar no site porque o doc que fiz é de anotações de vários labs por isso as coisas estão bem desorganizadas. Pretendo um dia organizar por tópicos e ir postando essas dicas aqui porque me ajudaram muito no Lab.
O que posso dizer, é que tudo que eu estudei e muito mais estava no lab que fiz. Segui as dicas que vi em blogs e fóruns como dormir bem, comer leve, beber muita agua, durante o almoço não arrebentar de comer e principalmente, manter a calma e se divertir com o Lab.
Apesar de tudo o que eu estudei estar no lab, não tive tempo o suficiente para terminar, é muito pouco tempo para muita coisa a fazer.
A prova começa as 8:00, são duas horas de toubleshooting e temos uns 40 min de almoço. O resto você tem que se virar pra fazer Switing, Frame-relay, OSPF, EIGRP, BGP, Multicast, Security, Services e Configurar as VRFs do VPN MPLS.
Quando foi dando o tempo da prova pulei as tarefas que demandavam mais tempo e fui nas tarefas mais rapidas.
Resultado, não tive tempo de fazer tudo e consegui um score de 65% no troubleshooting e quase a mesma coisa na Parte de config.
Gostei muito do resultado em vista de tudo que caiu e tive certeza que estava no caminho certo dos meus estudos, tudo que caiu eu sabia fazer com exceção do tempo.
Vou dar um tempo agora e retomar a praticar em Fevereiro.
O material do Livro para a prova escrita não chega em nem 10% do que pode cair no LAB, porém o material do Cisco 360 é mais do que suficiente para passar no lab, contanto que tenha muita prática na velocidade, se conseguir completar um LAB do cisco 360 sem errar nada e em 6 horas (Eles recomendam 8) digo que é 100% de certeza que você pode ser aprovado no LAB.
Vou tentar fazer alguns posts das minhas anotações que fiz para o Lab.
Seguimos no caminho e até mais!
Link para ver a disponibilidade dos Labs Moveis:
https://learningnetwork.cisco.com/docs/DOC-3224
Fiquei durante esse tempo fazendo labs e estudando o material do Cisco 360, fiz um bom resumo com muitas dicas práticas e coisas que nunca pensei que me depararia. Infelizmente não estava um bom material para poder colocar no site porque o doc que fiz é de anotações de vários labs por isso as coisas estão bem desorganizadas. Pretendo um dia organizar por tópicos e ir postando essas dicas aqui porque me ajudaram muito no Lab.
O que posso dizer, é que tudo que eu estudei e muito mais estava no lab que fiz. Segui as dicas que vi em blogs e fóruns como dormir bem, comer leve, beber muita agua, durante o almoço não arrebentar de comer e principalmente, manter a calma e se divertir com o Lab.
Apesar de tudo o que eu estudei estar no lab, não tive tempo o suficiente para terminar, é muito pouco tempo para muita coisa a fazer.
A prova começa as 8:00, são duas horas de toubleshooting e temos uns 40 min de almoço. O resto você tem que se virar pra fazer Switing, Frame-relay, OSPF, EIGRP, BGP, Multicast, Security, Services e Configurar as VRFs do VPN MPLS.
Quando foi dando o tempo da prova pulei as tarefas que demandavam mais tempo e fui nas tarefas mais rapidas.
Resultado, não tive tempo de fazer tudo e consegui um score de 65% no troubleshooting e quase a mesma coisa na Parte de config.
Gostei muito do resultado em vista de tudo que caiu e tive certeza que estava no caminho certo dos meus estudos, tudo que caiu eu sabia fazer com exceção do tempo.
Vou dar um tempo agora e retomar a praticar em Fevereiro.
O material do Livro para a prova escrita não chega em nem 10% do que pode cair no LAB, porém o material do Cisco 360 é mais do que suficiente para passar no lab, contanto que tenha muita prática na velocidade, se conseguir completar um LAB do cisco 360 sem errar nada e em 6 horas (Eles recomendam 8) digo que é 100% de certeza que você pode ser aprovado no LAB.
Vou tentar fazer alguns posts das minhas anotações que fiz para o Lab.
Seguimos no caminho e até mais!
quarta-feira, 15 de junho de 2011
Sucesso!!
Faz um tempo que eu não posto, na verdade eu estava relendo todo o resumo do site, lendo novamente o livro e fazendo alguns labs.
Mas gostaria de falar que valeu muito a pena esses quase dois anos de estudo.
Semana passada eu PASSEI na prova!!! Sim.. com 991 pontos.
Fiquei muito feliz e satisfeito com o resultado, a prova não foi fácil e exige muita atenção.
O conteúdo do livro mais o conteúdo do site da Cisco foi suficiente para completar a prova. Basta seguir o Blueprint.
Agora vou me dedicar ao estudo pro laboratório, que pelo o que eu estou vendo nos Workbooks será uma prova muito encardida de fazer.
Espero que no final dê tudo certo!!
Obrigado a todos que me apoiaram.
Mas gostaria de falar que valeu muito a pena esses quase dois anos de estudo.
Semana passada eu PASSEI na prova!!! Sim.. com 991 pontos.
Fiquei muito feliz e satisfeito com o resultado, a prova não foi fácil e exige muita atenção.
O conteúdo do livro mais o conteúdo do site da Cisco foi suficiente para completar a prova. Basta seguir o Blueprint.
Agora vou me dedicar ao estudo pro laboratório, que pelo o que eu estou vendo nos Workbooks será uma prova muito encardida de fazer.
Espero que no final dê tudo certo!!
Obrigado a todos que me apoiaram.
segunda-feira, 29 de março de 2010
Existem dois tipos de roteamento multicast:
Dense-Mode
Sparse-Mode
Multicast Forwarding Using Dense Mode
Dense-mode routers não recebem pacotes de um grupo multicast especifico se ambas as condições forem verdadeiras:
■ O roteador não tem nenhum router downstream que precisa receber pacotes do grupo.
■ O Roteador não tem nenhuma subnet conectada que ingressou naquele grupo.
DVMRP, PIM-DM, e o MOSPF são os protocolos dense-mode.
Multicast Forwarding Using Sparse Mode
A diferença fundamental entre dense-mode e sparse-mode é seu comportamento padrão.
Por default os protocolos dense-mode sempre encaminham tráfego a não ser que o downstream router envie uma menssagem informando que não deseja receber aquele tráfego. Os Protocolos Sparse-mode
não encaminha tráfego do grupo a não ser que ele receba uma menssagem solicitando tráfego de determinado grupo multicast.
TTL Scoping
Quando um pacote chega no roteador e tem que ser encaminhado a outras interfaces o roteador compara o se o TTL do pacote é maior ou igual ao TTL da interface, se sim ele o encaminha.
Por default o TTL na cisco é Zero.
Protocolos Dense-mode
PIM-DM - Protocol Independent Multicast Dense Mode
Diferente do DVMRP e do MOSPF ele utiliza a tabela de roteamento para realizar o RPF check.
O PIM estabelece relacionamento com seus vizinhos utilizando mensagens Hello que são enviadas a cada 30 segundos utilizando o protocolo IP 103 e o endereço 224.0.0.13 (All-PIM-Routers), oHoldtimer geralmente é três vezes o tempo do Hello.
O PIM utiliza uma arvore STP para cada grupo multicast com base na origem e nos hosts que recebem o tráfego multicast.
Para habilitar o PIM bastam 2 comandos:
Global - ip multicast-routing
Em cada interface - ip pim dense-mode
Para verificar a routing table multicast: show ip mroute
Onde ele mostra o ip de origem 10.1.1.10 (S) e o grupo multicast de destino 226.1.1.1 (G) no formato da entrada (S,G).
R3#show ip mroute
Mostra que a entrada está ativa fazem 12 segundos e que se R3 não encaminhar nenhum pacote dentro de 2:48 a entradá irá expirar.
O Flag C indica que existe um host interessado no tráfego 226.1.1.1 diretamente conectado. A Flag T indica que o tráfego é encaminhado pelo STP.
Prune Message
Quando R3 recebe mensagens dessa entrada do R2, ele realiza o RPF check e envia ao R2 uma Prune Message, então R2 aguarda 30 segundos e não encaminha mais tráfego dessa entrada ao R3.
Prune override
Caso exista algum router R4 no mesmo seguimento que deve receber o tráfego, esse router R4 ao receber tambem o Prune message (por que esta no mesmo seguimento) envia uma mensagem chamada Prune override informando que apesar do R3 não querer tráfego, tem alguem ali naquele seguimento que quer.
*Quando RPF nbr é 0.0.0.0 significa que o router está diretamente conectado a origem (10.1.1.10)
R2#show ip mroute
Como ele está trabalhando com o DM se o Prune timer (2:52) chegar a zero a interface vai para Forward novamente, a não ser que R3 envie uma state refresh message ao R2 de tempos em tempos antes do Prune Timer expirar em R2.
Graft message
Caso o router receba um IGMP Join nesse meio tempo ele envia uma Graft message solicitando o unpruning da porta, fazendo com que ele comece a receber o tráfego imediatamente sem ter que esperar os 3 minutos.
2 routers conectados diretamente num mesmo seguimento
Assert Messages
Caso existam 2 routers conectados diretamente num mesmo seguimento onde existe um router interessado, é efetuado um critério de desempate para apenas um enviar o trafégo multicast, evitando assim desperdicio de banda, através de Assert Messages, os critérios são:
1- Quem usa o protocolo com a menor distância administrativa.
2- No empate, a menor métrica.
3- No empate, o router com o maior IP na LAN.
Designated Router
Caso existam 2 routers conectados diretamente num mesmo seguimento é eleito um router para gerenciar as menssagens IGMP. o IGMPv2 elege o router com o menor IP da LAN.
*Por causa disso geralmente o designated Router não é o mesmo rotuer que envia o tráfego multicast.
RESUMO DAS MENSAGENS PIM-DM
Dense-Mode
Sparse-Mode
Multicast Forwarding Using Dense Mode
Dense-mode routers não recebem pacotes de um grupo multicast especifico se ambas as condições forem verdadeiras:■ O roteador não tem nenhum router downstream que precisa receber pacotes do grupo.
■ O Roteador não tem nenhuma subnet conectada que ingressou naquele grupo.
DVMRP, PIM-DM, e o MOSPF são os protocolos dense-mode.
Multicast Forwarding Using Sparse Mode
A diferença fundamental entre dense-mode e sparse-mode é seu comportamento padrão.
Por default os protocolos dense-mode sempre encaminham tráfego a não ser que o downstream router envie uma menssagem informando que não deseja receber aquele tráfego. Os Protocolos Sparse-mode
não encaminha tráfego do grupo a não ser que ele receba uma menssagem solicitando tráfego de determinado grupo multicast.
TTL Scoping
Quando um pacote chega no roteador e tem que ser encaminhado a outras interfaces o roteador compara o se o TTL do pacote é maior ou igual ao TTL da interface, se sim ele o encaminha.Por default o TTL na cisco é Zero.
Protocolos Dense-mode
PIM-DM - Protocol Independent Multicast Dense Mode
Diferente do DVMRP e do MOSPF ele utiliza a tabela de roteamento para realizar o RPF check.
O PIM estabelece relacionamento com seus vizinhos utilizando mensagens Hello que são enviadas a cada 30 segundos utilizando o protocolo IP 103 e o endereço 224.0.0.13 (All-PIM-Routers), oHoldtimer geralmente é três vezes o tempo do Hello.
O PIM utiliza uma arvore STP para cada grupo multicast com base na origem e nos hosts que recebem o tráfego multicast.Para habilitar o PIM bastam 2 comandos:
Global - ip multicast-routing
Em cada interface - ip pim dense-mode
Para verificar a routing table multicast: show ip mroute
Onde ele mostra o ip de origem 10.1.1.10 (S) e o grupo multicast de destino 226.1.1.1 (G) no formato da entrada (S,G).
R3#show ip mroute
Mostra que a entrada está ativa fazem 12 segundos e que se R3 não encaminhar nenhum pacote dentro de 2:48 a entradá irá expirar.O Flag C indica que existe um host interessado no tráfego 226.1.1.1 diretamente conectado. A Flag T indica que o tráfego é encaminhado pelo STP.
Prune Message
Quando R3 recebe mensagens dessa entrada do R2, ele realiza o RPF check e envia ao R2 uma Prune Message, então R2 aguarda 30 segundos e não encaminha mais tráfego dessa entrada ao R3.
Prune override
Caso exista algum router R4 no mesmo seguimento que deve receber o tráfego, esse router R4 ao receber tambem o Prune message (por que esta no mesmo seguimento) envia uma mensagem chamada Prune override informando que apesar do R3 não querer tráfego, tem alguem ali naquele seguimento que quer.
*Quando RPF nbr é 0.0.0.0 significa que o router está diretamente conectado a origem (10.1.1.10)
R2#show ip mroute
Como ele está trabalhando com o DM se o Prune timer (2:52) chegar a zero a interface vai para Forward novamente, a não ser que R3 envie uma state refresh message ao R2 de tempos em tempos antes do Prune Timer expirar em R2.Graft message
Caso o router receba um IGMP Join nesse meio tempo ele envia uma Graft message solicitando o unpruning da porta, fazendo com que ele comece a receber o tráfego imediatamente sem ter que esperar os 3 minutos.
2 routers conectados diretamente num mesmo seguimento
Assert Messages
Caso existam 2 routers conectados diretamente num mesmo seguimento onde existe um router interessado, é efetuado um critério de desempate para apenas um enviar o trafégo multicast, evitando assim desperdicio de banda, através de Assert Messages, os critérios são:
1- Quem usa o protocolo com a menor distância administrativa.
2- No empate, a menor métrica.
3- No empate, o router com o maior IP na LAN.
Designated Router
Caso existam 2 routers conectados diretamente num mesmo seguimento é eleito um router para gerenciar as menssagens IGMP. o IGMPv2 elege o router com o menor IP da LAN.
*Por causa disso geralmente o designated Router não é o mesmo rotuer que envia o tráfego multicast.
RESUMO DAS MENSAGENS PIM-DM
quarta-feira, 10 de março de 2010
Otimizando o uso Multicast na LAN
Como IGMP trabalha na camada 3, para evitar o uso de recursos desnecessários na LAN é possivel usar:
IGMP Snooping
Cisco Group Management Protocol (CGMP).
CGMP - Cisco Group Management Protocol
Protocolo proprietário da Cisco.
Apenas o Router gera mensagens e o Switch apenas as escuta
As mensagens CGMP são enviadas ao endereço de multicast 0100.0cdd.dddd contendo os seguintes campos:
GDA - Group Destination Adress
USA - Unicast Source Adress
O router envia a Router Join Message (GTA = 0, USA= Próprio MAC), para informar ao Switch que aquela porta está conectada a um router multicast e são renovadas a cada 60 segundos.
Igualmente ele pode enviar uma mensagem tipo Leave, tambem no mesmo formato (GTA = 0, USA= Próprio MAC). para liberar a porta Router CGMP.
Quando um host ingressa a um grupo multicast o roteador envia uma mensagem CGMP(GTA = End Multicast, USA= MAC do Host) ao Switch informando que o mac address do host irá receber mensagens de determinado grupo multicast, então o Switch relaciona a porta do Host com o Grupo Multcast em uma tabela.Do mesmo modo é possível informar ao SW que o host não recebe mais tráfego multicast.
Também é possivel limpar as entradas CGMP com o comando clear ip cgmp.
Segue uma tabela com o resumo das mensagens:
IGMP Snooping
Parecido com o CGMP, só que faz com que o SWITCH escute as mensagens IGMP e monte a tabela ao invés de aguardar mensagens CGMP do roteador. O Leave Group message só é encaminhada ao roteador quando não existir nenhuma outra porta associada ao endereço de multicast na tabela do Switch.
terça-feira, 23 de fevereiro de 2010
Multicast II - IGMP
IGMP Internet Group Management Protocol
Para maiores detalhes consulte as RFCs:
IGMPv1 - http://www.ietf.org/rfc/rfc1112.txt
IGMPv2 - http://www.ietf.org/rfc/rfc2236.txt
IGMPv3 - http://www.ietf.org/rfc/rfc3376.txt
O CCIE foca no IGMPv2, então é onde vou concentrar esforços.
O maior objetivo do IGMP é informar o roteador multicast local que um host:
-Deseja receber o tréfeco multicast ingressando em um grupo.
-Deseja deixar o grupo multicast.
Como o IGMP tem um significado local (Host - Router), ele não é propagado a outro roteador, logo seu TTL é setado como 1.
Para multicast L2 é usado outros protocolos (IGMP Snooping, CGMP e RGMP
Existem 4 tipos de menssagens:
-Membership Query (0x11) - O Router Multicast envia essa mensagem depois de receber um "Leave Group" para verificar se existe mais algum Host no segmento, que ainda deseja receber tráfego Multicast.
- V1 MS Report (0x12) - Para compatibilidade com o IGMPv1
- V2 MS Report (0x16) - Informa ao Router Multicast que o host deseja receber tráfego, seja em resposta a MS Query ou enviado sem esperar a MS Query.
- Leave Group (0x17) - Informa ao Router Multicast que o host não deseja mais receber tráfego.
O processo é bem simples.
Aplicação configura o host a ingresar em um grupo multicast, calcula o endereço de MAC de multicast e o host passa a "escutar" o tráfego camada 2 para esse MAC multicast e seu MAC (BIA)
Ou eles enviam um MS Report direto ou aguardam para enviar em resposta ao MS Query.
Quando recebem um MS Query eles enviam o MS Report no tempo aleatório entre 0.1 e MRT (Maximum response time) se um host receber o MS report de outro router ele suprime o envio de seu MS report para evitar envios de MS report desnecessários, uma vez que o router apenas envia ou não tráfego para um determinado segmento.
Quando o host sai do grupo multicast e envia o Leave Group o router multicast envia uma mensagem MS query no segmento para verificar se existe algum host que ainda deseja receber tráfego dai voltamos ao processo de resposta do MS Query.
Se nenhum host responder dentro do MRT o host repete o processo o numero de vezes definido no "Last Member Query Count" Então o tempo que o router demora para parar de enviar tráfego multicast depois de receber o MS Leave do ultimo host é o MRT x LMQC.
Fácil :)
*Afim de evitar ataques de DoS o IGMPv3 utiliza um recurso chamado SSM (Source-Specifc Multicast.
Comparação entre as versões IGMP.
Para maiores detalhes consulte as RFCs:
IGMPv1 - http://www.ietf.org/rfc/rfc1112.txt
IGMPv2 - http://www.ietf.org/rfc/rfc2236.txt
IGMPv3 - http://www.ietf.org/rfc/rfc3376.txt
O CCIE foca no IGMPv2, então é onde vou concentrar esforços.
O maior objetivo do IGMP é informar o roteador multicast local que um host:
-Deseja receber o tréfeco multicast ingressando em um grupo.
-Deseja deixar o grupo multicast.
Como o IGMP tem um significado local (Host - Router), ele não é propagado a outro roteador, logo seu TTL é setado como 1.
Para multicast L2 é usado outros protocolos (IGMP Snooping, CGMP e RGMP
Existem 4 tipos de menssagens:-Membership Query (0x11) - O Router Multicast envia essa mensagem depois de receber um "Leave Group" para verificar se existe mais algum Host no segmento, que ainda deseja receber tráfego Multicast.
- V1 MS Report (0x12) - Para compatibilidade com o IGMPv1
- V2 MS Report (0x16) - Informa ao Router Multicast que o host deseja receber tráfego, seja em resposta a MS Query ou enviado sem esperar a MS Query.
- Leave Group (0x17) - Informa ao Router Multicast que o host não deseja mais receber tráfego.
O processo é bem simples.Aplicação configura o host a ingresar em um grupo multicast, calcula o endereço de MAC de multicast e o host passa a "escutar" o tráfego camada 2 para esse MAC multicast e seu MAC (BIA)
Ou eles enviam um MS Report direto ou aguardam para enviar em resposta ao MS Query.
Quando recebem um MS Query eles enviam o MS Report no tempo aleatório entre 0.1 e MRT (Maximum response time) se um host receber o MS report de outro router ele suprime o envio de seu MS report para evitar envios de MS report desnecessários, uma vez que o router apenas envia ou não tráfego para um determinado segmento.
Quando o host sai do grupo multicast e envia o Leave Group o router multicast envia uma mensagem MS query no segmento para verificar se existe algum host que ainda deseja receber tráfego dai voltamos ao processo de resposta do MS Query.
Se nenhum host responder dentro do MRT o host repete o processo o numero de vezes definido no "Last Member Query Count" Então o tempo que o router demora para parar de enviar tráfego multicast depois de receber o MS Leave do ultimo host é o MRT x LMQC.
Fácil :)
*Afim de evitar ataques de DoS o IGMPv3 utiliza um recurso chamado SSM (Source-Specifc Multicast.
Comparação entre as versões IGMP.
Multicast
Quando falamos em Multicast estamos falando em exibir um fluxo de dado a muitos destinos otimizando os recursos da rede, não criando um fluxo unicast para cada destino, mas sim um fluxo unico que diferente do broadcast é enviado somente a segmentos interessados da rede.
A IANA definiu que o grupo Multicast deve usar a classe D de endereços IP (224.0.0.0 - 239.255.255.255).
Dentro da classe D a IANA definiu 4 ranges:
1 - quando o 3 octeto é 0 não deve ser roteado, quando 1 sim (Ex: Auto-RP)2 - Usa o protocolo SSM
3- Usado para transformar o numero do AS em end Multicast (Ex AS 5663 em binario (00010110 00011111) Separando em 2 octetos e transformando em decimal temos respectivamente 22 e 31, então o endereço de multicast ficaria (233.22.31.0)
4- Endereços para serem usados dentro do AS. Como os endereços privados 192.168.0.0/16 por ex.
Resumindo:
Os endereços Multicast geram um endereço MAC, segundo os 5 passos do processo a seguir, o administrador apenas deve ter cuidado ao usar um endereço Multicast para não gerar o mesmo numero MAC para aplicações distintas.
No proximo post vou falar sobre os protocolos que administram os grupos Multicast. IGMP, CGMP e RGMP
Assinar:
Postagens (Atom)