Visão geral

VPNs de camada 2

Implementar uma VPN de Camada 2 em um roteador é semelhante à implementação de uma VPN usando uma tecnologia de Camada 2, como ATM ou Frame Relay. No entanto, para uma VPN de Camada 2 em um roteador, o tráfego é encaminhado para o roteador no formato de Camada 2. Ele é transportado pelo MPLS pela rede do provedor de serviços e depois convertido de volta ao formato de Camada 2 no site de recebimento. Você pode configurar diferentes formatos de Camada 2 nos sites de envio e recebimento. A segurança e a privacidade de uma VPN MPLS Layer 2 são iguais às de uma VPN atm ou Frame Relay.

Em uma VPN de Camada 2, o roteamento ocorre nos roteadores do cliente, normalmente no roteador CE. O roteador CE conectado a um provedor de serviços em uma VPN de Camada 2 deve selecionar o circuito apropriado para enviar tráfego. O roteador PE que recebe o tráfego envia-o pela rede do provedor de serviços para o roteador PE conectado ao site receptor. Os roteadores PE não precisam armazenar ou processar as rotas do cliente; eles só precisam ser configurados para enviar dados para o túnel apropriado.

Para uma VPN de Camada 2, os clientes precisam configurar seus próprios roteadores para transportar todo o tráfego de Camada 3. O provedor de serviços precisa saber apenas quanto tráfego a VPN de Camada 2 precisa transportar. Os roteadores do provedor de serviços transportam tráfego entre os sites do cliente usando interfaces VPN de Camada 2. A topologia de VPN é determinada por políticas configuradas nos roteadores PE.

VPNs de camada 3

Em uma VPN de Camada 3, o roteamento ocorre nos roteadores do provedor de serviços. Portanto, as VPNs de Camada 3 exigem mais configuração por parte do provedor de serviços, porque os roteadores PE do provedor de serviços devem armazenar e processar as rotas do cliente.

No Junos OS, as VPNs de Camada 3 são baseadas em RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs). Essa RFC define um mecanismo pelo qual os provedores de serviços podem usar seus backbones IP para fornecer serviços VPN de Camada 3 a seus clientes. Os sites que compõem uma VPN de Camada 3 estão conectados pelo backbone de Internet público existente de um provedor.

As VPNs baseadas na RFC 4364 também são conhecidas como VPNs BGP/MPLS porque o BGP é usado para distribuir informações de roteamento VPN pelo backbone do provedor, e o MPLS é usado para encaminhar o tráfego de VPN através do backbone para sites VPN remotos.

As redes de clientes, por serem privadas, podem usar endereços públicos ou privados, conforme definido na RFC 1918, Alocação de endereços para Internets privadas. Quando as redes de clientes que usam endereços privados se conectam à infraestrutura pública da Internet, os endereços privados podem se sobrepor aos endereços privados usados por outros usuários da rede. As VPNs BGP/MPLS resolvem esse problema prefixando um identificador de VPN em cada endereço de um determinado site VPN, criando assim um endereço único, tanto dentro da VPN como dentro da Internet pública. Além disso, cada VPN tem sua própria tabela de roteamento específica de VPN que contém as informações de roteamento apenas para essa VPN.

VPLS

O serviço de LAN privada virtual (VPLS) permite que você conecte sites de clientes geograficamente dispersos como se estivessem conectados à mesma LAN. De várias maneiras, funciona como uma VPN de Camada 2. VPLS e VPNs de Camada 2 usam a mesma topologia e função de rede de maneira semelhante. Um pacote originário da rede de um cliente é enviado primeiro para um dispositivo CE. Em seguida, ele é enviado para um roteador PE dentro da rede do provedor de serviços. O pacote atravessa a rede do provedor de serviços por um MPLS LSP. Ele chega ao roteador PE de saída, que depois encaminha o tráfego para o dispositivo CE no local do cliente de destino.

A principal diferença no VPLS é que os pacotes podem atravessar a rede do provedor de serviços de forma ponto a multiponto, o que significa que um pacote originário de um dispositivo CE pode ser transmitido para roteadores PE no VPLS. Por outro lado, uma VPN de Camada 2 encaminha pacotes apenas de forma pontual. O destino de um pacote recebido de um dispositivo CE por um roteador PE deve ser conhecido para que a VPN de Camada 2 funcione corretamente.

Somente em uma rede de Camada 3, você pode configurar serviços de LAN privadas virtuais (VPLS), para conectar sites de redes locais de Ethernet (LAN) geograficamente dispersos entre si em um backbone MPLS. Para clientes ISP que implementam VPLS, todos os sites parecem estar na mesma LAN Ethernet, embora o tráfego viaje pela rede do provedor de serviços. O VPLS foi projetado para transportar o tráfego Ethernet por uma rede de provedores de serviços habilitada para MPLS. De certas maneiras, o VPLS imita o comportamento de uma rede Ethernet. Quando um roteador PE configurado com uma instância de roteamento VPLS recebe um pacote de um dispositivo CE, ele primeiro verifica a tabela de roteamento apropriada para o destino do pacote VPLS. Se o roteador tiver o destino, ele o encaminha para o roteador PE apropriado. Se ele não tiver o destino, ele transmite o pacote para todos os outros roteadores PE que são membros da mesma instância de roteamento VPLS. Os roteadores PE encaminham o pacote para seus dispositivos CE. O dispositivo CE que é o destinatário pretendido do pacote o encaminha ao seu destino final. Os outros dispositivos CE o descartam.

Instâncias de roteamento de roteador virtual

Uma instância de roteamento de roteador virtual, como uma instância de roteamento e encaminhamento de VPN (VRF), mantém tabelas separadas de roteamento e encaminhamento para cada instância. No entanto, muitas etapas de configuração necessárias para instâncias de roteamento VRF não são necessárias para instâncias de roteamento de roteador virtual. Especificamente, você não precisa configurar um diferencial de rota, uma política de tabela de roteamento (o vrf-export, vrf-importe route-distinguisher declarações), ou MPLS entre os roteadores P.

No entanto, você precisa configurar interfaces lógicas separadas entre cada um dos roteadores de provedores de serviços que participam de uma instância de roteamento de roteador virtual. Você também precisa configurar interfaces lógicas separadas entre os roteadores de provedores de serviços e os roteadores de clientes que participam de cada instância de roteamento. Cada instância do roteador virtual requer seu próprio conjunto exclusivo de interfaces lógicas para todos os roteadores participantes.

A Figura 1 mostra como isso funciona. Os roteadores de provedores de serviços G e H estão configurados para instâncias de roteamento de roteador virtual Red e Green. Cada roteador de provedor de serviços está diretamente conectado a dois roteadores de clientes locais, um em cada instância de roteamento. Os roteadores de provedores de serviços também estão conectados entre si pela rede de provedores de serviços. Esses roteadores precisam de quatro interfaces lógicas: uma interface lógica para cada um dos roteadores de clientes conectados localmente e uma interface lógica para transportar tráfego entre os dois roteadores de provedores de serviços para cada instância do roteador virtual.

Figura 1: Interface lógica por roteador em uma instância de roteamento de roteador virtual

As VPNs de Camada 3 não têm esse requisito de configuração. Se você configurar várias instâncias de roteamento VPN de Camada 3 em um roteador PE, todas as instâncias podem usar a mesma interface lógica para alcançar outro roteador PE. Isso é possível porque as VPNs de Camada 3 usam rótulos MPLS (VPN) que diferenciam o tráfego de e para várias instâncias de roteamento. Sem rótulos MPLS e VPN, como em uma instância de roteamento de roteador virtual, você precisa de interfaces lógicas separadas para separar o tráfego de diferentes instâncias.

Um método para fornecer essa interface lógica entre os roteadores de provedores de serviços é configurar túneis entre eles. Você pode configurar segurança IP (IPsec), encapsulamento de roteamento genérico (GRE) ou túneis IP-IP entre os roteadores de provedores de serviços, encerrando os túneis na instância do roteador virtual.

Componentes de uma VPN de Camada 3

Existem três tipos principais de VPNs MPLS: VPNs de Camada 2, circuitos de Camada 2 e VPNs de Camada 3. Todos os tipos de VPNs MPLS compartilham determinados componentes:

• Dispositivos CE — dispositivos Customer Edge (CE) nas instalações do cliente que se conectam à rede do provedor. Alguns modelos chamam esses dispositivos de Customer Premises Equipment (CPE).

• Rede do cliente — sites de clientes com dispositivos CE que pertencem à VPN.

• Rede de provedores — a rede de backbone do provedor de serviços que executa o backbone MPLS.

• Dispositivos P — dispositivos provedores (P) dentro do núcleo da rede do provedor. Os dispositivos de provedores não estão conectados a nenhum dispositivo em um site do cliente e fazem parte do túnel entre pares de dispositivos PE. Os dispositivos provedores oferecem suporte à funcionalidade de caminho comutado por rótulos (LSP) como parte do suporte ao túnel, mas não oferecem suporte à funcionalidade VPN.

• Dispositivos PE — dispositivos de borda de provedor (PE) dentro de uma rede de núcleo de provedor de serviços que se conectam diretamente a um dispositivo CE no site do cliente.

• MP-BGP— Dispositivos PE usam MP-BGP para distribuir rotas de clientes para os dispositivos PE adequados em todo o backbone MPLS.

Terminologia VPN de Camada 3

As VPNs usam uma terminologia distinta para identificar componentes da rede:

• Tabela de roteamento IP (também chamada de tabela de roteamento global)— esta tabela contém rotas de provedores de serviços não incluídas em um VRF. Os dispositivos de provedores precisam desta tabela para poder alcançar uns aos outros, enquanto a tabela VRF é necessária para alcançar todos os dispositivos do cliente em uma VPN específica. Por exemplo, um roteador PE com a Interface A para um roteador CE e Interface B para um roteador P de backbone coloca os endereços Interface A no VRF e nos endereços B da Interface na tabela de roteamento IP global.

• Distinção de rotas — um valor de 64 bits pré-preparado para um endereço IP. Essa tag exclusiva ajuda a identificar as rotas dos diferentes clientes, pois os pacotes fluem pelo mesmo túnel do provedor de serviços.

  Como uma rede de trânsito típica está configurada para lidar com mais de uma VPN, é provável que os roteadores de provedores tenham várias instâncias VRF configuradas. Como resultado, dependendo da origem do tráfego e de quaisquer regras de filtragem aplicadas ao tráfego, as tabelas de roteamento BGP podem conter várias rotas para um determinado endereço de destino. Como o BGP exige que exatamente uma rota BGP por destino seja importada para a tabela de encaminhamento, o BGP deve ter uma maneira de distinguir entre as mensagens de alcance de camada de rede (NLRI) potencialmente idênticas recebidas de diferentes VPNs.

  Um diferenciador de rotas é um número localmente único que identifica todas as informações de rota para uma VPN em particular. Identificadores numéricos exclusivos permitem que o BGP distingue entre rotas idênticas.

  Cada instância de roteamento configurada em um roteador PE deve ter um diferencial de rota único. Existem dois formatos possíveis:

  • as-number:number— Onde há as-number um número de sistema autônomo (AS) (um valor de 2 byte) na faixa de 1 a 65.535, e number é qualquer valor de 4 byte. Recomendamos que você use uma Autoridade de Números Atribuídos à Internet (IANA) designada, número AS nãoprivado, de preferência o ISP ou o número AS do cliente.

  • ip-address:number— Onde há ip-address um endereço IP (um valor de 4 byte) e number qualquer valor de 2 byte. O endereço IP pode ser qualquer endereço unicast único globalmente. Recomendamos que você use o endereço que configura na declaração de identificação do roteador, que é um endereço IP público na faixa de prefixo atribuída.

• Alvo de rota (RT)— um valor de 64 bits usado para identificar o dispositivo PE de saída final para rotas de clientes em um VRF específico para permitir o compartilhamento complexo de rotas. O alvo de rota define qual rota faz parte de uma VPN. Um alvo de rota exclusivo ajuda a distinguir entre diferentes serviços de VPN no mesmo roteador. Cada VPN também tem uma política que define como as rotas são importadas para a tabela VRF no roteador. Uma VPN de Camada 2 está configurada com políticas de importação e exportação. Uma VPN de Camada 3 usa um alvo de rota exclusivo para distinguir entre as rotas de VPN. Por exemplo, o RT permite o compartilhamento de rotas em uma rede de serviços compartilhados para vários clientes. Cada rota vpn pode ter um ou mais RTs. Um dispositivo PE lida com RTs como valores estendidos da comunidade BGP e usa os RTs para instalar rotas de clientes.

• Rotas VPN-IPv4 — uma rota que consiste em uma sequência de 96 bits composta por uma tag RD de 64 bits preparada para um endereço IPv4 de 32 bits. Os dispositivos PE exportam as rotas VPN-IPv4 em sessões de IBGP para os outros dispositivos provedores. Essas rotas são trocadas pelo backbone MPLS usando o iBGP. Quando o dispositivo PE de saída recebe a rota, ele tira o diferencial de rota e anuncia a rota para os dispositivos CE conectados, normalmente através de anúncios de rota BGP IPv4 padrão.

• VRF — A tabela de roteamento e encaminhamento virtual (VRF) distingue as rotas para diferentes clientes, bem como as rotas de clientes das rotas de provedores no dispositivo PE. Essas rotas podem incluir espaços de endereço de rede privada sobrepostos, rotas públicas específicas do cliente e rotas de provedor em um dispositivo PE útil ao cliente.

  Uma instância VRF consiste em uma ou mais tabelas de roteamento, uma tabela de encaminhamento derivada, as interfaces que usam a tabela de encaminhamento e os protocolos de políticas e roteamento que determinam o que entra na tabela de encaminhamento. Como cada instância está configurada para uma VPN em particular, cada VPN tem tabelas, regras e políticas separadas que controlam sua operação.

  Uma tabela VRF separada é criada para cada VPN que tenha uma conexão com um roteador CE. A tabela VRF é povoada com rotas recebidas de locais CE diretamente conectados associados à instância VRF, e com rotas recebidas de outros roteadores PE na mesma VPN.

Arquitetura VPN de Camada 3

Uma VPN de Camada 3 conecta roteadores de borda do cliente (roteadores CE) a roteadores na borda da rede de provedores de serviços (roteadores PE). Uma VPN de Camada 3 usa um modelo de roteamento por pares entre roteadores locais de PE e CE que se conectam diretamente. Ou seja, sem precisar de vários saltos no backbone do provedor para conectar pares de roteadores PE e CE. Os roteadores PE distribuem informações de roteamento a todos os roteadores CE pertencentes à mesma VPN, com base no diferencial de rotas BGP, localmente e em toda a rede do provedor. Cada VPN tem sua própria tabela de roteamento para essa VPN, coordenada com as tabelas de roteamento nos roteadores de peer CE e PE. Os roteadores CE e PE têm tabelas VRF diferentes. Cada roteador CE tem apenas uma única tabela VRF porque as outras VPNs são invisíveis para o CE. Um roteador PE pode se conectar a mais de um roteador CE, de modo que o roteador PE tenha uma tabela geral de roteamento IP e uma tabela VRF para cada CE conectado com uma VPN.

A Figura 2 mostra a arquitetura geral de uma VPN de Camada 3.

Figura 2: Arquitetura VPN geral de Camada 3.

O roteador PE sabe qual tabela VRF usar para pacotes que chegam de sites remotos de VPN porque cada tabela VRF tem um ou mais atributos de comunidade estendidos associados ao hit. Os atributos da comunidade identificam a rota como pertencente a uma coleção específica de roteadores. O atributo da comunidade alvo de rota identifica uma coleção de locais (com mais precisão, a coleção de suas tabelas VRF) para as quais um roteador PE distribui rotas. O roteador PE usa o alvo de rota para importar as rotas de VPN remotas corretas em suas tabelas VRF.

A importação e exportação de rotas VPN entre sites VPN não é automática. Esse processo é controlado pelas polícias de roteamento BPG. As políticas de roteamento estabelecem as regras para a troca de informações de roteamento na rede MPLS do provedor de serviços e devem ser configuradas corretamente e mantidas quando a topologia da rede mudar.

O roteador PE classifica as rotas IPv4 anunciadas por um roteador CE peer e recebidas pelo roteador PE como rotas VPN-IPv4. Quando um roteador PE de entrada recebe rotas anunciadas de um roteador CE peer diretamente conectado, o roteador PE de entrada verifica a rota recebida contra a política de exportação VRF para essa VPN. Ou seja, o roteador PE de entrada decide quais roteadores pe remotos precisam saber sobre as rotas anunciadas. Este é um processo em duas etapas:

• Se a política de exportação estabelecida aceitar a rota, o roteador PE converte as informações no formato VPN-IPv4 adicionando o diferencial de rota ao endereço IPv4. Em seguida, o roteador PE anuncia a rota VPN-IPv4 para os roteadores PE remotos. A política de destino de exportação configurada da tabela VRF determina o valor da meta de rota anexada. As sessões do IBGP distribuem as rotas VNP-IPv4 pela rede principal do provedor de serviços.

• Se a política de exportação estabelecida não aceitar a rota, o roteador PE não exporta a rota para outros roteadores PE, mas o roteador PE usa a rota localmente. Isso acontece, por exemplo, quando dois roteadores CE na mesma VPN se conectam diretamente ao mesmo roteador PE para que o tráfego geral possa fluir de um site ce para outro.

Quando um roteador PE de saída do outro lado da rede de provedores de serviços recebe uma rota, o roteador PE de saída verifica a rota contra a política de importação do IBGP em vigor entre os roteadores PE. Se o roteador PE de saída aceitar a rota, o roteador PE de saída adiciona a rota à tabela de roteamento bgp.l3vpn.0. O roteador também verifica a rota contra a política de importação VRF para a VPN. Se a rota for aceita, o roteador PE de saída remove o distintivo de rotas e coloca a rota na tabela VRF correta. As tabelas VRF usam a convenção de nome de instância de roteamento.inet.0, de modo que "VPN A" geralmente configura a tabela como vpna.inet.0).