Você está na página 1de 18

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óximo salto, todos os pacote
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 e a tabela CEF é modificado d
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