Ayúdenos a mejorar su experiencia.

Háganos saber su opinión.

¿Podría dedicar dos minutos de su tiempo a completar una encuesta?

close
keyboard_arrow_left
list Table of Contents

¿Fue útil esta traducción automática?

starstarstarstarstar
Go to English page
DESCARGO DE RESPONSABILIDAD:

Esta página será traducida por software de traducción automática de terceros. Si bien nos hemos esforzado por proporcionar una traducción de calidad, Juniper Networks no puede garantizar su corrección. En caso de duda respecto a la exactitud de la información que ofrece esta traducción, consulte la versión en inglés. El PDF descargable está disponible solo en inglés.

NAT estática en línea sobre VPN de capa 3 para borde empresarial

date_range 02-Aug-23

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.

Figura 1: Descripción general de Inline NAT Network Overview 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.

Figura 2: Descripción general de Inline NAT Example Network Overview 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

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.

Figura 3: • Interfaces principales y enrutamiento • Core Interfaces and Routing

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

  1. Configure la interfaz física orientada al núcleo y la interfaz de circuito cerrado.
    content_copy zoom_out_map
        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;
                    }
                }
            }
        }
    
  2. Configure los protocolos de enrutamiento del núcleo en la interfaz orientada al núcleo (xe-0/0/2.0).
    • Habilite RSVP.

    • Habilite MPLS en la interfaz orientada al núcleo para permitir que MPLS cree una etiqueta MPLS para la interfaz.

    • Configure un túnel LSP MPLS de PE1 a PE3.

    • Configure IBGP y agregue la dirección de circuito cerrado de PE3 como vecino.

    • Configure OSPF y agregue la interfaz orientada al núcleo y la interfaz de circuito cerrado al área 0.

    Se recomienda agregar la instrucción a la configuración de MPLS para deshabilitar el no-cspf cálculo del LSP de ruta restringida. CSPF está habilitado de forma predeterminada, pero es una práctica recomendada desactivarlo cuando no es necesario.

    content_copy zoom_out_map
    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;
            }
        }
    }
    
  3. Configure el sistema autónomo.
    content_copy zoom_out_map
    routing-options {
        autonomous-system 65000;
    }
    
  4. Configure y aplique el equilibrio de carga por flujo.
    content_copy zoom_out_map
    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;
    }
    

Configuración de PE2

  1. Configure la interfaz física orientada al núcleo y la interfaz de circuito cerrado.
    content_copy zoom_out_map
    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;
                }
            }
        }
    }
    
  2. Configure los protocolos de enrutamiento del núcleo en la interfaz orientada al núcleo (xe-0/0/0.0).
    • Habilite RSVP.

    • Configure un túnel LSP MPLS de PE2 a PE3.

    • Habilite MPLS en la interfaz orientada al núcleo para permitir que MPLS cree una etiqueta MPLS para la interfaz.

    • Configure IBGP y agregue la dirección de circuito cerrado de PE3 como vecino.

    • Configure OSPF y agregue la interfaz orientada al núcleo y la interfaz de circuito cerrado al área 0.

    Se recomienda agregar la instrucción a la configuración de MPLS para deshabilitar el no-cspf cálculo del LSP de ruta restringida. CSPF está habilitado de forma predeterminada, pero es una práctica recomendada desactivarlo cuando no es necesario.

    content_copy zoom_out_map
    protocols {
        rsvp {
            interface xe-0/0/0.0; ## core-facing interface
        }
        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;
            }
        }
    }
    
  3. Configure el sistema autónomo.
    content_copy zoom_out_map
    routing-options {
        autonomous-system 65000;
    }
    
  4. Configure y aplique el equilibrio de carga por flujo.
    content_copy zoom_out_map
    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;
    }
    

Configuración de PE3

  1. Configure las interfaces físicas orientadas al núcleo y la interfaz de circuito cerrado.
    content_copy zoom_out_map
    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;
                }
            }
        }
    }
    
  2. Configure los protocolos de enrutamiento principales en las interfaces orientadas al núcleo (xe-0/0/0.0 y xe-0/0/1.0).
    • Habilite RSVP.

    • Habilite MPLS en la interfaz orientada al núcleo para permitir que MPLS cree una etiqueta MPLS para la interfaz.

    • Configure un túnel LSP de MPLS de PE3 a PE1 y de PE3 a PE2.

    • Configure IBGP y agregue las direcciones de circuito cerrado PE1 y PE3 como vecinos.

    • Configure OSPF y agregue la interfaz orientada al núcleo y la interfaz de circuito cerrado al área 0.

    Se recomienda agregar la instrucción a la configuración de MPLS para deshabilitar el no-cspf cálculo del LSP de ruta restringida. CSPF está habilitado de forma predeterminada, pero es una práctica recomendada desactivarlo cuando no es necesario.

    content_copy zoom_out_map
    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;
            }
        }
    }
    
  3. Configure el sistema autónomo.
    content_copy zoom_out_map
    routing-options {
        autonomous-system 65000;
    }
    
  4. Configure y aplique el equilibrio de carga por flujo.
    content_copy zoom_out_map
    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;
    }
    

Verificación de la configuración

Confirme y, a continuación, compruebe la configuración principal. Los siguientes ejemplos muestran la salida de PE3.

  1. Compruebe que las interfaces físicas estén activas.
    content_copy zoom_out_map
    host@PE3> show interfaces xe-0/0/0 terse
    Interface               Admin Link Proto    Local                 Remote
    xe-0/0/0                up    up
    xe-0/0/0.0              up    up   inet     172.16.1.2/24   
                                       mpls    
                                       multiservice
    
    content_copy zoom_out_map
    host@PE3> show interfaces xe-0/0/1 terse
    Interface               Admin Link Proto    Local                 Remote
    xe-0/0/1                up    up
    xe-0/0/1.0              up    up   inet     172.17.1.2/24   
                                       mpls    
                                       multiservice
    
    
  2. Verifique los vecinos de OSPF.
    content_copy zoom_out_map
    host@PE3> show ospf neighbor 
    Address          Interface              State     ID               Pri  Dead
    172.16.1.1       xe-0/0/0.0             Full      10.250.1.1       128    39
    172.17.1.1       xe-0/0/1.0             Full      10.250.1.2       128    34
    
  3. Compruebe los pares BGP en PE1 y PE2.
    content_copy zoom_out_map
    user@PE3> show bgp summary 
    Groups: 1 Peers: 2 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0               
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active Received/Accepted/Damped...
    10.250.1.1            65000       2586       2575       0       0    19:21:36 0/0/0/0              0/0/0/0
    10.250.1.2            65000       2586       2577       0       0    19:21:38 0/0/0/0              0/0/0/0
    
  4. Demostrar que los vecinos están establecidos en el grupo IBGP.
    content_copy zoom_out_map
    user@PE3> show bgp group IBGP
    Group Type: Internal    AS: 65000                  Local AS: 65000
      Name: IBGP            Index: 0                   Flags: <Export Eval>
      Holdtime: 0
      Total peers: 2        Established: 2
      10.250.1.1+179
      10.250.1.2+179
      inet.0: 0/0/0/0
    
  5. Verifique sus sesiones de RSVP.
    content_copy zoom_out_map
    host@PE3> show rsvp session 
    Ingress RSVP: 2 sessions
    To              From            State   Rt Style Labelin Labelout LSPname 
    10.250.1.1      10.250.1.3      Up       0  1 FF       -        3 PE3toPE1
    10.250.1.2      10.250.1.3      Up       0  1 FF       -        3 PE3toPE2
    Total 2 displayed, Up 2, Down 0
    
    Egress RSVP: 2 sessions
    To              From            State   Rt Style Labelin Labelout LSPname 
    10.250.1.3      10.250.1.2      Up       0  1 FF       3        - PE2toPE3
    10.250.1.3      10.250.1.1      Up       0  1 FF       3        - PE1toPE3
    Total 2 displayed, Up 2, Down 0
    
    Transit RSVP: 0 sessions
    Total 0 displayed, Up 0, Down 0
    
  6. Verifique sus sesiones de LSP de MPLS.
    content_copy zoom_out_map
    host@PE3> show mpls lsp         
    Ingress LSP: 2 sessions
    To              From            State Rt P     ActivePath       LSPname
    10.250.1.1      10.250.1.3      Up     0 *                      PE3toPE1
    10.250.1.2      10.250.1.3      Up     0 *                      PE3toPE2
    Total 2 displayed, Up 2, Down 0
    
    Egress LSP: 2 sessions
    To              From            State   Rt Style Labelin Labelout LSPname 
    10.250.1.3      10.250.1.2      Up       0  1 FF       3        - PE2toPE3
    10.250.1.3      10.250.1.1      Up       0  1 FF       3        - PE1toPE3
    Total 2 displayed, Up 2, Down 0
    
    Transit LSP: 0 sessions
    Total 0 displayed, Up 0, Down 0
    
  7. Compruebe el estado de las rutas de conmutación de etiquetas (LSP) de MPLS.
    content_copy zoom_out_map
    host@PE3> show mpls lsp name PE3toPE1 detail
    Ingress LSP: 2 sessions
    
    10.250.1.1
      From: 10.250.1.3, State: Up, ActiveRoute: 0, LSPname: PE3toPE1
      ActivePath:  (primary)
      LSPtype: Static Configured, Penultimate hop popping
      LoadBalance: Random
      Encoding type: Packet, Switching type: Packet, GPID: IPv4
      LSP Self-ping Status : Enabled
     *Primary                    State: Up
        Priorities: 7 0
        SmartOptimizeTimer: 180
        Flap Count: 0
        MBB Count: 0
        Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
              172.16.1.1(Label=3)
    Total 1 displayed, Up 1, Down 0
    
    Egress LSP: 2 sessions
    Total 0 displayed, Up 0, Down 0
    
    Transit LSP: 0 sessions
    Total 0 displayed, Up 0, Down 0
                                       
    
  8. Para validar la accesibilidad a nivel de OSPF en el núcleo, desde PE3, ping PE1.
    content_copy zoom_out_map
    user@PE3> ping 10.250.1.1 
    PING 10.250.1.1 (10.250.1.1): 56 data bytes
    64 bytes from 10.250.1.1: icmp_seq=0 ttl=64 time=1.571 ms
    64 bytes from 10.250.1.1: icmp_seq=1 ttl=64 time=1.829 ms
    64 bytes from 10.250.1.1: icmp_seq=2 ttl=64 time=0.947 ms
    64 bytes from 10.250.1.1: icmp_seq=3 ttl=64 time=2.022 ms
    64 bytes from 10.250.1.1: icmp_seq=4 ttl=64 time=0.948 ms
    --- 10.250.1.1 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 0.947/1.463/2.022/0.445 ms
    

Configuración de la VPN de capa 3 en enrutadores PE

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.

Figura 4: VPN de capa 3 con concentrador y radiales Layer 3 VPN with Hub and Spokes

Configuración de PE1

  1. Configure las interfaces físicas para los clientes A y B.
    content_copy zoom_out_map
    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;
                }
            }
        }
    }
    
  2. Configure las políticas que usaremos como políticas de importación y exportación de VPN en las instancias de enrutamiento VRF del enrutador.
    • CustA-to-CloudSvcs y CustB-to-CloudSvcs—Estas son políticas de exportación que agregan la etiqueta Spoke cuando BGP exporta rutas que coinciden con las políticas.

    • from-CloudSvcs: esta es una política de importación que agrega rutas recibidas con la etiqueta Hub a la tabla de enrutamiento VRF.

    content_copy zoom_out_map
    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;
        }
    }
    
  3. Configure instancias de enrutamiento VRF para los clientes A y B. Estas instancias de enrutamiento crean las siguientes tablas de enrutamiento en PE1:
    • Para el cliente A, la tabla VRF es Cust-A-VRF.inet.0.

    • Para el cliente B, la tabla VRF es Cust-B-VRF.inet.0.

    Cada instancia de enrutamiento debe contener:

    • Tipo de instancia de VRF, que crea la tabla de enrutamiento VRF para la VPN en el enrutador PE.

    • Interfaz conectada al dispositivo CE del cliente.

    • Distinguidor de ruta, que debe ser único para cada instancia de enrutamiento en el enrutador PE. Se utiliza para distinguir las direcciones en una VPN de las de otra VPN.

    • Directiva de importación de VRF que agrega rutas recibidas con la etiqueta Hub a la tabla de enrutamiento VRF.

    • Política de exportación de VRF que agrega la etiqueta radial cuando BGP exporta la ruta.

    • Etiqueta de tabla VRF que asigna la etiqueta interna de un paquete a una tabla VRF específica. Esto permite el examen del encabezado IP encapsulado. Todas las rutas del VRF configuradas con esta opción se anuncian con la etiqueta asignada por VRF.

    content_copy zoom_out_map
    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;
        }
    }
    
  4. Agregue compatibilidad con VPN de capa 3 al grupo IBGP.
    content_copy zoom_out_map
    protocols  {
        bgp {
            group IBGP {
                family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
                unicast;
            }
        }
    }
    

Configuración de PE2

  1. Configure la interfaz para el cliente C.
    content_copy zoom_out_map
    interfaces {
        xe-0/0/3 {
            description "Inside to CE1_Cust-C";
            unit 0 {
                family inet {
                    address 10.0.50.1/24;
                }
            }
        }
    }
    
  2. Configure las políticas que usaremos como políticas de importación y exportación de VPN en la instancia de enrutamiento VRF del enrutador.
    • CustC-to-CloudSvcs: se trata de una política de exportación que agrega la etiqueta Spoke cuando BGP exporta rutas que coinciden con la política.

    • from-CloudSvcs: esta es una política de importación que agrega rutas recibidas con la etiqueta Hub a la tabla de enrutamiento VRF.

    content_copy zoom_out_map
    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;
        }
    }
    
  3. Configure una instancia de enrutamiento VRF para el cliente C que creará una tabla de enrutamiento para reenviar paquetes dentro de la VPN.

    Para Cust-C, la tabla VRF es Cust-C.inet.0.

    La instancia de enrutamiento debe contener:

    • Distinguidor de ruta, que debe ser único para cada instancia de enrutamiento en el enrutador PE. Se utiliza para distinguir las direcciones en una VPN de las de otra VPN.

    • Tipo de instancia de VRF, que crea la tabla de enrutamiento VRF para la VPN en el enrutador PE.

    • Interfaz conectada a CE3.

    • Directiva de importación de VRF que agrega rutas recibidas con la etiqueta Hub a la tabla de enrutamiento VRF.

    • Política de exportación de VRF que agrega la etiqueta radial cuando BGP exporta la ruta.

    • Etiqueta de tabla VRF que asigna la etiqueta interna de un paquete a una tabla VRF específica. Esto permite el examen del encabezado IP encapsulado. Todas las rutas del VRF configuradas con esta opción se anuncian con la etiqueta asignada por VRF.

    content_copy zoom_out_map
    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;
        }
    }
    
  4. Agregue compatibilidad con VPN de capa 3 al grupo IBGP.
    content_copy zoom_out_map
    protocols  {
        bgp {
            group IBGP {
                family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
                unicast
            }
        }
    }
    

Configuración de PE3

  1. Configure la interfaz física para los servicios en la nube.
    content_copy zoom_out_map
    interfaces {
        xe-0/0/2 {
            description "PE3 to CloudSvcs";
            unit 0 {
                family inet {
                    address 192.168.1.1/24;
                }
            }
        }
    }
    
  2. Configure las políticas que usaremos como políticas de importación y exportación de VPN en la instancia de enrutamiento VRF del enrutador.
    • to-Cust: se trata de una política de exportación que agrega la etiqueta Spoke cuando BGP exporta rutas que coinciden con la política.

    • from-Cust: esta es una política de importación que agrega las rutas recibidas que tienen una etiqueta Spoke a la tabla de enrutamiento VRF.

    content_copy zoom_out_map
    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;
            }
        }
    }
    
  3. Configure una instancia de enrutamiento VRF que se use para crear una tabla de enrutamiento para reenviar paquetes dentro de la VPN.

    Para Servicios en la nube, la tabla VRF es CloudSvcs.inet.0.

    La instancia de enrutamiento debe contener:

    • Distinguidor de ruta, que debe ser único para cada instancia de enrutamiento en el enrutador PE. Se utiliza para distinguir las direcciones en una VPN de las de otra VPN.

    • Tipo de instancia de VRF, que crea la tabla VRF en el enrutador PE.

    • Interfaces conectadas a los enrutadores PE.

    • Política de importación de VRF que agrega rutas recibidas con una etiqueta Spoke a la tabla de enrutamiento VRF.

    • Política de exportación de VRF que agrega la etiqueta radial cuando BGP exporta rutas que coinciden con la política.

    content_copy zoom_out_map
    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;
        }
    }
    
  4. Agregue compatibilidad con VPN de capa 3 al grupo IBGP que se configuró anteriormente.
    content_copy zoom_out_map
    protocols  {
        bgp {
            group IBGP {
                family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
                unicast
            }
        }
    }
    

Verificación de la configuración

Para comprobar su configuración, confirme la configuración y, a continuación, haga lo siguiente:

  1. Desde PE3, muestra a los vecinos del grupo IBGP. Observe la adición de las tablas de enrutamiento bgp.l3vpn y CloudSvcs.
    content_copy zoom_out_map
    user@PE3> show bgp group IBGP 
    Group Type: Internal    AS: 65000                  Local AS: 65000
      Name: IBGP            Index: 0                   Flags: <Export Eval>
      Holdtime: 0
      Total peers: 2        Established: 2
      10.250.1.1+179
      10.250.1.2+179
      inet.0: 0/0/0/0
      bgp.l3vpn.0: 0/0/0/0
      CloudSvcs.inet.0: 0/0/0/0
    
    Nota:

    Cuando un enrutador de PE recibe una ruta de otro enrutador de PE, la compara con la política de importación en la sesión de IBGP entre los enrutadores de PE. Si se acepta, el enrutador coloca la ruta en su tabla bgp.l3vpn.0. Al mismo tiempo, el enrutador comprueba la ruta con respecto a la política de importación de VRF para la VPN. Si coincide, el diferenciador de ruta se elimina de la ruta y la ruta se coloca en la tabla VRF adecuada (la tabla routing-instance-name.inet.0).

  2. Desde PE3, verifique los pares BGP en PE1 y PE2. Observe nuevamente la adición de las tablas bgp.l3vpn.
    content_copy zoom_out_map
    user@PE3> show bgp summary
    Groups: 1 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          
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    10.250.1.1            65000         41         39       0       0       17:16 Establ
      inet.0: 0/0/0/0
      bgp.l3vpn.0: 0/0/0/0
    10.250.1.2            65000         41         38       0       0       17:12 Establ
      inet.0: 0/0/0/0
      bgp.l3vpn.0: 0/0/0/0
    
  3. Desde PE1, compruebe que la instancia de enrutamiento Cust-A-VRF esté activa.
    content_copy zoom_out_map
    user@PE1> show route instance Cust-A-VRF detail 
    Cust-A-VRF:
      Router ID: 10.0.1.1
      Type: vrf               State: Active        
      Interfaces:
        xe-0/0/0.0
        lsi.0
      Route-distinguisher: 10.250.1.1:1
      Vrf-import: [ from-CloudSvcs ]
      Vrf-export: [ CustA-to-CloudSvcs ]
      Fast-reroute-priority: low
      Tables:
        Cust-A-VRF.inet.0      : 3 routes (3 active, 0 holddown, 0 hidden)
    
  4. Desde PE1, compruebe la tabla de enrutamiento Cust-A-VRF.inet.0.
    content_copy zoom_out_map
    user@PE1> show route table Cust-A-VRF.inet.0 
    Cust-A-VRF.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    10.0.1.0/24        *[Direct/0] 00:10:12
                        > via xe-0/0/0.0
    10.0.1.1/32        *[Local/0] 00:10:12
                          Local via xe-0/0/0.0
    

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

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.

Figura 5: Conexiones a enrutadores CE y servicios Connections to CE Routers and Cloud Services 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

  1. Configure las interfaces físicas y de circuito cerrado para CE1.
    content_copy zoom_out_map
    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;
                }
            }
        }
    }
    
  2. Configure una política de enrutamiento que coincida con la dirección de la LAN A del cliente.
    content_copy zoom_out_map
    policy-options {
        policy-statement CustA-to-PE1 {
            term 1 {
                from {
                    route-filter 10.250.100.101/32 exact;
                }
                then accept;
            }
            term 2 {
                then reject;
            }
        }
    }
    
  3. Configure un grupo EBGP para el emparejamiento entre CE1 y PE1. Aplique la política de enrutamiento que coincida con la LAN A del cliente como una política de exportación. BGP anuncia la dirección de la política a PE1, que redistribuye las rutas LAN del cliente en la VPN.
    content_copy zoom_out_map
    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
            }
        }
    }
    
  4. Configure el sistema autónomo para el enrutador.
    content_copy zoom_out_map
    routing-options {
        autonomous-system 65101;
    }
    

Configuración de PE1

Agregue un grupo EBGP a las instancias de enrutamiento Cust-A-VRF para el emparejamiento entre PE1 y CE1.
content_copy zoom_out_map
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

  1. Configure las interfaces físicas y de circuito cerrado para CE2.
    content_copy zoom_out_map
    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;
                }
            }
        }
    }
    
  2. Configure una política de enrutamiento que coincida con la dirección de la LAN B del cliente.
    content_copy zoom_out_map
    policy-options {
        policy-statement CustB-to-PE1 {
            term 1 {
                from {
                    route-filter 10.250.100.102/32 exact;
                }
                then accept;
            }
            term 2 {
                then reject;
            }
        }
    }
    
  3. Configure un grupo EBGP para el emparejamiento entre CE2 y PE1. Aplique la directiva de enrutamiento que coincida con la LAN B del cliente como una política de exportación. BGP anuncia esta dirección a la red VPN, lo que significa que las rutas LAN del cliente se distribuyen en la VPN.
    content_copy zoom_out_map
    protocols {
        bgp {
            group to-PE1 {
                type external;
                export CustB-to-PE1;
                peer-as 65000;
                neighbor 10.0.1.2;  ## PE1 interface address
            }
        }
    }
    
  4. Configure el sistema autónomo.
    content_copy zoom_out_map
    routing-options {
        autonomous-system 65102;
    }
    

Configuración de PE1

Agregue un grupo EBGP a las instancias de enrutamiento Cust-B-VRF para el emparejamiento entre PE1 y CE2.
content_copy zoom_out_map
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

  1. Configure las interfaces físicas y de circuito cerrado para CE3.
    content_copy zoom_out_map
    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;
                }
            }
        }
    }
    
  2. Configure una política de enrutamiento que coincida con la dirección de la LAN C del cliente.
    content_copy zoom_out_map
    policy-options {
        policy-statement CustC-to-PE2 {
            term 1 {
                from {
                    route-filter 10.250.100.103/32 exact;
                }
                then accept;
            }
            term 2 {
                then reject;
            }
        }
    }
    
  3. Configure un grupo EBGP para el emparejamiento entre CE3 y PE2. Aplique la directiva de enrutamiento que coincida con la LAN C del cliente como política de exportación. BGP anuncia esta dirección a la red VPN, lo que significa que las rutas LAN del cliente se distribuyen en la VPN.
    content_copy zoom_out_map
    protocols {
        bgp {
            group to-PE2 {
                type external;
                export CustC-to-PE2;
                peer-as 65000;
                neighbor 10.0.50.1;  ## PE2 interface address
            }
        }
    }
    
  4. Configure el sistema autónomo.
    content_copy zoom_out_map
    routing-options {
        autonomous-system 65103;
    }
    

Configuración de PE2

Agregue un grupo EBGP a la instancia de enrutamiento Cust-C para emparejar entre PE2 y CE3.
content_copy zoom_out_map
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

  1. Verifique que las interfaces físicas de los enrutadores CE estén activas. Por ejemplo:
    content_copy zoom_out_map
    host@CE1> show interfaces xe-0/0/0 terse 
    Interface               Admin Link Proto    Local                 Remote
    xe-0/0/0                up    up
    xe-0/0/0.0              up    up   inet     10.0.1.2/24     
                                       multiservice
    
  2. Verifique las conexiones de los enrutadores PE a los enrutadores CE. Por ejemplo:
    content_copy zoom_out_map
    host@PE1> ping 10.0.1.2 routing-instance Cust-A-VRF source 10.0.1.1 count 4 
    PING 10.0.1.2 (10.0.1.2): 56 data bytes
    64 bytes from 10.0.1.2: icmp_seq=0 ttl=64 time=1.087 ms
    64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=1.434 ms
    64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=3.478 ms
    64 bytes from 10.0.1.2: icmp_seq=3 ttl=64 time=15.761 ms
    
    --- 10.0.1.2 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 1.087/5.440/15.761/6.028 ms
    
  3. Verifique la conexión de PE3 a los servicios en la nube.
    content_copy zoom_out_map
    host@PE3> ping 192.168.1.2 routing-instance CloudSvcs source 192.168.1.1 count 4 
    PING 192.168.1.2 (192.168.1.2): 56 data bytes
    64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.936 ms
    64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=6.257 ms
    64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.868 ms
    64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.849 ms
    
    --- 192.168.1.2 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 0.849/2.228/6.257/2.327 ms
    
  4. En PE3, compruebe los pares BGP. Servicios en la nube (192.168.1.2) ahora es un par BGP.
    content_copy zoom_out_map
    host@PE3> show bgp summary 
    Groups: 2 Peers: 3 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0               
                           0          0          0          0          0          0
    bgp.l3vpn.0          
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    10.250.1.1            65000        946        941       0       0     7:03:46 Establ
      inet.0: 0/0/0/0
      bgp.l3vpn.0: 0/0/0/0
    10.250.1.2            65000        946        941       0       0     7:03:42 Establ
      inet.0: 0/0/0/0
      bgp.l3vpn.0: 0/0/0/0
    192.168.1.2           65200        159        155       0       0     1:09:47 Establ
      CloudSvcs.inet.0: 1/1/1/0
    
  5. En PE1, compruebe que CE1 y CE2 son ahora pares BGP.
    content_copy zoom_out_map
    host@PE1> show bgp summary 
    Groups: 3 Peers: 3 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0               
                           0          0          0          0          0          0
    bgp.l3vpn.0          
                           1          1          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    10.0.1.2              65101          11         3       0       0    16:41:31 Establ
    10.0.1.4              65102          7          2       0       0        1:24 Establ
      Cust-B-VRF.inet.0: 1/1/1/0
    10.250.1.3            65000       3202       3210       0       1  1d 0:02:40 Establ
      inet.0: 0/0/0/0
      bgp.l3vpn.0: 1/1/1/0
      Cust-A-VRF.inet.0: 1/1/1/0
      Cust-B-VRF.inet.0: 1/1/1/0
    
  6. En los enrutadores CE, verifique el grupo EBGP. Por ejemplo:
    content_copy zoom_out_map
    host@CE1> show bgp group to-PE1 
    Group Type: External                               Local AS: 65101
      Name: to-PE1          Index: 0                   Flags: <Export Eval>
      Export: [ CustA-to-PE1 ] 
      Holdtime: 0
      Total peers: 1        Established: 1
      10.0.1.1+60358
      inet.0: 1/1/1/0
    

Configuración de NAT 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.

Figura 6: Configuración Next-Hop Style Inline NAT Configuration 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.

Figura 7: Flujo de tráfico en PE1 para tráfico NAT en línea estilo salto del cliente A LAN a servicios Traffic Flow on PE1 for Next-Hop Style Inline NAT Traffic from Customer A LAN to Cloud Services en la nube

Para configurar la NAT en línea de estilo próximo salto en PE1:

  1. Habilite los servicios en línea para la ranura FPC y la ranura PIC pertinentes, y defina la cantidad de ancho de banda que se dedicará a los servicios en línea.

    La configuración de FPC y PIC se asigna a la interfaz si- configurada.

    content_copy zoom_out_map
    chassis {
        fpc 0 {
            pic 0 {
                inline-services {
                    bandwidth 1g;
                }
            }
        }
    }
    
  2. Configure las interfaces de servicio usadas para NAT. Las interfaces internas están en el lado CE de la red. Las interfaces externas están en el lado central de la red.
    • Para el tráfico desde la red del cliente hasta el núcleo:

      La interfaz interna maneja el tráfico de entrada desde la red del cliente. NAT se aplica a este tráfico y, a continuación, el tráfico de salida se envía a la interfaz externa.

    • Para el tráfico desde el núcleo hasta la red del cliente:

      La interfaz externa controla el tráfico de entrada desde la red principal. NAT se elimina de este tráfico y, a continuación, el tráfico de salida se envía a la interfaz interna.

    content_copy zoom_out_map
    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
    }
    
  3. Configurar grupos NAT.
    content_copy zoom_out_map
    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;
    }
    
  4. Configure reglas NAT que:
    • Haga coincidir el tráfico de las redes del cliente A y del cliente B.

    • Aplique el grupo del que desea obtener una dirección.

    • Aplique NAT 44 básica, un tipo de NAT estática que se aplica al tráfico IPv4.

    content_copy zoom_out_map
    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
                    }
                }
            }
        }
    }
    
  5. Configure conjuntos de servicios de estilo de próximo salto. El servicio establece interfaces de servicio asociadas y define servicios. En este caso, se aplicará el procesamiento NAT al tráfico enviado a través de las interfaces internas y externas definidas.
    content_copy zoom_out_map
    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;
        }
    }
    
  6. Cree instancias de enrutamiento de RV para el tráfico del cliente A y el tráfico del cliente B. Estas instancias de enrutamiento separan el tráfico del cliente A y B. Incluyen rutas estáticas predeterminadas que envían tráfico a las interfaces de servicio internas y hacia los conjuntos de servicios, donde se puede aplicar NAT.
    content_copy zoom_out_map
    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
                    
                }
            }
        }
    }
    
  7. Configure filtros de firewall que redirijan el tráfico entrante del cliente A y el cliente B a las instancias de enrutamiento de realidad virtual.
    content_copy zoom_out_map
    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;
    }
    
  8. Aplique los filtros del firewall a las interfaces adecuadas.
    content_copy zoom_out_map
    interfaces {
        xe-0/0/0 {  ## to Customer A
        unit 0 {
            family inet {
                filter {
                    input CustA-to-NAT-VR;
                }
            }
        }
    }
    
  9. Agregue las interfaces si- externas a las instancias de enrutamiento VRF configuradas previamente. Esto devuelve el tráfico saliente ahora traducido a NAT a su instancia de enrutamiento VRF prevista, y ahora se puede enviar a través de la VPN como de costumbre.
    content_copy zoom_out_map
    routing-instances {
        Cust-A-VRF {
            interface si-0/0/0.2;
        }
        Cust-B-VRF {
            interface si-0/0/0.4;
        }
    }
    

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.

Figura 8: Flujo de tráfico en PE1 para el tráfico NAT en línea de estilo siguiente salto desde los servicios en la nube hasta el cliente A LAN Traffic Flow on PE1 for Next-Hop Style Inline NAT Traffic from Cloud Services to the Customer A LAN

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:

content_copy zoom_out_map
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:

  1. Cree políticas que coincidan con las rutas que se van a compartir.
    • El término 1 hace coincidir las rutas que proporcionan accesibilidad a las LAN del cliente.

    • El término 2 hace coincidir las rutas de interfaz que proporcionan accesibilidad a los dispositivos CE.

    content_copy zoom_out_map
    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;
        }
    }
    
  2. Cree grupos RIB para compartir rutas entre tablas.
    • Con la instrucción, enumere la tabla de enrutamiento de origen que se va a compartir, seguida de la import-rib tabla de enrutamiento de destino en la que se importarán las rutas.

    • Con la instrucción, especifique la import-policy política utilizada para definir las rutas específicas que se compartirán.

    content_copy zoom_out_map
    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;
    }
    
  3. En las instancias de enrutamiento de VRF creadas anteriormente, aplique los grupos RIB a las rutas deseadas.
    • Para importar rutas conectadas directamente, aplique el grupo RIB en la routing-options jerarquía.

    • Para importar las rutas LAN del cliente (PE1 recibe estas rutas a través de los emparejamientos de EBGP de CE a PE), aplique el grupo RIB en la protocols jerarquía.

    content_copy zoom_out_map
    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;
                    }
                }
            }
        }
    }
    

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:

content_copy zoom_out_map
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

  1. Desde CE1, verifique la conectividad entre CE1 y los servicios en la nube.
    content_copy zoom_out_map
    host@CE1> ping 10.250.200.200 source 10.250.100.101 count 4 
    PING 10.250.200.200 (10.250.200.200): 56 data bytes
    64 bytes from 10.250.200.200: icmp_seq=0 ttl=62 time=1.246 ms
    64 bytes from 10.250.200.200: icmp_seq=1 ttl=62 time=1.042 ms
    64 bytes from 10.250.200.200: icmp_seq=2 ttl=62 time=1.053 ms
    64 bytes from 10.250.200.200: icmp_seq=3 ttl=62 time=1.083 ms
    
    --- 10.250.200.200 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 1.042/1.106/1.246/0.082 ms
    
  2. Desde PE1, muestre estadísticas NAT para verificar que el tráfico se está traduciendo a NAT.
    content_copy zoom_out_map
    host@PE1> show services inline nat statistics  
    Service PIC Name                                      si-0/0/0             
    
     Control Plane Statistics
         Received IPv4 packets                                0                    
         ICMPv4 error packets pass through                    0                    
         ICMPv4 error packets locally generate                0                    
         Dropped IPv4 packets                                 0                    
         Received IPv6 packets                                0                    
         ICMPv6 error packets pass through for NPTv6          0                    
         ICMPv6 error packets locally generated for NPTv6     0                    
         Dropped IPv6 packets                                 0                    
    
    Data Plane Statistics           Packets                  Bytes
         IPv4 NATed packets            73                      7154                 
         IPv4 deNATed packets          73                      7446                 
         IPv4 error packets            0                       0                    
         IPv4 skipped packets          0                       0                    
         IPv6 NATed packets            0                       0                    
         IPv6 deNATed packets          0                       0                    
         IPv6 error packets            0                       0                    
         IPv6 skipped packets          0                       0     
    
  3. Desde PE1, verifique los grupos de NAT que se utilizan para traducir direcciones para los clientes A y B.
    content_copy zoom_out_map
    host@PE1> show services inline nat pool 
    Interface: si-0/0/0, Service set: NH-STYLE-SS-NAT_A
      NAT pool: A, Translation type: BASIC NAT44
        Address range: 192.0.2.0-192.0.2.255
        NATed packets: 33, deNATed packets: 33, Errors: 0, Skipped packets: 0
    
    Interface: si-0/0/0, Service set: NH-STYLE-SS-NAT_B
      NAT pool: B, Translation type: BASIC NAT44
        Address range: 198.51.100.0-198.51.100.255
        NATed packets: 23, deNATed packets: 23, Errors: 0, Skipped packets: 0
    
    
  4. Desde los servicios en la nube, verifique que el enrutador esté recibiendo los pings del cliente de PE1s Un grupo de direcciones de origen traducidas NAT (192.0.2.0/24).

    Vuelva a ejecutar pings desde CE1 a servicios en la nube e ingrese el siguiente comando en servicios en la nube.

    content_copy zoom_out_map
    host@CldSvcs> monitor traffic interface xe-0/0/0 detail no-resolve
    Address resolution is OFF.
    Listening on xe-0/0/0, capture size 1514 bytes
    21:54:42.937849  In IP (tos 0xc0, ttl   1, id 38220, offset 0, flags [none], proto: TCP (6), length: 52) 192.168.1.1.179 > 192.168.1.2.55253: . ack 2452754676 win 16384 <nop,nop,timestamp 117113408 1131425253>
    21:54:43.651296  In IP (tos 0x0, ttl  62, id 36015, offset 0, flags [none], proto: ICMP (1), length: 84) 192.0.2.101 > 10.250.200.200: ICMP echo request, id 7224, seq 24, length 64
    21:54:43.651336 Out IP (tos 0x0, ttl  64, id 55445, offset 0, flags [none], proto: ICMP (1), length: 84) 10.250.200.200 > 192.0.2.101: ICMP echo reply, id 7224, seq 24, length 64
    
    
  5. Desde PE3, muestre la tabla de enrutamiento de capa 3 del BGP. En esta tabla se comprueba que se está realizando la traducción de NAT. 192.0.2.0 /24 es la dirección del grupo A para el tráfico del cliente A. 198.51.100.0 es la dirección del grupo B para el tráfico del cliente B
    content_copy zoom_out_map
    user@PE3> show route table bgp.l3vpn.0 
    bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    10.250.1.1:1:192.0.2.0/24                
                       *[BGP/170] 00:20:09, localpref 100, from 10.250.1.1
                          AS path: I, validation-state: unverified
                        > to 172.16.1.1 via xe-0/0/0.0, label-switched-path PE3toPE1
    10.250.1.1:2:198.51.100.0/24                
                       *[BGP/170] 00:20:09, localpref 100, from 10.250.1.1
                          AS path: I, validation-state: unverified
                        > to 172.16.1.1 via xe-0/0/0.0, label-switched-path PE3toPE1
    

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.

Figura 9: Configuración Interface-Style NAT Configuration 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.

Figura 10: Flujo de tráfico en PE2 para tráfico NAT en línea estilo interfaz desde C LAN del cliente a servicios Traffic Flow on PE2 for Interface-Style Inline NAT traffic from Customer C LAN to Cloud Services 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.

Figura 11: Flujo de tráfico en PE2 para tráfico NAT de estilo interfaz desde los servicios en la nube a la C LAN Traffic Flow on PE2 for Interface-Style NAT Traffic from Cloud Services to Customer C LAN del cliente

Para configurar NAT en línea de estilo de interfaz en PE2:

  1. Habilite los servicios en línea para la ranura FPC y la ranura PIC pertinentes, y defina la cantidad de ancho de banda que se dedicará a los servicios en línea.

    La configuración de FPC y PIC se asigna a la interfaz si- configurada anteriormente.

    content_copy zoom_out_map
    chassis {
        fpc 0 {
            pic 0 {
                inline-services {
                    bandwidth 1g;
                }
            }
        }
    }
    
  2. Configure la interfaz de servicio utilizada para NAT. La NAT de estilo de interfaz solo requiere una interfaz.
    content_copy zoom_out_map
    interfaces {
        si-0/0/0 {
            unit 0 {
                family inet; ## protocol family that will need NAT services
            }
        }
    }
    
  3. Configure un grupo NAT.
    content_copy zoom_out_map
    services {
        nat {
            pool C {
                address 203.0.113.0/24;
            }
        }
    }
    
  4. Configure una regla NAT que:
    • Hace coincidir el tráfico de la red C del cliente.

    • Aplica el grupo del que se va a obtener una dirección.

    • Aplica NAT 44 básico, un tipo de NAT estática que se aplica al tráfico IPv4.

    content_copy zoom_out_map
    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
                        }
                    }
                }
            }
        }
    }
    
  5. Configure un conjunto de servicios de estilo de interfaz que asocie la interfaz de servicio al servicio NAT. En este caso, el servicio NAT utiliza la regla SRC-NAT-C NAT.

    El tráfico entrará y saldrá de la interfaz si- para acceder al servicio NAT en línea.

    content_copy zoom_out_map
    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;
        }
    }
    
  6. Aplique el conjunto de servicios de entrada y salida a la interfaz xe-0/0/2, que es la interfaz del cliente C. Esta configuración especifica que todo el tráfico hacia y desde el cliente C se redirige a través del conjunto de servicios.
    content_copy zoom_out_map
    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;
                        }
                    }
                }
            }
        }
    }
    
  7. Agregue la interfaz si- a la instancia de enrutamiento VRF Cust-C.
    content_copy zoom_out_map
    routing-instances {
        Cust-C {
            interface si-0/0/0.0;
        }
    }
    

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

  1. Desde CE3, verifique la conectividad entre CE3 y los servicios en la nube.
    content_copy zoom_out_map
    host@CE3> ping 10.250.200.200 source 10.250.100.103 count 4  
    PING 10.250.200.200 (10.250.200.200): 56 data bytes
    64 bytes from 10.250.200.200: icmp_seq=0 ttl=62 time=1.109 ms
    64 bytes from 10.250.200.200: icmp_seq=1 ttl=62 time=1.111 ms
    64 bytes from 10.250.200.200: icmp_seq=2 ttl=62 time=1.087 ms
    64 bytes from 10.250.200.200: icmp_seq=3 ttl=62 time=1.192 ms
    
    --- 10.250.200.200 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 1.087/1.125/1.192/0.040 ms
    
    
  2. Desde PE2, muestre las estadísticas NAT en línea para verificar que el tráfico se está traduciendo a NAT.
    content_copy zoom_out_map
    host@PE2> show services inline nat statistics 
     Service PIC Name                                      si-0/0/0             
    
     Control Plane Statistics
         Received IPv4 packets                                0                   
         ICMPv4 error packets pass through                    0                    
         ICMPv4 error packets locally generate                0                    
         Dropped IPv4 packets                                 0                    
         Received IPv6 packets                                0                    
         ICMPv6 error packets pass through for NPTv6          0                    
         ICMPv6 error packets locally generated for NPTv6     0                    
         Dropped IPv6 packets                                 0                    
    
     Data Plane Statistics           Packets                  Bytes
         IPv4 NATed packets            18                      1248                 
         IPv4 deNATed packets          12                      1008                 
         IPv4 error packets            0                       0                    
         IPv4 skipped packets          0                       0                    
         IPv6 NATed packets            0                       0                    
         IPv6 deNATed packets          0                       0                    
         IPv6 error packets            0                       0                    
         IPv6 skipped packets          0                       0   
    
  3. Desde PE2, compruebe que la NAT en línea se está aplicando correctamente.
    content_copy zoom_out_map
    host@PE2> show services inline nat pool 
    Interface: si-0/0/0, Service set: INT-STYLE-SS-NAT_C
      NAT pool: C, Translation type: BASIC NAT44
        Address range: 203.0.113.0-203.0.113.255
        NATed packets: 11, deNATed packets: 5, Errors: 0, Skipped packets: 0
    
  4. Desde PE2, compruebe que el grupo de traducción NAT se muestra en la tabla de enrutamiento para la red C del cliente.
    content_copy zoom_out_map
    host@PE2> show route table Cust-C.inet.0 
    Cust-C.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    10.0.50.0/24       *[Direct/0] 1d 00:27:53
                        > via xe-0/0/2.0
    10.0.50.1/32       *[Local/0] 1d 00:27:53
                          Local via xe-0/0/2.0
    10.250.100.103/32  *[BGP/170] 19:01:38, localpref 100
                          AS path: 65103 I, validation-state: unverified
                        > to 10.0.50.2 via xe-0/0/2.0
    10.250.200.0/24    *[BGP/170] 20:20:30, localpref 100, from 10.250.1.3
                          AS path: 65200 I, validation-state: unverified
                        > to 172.17.1.2 via xe-0/0/0.0, label-switched-path PE2toPE3
    203.0.113.0/24     *[Static/1] 02:20:18
                          Service to INT-STYLE-SS-NAT_C
    
  5. Desde los servicios en la nube, verifique que el enrutador esté recibiendo los pings del grupo PE2 de direcciones de origen traducidas NAT (203.0.113.0/24).

    Vuelva a ejecutar pings desde CE3 a servicios en la nube e introduzca el siguiente comando en servicios en la nube.

    content_copy zoom_out_map
    host@CldSvcs> monitor traffic interface xe-0/0/0 detail no-resolve
    Address resolution is OFF.
    Listening on xe-0/0/0, capture size 1514 bytes
    19:41:09.879603  In IP (tos 0x0, ttl  62, id 29437, offset 0, flags [none], proto: ICMP (1), length: 84) 203.0.113.103 > 10.250.200.200: ICMP echo request, id 6667, seq 6, length 64
    19:41:09.879644 Out IP (tos 0x0, ttl  64, id 51068, offset 0, flags [none], proto: ICMP (1), length: 84) 10.250.200.200 > 203.0.113.103: ICMP echo reply, id 6667, seq 6, length 64
    19:41:10.880605  In IP (tos 0x0, ttl  62, id 29456, offset 0, flags [none], proto: ICMP (1), length: 84) 203.0.113.103 > 10.250.200.200: ICMP echo request, id 6667, seq 7, length 64
    19:41:10.880644 Out IP (tos 0x0, ttl  64, id 51088, offset 0, flags [none], proto: ICMP (1), length: 84) 10.250.200.200 > 203.0.113.103: ICMP echo reply, id 6667, seq 7, length 64
    .
    .
    . ^C
    18 packets received by filter
    0 packets dropped by kernel
    

Configuraciones completas del enrutador

Esta sección tiene la configuración completa de cada router.

Configuración de PE1

content_copy zoom_out_map
## 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

content_copy zoom_out_map
## 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

content_copy zoom_out_map
## 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

content_copy zoom_out_map
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

content_copy zoom_out_map
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

content_copy zoom_out_map
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;
}
footer-navigation