Cisco 300-410: MPLS, VRFs e Serviços de VPN de Camada 3 — Guia de estudos
Faz parte do Cisco CCNP Enterprise 300-410 ENARSI — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.
Visão Geral
As VPNs de Camada 3 com Multiprotocol Label Switching (MPLS) separam o roteamento do cliente em instâncias de roteamento e encaminhamento virtual (VRFs), enquanto utilizam um núcleo de provedor (provider core) compartilhado para o transporte. Roteadores de Borda do Provedor (PE) impõem e removem pilhas de rótulos (labels) para que os roteadores do Provedor (P) encaminhem pacotes baseando-se puramente nos rótulos, preservando a escalabilidade e o isolamento. O MP-BGP distribui rotas de VPN (VPNv4/VPNv6) com Route Distinguishers (RDs) para garantir a unicidade e Route Targets (RTs) para controlar a política de importação/exportação. Um projeto adequado exige uma separação clara das funções do cliente e do provedor, distribuição cuidadosa de rótulos e políticas explícitas para vazamento de rotas (route leaking) e serviços compartilhados. A operação exige estados previsíveis no plano de controle (IGP, LDP/RSVP, MP-BGP) e comportamento determinístico no plano de dados (empilhamento de rótulos, PHP), com verificação rigorosa e isolamento de falhas através das fronteiras CE–PE–núcleo (core).
Encaminhamento MPLS e Distribuição de Rótulos
Formato e pilha de rótulos (labels)
- Um cabeçalho shim do MPLS contém um rótulo de 20 bits, 3 bits para a Classe de Tráfego (TC/EXP), 1 bit para o Fundo da Pilha (S) e 8 bits para o TTL.
- Os pacotes carregam uma pilha: um rótulo externo de “transporte” para o LSP de PE para PE e um rótulo interno de “VPN” que identifica a VRF do PE de egresso (ou o serviço).
- O Penultimate Hop Popping (PHP) remove o rótulo superior no penúltimo roteador P para reduzir a carga no PE de egresso; o explicit-null pode ser usado para manter o rótulo superior a fim de preservar a semântica de QoS/TTL até o egresso.
Fundamentos do LDP
- Roteadores P e PE normalmente executam um protocolo de gateway interior (IGP) para estabelecer alcançabilidade e o Label Distribution Protocol (LDP) para mapear Classes de Equivalência de Encaminhamento (FECs) para rótulos.
- O LDP descobre vizinhos via hellos em UDP/646 e forma sessões de rótulos sobre TCP/646, fornecendo sinalização de rótulos confiável. O Targeted LDP (tLDP) pode construir sessões offlink para FECs específicas.
- Estilos de alocação/propagação de rótulos:
- Controle independente vs. ordenado: um roteador pode alocar rótulos para uma FEC assim que conhece uma rota (independente) ou somente quando recebe um rótulo de seu próximo salto (ordenado).
- Retenção de rótulos liberal vs. conservadora: manter todos os rótulos recebidos ou apenas aqueles do melhor próximo salto, trocando memória por agilidade na convergência.
- O router ID do LDP assume por padrão o maior endereço de loopback, se presente (caso contrário, a maior interface ativa). Estabilize-o (e o transporte) para evitar instabilidade nas sessões (session churn); considere a sincronização LDP-IGP para prevenir blackholing durante a convergência.
Escopo do plano de controle do roteador P
- Os roteadores P do núcleo (core) não carregam rotas de VPN; eles executam apenas o underlay (IGP) e a sinalização de rótulos (LDP ou RSVP-TE). O RSVP-TE pode ser usado em vez de, ou junto com, o LDP para fazer engenharia de tráfego.
Caminho do plano de dados
- O PE de ingresso insere (pushes) os rótulos de VPN e de transporte; os roteadores P trocam (swap) apenas o rótulo externo; o P penúltimo remove (pops) o rótulo de transporte (a menos que o explicit-null esteja em uso); o PE de egresso remove (pops) o rótulo de VPN, seleciona a VRF e encaminha o pacote através de uma consulta IP normal.
Habilitadores de configuração prática (IOS/IOS XE)
- Em interfaces voltadas para o núcleo (core): mpls ip
- Globalmente: mpls label protocol ldp
- Verificar: show mpls ldp neighbor, show mpls ldp bindings, show mpls forwarding-table
Arquitetura L3VPN: Funções, VRFs, RDs, RTs e MP-BGP
Funções e demarcações
- CE (Customer Edge): executa um protocolo voltado para o PE (estático, eBGP, OSPF, EIGRP) e mantém as rotas do cliente; não tem conhecimento do MPLS.
- PE (Provider Edge): mantém VRFs por cliente (tenant), participa do MP-BGP (VPNv4/VPNv6) e impõe/remove rótulos.
- P (Provider Core): apenas comutação de rótulos (label-switching); sem estado de VRF.
- Cliente: proprietário administrativo do CE e das políticas de roteamento do tenant.
VRFs e sobreposição de endereços
- Cada cliente (tenant) recebe uma VRF (RIB/FIB separadas). A sobreposição de espaços de endereço IPv4/IPv6 entre clientes é permitida.
- Os Route Distinguishers (RDs) tornam as rotas por VRF globalmente únicas ao prefixar “RD:” ao prefixo para formar NLRIs VPNv4/VPNv6; os RDs não são um mecanismo de segurança e não controlam políticas.
- Os Route Targets (RTs) são comunidades estendidas (extended communities) do BGP usadas para marcar rotas na exportação e selecionar quais rotas uma VRF importa. A política de RT é o controle autoritativo de importação/exportação.
Address families do MP-BGP
- VPNv4: AFI 1, SAFI 128. O MP_REACH_NLRI transporta o próximo salto e um rótulo de VPN por rota. As rotas VPNv4 são distribuídas apenas entre os nós PE (e route reflectors).
- VPNv6 (6VPE): AFI 2, SAFI 128. Habilita VPNs IPv6 sobre um núcleo MPLS IPv4. O próximo salto do BGP pode permanecer IPv4; o PE atribui rótulos de VPN por rota IPv6.
- Habilite as comunidades estendidas (extended communities) nas sessões BGP entre PEs para que os RTs sejam transportados.
Padrão de configuração simplificado (PE)
- Definir a VRF e a conexão com o CE:
- ip vrf CUST-A rd 65000:10 route-target export 65000:10 route-target import 65000:10
- interface GigabitEthernet0/0 ip vrf forwarding CUST-A ip address 10.0.0.1 255.255.255.252
- MP-BGP para VPNv4:
- router bgp 65000 neighbor 192.0.2.2 remote-as 65000 neighbor 192.0.2.2 update-source Loopback0 address-family vpnv4 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended maximum-paths ibgp 2
- Address families por VRF:
- address-family ipv4 vrf CUST-A redistribute connected
- address-family ipv6 vrf CUST-A redistribute connected
- Para 6VPE:
- address-family vpnv6 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended
- Definir a VRF e a conexão com o CE:
Verificação
- show ip route vrf CUST-A
- show bgp vpnv4 vrf CUST-A
- show bgp vpnv6 vrf CUST-A
- show bgp vpnv4 all summary
Política, Vazamento de Rotas, Serviços Compartilhados e Segmentação
Política de importação/exportação de RT
- Exportação: marca as rotas de uma VRF com um ou mais RTs. Importação: uma VRF importa qualquer rota cujo RT corresponda à sua lista de importação.
- O controle granular é alcançado com route-maps por VRF (mapas de exportação/importação) que correspondem a prefixos e definem/manipulam RTs. Isso limita a propagação não intencional de rotas.
Métodos de vazamento de rotas
- Vazamento baseado em RT (recomendado): defina uma VRF de Serviços Compartilhados (Shared-Services), exporte os prefixos de serviço com o RT SVC e importe o RT SVC nas VRFs de tenant selecionadas. Use mapas de exportação nos tenants para restringir quais rotas de tenant são exportadas de volta para os serviços.
- Vazamento local de VRF para VRF: em algumas plataformas, rotas estáticas podem apontar para interfaces em outras VRFs, ou o BGP pode estabelecer peering entre VRFs no mesmo PE. Use com cautela; isso ignora a política de RT e pode ser mais difícil de auditar.
- Compromissos de segurança:
- Importações excessivamente permissivas levam à alcançabilidade de qualquer para qualquer (any-to-any) e a um potencial movimento lateral.
- O vazamento simétrico sem filtros pode criar loops de feedback ou expor prefixos de gerenciamento/infraestrutura.
- Prefira um modelo de serviços compartilhados hub-and-spoke com listas de permissão (allow lists) explícitas (route-maps) e intertravamentos de firewall.
Conceitos e migração de roteamento segmentado
- A segmentação corporativa começa com VRF-Lite dentro de campi e data centers. O MPLS L3VPN estende esses segmentos pela WAN sem NAT, preservando IPs sobrepostos.
- Abordagem de migração:
- Mapeie cada segmento VRF-Lite on-prem para um par de RTs do provedor.
- Use o roteamento CE–PE (eBGP é o preferencial) para trocar rotas por segmento de forma determinística.
- Introduza uma VRF de Serviços Compartilhados para saída de DNS/AD/Internet e importe-a seletivamente.
- Underlays preparados para o futuro:
- LSPs baseados em LDP ou RSVP-TE são amplamente implantados. O Segment Routing MPLS (SR-MPLS) pode substituir o LDP/RSVP no underlay, mantendo o modelo de serviço L3VPN idêntico; apenas o label de transporte vem do SR em vez do LDP/RSVP.
Operações: Plano de Controle, Plano de Dados, Verificação e Isolamento de Falhas
Fluxo de pacotes de ponta a ponta
- O CE anuncia um prefixo para o PE de ingresso na VRF X.
- O PE de ingresso o instala na RIB/CEF da VRF X, o marca com os RTs de exportação, cria um NLRI VPNv4/v6 (RD:prefixo) e aloca um label de VPN.
- O MP-BGP anuncia a rota para os PEs remotos (ou via route reflectors), transportando o next hop (loopback do PE de ingresso) e o label de VPN.
- O IGP e o LDP/RSVP estabelecem um LSP de transporte em direção ao next hop do PE de egresso.
- Plano de dados: o PE de ingresso insere o label de VPN (interno) e o label de transporte (externo); os roteadores P trocam os labels externos; o penúltimo roteador P remove o label externo (PHP); o PE de egresso usa o label interno para selecionar a VRF e encaminha para o CE de egresso.
Modos de falha comuns e trade-offs
- Alcançabilidade do underlay ou LDP inativo: O MP-BGP pode permanecer ativo, mas sem um LSP de transporte, o PE de ingresso não consegue inserir um label externo válido; os pacotes são descartados. Use a sincronização LDP-IGP para evitar blackholing.
- Falta do label de VPN: A rota VPNv4 está presente, mas a ausência de um label (ou o label 3 com semântica inesperada) interrompe o encaminhamento. Confirme se o PE de egresso aloca labels por VRF; verifique políticas que possam suprimir o anúncio de labels.
- Incompatibilidade de RT (RT mismatch): As rotas estão presentes na VRF de envio, mas não são importadas pela VRF de recebimento. Verifique os RTs e se as comunidades estendidas são trocadas (send-community extended).
- MTU/fragmentação: As pilhas de labels adicionam overhead. Garanta que as interfaces do core e dos PEs suportem um MTU MPLS suficiente para evitar descartes; ajuste o MSS se necessário.
- QoS e PHP: O mapeamento de EXP para QoS pode ser perdido no egresso se o label superior for removido. Use explicit-null para transparência de QoS no salto de egresso.
- Seleção de caminho iBGP em VPNv4: Sem
maximum-paths ibgp N, apenas um caminho pode ser usado, mesmo com ECMP no core; habilite o multipath para fazer o balanceamento de carga.
Fluxo de trabalho de verificação
- Borda CE–PE:
undefined
,
undefined
, ou
undefined
- MP-BGP:
undefined
;
undefined
- Labels:
undefined
;
undefined
;
undefined
- Plano de dados:
undefined
;
undefined
ou para o loopback do PE de egresso; valide a marcação EXP/TC se QoS estiver no escopo
Saúde (Health): Considere o BFD nas adjacências CE–PE e PE–PE para proteger as sessões de roteamento.
Isolamento de falhas entre CE, PE e o core do provedor
- Valide a adjacência CE–PE e a existência das rotas da VRF no PE de ingresso.
- Confirme que a rota é exportada para VPNv4 com um RT esperado e que um label de VPN está presente no PE de egresso.
- Garanta que existe um LSP de transporte do PE de ingresso para o de egresso (vizinhos LDP/RSVP e label em direção ao loopback do PE de egresso).
- Teste a alcançabilidade PE–PE usando ping/traceroute originado do loopback do PE; verifique a consistência do ECMP.
- No PE de egresso, verifique se o label de VPN resolve para a VRF e a interface do CE corretas.
- Se todas as verificações do plano de controle passarem, capture os contadores do plano de dados e verifique o comportamento de MTU e QoS.
Cenário de Problema Prático
A Contoso Manufacturing planeja migrar de uma WAN com VRF-Lite para um MPLS L3VPN de um provedor, introduzindo ao mesmo tempo uma VRF central de Serviços Compartilhados (Shared-Services) para Internet e DNS. Os tenants A e B usam o endereço 10.10.0.0/16 internamente e devem permanecer isolados, exceto pelo acesso seletivo aos Serviços Compartilhados.
Abordagem
- Definir as VRFs e a política de RT nos PEs
Configuração:
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
- Justificativa: Os RDs garantem a unicidade entre as rotas sobrepostas de 10.10.0.0/16. Os RTs definem os limites de segmentação. Um RT distinto para os Serviços Compartilhados fornece um hub controlável.
- Associar as interfaces do CE às VRFs corretas e estabelecer o roteamento CE-PE
Exemplo de configuração:
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
- Justificativa: O eBGP entre CE e PE fornece limites de política claros e controle por tenant, sem vazar atributos entre os tenants.
- Habilitar o MP-BGP entre os PEs e propagar os RTs e os labels de VPN
Configuração:
undefined
undefined
undefined
undefined
undefined
undefined
undefined
- Justificativa: O anúncio VPNv4 transporta tanto os RTs quanto os labels de VPN por rota; habilitar o multipath iBGP prepara para o ECMP através de múltiplos caminhos de RR/PE.
- Construir e verificar os LSPs de transporte no core
Configuração:
undefined
-
undefined
undefined
undefined
- Justificativa: O LDP cria LSPs de PE para PE para o label externo. O ECMP no IGP junto com o LDP suporta escalabilidade e convergência. Verifique com
show mpls ldp neighboreshow mpls forwarding-table.
- Implementar o vazamento seletivo (selective leaking) de rotas dos Serviços Compartilhados
Configuração (nos tenants):
undefined
undefined
-
undefined
undefined
-
undefined
undefined
undefined
undefined
-
undefined
undefined
-
undefined
- Justificativa: Os tenants importam apenas as rotas dos Serviços Compartilhados; os Serviços Compartilhados importam as rotas dos tenants, mas exportam de volta apenas os prefixos aprovados para evitar que os tenants aprendam as rotas uns dos outros através do hub.
- Validar os planos de controle/dados e MTU/QoS
Comandos:
undefined
-
undefined
-
undefined
-
undefined
-
undefined
- Justificativa: Confirma o roteamento da VRF, as associações de labels (bindings) e a alcançabilidade de ponta a ponta. Verifique os MTUs das interfaces para acomodar a pilha de labels e preservar as marcações de QoS; habilite o explicit-null se o egresso precisar de visibilidade do EXP.
- Introduzir VPNs IPv6 usando 6VPE
Configuração:
undefined
undefined
undefined
-
undefined
undefined
- Justificativa: Fornece segmentação IPv6 sobre o mesmo core MPLS IPv4 com labels de VPN por rota e o mesmo modelo de política baseado em RT.
Este plano em etapas preserva a segmentação, permite o acesso compartilhado controlado, escala por meio da comutação de labels (label switching) no core e fornece pontos de verificação claros para o isolamento rápido de falhas.
← Redistribuição de Rotas e Roteamento Baseado em Políticas · Todos os domínios · Roteamento e Distribuição Multicast →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →