NAT estático em linha sobre VPNs de camada 3 para borda empresarial
Sobre este exemplo
Este exemplo mostra como um provedor de serviços pode dar aos funcionários da empresa em diferentes redes acesso a serviços de nuvem usando NAT em linha das LANs de seus clientes através do núcleo MPLS do provedor de serviços aos serviços de nuvem. O exemplo consiste no seguinte:
Três roteadores Customer Edge (CE) que originam o tráfego das LANs do cliente aos serviços de nuvem.
Roteadores de borda de três provedores (PE).
Serviços de nuvem que poderiam pertencer à empresa ou ao provedor de serviços.

Visão geral da tecnologia
A Figura 2 oferece uma visão geral da tecnologia usada neste exemplo.

Visão geral do roteamento
O núcleo é um núcleo MPLS que usa:
RSVP como o protocolo de sinalização que define caminhos de ponta a ponta.
Túneis de caminho comutada por rótulos (LSP) entre os roteadores PE.
EBGP para distribuir rotas dos roteadores CE e serviços de nuvem para roteadores PE.
BGP multiprotocol (MP-BGP) para trocar informações de roteamento entre os roteadores PE.
OSPF para fornecer informações de alcance no núcleo para permitir que o BGP resolva seus próximos saltos.
VPN de camada 3
Uma VPN de Camada 3 é um conjunto de sites que compartilham informações comuns de roteamento e cuja conectividade é controlada por políticas. As VPNs de camada 3 permitem que os provedores de serviços usem seu núcleo IP para fornecer serviços de VPN a seus clientes.
O tipo de VPN de Camada 3 neste exemplo é chamado de VPN BGP/MPLS porque o BGP distribui informações de roteamento VPN em todo o núcleo do provedor, e o MPLS encaminha o tráfego de VPN em todo o núcleo para os sites de VPN.
Neste exemplo, existem quatro sites conectados à VPN de Camada 3 — três sites de clientes e um site de serviços de nuvem. A VPN de Camada 3 tem uma configuração hub-and-spoke. Os roteadores PE1 e PE2 são os spokes, e eles se conectam às redes do cliente. O PE3 é o hub e se conecta aos serviços de nuvem.
NAT em linha
Em um dispositivo da Série MX, você pode usar NAT em linha em placas de linha MPC. Você não precisa de uma interface de serviços dedicada, como um MS-MPC. O NAT em linha é aplicado no plano de encaminhamento, semelhante à maneira como firewalls e policiais são tratados no Junos OS. O NAT em linha funciona em interfaces de serviços em linha (si) que são baseadas no FPC e PIC.
Como os pacotes não precisam ser enviados a uma placa de serviços para processamento, o roteador da Série MX pode alcançar taxa de linha, tradução de NAT de baixa latência. Embora os serviços NAT em linha ofereçam melhor desempenho do que usar uma placa de serviços, sua funcionalidade é mais básica; o NAT em linha oferece suporte apenas a NAT estático.
Existem dois tipos de NAT em linha:
Estilo de interface — um método baseado em interface, onde os pacotes que chegam a uma interface são enviados por um conjunto de serviços. Você usa o NAT no estilo de interface para aplicar NAT a todo o tráfego em uma interface.
Estilo next-hop — um método baseado em rota que normalmente é usado quando as instâncias de roteamento encaminham pacotes de uma rede específica ou destinados a um destino específico. As instâncias de roteamento movem o tráfego do cliente para uma interface de serviço onde o NAT é aplicado ao tráfego que corresponde à rota.
Ambos os métodos são usados neste exemplo.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
Roteadores da Série MX com Concentradores modulares de portas (MPCs)
Versão Junos OS 17.1R1 ou superior
Configuração do núcleo
- Visão geral do núcleo
- Configuração do PE1
- Configuração do PE2
- Configuração do PE3
- Verificando sua configuração
Visão geral do núcleo
A configuração do núcleo consiste nas interfaces físicas e de loopback e protocolos de roteamento. O projeto do protocolo de roteamento inclui:
RSVP é o protocolo de sinalização que define caminhos de ponta a ponta entre PE1 e PE3 e entre PE2 e PE3.
Os LSPs MPLS fornecem túneis entre PE1 e PE3 e entre PE2 e PE3.
O OSPF fornece informações de acessibilidade no núcleo para permitir que o BGP resolva seus próximos saltos.
O MP-BGP oferece suporte a VPNs de Camada 3, permitindo que os roteadores PE troquem informações sobre rotas originadas e terminais nas VPNs.

- Considerações de design de sinalização de transporte principal
- Considerações de design do Interior Gateway Protocol (IGP)
Considerações de design de sinalização de transporte principal
Os dispositivos pe usam LSPs entre eles para enviar tráfego do cliente pelo núcleo MPLS. Nesse design, consideramos os dois tipos de sinalização mais comuns para configurar os caminhos de LSP de ponta a ponta — LDP e RSVP. Estamos usando o RSVP como o protocolo de sinalização que define caminhos de ponta a ponta.
Neste exemplo, o MP-BGP distribui informações de roteamento VPN em todo o núcleo do provedor, e o MPLS encaminha o tráfego de VPN em todo o núcleo para sites de VPN remotos.
Considerações de design do Interior Gateway Protocol (IGP)
Um IGP troca informações de roteamento dentro de um sistema autônomo (AS). Estamos usando o OSPF como IGP para a rede central. Escolhemos o OSPF porque é fácil de configurar, não requer uma grande quantidade de planejamento, tem resumo e filtragem flexíveis, e pode ser dimensionado para grandes redes.
Configuração do PE1
Configuração do PE2
Configuração do PE3
Verificando sua configuração
Confirme e verifique a configuração do núcleo. Os exemplos abaixo mostram a saída do PE3.
Configuração da VPN de camada 3 em roteadores PE
- Visão geral da VPN da camada 3
- Configuração do PE1
- Configuração do PE2
- Configuração do PE3
- Verificando sua configuração
Visão geral da VPN da camada 3
Estamos usando uma VPN de Camada 3 para separar e rotear o tráfego de cada uma das LANs do cliente e serviços de nuvem em todo o núcleo. Existem quatro sites na VPN — as três LANs de clientes e serviços de nuvem.
Para distinguir rotas para as LANs do cliente e os serviços de nuvem nos roteadores PE, estamos usando a instância de roteamento e encaminhamento virtual (VRF). Uma instância de roteamento VRF tem uma ou mais tabelas de roteamento, uma tabela de encaminhamento, as interfaces que usam a tabela de encaminhamento e as políticas e protocolos de roteamento que controlam o que entra na tabela de encaminhamento. As tabelas VRF são povoadas com rotas recebidas dos locais ce e serviços de nuvem, e com rotas recebidas de outros roteadores PE na VPN. Como cada site tem sua própria instância de roteamento, cada site tem tabelas, regras e políticas separadas.
Este exemplo usa uma configuração de VPN hub-and-spoke. Os roteadores PE1 e PE2 são os spokes, e eles representam as redes do cliente. O PE3 é o hub, e representa os serviços de nuvem. As políticas marcam o tráfego como um hub ou um spoke, e a marcação é usada para direcionar o tráfego para a instância de roteamento VRF correta.

Configuração do PE1
Configuração do PE2
Configuração do PE3
Verificando sua configuração
Para verificar sua configuração, confirmar a configuração e, em seguida, fazer o seguinte:
Configuração de conexões de roteadores CE e serviços de nuvem para roteadores PE
- Conexões de roteadores CE e serviços de nuvem para roteadores PE Visão geral
- Configurando a conexão entre CE1 e PE1
- Configurando a conexão entre CE2 e PE1
- Configurando a conexão entre CE3 e PE2
- Verificação de conexões de roteadores CE e serviços de nuvem
Conexões de roteadores CE e serviços de nuvem para roteadores PE Visão geral
Estamos usando o EBGP para roteamento entre os roteadores CE e PE1 e PE2 e entre serviços de nuvem e PE3. Os roteadores CE usam uma política de roteamento que corresponde ao endereço da LAN do cliente. Você aplica essa política como política de exportação no peer EBGP, o que faz com que o EBGP envie esses endereços aos roteadores PE. A mesma configuração no roteador de serviços de nuvem faz com que suas rotas sejam enviadas para o PE3.

Configurando a conexão entre CE1 e PE1
Neste exemplo, estamos usando as interfaces de loopback no roteador para representar as LANs dos clientes. É por isso que as interfaces de loopback usam os endereços IP da LAN do cliente.
Configuração do CE1
Configuração do PE1
routing-instances { Cust-A-VRF { protocols { bgp { group to-Cust-A { type external; peer-as 65101; neighbor 10.0.1.2; ## CE1 interface address } } } } }
Configurando a conexão entre CE2 e PE1
Neste exemplo, estamos usando as interfaces de loopback no roteador para representar as LANs dos clientes. É por isso que as interfaces de loopback usam os endereços IP da LAN do cliente.
Configuração do CE2
Configuração do PE1
routing-instances { Cust-B-VRF { protocols { bgp { group to-Cust-B { type external; peer-as 65102 neighbor 10.0.1.4; ## CE2 interface address } } } } }
Configurando a conexão entre CE3 e PE2
Neste exemplo, estamos usando as interfaces de loopback no roteador para representar as LANs dos clientes. É por isso que as interfaces de loopback usam os endereços IP da LAN do cliente.
Configuração do CE3
Configuração do PE2
routing-instances { Cust-C { protocols { bgp { group to-Cust-C { type external; peer-as 65103 neighbor 10.0.50.2; ## CE3 interface address } } } } }
Verificação de conexões de roteadores CE e serviços de nuvem
Configuração do NAT em linha
- Considerações de design de NAT em linha
- Configuração do NAT de origem inline estilo Next-Hop no PE1
- Permitindo que o tráfego de retorno dos serviços de nuvem chegue às LANs dos clientes
- Verificando o nat em linha estilo next-hop
- Configuração do NAT em linha estilo interface no PE2
- Verificando o estilo de interface nat em linha
Considerações de design de NAT em linha
O NAT em linha oferece tradução de endereços stateless em roteadores da Série MX que possuem placas de linha MPC. O benefício de usar um serviço em linha é que você não precisa de uma placa de serviços dedicada e quase não há impacto na capacidade ou latência do encaminhamento. Embora os serviços em linha geralmente ofereçam melhor desempenho do que usar uma placa de serviços, suas funcionalidades tendem a ser mais básicas. Por exemplo, o NAT em linha oferece suporte apenas a NAT estático.
Estamos usando NAT estático de origem neste exemplo de NAT em linha.
Tipos de NAT em linha
Existem dois tipos de NAT em linha:
Estilo de interface — um método baseado em interface, onde os pacotes que chegam a uma interface são enviados por um conjunto de serviços. Use o NAT no estilo de interface para aplicar NAT a todo tráfego que atravessa uma interface.
O NAT no estilo de interface é mais simples de configurar do que o NAT estilo next-hop.
Estilo next-hop — um método baseado em rota que normalmente é usado quando as instâncias de roteamento encaminham pacotes provenientes de uma rede específica ou destinados a um destino específico por meio do serviço em linha.
Este exemplo mostra como usar ambos os métodos de NAT em linha da seguinte forma:
O PE1 usa o NAT de linha baseada em próximo salto para tráfego desde as redes Customer A e Customer B até serviços de nuvem.
O PE 2 usa o NAT em linha baseado em interface para tráfego desde a rede Customer C até os serviços de nuvem.
Configuração do NAT de origem inline estilo Next-Hop no PE1
Esta seção mostra como configurar o NAT em linha baseado em rota usando interfaces si com conjuntos de serviço no estilo next-hop.
Neste exemplo, a LAN do cliente A e a LAN B do cliente têm sub-redes sobrepostas. O roteador PE1 diferencia o tráfego de acordo com qual interface si- o tráfego chega.

Os itens de configuração a seguir são usados nesta seção:
Interface de serviço em linha — uma interface virtual que reside no Mecanismo de encaminhamento de pacotes do MPC. Para acessar serviços, o tráfego entra e sai das interfaces si- (serviço em linha).
Conjunto de serviços — define o(s) serviço(s) executado e identifica qual interface em linha alimentará o tráfego dentro e fora do conjunto de serviços. Esta seção implementa conjuntos de serviços no estilo next-hop, que usa um método baseado em rota, onde rotas estáticas são usadas para encaminhar pacotes destinados a um destino específico através do serviço em linha.
A regra nat — usa uma estrutura if-then (como filtros de firewall) para definir condições de correspondência e, em seguida, aplicar a tradução de endereço ao tráfego correspondente.
Grupo DE NAT — um conjunto definido pelo usuário de endereços IP que a regra NAT usa para tradução.
A instância de roteamento de roteador virtual (VR) inclui uma rota estática padrão que envia o tráfego do cliente para a interface si onde o NAT é aplicado.
Filtros de firewall— redireciona o tráfego de entrada do Cliente A e do Cliente B para as instâncias de roteamento VR apropriadas.
Instância de roteamento VRF — as interfaces si externas são adicionadas às instâncias de roteamento VRF para o Cliente A e o Cliente B para que o tráfego de saída traduzido por NAT possa continuar em seu caminho desejado através da VPN.
A Figura 7 mostra o fluxo de tráfego por PE1 para tráfego NAT em linha vindo da LAN do cliente A e indo para serviços de nuvem.

Para configurar o NAT em linha de estilo next-hop no PE1:
Permitindo que o tráfego de retorno dos serviços de nuvem chegue às LANs dos clientes
Quando o tráfego de retorno dos serviços de nuvem passa pelas interfaces de serviços, o endereçamento de NAT é removido e o tráfego é enviado para as instâncias de roteamento VR. No entanto, não há rota para as LANs dos clientes nas instâncias de roteamento VR, por isso precisamos adicioná-las. Para isso, compartilharemos rotas das instâncias de roteamento VRF para as instâncias de roteamento VR usando grupos RIB.
Por exemplo, para tráfego para o Cliente A LAN, compartilharemos rotas da tabela de roteamento Cust-A-VRF.inet.0 na tabela de roteamento Cust-A-VR.inet.0. A Figura 8 mostra o fluxo de tráfego por PE1 para tráfego NAT em linha proveniente de serviços de nuvem que vão para a LAN do cliente A.

Antes de configurarmos o compartilhamento de rotas no PE1, há apenas uma rota estática padrão na tabela de roteamento Cust-A-VR.inet.0:
host@PE1> show route table Cust-A-VR.inet.0 Cust-A-VR.inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 02:10:53 > via si-0/0/0.1
Para compartilhar rotas da tabela de roteamento Cust-A-VRF.inet.0 com a tabela de roteamento Cust-A-VR.inet.0:
Depois de configurarmos o compartilhamento de rotas, uma rota de interface direta e uma rota BGP para o cliente A LAN foram adicionadas à tabela de roteamento Cust-A-VR.inet.0:
host@PE1> show route table Cust-A-VR.inet.0 Cust-A-VR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 02:26:20 > via si-0/0/0.1 10.0.1.0/24 *[Direct/0] 00:00:50 > via xe-0/0/0.0 10.250.100.101/32 *[BGP/170] 00:00:50, localpref 100 AS path: 65101 I, validation-state: unverified > to 10.0.1.2 via xe-0/0/0.0
O tráfego de retorno agora pode chegar às LANs do cliente.
Verificando o nat em linha estilo next-hop
Configuração do NAT em linha estilo interface no PE2
Para tráfego do Cliente C, estamos usando NAT em linha estilo interface. Esta seção mostra como configurar o NAT em linha baseado em interface, que usa uma configuração mais simples do que o NAT estilo next-hop.

Os itens de configuração a seguir são usados nesta seção:
Interface de serviço em linha — uma interface virtual que reside no Mecanismo de encaminhamento de pacotes do MPC. Para acessar serviços, o tráfego entra e sai da interface si- (serviço em linha).
Conjunto de serviços — define o(s) serviço(s) executado e identifica qual(s) interface(s) em linha vai alimentar o tráfego dentro e fora do conjunto de serviços. Esta seção implementa conjuntos de serviços no estilo de interface, onde os pacotes que chegam a uma interface são enviados pela interface de serviço em linha.
A regra NAT — usa uma estrutura if-then (semelhante a filtros de firewall) para definir condições de correspondência e, em seguida, aplicar a tradução de endereços ao tráfego correspondente.
Grupo DE NAT — um conjunto definido pelo usuário de endereços IP que a regra NAT usa para tradução.
Instância de roteamento VRF — a interface si é adicionada à instância de roteamento VRF para o Cliente C.
A Figura 10 mostra o fluxo de tráfego no PE2 para tráfego enviado da LAN do cliente C para serviços de nuvem.

A Figura 11 mostra o fluxo de tráfego no PE2 para tráfego, desde serviços de nuvem até a LAN C do cliente.

Para configurar o estilo de interface em linha NAT no PE2:
Com essa configuração em vigor, o tráfego do Cliente C entra na interface no PE2, é redirecionado pela interface de serviço para o conjunto de serviços para tradução de NAT. O tráfego é então devolvido à instância de roteamento VRF e pode ser enviado através da VPN como de costume.
Verificando o estilo de interface nat em linha
Configurações completas do roteador
Esta seção tem a configuração completa de cada roteador.
- Configuração de PE1
- Configuração de PE2
- Configuração do PE3
- Configuração do CE1
- Configuração do CE2
- Configuração do CE3
Configuração de PE1
## Configuring the Core interfaces { xe-0/0/2 { description "Outside to PE3"; unit 0 { family inet { address 172.16.1.1/24; } family mpls; ## allows interface to support MPLS protocol traffic } } lo0 { unit 0 { family inet { address 10.250.1.1/32; } } } } protocols { rsvp { interface xe-0/0/2.0; } mpls { no-cspf; label-switched-path PE1toPE3 { to 10.250.1.3; ## PE3 loopback address } interface xe-0/0/2.0; ## core-facing interface } bgp { group IBGP { type internal; local-address 10.250.1.1; neighbor 10.250.1.3; ## PE3 loopback address } } ospf { area 0.0.0.0 { interface xe-0/0/2.0; ## core-facing interface interface lo0.0; } } } routing-options { autonomous-system 65000; } policy-options { policy-statement LB { ## load balancing policy then { load-balance per-packet; ## actually applied per flow } } routing-options { forwarding-table { ## adds the LB policy to the forwarding table export LB; } ## Configuring the Layer 3 VPN interfaces { xe-0/0/0 { description "Inside to CE1_Cust-A"; unit 0 { family inet { address 10.0.1.1/24; } } } xe-0/0/1 { description "Inside to CE1_Cust-B"; unit 0 { family inet { address 10.0.1.2/24; } } } } policy-options { policy-statement CustA-to-CloudSvcs { term 1 { from protocol static; then { community add SpokeA; ## Add SpokeA tag when BGP exports route accept; } } term 2 { then reject; } } policy-statement CustB-to-CloudSvcs { term 1 { from protocol static; then { community add SpokeB; ## Add SpokeB tag when BGP exports route accept; } } term 2 { then reject; } } policy-statement from-CloudSvcs { ## add routes received with Hub tag to routing table term 1 { from community Hub; then accept; } term 2 { then reject; } } routing-instances { Cust-A-VRF { instance-type vrf; interface xe-0/0/0.0; route-distinguisher 10.250.1.1:1; vrf-import from-CloudSvcs; vrf-export CustA-to-CloudSvcs; vrf-table-label; } Cust-B-VRF { instance-type vrf; interface xe-0/0/1.0; route-distinguisher 10.250.1.1:2; vrf-import from-CloudSvcs; vrf-export CustB-to-CloudSvcs; vrf-table-label; } } protocols { bgp { group IBGP { family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI unicast; } } } ## Configuring the Connection to CE1 interfaces { xe-0/0/1 { description Cust-B_to_PE1; unit 0 { family inet { address 10.0.1.4/24; } } } lo0 { unit 0 { family inet { address 10.250.100.102/32; } } } } ## Configuring the Connection to CE2 routing-instances { Cust-B-VRF { protocols { bgp { group to-Cust-B { type external; peer-as 65102 neighbor 10.0.1.4; ## CE2 interface address } } } } } ## Configuring Next-hop Style Inline NAT chassis { fpc 0 { pic 0 { inline-services { bandwidth 1g; } } } } interfaces { si-0/0/0 { unit 1 { ## Customer A traffic family inet; ## causes NAT to be applied to IPv4 traffic service-domain inside; ## traffic from customer A LAN to core } unit 2 { ## Customer A traffic family inet; service-domain outside; ## customer A traffic from core to customer LAN } unit 3 { ## Customer B traffic family inet; service-domain inside; ## traffic from customer B LAN to core } unit 4 { ## Customer B traffic family inet; service-domain outside; ## customer B traffic from core to customer LAN } services { nat { pool A { ## applied to customer A traffic address 192.0.2.0/24; } pool B { ## applied to customer B traffic address 198.51.100.0/24; } services { nat { rule SRC-NAT-A { ## applied to traffic from customer A match-direction input; ## direction from which traffic is received term r1 { from { source-address { 10.250.100.0/24; ## from customer A } } then { translated { source-pool A; translation-type { basic-nat44; ## type of one-to-one static NAT } } } } } rule SRC-NAT-B { ## applied to traffic from customer B match-direction input; term r1 { from { source-address { 10.250.100.0/24; ## from customer B } } then { translated { source-pool B; translation-type { basic-nat44; ## type of one-to-one static NAT } } } } } services { service-set NH-STYLE-SS-NAT_A { ## applied to Customer A traffic nat-rules SRC-NAT-A; next-hop-service { inside-service-interface si-0/0/0.1; outside-service-interface si-0/0/0.2; } } service-set NH-STYLE-SS-NAT_B { ## applied to Customer B traffic nat-rules SRC-NAT-B; next-hop-service { inside-service-interface si-0/0/0.3; outside-service-interface si-0/0/0.4; } } routing-instances { Cust-A-VR { instance-type virtual-router; interface si-0/0/0.1; ## Cust A inside service interface routing-options { static { route 0.0.0.0/0 next-hop si-0/0/0.1; ## incoming Cust A traffic to si } } } Cust-B-VR { instance-type virtual-router; interface si-0/0/0.3; ## Cust B inside service interface routing-options { static { route 0.0.0.0/0 next-hop si-0/0/0.3; ## incoming Cust B traffic to si } } } } firewall { filter CustA-to-NAT-VR { term 1 { from { source-address { ## traffic from Customer A network 10.250.100.0/24; } } then { routing-instance Cust-A-VR; ## sends matching traffic to this RI } } term 2 { then accept; } } filter CustB-to-NAT-VR { term 1 { from { source-address { ## traffic from Customer B network 10.250.100.0/24; } } then { routing-instance Cust-B-VR; ## sends matching traffic to this RI } } term 2 { then accept; } interfaces { xe-0/0/0 { ## to Customer A unit 0 { family inet { filter { input CustA-to-NAT-VR; } } } } routing-instances { Cust-A-VRF { interface si-0/0/0.2; } Cust-B-VRF { interface si-0/0/0.4; } } ## Allow return traffic from Cloud Services policy-options { policy-statement leak-to-Cust-A-VR { ## share matching route with Cust-A-VR term 1 { from { route-filter 10.250.100.0/24 orlonger; ## match routes to Cust LAN } then accept; } term 2 { from protocol direct; ## match interface routes then accept; } term 3 { then reject; } } policy-statement leak-to-Cust-B-VR { ## share matching route with Cust-B-VR term 1 { from { route-filter 10.250.100.0/24 orlonger; ## match routes to Cust LAN } then accept; } term 2 { from protocol direct; ## match interface routes then accept; } term 3 { then reject; } } routing-options { rib-groups { Cust-A_leak-VRF-to-VR { ## share routes from A-VRF to A-VR import-rib [ Cust-A-VRF.inet.0 Cust-A-VR.inet.0 ]; import-policy leak-to-Cust-A-VR; } Cust-B_leak-VRF-to-VR { ## share routes from B-VRF to B-VR import-rib [ Cust-B-VRF.inet.0 Cust-B-VR.inet.0 ]; import-policy leak-to-Cust-B-VR; } routing-instances { Cust-A-VRF { routing-options { interface-routes { ## sharing interface routes with A-VR rib-group inet Cust-A_leak-VRF-to-VR; } } protocols { bgp { group to-Cust-A { family inet { unicast { ## sharing Cust-A network with A-VR rib-group Cust-A_leak-VRF-to-VR; } } } } }
Configuração de PE2
## Configuring the Corre interfaces { xe-0/0/0 { description "Outside to PE3"; unit 0 { family inet { address 172.17.1.1/24; } family mpls; ## allows interface to support MPLS protocol traffic } } lo0 { unit 0 { family inet { address 10.250.1.2/32; } } } } protocols { rsvp { interface xe-0/0/0.0; } mpls { no-cspf; label-switched-path PE2toPE3 { to 10.250.1.3; ## PE3 loopback address } interface xe-0/0/0.0 ## core-facing interface } bgp { group IBGP { type internal; local-address 10.250.1.2; ## local loopback address family inet { unicast; } neighbor 10.250.1.3; ## lo0 address of PE3 } } ospf { area 0.0.0.0 { interface xe-0/0/0.0; interface lo0.0; } } } routing-options { autonomous-system 65000; } policy-options { policy-statement LB { ## load balancing policy then { load-balance per-packet; ## actually applied per flow } } routing-options { forwarding-table { ## adds the LB policy to the forwarding table export LB; } policy-options { policy-statement CustA-to-CloudSvcs { term 1 { from protocol static; then { community add SpokeA; ## Add SpokeA tag when BGP exports route accept; } } term 2 { then reject; } } policy-statement CustB-to-CloudSvcs { term 1 { from protocol static; then { community add SpokeB; ## Add SpokeB tag when BGP exports route accept; } } term 2 { then reject; } } policy-statement from-CloudSvcs { ## add routes received with Hub tag to routing table term 1 { from community Hub; then accept; } term 2 { then reject; } } routing-instances { Cust-A-VRF { instance-type vrf; interface xe-0/0/0.0; route-distinguisher 10.250.1.1:1; vrf-import from-CloudSvcs; vrf-export CustA-to-CloudSvcs; vrf-table-label; } Cust-B-VRF { instance-type vrf; interface xe-0/0/1.0; route-distinguisher 10.250.1.1:2; vrf-import from-CloudSvcs; vrf-export CustB-to-CloudSvcs; vrf-table-label; } } protocols { bgp { group IBGP { family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI unicast; } } } ## Configuring the Layer 3 VPN interfaces { xe-0/0/3 { description "Inside to CE1_Cust-C"; unit 0 { family inet { address 10.0.50.1/24; } } } } policy-options { policy-statement CustC-to-CloudSvcs { ## Add SpokeC tag when BGP exports route term 1 { from protocol static; then { community add SpokeC; accept; } } term 2 { then reject; } } policy-statement from-CloudSvcs { ## add routes received with Hub tag to routing table term 1 { from community Hub; then accept; } term 2 { then reject; } } routing-instances { Cust-C { instance-type vrf; interface xe-0/0/3.0; route-distinguisher 10.250.1.2:3; vrf-import from-CloudSvcs; vrf-export CustC-to-CloudSvcs; vrf-table-label; } } protocols { bgp { group IBGP { family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI unicast } } } ## Configuring the Connection to CE3 routing-instances { Cust-C { protocols { bgp { group to-Cust-C { type external; peer-as 65103 neighbor 10.0.50.2; ## CE3 interface address } } } } } ## Configuring Interface-Style Inline NAT chassis { fpc 0 { pic 0 { inline-services { bandwidth 1g; } } } } interfaces { si-0/0/0 { unit 0 { family inet; ## protocol family that will need NAT services } } } services { nat { pool C { address 203.0.113.0/24; } } } services { nat { rule SRC-NAT-C { ## applied to traffic from Customer C match-direction input; ## direction from which traffic is received term r1 { from { source-address { 10.250.100.0/24; ## customer C } } then { translated { source-pool C; translation-type { basic-nat44; ## type of one-to-one static NAT } } } } } } services { service-set INT-STYLE-SS-NAT_C { nat-rules SRC-NAT-C; interface-service { ## defines that this is an interface-style service set service-interface si-0/0/0.0; } } interfaces { xe-0/0/3{ unit 0 { family inet { service { input { service-set INT-STYLE-SS-NAT_C; } output { service-set INT-STYLE-SS-NAT_C; } } } } } } routing-instances { Cust-C { interface si-0/0/0.0; } }
Configuração do PE3
## Configuring the Core interfaces { xe-0/0/0 { description "to PE1"; unit 0 { family inet { address 172.16.1.2/24; } family mpls; ## allows interface to support MPLS protocol traffic } } xe-0/0/1 { description "to PE2"; unit 0 { family inet { address 172.17.1.2/24; } family mpls; ## allows interface to support MPLS protocol traffic } } lo0 { unit 0 { family inet { address 10.250.1.3/32; } } } } protocols { rsvp { interface xe-0/0/0.0; interface xe-0/0/1.0; } mpls { no-cspf; label-switched-path PE3toPE1 { to 10.250.1.1; ## PE1 loopback address } label-switched-path PE3toPE2 { to 10.250.1.2; ## PE2 loopback address } interface xe-0/0/0.0; ## core-facing interface interface xe-0/0/1.0; ## core-facing interface } bgp { group IBGP { type internal; local-address 10.250.1.3; ## local loopback address family inet { unicast; } neighbor 10.250.1.1; ## lo0 address of spoke router PE1 neighbor 10.250.1.2; ## lo0 address of spoke router PE2 } } ospf { area 0.0.0.0 { interface xe-0/0/0.0; interface xe-0/0/1.0; interface lo0.0; } } } routing-options { autonomous-system 65000; } policy-options { policy-statement LB { ## load balancing policy then { load-balance per-packet; ## actually applied per session } } routing-options { forwarding-table { ## adds the LB policy to the forwarding table export LB; } ## Configuring the Layer 3 VPN interfaces { xe-0/0/2 { description "PE3 to CloudSvcs"; unit 0 { family inet { address 192.168.1.1/24; } } } } policy-options { policy-statement from-Cust { ## add routes with hub tag to routing table term 1 { from community [ SpokeA SpokeB SpokeC ]; then accept; } } policy-statement to-Cust { ## add hub tag when BGP exports route term 1 { from protocol bgp; then { community add Hub; accept; } } } routing-instances { CloudSvcs { instance-type vrf; interface xe-0/0/2.0; route-distinguisher 10.250.1.3:100; ## PE3 vrf-import from-Cust; vrf-export to-Cust; } } protocols { bgp { group IBGP { family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI unicast } } }
Configuração do CE1
interfaces { xe-0/0/0 { description Cust-A_to_PE1; unit 0 { family inet { address 10.0.1.2/24; } } } lo0 { unit 0 { family inet { address 10.250.100.101/32; } } } } policy-options { policy-statement CustA-to-PE1 { term 1 { from { route-filter 10.250.100.101/32 exact; } then accept; } term 2 { then reject; } } } protocols { bgp { group to-PE1 { type external; export CustA-to-PE1; ## BGP advertises routes to the L3VPN peer-as 65000; neighbor 10.0.1.1; ## PE1 interface address } } } routing-options { autonomous-system 65101; }
Configuração do CE2
interfaces { xe-0/0/1 { description Cust-B_to_PE1; unit 0 { family inet { address 10.0.1.4/24; } } } lo0 { unit 0 { family inet { address 10.250.100.102/32; } } } } policy-options { policy-statement CustB-to-PE1 { term 1 { from { route-filter 10.250.100.102/32 exact; } then accept; } term 2 { then reject; } } } protocols { bgp { group to-PE1 { type external; export CustB-to-PE1; peer-as 65000; neighbor 10.0.1.2; ## PE1 interface address } } } routing-options { autonomous-system 65102; }
Configuração do CE3
interfaces { xe-0/0/2 { description Cust-C_to_PE2; unit 0 { family inet { address 10.0.50.2/24; } } } lo0 { unit 0 { family inet { address 10.250.100.103/32; } } } } policy-options { policy-statement CustC-to-PE2 { term 1 { from { route-filter 10.250.100.103/32 exact; } then accept; } term 2 { then reject; } } } protocols { bgp { group to-PE2 { type external; export CustC-to-PE2; peer-as 65000; neighbor 10.0.50.1; ## PE2 interface address } } } routing-options { autonomous-system 65103; }