NAT estática en línea sobre VPN de capa 3 para borde empresarial
Acerca de este ejemplo
En este ejemplo se muestra cómo un proveedor de servicios puede proporcionar a los empleados de una empresa en diferentes redes acceso a servicios en la nube mediante el uso de NAT en línea desde las LAN de sus clientes a través del núcleo MPLS del proveedor de servicios a los servicios en la nube. El ejemplo consta de lo siguiente:
Tres enrutadores perimetrales de cliente (CE) que originan tráfico desde las LAN del cliente a los servicios en la nube.
Tres enrutadores perimetrales de proveedor (PE).
Servicios en la nube que podrían pertenecer a la empresa o al proveedor de servicios.
la red NAT en línea
Descripción general de la tecnología
La figura 2 ofrece una descripción general de la tecnología utilizada en este ejemplo.
la red de ejemplo de NAT en línea
Información general sobre el enrutamiento
El núcleo es un núcleo MPLS que utiliza:
RSVP como el protocolo de señalización que configura rutas de extremo a extremo.
Túneles de ruta de conmutación de etiquetas (LSP) entre los enrutadores de PE.
EBGP para distribuir rutas desde los enrutadores CE y los servicios en la nube a los enrutadores PE.
BGP multiprotocolo (MP–BGP) para intercambiar información de enrutamiento entre los enrutadores PE.
OSPF para proporcionar información de accesibilidad en el núcleo para permitir que BGP resuelva sus próximos saltos.
VPN de capa 3
Una VPN de capa 3 es un conjunto de sitios que comparten información de enrutamiento común y cuya conectividad está controlada por políticas. Las VPN de capa 3 permiten a los proveedores de servicios utilizar su núcleo IP para proporcionar servicios VPN a sus clientes.
El tipo de VPN de capa 3 en este ejemplo se denomina VPN BGP/MPLS porque BGP distribuye la información de enrutamiento VPN a través del núcleo del proveedor y MPLS reenvía el tráfico VPN a través del núcleo a los sitios VPN.
En este ejemplo, hay cuatro sitios asociados a la VPN de capa 3: tres sitios de clientes y un sitio de servicios en la nube. La VPN de capa 3 tiene una configuración radial. Los enrutadores PE1 y PE2 son los radios y se conectan a las redes del cliente. PE3 es el centro y se conecta a los servicios en la nube.
TDR en línea
En un dispositivo de la serie MX, puede usar NAT en línea en tarjetas de línea MPC. No necesita una interfaz de servicios dedicada, como un MS-MPC. La NAT en línea se aplica en el plano de reenvío, de manera similar a como se manejan los firewalls y las políticas en Junos OS. NAT en línea se ejecuta en interfaces de servicios en línea (si) que se basan en FPC y PIC.
Dado que no es necesario enviar paquetes a una tarjeta de servicios para su procesamiento, el enrutador de la serie MX puede lograr traducciones NAT de baja latencia y velocidad de línea. Aunque los servicios NAT en línea proporcionan un mejor rendimiento que con una tarjeta de servicios, su funcionalidad es más básica; NAT en línea solo admite NAT estática.
Hay dos tipos de NAT en línea:
Estilo de interfaz: un método basado en interfaz en el que los paquetes que llegan a una interfaz se envían a través de un conjunto de servicios. Se utiliza NAT de estilo de interfaz para aplicar NAT a todo el tráfico de una interfaz.
Estilo de salto siguiente: método basado en rutas que se suele utilizar cuando las instancias de enrutamiento reenvían paquetes desde una red específica o destinados a un destino específico. Las instancias de enrutamiento mueven el tráfico del cliente a una interfaz de servicio donde se aplica NAT al tráfico que coincide con la ruta.
Ambos métodos se utilizan en este ejemplo.
Requisitos
En este ejemplo se utilizan los siguientes componentes de hardware y software:
Enrutadores serie MX con concentradores de puertos modulares (MPC)
Junos OS versión 17.1R1 o superior
Configuración del núcleo
- Descripción general del núcleo
- Configuración de PE1
- Configuración de PE2
- Configuración de PE3
- Verificación de la configuración
Descripción general del núcleo
La configuración principal consiste en las interfaces físicas y de circuito cerrado y los protocolos de enrutamiento. El diseño del protocolo de enrutamiento incluye:
RSVP es el protocolo de señalización que configura rutas de extremo a extremo entre PE1 y PE3 y entre PE2 y PE3.
Los LSP MPLS proporcionan túneles entre PE1 y PE3 y entre PE2 y PE3.
OSPF proporciona información de accesibilidad en el núcleo para permitir que BGP resuelva sus próximos saltos.
MP-BGP admite VPN de capa 3 al permitir que los enrutadores PE intercambien información sobre las rutas que se originan y terminan en las VPN.
- Consideraciones de diseño de señalización de transporte principal
- Consideraciones de diseño del Protocolo de puerta de enlace interior (IGP)
Consideraciones de diseño de señalización de transporte principal
Los dispositivos PE utilizan LSP entre ellos para enviar tráfico de clientes a través del núcleo MPLS. En este diseño, consideramos los dos tipos de señalización más comunes para configurar las rutas de LSP de extremo a extremo: LDP y RSVP. Estamos utilizando RSVP como el protocolo de señalización que configura rutas de extremo a extremo.
En este ejemplo, MP-BGP distribuye la información de enrutamiento VPN a través del núcleo del proveedor y MPLS reenvía el tráfico VPN a través del núcleo a sitios VPN remotos.
Consideraciones de diseño del Protocolo de puerta de enlace interior (IGP)
Un IGP intercambia información de enrutamiento dentro de un sistema autónomo (AS). Estamos utilizando OSPF como IGP para la red central. Elegimos OSPF porque es fácil de configurar, no requiere una gran cantidad de planificación, tiene un resumen y filtrado flexibles, y puede escalar a redes grandes.
Configuración de PE1
Configuración de PE2
Configuración de PE3
Verificación de la configuración
Confirme y, a continuación, compruebe la configuración principal. Los siguientes ejemplos muestran la salida de PE3.
Configuración de la VPN de capa 3 en enrutadores PE
- Descripción general de VPN de capa 3
- Configuración de PE1
- Configuración de PE2
- Configuración de PE3
- Verificación de la configuración
Descripción general de VPN de capa 3
Estamos utilizando una VPN de capa 3 para separar y enrutar el tráfico de cada una de las LAN y servicios en la nube del cliente a través del núcleo. Hay cuatro sitios en la VPN: las tres LAN de cliente y los servicios en la nube.
Para distinguir las rutas de las LAN del cliente y los servicios en la nube en los enrutadores PE, estamos utilizando la instancia de enrutamiento virtual de enrutamiento y reenvío (VRF). Una instancia de enrutamiento VRF tiene una o más tablas de enrutamiento, una tabla de reenvío, las interfaces que utilizan la tabla de reenvío y las directivas y protocolos de enrutamiento que controlan lo que entra en la tabla de reenvío. Las tablas VRF se rellenan con rutas recibidas de los sitios CE y servicios en la nube, y con rutas recibidas de otros enrutadores PE en la VPN. Dado que cada sitio tiene su propia instancia de enrutamiento, cada sitio tiene tablas, reglas y políticas independientes.
En este ejemplo se utiliza una configuración de VPN radial. Los enrutadores PE1 y PE2 son los radios y representan las redes del cliente. PE3 es el centro y representa los servicios en la nube. Las políticas marcan el tráfico como concentrador o radio, y el marcado se utiliza para dirigir el tráfico a la instancia de enrutamiento VRF correcta.
Configuración de PE1
Configuración de PE2
Configuración de PE3
Verificación de la configuración
Para comprobar su configuración, confirme la configuración y, a continuación, haga lo siguiente:
Configuración de conexiones desde enrutadores CE y servicios en la nube a enrutadores PE
- Descripción general de las conexiones de enrutadores CE y servicios en la nube a enrutadores PE
- Configuración de la conexión entre CE1 y PE1
- Configuración de la conexión entre CE2 y PE1
- Configuración de la conexión entre CE3 y PE2
- Verificación de conexiones desde enrutadores CE y servicios en la nube
Descripción general de las conexiones de enrutadores CE y servicios en la nube a enrutadores PE
Estamos utilizando EBGP para el enrutamiento entre los enrutadores CE y PE1 y PE2 y entre los servicios en la nube y PE3. Los enrutadores CE utilizan una política de enrutamiento que coincide con la dirección de la LAN del cliente. Esta política se aplica como una política de exportación en el par EBGP, lo que hace que EBGP envíe estas direcciones a enrutadores PE. La misma configuración en el enrutador de servicios en la nube hace que sus rutas se envíen a PE3.
en la nube
Configuración de la conexión entre CE1 y PE1
En este ejemplo, estamos utilizando las interfaces de circuito cerrado en el enrutador para representar las LAN del cliente. Es por eso que las interfaces de circuito cerrado utilizan las direcciones IP de la LAN del cliente.
Configuración de CE1
Configuración de 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
}
}
}
}
}
Configuración de la conexión entre CE2 y PE1
En este ejemplo, estamos utilizando las interfaces de circuito cerrado en el enrutador para representar las LAN del cliente. Es por eso que las interfaces de circuito cerrado utilizan las direcciones IP de la LAN del cliente.
Configuración de CE2
Configuración de 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
}
}
}
}
}
Configuración de la conexión entre CE3 y PE2
En este ejemplo, estamos utilizando las interfaces de circuito cerrado en el enrutador para representar las LAN del cliente. Es por eso que las interfaces de circuito cerrado utilizan las direcciones IP de la LAN del cliente.
Configuración de CE3
Configuración de PE2
routing-instances {
Cust-C {
protocols {
bgp {
group to-Cust-C {
type external;
peer-as 65103
neighbor 10.0.50.2; ## CE3 interface address
}
}
}
}
}
Verificación de conexiones desde enrutadores CE y servicios en la nube
Configuración de NAT en línea
- Consideraciones de diseño de NAT en línea
- Configuración de NAT de origen en línea estilo salto siguiente en PE1
- Permitir que el tráfico de retorno de los servicios en la nube llegue a las LAN de los clientes
- Verificación de NAT en línea de estilo de salto siguiente
- Configuración de NAT en línea de estilo interfaz en PE2
- Verificar el estilo de interfaz TDR en línea
Consideraciones de diseño de NAT en línea
NAT en línea proporciona traducción de direcciones sin estado en enrutadores serie MX que tienen tarjetas de línea MPC. La ventaja de usar un servicio en línea es que no necesita una tarjeta de servicios dedicados y casi no afecta a la capacidad de reenvío ni a la latencia. Aunque los servicios en línea generalmente proporcionan un mejor rendimiento que usar una tarjeta de servicios, su funcionalidad tiende a ser más básica. Por ejemplo, NAT en línea solo admite NAT estática.
Estamos usando NAT estática de origen en este ejemplo de NAT en línea.
Tipos de TDR en línea
Hay dos tipos de NAT en línea:
Estilo de interfaz: un método basado en interfaz en el que los paquetes que llegan a una interfaz se envían a través de un conjunto de servicios. Utilice NAT de estilo interfaz para aplicar NAT a todo el tráfico que atraviesa una interfaz.
La NAT de estilo de interfaz es más fácil de configurar que la NAT de estilo de salto siguiente.
Estilo de salto siguiente: un método basado en rutas que se usa normalmente cuando las instancias de enrutamiento reenvían paquetes procedentes de una red específica o destinados a un destino específico a través del servicio en línea.
En este ejemplo se muestra cómo usar ambos métodos de NAT en línea de la siguiente manera:
PE1 usa NAT en línea basada en el próximo salto para el tráfico de las redes del cliente A y del cliente B a los servicios en la nube.
PE 2 utiliza NAT en línea basada en interfaz para el tráfico desde la red C del cliente a los servicios en la nube.
Configuración de NAT de origen en línea estilo salto siguiente en PE1
En esta sección se muestra cómo configurar la NAT en línea basada en rutas mediante interfaces si con conjuntos de servicios de estilo de salto siguiente.
En este ejemplo, la LAN del cliente A y la LAN del cliente B tienen subredes superpuestas. El enrutador PE1 diferencia el tráfico según la interfaz si- en la que llega el tráfico.
de NAT en línea de estilo de salto siguiente
En esta sección se utilizan los siguientes elementos de configuración:
Interfaz de servicio en línea: una interfaz virtual que reside en el motor de reenvío de paquetes de la MPC. Para acceder a los servicios, el tráfico entra y sale de las interfaces si- (service-inline).
Conjunto de servicios: define los servicios ejecutados e identifica qué interfaz en línea alimentará el tráfico dentro y fuera del conjunto de servicios. En esta sección se implementan conjuntos de servicios de estilo de salto siguiente, que utilizan un método basado en rutas, en el que se utilizan rutas estáticas para reenviar paquetes destinados a un destino específico a través del servicio en línea.
Regla NAT: utiliza una estructura if-then (como filtros de firewall) para definir condiciones de coincidencia y, a continuación, aplicar la traducción de direcciones al tráfico coincidente.
Grupo NAT: conjunto de direcciones IP definido por el usuario que la regla NAT utiliza para la traducción.
Instancia de enrutamiento del enrutador virtual (VR): incluye una ruta estática predeterminada que envía el tráfico del cliente a la interfaz si- donde se aplica NAT.
Filtros de firewall: redirige el tráfico entrante del cliente A y el cliente B a las instancias de enrutamiento de realidad virtual adecuadas.
Instancia de enrutamiento VRF: las interfaces si- externas se agregan a las instancias de enrutamiento VRF para los clientes A y B para que el tráfico saliente traducido al NAT pueda continuar en su ruta prevista a través de la VPN.
La figura 7 muestra el flujo de tráfico a través de PE1 para el tráfico NAT en línea proveniente de la LAN A del cliente y que va a los servicios en la nube.
en la nube
Para configurar la NAT en línea de estilo próximo salto en PE1:
Permitir que el tráfico de retorno de los servicios en la nube llegue a las LAN de los clientes
Cuando el tráfico de retorno de Servicios en la nube pasa por las interfaces de servicios, se elimina el direccionamiento NAT y el tráfico se envía a las instancias de enrutamiento de realidad virtual. Sin embargo, no hay una ruta a las LAN del cliente en las instancias de enrutamiento de realidad virtual, por lo que debemos agregarlas. Para ello, compartiremos rutas desde las instancias de enrutamiento de VRF a las instancias de enrutamiento de VR mediante grupos RIB.
Por ejemplo, para el tráfico a la LAN A del cliente, compartiremos rutas desde la tabla de enrutamiento Cust-A-VRF.inet.0 en la tabla de enrutamiento Cust-A-VR.inet.0. La figura 8 muestra el flujo de tráfico a través de PE1 para el tráfico NAT en línea proveniente de los servicios en la nube que van a la LAN A del cliente.
Antes de configurar el uso compartido de rutas en PE1, solo hay una ruta estática predeterminada en la tabla de enrutamiento 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 compartir rutas de la tabla de enrutamiento Cust-A-VRF.inet.0 con la tabla de enrutamiento Cust-A-VR.inet.0:
Después de configurar el uso compartido de rutas, una ruta de interfaz directa y una ruta BGP al cliente, se agregó una LAN a la tabla de enrutamiento 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
El tráfico de retorno ahora puede llegar a las LAN del cliente.
Verificación de NAT en línea de estilo de salto siguiente
Configuración de NAT en línea de estilo interfaz en PE2
Para el tráfico del cliente C, estamos utilizando NAT en línea de estilo de interfaz. En esta sección se muestra cómo configurar NAT en línea basada en interfaz, que usa una configuración más sencilla que la NAT de estilo del próximo salto.
de NAT de estilo interfaz
En esta sección se utilizan los siguientes elementos de configuración:
Interfaz de servicio en línea: una interfaz virtual que reside en el motor de reenvío de paquetes de la MPC. Para acceder a los servicios, el tráfico entra y sale de la interfaz si- (service-inline).
Conjunto de servicios: define los servicios prestados e identifica qué interfaces en línea alimentarán el tráfico dentro y fuera del conjunto de servicios. En esta sección se implementan conjuntos de servicios de estilo de interfaz, en los que los paquetes que llegan a una interfaz se envían a través de la interfaz de servicio en línea.
Regla NAT: utiliza una estructura if-then (similar a los filtros de firewall) para definir condiciones de coincidencia y, a continuación, aplicar la traducción de direcciones al tráfico coincidente.
Grupo NAT: conjunto de direcciones IP definido por el usuario que la regla NAT utiliza para la traducción.
Instancia de enrutamiento VRF: la interfaz si- se agrega a la instancia de enrutamiento VRF para el cliente C.
La figura 10 muestra el flujo de tráfico en PE2 para el tráfico enviado desde la LAN C del cliente a los servicios en la nube.
en la nube
La figura 11 muestra el flujo de tráfico en PE2 para el tráfico desde los servicios en la nube a la C LAN del cliente.
del cliente
Para configurar NAT en línea de estilo de interfaz en PE2:
Con esta configuración, el tráfico del cliente C entra en la interfaz en PE2 y se redirige a través de la interfaz de servicio al conjunto de servicios para la traducción NAT. A continuación, el tráfico se devuelve a la instancia de enrutamiento VRF y se puede enviar a través de la VPN como de costumbre.
Verificar el estilo de interfaz TDR en línea
Configuraciones completas del enrutador
Esta sección tiene la configuración completa de cada router.
- Configuración de PE1
- Configuración de PE2
- Configuración de PE3
- Configuración CE1
- Configuración CE2
- Configuración CE3
Configuración 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;
}
}
}
}
}
Configuración 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;
}
}
Configuración de 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
}
}
}
Configuración 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;
}
Configuración 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;
}
Configuración 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;
}