GUIA DE DESIGN | FASES DMVPN

03 FEB2015 EmBlog

Adicionar Comentário   

DMVPN
 

MultiPoint dinâmica Virtual Private Network (DMVPN) é uma forma dinâmica de

rede privada virtual (VPN) que permite que uma malha de VPNs sem a
necessidade de pré-configurar todas as extremidades do túnel, ou seja,
raios. Túneis raios estabelecer sob demanda com base em padrões de tráfego
sem configuração repetido em hubs ou raios.
Na sua forma mais simples, DMVPN é uma sobreposição de ponto-a-
multiponto Layer 3 VPN permitindo hub lógico e falou topologia suportar
comunicações diretas raios-para-raio, dependendo projeto DMVPN (Fase 1,
Fase 2 e Fase 3) seleção. VPN fase de selecção afecta grandemente
configuração do protocolo de roteamento e como ele funciona através da
topologia lógica. De um ponto de roteamento de vista, paralelos entre
roteamento frame-relay e configurações do protocolo de roteamento DMVPN
são evidentes.
 

DMVPN permite a criação de GRE malha completa ou túneis IPsec com

um modelo simples de configuração. De um ponto de vista de
provisionamento, DMPVN é simples.
 

DMVPN é uma combinação de tecnologias de 4:

mGRE : Em conceito, túneis GRE se comportar como ponto-a-ponto links
seriais. mGRE comportar como LAN então você tem muitos vizinhos
alcançáveis através da mesma interface. O "M" em mGRE significa multiponto .
Dinâmica Next Hop Resolution Protocol (PNDH) com Next Hop Server
(NHS  ): ambientes de rede local utilizam Address Resolution Protocol (ARP)
para determinar o endereço MAC do seu vizinho (inverso ARP para frame
relay).mGRE o papel da ARP passa a ter NHRP. NHRP une o endereço IP
lógico no túnel com o endereço IP físico utilizado no link de saída (fonte túnel).
Processo de resolução determina se você quiser formar destino túnel para X, o
endereço faz túnel X determinação no sentido. DMVPN liga IP-a-IP oposição a
ARP, que se ligam destino IP para endereço MAC de destino.
IPsec protecção túnel : DMVPN é uma técnica de roteamento não
directamente relacionadas com criptografia. IPsec é opcional e usado
principalmente em redes públicas. Existem projetos potenciais para DMVPN
em redes públicas com GETVPN que permite agrupamento de túneis para
Associação de segurança único (SA).
Encaminhamento:  Designers estão implementando DMVPN sem IPsec para
redes baseadas em MPLS para melhorar a convergência como DMVPN age
independente da política de roteamento provedor de serviços. Os sites só
precisa de conectividade IP entre si para formar uma rede DMVPN. Você só
precisa fazer o ping os pontos finais de túneis e IP rota entre os sites. -Se aos
clientes finais para decidir a política de roteamento não o prestador de
serviços; oferecendo mais flexibilidade do que sites conectados pelo
MPLS. MPLS sites conectados ao provedor de serviços determina políticas de
protocolo de roteamento.
 

Mensagens DMVPN
 
IP mapa para IP : significa que se você quiser alcançar o meu endereço
privado você precisa GRE encapsular-lo e enviar para o meu endereço
público. Falou processo de registro.
 

TRÊS MODELOS DE DESIGN CHAMADOS FASES

influência DMVPN fase-selecionados falou-to-spoke padrões de tráfego,
apoiado projetos de roteamento e escalabilidade.
Fase 1 : Todos os fluxos de tráfego através do cubo. O hub é usado para o
plano da rede de controle e também está no caminho de plano de dados.
Fase 2 : Permite raios-to-falou túneis. Comunicação falou-to-spoke não precisa
do hub no plano de dados reais. Túneis falou-para-raio estão em demanda com
base no tráfego raios provocando o túnel. Existem limitações de design
protocolo de roteamento. O cubo é utilizado para o plano de controlo, mas ao
contrário de uma fase não necessariamente no plano de dados.
Fase 3 : melhora a escalabilidade da Fase 2. Podemos usar qualquer protocolo
de roteamento com qualquer configuração. "NHRP
reorientar" e "atalhos" cuidar dos fluxos de tráfego.
 

FASE 1 DMVPN
 

Fase 1 DMVPN
 
Fase 1 consiste em mGRE em túneis hub e ponto-a-ponto GRE sobre raios.
Hub pode chegar a qualquer falou sobre a interface do túnel, mas raios só pode
passar pelo hub. Sem Spoke-to-Spoke direta . Falou só precisa chegar ao hub
assim uma rota de host para o hub é necessária. Perfeito para o projeto rota
padrão do cubo. Projeto contra qualquer protocolo de roteamento, contanto que
você definir o próximo-hop para o dispositivo hub.
Multicast (roteamento plano de controle de protocolo) trocadas entre hub e
falou e não falou-se dos raios.
No raio, para ajudar com ambientes onde Path MTU é rompido, insira ajustar
MMS. Deve ser de 40 bytes menor do que a MTU - ip mtu 1400 & tcp ip ajustar-
MSS 1360 . Ele insere a opção de tamanho de segmento máximo em pacotes
TCP SYN por isso mesmo que Path MTU não funcionar, pelo menos sessões
TCP não são afetados.
 
CHAVES TÚNEL
chave túnel são opcionais para cubos com interface do túnel único. Eles podem
ser usados para túneis paralelos geralmente em conjunto com desenhos FRV-
luz. Dois túneis entre hub and spoke, o cubo não pode determinar com base no
destino ou origem do endereço IP, que túnel que pertence também. chaves de
túneis são usados identificar túneis e ajuda com mapeamento de entrada
pacotes GRE para múltiplas interfaces de túnel.
 

GRE Chaves túnel

 

Chaves túnel em 6500 e 7600 - hardware é incapaz de usar as teclas do

túnel. Ele não pode olhar tão profundo no pacote. Todo o tráfego de entrada é
comutada por CPU por isso o desempenho vai para baixo por um fator de 100.
Para superar isso, você deve usar uma fonte diferente para cada túnel paralelo.
Se você tem uma configuração estática e a rede é estável, você poderia usar
um "hold-time" e "tempo limite de inscrição"com base em horas, não de 60
segundos padrão.
Em Ethernet carrier e da rede de cabo, o IP spoke é atribuído pelo DHCP e
pode mudar regularmente. Além disso, em xDLS ambientes onde sessão
PPPoE podem ser apagadas e raios obter um novo endereço IP. NHRP
Registro não-exclusivo trabalho de forma eficiente aqui.
 

PROTOCOLO DE ROTEAMENTO
Encaminhamento para a Fase 1 é simples. Sumarização e roteamento padrão
no hub é permitido. Next-hop em raios é sempre alterada pelo hub; hub é
sempre o próximo salto .
Falou necessidade de comunicar primeiro com hub, não faz sentido para
enviar-lhes todas as informações de roteamento.Basta enviar-lhes uma rota
padrão.
Cuidado com roteamento recursivo - às vezes o raio pode anunciar seu
endereço físico ao longo do túnel para o centro tenta enviar DMVPN pacote
para o raio através do túnel; resultando em abas túnel.
 

DMVPN FASE 1 OSPF ROUTING

projeto recomendado deve usar protocolo de roteamento diferente sobre
DMVPN mas você pode estender domínio OSPF, adicionando a rede DMVPN
em uma área OSPF separado. Possível ter uma área grande, mas com um
grande número de raios tentar minimizar os raios de informação topologia tem
que processar.
Redundante set-up com raios execução de dois túneis para redundantes Hubs
ou seja Tunnel 1 a Hub 1 e túnel 2 a Hub 2. Projeto para ter as interfaces de
túnel na mesma área não-backbone. Tê-los em áreas separadas fará com que
falou para se tornar Área Border Router (ABR). Cada OSPF ABR deve ter um
link para a Área 0. Resultando em complexo de configuração OSPF Virtual-Link
e Shortest Path adicionais desnecessários First (SPF) é executado.
Certifique-se de algoritmo SPF não consumir muito falou de recursos. Se raios
são roteadores high-end com boa CPU, então, você não se preocupam com
SPF execução em Spoke. Normalmente, eles são roteadores low-end e manter
os níveis de recursos eficientes é fundamental. Potencialmente projetar área
DMVPN como  rascunho ou área totalmente stub . Este projeto impede
alterações (exemplo: adições prefixo) sobre a não DVMPN parte para causar
totais ou parciais SPF do.
 

Low-end falou roteadores pode lidar com 50 roteadores na área OSPF

única.
 

Configurar OSPF  ponto-a-multiponto.  Obrigatórios em cubo e recomendado

no raio. Spoke têm túneis GRE, pelo uso padrão OSPF tipo de rede ponto-a-
ponto. Temporizadores precisam corresponder para OSPF adjacência para
subir.
OSPF é hierárquica do projeto e não escalável. OSPF sobre DMVPN é bom,
desde que você tem um baixo número de site de raios, ou seja, abaixo de 100.
 

ROUTING DMVPN FASE 1 EIGRP

No Hub, desativar split horizon e realizar sumarização. Implantar mapas de
vazamento EIGRP para locais remotos redundantes. Dois roteadores que ligam
o DMVPN e com mapas de vazamento, especificar qual a informação (rotas)
podem vazar a cada redundante falou.
Implantar raios como  rascunho roteadores . Sem roteamento stub sempre
que ocorrer alteração (prefixo perdido), o hub irá consultar todos os raios para
informações de caminho.
Importante especificar interface de largura de banda.
 

DMVPN FASE ROUTING 1 BGP

Recomendado o uso EBGP. Hub deve ter next-hop-self em todos os vizinhos
BGP. Para poupar recursos e etapas de configuração, possíveis de utilizar
modelos de política. Tente minimizar atualizações de roteamento para raios,
filtrando as atualizações BGP ou rota de publicidade padrão para dispositivos
de raios.
Em IOS recentes, temos vizinhos BGP dinâmicos . Configurar gama de hub
com o comando bgp ouvir gama 192.168.0.0/24~~number=plural raios peer-
grupo. Sessões de entrada BGP são aceitos se o endereço IP de origem está
no intervalo especificado de 192.168.0.0/24.
 

DMVPN Fase 1 Resumo

 

FASE 2 DMVPN
 
Fase 2 DMVPN
 

Fase 2 permite mGRE no hub e falou, permitindo raios-to-falou sobre túneis de

demanda. Fase 2 consiste em nenhuma alteração no router hub, basta alterar o
modo de túnel em raios de gre multiponto - túnel de modo gre
multiponto. Chaves túnel são obrigatórios quando vários túneis compartilham a
mesma interface de origem.
O tráfego multicast ainda flui entre o hub e falou apenas, mas o tráfego de
dados agora pode fluir de raios-to-raios.
 

Fase DMVPN 2 Fluxo de pacotes

-Para Fluxo de pacotes inicial, mesmo que a tabela de roteamento mostra o raio como o próxim
salto, todos os pacotes são enviados para router hub. Atalho não estabelecido.
-Os Raios enviar solicitação NHRP ao Hub e pede ao hub sobre o endereço IP dos outros raios
-Reply É recebido e armazenado no cache dinâmico NHRP no roteador spoke.
raios -Agora tentar configurar IPSEC e IKE sessão para outros raios diretamente.
-Uma Vez IKE e IPSEC se tornar operacional, a entrada NHRP também está operacional
a tabela CEF é modificado de modo raios pode enviar tráfego direto a raios.
 

O processo é unidireccional. tráfego inverso de outro raio desencadeia o

mesmo mecanismo. Spokes não estabelecem duas sessões IPsec
unidirecionais; Apenas um.
Mais protocolo de roteamento de restrição com a Fase 2 do que com a Fase 1
e Fase 3. Por exemplo, sumarização e roteamento padrão não é permitido em
cubo e do próximo salto em raios sempre é preservada pelo hub. Spokes
precisa rotas específicas a cada outras redes.
 

DMVPN FASE 2 OSPF ROUTING

Recomenda-se usar OSPF tipo de rede Broadcast. Certifique-se de hub é
DR. Você vai ter um desastre se um raio torna-se Designated Router (DR). Por
esse motivo definir o raio OSPF prioridade a "zero".
OSPF pacotes multicast são entregues apenas hub. Devido à configurados
NHRP mapas multicast estáticos ou dinâmicos, relacionamentos vizinho OSPF
formam apenas entre o hub e falou.
Falou roteador precisa todas as rotas de todos os outros raios de modo
roteamento padrão é impossível para o hub.
 
ROUTING DMVPN FASE 2 EIGRP
Nenhuma alteração para falar. No hub só adicionar no ip do próximo salto
self. Desativar EIRP split-horizon em roteadores hub para propagar
atualizações entre raios.
Não use resumo, se você configurar o resumo em raios, as rotas não vai
chegar a outros raios. Resultando em tráfego de raios-to-spoke indo para o
centro.
 
DMVPN FASE ROUTING 2 BGP
Retirar a próxima-hop-self em roteadores centrais.
 

ROUTING PADRÃO DE DIVISÃO

roteamento padrão de divisão pode ser usado se você tem a exigência de
roteamento padrão para hub: talvez para o projeto central de firewall e você
quer todo o tráfego para ir para lá antes de prosseguir para a Internet. O
problema com a Fase 2 permite raios-to-falou o tráfego por isso mesmo que
nós rota padrão apontando para hub que realmente precisa o ponto de rota
padrão para a Internet.
Exigir duas perspectivas de roteamento; uma perspectiva para GRE e pacotes
IPsec e uma outra perspectiva de dados que atravessam a WAN
corporativa. Possível configurar política baseada Routing (PBR), mas apenas
como uma medida temporária. PBR pode executar em erros e é difícil de
solucionar. Dividir roteamento com VRF é muito mais limpo .Tabelas de
roteamento para diferentes VRF pode conter rotas padrão. Roteamento em um
VRF não afetará roteamento em outro VRF.
 
Routing padrão de divisão
 

SITE REMOTO MULTI-HOMED

Para torná-lo complexidade do sistema do raio precisa de dois 0.0.0 / 0. um
para cada rede DMVPN Hub. Agora, temos duas rotas padrão na mesma VRF
INTERNET. Precisamos de um mecanismo para nos dizer, qual usar, para o
qual DMVPN nuvem.
 

Sites redundantes
 
Mesmo se a fonte do túnel é para mGRE-B ISP-B, a tabela de
encaminhamento pode enviar o tráfego para ISP-A. ISP-A pode realizar uRFC
para evitar falsificação de endereço. Resultando em quedas de pacotes.
O problema é a seleção do link de saída (ISP-A) depende Cisco Express
Forwarding (CEF) hashing, que você não pode influenciar. Então, nós temos
um problema e o pacote de saída tem que usar o link de saída correta com
base no endereço IP de origem e não destino. A solução é Tunnel Route-via -
Política de roteamento para o GRE. Para chegar a este trabalho com o IPsec
instalar dois VRFs, um para cada ISP.
 

FASE 3 DMVPN
 

Fase 3 DMVPN
 

Fase 3 consiste de mGRE nos túneis de cubo e mGRE sobre o raio. Permite

raios-to-falou sobre túneis de demanda. A diferença aqui é que, quando o hub
recebe pedido NHRP, o hub pode enviar um redirecionamento para falou
remoto, a fim de dizer-lhes para atualizar sua tabela de roteamento.
Permite raios-to-falou comunicação mesmo com roteamento padrão. Assim,
mesmo que a tabela de roteamento aponta para o centro, o tráfego flui entre
raios. Não há limites para o roteamento, nós ainda obter o fluxo de tráfego
raios-to-spoke mesmo quando você usa rotas padrão
"Orientada para o tráfego-redirect";  hub percebe o raio está a enviar dados
para ele, ele envia um redirecionamento de volta para falou, dizendo uso deste
outro raio. Redirect informa o remetente um caminho melhor . O raio irá instalar
este atalho e iniciar IPsec com outros Spoke. Use ip PNDH redirecionar em
roteadores hub & ip atalhos NHRP em roteadores spoke.
Não há restrições sobre protocolo de roteamento ou quais as rotas que são
recebidos por raios. Sumarização e roteamento padrão é permitido. Próximo
salto é sempre o hub.
PROJETOS DMVPN REDUNDANTES, PARTE 1 (THE
BASICS)
Por Ivan Pepelnjak Clique aqui para subscrever a minha lista SDN
Terça-feira, janeiro 17, 2012

A maioria das questões relacionadas com a DMVPN que recebo são uma

variante do " quantos túneis / hubs / interfaces / áreas que eu preciso para um

projeto redundante DMVPN? "Como sempre, a resposta certa é" depende "(e

eu sempre pode ajudá-lo com o seu design se você gostaria de obter uma

segunda opinião), mas aqui está o que eu aprendi até agora.

Único roteador / uplink única no local spoke

Este post centra-se na mais simples projeto possível - cada um falou site tem

um único roteador e um único uplink. Não há nenhuma redundância nos raios,

o que pode ser uma troca aceitável (ou você pode usar a conexão 3G como um

backup para DMVPN).

Você provavelmente gostaria de ter dois roteadores hub (de preferência com

uplinks independente), o que nos leva à pergunta fundamental: " precisamos

de uma ou duas nuvens DMVPN? "

Projeto # 1 - um hub por túnel DMVPN

Neste projeto, cada roteador hub controla a sua própria sub-rede DMVPN, e

falou routers têm múltiplas interfaces de túnel (um por hub). Cada roteador hub

é o servidor NHRP para a sub-rede que controla, e propaga informações de

roteamento entre raios.

Este projeto é de longe o mais simples, mais limpa e mais fácil de entender /

solução de problemas - que não tem dependências complexas entre protocolos

de roteamento e NHRP.Você também pode facilmente implantar primário /

backup de cenários de roteador hub , aumentando o custo de interface de uma

interface de túnel, ou você pode carregar-share o tráfego entre os dois

roteadores hub.

E agora, para os inconvenientes:

 Foi possível estabelecer sessões IPsec múltiplas entre um par de

roteadores falou emDMVPN Fase 2 implementações (uma sobre cada interface

do túnel);

 chaves GRE são obrigatórios na Fase 2 implementações (caso

contrário, os raios não pode decifrar qual túnel do outro roteador spoke estava

usando), causando a degradação do desempenho se os routers hub não

suportam chaves GRE em hardware (Catalyst 6500 não faz)

 Este projeto não funciona com grande escala Fase 3 DMVPNs onde

você deseja que cada raio se conectar a um subconjunto de hubs (você não

pode estabelecer Fase 2/3 atalhos através de túneis DMVPN, somente dentro

de um túnel).

Projeto # 2 - vários centros de conexões em um único túnel DMVPN

Neste projeto, você conecta todos os roteadores de Hub para o mesmo túnel

DMVPN. Todos os roteadores hub agir como servidores NHRP, e propagar

informações de roteamento entre os raios (se você usar OSPF, um dos

roteadores de hub se tornaria um DR, outro um BDR ).

Fase 1 DMVPN usando vários roteadores hub por túnel é muito fácil de projetar

/ implantar - NHRP é utilizado apenas para registrar raios com todos os hubs, e

a convergência é controlada pelos protocolos de roteamento. Implementar

roteadores hub primárias / backup é uma tarefa complicada; você tem que usar

truques protocolo de roteamento como o custo por vizinhoOSPF ou por

interface compensado listas com EIGRP.

Fase 2/3 DMVPN projetos com vários roteadores hub por túnel poderia

enfrentar problemas de convergência graves - a detecção de falha de um

roteador hub poderia demorar até três minutos . No benefícios lado, este

projeto não requer chaves GRE (que é uma boa notícia se seu roteador hub é

um Catalyst 6500) ou várias sessões IPsec entre roteadores spoke.

 Resumo

 Um roteador hub per DMVPN sub-rede é o projeto ideal para a Fase 2

implantações DMVPN ... a menos que você tem Catalyst 6500 como o seu

router hub, caso em que você deve usar uma sub-rede DMVPN devido à falta

de apoio fundamental GRE hardware.

 Você pode usar ambos os projetos com a Fase 1 DMVPN; um roteador

hub por sub-rede é uma alternativa melhor se você tiver primário / backup de

requisitos roteador hub.

 Um DMVPN sub-rede é, provavelmente, o melhor projeto para a Fase 3

DMVPN e é obrigatório se você tem conectividade NHRP raios-to-hub parcial.

Eu preciso correr mais alguns testes de convergência antes de abraçar

plenamente uma sub-rede DMVPN design como o melhor em todos os
cenários DMVPN Fase 3.

Vem em seguida: falou roteadores com vários uplinks e falou sites com

roteadores redundantes.

Preciso de ajuda?

Comece com o DMVPN - do básico para redes

escaláveis webinar; provavelmente contém 95% do que você precisa saber

sobre DMVPN (a DMVPN New Features um descreve DMVPN recursos

introduzidos no IOS libera 15.x).

 Se você precisar de uma segunda opinião ou ajudar com seu projeto DMVPN,

confira o serviço ExpertExpress . Você também pode envolver a nossa equipe

de serviços profissionais paraprojetos maiores de design / implantação

Tags: DMVPN , OSPF , OficinaEmailBlogThis!Compartilhar no
TwitterCompartilhar no Facebook

POSTS RELACIONADOS POR CATEGORIAS

DMVPN
 Devo usar L2VPN + MACsec ou L3VPN + GETVPN?
 Inter-VRF NAT em DMVPN implantações
 DMVPN Dividir Default Routing
 Reduzir BGP SNMP Traps em DMVPN Networks
 Viptela SEN: Conectividade WAN híbrido com uma torção SDN
 É alguém usando DMVPN-over-IPv6?
 Mudanças na IBGP Next Hop Processamento melhorar drasticamente
Designs DMVPN baseadas em BGP
 Real Life BGP Route Originação e BGP próximo hop Intricacies
 Dimensionamento Networks DMVPN BGP-Based
 A diferença fundamental entre a Fase 2 e Fase 3 DMVPN

OSPF
 Por que usar BGP e OSPF não entre servidores e da rede?
 Áreas OSPF e resumo: a teoria ea realidade
 Ainda precisamos de áreas OSPF e sumarização?
 Não executar OSPF com seus clientes
 BGP ou OSPF? Faz Topologia Visibilidade importa?
 Interfaces não numeradas OSPF em Quagga (e Cumulus)
 Combinando DMVPN com Existente MPLS / VPN Rede
 Protocolos de roteamento no NSX Edge Services Router
 Protocolos de execução do plano de controlo com OpenFlow
 Inter-Process OSPF Regras de Seleção de Rota

9 COMENTÁRIOS:

1.

KAV17 de janeiro de 2012 07:55

solução mais simples: 

tem vários hubs dmvpn e raios e ISP múltiplos em cada lado 

para se conectar-lo juntos, precisamos VRF dedicado para cada ISP
(fora VRFs) e VRF dedicado para cada túnel interface (dentro VRFs). em
seguida, configurar cada túnel interface como de costume e
redistribuição de rotas entre VRFs dentro via BGP. 
 com este esquema, temos todos os possíveis conectividade entre
qualquer número de eixos e raios com qualquer número de conexões de
ISP cada. 

PS: Desculpem a má Inglês.

Resposta

2.

KAV17 de janeiro de 2012 08:02

Além de meu post cedo - pode fornecer exemplos de configuração 

, também, esse esquema funcionando bem com o Linux (mas no túnel
estática final de poing de configuração com o anfitrião linux não
encontrou o tempo e desejo de configurar corretamente NHRP daemon
no lado linux.

Resposta

3.

Shamal Weerakoon13 de novembro de 2012 04:52

Oi Ivan, 

eu tenho tentado encontrar uma solução para este cenário para últimos
três meses. 

Eu tenho 3 routers cada um tem interfaces de ADSL e 3G. um deles

será um hub e os outros dois serão raios. Qual é a melhor maneira de
ter redundância para esta topologia ?. Estou pensando em configuração
2 DMVPN nuvens, um no DSL e outro no 3G. Eu sei que, se eu mudar
as métricas de interfaces de túnel eu posso fazer os routers a preferir
DSL com EIGRP. 

Todos os IPs DSL são estáticos Pública ea interface 3G no Hub também

é stati. Mas IPs 3G 'raios são dinâmicas. 

Então, meu dilema é, 

Se eu implementar o DMVPN secundário como mencionado acima,

Como eu vou para configurar rotas padrão no HUB ?. (I pode ter uma
rota específica sobre os raios, apontando 3G IP do HUB, para fora
através de sua interface 3G, porque eu já sei endereço 3G IP do HUB
(estático).) Mas, no Hub, eu já tenho uma rota padrão através da
interface DSL . Porque os raios 3G IPs são dinâmicos, não pode
especificar uma rota no Hub para que o Hub pode responder ao tráfego
de iniciação ISAKMP recebeu de Spokes 3G-IP de volta via interface
Hubs 3G. Assim, mesmo que hub recebe o tráfego de iniciação raios
(para DMVPN secundário) a partir de sua interface 3G, que vai
responder a usá-lo é DSL de interface (é?). Então eu acho que isso
pode causar muitos problemas .. 

Você pode me colocar na direção certa .. Pode ser que há uma maneira
melhor. Esta tem sido uma dor na parte de trás por muito tempo agora. 

Agradeço antecipadamente.

Resposta

respostas

1.

Ivan Pepelnjak13 de novembro de 2012 07:34

Use diferentes VRFs para (Internet, 3G) de redes de transporte
diferente, então você pode ter uma rota padrão em cada VRF. 

Este projeto é descrito em meus webinars DMVPN (e você fazer o

teste configurações do roteador de aplicação), e também aqui:
http://blog.ioshints.info/2012/01/redundant-dmvpn-designs-part-2-
multiple.html

2.

Shamal Weerakoon13 de novembro de 2012 08:09

Oi Ivan, 

Obrigado pela sua resposta. 

Acabei de comprar todos os 3 webinars DMVPN (oferta

especial :)). Material impressionante. Vou passar por aqueles e
voltar para você se eu ainda tiver problemas. 

obrigado

3.

Shamal Weerakoon14 de novembro de 2012 00:26

Eu fui através de seu material. Muito informativo e local. Apenas

uma coisa que eu quero esclarecer sobre o cenário acima, meus
raios precisam de acesso à Internet local (sobrecarga de NAT
normal). Em seus vídeos você recomendaria para usar diferentes
 VRFs para uplinks ISP e não usar PBR. 

Então, minha pergunta é, posso usar VRFs e ainda permitir que

os usuários internos para acessar internet sem passar pelo hub? 
Qual seria a minha melhor opção aqui .. ?? 
Muito obrigado por ter tempo para isso. :)

4.

Ivan Pepelnjak14 de novembro de 2012 07:27

Use um VRF separado para cada uplink Internet, tabela de
roteamento global para sua rede interna. Rota padrão em cada
VRF aponta para o uplink correspondente.Roteamento da Internet
resolvido. 

Em seguida, adicione uma rota padrão na tabela de roteamento

global apontando para um dos uplinks de Internet (você deve
incluir interface na rota estática), e configurar inter-VRF NAT. 

Shameless plug: inter-VRF NAT é descrito em detalhes (em

conjunto com configurações do roteador) em webinar Empresa
MPLS / VPN e meus MPLS / VPN livros.

5.

Shamal Weerakoon15 de novembro de 2012 11:05

Muito obrigado Ivan. Vai fazer isso. Eu não hesitaria em comprar

a série MPLS / VPN, bem .. porque eu tenho certeza que eles são
tão bons quanto os DMVPN. Muito a aprender. Com certeza vale
o dinheiro!

Resposta

4.

Martin Friebe11 de setembro de 2016 21:51

Oi, 

eu tenho um monte de Spoke está na minha dupla projeto Hub. E eu

recebo o fenômeno que alguns deles não vai voltar a ligar ao
HUB. (DMVPN Config é tudo a mesma coisa) O comando "sh dmvpn"
me mostra "NHRP" e eles ficam stucked. Depois dis / en -able tudo
funciona bem.Alguma sugestão ?

Resposta