cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
cancel
Comunicados
Bem-vindo à Comunidade de Suporte da Cisco, gostaríamos de ter seus comentários.
A partir deste verão: as comunidades da Cisco e a Comunidade de Suporte da Cisco estão se fundindo. Saiba mais.

Routing & Switching Blogues

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

Olá a todos.

 

Estou com uma duvida. Fechei uma VPN com um cliente, porem ele insiste que eu deva configurar meu grupo local de ip como 192.168.229.224 e 255.255.255.224 sendo que minha rede interna é 10.91.254.0/24.

 

No firewall antigo que é um IPtables, funciona dessa forma foi apenas criadas umas regras de direcionamento.

 

Como faço isso no cisco?

 

OBRIGADO

 

 

1715 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

327 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

20 visualizações
0 Comentários

isto é um teste

163 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...

43 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...

77 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...

46 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...

225 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...

23 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...

43 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...

179 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...

49 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...

21 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

49 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

CriarFaça o para criar o conteúdo