cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
Comunicados
Bem-vindo à Comunidade de Suporte da Cisco, gostaríamos de ter seus comentários.
ATE_protocolo_EIGRP

Routing & Switching Blogues

Rótulos
894 visualizações
0 Comentários

A necessidade por Engenharia de Tráfego e a relação com o MPLS TE


O Multiprotocol Label Switching Traffic Engineering (MPLS TE) é uma tecnologia que foi criada para sanar uma deficiência inerente do próprio modelo de roteamento instaurado e suportado pelo protocolo IP. Essencialmente, ou resumidamente, o MPLS TE propõe-se a resolver os seguintes grandes desafios em temos técnicos que são decorrentes do roteamento IP padrão:

 

  • Ineficiências naturais do roteamento IP e as soluções funcionais do MPLS para cada caso.
  • O roteamento baseado no protocolo IP possui alguns “defeitos”, conforme esclarecido a seguir:

Limitações nativas do roteamento IP

 

  • Comportamento natural “salto-a-salto” (per-hop behavior) e orientado somente ao endereço IP de destino. Ou seja, o roteamento IP unicast tradicional não se importa com a origem do pacote (exceto, de certa forma, quando implementando mecanismos adicionais, como o uRPF) e sim para onde os pacotes deverão ser encaminhados;
  • Má utilização dos recursos de rede disponíveis;
  • Congestionamentos na rede que são causados pelo próprio fato do roteamento IP sempre utilizar os caminhos de menor custo;
  • Consequentemente, a existência de poucos links saturados/congestionados atendendo a maior parte do tráfego, enquanto, ao mesmo tempo, havendo outras opções de links que poderiam ser utilizados para encaminhar tráfego e que estão com baixa utilização (enlaces subutilizados);

Propostas de aprimoramentos com o MPLS TE

 

  1. Como alternativa mais inteligente aos problemas de congestionamento supracitados, dispensar a manipulação de métricas dos protocolos IGP e o uso de ferramentas complexas para filtrar, selecionar, e influenciar o tráfego na rede;
  2. Assegurar níveis de serviço (SLA) mais agressivos e competitivos e facilitar o mapeamento de classes de tráfego para os túneis de TE, e com isto fomentar uma engenharia de tráfego mais inteligente e simplificada;
  3. Possibilitar maior consistência do QoS fim a fim;
  4. Permitir a implementação de facilidades de rápida recuperação da conectividade fim a fim em cenários de falhas de enlaces e equipamentos no backbone;
  5. Fornecer uma solução mais atraente no ponto de vista operacional, pois a dispensa de ferramentas e componentes mais complexos reduz proporcionalmente o surgimento de problemas e incidentes na infraestrutura decorrentes de falha humana (configuração indevida ou incorreta de elementos e facilidades e que poderiam ocasionar em indisponibilidades, por exemplo).


Onde o MPLS Traffic Engineering (TE) é comumente empregado?


O MPLS TE é uma tecnologia muito implementada em backbones de operadoras (provedores de acesso de Internet ou multisserviços e afins) e que serve para manipular o tráfego da rede com maior facilidade e flexibilidade, porém sem que sejam exigidas modificações nas propriedades dos protocolos de roteamento IGP em uso, tais como, por exemplo, custos de interfaces de roteadores habilitadas para o protocolo de roteamento OSPF ou ISIS, e também dispensando o uso de complexas políticas de roteamento.

 

A escalabilidade da infraestrutura no geral é sem dúvida alguma aprimorada e assegurada a um fator pouco oneroso operacionalmente. O MPLS TE é também muito apreciado para promover uma convergência muito rápida no backbone em cenários de falhas de enlaces ou roteadores com o uso da ferramenta “Fast Reroute (FRR) Link and Node Protection”, com possibilidade de recuperar LSPs em até 50 ms! Sem contar com recursos tais como a (re)otimização de túneis de TE no regime “Make Before Break”, dentre outros.


Para compreender os benefícios do MPLS TE, você precisa primeiro conhecer como funciona o roteamento IP.  Com o MPLS TE, conseguimos eliminar as seguintes deficiências nativas do roteamento IP “padrão”, as quais apresentaremos na ordem correta abaixo:

 

Comportamento típico do roteamento IP

 

  1. O roteamento IP ocorre sempre no regime “salto-a-salto” e com base nos endereços IP de destino, e adotando o critério de “caminho de menor custo”. No que tange ao conceito de “menor custo”, consideramos os seguintes:
    1. Cada protocolo de roteamento possui o seu próprio critério de seleção dos caminhos de “menor custo”. Por exemplo, o RIP emprega o conceito de “hop count”; o OSPF emprega o conceito de “Cost” (que é inversamente proporcional à banda das interfaces); o EIGRP emprega o conceito de “Composite Metric” (menor banda ao longo do caminho + a soma dos delays de todas as interfaces envolvidas);
    2. Seleção de rotas para publicação na tabela de roteamento de acordo com o critério de confiabilidade da origem da informação
  2. O valor “Administrative Distance” é usado pelo roteador para selecionar as rotas de origem/protocolos “mais confiáveis” na perspectiva ou entendimento do próprio sistema operacional. Por exemplo, em um roteador Cisco, uma rota para uma determinada rede aprendida via OSPF, por exemplo 100.100.100.0/24, possui um valor de confiabilidade denominado “AD 110” sendo, portando, preferida sobre uma rota para esta mesma rede (100.100.100.0/24) aprendida via o protocolo RIP, cujo AD seria o de “120”;
    1. Quando há rotas de custos iguais, o load sharing pode ser viabilizado…
  3. Quando há duas ou mais opções de rotas para uma mesma rede de destino e aprendidas pelo mesmo protocolo de roteamento – por exemplo, OSPF cujo AD é “110” – será considerada aquela que apresentar o menor custo. Uma rota de custo “200” é preferida sobre uma rota para a mesma rede da primeira opção de rota que tiver, por exemplo, um custo de “500”. Havendo duas ou mais rotas com custos iguais, estas opções de rotas, cujas quantidades máximas são variáveis e dependem da plataforma ou equipamento utilizado, poderão ser instaladas para efeitos de “load sharing”;
    1. No caso do OSPF há outro critério de seleção que tem precedência sobre os custos: rotas intra-área são preferidas sobre rotas interarea, depois rotas externas tipo 1 e, por último, rotas externas tipo 2.
  4. Critério primário para encaminhamento de pacotes: prefixo mais específico contido na FIB, independente da origem da informação/rota, AD, métrica…
  5. No que tange ao encaminhamento de pacotes pelo roteador, o critério principal de seleção de uma rota para encaminhamento deste tráfego será a rota que for a mais específica. Por exemplo, o endereço IP de destino citado no cabeçalho IP do pacote é “10.1.1.1”, e o roteador possui duas rotas possíveis e que atenderiam ao propósito: 10.1.1.0/28 via RIP e 10.1.1.0/24 via OSPF. A opção /28 é mais específica que a opção /24 e, portanto, esta rota e a sua adjacência associada serão utilizadas;
    1. Se, por exemplo, tivéssemos três opções de rotas, sendo a primeira 10.1.1.0/24 pelo RIP, e 10.1.1.0/24 pelo OSPF com custo de 100 e 10.1.1.0/24, também pelo OSPF, com custo de 200, a única rota que existiria na tabela de roteamento seria a rota OSPF 10.1.1.0/24 com custo de 100;
    2. Observações: não entraremos em detalhes aqui, mas as plataformas de roteamento modernas não processam o encaminhamento de pacotes pela tabela de roteamento (o que seria uma estrutura de dados mantida no Control Plane do equipamento), e sim por estruturas de comutação mais inteligentes e programadas no hardware do equipamento (ex: Line Card, I/O Modules), o que seria considerado o Data Plane.
    3. Estas estruturas (por exemplo, FIB) são alimentadas pelas instruções contidas na RIB (tabela de roteamento), enquanto as informações para a reescrita dos cabeçalhos de camada 2 – ADJ no Data Plane, e processos tais como ARP, no Control Plane – havendo, portanto, uma relação entre processos de Control Plane e Data Plane. Mas isto fica para um próximo artigo!
  6. Portanto, do ponto “A” para o ponto “B” poderão haver múltiplas opções, porém suponhamos que somente uma única opção (a melhor opção, ou “shortest path”) tenha sido escolhida;
  7. O encaminhamento de pacotes nas redes IP possui limitações, entenda:
    1. O roteamento IP encaminhará o tráfego salto-a-salto ao longo deste melhor caminho, enquanto as outras opções de caminhos/alternativas não são utilizadas ou aproveitadas;
  8. Se a quantidade de tráfego ofertado sobre este caminho for superior à capacidade de algum dos links ou interfaces envolvidas nesta melhor rota, haverá congestionamentos e potencialmente descartes de pacotes na rede, resultando em baixo desempenho e baixo throughput;
    1. Consequentemente, o chamado “melhor caminho” fica saturado, sobrecarregado;
    2. Ao mesmo tempo em que os caminhos alternativos não são utilizados ou ficam muito subutilizados;
    3. O mapeamento do tráfego de rede sobre os recursos disponíveis é muito ineficaz;
  9. As consequências disto tudo são reclamações, problemas, impactos, e o seu planejamento de capacidades fica complexo e oneroso.

 

Os benefícios do MPLS TE

 

Como o MPLS TE poderá servir para aliviar congestionamentos na rede decorrentes do comportamento natural das redes IP? O MPLS pode atuar em duas frentes para o efeitivo planejamento de capacidades, qualidade de serviço, aumento de SLA e maior disponibilidade da infraestrutura: engenharia de tráfego e proteção contra falhas. 

 

Conforme já apresentado, um dos maiores problemas sanados pelo MPLS TE é o que chamamos "The Fish Problem", decorrente do processo de seleção do caminho de menor custo dos protocolos de roteamento IP.

 

MPLS TE.png


O MPLS TE é uma excelente ferramenta para aliviar os congestionamentos persistentes no backbone, ao mesmo tempo em que dispensando procedimentos de engenharia de tráfego “padrão”, tais como modificações de parâmetros dos protocolos IGP (custos, métricas, etc.), que costumam resolver “um” problema e ao mesmo tempo causar outros “500” problemas!

 

O MPLS TE poderá também servir como componente de alta resiliência para cenários de falhas, sendo esta uma das capacidades mais apreciadas do MPLS TE, ou seja, o Fast Reroute (FRR).

 

MPLS TE 2.png

 

Espero ter esclarecido algumas coisas importantes sobre o MPLS TE: não faz mágica e não é a solução para congestionamentos de curto prazo decorrentes de eventos inesperados. O MPLS TE é eficiente nas questões de planejamento de capacidades e congestionamentos persistentes, além de servir como excelente ferramenta para maior disponibilidade do backbone.

 

Consulte o arquivo PDF em anexo: é um formidável mapa mental (mind map) que resume diversas das tecnologias e componentes empregados nas arquiteturas e aplicações baseadas no MPLS!

 

E aproveite a oportunidade para conferir este webcast para conhecer melhor o MPLS!

 

Desvendando o MPLS - Webcast Vídeo

 

 

Espero ter contribuído com este artigo.

 

Cordialmente,

 

Leonardo Furtado

211 visualizações
1 Comentário

Olá! E bem vindo à Comunidade de Suporte Cisco em Português!

 

Este documento foi produzido para auxiliar os profissionais da área no processo de dimensionamento e seleção de uma plataforma de roteamento para aplicações com o protocolo de roteamento BGP.

 

Em primeiro lugar, é necessário compreendermos que equipamentos tais como roteadores devem ser tratados como soluções, e, portanto, devem ir de encontro à uma grade de especificações técnicas que seja aderente aos propósitos e requisitos tanto do negócio quanto de seu projeto técnico. A escolha do roteador ideal para o seu projeto deverá observar alguns critérios de dimensionamento, dos quais exemplifico alguns a seguir:

 

ACERCA DA DENSIDADE, QUANTIDADE E TIPO DE INTERFACES/PORTAS DO EQUIPAMENTO:

 

Objetivo: permitir identificar e validar os requerimentos de conectividade física, particularmente a quantidade de interfaces - e capacidades das mesmas - para que o roteador atenda não somente à quantidade de portas do cenário atual, mas que este dimensionamento apresente alguma escalabilidade com termos de crescimento futuro desta demanda. Isto inclusive ditará se o equipamento deverá apresentar uma configuração fixa (de interfaces) ou modular (com slots para expansão de interfaces adicionais).

 

  1. Qual a densidade/quantidade de portas 1 Gigabit desejada?
  2. Qual a densidade/quantidade de portas 10 Gigabit desejada?
  3. Há a expectativa de usar portas de 40 Gbps no momento? Ou há a expectativa de adoção de 40 Gbps neste equipamento daqui a 1 ou 2 anos? Caso afirmativo, talvez seja melhor considerar um equipamento que possua suporte a 40 Gbps por meios de módulo adicional, o qual você poderia investir lá na frente.
  4. O mesmo com relação à necessidade de adoção de interfaces 100 Gbps.
  5. Quais deverão ser as interfaces de conexão com a rede cabeada (UTP, fibra ótica...). No caso de conexões por fibras óticas, quais deverão ser os transceptores óticos embarcados no fornecimento? Por exemplo, tipo de fibra (multimodo, monomodo), distância, wavelength, conector, etc., isto válido tanto para SFP quanto para SFP+/XFP, QSFP...
  6. Fatore a escalabilidade final desejada para o equipamento, pois isto ditará quantos slots para módulos de portas deverão acompanhar a solução – embora que não todos necessariamente preenchidos com módulos de portas inicialmente, mas isto se traduziria em uma solução mais escalável com melhores investimentos em longo prazo.

 

ACERCA DAS CARACTERÍSTICAS DE ALTA DISPONIBILIDADE

 

Objetivo: identificar e validar as características físicas e lógicas no tocante aos propósitos por alta disponibilidade e resiliência, os quais se traduzirão em melhores indicadores de níveis de serviços. Um bom diagrama de bloco de confiabilidade, além da computação dos devidos valores de MTBF e MTTR, poderão ser muito úteis na hora de tomar esta decisão.

 

  1. Qual deverá ser a conexão do equipamento para a rede elétrica? AC ou DC?
  2. Deverá incluir fontes de alimentação em configuração redundante 1 + 1 ou N + 1?
  3. Deverá haver redundância no módulo de supervisão e controle? Ex: duas RP/RSP em configuração redundante, para maximizar a alta disponibilidade, consequentemente aprimorar substancialmente o SLA de clientes atendidos por este equipamento?
  4. No caso de optar por não redundância de hardware (sem dual RP/RSP), a redundância por software é viável (isto está disponível em alguns equipamentos, com cópias redundantes do Cisco IOS XE Software)?
  5. Entenda que a alta disponibilidade não é conquistada pelo hardware redundante apenas, e que facilidades/recursos do software do equipamento precisam ser considerados e projetados para que haja este "matrimônio"entre os componentes redundantes do hardware e a arquitetura do software da plataforma (ex: SSO, NSF, NSR, BFD, BGP PIC Edge, etc.).
  6. Estude a sua rede e identifique os pontos de falhas tratados como "SPOF" (single points of failure) usando um RBD. Procure derivar estes cenários de falhas para que a sua rede apresente o nível de confiabilidade compatível com as necessidades ou exigências por alta disponibilidade.

 

ACERCA DAS FACILIDADES E RECURSOS DE SOFTWARE:

 

Objetivo: identificar e validar as aplicações gerais do equipamento, as quais poderão especializar o equipamento para escala multisserviço ou não. Isto definitivamente governará não somente o software, mas a própria "classe"do equipamento a ser adotado.

 

  1. Qual deverá ser a missão “final” do equipamento? Suportar apenas o BGP para interconexão com outras operadoras/provedores? Ou ser uma legítima borda de serviços? No caso de BGP apenas:
    1. Quantas sessões full routes para peering e trânsito? Quantas full routes deverão ser suportadas? Isto ditará a quantidade de memória RAM recomendada e também no dimensionamento do hardware para o processamento de pacotes.
    2. Qual deverá ser a capacidade de banda agregada e non-blocking da solução? Ou seja, quantos Gbps "reais" (com ou sem oversubscription por módulo line card) o roteador deverá suportar, e considerando eventual crescimento desta demanda para o seu projeto?
  2. Este roteador atuará como uma borda de serviços para clientes, em adição ao suporte de BGP?
    1. O equipamento realizará serviços tais como L3VPN MPLS para clientes corporativos (o que exigiria suporte a VRFs e ao MPLS, por exemplo)?
    2. Caso você tenha que implementar uma relação PE-CE com clientes corporativos usando o protocolo BGP, como será feito o transporte L2 do CPE do cliente até o seu roteador? Será por L2 puro sobre uma rede com algum protocolo de resiliência (ex: REP ou G.8032) ou por L2VPN (VPLS/VPWS/EVPN)? Há indicadores de dimensionamento aqui, tais como pseudowires e endereços MAC.
    3. O roteador realizará a autenticação de assinantes de Internet banda larga (sessões PPPoE)? Caso afirmativo, quantas sessões máximas simultâneas? Isto ditará o licenciamento deste recurso.
    4. O roteador realizará CGNAT? Quantas traduções simultâneas para IPv4 com e sem o IPv6 na solução? Isto ditará o licenciamento deste recurso.
    5. Procure identificar outros (eventuais ou possíveis) serviços requeridos, sendo estes dependentes de outras facilidades ou não, para que você consiga dimensionar completamente o hardware, software e licenças necessárias.

 

Para concluir, recomendo que sejam evitados roteadores de missão corporativa para projetos em ambientes de provedores, exceto quando posicionados como soluções CE/CPE para a conectividade de clientes corporativos. Os roteadores ISR da Cisco, por exemplo, são soluções excepcionais para clientes corporativos, pois são formidáveis no desempenho e na entrega de ricos recursos geralmente consumidos por empresas. No entanto, são plataformas multisserviços e suportam uma diversidade de soluções em um único equipamento (wireless WLC, firewall, colaboração/comunicações unificadas, e muitos outros.) e dimensionadas para cenários tipicamente corporativos, e não necessariamente projetadas para ambientes de service provider. Um roteador assim entrega serviços que provedores tipicamente não implementam no perímetro destinado para a conectividade por BGP ou borda de serviços/agregação, e, ao mesmo tempo, o equipamento não é de missão específica para justamente aquilo que o provedor está buscando.

 

Para provedores/operadoras, realmente recomendo que sejam considerados os roteadores das famílias Cisco ASR 1000 ou Cisco ASR 9000. São soluções de roteamento de última geração e com missão específica para operadoras/provedores. Apenas procure mapear o seu cenário para os pontos abordados acima para que você possa dimensionar corretamente o seu roteador.

 

Família Cisco ASR 1000

 

2017-12-23_03-46-41.png

 

Família Cisco ASR 9000

 

2017-12-23_03-48-00.png

 

Há projetos que credenciam inclusive a adoção de outras plataformas da Cisco, tais como a família Cisco NCS 5500 ou outros. Cada projeto possui as suas próprias características e é realmente muito importante que você saiba estruturar o seu projeto técnico, selecionar as características físicas, eletromecânicas, componentes em configuração redundante, classe de software, quais recursos (de software) são requeridos para o seu projeto e em suas respectivas qualidades e capacidades, além do licenciamento destes recursos, onde aplicáveis.

 

A Cisco possui parceiros bastante especializados no Brasil. Entre em contato através do link a seguir. Você será atendido diretamente pela Cisco, que destinará um parceiro para cuidar especialmente da sua solicitação, além de esclarecer mais dúvidas e tudo mais: https://engage2demand.cisco.com/LP=581?ecid=136

 

Espero ter contribuído!

 

Leonardo Furtado

4 visualizações
0 Comentários

isto é um teste

22 visualizações
1 Comentário

Todo mundo que trabalha com Linux conhece o famoso serviço Cron, que agenda tarefas periódicas para serem executadas num host. Pois bem, a partir da versão 12.4, os IOS da Cisco disponibilizam um serviço semelhante. Este exemplo copia a running-config para a startup-config, todo domingo as 23:00: Leia mais...

18 visualizações
0 Comentários

Estava pesquisando com o Thiago Correia um assunto totalmente diferente na UNICID quando nos deparamos com algo que nos chamou muito a atenção: a possibilidade de criar menus personalizados para definir um escopo limitado de comandos a um determinado usuário no IOS. Leia mais...

38 visualizações
0 Comentários

Dando sequência aos estudos do curso de Arch, segue o que achei mais interessante nas seções que tratam de detalhes de Projeto de Protocolos de Roteamento Leia mais...

19 visualizações
0 Comentários

No começo do capitulo 3 do material de ARCH, deparo-me com sumarização e criação de ACLs amigáveis. Uma coisa que me chama a atenção é que, ao contrário dos outros materiais da Cisco que já li sobre o assunto, este material sugere que se procure "enxergar" os blocos sumarizados em decimal mesmo, ao invés de converter em binário e olhar a sequencia de bits (gambiarra tal que já fazemos no Netacad há muitos anos, diga-se de passagem). Leia mais...

99 visualizações
0 Comentários

Spanning-Tree Protocol evita a ocorrência de loops na camada 2, elegendo um Switch como Root Bridge e mantendo ativos apenas os links que formam o melhor caminho para esta raiz, deixando os caminhos redundantes bloqueados. Leia mais...

9 visualizações
0 Comentários

Pois é PessoALL, Estudando o material do CCIE vi que há caem muitos comandos relacionados com a configuração do SNMP v3. No CCNA só usamos o SNMP v2, sem criptografia nem autenticação por usuário. Nos labs nos limitamos a ativar o serviço de SNMP e definir a string que é o nome da Community a ser enviada em texto claro. Leia mais...

26 visualizações
0 Comentários

Estava pesquisando sobre o comando no service password-recovery e chamou-me a atenção o fato de que o mesmo não é documentado (não se consegue acha-lo usando a ?). Fiquei interessado pelo tema e resolvi pesquisar ! Leia mais...

69 visualizações
0 Comentários

Este assunto surgiu numa aula de Redes Convengentes na UNIP, onde minha esposa Márcia Santos Florentino trabalha. Achei muito interessante e pedi para publicar no Blog Leia mais...

25 visualizações
0 Comentários

ODR é um recurso disponível nos roteadores Cisco para a criação de rotas dinâmicas sem o uso de um protocolo de roteamento. Leia mais...

4 visualizações
0 Comentários

Criei minha conta no Github para publicar minhas topologias usando o VIRL, você quer dar uma olhada só use o link a seguir https://github.com/rubenvirl/virl

No momento você pode encontrar topologias sobre VPLS, VPLS AutoDiscovery BGP / LDP e LISP

19 visualizações
0 Comentários

Ao realizar alguns testes de DNS, verifiquei que o router estava a bloquear a transferência devido ao tamanho da mensagem. quando iniciada a transferência o route automaticamente envia um pacote RST ao servidor, terminado de imediato a ligação. Efetuada uma captura, foi possível verificar que o RST é enviado pelo router (TTL 254). Por quê? Resposta ALG.

Como ALG pode manipular até um determinado tamanho de mensagem, a única maneira de corrigir isso é desativando o ALG no router.

INTERNET#sh ver | i Vers
Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.2(4)M6, RELEASE SOFTWARE (fc2)

[root@bind9 ~]# dig -y @104.28.16.27 cocheno.com -t axfr;; communications error to 104.28.16.27#53: connection reset

Observando o debug do NAT…..

Jan 11 23:15:10.146: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.150:  NAT-L4F:setting ALG_NEEDED flag in subblock
Jan 11 23:15:10.150: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.150:  NAT-L4F: Policy check successful
Jan 11 23:15:10.150:  NAT-L4F: received fd1: 1073742971 and
tcp flags = 0x2, payload_len = 0
Jan 11 23:15:10.294:  NAT-L4F:setting ALG_NEEDED flag in subblock
Jan 11 23:15:10.294: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.294:  NAT-L4F: received fd2: 1073742972 and
tcp flags = 0x12,payload_len = 0
Jan 11 23:15:10.298:  NAT-L4F:setting ALG_NEEDED flag in subblock
Jan 11 23:15:10.298: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.298:  NAT-L4F: Received final ACK from fd1 : 1073742971 and
tcp flags = 0x10
Jan 11 23:15:10.298:  NAT-L4F:Transistioning to proxy: rc 0 error 0
Jan 11 23:15:10.298:  NAT-L4F: Successfully proxied this flow
Jan 11 23:15:10.298:  NAT-L4F:setting ALG_NEEDED flag in subblock
Jan 11 23:15:10.298: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.298: NAT-ALG: lookup=0 l7_bytes_recd=125 appl_type=12
Jan 11 23:15:10.298: NAT-ALG: DNS l7_msg_size = 125
Jan 11 23:15:10.298: NAT-ALG: after state machine:
Jan 11 23:15:10.298: NAT-ALG: remaining_hdr_sz=0
Jan 11 23:15:10.298: NAT-ALG: remaining_payl_sz=0
Jan 11 23:15:10.298: NAT-ALG: tcp_alg_state=0
Jan 11 23:15:10.298: NAT-ALG: complete_msg_len=125
Jan 11 23:15:10.298:  l4f_send returns 125 bytes
Jan 11 23:15:10.298:  Complete buffer written to proxy
Jan 11 23:15:10.298:  NAT-L4F:NO DATA to read
Jan 11 23:15:10.446:  NAT-L4F:setting ALG_NEEDED flag in subblock
Jan 11 23:15:10.446: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.454:  NAT-L4F:setting ALG_NEEDED flag in subblock
Jan 11 23:15:10.454: NAT-FRAG: tcpmss value :0
Jan 11 23:15:10.454: NAT-ALG: lookup=1 l7_bytes_recd=1452 appl_type=12
Jan 11 23:15:10.454: NAT-ALG: DNS l7_msg_size = 31751
Jan 11 23:15:10.454: NAT-ALG: Unsupported l7_msg_size = 31751
Jan 11 23:15:10.454: NAT-L4F:CSM isn’t able to accept the pkt
Jan 11 23:15:10.458:  NAT-L4F:read RST, aborting
Jan 11 23:15:10.458:  NAT-L4F:setting ALG_NEEDED flag in subblock

 

Como desativar o DNS ALG?

INTERNET-RTR(config)#no ip nat service alg tcp dns

5 visualizações
0 Comentários

Ola, boa noite.

Peco desculpa, se caso estiver postando no lugar errado,pois e meu primeiro post

Alem de ser meu primeiro contato com equipamentos da Cisco.  ;)

Minha duvida e...como eu acesso  e Configuro o Catalyst 2948G apenas para roteamento.   

Obrigado a todos vlw

205 visualizações
0 Comentários

O IP Source Guard garante que o tráfego ingress num porta L2 é originada por um host legitimo, permitindo assim garantir a legitimidade do tráfego originado. Esta feature usa o DHCP snooping e static IP binding para fazer match dos IPs nas portas L2 untrusted.
Inicialmente todo o tráfego é bloqueado excepto os pacotes DHCP. Após um cliente receber o IP via DHCP ou através de uma entrada static, todo o tráfego e autorizado.

Sintaxe:

Router(config)# ip dhcp snooping
Router(config)# ip dhcp snooping vlan number [number]
Router(config)# interface interface-name
Router(config-if)# no ip dhcp snooping trust
Router(config-if)# ip verify source vlan dhcp-snooping
Router(config)# ip source binding mac-address vlan vlan-id ip-address interface interface-name

Exemplo:

Configurar a interface F1/6 em switch port access na VLan 10 e activar o IP Source Guard
Router(config)# ip dhcp snooping
Router(config)# ip dhcp snooping vlan 10 20
Router(config)# interface fa6/1
Router(config-if)# switchport mode access
Router(config-if)# switchport access vlan 10
Router(config-if)# no ip dhcp snooping trust
Router(config-if)# ip verify source vlan dhcp-snooping

Router# show ip verify source

Interface  Filter-type  Filter-mode  IP-address       Mac-address     Vlan

———       ———–  –    ———-     —————         ————–       ———

fa6/1            ip                   active       10.0.0.1                                                  10

fa6/1            ip                   active       deny-all                                                  11-20

fa6/2            ip                   inactive-trust-port

fa6/3            ip                   inactive-no-snooping-vlan

fa6/4            ip                   active       10.0.0.2         aaaa.bbbb.cccc               10

fa6/4            ip                   active       11.0.0.1         aaaa.bbbb.cccd               11

36 visualizações
0 Comentários

Esta feature do BGP permite ao router controlar através de um prefix-list quais os prefixos que o BGP peer deve enviar, permitindo assim reduzir o numero de prefixos processados.

Sintaxe:

router bgp autonomous-system-number
 
neighbor ip-address capability orf prefix-list [send | receive | both]
 
neighbor {ip-address| peer-group-name} prefix-list prefix-list-name {in | out}

Notas:

  • Apenas é usado em eBGP
  • Não suporta multicast
  • Deve ser configurado apenas por address family

Diagrama

BGP Outbound Router Filtering (ORF)

Exemplo 1

O router R2 pretende receber apenas o prefixo 192.168.2.0/24

R1

router bgp 65100
neighbor 192.168.1.2 remote-as 65200
address-family ipv4
neighbor 192.168.1.2 capability orf prefix-list receive

R2

ip prefix-list ORFFILTER seq 5 permit 192.168.2.0/24
 
router bgp 65200
neighbor 192.168.1.1 remote-as 65100
address-family ipv4
neighbor 192.168.1.1 capability orf prefix-list send
neighbor 192.168.1.1 prefix-list ORFFILTER in

 
Verificar os prefixos a filtrar no peering com o R2, definidos pelo prefix-list em R2:

R1#show ip bgp neighbors 192.168.1.2 received prefix-filter
Address family: IPv4 Unicast ip prefix-list 192.168.1.2: 1 entries seq 5 permit 192.168.2.0/24
 
R1#show ip bgp neighbors 192.168.1.2 | beg ORF
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: received
Receive-mode: advertised
Outbound Route Filter (ORF): received (1 entries)

Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
ORF prefix-list: 4 n/a
Total: 4 0
Number of NLRIs in the update sent: max 3, min 1

Tabela de routing do R2

R2#show ip route bgp
 
B 192.168.2.0/24 [20/0] via 192.168.1.1, 00:01:12

 

Exemplo 2

O router R2 pretende receber todos os prefixos excepto o 192.168.2.0/24

R1

router bgp 65100
neighbor 192.168.1.2 remote-as 65200
address-family ipv4
neighbor 192.168.1.2 capability orf prefix-list receive

R2

ip prefix-list ORFFILTER seq 5 deny 192.168.2.0/24
ip prefix-list ORFFILTER seq 10 permit le 0.0.0.0/0 le 32
 
router bgp 65200
neighbor 192.168.1.1 remote-as 65100
address-family ipv4
neighbor 192.168.1.1 capability orf prefix-list send
neighbor 192.168.1.1 prefix-list ORFFILTER in

Verificar os prefixos a filtrar no peering com o R2, definidos pelo prefix-list em R2:

R1#show ip bgp neighbors 192.168.1.2 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 192.168.1.2: 2 entries
seq 5 deny 192.168.2.0/24
seq 10 permit 0.0.0.0/0 le 32
 
R1#show ip bgp neighbors 192.168.1.2 | beg ORF
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: received
Receive-mode: advertised
Outbound Route Filter (ORF): received (2 entries)
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 3 0
Prefixes Total: 3 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
ORF prefix-list: 1 n/a
Total: 1 0
Number of NLRIs in the update sent: max 3, min 1

Tabela de routing do R2

R2#show ip route bgp
B 192.168.4.0/24 [20/0] via 192.168.1.1, 00:00:36
B 192.168.5.0/24 [20/0] via 192.168.1.1, 00:00:36
B 192.168.3.0/24 [20/0] via 192.168.1.1, 00:00:36

Nota:As alterações efetuadas na prefix-list não são propagadas automaticamente, sendo necessário forçar usando:

R2#clear ip bgp 192.168.1.1 in prefix-filter

@Atualizado 19/12/2015

60 visualizações
0 Comentários

O sistema inicia o relógio no momento em que este também inicia e mantém o registo da data/hora.

O relógio do sistema pode ser atualizado das seguintes formas:

  • NTP
  • Simple Network Time Protocol (SNTP)
  • Virtual Integrated Network Service (VINES) Time Service
  • Manual configuration

O NTP permitem garantir a sincronização da data/hora entre os vários elementos, este pode ser configurado nos seguintes modos:

  •    Client/Server
  •     Symmetric Active/Passive – Grupo de peers low stratum operam como backups uns dos outros. Cada peer usa as suas referencias primarias e em caso de falha usa os peers, esta operação e descrita como push-pull. Um peer é configurado em modo  Symmetric Active usando o comando peer. O outro peer também deve ser configurado da mesma forma.
    Nota: Se o outro peer não for configurado com o comando peer, a associacao e feita em Symmetric Passive quando é recebida uma mensagem Symmetric Active.
  •     Broadcast

Exemplo:

Ligações:

R1——-s2/1-R2-f0/1———-f0/0-R3

Autenticar o NTP entre o R1/R3
O R1 deve estar em Symmetric Active mode
O R3 recebe o NTP via broadcast

R1(config)#
ntp authentication-key 1 md5 CCIE
ntp authenticate
ntp trusted-key 1
ntp server 192.168.2.2
ntp peer 192.168.2.2

R2(config)#
ntp authentication-key 1 md5 CCIE
ntp authenticate
ntp trusted-key 1
ntp master 2

R3(config)#
int f0/1
ntp broadcast client

R2#sh ntp associations

address         ref clock     st  when  poll reach  delay  offset    disp
*~127.127.7.1      .LOCL.            1     5    64  377     0.0    0.00     0.0
* master (synced), # master (unsynced), + selected, – candidate, ~ configured

R2#sh ntp status
Clock is synchronized, stratum 2, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is D62E1DCD.301D493F (15:48:29.187 UTC Wed Nov 13 2013)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.02 msec, peer dispersion is 0.02 msec

R1#sh ntp associations de
192.168.2.2 configured, our_master, sane, valid, stratum 2
ref ID 127.127.7.1, time D62E1E4D.301CB65E (15:50:37.187 UTC Wed Nov 13 2013)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 377, sync dist 25.284
delay 12.12 msec, offset 6.2250 msec, dispersion 19.20
precision 2**24, version 3
org time D62E1E63.80060ECC (15:50:59.500 UTC Wed Nov 13 2013)
rcv time D62E1E63.7FCF0483 (15:50:59.499 UTC Wed Nov 13 2013)
xmt time D62E1E63.747ED2BE (15:50:59.455 UTC Wed Nov 13 2013)
filtdelay =    44.14   19.94   47.94   12.12   39.92   40.07   27.91   36.16
filtoffset =   22.92  -16.03    3.07    6.23   11.91   -4.44   -2.76    0.59
filterror =     0.02    0.99    1.97    2.94    3.92    4.90    5.87    6.85

R3#sh ntp associations

address         ref clock     st  when  poll reach  delay  offset    disp
* 192.168.20.2     127.127.7.1       2    18    64  376    16.1   13.55    15.9
* master (synced), # master (unsynced), + selected, – candidate, ~ configured

R3#sh ntp ass detail
192.168.20.2 dynamic, our_master, sane, valid, stratum 2
ref ID 127.127.7.1, time D62E1E8D.301D95DD (15:51:41.187 UTC Wed Nov 13 2013)
our mode bdcast client, peer mode bdcast, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 376, sync dist 24.002
delay 16.07 msec, offset 13.5468 msec, dispersion 15.95
precision 2**24, version 3
org time D62E1E9C.301B1A0A (15:51:56.187 UTC Wed Nov 13 2013)
rcv time D62E1E9C.2CA64C21 (15:51:56.174 UTC Wed Nov 13 2013)
xmt time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
filtdelay =    16.07   16.07   16.07   16.07   16.07   16.07   16.07   16.07
filtoffset =   13.55    1.73   25.91  -16.53   -5.48   -6.40    1.73  -12.14
filterror =     0.99    1.97    2.94    3.92    4.90    5.87    6.85    7.83

9103 visualizações
2 Comentários

VLAN – Virtual LAN, é um recurso disponível em switches que tem como característica principal a segmentação da rede. Uma VLAN é considerada uma rede lógica e permite separar grupos de usuários e assim proporcionar uma melhora no desempenho da rede, entre outros benefícios.

O exemplo clássico de aplicação de VLAN é agrupar portas dos switches de acordo com as departamentos da empresa (Administrativo, Financeiro, Operacional,…). Mas este agrupamento pode ser feito da forma que melhor convier para cada caso. Em geral a regra é que os usuários com o mesmo perfil fiquem na mesma VLAN.

Observe que ao criar uma VLAN você estará criando um domínio de broadcast (pacotes broadcast não são enviados de uma VLAN para outra). Por isso uma máquina na VLAN A não se comunicará com uma máquina na VLAN B. Para que haja comunicação entre hosts em VLANs diferentes é preciso que exista o roteamento entre as VLANs.

Criando uma VLAN em um switch Cisco:

! Entre no modo de configuração global
BrainSW01# configure terminal
! Crie a VLAN que desejar, neste caso 20
BrainSW01(config)# vlan 20
! Adicione um nome a VLAN, o nome padrão seria VLAN0020
BrainSW01(config-vlan)# name BRAIN20
BrainSW01(config-vlan)# end
BrainSW01#wr

Pronto a VLAN 20 está criada. Para verificar a VLAN podemos usar o comando show vlan.

Após criar a VLAN devemos adicionar as portas de acesso a VLAN. As portas de acesso permitem apenas o tráfego da VLAN a qual pertencem.

Adicionando uma porta a VLAN:

! Entre no modo de configuração global
BrainSW01# configure terminal
! Entre na interface que deseja associar a VLAN
BrainSW01(config)# interface fastethernet0/1
! Configure a porta como porta de acesso
BrainSW01(config-if)# switchport mode access
! Adicione a porta a VLAN
BrainSW01(config-if)# switchport access vlan 20
BrainSW01(config-if)# end
BrainSW01#wr

Novamente podemos utilizar o comando show vlan para verificar a associação da porta a VLAN desejada.

Por fim, normalmente é configurada uma porta trunk. A porta trunk permite passar o tráfego de mais de uma VLAN. Na figura abaixo, por exemplo, temos 3 VLANs em cada switch (1, 2 e 17). Com a porta trunk um host que está na VLAN 2 do primeiro switch pode se comunicar com os hosts que estão na VLAN 2 do segundo switch.

Link TRUNK

Configurando uma porta trunk:

! Entre no modo de configuração global
BrainSW01# configure terminal
! Entre na interface que será trunk
BrainSW01(config)# interface fastethernet0/10
! configure a porta como trunk
BrainSW01(config-if)# switchport mode trunk
BrainSW01(config-if)# end
BrainSW01# wr

Existe muito mais teoria sobre VLANs, Trunk e etc… mas espero que este post ajude nos primeiro passos na configuração de VLANs. Quem quiser saber mais pode usar o Configuration Guide do 2960 como base.

Até a próxima.

Postado originalmente em: http://www.brainwork.com.br/blog/2009/03/16/configurando-vlan/

3379 visualizações
1 Comentário

O Cisco IOS é o sistema operacional da maioria dos roteadores, switches e access-points Cisco. E ele possui um funcionalidade chamada IFS – IOS File System.

O IFS permite criar, listar, remover arquivos e diretórios, e usa os mesmos comandos (ou quase) de outros sistemas operacionais como Windows e Linux.

Abaixo um lista dos comandos mais comuns.

  • pwd: mostra o nível do file system em que você está (print working directory), como no Linux.
BrainRT#pwd
flash:
BrainRT#
  • cd: como no Linux ou Windows, permite mudar de diretório.
BrainRT#cd teste
BrainRT#pwd
flash:/teste/
BrainRT#
BrainRT#cd ..
BrainRT#pwd
flash:/
  • dir: como no Windows, mostra a lista de arquivos e diretórios em um determinado nível.
BrainRT#dir
Directory of flash:/
    1  -rw-        34421360  Apr 15 2011 12:23:04 -03:00  c1841-advsecurityk9-mz.124-24.T5.bin
    2  -rw-        6107          Jun 29 2011 13:59:12 -03:00  110629@1359-Config
    6  -rw-        9551          Jul 8 2011 11:18:04 -03:00  110708-Config
    7  -rw-        11543        Jul 25 2011 15:11:10 -03:00  running-config
129740800 bytes total (71872512 bytes free)
BrainRT#
  • copy: copia um arquivo de um lugar para outro. Podemos fazer uma cópia de um diretório para outro na flash, da flash para um tftp, de um ftp para a flash…
BrainRT#copy flash:show_ver.txt tftp://10.10.8.10/BrainRT#copy run start
  • mkdir: cria um diretório.
BrainRT#mkdir teste
Create directory filename [teste]?
Created dir flash:teste
BrainRT#
  • rmdir: remove um diretório (se estiver vazio).
BrainRT#rmdir flash:teste
Remove directory filename [teste]?
Delete flash:teste? [confirm]
Removed dir flash:teste
BrainRT#
  • |: o pipe permite alterar a saída de um comando. Incluir ou remover parte do conteúdo é o mais comum. Mas também podemos usar o | para redirecionar a saída de um comando para um arquivo.
BrainRT#sh run | in ip route
ip route 0.0.0.0 0.0.0.0 Dialer0
ip route 10.10.22.0 255.255.255.0 1.1.1.2
ip route 10.10.28.0 255.255.255.0 1.1.1.2
BrainRT#
BrainRT#sh version | redirect flash:/show_ver.txt
  • more: mostra o conteúdo de um arquivo.
BrainRT#more flash:show_ver.txt
Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(24)T5, RELEASE SOFTWARE (fc3)
Technical Support:
http://www.cisco.com/techsupport
Copyright (c) 1986-2011 by Cisco Systems, Inc.
Compiled Fri 04-Mar-11 02:50 by prod_rel_team
ROM: System Bootstrap, Version 12.4(13r)T5, RELEASE SOFTWARE (fc1)BrainRT uptime is 3 weeks, 3 days, 22 hours, 1 minute
System returned to ROM by power-on
System restarted at 12:18:57 SaPaulo Fri May 25 2012
System image file is "flash:/c1841-advsecurityk9-mz.124-24.T5.bin"
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
Cisco 1841 (revision 7.0) with 118784K/12288K bytes of memory.
Processor board ID FTX1132W0NN
3 FastEthernet interfaces
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
126976K bytes of ATA CompactFlash (Read/Write)
Configuration register is 0×2102BrainRT#
  • write erase: apaga tudo. Volta a configuração padrão de fábrica (no caso de switches NÃO apaga o arquivo vlan.dat).
  • show file systems: lista os sistemas de arquivos disponíveis no seu equipamento. Este comando também exibe informações sobre cada sistema de arquivos.
BrainRT#show file systems
File Systems:
       Size(b)       Free(b)      Type  Flags  Prefixes
             -             -    opaque     rw   archive:
             -             -    opaque     rw   system:
             -             -    opaque     rw   tmpsys:
             -             -    opaque     rw   null:
             -             -   network     rw   tftp:
        196600        179583     nvram     rw   nvram:
*    129740800      71864320      disk     rw   flash:#
             -             -    opaque     wo   syslog:
             -             -    opaque     rw   xmodem:
             -             -    opaque     rw   ymodem:
             -             -   network     rw   rcp:
             -             -   network     rw   http:
             -             -   network     rw   ftp:
             -             -   network     rw   scp:
             -             -    opaque     ro   tar:
             -             -   network     rw   https:
             -             -    opaque     ro   cns:
BrainRT#
  • show file information <arquivo>: mostra informações sobre um arquivo específico.
BrainRT#show file information flash:show_ver.txt
flash:show_ver.txt:
  type is ascii text
BrainRT#
  • delete: apaga um determinado arquivo.

BrainRT#delete flash:show_ver.txt
Delete filename [show_ver.txt]?
Delete flash:/show_ver.txt? [confirm]
BrainRT#

Mais informações sobre o IFS neste link.

Até a próxima.

OBS: Postado originalmente em www.brainwork.com.br.

742 visualizações
1 Comentário

Como sabemos os switches e roteadores Cisco permitem a conexão Telnet para outros dispositivos, pois são clientes Telnet. Ou seja, de um switch podemos acessar outro equipamento que seja um servidor Telnet. O mesmo se aplica ao SSH.

Para usar esta funcionalidade (Telnet/SSH Client), basta entrar na line vty do equipamento de onde a conexão se originará e utilizar o comando transport output. Com ele podemos especificar o tipo de conexão que será permitida sair do equipamento(Telnet, SSH).

Por padrão os equipamentos vem com o Telnet liberado.

Exemplo: Liberando SSH originado no switch/roteador

BrainGW01#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
BrainGW01(config)#line vty 0 4
BrainGW01(config-line)#transport output  ssh
BrainGW01(config-line)#end
BrainGW01#

Output none

Também é possível bloquear as conexões Telnet e SSH originadas no equipamento. Para isso bastar usar a opção none.

Exemplo: Bloqueando conexões Telnet e SSH originadas em um switch

BrainGW01#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
BrainGW01(config)#line vty 0 4
BrainGW01(config-line)#transport output  none
BrainGW01(config-line)#end
BrainGW01#

Com o comando transport output none configurado, caso alguém tente realizar um Telnet ou SSH para outro dispositivo o equipamento gerará a seguinte mensagem:

Unable to Telnet to other devices, and the %telnet connections not permitted from this terminal

Até a próxima.

Postado originalmente em: www.brainwork.com.br

3903 visualizações
0 Comentários

Conectando Sua Rede no Mundo IPv6

Hoje em dia, IPv6 não é mais uma novidade e sim uma realidade, e todos os Services Providers já pensam em como ativar IPv6, e também como prover serviços utilzando IPv6, e isso gera muitas discussões e principalmente uma série de testes, no qual são todos muito importantes.

Existem alguns Serivces Providers que fornecem conectividade IPv6 de uma forma muito simples e sem nenhum custo, e assim fica fácil conectarmos uma rede IPv4 a estes Services Providers, obtendo assim uma completa conectividade ao mundo IPv6, segue alguns Services Providers que fornecem este serviço:

Hurricane Eletric - http://tunnelbroker.net/

SixXS - http://www.sixxs.net/

Através destes dois Services Providers conseguimos conectar um PC individualmente, ou até mesmo um Roteador através de Tunnel GRE, e assim é possível obter um range de endereço IPv6 no qual pode ser distribuído internamente na rede Local, possibilitando vários usuários acessarem o mundo IPv6. Acredito que essa forma é excelente para começar a trabalhar com IPv6 e adquirir mais experiência sobre o assunto, que será fundamental para todos que trabalham com Network.

Sendo assim, o objetivo deste Post é mostrar um exemplo de uma conexão IPv6 de uma residência, através de um simples Roteador domestico, ao mundo IPv6.

1o. Passo

A primeira coisa que deve ser feito é verificar se o Roteador em sua residência suporta conexão IPv6, se o mesmo suporta, acesse o Site do Service Provider (http://tunnelbroker.net/) e faça o cadastro através do botão "Register".

Screen Shot 2013-03-01 at 22.15.07.png

Após todas as informações preenchidas, voce terá acesso a página principal, e então basta clicar na opção "Create Regular Tunnel".

Na próxima tela voce precisará fornecer duas informações:

A) Seu IP Público

B) Região no qual será conectado o seu Tunnel

Acho que para o Brasil, a melhor região seria Miami. Após escolher a região, basta clicar em "Create Tunnel", e então o Service Provider fará uma verificação no endereço IPv4 Público fornecido, e então na próxima tela voce receberá todas as informações dos endereços IPv6 que será utilizado para configuração do seu roteador.

Segue uma descrição sobre cada informação fornecida:

IPv6 Tunnel Endpoints:

Server IPv4 Address: Endereço IPv4 do SP que deve ser configurado como Tunnel Destination

Server IPv6 Address: Endereço IPv6 do SP

Client IPv4 Address: Este é o seu Endereço Público IPv4 utilizado como Tunnel Source

Client IPv6 Address: Este é o Endereço IPv6 fornecido pelo SP para ser configurado no seu Roteador na interface Tunnel

Routed IPv6 Prefixes:

Routed /64: Este range de Endereços IPv6 deverá ser utilizado na sua rede LAN. Caso seja necessário um novo Bloco, o SP pode fornecer um novo bloco /48, para isso, basta clica na opção "Assign /48".

Note que nesta tela, existe uma aba chamada "Example Configuration" que fornece um exemplo de configuração para vários tipos de Sistemas Operacionais, e também para vários modelos de roteadores.

2o. Passo

Com todas as informações disponivéis, o próximo passo é configurar o seu roteador com o Tunnel IPv4 para ter acesso ao mundo IPv6, e para isso segue uma figura que serve como exemplo de um roteador muito utilzado em residencias para conexão com a Internet.

Screen Shot 2013-03-01 at 22.13.12.png

Basta preencher as informações corretas para configurar o Tunnel, lembrando que essa tela é apenas um exemplo, mas as informações necessárias são basicamente as mesmas para todos os modelos de equipamentos.

Uma observação, o endereço Local IPv4 é o seu endereço fornecido por sua operadora local, e ele muda aleatoriamente, e assim, neste exemplo, toda vez que este endereço mudar, seja através de um reset no equipamento, ou por algum motivo da operadora local, deve-se ajustar este IP no seu roteador local, e também no Service Provider IPv6.

Após tudo preenchido, o seu Tunnel já está configurado e pronto para acessar o mundo IPv6. Porém ainda falta um passo para completar toda configuração.

3o. Passo

O último passo é configurar o seu roteador local para prover endereços IPv6 na sua rede Local fazendo com que os seus computadores possam acessar o mundo IPv6 automaticamente. Para essa configuração iremos utilizar o bloco /64 IPv6 fornecido pelo Service Provider. Segue o exemplo abaixo da configuração para o mesmo modelo de roteador no 2o. Passo:

Screen Shot 2013-03-01 at 22.58.20.png

Veja que neste exemplo, foi utilizando o endereço ::1 como IP do roteador local, e o próprio roteador é um servidor DHCPv6, responsável em administrar o fornecimento de endereços IPv6 para a rede local. Apos essa configuração, todos os computadores da rede loal que suportam IPv6 receberão um IPv6 também, além do IPv4, e assim poderão navegar no mundo IPv6.

Um simples teste apos toda configuração é acessar o Site IPV6.BR, se o Globo na direita estiver girando, é porque voce acessou o site via IPv6. Ou outro teste é acessar o site de Teste IPv6. Este site fará uma verificação dos endereços que foram utilizados para acessar o site. Segue abaixo uma tela de um teste bem sucedido.

Screen Shot 2013-03-01 at 23.06.30.png

Importante ressaltar que voce continua utilizando normalmente o endereço IPv4 para acesso a Internet, ou seja, se o site que voce quer acessar não tem suporte a IPv6, ele será acessado via IPv4 normalmente sem nenhum tipo de configuração adicional.

Pronto, agora voce já está no mundo IPv6.

Cassio Gomes


21665 visualizações
0 Comentários

Introdução:

VLAN significa Rede Local Virtual (Virtual Local Area Network). Em um Switch Cisco você pode criar várias VLANs que conectam a diferentes redes. Este documento fornece informações básicas sobre como criar VLANs em Switches Cisco Catalyst que excutam Cisco IOS Software.

Descrição:

VLANs são identificadas por números. Os dois intervalos válidos de VLANs são os seguintes:

  • 1)     O intervalo de VLANs padrão que são as VLANs cujos números vão de 1 até 1000
  • 2)     O intervalo de VLANs estendidas que são as VLANs cujos números vão de 1025 até 4096.

Por padrão todos os Switches Cisco já vem de fabrica com a VLAN 1 criada e todas as portas L2 do Switch estão configuradas nesta VLAN 1. O processo de criação de VLAN em todos os Switches Catalyst são praticamente idênticos. 

Configurando VLANs no IOS:

No Cisco IOS VLANs podem ser configuradas de duas formas:

  • 1)     Modo config-vlan
  • 2)     Modo vlan database (Hoje em dia a maiora dos Switches não suportam mais esse modo de configuração)

Configurando VLAN usando o modo config-vlan:

Etapas de configuração:

  • 1)     Digte o  comando "configure terminal" para entrar no modpo de configuração global.
  • 2)     Criar a VLAN usando o comando "vlan <number>", caso deseje é possível atribuir um nome para a VLAN inserindo o comando “name <nome-vlan>” dentro do comando "vlan <number>".

Neste ponto já temos a VLAN criada. A seguir serão exibidos as etapas de configuração para configurar uma porta em uma determinada VLAN:

  • 3)     Digite o comando "interface [type] mod/port>" para entrar no modo de configuração de interface.
  • 4)     Digite o comando "switchport mode access" para configurar a interface como modo de acesso.
  • 5)     Digite o comando "switchport access <vlan-id>" para configurar a interface para acessar a vlan determinada.
  • 6)     Digite o camando "show vlan" para verificar a configuração das VLANs.

Exemplo de configuração:

SW1(config)#vlan 11
SW1(config-vlan)#name teste
SW1(config-vlan)#exit
SW1(config)#int fa1/0
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 11
SW1(config-if)#end

Configurando VLAN usando o modo VLAN database:

Etapas de configuração:

  • 1)     Digite o comando "vlan database"  no modo privilegiado para entrar no modo de configuração VLAN database.
  • 2)     Digite o comando "vlan vlan-id> name vlan-name" no prompt vlan database para criar uma VLAN, atribuir um número e um nome. Se o nome não é configurado para a VLAN, o padrão é adicionar ao VLAN ID a palavra VLAN.
  • 3)     Para atualizar a VLAN database, propagá-lo por todo o domínio administrativo entre com o comando “Apply” e em seguida digite “exit”  para retornar ao modo privilegiado.

Neste ponto já temos a VLAN criada. A seguir serão exibidos as etapas de configuração para configurar uma porta em uma determinada VLAN:

  • 1)     Digite o comando "interface [type] mod/port>" para entrar no modo de configuração de interface.
  • 2)     Digite o comando "switchport mode access" para configurar a interface como modo de acesso.
  • 3)     Digite o comando "switchport access <vlan-id>" para configurar a interface para acessar a vlan determinada.
  • 4)     Digite o camando "show vlan" para verificar a configuração das VLANs.

Exemplo de configuração:

SW1#vlan database

% Warning: It is recommended to configure VLAN from config mode,  as VLAN database mode is being deprecated. Please consult user documentation for configuring VTP/VLAN in config mode.

SW1(vlan)#vlan 2 name teste

VLAN 2 added:
     Name: teste
SW1(vlan)#apply
APPLY completed.
SW1(vlan)#exit
APPLY completed.
Exiting....

SW1#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

SW1(config)#int fa1/0
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 2
SW1(config-if)#end

4128 visualizações
0 Comentários

Introdução


Neste documento veremos algumas como configurar IP SLA com HSRP.

Pré-requisitos

Requerimentos

Não existem requerimentos específicos para este documento.

Convenções

Consulte o Cisco Technical Tips Conventions para mais informações sobre as convenções (em Inglês).

IP SLA

A função do Cisco IP SLA (Service Level Agreement) é reunir informações detalhadas de algum tipo de tráfico especifico de dentro da rede. Basicamente, um equipamento que tem IP SLA configurado captura um teste previamente configurado até um equipamento em algum ponto remoto da rede. Deste modo, ao receber a resposta do teste enviado ao equipamento remoto, o IP SLA reúne informações sobre o estado do caminho pelo qual os pacotes passaram.

IP SLA pode realizar diferentes conjuntos de testes, os quais estão detalhados abaixo:

Teste

Descrição

Requer configurar IP SLA no destino?

icmp-echo

Tempo   de resposta do ICMP Echo

N

path-echo

Saltos   e tempo de respostas fim a fim dentro do caminho utilizado pelo ICMP Echo

N

path-jitter

Jitter fim   a fim no caminho do ICMP Echo

S

dns

Tempo   de resposta de uma consulta DNS

N

dhcp

Tempo   de resposta do DHCP

N

ftp

Tempo   de resposta ao solicitar um arquivo por FTP

N

http

Tempo   de resposta de uma página web

N

udp-echo

Tempo   total de um UDP echo

N

udp-jitter

Atraso   de ida e volta, atraso de ida, jitter de ida, perda de pacotes de ida e   conectividade usando pacotes UDP

S

tcp-connect

Tempo   de resposta para fazer uma conexão TCP a um host

N

Tabela 1

Como podem imaginar essa é uma ferramenta muito útil quando se requer monitorar um enlace com um proposito especifico, um bom exemplo é o de monitorar enlaces para saber quando é conveniente fazer trocas de roteadores ativos em protocolos FHRP, neste caso HSRP.

Primeiro para configurar IP SLA se devem seguir os seguintes passos:

  • 1.     Habilitar IP SLA no Switch de resposta. Switch(config)#ip sla responder

          (Nota: Isto só se faz para medições de Jitter ou para medições mais precisas)

  • 2.     Iniciar uma operação de IP SLA no Switch que se quer monitorar. Switch(config)#ip sla operation number

  • 3.     Escolher o tipo de teste dentre as opções que existe na Tabela 1 deste documento.

          Exemplo - Switch(config-ip-sla)#icmp-echo destination-ip-addr [source-ip-addr]

  • 4.     Configurar a execução de testes. Switch(config)#ip sla schedule operation-number

          (Nota: Com esta opção se pode iniciar o teste neste momento, faze-la recorrente ou torna-lo um tempo de inicio e tempo de vida)

Já que se tem um teste em execução de IP SLA. Ele deve ser atribuído a um objeto que pode ser monitorado por outros protocolos, neste caso pelo protocolo HSRP. Para conseguir isso utiliza-se o comando:

Switch(config)#track object-number ip sla operation-number {state | reachability}

Uma vez que se têm os objetos, podem ser adicionados ao protocolo HSRP dentro da interface na que se encontra configurado com o seguinte comando:

Switch(conf-if)#standby group track object-number decrement decrement-value

Deve-se utilizar o mesmo número de grupo de standby que se quer monitorar, e o decremento é o número que será subtraído da prioridade do roteador quando a falha é detectada durante o teste de IP SLA.

O seguinte é um exemplo de como usar a configuração de IP SLA para monitorar um enlace em um grupo HSRP:

Switch(config)#ip sla 10
Switch(config-ip-sla)#icmp-echo 192.168.70.1
Switch(config-ip-sla)#frequency 5

Switch(config-ip-sla)#exit
Switch(config)#ip sla schedule 10 life forever start-time now

Switch(config)#track 1 ip sla 10 reachability

Switch(config)#interface vlan 10
Switch(config)#ip address 192.168.1.3 255.255.255.0
Switch(config)#standby 1 priority 200
Switch(config)#stabdby 1 track 1 decrement 50
Switch(config)#no shutdown

Neste exemplo esta sendo monitorado um ICMP echo ate o host 192.168.70.1, o roteador foi configurado no grupo 1 do HSRP com prioridade 200, neste caso se o ICMP echo falhar a prioridade será reduzida em 50 e se existir outro roteador com uma prioridade maior que 150 e o comando “standby <group> preempt” estiver habilitado, então este roteador se tornará ativo. Isso é muito útil já que de outro modo o HSRP só pode monitorar enlaces diretamente conectados ao roteador.

535 visualizações
0 Comentários

MAC FLOOD!

O que é?

É uma técnica utilizada para comprometer, para invadir uma rede através do Switch.

Funcionamento básico do switch.

Para entendermos o que ele faz, precisamos entender o funcionamento básico de um switch. O switch opera em camada 2 (enlace), e cada porta dele corresponde a um domínio de colisão diferente.

O switch possui uma tabela MAC, onde se encontram os endereços de hardware relativos a cada porta. Quando o frame chega ele olha o Mac de origem e verifica se o mesmo se encontra na tabela e se não estiver ele o coloca lá especificando a porta, depois verifica o Mac de destino, checa a tabela e encaminha para a porta específica.

Funcionamento do ataque Mac flood

O “invasor” envia vários pacotes contendo Mac’s de origem diferentes para o switch fazendo com que o switch guarde todos esses endereços de hardware. Cada switch possui uma memória limitada para a tabela Mac, quando essa memória se esgota ele passa a encaminhar os pacotes para todas as portas, ou seja, começa a agir como um hub.

1714 visualizações
0 Comentários

Receita de Bolo: DHCP Snooping

A seguir, um rápido tutorial para configurar a funcionalidade DHCP snooping.

**Para realizar tal configuração, foi utilizado um switch Catalyst 2970, utilizando a imagem 12.2(20) SE**

Passo 1: Entre no modo de configuração global.

configure terminal

Passo 2: Habilite o DHCP Snooping globalmente.

ip dhcp snooping

Passo 3: Habilite o DHCP snooping em uma VLAN especifica ou em um range (grupo) de VLANs. Este range pode ser um grupo de números entre 1 e 4094.

Podemos inserir VLANs individuais ou um range de VLANs.

ip dhcp snooping vlan vlan-range

Passo 4: Esse passo nos mostra como habilitar o switch para inserir ou remover a informação de DHCP relay (Campo de opção 82) nas mensagens de DHCP request que são encaminhadas ao servidor DHCP.

Por padrão, essa opção já vem habilitada.

ip dhcp snooping information option

Passo 5: Entre no modo de configuração da interface.

interface interface-id

Passo 6: (Opcional) Configurar a interface como confiável (trust) ou não-confiável (untrust). Você pode usar o comando no para configurar uma interface para que receber mensagens de um cliente não-confiável (untrusted). O padrão é não-confiável.

ip dhcp snooping trust

Passo 7: (Opcional) Configura o número de pacotes DHCP por segundo que uma interface pode receber. O intervalo é de 1 até 4294967294. Por padrão nenhum limite é configurado.

Nota Nós recomendamos que se for configurado algum limite para tais pacotes, que este limite não seja superior à 100 pacotes por segundo. Caso você configure esse limite em alguma interface confiavel (trusted), você precisa aumentar esse limite caso tal porta seja um tronco com várias VLANs configuradas com o DHCP snooping.

ip dhcp snooping limit rate rate

Passo 8: (Opcional). Configura o switch para verificar a origem do endereço MAC no pacote DHCP que é recebido nas interfaces não-confiáveis para ver se tal endereço é realmente confiável (verificar se o endereço MAC é realmente do cliente).O padrão ele já vem habilitado em interfaces não-confiáveis.

ip dhcp snooping verify mac-address

Passo 9: Voltando pro modo privilegiado (privileged EXEC mode)

End

Passo 10: Verificando a configuração.

show running-config

Passo 11: (Opcional) Salve as configurações feitas.

copy running-config startup-config

CriarFaça o para criar o conteúdo
Autores com maior número de kudos
Utilizador Contagem de kudos
5