Tráfego IPv4 sobre VPNs de Camada 3
Entender a distribuição de rotas IPv4 em uma VPN de Camada 3
Dentro de uma VPN, a distribuição das rotas VPN-IPv4 ocorre entre os roteadores PE e CE e entre os roteadores PE (consulte a Figura 1).
Esta seção discute os seguintes tópicos:
- Distribuição de rotas de roteadores CE para PE
- Distribuição de rotas entre roteadores PE
- Distribuição de rotas de roteadores PE para CE
Distribuição de rotas de roteadores CE para PE
Um roteador CE anuncia suas rotas para o roteador PE conectado diretamente. As rotas anunciadas estão no formato IPv4. O roteador PE coloca as rotas na tabela VRF para a VPN. No Junos OS, esta é a routing-instance-nametabela de roteamento .inet.0, onde routing-instance-name está o nome configurado da VPN.
A conexão entre os roteadores CE e PE pode ser uma conexão remota (uma conexão WAN) ou uma conexão direta (como uma conexão Frame Relay ou Ethernet).
Os roteadores CE podem se comunicar com roteadores PE usando um dos seguintes:
OSPF
RIP
BGP
Rota estática
A Figura 2 ilustra como as rotas são distribuídas de roteadores CE a roteadores PE. O Roteador PE1 está conectado a dois roteadores CE que estão em VPNs diferentes. Portanto, ele cria duas tabelas VRF, uma para cada VPN. Os roteadores CE anunciam rotas IPv4. O roteador PE instala essas rotas em duas tabelas VRF diferentes, uma para cada VPN. Da mesma forma, o Roteador PE2 cria duas tabelas VRF em que as rotas são instaladas a partir dos dois roteadores CE conectados diretamente. O Roteador PE3 cria uma tabela VRF porque ela está diretamente conectada a apenas uma VPN.
PE
Distribuição de rotas entre roteadores PE
Quando um roteador PE recebe rotas anunciadas de um roteador CE diretamente conectado, ele verifica a rota recebida contra a política de exportação de VRF para essa VPN. Se for compatível, a rota é convertida em formato VPN-IPv4 — ou seja, o distintivo de roteamento de 8 byte está preparado para o prefixo VPN de 4 byte para formar um endereço VPN-IPv4 de 12 byte. A rota é então marcada com uma comunidade alvo de rotas. O roteador PE anuncia a rota no formato VPN-IPv4 para os roteadores PE remotos para uso por políticas de importação de VRF. As rotas são distribuídas usando sessões de IBGP, que estão configuradas na rede principal do provedor. Se a rota não for compatível, ela não é exportada para outros roteadores PE, mas ainda pode ser usada localmente para roteamento, por exemplo, se dois roteadores CE na mesma VPN estiverem conectados diretamente ao mesmo roteador PE.
O roteador PE remoto coloca a rota em sua tabela bgp.l3vpn.0 se a rota passar pela política de importação na sessão do IBGP entre os roteadores PE. Ao mesmo tempo, ele verifica a rota em relação à política de importação de VRF para a VPN. Caso corresponda, o distintivo de roteamento é removido da rota e é colocado na tabela VRF (a routing-instance-nametabela .inet.0) em formato IPv4.
A Figura 3 ilustra como o Roteador PE1 distribui rotas para os outros roteadores PE na rede principal do provedor. O ROTEADOR PE2 e o Roteador PE3 têm políticas de importação de VRF que usam para determinar se aceitam rotas recebidas nas sessões do IBGP e as instalam em suas tabelas VRF.
PE
Quando um roteador PE recebe rotas anunciadas de um roteador CE diretamente conectado (Roteador PE1 na Figura 3), ele usa o seguinte procedimento para examinar a rota, convertê-la em uma rota VPN e distribuí-la aos roteadores PE remotos:
O roteador PE verifica a rota recebida usando a política de exportação de VRF para essa VPN.
Se a rota recebida corresponda à política de exportação, a rota será processada da seguinte forma:
A rota é convertida em formato VPN-IPv4 — ou seja, o distintivo de roteamento de 8 byte está preparado para o prefixo VPN de 4 byte para formar o endereço VPN-IPv4 de 12 byte.
Uma comunidade alvo de rotas é adicionada à rota.
O roteador PE anuncia a rota no formato VPN-IPv4 para os roteadores PE remotos. As rotas são distribuídas usando sessões de IBGP, que estão configuradas na rede principal do provedor.
Caso a rota não corresponda à política de exportação, ela não é exportada para os roteadores PE remotos, mas ainda pode ser usada localmente para roteamento — por exemplo, se dois roteadores CE na mesma VPN estiverem diretamente conectados ao mesmo roteador PE.
Quando o roteador PE remoto recebe rotas anunciadas de outro roteador PE (Roteadores PE2 e PE3 na Figura 3), ele usa o seguinte procedimento para processar a rota:
Se a rota for aceita pela política de importação na sessão do IBGP entre os roteadores PE, o roteador PE remoto coloca a rota em sua tabela bgp.l3vpn.0.
O roteador PE remoto verifica a comunidade alvo de rota da rota contra a política de importação de VRF para a VPN.
Caso corresponda, o distintivo de roteamento é removido da rota e é colocado na tabela VRF (a routing-instance-nametabela .inet.0) em formato IPv4.
Distribuição de rotas de roteadores PE para CE
O roteador PE remoto anuncia as rotas em suas tabelas VRF, que estão no formato IPv4, para seus roteadores CE conectados diretamente.
Os roteadores PE podem se comunicar com roteadores CE usando um dos seguintes protocolos de roteamento:
OSPF
RIP
BGP
Rota estática
A Figura 4 ilustra como os três roteadores PE anunciam suas rotas para seus roteadores CE conectados.
CE
Entender endereços VPN-IPv4 e distinguidores de rotas
Como as VPNs de Camada 3 conectam redes privadas — que podem usar endereços públicos ou endereços privados, conforme definido no RFC 1918 (Alocação de endereços para Internets privadas)— pela infraestrutura pública da Internet, quando as redes privadas usam endereços privados, os endereços podem se sobrepor aos endereços de outra rede privada.
A Figura 5 ilustra como endereços privados de diferentes redes privadas podem se sobrepor. Aqui, sites dentro da VPN A e VPN B usam os espaços de endereço 10.1.0.0/16, 10.2.0.0/16 e 10.3.0.0/16 para suas redes privadas.
Para evitar endereços privados sobrepostos, você pode configurar os dispositivos de rede para usar endereços públicos em vez de endereços privados. No entanto, essa é uma empresa grande e complexa. A solução fornecida no RFC 4364 usa os números de rede privada existentes para criar um novo endereço que é inequívoco. O novo endereço faz parte da família de endereços VPN-IPv4, que é uma família de endereços BGP adicionada como uma extensão ao protocolo BGP. Nos endereços VPN-IPv4, um valor que identifica a VPN, chamada de distinção de rotas, é prefixado no endereço IPv4 privado, fornecendo um endereço que identifica exclusivamente um endereço IPv4 privado.
Apenas os roteadores PE precisam dar suporte à extensão de endereço VPN-IPv4 ao BGP. Quando um roteador PE de entrada recebe uma rota IPv4 de um dispositivo dentro de uma VPN, ele o converte em uma rota VPN-IPv4 adicionando o prefixo de distinção de rotas à rota. Os endereços VPN-IPv4 são usados apenas para rotas trocadas entre roteadores PE. Quando um roteador PE de saída recebe uma rota VPN-IPv4, ele converte a rota VPN-IPv4 de volta a uma rota IPv4 removendo o diferencial de rota antes de anunciar a rota para seus roteadores CE conectados.
Os endereços VPN-IPv4 têm o seguinte formato:
O diferencial de roteamento é um valor de 6 byte que você pode especificar em um dos seguintes formatos:
as-number:number, ondeas-numberestá um número AS (um valor de 2 byte) enumberqualquer valor de 4 byte. O número AS pode estar na faixa de 1 a 65.535. Recomendamos que você use uma Autoridade de Números Atribuídos à Internet (IANA) designada, número AS nãoprivado, de preferência do próprio provedor de serviços de Internet (ISP) ou do próprio número AS do cliente.ip-address:number, ondeip-addressestá um endereço IP (um valor de 4 byte) enumberqualquer valor de 2 byte. O endereço IP pode ser qualquer endereço unicast globalmente exclusivo. Recomendamos que você use o endereço que configura narouter-iddeclaração, que é um endereço nãoprivado na faixa de prefixo atribuído.
Endereço IPv4 — endereço de 4 byte de um dispositivo dentro da VPN.
A Figura 5 ilustra como o número de AS pode ser usado no distinguidor de rotas. Suponha que a VPN A esteja no AS 65535 e que a VPN B esteja no AS 666 (ambos os números de AS pertencem ao ISP) e suponha que o distinguidor de rotas para o Site 2 na VPN A seja 65535:02 e que o diferencial de rota para o Site 2 na VPN B seja 666:02. Quando o Roteador PE2 recebe uma rota do roteador CE na VPN A, ele a converte de seu endereço IP de 10.2.0.0 para um endereço VPN-IPv4 de 65535:02:10.2.0.0.0. Quando o roteador PE recebe uma rota da VPN B, que usa o mesmo espaço de endereço que VPN A, ele o converte em um endereço VPN-IPv4 de 666:02:10.2.0.0.
Se o endereço IP for usado no distintor de rotas, suponha que o endereço IP do Roteador PE2 seja 172.168.0.1. Quando o roteador PE recebe uma rota da VPN A, converte-o em um endereço VPN-IPv4 de 172.168.0.1:0:10.2.0.0/16, e converte uma rota da VPN B para 172.168.0.0.0:1:10.2.0.0/16.
Os diferenciais de rota são usados apenas entre roteadores PE e endereços IPv4 de diferentes VPNs. O roteador PE de entrada cria um diferencial de rota e converte as rotas IPv4 recebidas de roteadores CE em endereços VPN-IPv4. Os roteadores PE de saída convertem rotas VPN-IPv4 em rotas IPv4 antes de anunciarem o roteador CE.
Como os endereços VPN-IPv4 são um tipo de endereço BGP, você deve configurar sessões de IBGP entre pares de roteadores PE para que os roteadores PE possam distribuir rotas VPN-IPv4 na rede principal do provedor. (Presume-se que todos os roteadores PE estejam dentro do mesmo AS.)
Você define comunidades BGP para restringir a distribuição de rotas entre os roteadores PE. Definir comunidades BGP não distingue, por si só, endereços IPv4.
A Figura 6 ilustra como o Roteador PE1 adiciona o distinguidor de rotas 10458:22:10.1/16 às rotas recebidas do roteador CE no Site 1 na VPN A e encaminha essas rotas para os outros dois roteadores PE. Da mesma forma, o Roteador PE1 adiciona o distinguidor de rotas 10458:23:10.2/16 às rotas recebidas pelo roteador CE no Site 1 na VPN B e encaminha essas rotas para os outros roteadores PE .
rota
Configuração do encaminhamento de pacotes IPv4 para VPNs de Camada 3
Você pode configurar o roteador para dar suporte ao encaminhamento de pacotes para o tráfego IPv4 nas VPNs de Camada 2 e Camada 3. O encaminhamento de pacotes é tratado de uma das seguintes maneiras, dependendo do tipo de serviço de ajudante configurado:
Serviço BOOTP — os clientes enviam solicitações do Bootstrap Protocol (BOOTP) pelo roteador configurado com serviço BOOTP para um servidor na instância de roteamento especificada. O servidor reconhece o endereço do cliente e envia uma resposta de volta ao roteador configurado com o serviço BOOTP. Este roteador encaminha a resposta ao endereço do cliente correto na instância de roteamento especificada.
Outros serviços — os clientes enviam solicitações pelo roteador configurado com o serviço para um servidor na instância de roteamento especificada. O servidor reconhece o endereço do cliente e envia uma resposta ao endereço do cliente correto na instância de roteamento especificada.
Para habilitar o encaminhamento de pacotes para VPNs, inclua a helpers declaração:
helpers {
service {
description description-of-service;
server {
address address {
routing-instance routing-instance-names;
}
}
interface interface-name {
description description-of-interface;
no-listen;
server {
address address {
routing-instance routing-instance-names;
}
}
}
}
}
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit forwarding-options][edit logical-systems logical-system-name forwarding-options][edit routing-instances routing-instance-name forwarding-options]Nota:Você pode habilitar o encaminhamento de pacotes para várias VPNs. No entanto, o cliente e o servidor devem estar dentro da mesma VPN. Qualquer plataforma de roteamento da Juniper Networks com encaminhamento de pacotes habilitado ao longo do caminho entre o cliente e o servidor também deve residir na mesma VPN.
A instância de endereço e roteamento em conjunto constitui um servidor único. Isso tem implicações para roteadores configurados com o serviço BOOTP, que pode aceitar vários servidores.
Por exemplo, um serviço BOOTP pode ser configurado da seguinte forma:
[edit forwarding-options helpers bootp] server address 10.2.3.4 routing-instance [instance-A instance-B];
Embora os endereços sejam idênticos, as instâncias de roteamento são diferentes. Um pacote que vem para o instance-A serviço instance-A BOOTP é encaminhado 10.2.3.4 na instância de roteamento, enquanto um pacote que entra é instance-B encaminhado na instance-B instância de roteamento. Outros serviços só podem aceitar um único servidor, para que essa configuração não se aplique nesses casos.
Exemplo: configure uma VPN de camada 3 baseada em MPLS básica
Este exemplo mostra como configurar e validar uma VPN básica de Camada 3 baseada em MPLS em roteadores ou switches que executam o Junos OS. O exemplo baseado em IPv4 usa o EBGP como protocolo de roteamento entre os dispositivos de borda do provedor e do cliente.
Nossa equipe de testes de conteúdo validou e atualizou este exemplo.
Você pode implantar uma VPN (Virtual Private Network, rede privada virtual) baseada em MPLS usando roteadores e switches que executam o Junos OS para interconectar sites de clientes com conectividade de Camada 3. Embora o roteamento estático seja suportado, as VPNs de Camada 3 normalmente têm os dispositivos do cliente trocando informações de roteamento com a rede do provedor e exigem suporte para protocolos IP, ou seja, IPv4 e/ou IPv6.
Isso contrasta com uma VPN de Camada 2, na qual os dispositivos do cliente podem não ser baseados em protocolos IP e onde o roteamento, se houver, ocorre entre os dispositivos de borda do cliente (CE). Ao contrário de uma VPN de Camada 3 em que o dispositivo CE interage (peers) com o dispositivo de borda do provedor, em uma VPN de Camada 2 o tráfego do cliente passa de maneira transparente pelo núcleo do provedor com quaisquer protocolos de roteamento em execução de ponta a ponta entre os dispositivos CE.
As VPNs baseadas em MPLS exigem funcionalidade MPLS de linha de base na rede do provedor. Assim que o MPLS básico estiver operacional, você pode configurar VPNs que usam caminhos comutados por rótulos (LSPs) para o transporte pelo núcleo do provedor.
A inclusão de serviços VPN não afeta as operações básicas de comutação MPLS na rede do provedor. Na verdade, os dispositivos de provedor (P) exigem apenas uma configuração MPLS de linha de base porque eles não estão cientes de VPN. O estado de VPN é mantido apenas nos dispositivos de borda do provedor (PE). Essa é uma das principais razões pelas quais as VPNs baseadas em MPLS se expandem tão bem.
- Requisitos
- Visão geral e topologia
- Configurações rápidas
- Configure o dispositivo PE local (PE1) para uma VPN de Camada 3 baseada em MPLS
- Configure o dispositivo PE remoto (PE2) para uma VPN de Camada 3 baseada em MPLS
- Verificação
Requisitos
Este exemplo usa os seguintes componentes de software e hardware:
Junos OS Versão 12.3 ou posterior para dispositivos de roteamento e comutação
Revalidado no junos OS versão 20.3R1
Dois dispositivos de borda de provedor (PE)
Dispositivo de um provedor (P)
Dois dispositivos de borda do cliente (CE)
O exemplo se concentra em como adicionar uma VPN de Camada 3 a uma linha de base MPLS pré-existente. Uma configuração MPLS básica é fornecida caso sua rede ainda não tenha MPLS implantada.
Para oferecer suporte a VPNs baseadas em MPLS, a linha de base MPLS subjacente deve fornecer a seguinte funcionalidade:
Interfaces de loopback e voltadas para o núcleo operacionais com suporte da família MPLS
Um protocolo de gateway interno, como OSPF ou IS-IS, para fornecer alcance entre os endereços de loopback dos dispositivos de provedor (P e PE)
Um protocolo de sinalização MPLS, como LDP ou RSVP, para sinalizar LSPs
LSPs estabelecidos entre endereços de loopback de dispositivo PE
Os LSPs são necessários entre cada par de dispositivos PE que participam de uma determinada VPN. É uma boa ideia criar LSPs entre todos os dispositivos PE para acomodar o crescimento futuro de VPN. Você configura LSPs no nível de [edit protocols mpls] hierarquia. Ao contrário de uma configuração MPLS para uma conexão de conexão cruzada (CCC), você não precisa associar manualmente o LSP à interface voltada para o cliente (borda) do dispositivo PE. Em vez disso, as VPNs de Camada 3 usam a sinalização BGP para anunciar a alcance do site. Essa sinalização BGP automatiza o mapeamento de sites remotos de VPN para OLSP encaminhando os próximos hops. Isso significa que, com um mapeamento explícito de uma VPN de Camada 3 de um LSP para a interface voltada para a borda de um dispositivo PE, não é necessário.
Visão geral e topologia
As VPNs de Camada 3 permitem que os clientes aproveitem a experiência técnica do provedor de serviços para garantir um roteamento eficiente de site para local. O dispositivo de borda do cliente (CE) normalmente usa um protocolo de roteamento, como BGP ou OSPF, para trocar rotas com o dispositivo de borda de provedor de serviços (PE). O roteamento estático é suportado para VPNs de Camada 3, mas um protocolo de roteamento dinâmico é geralmente preferido.
A definição de uma VPN envolve alterações apenas nos dispositivos PE locais e remotos. Nenhuma configuração adicional é necessária nos dispositivos do provedor (supondo que eles já tenham uma linha de base MPLS em funcionamento), porque esses dispositivos só fornecem funções básicas de comutação MPLS. Os dispositivos CE não usam MPLS e exigem apenas uma configuração básica de protocolo de interface e roteamento para que possam interagir com os dispositivos PE.
Em uma VPN de Camada 3, você configura os dispositivos CE para peer com o dispositivo PE local. Isso contrasta com uma VPN de Camada 2, na qual os dispositivos CE se conectam como se estivessem em um link compartilhado, apesar de estarem conectados por meio de um núcleo de provedor baseado em MPLS.
Uma vez que uma linha de base MPLS esteja em vigor, você deve configurar a seguinte funcionalidade nos dispositivos PE para estabelecer sua VPN de Camada 3 baseada em MPLS:
Um grupo BGP com
family inet-vpn unicastsuporteUma instância de roteamento com tipo
vrfde instância e uma definição de protocolo de roteamento compatível com o dispositivo CE conectadoAs interfaces voltadas para o cliente nos dispositivos PE configuradas juntamente com
family inetum endereço IPv4 que coloca a interface na mesma sub-rede que o dispositivo CE conectado. Se desejado encapsulamento VLAN e um ID VLAN correspondente também podem ser configurados.
Para uma conectividade de ponta a ponta adequada, o dispositivo CE precisa ser configurado com parâmetros de protocolo de sub-rede IP e roteamento compatíveis para oferecer suporte a peering com o dispositivo PE.
A Figura 7 mostra a topologia usada neste exemplo. A figura detalha os nomes da interface, o endereço IP e os protocolos de roteamento usados nas redes de provedores e clientes. Ele também destaca a relação de peering entre os dispositivos CE e PE. Neste exemplo, você espera que cada dispositivo CE forme uma sessão de peering EBGP para o dispositivo PE local. Observe que a rede do provedor e ambos os sites de clientes têm um número de sistema autônomo atribuído para dar suporte à operação BGP. Neste exemplo, a política de roteamento é aplicada nos dispositivos CE para que eles anunciem as rotas diretas para suas interfaces voltadas para provedores e loopback.
de roteamento PE-CE
Configurações rápidas
Use as configurações nesta seção para colocar sua VPN de Camada 3 baseada em MPLS em funcionamento rapidamente. As configurações incluem uma linha de base MPLS funcional para dar suporte à sua VPN de Camada 3. Este exemplo se concentra nos aspectos vpn da configuração. Consulte os links a seguir para obter informações adicionais sobre a funcionalidade MPLS da linha de base usada neste exemplo:
Configuração rápida da CLI
As configurações do dispositivo omitem a interface de gerenciamento, rotas estáticas, registro de sistema, serviços de sistema e informações de login do usuário. Essas partes da configuração variam de acordo com a localização e não estão diretamente relacionadas à funcionalidade MPLS ou VPN.
Edite os seguintes comandos conforme necessário para as especificidades do seu ambiente e cole-os na janela de terminal de dispositivos CE (CE1) local quando estiver no modo de configuração na [edit] hierarquia:
A configuração completa para o dispositivo CE1.
set system host-name ce1 set interfaces xe-0/0/0:0 description "Link from CE1 to PE1 for L3vpn" set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 65410 set protocols bgp group PE1 type external set protocols bgp group PE1 export adv_direct set protocols bgp group PE1 peer-as 65412 set protocols bgp group PE1 neighbor 172.16.1.2 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept
A configuração completa para dispositivo PE1.
set system host-name pe1 set interfaces xe-0/0/0:0 description "Link from PE1 to CE1 for L3vpn" set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.1.2/30 set interfaces xe-0/0/0:1 description "Link from PE1 to p-router" set interfaces xe-0/0/0:1 mtu 4000 set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24 set interfaces xe-0/0/0:1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 65410 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn interface xe-0/0/0:0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.3 set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.3 set protocols mpls interface xe-0/0/0:1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface xe-0/0/0:1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface xe-0/0/0:1.0
A configuração completa para o dispositivo P.
set system host-name p set interfaces xe-0/0/0:0 description "Link from p-router to PE1" set interfaces xe-0/0/0:0 mtu 4000 set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.23.2/24 set interfaces xe-0/0/0:0 unit 0 family mpls set interfaces xe-0/0/0:1 description "Link from p-router to PE2" set interfaces xe-0/0/0:1 mtu 4000 set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.34.1/24 set interfaces xe-0/0/0:1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols mpls interface xe-0/0/0:0.0 set protocols mpls interface xe-0/0/0:1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 set protocols ospf area 0.0.0.0 interface xe-0/0/0:1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface xe-0/0/0:0.0 set protocols rsvp interface xe-0/0/0:1.0
A configuração completa para o dispositivo PE2.
set system host-name pe2 set interfaces xe-0/0/0:1 description "Link from PE2 to CE2 for L3vpn" set interfaces xe-0/0/0:1 unit 0 family inet address 172.16.2.2/30 set interfaces xe-0/0/0:0 description "Link from PE2 to p-router" set interfaces xe-0/0/0:0 mtu 4000 set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.34.2/24 set interfaces xe-0/0/0:0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 65420 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn interface xe-0/0/0:1.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.3:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set routing-options router-id 192.168.0.3 set routing-options autonomous-system 65412 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.3 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls interface xe-0/0/0:0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface xe-0/0/0:0.0
A configuração completa para o dispositivo CE2.
set system host-name ce2 set interfaces xe-0/0/0:0 description "Link from CE2 to PE2 for L3vpn" set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 65420 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept
Certifique-se de confirmar as mudanças de configuração em todos os dispositivos quando satisfeitos com o seu trabalho. Parabéns pela sua nova VPN de Camada 3 baseada em MPLS! Consulte a seção de verificação para saber as etapas necessárias para confirmar que sua VPN de Camada 3 está funcionando como esperado.
Configure o dispositivo PE local (PE1) para uma VPN de Camada 3 baseada em MPLS
Esta seção abrange as etapas necessárias para configurar o dispositivo PE1 para este exemplo. O foco nos dispositivos PE porque é onde a configuração de VPN está alojada. Consulte a seção configurações rápidas para as configurações de dispositivos CE e dispositivos P usadas neste exemplo.
Configure a linha de base MPLS (se necessário)
Antes de configurar uma VPN de Camada 3, certifique-se de que o dispositivo PE tenha uma linha de base MPLS em funcionamento. Se você já tiver uma linha de base MPLS, você pode pular para o procedimento passo a passo para adicionar a VPN de Camada 3 aos dispositivos PE.
Configure o nome de host.
[edit] user@pe1# set system host-name pe1
Configure as interfaces de núcleo e loopback:
[edit] user@pe1# set interfaces xe-0/0/0:1 description "Link from PE1 to P-router" [edit] user@pe1# set interfaces xe-0/0/0:1 mtu 4000 [edit] user@pe1# set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24 [edit] user@pe1# set interfaces xe-0/0/0:1 unit 0 family mpls [edit] user@pe1# set interfaces lo0 unit 0 family inet address 192.168.0.1/32
Práticas recomendadas:Embora uma VPN de Camada 3 possa realizar fragmentação na entrada PE, sua melhor prática é projetar a rede para que o CE possa enviar um quadro de tamanho máximo sem precisar de fragmentação. Para garantir que a fragmentação não ocorra, a rede do provedor deve suportar o maior quadro que os dispositivos CE podem gerar após o MPLS e os rótulos de roteamento e encaminhamento virtual (VRF) serem adicionados pelo dispositivo PE. Este exemplo deixa os dispositivos CE na unidade de transmissão máxima (MTU) padrão de 1500 byte enquanto configura o núcleo do provedor para oferecer suporte a um MTU de 4000 byte. Isso garante que os dispositivos CE não possam exceder o MTU na rede do provedor, mesmo com a sobrecarga de encapsulamento MPLS e VRF.
Configure os protocolos:
Nota:A engenharia de tráfego tem suporte para LSPs sinalizados por RSVP, mas não é necessária para a implantação básica de MPLS ou VPN. A linha de base MPLS fornecida usa RSVP para sinalizar LSPs e permite a engenharia de tráfego para OSPF. No entanto, nenhuma restrição de caminho está configurada, então você espera que os LSPs sejam roteados pelo caminho mais curto do protocolo de gateway interior.
[edit] user@pe1# set protocols ospf area 0.0.0.0 interface lo0.0 passive [edit] user@pe1# set protocols ospf area 0.0.0.0 interface xe-0/0/0:1.0 [edit] user@pe1# set protocols ospf traffic-engineering [edit] user@pe1# set protocols mpls interface xe-0/0/0:1.0 [edit] user@pe1# set protocols rsvp interface lo0.0 [edit] user@pe1# set protocols rsvp interface xe-0/0/0:1.0
Defina o LSP para o endereço de loopback do dispositivo PE remoto:
[edit] user@pe1# set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.3
A linha de base MPLS agora está configurada no dispositivo PE1. Continue configurando a VPN de Camada 3.
Procedimento
Procedimento passo a passo
Siga essas etapas para configurar o dispositivo PE1 para uma VPN de Camada 3.
Configure a interface voltada para o cliente:
Ponta:Você pode configurar uma VPN de Camada 2 baseada em MPLS e uma VPN de Camada 3 baseada em MPLS no mesmo dispositivo PE. No entanto, você não pode configurar a mesma interface voltada para a borda do cliente para oferecer suporte a uma VPN de Camada 2 e uma VPN de Camada 3.
[edit interfaces] user@pe1# set xe-0/0/0:0 description "Link from PE1 to CE1 for L3vpn" [edit] user@pe1# set xe-0/0/0:0 unit 0 family inet address 172.16.1.2/30
Configure um grupo BGP para o peering entre os dispositivos pe locais e remotos. Use o endereço de loopback do dispositivo PE como endereço local e permita que a
inet-vpn unicastfamília de endereços ofereça suporte à troca de rotas VPN de Camada 3. Uma política de roteamento para BGP não é necessária nos dispositivos PE neste exemplo. Por padrão, os dispositivos PE readvertem no IBGP as rotas que aprendem em seu peering EBGP para o dispositivo CE.[edit protocols bgp] user@pe1# set group ibgp local-address 192.168.0.1 [edit protocols bgp] user@pe1# set group ibgp family inet-vpn unicast
Ponta:Você pode especificar outras famílias de endereços se a sessão PE para PE IBGP precisar oferecer suporte à troca de rotas não VPN, como rotas IPv4 ou IPv6 regulares usando as famílias ou
inet6asinetfamílias, respectivamente.Configure o tipo de grupo BGP como interno.
[edit protocols bgp] user@pe1# set group ibgp type internal
Configure o endereço de loopback do dispositivo PE remoto como um vizinho BGP.
[edit protocols bgp] user@pe1# set group ibgp neighbor 192.168.0.3
Configure o ID do roteador para combinar com seu endereço de loopback e defina o número do sistema autônomo BGP necessário para peering BGP.
[edit routing-options] user@pe1# set router-id 192.168.0.1 [edit routing-options] user@pe1# set autonomous-system 65412
Configure a instância de roteamento. Especifique um nome de CE1_L3vpninstância e configure um
instance-typedevrf.[edit routing-instances] user@pe1# set CE1_L3vpn instance-type vrf
Configure a interface voltada para o cliente do dispositivo PE para pertencer à instância de roteamento.
[edit routing-instances] user@pe1# set CE1_L3vpn interface xe-0/0/0:0.0
Configure o diferencial de rota da instância de roteamento. Essa configuração é usada para distinguir as rotas enviadas de um VRF específico em um determinado dispositivo PE. Ela deve ser única para cada instância de roteamento em cada dispositivo PE.
[edit routing-instances] user@pe1# set CE1_L3vpn route-distinguisher 192.168.0.1:12
Configure o alvo da rota de roteamento e encaminhamento virtual (VRF) da instância. A
vrf-targetdeclaração adiciona a tag da comunidade especificada a todas as rotas anunciadas e, ao mesmo tempo, iguala automaticamente o mesmo valor para a importação de rotas. Configurar alvos de rota correspondentes nos dispositivos PE que compartilham uma determinada VPN é necessário para uma troca de rotas adequada.[edit routing-instances] user@pe1# set CE1_L3vpn vrf-target target:65142:12
Nota:Você pode criar políticas mais complexas configurando explicitamente políticas de importação e exportação de VRF usando as opções de importação e exportação. Veja detalhes sobre a importação de vrf e vrf-export .
Configure a instância de roteamento para dar suporte ao peering EBGP ao dispositivo CE1. O peering de interface direta para a extremidade CE1 do enlace VRF é usado, e o número do sistema autônomo do CE1 é especificado corretamente com o
peer-asparâmetro.[edit routing-instances] user@pe1# set CE1_L3vpn protocols bgp group CE1 type external [edit routing-instances] user@pe1# set CE1_L3vpn protocols bgp group CE1 peer-as 65410 [edit routing-instances] user@pe1# set CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1
Cometa suas alterações no dispositivo PE1 e retorne ao modo operacional CLI.
[edit] user@pe1# commit and-quit
Resultados
Exibir os resultados da configuração no dispositivo PE1. A saída reflete apenas a configuração funcional adicionada neste exemplo.
user@pe1> show configuration
interfaces {
xe-0/0/0:0 {
description "Link from PE1 to CE1 for L3vpn";
unit 0 {
family inet {
}
}
unit 0 {
family inet {
address 10.1.23.1/24;
}
family mpls;
}
ge-0/0/1 {
description "Link from PE1 to P-router";
mtu 4000;
unit 0 {
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
protocols {
bgp {
group CE1 {
type external;
peer-as 65410;
neighbor 172.16.1.1;
}
}
}
instance-type vrf;
interface xe-0/0/0:0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
router-id 192.168.0.1;
autonomous-system 65412;
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet-vpn {
unicast;
}
neighbor 192.168.0.3;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.3;
}
interface xe-0/0/0:1.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface xe-0/0/0:1.0;
}
}
rsvp {
interface lo0.0;
interface xe-0/0/0:1.0;
}
}
Configure o dispositivo PE remoto (PE2) para uma VPN de Camada 3 baseada em MPLS
Esta seção abrange as etapas necessárias para configurar o dispositivo PE1 para este exemplo. O foco nos dispositivos PE porque é onde a configuração de VPN está alojada. Consulte a seção configurações rápidas para as configurações de dispositivos CE e dispositivos P usadas neste exemplo.
Configure a linha de base MPLS (se necessário)
Antes de configurar uma VPN de Camada 3, certifique-se de que o dispositivo PE tenha uma linha de base MPLS em funcionamento. Se você já tiver uma linha de base MPLS, você pode pular para o procedimento passo a passo para adicionar a VPN de Camada 3 aos dispositivos PE.
Configure o nome de host.
[edit] user@pe2# set system host-name pe2
Configure as interfaces de núcleo e loopback:
[edit] user@pe2# set interfaces xe-0/0/0:0 description "Link from PE2 to P-router" [edit] user@pe2# set interfaces xe-0/0/0:0 mtu 4000 [edit] user@pe2# set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.34.2/24 [edit] user@pe2# set interfaces xe-0/0/0:0 unit 0 family mpls [edit] user@pe2# set interfaces lo0 unit 0 family inet address 192.168.0.3/32
Práticas recomendadas:Embora uma VPN de Camada 3 possa realizar fragmentação na entrada PE, sua melhor prática é projetar a rede para que o CE possa enviar um quadro de tamanho máximo sem precisar de fragmentação. Para garantir que a fragmentação não ocorra, a rede do provedor deve suportar o maior quadro que os dispositivos CE podem gerar após o MPLS e os rótulos de roteamento e encaminhamento virtual (VRF) serem adicionados pelo dispositivo PE. Este exemplo deixa os dispositivos CE na unidade de transmissão máxima (MTU) padrão de 1500 byte enquanto configura o núcleo do provedor para oferecer suporte a um MTU de 4000 byte. Isso garante que os dispositivos CE não possam exceder o MTU na rede do provedor, mesmo com a sobrecarga de encapsulamento MPLS e VRF.
Configure os protocolos:
Nota:A engenharia de tráfego tem suporte para LSPs sinalizados por RSVP, mas não é necessária para a implantação básica de MPLS ou VPN. A linha de base MPLS fornecida usa RSVP para sinalizar LSPs e permite a engenharia de tráfego para OSPF. No entanto, nenhuma restrição de caminho está configurada, então você espera que os LSPs sejam roteados pelo caminho mais curto do protocolo de gateway interior.
[edit] user@pe2# set protocols ospf area 0.0.0.0 interface lo0.0 passive [edit] user@pe2# set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 [edit] user@pe2# set protocols ospf traffic-engineering [edit] user@pe2# set protocols mpls interface xe-0/0/0:0.0 [edit] user@pe2# set protocols rsvp interface lo0.0 [edit] user@pe2# set protocols rsvp interface xe-0/0/0:0.0
Defina o LSP para o endereço de loopback do dispositivo PE remoto:
[edit] user@pe2# set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1
A linha de base MPLS agora está configurada no dispositivo PE1. Continue configurando a VPN de Camada 3.
Procedimento
Procedimento passo a passo
Siga essas etapas para configurar o dispositivo PE2 para uma VPN de Camada 3.
Configure a interface voltada para o cliente:
Ponta:Você pode configurar uma VPN de Camada 2 baseada em MPLS e uma VPN de Camada 3 baseada em MPLS no mesmo dispositivo PE. No entanto, você não pode configurar a mesma interface voltada para a borda do cliente para oferecer suporte a uma VPN de Camada 2 e uma VPN de Camada 3.
[edit interfaces] user@pe2# set xe-0/0/0:1 description "Link from PE2 to CE2 for L3vpn" [edit] user@pe2# set xe-0/0/0:1 unit 0 family inet address 172.16.2.2/30
Configure um grupo BGP para o peering entre os dispositivos pe locais e remotos. Use o endereço de loopback do dispositivo PE como endereço local e permita que a
inet-vpn unicastfamília de endereços ofereça suporte à troca de rotas VPN de Camada 3.[edit protocols bgp] user@pe1# set group ibgp local-address 192.168.0.1 [edit protocols bgp] user@pe1# set group ibgp family inet-vpn unicast
Ponta:Você pode especificar outras famílias de endereços se a sessão PE para PE IBGP precisar oferecer suporte à troca de rotas não VPN, como rotas IPv4 ou IPv6 regulares usando as famílias ou
inet6asinetfamílias, respectivamente.Configure o tipo de grupo BGP como interno.
[edit protocols bgp] user@pe2# set group ibgp type internal
Configure o endereço de loopback do dispositivo PE1 como um vizinho BGP.
[edit protocols bgp] user@pe2# set group ibgp neighbor 192.168.0.1
Configure o ID do roteador para combinar com seu endereço de loopback e defina o número do sistema autônomo BGP.
[edit routing-options] user@pe2# set routing-options router-id 192.168.0.3 [edit routing-options] user@pe2# set autonomous-system 65412
Configure a instância de roteamento. Especifique um nome de CE2_L3vpninstância com um
instance-typedevrf.[edit routing-instances] user@pe2# set CE2_L3vpn instance-type vrf
Configure a interface voltada para o cliente do dispositivo PE para pertencer à instância de roteamento.
[edit routing-instances] user@pe2# set CE2_L3vpn interface xe-0/0/0:1.0
Configure o diferencial de rota da instância de roteamento. Essa configuração é usada para distinguir as rotas enviadas de um VRF específico em um determinado dispositivo PE. Ela deve ser única para cada instância de roteamento em cada dispositivo PE.
[edit routing-instances] user@pe2# set CE2_L3vpn route-distinguisher 192.168.0.3:12
Configure o alvo da rota de roteamento e encaminhamento virtual (VRF) da instância. A
vrf-targetdeclaração adiciona a tag da comunidade especificada a todas as rotas anunciadas e, ao mesmo tempo, iguala automaticamente o mesmo valor para a importação de rotas. Configurar alvos de rota correspondentes nos dispositivos PE que compartilham uma determinada VPN é necessário para uma troca de rotas adequada.[edit routing-instances] user@pe2# set CE2_L3vpn vrf-target target:65412:12
Nota:Você pode criar políticas mais complexas configurando explicitamente políticas de importação e exportação de VRF usando as opções de importação e exportação. Veja detalhes sobre a importação de vrf e vrf-export .
Configure a instância de roteamento para dar suporte ao peering EBGP ao dispositivo CE2. O peering de interface direta para a extremidade CE2 do link VRF é usado, e o número do sistema autônomo do CE2 é especificado corretamente com o
peer-asparâmetro.[edit routing-instances] user@pe2# set CE2_L3vpn protocols bgp group CE2 type external [edit routing-instances] user@pe2# set CE2_L3vpn protocols bgp group CE2 peer-as 65420 [edit routing-instances] user@pe2# set CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1
Cometa suas alterações no dispositivo PE2 e retorne ao modo operacional CLI.
[edit] user@pe2# commit and-quit
Resultados
Exibir os resultados da configuração no dispositivo PE2. A saída reflete apenas a configuração funcional adicionada neste exemplo.
user@pe2> show configuration
interfaces {
xe-0/0/0:0 {
description "Link from PE2 to p-router";
mtu 4000;
unit 0 {
family inet {
address 10.1.34.2/24;
}
family mpls;
}
}
xe-0/0/0:1 {
description "Link from PE2 to CE2 for L3vpn";
unit 0 {
family inet {
address 172.16.2.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.3/32;
}
}
}
}
routing-instances {
CE2_L3vpn {
protocols {
bgp {
group CE2 {
type external;
peer-as 65420;
neighbor 172.16.2.1;
}
}
}
instance-type vrf;
interface xe-0/0/0:1.0;
route-distinguisher 192.168.0.3:12;
vrf-target target:65412:12;
}
}
routing-options {
router-id 192.168.0.3;
autonomous-system 65412;
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.3;
family inet-vpn {
unicast;
}
neighbor 192.168.0.1;
}
}
mpls {
label-switched-path lsp_to_pe1 {
to 192.168.0.1;
}
interface xe-0/0/0:0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface xe-0/0/0:0.0;
}
}
rsvp {
interface lo0.0;
interface xe-0/0/0:0.0;
}
}
Verificação
Execute essas tarefas para verificar se a VPN de Camada 3 baseada em MPLS funciona corretamente:
- Verificar as adjacências e a troca de rotas do provedor OSPF
- Verifique as configurações da interface MPLS e RSVP
- Verifique os LSPs sinalizados por RSVP
- Verificar o status da sessão BGP
- Verifique as rotas de VPN de Camada 3 na tabela de roteamento
- Ping no dispositivo PE remoto usando a conexão VPN de Camada 3
- Verifique a operação de ponta a ponta dos dispositivos CE na VPN de Camada 3
Verificar as adjacências e a troca de rotas do provedor OSPF
Propósito
Confirme que o protocolo OSPF está funcionando corretamente na rede do provedor verificando o status de adjacência e as rotas aprendidas pelo OSPF para os endereços de loopback dos dispositivos de provedor remoto. A operação adequada do IGP é essencial para o bem-sucedido estabelecimento de LSPs MPLS.
Ação
user@pe1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 xe-0/0/0:1.0 Full 192.168.0.2 128 37
user@pe1> show route protocol ospf | match 192.168 192.168.0.2/32 *[OSPF/10] 1w1d 23:59:43, metric 1 192.168.0.3/32 *[OSPF/10] 1w1d 23:59:38, metric 2
Significado
A saída mostra que o dispositivo PE1 estabeleceu uma adjacência de OSPF para o dispositivo P ().192.168.0.2 Ele também mostra que os endereços de loopback do dispositivo P e PE remoto (192.168.0.2) e (192.168.0.3) são corretamente aprendidos via OSPF no dispositivo PE local.
Verifique as configurações da interface MPLS e RSVP
Propósito
Verifique se os protocolos RSVP e MPLS estão configurados para operar na interface voltada para o núcleo do dispositivo PE. Essa etapa também verifica que family mpls está configurada corretamente no nível de unidade da interface voltada para o núcleo do dispositivo PE.
Ação
user@pe1> show mpls interface Interface State Administrative groups (x: extended) xe-0/0/0:1.0 Up <none>
user@pe1> show rsvp interface
RSVP interface: 2 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
xe-0/0/0:1.0 Up 1 100% 10Gbps 10Gbps 0bps 0bps
Significado
A saída mostra que MPLS e RSVP estão configurados corretamente nas interfaces de loopback e núcleo do dispositivo PE local.
Verifique os LSPs sinalizados por RSVP
Propósito
Verifique se os LSPs de entrada e saída sinalizados pelo RSVP estão corretamente estabelecidos entre os endereços de loopback do dispositivo PE.
Ação
user@pe1> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.3 192.168.0.1 Up 0 1 FF - 17 lsp_to_pe2 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.3 Up 0 1 FF 3 - lsp_to_pe1 Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
A saída mostra que as sessões de RSVP de entrada e saída estão corretamente estabelecidas entre os dispositivos PE. Um estabelecimento LSP bem-sucedido indica que a linha de base MPLS está operacional.
Verificar o status da sessão BGP
Propósito
Verifique se a sessão de IBGP entre os dispositivos PE está corretamente estabelecida com suporte para informações de alcance da camada de rede VPN (NLRI) de Camada 3. Nesta etapa, você também confirma que a sessão local de PE para CE EBGP está estabelecida e configurada corretamente para trocar rotas IPv4.
Ação
user@pe1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 65410 26038 25938 0 0 1w1d 3:12:32 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.3 65412 19 17 0 0 6:18 Establ
CE1_L3vpn.inet.0: 2/2/2/0
bgp.l3vpn.0: 2/2/2/0
Significado
A saída mostra que a sessão do IBGP para o dispositivo PE remoto (192.168.0.3) foi corretamente estabelecida (Establ) e, através do Up/Dwn campo, há quanto tempo a sessão está no estado atual (6:18). O flaps campo confirma que nenhuma transição de estado ocorreu (0), indicando que a sessão está estável. Observe também que as rotas VPN de Camada 3 (NLRI) foram aprendidas com o PE remoto, conforme mostrado pela presença de uma bgp.l3vpn.0 tabela.
O display também confirma que a sessão EBGP para o dispositivo CE1 local (172.16.1.1) está estabelecida e que as rotas IPv4 foram recebidas do dispositivo CE1 e instaladas na instância de roteamento de dispositivos CE1 (CE1_L3vpn.inet.0)
Essa saída confirma que o peering BGP entre os dispositivos PE e o dispositivo CE está funcionando corretamente para dar suporte à sua VPN de Camada 3.
Verifique as rotas de VPN de Camada 3 na tabela de roteamento
Propósito
Confirme que a tabela de roteamento do dispositivo PE1 é preenchida com rotas VPN de Camada 3 anunciadas pelo PE remoto. Essas rotas são usadas para encaminhar o tráfego para o dispositivo CE remoto.
Ação
user@pe1> show route table bgp.l3vpn.0
bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.3:12:172.16.2.0/30
*[BGP/170] 00:22:45, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
192.168.0.3:12:172.16.255.2/32
*[BGP/170] 00:22:43, localpref 100, from 192.168.0.3
AS path: 65420 I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
user@pe1> show route table CE1_L3vpn.inet.0
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 1w1d 03:29:44
> via xe-0/0/0:0.0
[BGP/170] 1w1d 03:29:41, localpref 100
AS path: 65410 I, validation-state: unverified
> to 172.16.1.1 via xe-0/0/0:0.0
172.16.1.2/32 *[Local/0] 1w1d 03:29:44
Local via xe-0/0/0:0.0
172.16.2.0/30 *[BGP/170] 00:23:28, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 1w1d 03:29:41, localpref 100
AS path: 65410 I, validation-state: unverified
> to 172.16.1.1 via xe-0/0/0:0.0
172.16.255.2/32 *[BGP/170] 00:23:26, localpref 100, from 192.168.0.3
AS path: 65420 I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
Significado
O show route table bgp.l3vpn.0 comando exibe as rotas VPN de Camada 3 que foram recebidas do dispositivo PE remoto. O show route table CE1_L3vpn.inet.0 comando lista todas as rotas importadas para a CE1_L3vpn instância de roteamento. Essas entradas representam as rotas aprendidas com o peering EBGP local até o dispositivo CE1, além das rotas recebidas do dispositivo PE2 remoto com um alvo de rota correspondente.
Ambas as tabelas mostram que as rotas vpn remotas de Camada 3 estão corretamente associadas ao lsp_to_pe2 LSP como um próximo salto de encaminhamento. As saídas confirmam que o dispositivo PE local aprendeu as rotas associadas à localização remota do CE2 a partir do dispositivo PE2. Isso também mostra que o PE local encaminha o tráfego VPN de Camada 3 para o dispositivo PE2 remoto usando o transporte MPLS pela rede do provedor.
Ping no dispositivo PE remoto usando a conexão VPN de Camada 3
Propósito
Verifique a conectividade VPN de Camada 3 entre os dispositivos PE locais e remotos usando ping. Esse comando verifica o roteamento VPN de Camada 3 e a operação de encaminhamento MPLS entre os dispositivos PE.
Ação
user@pe1> ping routing-instance CE1_L3vpn 172.16.2.2 source 172.16.1.2 count 2 PING 172.16.2.2 (172.16.2.2): 56 data bytes 64 bytes from 172.16.2.2: icmp_seq=0 ttl=61 time=128.235 ms 64 bytes from 172.16.2.2: icmp_seq=1 ttl=61 time=87.597 ms --- 172.16.2.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 87.597/107.916/128.235/20.319 m
Significado
A saída confirma que os planos de controle e encaminhamento de VPN de Camada 3 estão operando corretamente entre os dispositivos PE.
Verifique a operação de ponta a ponta dos dispositivos CE na VPN de Camada 3
Propósito
Verifique a conectividade VPN de Camada 3 entre os dispositivos CE. Esta etapa confirma que os dispositivos CE têm interfaces operacionais e estão devidamente configurados para conectividade de Camada 3 baseada em EBGP. Isso é feito verificando se o dispositivo CE1 local aprendeu as rotas remotas do dispositivo CE, e confirmando que os dispositivos CE são capazes de passar tráfego de ponta a ponta entre seus endereços de loopback.
Ação
user@ce1> show route protocol bgp
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/30 *[BGP/170] 00:40:50, localpref 100
AS path: 65412 I, validation-state: unverified
> to 172.16.1.2 via xe-0/0/0:0.0
172.16.255.2/32 *[BGP/170] 00:40:49, localpref 100
AS path: 65412 65420 I, validation-state: unverified
> to 172.16.1.2 via xe-0/0/0:0.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
user@ce1> ping 172.16.255.2 source 172.16.255.1 size 1472 do-not-fragment count 2 PING 172.16.255.2 (172.16.255.2): 1472 data bytes 1480 bytes from 172.16.255.2: icmp_seq=0 ttl=61 time=79.245 ms 1480 bytes from 172.16.255.2: icmp_seq=1 ttl=61 time=89.125 ms --- 172.16.255.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 79.245/84.185/89.125/4.940 ms
Significado
A saída mostra que a conectividade baseada em VPN de Camada 3 está funcionando corretamente entre os dispositivos CE. O dispositivo CE local aprendeu a interface VRF do dispositivo CE remoto e rotas de loopback através do BGP. O ping é gerado para o endereço de loopback do dispositivo CE remoto, e é originado do endereço de loopback do dispositivo CE local usando o source 172.16.255.1 argumento. Adicionar os do-not-fragment switches e size 1472 confirmar que os dispositivos CE são capazes de passar pacotes IP de 1500 byte sem evocar fragmentação no dispositivo PE local.
O size 1472 argumento adicionado ao ping comando gera 1472 bytes de dados echo. Mais 8 bytes do Protocolo de Mensagem de Controle de Internet (ICMP) e 20 bytes de cabeçalho IP são adicionados para levar o tamanho total da carga a 1500 bytes. Adicionar o do-not-fragment switch garante que os dispositivos CE e PE locais não possam realizar a fragmentação. Este método de ping confirma que a fragmentação não é necessária ao trocar quadros Ethernet de comprimento máximo padrão de 1500 byte entre os dispositivos CE.
Esses resultados confirmam que a VPN de Camada 3 baseada em MPLS está funcionando corretamente.