juniper

Conceptos y ejemplosManual de referencia de ScreenOS

Volumen 7:Enrutamiento

Versión 6.0.0, Rev. 02

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089

USA.

408-745-2000

www.juniper.net

Número de pieza: 530-017773-01-SP, Revisión 02

ii

Copyright Notice

Copyright © 2007 Juniper Networks, Inc. All rights reserved.

Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

FCC Statement

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:

Reorient or relocate the receiving antenna.

Increase the separation between the equipment and receiver.

Consult the dealer or an experienced radio/TV technician for help.

Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user’s warranty and authority to operate this device.

Disclaimer

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

Contenido

Acerca de este volumen xi

Convenciones del documento ........................................................................ xiiConvenciones de la interfaz de usuario web ............................................ xiiConvenciones de interfaz de línea de comandos ..................................... xiiConvenciones de nomenclatura y conjuntos de caracteres ..................... xiiiConvenciones para las ilustraciones ....................................................... xiv

Asistencia y documentación técnica............................................................... xv

Capítulo 1 Enrutamiento estático 1

Vista general ....................................................................................................1Cómo funciona el enrutamiento estático ...................................................2Cuándo configurar rutas estáticas..............................................................3Configuración de rutas estáticas ................................................................4

Ajuste de rutas estáticas ......................................................................5Establecimiento de una ruta estática para una interfaz de túnel..........8

Habilitación del seguimiento de puertas de enlace ....................................9Reenvío de tráfico a la interfaz Null ...............................................................10

Impedir las consultas de rutas en otras tablas de enrutamiento...............10Impedir que el tráfico de túnel se envíe a través de interfaces que no sean de túnel ...................................................................................................10Evitar bucles creados por las rutas resumidas..........................................11

Rutas permanentemente activas ....................................................................11Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de

igual coste ...............................................................................................12

Capítulo 2 Enrutamiento 13

Vista general ..................................................................................................14Tablas de enrutamiento del enrutador virtual.................................................15

Tabla de enrutamiento basada en destinos..............................................16Tabla de enrutamiento basada en el origen .............................................18Tabla de enrutamiento según la interfaz de origen ..................................20

Creación y modificación de enrutadores virtuales ..........................................22Modificación de enrutadores virtuales .....................................................22Asignación de una ID de enrutador virtual...............................................23Reenvío de tráfico entre enrutadores virtuales.........................................24Configuración de dos enrutadores virtuales .............................................24Creación y eliminación de enrutadores virtuales .....................................26

Creación de un enrutador virtual personalizado ................................26Eliminación de un enrutador virtual personalizado ...........................27

Enrutadores virtuales y sistemas virtuales ...............................................27Creación de un enrutador virtual en un Vsys.....................................28Compartir rutas entre enrutadores virtuales......................................29

Contenido iii

iv

Manual de referencia de ScreenOS: Conceptos y ejemplos

Limitación del número máximo de entradas de la tabla de enrutamiento...........................................................................................30

Ejemplos y funciones del enrutamiento .........................................................30Selección de rutas....................................................................................31

Establecimiento de una preferencia de ruta ......................................31Métricas de ruta ................................................................................32Cambio de la secuencia predeterminada de consulta de rutas ..........33Consulta de rutas en múltiples enrutadores virtuales ........................35

Configuración del enrutamiento multidireccional de igual coste ..............36Redistribución de rutas............................................................................38

Configuración de un mapa de rutas ..................................................39Filtrado de rutas................................................................................41Configuración de una lista de acceso.................................................41Redistribución de rutas en OSPF.......................................................42

Exportación e importación de rutas entre enrutadores virtuales..............43Configuración de una regla de exportación .......................................44Configuración de la exportación automática .....................................45

Capítulo 3 Abrir primero la ruta más corta 47

Vista general ..................................................................................................48Áreas .......................................................................................................48Clasificación de enrutadores....................................................................49Protocolo de saludo .................................................................................50Tipos de redes .........................................................................................50

Redes de difusión..............................................................................50Redes punto a punto .........................................................................50Redes punto a multipunto .................................................................51

Notificaciones de estado de conexiones ..................................................51Configuración básica de OSPF .......................................................................51

Creación y eliminación de una instancia de enrutamiento OSPF .............53Creación de una instancia de OSPF...................................................53Eliminación de una instancia de OSPF ..............................................53

Creación y eliminación de un área OSPF.................................................54Creación de un área OSPF.................................................................54Eliminación de un área OSPF............................................................55

Asignación de interfaces a un área OSPF.................................................55Asignación de interfaces a áreas .......................................................55Configuración de un rango de áreas..................................................56

Habilitación de OSPF en interfaces..........................................................56Habilitación de OSPF en interfaces ...................................................56Inhabilitar OSPF en una interfaz .......................................................57

Verificación de la configuración...............................................................57Redistribución de rutas en protocolos de enrutamiento .................................59Resumen de rutas redistribuidas ....................................................................60

Resumen de rutas redistribuidas .............................................................60Parámetros globales de OSPF ........................................................................61

Notificación de la ruta predeterminada....................................................62Conexiones virtuales ...............................................................................62

Creación de una conexión virtual ......................................................63Creación de una conexión virtual automática....................................64

Ajuste de parámetros OSPF de interfaz ..........................................................64Configuración de seguridad............................................................................67

Autenticación de vecinos .........................................................................67Configuración de una contraseña de texto no cifrado .......................67

Contenido

Contenido

Configuración de una contraseña MD5 .............................................67Configuración de una lista de vecinos de OSPF .......................................68Rechazo de rutas predeterminadas..........................................................69Protección contra inundaciones...............................................................69

Configuración de un umbral de saludo..............................................70Configuración de un umbral de LSA..................................................70Habilitación de la inundación reducida .............................................70

Creación de un circuito de demanda OSPF en una interfaz de túnel ..............71Interfaz de túnel punto a multipunto..............................................................71

Establecer el tipo de conexión OSPF .......................................................72Inhabilitación de la restricción Route-Deny .............................................72Creación de una red punto a multipunto .................................................73

Capítulo 4 Protocolo de información de enrutamiento 79

Vista general ..................................................................................................80Configuración básica de RIP...........................................................................81

Creación y eliminación de una instancia RIP ...........................................82Creación de una instancia RIP...........................................................82Eliminación de una instancia RIP ......................................................83

Habilitación y deshabilitación de RIP en interfaces..................................83Habilitar RIP en una interfaz .............................................................83Inhabilitación de RIP en una interfaz ................................................83

Redistribución de rutas............................................................................84Visualización de la información de RIP ..........................................................85

Visualización de la base de datos RIP ......................................................85Visualización de los detalles de RIP .........................................................86Visualización de información de vecino RIP ............................................87Visualización de detalles de RIP para una interfaz específica ...................88

Parámetros globales de RIP............................................................................89Notificación de la ruta predeterminada ..........................................................90Configuración de los parámetros de interfaz de RIP.......................................90Configuración de seguridad............................................................................92

Autenticar vecinos al establecer una contraseña......................................92Configuración de vecinos fiables .............................................................93Rechazo de rutas predeterminadas..........................................................94Protección contra inundaciones...............................................................94

Configuración de un umbral de actualización....................................95Habilitación de RIP en interfaces de túnel .........................................95

Configuraciones opcionales de RIP ................................................................96Configuración de la versión de RIP ..........................................................96Habilitación e inhabilitación de un resumen de prefijos...........................98

Habilitación de un resumen de prefijos .............................................98Inhabilitar un resumen de prefijo ......................................................99

Establecimiento de rutas alternas ............................................................99Circuitos de demanda en interfaces de túnel .........................................101Configuración de un vecino estático ......................................................102

Configuración de una interfaz de túnel punto a multipunto..........................102

Capítulo 5 Protocolo de puertas de enlace de límite 109

Vista general ................................................................................................110Tipos de mensajes BGP..........................................................................110Atributos de ruta....................................................................................111BGP externo e interno ...........................................................................112

Contenido v

vi


Configuración básica de BGP........................................................................112Creación y habilitación de una instancia de BGP ...................................113

Creación de una instancia BGP........................................................113Eliminación de una instancia de BGP ..............................................114

Habilitación e inhabilitación de BGP en interfaces .................................114Habilitación de BGP en interfaces ...................................................114Inhabilitación de BGP en interfaces.................................................115

Configuración de grupos de interlocutores e interlocutores BGP............115Configuración de un interlocutor BGP .............................................117Configuración de un grupo de interlocutores IBGP ..........................117

Comprobación de la configuración BGP.................................................119Configuración de seguridad..........................................................................120

Autenticación de vecinos BGP ...............................................................120Rechazo de rutas predeterminadas........................................................121

Configuraciones opcionales de BGP .............................................................122Redistribución de rutas en BGP .............................................................123Configuración de una lista de acceso AS-Path........................................124Agregar rutas a BGP...............................................................................125

Notificación de ruta condicional......................................................125Establecimiento del peso de la ruta.................................................126Establecimiento datributos de ruta..................................................126

Capacidad de route-refresh....................................................................127Solicitud de una actualización de la tabla de enrutamiento entrante ..........................................................................................128Solicitud de una actualización de la tabla de enrutamiento saliente ...........................................................................................128

Configuración de la reflexión de rutas ...................................................128Configurar una confederación ...............................................................131Comunidades BGP.................................................................................133Agregación de rutas...............................................................................134

Agregación de rutas con diferentes AS-Paths...................................134Supresión de las rutas más específicas en actualizaciones ..............134Selección de rutas para el atributo Path ..........................................136Cambiar atributos de una ruta agregada .........................................137Cambiar atributos de una ruta agregada .........................................137

Capítulo 6 Enrutamiento basado en directivas 139

Vista general del enrutamiento basado en directivas....................................140Listas de acceso extendidas...................................................................140Grupos de coincidencias ........................................................................141Grupos de acciones................................................................................141

Consulta de rutas con enrutamiento basado en directivas............................142Configuración del enrutamiento basado en directivas ..................................143

Configuración de una lista de acceso extendida.....................................143Configuración de un grupo de coincidencias .........................................145Configuración de un grupo de acciones .................................................145Configuración de una directiva de PBR..................................................146Enlace de una directiva de enrutamiento basado en directivas..............146

Enlace de una directiva de enrutamiento basado en directivas a una interfaz ...........................................................................................146Enlace de una directiva de enrutamiento basado en directivas a una zona................................................................................................147Enlace de una directiva de enrutamiento basado en directivas a un enrutador virtual .............................................................................147

Contenido

Contenido

Visualización de la salida de enrutamiento basado en directivas..................147Visualización de una lista de acceso extendida ......................................147Visualización de un grupo de coincidencias ...........................................148Visualización de un grupo de acciones...................................................148Visualización de la configuración de una directiva de enrutamiento basado en directivas ..............................................................................149Visualización de la configuración completa de enrutamiento basado en directivas...............................................................................................150

Ejemplo de PBR avanzado ...........................................................................150Enrutamiento ........................................................................................152Elementos PBR......................................................................................153

Listas de acceso extendidas ............................................................153Grupos de coincidencias..................................................................154Grupos de acciones .........................................................................154Directivas de PBR............................................................................154

Asociación de interfaces ........................................................................155PBR avanzado con alta disponibilidad y posibilidad de ampliación ..............155

Solución de resistencia en PBR..............................................................155Solución con posibilidad de ampliación en PBR.....................................156

Capítulo 7 Enrutamiento multicast 157

Vista general ................................................................................................157Direcciones multicast ............................................................................158Reenvío por rutas inversas ....................................................................158

Enrutamiento multicast en dispositivos de seguridad...................................159Tabla de enrutamiento multicast ...........................................................159Configuración de una ruta multicast estática .........................................160Listas de acceso.....................................................................................161Configurar Encapsulado de enrutamiento genérico en interfaces de túnel ......................................................................................................161

Directivas multicast......................................................................................163

Capítulo 8 Protocolo de administración de grupos de Internet 165

Vista general ................................................................................................166Hosts .....................................................................................................166Enrutadores multicast............................................................................167

IGMP en dispositivos de seguridad ...............................................................167Habilitación e inhabilitación de IGMP en interfaces ...............................167

Habilitación de IGMP en una interfaz ..............................................168Desactivación de IGMP en una interfaz ...........................................168

Configuración de una lista de accesos para grupos aceptados ...............168Configuración de IGMP..........................................................................169Verificación de una configuración de IGMP ...........................................171Parámetros operativos de IGMP.............................................................172

Proxy de IGMP .............................................................................................173Informes de miembros en sentido ascendente hacia el origen ..............174Datos multicast en sentido descendente a los receptores ......................175Configuración del proxy de IGMP ..........................................................176Configuración de un proxy de IGMP en una interfaz..............................176Directivas multicast para configuraciones de IGMP y proxy de IGMP ....178

Creación de una directiva de grupo multicast para IGMP ................178Creación de una configuración de proxy de IGMP...........................178

Configuración de un proxy de remitente de IGMP .................................185

Contenido vii

viii


Capítulo 9 Multicast independiente de protocolo 191

Vista general ................................................................................................192PIM-SM..................................................................................................193

Árboles de distribución multicast ....................................................194Enrutador designado.......................................................................194Asignación de puntos de encuentro a grupos ..................................195Reenvío de tráfico a través del árbol de distribución .......................195

PIM-SSM ................................................................................................197Configuración de PIM-SM en dispositivos de seguridad................................198

Habilitación y eliminación de una instancia PIM-SM en un VR ..............199Habilitación de una instancia PIM-SM .............................................199Eliminación de una instancia PIM-SM .............................................199

Habilitación e inhabilitación de PIM-SM en interfaces............................200Habilitación de PIM-SM en una interfaz...........................................200Desactivación de PIM-SM en una interfaz........................................200

Directivas de grupo multicast ................................................................200Mensajes Static-RP-BSR...................................................................201Mensajes Join-Prune........................................................................201Definición de una directiva de grupo multicast para PIM-SM...........201

Ajuste de una configuración de PIM-SM básica.............................................202Verificación de la configuración ...................................................................207Configuración de puntos de encuentro.........................................................209

Configuración de un punto de encuentro estático..................................209Configuración de un punto de encuentro candidato ..............................210

Consideraciones sobre seguridad .................................................................211Restricción de grupos multicast .............................................................211Restricción de orígenes multicast ..........................................................212Restricción de puntos de encuentro.......................................................213

Parámetros de la interfaz PIM-SM ................................................................214Definición de una directiva vecina.........................................................214Definición de un límite bootstrap ..........................................................215

Configuración de un punto de encuentro del proxy .....................................215PIM-SM e IGMPv3 ........................................................................................225

Capítulo 10 Protocolo de descubrimiento de enrutador de ICMP 227

Vista general ................................................................................................227Configuración del protocolo de descubrimiento de enrutador de ICMP........228

Habilitación del protocolo de descubrimiento de enrutador de ICMP.....228Configuración del protocolo de descubrimiento del enrutador de ICMP desde WebUI .........................................................................................228Configuración del protocolo de descubrimiento del enrutador de ICMP desde CLI...............................................................................................229

Notificación de una interfaz ............................................................229Difusión de la dirección...................................................................229Configuración de un intervalo máximo de notificación ...................230Configuración de un intervalo mínimo de notificación....................230Configuración de un valor de duración de la notificación ................230Configuración de un retardo de respuesta.......................................230Configuración de un intervalo de notificación inicial .......................231Configuración de un número de paquetes de notificación inicial.....231

Contenido

Contenido

Deshabilitación de IRDP...............................................................................231Visualización de los ajustes de IRDP.............................................................231

Índice ........................................................................................................................IX-I

Contenido ix

x C


ontenido

Acerca de este volumen

El Volumen 7: Enrutamiento incluye las siguientes secciones:

El Capítulo 1, “Enrutamiento estático,” explica las tablas de rutas y cómo configurar las rutas estáticas para enrutamiento basado en los destinos, enrutamiento basado en la interfaz de origen o enrutamiento basado en orígenes.

El Capítulo 2, “Enrutamiento,” explica cómo configurar los enrutadores virtuales en los dispositivos de seguridad y cómo redistribuir las entradas de la tabla de enrutamiento entre protocolos o entre enrutadores virtuales.

El Capítulo 3, “Abrir primero la ruta más corta,” explica cómo configurar OSPF (abrir primero la ruta más corta).

El Capítulo 4, “Protocolo de información de enrutamiento,” explica cómo configurar el protocolo de información de enrutamiento (RIP).

El Capítulo 5, “Protocolo de puertas de enlace de límite,” explica cómo configurar el protocolo de puerta de enlace de límites (BGP).

El Capítulo 6, “Enrutamiento basado en directivas,” explica la manera de obligar al tráfico interesante a que siga una ruta específica en la red.

El Capítulo 7, “Enrutamiento multicast,” explica los fundamentos del enrutamiento multicast, incluyendo cómo configurar rutas multicast estáticas.

El , “Protocolo de administración de grupos de Internet,” explica cómo configurar el protocolo de gestión de grupos de Internet (IGMP).

El Capítulo 9, “Multicast independiente de protocolo,” explica cómo configurar la opción de multicast independiente de protocolo en modo Sparse (PIM-SM) y multicast independiente de protocolo - multicast de origen específico (PIM-SSM).

El Capítulo 10, “Protocolo de descubrimiento de enrutador de ICMP,” explica la forma de configurar un intercambio de mensajes del protocolo de mensajes de control de Internet (ICMP) entre un host y un enrutador.

xi


xii

Convenciones del documento

Este documento utiliza las convenciones descritas en las secciones siguientes:

“Convenciones de la interfaz de usuario web” en esta página

“Convenciones de interfaz de línea de comandos” en esta página

“Convenciones de nomenclatura y conjuntos de caracteres” en la página xiii

“Convenciones para las ilustraciones” en la página xiv

Convenciones de la interfaz de usuario webEn la interfaz de usuario web (WebUI), el conjunto de instrucciones de cada tarea se divide en ruta de navegación y establecimientos de configuración. Para abrir una página de WebUI e introducir parámetros de configuración, navegue hacia la página en cuestión haciendo clic en un elemento del menú en el árbol de navegación en el lado izquierdo de la pantalla, luego en los elementos subsiguientes. A medida que avanza, su ruta de navegación aparece en la parte superior de la pantalla, cada página separada por signos de mayor y menor.

Lo siguiente muestra los parámetros y ruta de WebUI para la definición de una dirección:

Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:

Address Name: dir_1IP Address/Domain Name:

IP/Netmask: (seleccione), 10.2.2.5/32Zone: Untrust

Para abrir la ayuda en línea para los ajustes de configuración, haga clic en el signo de interrogación (?) en la parte superior izquierda de la pantalla.

El árbol de navegación también proporciona una página de configuración de Ayuda > Guía de configuración para ayudarle a configurar las directivas de seguridad y la Seguridad de protocolo de Internet (IPSec). Seleccione una opción del menú desplegable y siga las instrucciones en la página. Haga clic en el carácter ? en la parte superior izquierda para la Ayuda en línea en la Guía de configuración.

Convenciones de interfaz de línea de comandosLas siguientes convenciones se utilizan para presentar la sintaxis de los comandos de interfaz de línea de comandos (CLI) en ejemplos y en texto.

En ejemplos:

Los elementos entre corchetes [ ] son opcionales.

Los elementos entre llaves { } son obligatorios.



Si existen dos o más opciones alternativas, aparecerán separadas entre sí por barras verticales ( | ). Por ejemplo:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

Las variables aparecen en cursiva:

set admin user nombre1 contraseña xyz

En el texto, los comandos están en negrita y las variables en cursiva.

Convenciones de nomenclatura y conjuntos de caracteresScreenOS emplea las siguientes convenciones relativas a los nombres de objetos (como direcciones, usuarios administradores, servidores de autenticación, puertas de enlace IKE, sistemas virtuales, túneles de VPN y zonas) definidos en las configuraciones de ScreenOS:

Si una cadena de nombre tiene uno o más espacios, la cadena completa deberá estar entre comillas dobles; por ejemplo:

set address trust “local LAN” 10.1.1.0/24

Cualquier espacio al comienzo o al final de una cadena entrecomillada se elimina; por ejemplo, “ local LAN ” se transformará en “local LAN”.

Los espacios consecutivos múltiples se tratan como uno solo.

En las cadenas de nombres se distingue entre mayúsculas y minúsculas; por el contrario, en muchas palabras clave de CLI pueden utilizarse indistintamente. Por ejemplo, “local LAN” es distinto de “local lan”.

ScreenOS admite los siguientes conjuntos de caracteres:

Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de múltiples bytes (MBCS). Algunos ejemplos de SBCS son los conjuntos de caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS, también conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran el chino, el coreano y el japonés.

Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepción de las comillas dobles ( “ ), que tienen un significado especial como delimitadores de cadenas de nombres que contengan espacios.

NOTA: Para introducir palabras clave, basta con introducir los primeros caracteres para identificar la palabra de forma inequívoca. Al escribir set adm u whee j12fmt54 se ingresará el comando set admin user wheezer j12fmt54. Sin embargo, todos los comandos documentados aquí se encuentran presentes en su totalidad.

NOTA: Una conexión de consola sólo admite conjuntos SBCS. La WebUI admite tanto SBCS como MBCS, según el conjunto de caracteres que admita el explorador.

Convenciones del documento xiii


xiv

Convenciones para las ilustracionesLa siguiente figura muestra el conjunto básico de imágenes utilizado en las ilustraciones de este volumen:

Figura 1: Imágenes de las ilustraciones

Sistema autónomoo biendominio de enrutamiento virtual

Interfaces de zonas de seguridad:Blanco = Interfaz de zona protegida (ejemplo = zona Trust)Negro = Interfaz de zona externa(ejemplo = zona Untrust)

Dispositivos de seguridad Juniper Networks

Concentrador

Conmutador

Enrutador

Servidor

Túnel VPN

Dispositivo de red genérico

Rango dinámico de IP (DIP)Internet

Red de área local (LAN) con una única subredo bienzona de seguridad

Interfaz de túnel

Motor de directivas



Asistencia y documentación técnica

Para obtener documentación técnica sobre cualquier producto de Juniper Networks, visite www.juniper.net/techpubs/.

Para obtener soporte técnico, abra un expediente de soporte utilizando el vínculo “Case Manager” en la página web http://www.juniper.net/customers/support/ o llame al teléfono 1-888-314-JTAC (si llama desde los EE.UU.) o al +1-408-745-9500 (si llama desde fuera de los EE.UU.).

Si encuentra algún error u omisión en este documento, póngase en contacto con Juniper Networks al [email protected].

Asistencia y documentación técnica xv

http://www.juniper.net/techpubs/

http://www.juniper.net/customers/support/

mailto:[email protected]


xvi
Asistencia y documentación técnica

Capítulo 1

Enrutamiento estático

Este capítulo explica el enrutamiento estático y explica cuándo y cómo configurar rutas estáticas. Incluye las siguientes secciones:

“Vista general” en esta página

“Cómo funciona el enrutamiento estático” en la página 2

“Cuándo configurar rutas estáticas” en la página 3

“Configuración de rutas estáticas” en la página 4

“Habilitación del seguimiento de puertas de enlace” en la página 9

“Reenvío de tráfico a la interfaz Null” en la página 10

“Impedir las consultas de rutas en otras tablas de enrutamiento” en la página 10

“Impedir que el tráfico de túnel se envíe a través de interfaces que no sean de túnel” en la página 10

“Evitar bucles creados por las rutas resumidas” en la página 11

“Rutas permanentemente activas” en la página 11

“Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de igual coste” en la página 12

Vista general

Una ruta estática es una asignación configurada manualmente de una dirección de red IP a un destino de salto siguiente (otro enrutador) que define en un dispositivo de reenvío de capa 3, como un enrutador.

En una red que tiene pocas conexiones a otras redes o en las redes cuyas interconexiones de red son relativamente estables, suele resultar más práctico definir rutas estáticas que rutas dinámicas. ScreenOS mantiene las rutas estáticas hasta que se eliminan explícitamente. No obstante, cuando sea necesario se puede dar prioridad a rutas dinámicas frente a las estáticas.

1


2

Puede ver rutas estáticas en la tabla de enrutamiento de ScreenOS. Para forzar el equilibrio de cargas, puede configurar en enrutamiento multidireccional de igual coste (ECMP). Para utilizar únicamente puertas de enlace activas, puede establecer el seguimiento de las puertas de enlace.

Debe establecer por lo menos una ruta predeterminada como una ruta predeterminada (dirección de red 0.0.0.0/0). Una ruta predeterminada es una entrada comodín para los paquetes destinados a redes distintas de las definidas en la tabla de enrutamiento.

Cómo funciona el enrutamiento estáticoCuando un host envía paquetes a un host de otra red, cada encabezado de paquete contiene la dirección del host de destino. Cuando un enrutador recibe un paquete, compara la dirección de destino con todas las direcciones existentes en la tabla de enrutamiento. El enrutador selecciona en la tabla la ruta más específica a la dirección de destino y, a partir de la entrada de ruta seleccionada, determina el siguiente salto (“next-hop”) al que debe reenviar el paquete.

La Figura 2 representa una red que utiliza enrutamiento estático y un ejemplo de paquete IP. En este ejemplo, el host 1 de la red A desea acceder al host 2 de la red C. El paquete que se enviará incluye los siguientes datos en el encabezado:

Dirección IP de origen

Dirección IP de destino

Carga (mensaje)

Figura 2: Ejemplo de enrutamiento estático

NOTA: La ruta más específica se determina aplicando en primer lugar el operador lógico AND bit por bit a la dirección de destino y a la máscara de red de cada entrada existente en la tabla de enrutamiento. Por ejemplo, el AND lógico bit por bit de la dirección IP 10.1.1.1 con la máscara de subred 255.255.255.0 es 10.1.1.0. La ruta que tenga el mayor número de bits con el valor 1 en la máscara de subred será la más específica (también denominada “ruta con la mayor coincidencia”).

IP ORIG

IPDEST

Host 1 Host 2 Carga de datos

Red A Red B Red C

Host 1

Enrutador X

Enrutador Y

Enrutador Z Host 2

Vista general

Capítulo 1: Enrutamiento estático

La Tabla 1 resume la tabla de enrutamiento de cada enrutador.

Tabla 1: Resumen de la tabla de enrutamiento para los enrutadores X, Y y Z

En la Tabla 1, el enrutador X tiene configurada una ruta estática hacia la red C con la puerta de enlace (siguiente salto) como enrutador Y. Cuando el enrutador X recibe el paquete destinado al host 2 de la red C, compara la dirección de destino del paquete con el contenido de su tabla de enrutamiento y detecta que la última entrada corresponde a la ruta más específica para la dirección de destino. En la última entrada de ruta se especifica que el tráfico destinado a la red C debe enviarse al enrutador Y para su entrega. El enrutador Y recibe el paquete y, como sabe que la red C está conectada directamente, envía el paquete a través de la interfaz conectada a esa red.

Si el enrutador Y falla o si la conexión entre el enrutador Y y la red C deja de estar disponible, el paquete no puede alcanzar el host 2. Aunque existe otra ruta hacia la red C a través del enrutador Z, no está configurada de forma estática en el enrutador X, por lo que éste no detecta la ruta alternativa.

Cuándo configurar rutas estáticasTiene que definir por lo menos algunas rutas estáticas incluso cuando utilice protocolos de enrutamiento dinámicos. Es necesario definir rutas estáticas cuando se cumplen condiciones como las siguientes:

Para agregar una ruta predeterminada (0.0.0.0/0) a la tabla de enrutamiento de un enrutador virtual (VR) es necesario definir una ruta estática. Por ejemplo, si está utilizando dos VR en el mismo dispositivo de seguridad, la tabla de enrutamiento de trust-vr podría contener una ruta predeterminada que especificaría untrust-vr como el salto siguiente. Esto permitiría enrutar hacia untrust-vr el tráfico destinado a direcciones no expresadas en la tabla de enrutamiento de trust-vr. También puede definir una ruta predeterminada en untrust-vr para desviar el tráfico de la dirección IP específica a direcciones no encontradas en la tabla de enrutamiento de untrust-vr.

Si una red no está conectada directamente con el dispositivo de seguridad pero es accesible a través de un enrutador de una interfaz contenida en un enrutador virtual (VR), debe definirse una ruta estática hacia la red que contenga la dirección IP del enrutador. Por ejemplo, la interfaz de zona Untrust puede ser una subred con dos enrutadores, cada uno de los cuales se conecta a diferentes proveedores de servicio de Internet (ISP). Debe definir cuál enrutador va a utilizar para reenviar el tráfico a ISP específicos.

Enrutador X Enrutador Y Enrutador Z

RedPuerta de enlace Red

Puerta de enlace Red

Puerta de enlace

Red A Conectada Red A Enrutador X Red A Enrutador X

Red B Conectada Red B Conectada Red B Conectada

Red C Enrutador Y Red C Conectada Red C Conectada

Vista general 3


4

Si está utilizando dos VR en el mismo dispositivo de seguridad y llega tráfico entrante a una interfaz de untrust-vr destinado a una red conectada a una interfaz de trust-vr, deberá definir una entrada estática en la tabla de enrutamiento de untrust-vr para la red de destino, indicando trust-vr como salto siguiente. Puede evitar establecer una ruta estática en este caso, si exporta las rutas de trust-vr a untrust-vr.

Cuando el dispositivo funciona en modo transparente, es necesario definir rutas estáticas que dirijan el tráfico administrativo originado en el dispositivo mismo (distinto del tráfico de usuario que pasa por el cortafuegos) a los destinos remotos. Por ejemplo, deberá definir rutas estáticas que dirijan los mensajes de syslog, SNMP y WebTrends a la dirección de un administrador remoto. También deberá definir rutas que dirijan las peticiones de autenticación a los servidores RADIUS, SecurID y LDAP, y las comprobaciones de URL al servidor Websense.

Para el tráfico de red privada virtual (VPN) saliente donde exista más de una interfaz de salida hacia el destino, deberá establecer una ruta para dirigir el tráfico saliente al enrutador externo a través de la interfaz deseada.

Si una interfaz en una zona de seguridad de trust-vr es NAT, y si esa interfaz tiene configurada una IP asignada (MIP) o IP virtual (VIP) para recibir tráfico procedente de un origen en el dominio de enrutamiento untrust-vr, deberá crear una ruta a la MIP o VIP en untrust-vr que apunte a trust-vr como puerta de enlace.

De forma predeterminada, el dispositivo de seguridad utiliza direcciones IP de destino para encontrar la mejor ruta por la que reenviar paquetes. En un VR, también puede habilitar tablas de enrutamiento basadas en orígenes o basadas en interfaces de origen. Ambas tablas de enrutamiento, las basadas en orígenes y las basadas en interfaces de origen, contienen las rutas estáticas que usted configura en el VR.

Configuración de rutas estáticasPara configurar una ruta estática se necesita definir lo siguiente:

Enrutador virtual (VR) al que pertenece la ruta.

La dirección IP y la máscara de red de la red de destino.

El salto siguiente para la ruta, que puede ser otro VR en el dispositivo de seguridad o la dirección IP de una puerta de enlace (enrutador). Si especifica otro VR, asegúrese de que en su tabla de enrutamiento exista una entrada para la red de destino.

NOTA: Cuando el dispositivo de seguridad trabaja en modo transparente, es necesario definir una ruta estática para el tráfico administrativo generado por el dispositivo incluso aunque el destino se encuentre en la misma subred que éste.

Vista general


La interfaz a través de la cual se reenvía el tráfico enrutado. La interfaz puede ser cualquier interfaz compatible con ScreenOS, como una interfaz física (por ejemplo, ethernet1/2) o una interfaz de túnel. También puede especificar la interfaz Null para determinadas aplicaciones. Consulte la “Reenvío de tráfico a la interfaz Null” en la página 10.

Opcionalmente, puede definir los siguientes elementos:

La métrica de ruta se utiliza para seleccionar la ruta activa cuando existen varias rutas hacia la misma red de destino y todas con el mismo valor de preferencia. La métrica predeterminada para las rutas estáticas es 1.

Una etiqueta de ruta es un valor que se puede utilizar como filtro al redistribuir rutas. Por ejemplo, puede seleccionar importar solamente aquellas rutas que contengan valores de etiqueta especificados a un VR.

Valor de preferencia para la ruta. De forma predeterminada, todas las rutas estáticas tienen el mismo valor de preferencia que se establece en el VR.

Si la ruta es permanente (se mantiene activa aunque la interfaz del reenvío esté inactiva o se haya eliminado la dirección IP de la interfaz).

Esta sección contiene los siguientes ejemplos:

“Ajuste de rutas estáticas” en la página 5

“Establecimiento de una ruta estática para una interfaz de túnel” en la página 8

Ajuste de rutas estáticasEn la Figura 3 en la página 6, un dispositivo de seguridad que opera con su interfaz de zona Trust en modo de traducción de direcciones de red (NAT) protege una red de múltiples niveles. Se utiliza tanto administración local como remota (a través de NetScreen-Security Manager). El dispositivo de seguridad envía capturas SNMP e informes syslog al administrador local (situado en una red de la zona Trust) y envía informes de NetScreen-Security Manager al administrador remoto (situado en una red de la zona Untrust). El dispositivo utiliza un servidor SecurID en la zona desmilitarizada (DMZ) para autenticar usuarios y un servidor Websense en la zona Trust para realizar el filtrado de web.

Las tablas de enrutamiento trust-vr y untrust-vr deben incluir rutas para los siguientes destinos:

untrust-vr

1. Puerta de enlace predeterminada hacia Internet (ruta predeterminada para el VR)

2. Administrador remoto en la subred 3.3.3.0/24

NOTA: Las siguientes zonas deben vincularse antes de que se complete este ejemplo: ethernet1 a la zona Trust, ethernet2 a la zona DMZ y ethernet3 a la zona Untrust. Las direcciones IP de las interfaces son 10.1.1.1/24, 2.2.10.1/24 y 2.2.2.1/24, respectivamente.

Vista general 5


6

Rutaprede

3. La subred 2.2.40.0/24 en DMZ

4. La subred 2.20.0.0/16 en DMZ

trust-vr

5. untrust-vr para todas las direcciones no encontradas en la tabla de enrutamiento de trust-vr (ruta predeterminada para el VR)

6. La subred 10.10.0.0/16 en la zona Trust



Figura 3: Configuración de rutas estáticas

10.10.30.0/24 10.10.40.0/24

10.1.1.0/24

2.2.2.2/24200.20.2.2/24

3.3.3.10/32

2.2.2.0/24

3.3.3.0/24

3.3.3.1/242.2.2.3/24

10.20.1.0/24

10.30.1.0/24

10.20.3.0/24 10.20.4.0/24

10.10.30.5/3210.30.4.7/32

10.1.1.2/24 10.1.1.4/24

10.1.1.3/2410.10.30.1/24

10.20.4.1/2410.20.3.1/2410.20.1.1/24

10.30.1.1/24

10.20.1.1/2410.10.30.1/24

76 8

3

4

2

2.2.10.0/24

2.2.10.0/242.2.40.1/24

2.2.10.3/242.20.30.1/24

2.2.40.0/24 2.20.30.0/24

2.20.30.2/242.20.3.1/242.20.4.1/24

2.20.4.0/242.20.3.0/24

2.2.45.7/32

1

Dominio de enrutamiento virtual

Internet

Dispositivo de seguridad

= Enrutador

trust-vr

Dominio del enrutador virtual

Zona Trust

Administración local Servidor Websense

Administración remotaNetScreen-Security Manager

DMZ

Zona Untrust

untrust-vr

5 terminada

= Conmutador/concentrador

Vista general


WebUI

1. untrust-vrNetwork > Routing > Destination > untrust-vr New: Introduzca los siguientes datos para crear la puerta de enlace predeterminada untrust y haga clic en OK:

Network Address/Netmask: 0.0.0.0/0Gateway: (seleccione)

Interface: ethernet3Gateway IP Address: 2.2.2.2

Network > Routing > Destination> untrust-vr New: Introduzca los siguientes datos para dirigir los informes del sistema generados por el dispositivo de seguridad a la administración remota, luego haga clic en OK:



Network > Routing > Destination > untrust-vr New: Introduzca los siguientes datos y haga clic en OK:



Network > Routing > Destination > untrust-vr New: Introduzca los siguientes datos y haga clic en OK:



2. trust-vrNetwork > Routing > Destination > trust-vr New: Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 0.0.0.0/0Next Hop Virtual Router Name: (seleccione); untrust-vr

Network > Routing > Destination > trust-vr New: Introduzca los siguientes datos y haga clic en OK:






Vista general 7


8




CLI

1. untrust-vrset vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.2 set vrouter untrust-vr route 3.3.3.0/24 interface ethernet3 gateway 2.2.2.3set vrouter untrust-vr route 2.2.40.0/24 interface ethernet2 gateway 2.2.10.2set vrouter untrust-vr route 2.20.0.0/16 interface ethernet2 gateway 2.2.10.3

2. trust-vrset vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vrset vrouter trust-vr route 10.10.0.0/16 interface ethernet1 gateway 10.1.1.2set vrouter trust-vr route 10.20.0.0/16 interface ethernet1 gateway 10.1.1.3set vrouter trust-vr route 10.30.1.0/24 interface ethernet1 gateway 10.1.1.4save

Establecimiento de una ruta estática para una interfaz de túnelEn la Figura 4, un host fiable reside en una subred diferente de la interfaz fiable. Un servidor del protocolo de transferencia de archivos (FTP) recibe tráfico a través de un túnel VPN. Se necesita establecer una ruta estática para dirigir el tráfico que sale por la interfaz de túnel al enrutador interno que conduce a la subred donde reside el servidor.

Figura 4: Ruta estática para una interfaz Tunnel

NOTA: Para eliminar una entrada, haga clic en Remove. Aparecerá un mensaje pidiendo confirmación para realizar la eliminación. Haga clic en OK para continuar o en Cancel para cancelar la acción.

Zona Trust

Interfaz Trustethernet110.1.1.1/24

Interfaz Untrustethernet31.1.1.1/24

Zona Untrust

Servidor FTP 10.2.2.5

Internet

Túnel VPN

tunnel.110.10.1.1/24

Enrutador1.1.1.250

Vista general


WebUI



Interface: tunnel.1Gateway IP Address: 0.0.0.0




CLI

set vrouter trust-vr route 10.2.2.5/32 interface tunnel.1set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250save

Habilitación del seguimiento de puertas de enlaceEl dispositivo de seguridad permite que se dé seguimiento a las rutas estáticas independientes de la interfaz con puertas de enlace para obtener accesibilidad. No se da seguimiento a las rutas estáticas de forma predeterminada, pero es posible configurar un dispositivo de seguridad para dar seguimiento a la accesibilidad de las rutas de las puertas de enlace. El dispositivo registra las rutas sometidas a seguimiento según estén activas o inactivas, dependiendo de la accesibilidad de cada puerta de enlace. Por ejemplo, si no se puede obtener acceso a una puerta de enlace, el dispositivo de seguridad cambia la ruta a inactiva. Cuando la puerta de enlace se vuelve a activar, la ruta se invierte a activa.

Para agregar una ruta estática con el seguimiento de la puerta de enlace, deberá establecer explícitamente la ruta a nivel del enrutador virtual (VR) y en la dirección de la puerta de enlace. No establezca una dirección IP para la interfaz.

Puede utilizar este comando para agregar una ruta estática con una puerta de enlace de seguimiento para la dirección IP 1.1.1.254 con prefijo 1.1.1.0 y una longitud de 24. Establezca el seguimiento de la puerta de enlace introduciendo la dirección IP de la puerta de enlace pero no establezca la interfaz.

WebUI

Network > Routing > Destination: Haga clic en New y luego introduzca lo siguiente:

IPv4/Netmask: 1.1.1.0/24Gateway: (seleccione)Gateway IP Address: 1.1.1.254

NOTA: Para que el tunnel.1 aparezca en la lista desplegable Interface, debe crear primero la interfaz tunnel.1.

Vista general 9


10

CLI

set vrouter trust route 1.1.1.0/24 gateway 1.1.1.254unset vrouter trust route 1.1.1.0/24 gateway 1.1.1.254save

Reenvío de tráfico a la interfaz Null

Puede configurar rutas estáticas usando la interfaz Null como interfaz de salida. La interfaz Null siempre se considera activa y el tráfico destinado a la interfaz Null siempre se descarta. Para convertir la ruta a la interfaz Null en una ruta de último recurso, defínala con una métrica más alta que la de las demás rutas. Las rutas estáticas que reenvían tráfico a la interfaz Null se utilizan principalmente con tres objetivos:

Impedir la consulta de rutas en otras tablas de enrutamiento

Impedir que el tráfico del túnel se envíe en interfaces que no sean de túnel

Evitar bucles de tráfico

Impedir las consultas de rutas en otras tablas de enrutamientoSi se habilita el enrutamiento basado en interfaz de origen, de forma predeterminada el dispositivo de seguridad realiza operaciones de consulta en la tabla de enrutamiento basada en la interfaz de origen. (Para obtener información sobre la configuración del enrutamiento basado interfaz de origen, consulte “Tabla de enrutamiento según la interfaz de origen” en la página 20.) Si la ruta no se encuentra en la tabla de enrutamiento basada en la interfaz de origen y si el enrutamiento basado en el origen no está activado, el dispositivo de seguridad realiza operaciones de consulta de rutas en la tabla de enrutamiento basada en el origen. Si la ruta no se encuentra en la tabla de enrutamiento basada en el origen, el dispositivo de seguridad realiza operaciones de consulta de la ruta en la tabla de enrutamiento basada en los destinos. Si desea evitar las operaciones de consulta de rutas en la tabla de enrutamiento basada en el origen o en la tabla de enrutamiento basada en los destinos, puede crear una ruta predeterminada en la tabla de enrutamiento basada en le interfaz de origen con la interfaz Null como la interfaz de salida. Utilice una métrica más alta que el resto de las rutas para asegurar que esta ruta sólo se utilice si no existe ninguna otra ruta basada en la interfaz que coincida con la ruta.

Impedir que el tráfico de túnel se envíe a través de interfaces que no sean de túnelPuede utilizar las rutas estáticas o dinámicas con las interfaces de túnel de salida para encriptar el tráfico dirigido a destinos específicos. Si una interfaz de túnel se queda inactiva, todas las rutas definidas en la interfaz se quedan inactivas. Si hay una ruta alternativa en una interfaz que no sea de túnel, el tráfico no se envía encriptado. Para impedir que el tráfico que debe estar encriptado se envíe a una interfaz que no sea de túnel, defina una ruta estática al mismo destino que el tráfico del túnel con la interfaz Null como interfaz de salida. Asigne a esta ruta una métrica más alta que la de la ruta de la interfaz de túnel de modo que la ruta solamente se active si la ruta de la interfaz de túnel no está disponible. Si la interfaz de túnel se queda inactiva, la ruta con la interfaz Null se activa y el tráfico para el destino del túnel se descarta.

Reenvío de tráfico a la interfaz Null


Evitar bucles creados por las rutas resumidasCuando el dispositivo de seguridad anuncia rutas resumidas, es posible que el dispositivo reciba el tráfico destinado a prefijos que no se encuentran en sus tablas de enrutamiento. Puede reenviar el tráfico basado en su ruta predeterminada. El enrutador de recepción puede reenviar el tráfico de nuevo al dispositivo de seguridad debido a el anuncio de la ruta resumida. Para evitar dichos bucles, puede definir una ruta estática para el prefijo de la ruta resumida con la interfaz Null como la interfaz de salida y una métrica de ruta alta. Si el dispositivo de seguridad recibe el tráfico para los prefijos que se encuentren en su anuncio de ruta resumida pero no en sus tablas de enrutamiento, se descarta el tráfico.

En este ejemplo establecerá una interfaz NULL para la ruta resumida creada hacia la red 2.1.1.0/24 del ejemplo anterior. Dentro de la red 2.1.1.0/24 se encuentran los hosts 2.1.1.2, 2.1.1.3 y 2.1.1.4. Cualquier paquete dirigido a 2.1.1.10 caerá en el rango de la ruta resumida. El dispositivo de seguridad acepta estos paquetes pero no tiene a dónde reenviarlos, salvo de vuelta al origen, lo que inicia un bucle de red. Para evitar este comportamiento, establecerá una interfaz NULL para esta ruta. Establecer una preferencia y métrica elevadas es importante al establecer una interfaz NULL.

WebUI



Interface: NullGateway IP Address: 0.0.0.0Preference: 255Metric: 65535

CLI

set vrouter trust-vr route 2.1.1.0/24 interface null preference 255 metric 65535save

Rutas permanentemente activas

Hay ciertas situaciones en las que posiblemente desee que una ruta mantenga su estado activo en una tabla de enrutamiento incluso si la interfaz física asociada a la ruta se queda inactiva o no tiene una dirección IP asignada. Por ejemplo, un servidor XAuth puede asignar una dirección IP a una interfaz en un dispositivo de seguridad siempre que se necesite enviar tráfico al servidor. La ruta hacia el servidor de XAuth debe mantenerse activa incluso cuando no haya dirección IP asignada en la interfaz de modo que el tráfico que está destinado al servidor XAuth no se descarte.

También es útil mantener activas las rutas a través de las interfaces en las que se configura el seguimiento de IP. El seguimiento de IP permite que el dispositivo de seguridad reencamine el tráfico saliente a través de una interfaz diferente si las direcciones IP de destino no se pueden alcanzar a través de la interfaz original. Aunque el dispositivo de seguridad puede reencaminar el tráfico a otra interfaz, necesita ser capaz de enviar peticiones del comando ping en la interfaz original para determinar si los destinos llegan a ser otra vez accesibles.

Rutas permanentemente activas 11


12

Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de igual coste

También puede cambiar la preferencia de enrutamiento de las rutas estáticas con enrutamiento multidireccional de igual coste (Equal Cost Multipath, ECMP). Consulte “Configuración del enrutamiento multidireccional de igual coste” en la página 36 para obtener más información.

Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de igual coste

Capítulo 2

Enrutamiento

Este capítulo describe la administración del enrutamiento y del enrutador virtual (VR). Incluye las siguientes secciones:

“Vista general” en la página 14

“Tablas de enrutamiento del enrutador virtual” en la página 15

“Tabla de enrutamiento basada en destinos” en la página 16

“Tabla de enrutamiento basada en el origen” en la página 18

“Tabla de enrutamiento según la interfaz de origen” en la página 20

“Creación y modificación de enrutadores virtuales” en la página 22

“Modificación de enrutadores virtuales” en la página 22

“Asignación de una ID de enrutador virtual” en la página 23

“Reenvío de tráfico entre enrutadores virtuales” en la página 24

“Configuración de dos enrutadores virtuales” en la página 24

“Creación y eliminación de enrutadores virtuales” en la página 26

“Enrutadores virtuales y sistemas virtuales” en la página 27

“Limitación del número máximo de entradas de la tabla de enrutamiento” en la página 30

“Ejemplos y funciones del enrutamiento” en la página 30

“Selección de rutas” en la página 31

“Configuración del enrutamiento multidireccional de igual coste” en la página 36

“Redistribución de rutas” en la página 38

“Exportación e importación de rutas entre enrutadores virtuales” en la página 43

13


14

Vista general

El enrutamiento es el proceso de reenviar paquetes de una red a otra hasta que alcanzan su destino final. Un enrutador es un dispositivo que está donde una red se encuentra con otra y dirige el tráfico entre esas redes.

De forma predeterminada, un dispositivo de seguridad entra al modo de funcionamiento de ruta y opera como un enrutador de capa 3. Sin embargo, puede configurar un dispositivo de seguridad para que funcione en modo transparente como un conmutador de capa 2.

Los dispositivos de seguridad de Juniper Networks logran enturarse a través de un proceso llamado enrutador virtual (VR). Un dispositivo de seguridad divide sus componentes de enrutamiento en dos o más VR y cada VR mantiene su propia lista de redes conocidas en forma de una tabla de enrutamiento, lógica de enrutamiento y zonas de seguridad relacionadas. Un solo VR puede admitir una o más de las siguientes rutas:

Rutas estáticas o configuradas manualmente

Rutas dinámicas, como las que se aprenden por medio de un protocolo de enrutamiento dinámico

Rutas multicast, como una ruta a un grupo de máquinas host

Los dispositivos de seguridad de Juniper Networks tienen dos VR predefinidos:

trust-vr, que de forma predeterminada contiene todas las zonas de seguridad predefinidas y todas las zonas definidas por el usuario

untrust-vr, que de forma predeterminada no contiene ninguna zona de seguridad

No puede eliminar los enrutadores virtuales trust-vr ni untrust-vr. Pueden existir varios VR, pero trust-vr es el predeterminado. En la tabla de VR, un asterisco (*) indica que trust-vr es el VR predeterminado en la interfaz de línea de comandos (CLI). Puede ver la tabla de VR ejecutando el comando CLI get vrouter. Para configurar zonas e interfaces en otros VR, debe especificar el VR por nombre, por ejemplo untrust-vr. Para obtener información sobre las zonas, consulte “Zonas” en la página 2-25.

Algunos dispositivos de seguridad le permiten crear otros VR personalizados. Al separar la información de enrutamiento en varios VR, podrá controlar cuánta información sobre enrutamiento puede ver en otros dominios de enrutamiento. Por ejemplo, puede mantener la información de enrutamiento de todas las zonas de seguridad de una red corporativa en el VR predefinido trust-vr y la información de enrutamiento de todas las zonas fuera de la red corporativa en el otro VR predefinido untrust-vr. Puede mantener la información sobre enrutamiento de redes internas separada de los orígenes no fiables afuera de la empresa porque los detalles de la tabla de enrutamiento de un VR no se pueden ver en la otra.

NOTA: En cualquier modo de funcionamiento, tendrá que configurar manualmente algunas rutas.

Vista general

Capítulo 2: Enrutamiento

Tablas de enrutamiento del enrutador virtual

En un dispositivo de seguridad, cada VR mantiene sus propias tablas de enrutamiento. Una tabla de enrutamiento es una lista actualizada de redes y direcciones conocidas, desde donde se puede obtener acceso a éstas. Cuando un dispositivo de seguridad procesa un paquete entrante, realiza una consulta en la tabla de enrutamiento para buscar la interfaz correspondiente que conduzca a la dirección de destino.

Cada entrada de la tabla de enrutamiento identifica la red destino a la que se puede reenviar el tráfico. La red destino puede ser una red IP, una subred, una supernet o un host. Cada entrada de la tabla de enrutamiento puede ser unicast (paquete enviado a una sola dirección IP que hace referencia a una sola máquina host) o multicast (paquete enviado a una sola dirección IP que hace referencia a varias máquinas host).

Las entradas de la tabla de enrutamiento pueden provenir de los siguientes orígenes:

Redes interconectadas directamente (la red de destino es la dirección IP que asigna a una interfaz en el modo de ruta)

Protocolos de enrutamiento dinámico, como protocolo de abrir primero la ruta más corta (OSPF), el protocolo de puerta de enlace de límites (BGP) o el protocolo de información de enrutamiento (RIP)

Otros enrutadores o enrutadores virtuales en forma de rutas importadas

Rutas configuradas estáticamente

Rutas host

Un VR admite tres tipos de tablas de enrutamiento:

La tabla de enrutamiento basada en destinos permite al dispositivo de seguridad realizar operaciones de consulta de rutas basándose en la dirección IP de destino de un paquete de datos entrante. De forma predeterminada, el dispositivo de seguridad utiliza únicamente direcciones IP de destino para encontrar la mejor ruta por la cual reenviar paquetes.

La tabla de enrutamiento basada en orígenes permite al dispositivo de seguridad realizar operaciones de consulta de rutas basándose en la dirección IP de origen de un paquete de datos entrante. Para agregar entradas a la tabla de enrutamiento basada en orígenes, debe configurar rutas estáticas para direcciones de origen específicas en las que el dispositivo de seguridad puede realizar operaciones de consulta de rutas. De forma predeterminada, esta tabla de enrutamiento está inhabilitada. Consulte “Tabla de enrutamiento basada en el origen” en la página 18.

NOTA: Cuando establece una dirección IP para identificar una interfaz en el modo de ruta, la tabla de enrutamiento conecta automáticamente una ruta hacia la subred adyacente para canalizar el tráfico que pasa por la interfaz.

Tablas de enrutamiento del enrutador virtual 15


16

La tabla de enrutamiento basada en orígenes permite al dispositivo de seguridad realizar las operaciones de consulta de rutas basándose en la interfaz por la cual un paquete de datos entra al dispositivo. Para agregar entradas a la tabla de enrutamiento basada en orígenes, debe configurar rutas estáticas para determinadas interfaces en las que el VR realiza operaciones de consulta de rutas. De forma predeterminada, esta tabla de enrutamiento está inhabilitada. Consulte “Tabla de enrutamiento según la interfaz de origen” en la página 20.

Tabla de enrutamiento basada en destinosLa tabla de enrutamiento basada en destinos está siempre presente en un VR. Además, puede habilitar las tablas de enrutamiento basadas en orígenes o basadas en interfaces de origen, o ambas, en un VR. El siguiente es un ejemplo de tablas de enrutamiento con base en el destino de ScreenOS:

device-> get route

IPv4 Dest-Routes for <untrust-vr> (0 entries)--------------------------------------------------------------------------------H: Host C: Connected S: Static A: Auto-ExportedI: Imported R: RIP P: Permanent D: Auto-DiscoverediB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1E2: OSPF external type 2

IPv4 Dest-Routes for <trust-vr> (11 entries)-------------------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys--------------------------------------------------------------------------------* 8 0.0.0.0/0 eth1/1 10.100.37.1 S 20 1 Root* 7 1.1.1.1/32 eth1/2 0.0.0.0 H 0 0 Root* 3 192.168.1.1/32 mgt 0.0.0.0 H 0 0 Root* 2 192.168.1.0/24 mgt 0.0.0.0 C 0 0 Root* 4 10.100.37.0/24 eth1/1 0.0.0.0 C 0 0 Root* 5 10.100.37.170/32 eth1/1 0.0.0.0 H 0 0 Root* 6 1.1.1.0/24 eth1/2 0.0.0.0 C 0 0 Root* 9 11.3.3.0/24 agg1 0.0.0.0 C 0 0 Root* 10 11.3.3.0/32 agg1 0.0.0.0 H 0 0 Root* 11 3.3.3.0/24 tun.1 0.0.0.0 C 0 0 Root* 12 3.3.3.0/32 tun.1 0.0.0.0 H 0 0 Root

La tabla de enrutamiento contiene la siguiente información de cada red de destino:

La interfaz del dispositivo de seguridad a través del que se reenvía el tráfico a la red de destino.

El siguiente salto (next-hop), que puede ser otro VR en el dispositivo de seguridad o la dirección IP de una puerta de enlace (normalmente la dirección de un enrutador).

El protocolo del cual se deriva la ruta. La columna del protocolo de la tabla de enrutamiento le permite conocer el tipo de ruta:

Red conectada (C)

Estática (S)

Autoexportada (A)



Importada (I)

Los protocolos de enrutamiento dinámico, como RIP (R), abrir primero la ruta más corta u OSPF (O), tipo externo 1 y 2 de OSPF (E1 o E2, respectivamente), protocolo de puerta de enlace de límite interno o externo (iB o eB, respectivamente)

Permanente (P)

Host (H)

Aparece una entrada host-ruta con una máscara de 32 bits cuando se configura cada interfaz con una dirección IP. La ruta host siempre está activa en la tabla de rutas para que la consulta de rutas siempre tenga éxito. Las rutas host se actualizan automáticamente con los cambios configurados, como eliminación de la dirección IP de interfaz, y nunca se redistribuyen ni se exportan. Las rutas host descartan la posibilidad de que haya tráfico errático y conservan la capacidad de procesamiento.

La preferencia se utiliza para seleccionar la ruta a utilizar cuando existen varias rutas hacia la misma red de destino. Este valor lo determina el protocolo o el origen de la ruta. Cuanto menor sea el valor de preferencia de una ruta, más posibilidades existen que esa ruta se seleccione como ruta activa.

Puede modificar el valor de preferencia en cada enrutador virtual para cada protocolo u origen de ruta. Consulte “Selección de rutas” en la página 31 para obtener más información.

La métrica también se puede utilizar para seleccionar la ruta a utilizar cuando existen varias rutas para la misma red de destino con el mismo valor de preferencia. El valor de métrica de las rutas conectadas es siempre 0. La métrica predeterminada de las rutas estáticas es 1, pero puede especificar un valor diferente cuando se definen estas rutas.

El sistema virtual (vsys) al cual pertenece esta ruta. Para obtener más información sobre enrutadores virtuales, consulte “Enrutadores virtuales y sistemas virtuales” en la página 27. En este ejemplo, no aparecen entradas bajo el encabezado de la tabla untrust-vr; sin embargo, bajo el encabezado de la tabla trust-vr aparecen once entradas.

La mayoría de las tablas de enrutamiento contienen una ruta predeterminada (con la dirección de red 0.0.0.0/0), que es una entrada comodín para los paquetes destinados a redes distintas de las definidas en la tabla de enrutamiento.

Para ver un ejemplo del enrutamiento basado en el destino, consulte “Configuración de rutas estáticas” en la página 4.



18

Tabla de enrutamiento basada en el origenPuede obligar a un dispositivo de seguridad a reenviar tráfico según la dirección IP de origen de un paquete de información en lugar de la dirección IP de destino. Esta función permite que el tráfico de los usuarios de una subred concreta se reenvíe por una ruta mientras que el tráfico de los usuarios de una subred diferente se reenvía por otra. Cuando el enrutamiento según el origen se habilita en un VR, el dispositivo de seguridad realiza operaciones de consulta de la tabla de enrutamiento en la dirección IP del origen del paquete en una tabla de enrutamiento con base en orígenes. Si el dispositivo de seguridad no encuentra una ruta para la dirección IP de origen en la tabla de enrutamiento basada en orígenes, utiliza la dirección IP de destino del paquete para las operaciones de consulta de rutas en la tabla de enrutamiento basada en destinos.

Usted define las rutas basadas en el origen como rutas configuradas estáticamente en VR especificados. Las rutas basadas en orígenes son aplicables al VR en el que usted las configura; sin embargo, puede especificar otro VR como siguiente salto para una ruta basada en orígenes. Tampoco puede redistribuir rutas basadas en el origen a otros VR o protocolos de enrutamiento.

Para utilizar esta función:

1. Cree al menos una ruta basada en origen especificando esta información:

El nombre del VR en el que es aplicable el enrutamiento según el origen.

La dirección IP de origen, que aparece como una entrada en la tabla de enrutamiento basada en orígenes, en la cual el dispositivo de seguridad realiza una consulta de la tabla de enrutamiento.

El nombre de la interfaz de salida por la que se reenvía el paquete.

El salto siguiente para la ruta basada en el origen (tenga en cuenta que si ya ha especificado una puerta de enlace predeterminada para la interfaz con el comando CLI set interface interfaz gateway dir_ip, no necesita especificar el parámetro de puerta de enlace; la puerta de enlace predeterminada de la interfaz se usa como siguiente salto para la ruta basada en el origen. También puede especificar otro VR como siguiente salto para la ruta basada en el origen con el comando set vrouter enrut_virtual route source dir_ip/máscara_red vrouter enrut_virtual_salto_siguiente.)

La métrica para la ruta basada en el origen. (Si hay varias rutas basadas en el origen con el mismo prefijo, sólo la ruta con la métrica más baja se utiliza para la consulta de rutas y el resto se marcan como “inactivas”.)

2. Habilitar el enrutamiento según el origen en el VR. El dispositivo de seguridad utiliza la IP de origen del paquete para las operaciones de consulta de rutas en la tabla de enrutamiento basada en orígenes. Si no se encuentra ninguna ruta para la dirección IP de origen, se utiliza la dirección IP de destino para consultar la tabla de enrutamiento.



En la Figura 5, el tráfico de los usuarios de la subred 10.1.1.0/24 se reenvía al ISP 1, mientras que el tráfico de los usuarios de la subred 10.1.2.0/24 se reenvía al ISP 2. Es necesario configurar dos entradas en la tabla de enrutamiento del VR predeterminado trust-vr y habilitar el enrutamiento según el origen:

La subred 10.1.1.0/24, con ethernet3 como interfaz de reenvío y enrutador del ISP 1 (1.1.1.1) como siguiente salto

La subred 10.1.2.0/24, con ethernet4 como interfaz de reenvío y enrutador del ISP 2 (2.2.2.2) como siguiente salto

Figura 5: Ejemplo de enrutamiento según el origen

WebUI

Network > Routing > Source Routing > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 10.1.1.0 255.255.255.0Interface: ethernet3 (seleccione)Gateway IP Address: 1.1.1.1

Network > Routing > Source Routing > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:


Network > Routing > Virtual Routers > Edit (para el trust-vr): Seleccione Enable Source Based Routing, luego haga clic en OK.

CLI

set vrouter trust-vr route source 10.1.1.0/24 interface ethernet3 gateway 1.1.1.1 metric 1

set vrouter trust-vr route source 10.1.2.0/24 interface ethernet4 gateway 2.2.2.2 metric 1

set vrouter trust-vr source-routing enablesave

1.1.1.1

2.2.2.210.1.2.0/24

10.1.1.0/24

ethernet1

ethernet2

ISP1

ISP2

NOTA: En la WebUI, la preferencia y el valor de métrica predeterminados son 1.



20

Tabla de enrutamiento según la interfaz de origenEl enrutamiento según la interfaz de origen (SIBR) permite al dispositivo de seguridad reenviar el tráfico en función de la interfaz de origen (la interfaz por la que el paquete de datos llega al dispositivo de seguridad.) Cuando SIBR se habilita en un enrutador virtual (VR), el dispositivo de seguridad realiza operaciones de consulta de rutas en una tabla de enrutamiento de SIBR. Si el dispositivo de seguridad no encuentra ninguna entrada de ruta en la tabla de enrutamiento de SIBR para la interfaz de origen, puede realizar consultas de ruta en la tabla de enrutamiento basada en orígenes (si el enrutamiento basado en orígenes está habilitado en el VR) o en la tabla de enrutamiento basada en destinos.

Las rutas basadas en la interfaz origen se definen como rutas estáticas para las interfaces de origen especificadas. Las rutas basadas en la interfaz de origen se aplican al VR en el que se configuran; sin embargo, también puede especificar otro VR como siguiente salto para una ruta basada en la interfaz de origen. Sin embargo, tampoco puede exportar rutas basadas en la interfaz de origen a otros VR ni redistribuirlas a un protocolo de enrutamiento.

Para utilizar esta función:

1. Cree al menos una ruta basada en la interfaz de origen especificando la información siguiente:

El nombre del VR en el que es aplicable el enrutamiento según la interfaz de origen.

La interfaz de origen en la que el dispositivo de seguridad realiza una consulta en la tabla SIBR. (Esta interfaz aparece como una entrada en la tabla de enrutamiento.)

La dirección IP y el prefijo de máscara de red para la ruta.

El nombre de la interfaz de salida por la que se reenvía el paquete.

El salto siguiente para la ruta basada en interfaz de origen. (Tenga en cuenta que si ya ha especificado una puerta de enlace predeterminada para la interfaz con el comando CLI interface gateway dir_ip, no es necesario especificar el parámetro de puerta de enlace; la puerta de enlace predeterminada de la interfaz se usa como siguiente salto para la ruta basada en la interfaz de origen. También puede especificar otro VR como siguiente salto para la ruta basada en el origen con el comando set vrouter enrut_virtual route source dir_ip/máscara_red vrouter enrut_virtual_salto_siguiente.)

La métrica para la ruta basada en interfaz de origen. (Si hay varias rutas con base en la interfaz de origen con el mismo prefijo, sólo la ruta con la métrica más baja se utiliza para la consulta de rutas y el resto se marcan como “inactivas”.)

2. Habilite SIBR para el VR. El dispositivo de seguridad utiliza la interfaz de origen del paquete para las operaciones de consulta de rutas en la tabla SIBR.



En la Figura 6, el tráfico de los usuarios de la subred 10.1.1.0/24 llega al dispositivo de seguridad en la interfaz ethernet1 y se reenvía al ISP 1, mientras que el tráfico procedente de los usuarios de la subred 10.1.2.0/24 llega al dispositivo en ethernet2 y se reenvía al ISP 2. Deberá configurar dos entradas en la tabla de enrutamiento del VR predeterminado trust-vr y habilitar SIBR:

La subred 10.1.1.0/24, con ethernet1 como interfaz de origen para reenvíos y ethernet3 como interfaz de reenvío y el enrutador del ISP 1 (1.1.1.1) como siguiente salto

La subred 10.1.2.0/24, con ethernet2 como interfaz de origen y ethernet4 como interfaz de reenvío y el enrutador del ISP 2 (2.2.2.2) como siguiente salto

Figura 6: Ejemplo de enrutamiento según la interfaz de origen (SIBR)

WebUI

Network > Routing > Source Interface Routing > New (para ethernet1): Introduzca los siguientes datos y haga clic en OK:


Network > Routing > Source Interface Routing > New (para ethernet2): Introduzca los siguientes datos y haga clic en OK:


Network > Routing > Virtual Routers > Edit (para el trust-vr): Seleccione Enable Source Interface Based Routing, luego haga clic en OK.

1.1.1.1

2.2.2.2

10.1.1.0/24

10.1.2.0/24

ethernet1

ethernet2

ethernet3

ethernet4

ISP1

ISP2

NOTA: En la WebUI, la preferencia y el valor de métrica predeterminados son 1.



22

CLI

set vrouter trust-vr route source in-interface ethernet1 10.1.1.0/24 interface ethernet3 gateway 1.1.1.1 metric 1

set vrouter trust-vr route source in-interface ethernet2 10.1.2.0/24 interface ethernet4 gateway 2.2.2.2 metric 1

set vrouter trust-vr sibr-routing enablesave

Creación y modificación de enrutadores virtuales

Esta sección incluye varios ejemplos y procedimientos para modificar enrutadores virtuales (VR) existentes y para crear o eliminar VR personalizados.

Modificación de enrutadores virtualesPuede modificar un VR personalizado o predeterminado mediante la WebUI o la CLI. Por ejemplo, para modificar el VR trust-vr:

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit

CLI

set vrouter trust-vr

Puede modificar los siguientes parámetros de los VR:

Identificador de enrutador virtual (consulte “Limitación del número máximo de entradas de la tabla de enrutamiento” en la página 30.)

Número máximo de entradas permitidas en la tabla de enrutamiento.

El valor de preferencia para las rutas, según el protocolo (consulte “Establecimiento de una preferencia de ruta” en la página 31.)

Hacer que el VR reenvíe el tráfico según la dirección IP de origen del paquete de datos (de forma predeterminada, un VR reenvía el tráfico según la dirección IP de destino del paquete de datos.) Consulte “Tabla de enrutamiento basada en el origen” en la página 18.)

Habilitar o deshabilitar la exportación de rutas automática al untrust-vr para interfaces configuradas en modo de ruta (sólo para el trust-vr.)

Añadir una ruta predeterminada con otro VR como siguiente salto (sólo para el trust-vr.)

Hacer capturas SNMP privadas para las MIB de enrutamiento dinámico (sólo para el VR de nivel raíz.)

Permitir que rutas de interfaces inactivas sean tenidas en cuenta para notificación (de forma predeterminada, sólo las rutas activas definidas en interfaces activas pueden ser redistribuidas a otros protocolos o exportadas a otros VR.)



Hacer que el VR ignore las direcciones de subredes superpuestas para interfaces (de forma predeterminada, no es posible configurar direcciones IP de subredes superpuestas para interfaces en el mismo VR.)

Permitir que el VR sincronice su configuración con el VR en su interlocutor del protocolo de redundancia de NetScreen (NSRP.)

Asignación de una ID de enrutador virtualCon los protocolos de enrutamiento dinámico, cada dispositivo de enrutamiento utiliza una identidad de enrutador exclusiva para comunicarse con otros dispositivos de enrutamiento. La identidad puede ser en forma de notación decimal con puntos, como una dirección IP, o un valor entero. Si no define una ID de enrutador virtual concreto (VR ID) antes de la habilitación de un protocolo de enrutamiento dinámico, ScreenOS automáticamente selecciona la dirección IP más alta de las interfaces activas en el enrutador virtual (VR) como identidad del enrutador.

De forma predeterminada todos los dispositivos de seguridad tienen asignada la dirección IP 192.168.1.1 a la interfaz VLAN1. Si no especifica una ID del enrutador antes de la habilitación de un protocolo de enrutamiento dinámico en un dispositivo de seguridad, la dirección IP elegida como ID del enrutador será probablemente la dirección predeterminada 192.168.1.1. Esto puede provocar un problema de enrutamiento puesto que no puede haber varios VR de seguridad con la misma ID de VR en un dominio de enrutamiento. Por lo tanto, recomendamos que siempre asigne una ID de VR explícita que sea única en la red. Puede establecer la ID del VR en la dirección de la interfaz de bucle invertido, puesto que la interfaz de bucle invertido no es una VSI (interfaz de seguridad virtual) en un clúster NSRP (protocolo de redundancia de NetScreen.) (Consulte el Volumen 11: Alta Disponibilidad para obtener más información sobre la configuración de un clúster NSRP.)

En este ejemplo, asignará 0.0.0.10 como ID de enrutador para el trust-vr.

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit: Introduzca los siguientes datos y haga clic en OK:

Virtual Router ID: Custom (seleccione)En el cuadro de texto, escriba 0.0.0.10

CLI

set vrouter trust-vr router-id 10save

NOTA: En la WebUI debe introducir la ID del enrutador en notación decimal de puntos. En la CLI, puede introducir la ID del enrutador en notación decimal de puntos (0.0.0.10) o simplemente introducir 10 (la CLI la convierte en 0.0.0.10.)

Creación y modificación de enrutadores virtuales 23


24

Reenvío de tráfico entre enrutadores virtualesCuando hay dos versiones de VR en un dispositivo de seguridad, el tráfico de las zonas en un VR no se reenvía automáticamente a zonas de otro VR, aunque haya directivas que permitan el tráfico. Si el tráfico debe pasar entre los VR, tiene que realizar uno de estos procedimientos:

Configurar una ruta estática en un VR que defina otro VR como el siguiente salto para la ruta. Esta ruta puede incluso ser la ruta predeterminada del VR. Por ejemplo, puede configurar una ruta predeterminada para el trust-vr con el untrust-vr como siguiente salto. Si el destino de un paquete de salida no coincide con ninguna de las entradas de la tabla de enrutamiento del trust-vr, se reenvía al untrust-vr. Para obtener información sobre la configuración de rutas estáticas, consulte “Configuración de rutas estáticas” en la página 4.

Exportar rutas de la tabla de enrutamiento de un VR a la tabla de enrutamiento de otro VR. Puede exportar e importar rutas concretas. También puede exportar todas las rutas de la tabla de enrutamiento del trust-vr a la tabla del untrust-vr. Esto permite el reenvío de paquetes recibidos en el untrust-vr a destinos del trust-vr. Para obtener información, consulte “Exportación e importación de rutas entre enrutadores virtuales” en la página 43.

Configuración de dos enrutadores virtualesCuando hay varios VR dentro de un dispositivo de seguridad, cada VR mantiene tablas de enrutamiento separadas. De forma predeterminada, todas las zonas de seguridad predefinidas y definidas por el usuario están asociadas al trust-vr. Esto significa que todas las interfaces asociadas a esas zonas de seguridad también pertenecen al trust-vr. Esta sección analiza cómo asociar una zona de seguridad (y sus interfaces) al VR untrust-vr.

Puede asociar una zona de seguridad a un sólo VR. Puede asociar varias zonas de seguridad a un sólo VR cuando no hay superposición de direcciones entre zonas. Esto es, todas las interfaces de las zonas deben estar en modo de ruta. Una vez que una zona está asociada a un VR, todas las interfaces de la zona pertenecen al VR. Puede cambiar la asociación de una zona de seguridad de un VR a otro, pero primero hay que quitar todas las interfaces de la zona. (Para obtener más información sobre cómo enlazar y desenlazar una interfaz de una zona de seguridad, consulte “Interfaces” en la página 2-33.)

A continuación se enumeran los pasos básicos para asociar una zona de seguridad al VR untrust-vr:

1. Eliminar todas las interfaces de la zona que quiera asociar al untrust-vr. No puede modificar el vínculo de zona a VR si hay una interfaz asignada a la zona. Si ha asignado una dirección IP a una interfaz, deberá eliminar la asignación de direcciones antes de quitar la interfaz de la zona.

NOTA: No puede asignar o cambiar una ID de enrutador si ya ha habilitado un protocolo de enrutamiento dinámico en el VR. Si necesita cambiar la ID del enrutador, debe primero deshabilitar el protocolo de enrutamiento dinámico en el VR. Para obtener información sobre la desactivación del protocolo de enrutamiento dinámico en VR, consulte el capítulo correspondiente en este volumen.



2. Asignar la zona al VR untrust-vr.

3. Volver a asignar las interfaces a la zona.

En el siguiente ejemplo, la zona de seguridad untrust está asociada de forma predeterminada al trust-vr y la interfaz ethernet3 está asociada a la zona de seguridad untrust. (No hay otras interfaces asociadas a la zona de seguridad untrust.) Primero debe definir la dirección IP y la máscara de red de la interfaz ethernet3 con un valor de 0.0.0.0, después cambiar los enlaces para que la zona de seguridad untrust se asocie al untrust-vr.

WebUI

1. Desasociar la interfaz de la zona untrustNetwork > Interfaces (ethernet3) > Edit: Introduzca los siguientes datos y haga clic en OK:

Zone Name: NullIP Address/Netmask: 0.0.0.0/0

2. Asociar la zona untrust al untrust-vrNetwork > Zones (untrust) > Edit: Seleccione untrust-vr de la lista desplegable Virtual Router Name, luego haga clic en OK.

3. Asociar la interfaz a la zona untrustNetwork > Interfaces (ethernet3) > Edit: Seleccione Untrust en la lista desplegable Zone Name, luego haga clic en OK.

CLI

1. Desasociar la interfaz de la zona untrustunset interface ethernet3 ipunset interface ethernet3 zone

2. Asociar la zona untrust al untrust-vrset zone untrust vrouter untrust-vr

3. Asociar la interfaz a la zona untrustset interface eth3 zone untrustsave

En el resultado del siguiente ejemplo, el comando get zone muestra la interfaz, zona y enlaces VR predeterminados. En los enlaces predeterminados, la zona untrust está asociada al trust-vr.

device-> get zoneTotal of 12 zones in vsys root. 7 policy configurable zone(s)-------------------------------------------------------------ID Name Type Attr VR Default-IF VSYS 0 Null Null Shared untrust-vr null Root 1 Untrust Sec(L3) Shared trust-vr ethernet3 Root 2 Trust Sec(L3) trust-vr ethernet1 Root 3 DMZ Sec(L3) trust-vr ethernet2 Root 4 Self Func trust-vr self Root 5 MGT Func trust-vr vlan1 Root 6 HA Func trust-vr null Root10 Global Sec(L3) trust-vr null Root11 V1-Untrust Sec(L2) trust-vr v1-untrust Root12 V1-Trust Sec(L2) trust-vr v1-trust Root



26

13 V1-DMZ Sec(L2) trust-vr v1-dmz Root16 Untrust-Tun Tun trust-vr null Root-------------------------------------------------------------

Puede elegir cambiar el enlace de la zona para untrust-vr. Al ejecutar el comando get zone, se muestra la interfaz, la zona y los enlaces de VR modificados; en este caso, la zona untrust está ahora vinculada a untrust-vr.

device-> get zoneTotal of 12 zones in vsys root. 7 policy configurable zone(s)-------------------------------------------------------------ID Name Type Attr VR Default-IF VSYS 0 Null Null Shared untrust-vr null Root 1 Untrust Sec(L3) Shared untrust-vr ethernet3 Root 2 Trust Sec(L3) trust-vr ethernet1 Root 3 DMZ Sec(L3) trust-vr ethernet2 Root 4 Self Func trust-vr self Root 5 MGT Func trust-vr vlan1 Root 6 HA Func trust-vr null Root10 Global Sec(L3) trust-vr null Root11 V1-Untrust Sec(L2) trust-vr v1-untrust Root12 V1-Trust Sec(L2) trust-vr v1-trust Root13 V1-DMZ Sec(L2) trust-vr v1-dmz Root16 Untrust-Tun Tun trust-vr null Root---------------------------------------------------------------

Creación y eliminación de enrutadores virtualesAlgunos dispositivos de seguridad le permiten crear VR personalizados además de los dos predefinidos. Puede modificar todos los aspectos de un VR definido por el usuario, incluidos la identidad del VR, el número máximo de entradas permitidas en la tabla de enrutamiento, y el valor de preferencia de las rutas de determinados protocolos.

Creación de un enrutador virtual personalizadoEn este ejemplo, creará un VR personalizado denominado trust2-vr y habilitará una exportación de rutas automática del VR trust2-vr al untrust-vr.

WebUI

Network > Routing > Virtual Routers > New: Introduzca los siguientes datos y haga clic en OK:

Virtual Router Name: trust2-vrAuto Export Route to Untrust-VR: (seleccione)

CLI

set vrouter name trust2-vrset vrouter trust2-vr auto-route-exportsave

NOTA: Sólo ciertos dispositivos de seguridad admiten VR personalizados. Para crear VR personalizados, necesita una clave de licencia de software.



Eliminación de un enrutador virtual personalizadoEn este ejemplo, eliminará un VR definido por el usuario existente denominado trust2-vr.

WebUI

Network > Routing > Virtual Routers: Haga clic en Remove para trust2-vr.

Cuando aparezca la petición de confirmación de la eliminación, haga clic en OK.

CLI

unset vrouter trust2-vr

Cuando aparezca la petición de confirmación para la eliminación (vrouter unset, are you sure? y/[n]), teclee Y.

save

Enrutadores virtuales y sistemas virtualesCuando un administrador del nivel raíz crea un vsys en sistemas con sistema virtual habilitado, automáticamente el vsys tiene los siguientes VR disponibles para su uso:

Cualquier VR de nivel raíz que haya sido definido como compartido. El untrust-vr es, de forma predefinida, un VR compartido accesible por cualquier vsys. Puede configurar otro VR de nivel raíz como compartido.

Un VR de nivel vsys. Cuando crea un vsys, se crea automáticamente un VR de nivel vsys que mantiene la tabla de enrutamiento de la zona Trust-nombresistvirt. Puede elegir nombrar el VR como nombresistvirt-vr o con un nombre definido por el usuario. Un VR de nivel vsys no puede ser compartido por otros vsys.

Puede definir uno o más VR personalizados para un vsys. Para obtener más información sobre los sistemas virtuales, consulte el Volumen 10: Sistemas virtuales. En la Figura 7, cada uno de los tres vsys tiene dos VR asociados con éste: un VR de nivel vsys llamado nombresistvirt-vr y el untrust-vr.

NOTA: No puede eliminar los VR predefinidos untrust-vr y trust-vr, pero se puede eliminar cualquier VR definido por el usuario. Para modificar el nombre de un VR definido por el usuario o cambiar la ID del VR, debe eliminar primero el VR y después volver a crearlo con el nuevo nombre o ID del VR.

NOTA: Únicamente los sistemas de seguridad de Juniper Networks (NetScreen-500, NetScreen-5200, NetScreen-5400) admiten vsys. Para crear objetos vsys, necesita una clave de licencia de software.



28

Figura 7: Enrutadores virtuales dentro de un Vsys

Creación de un enrutador virtual en un VsysEn este ejemplo, definirá un VR personalizado vr-1a con la ID de VR 10.1.1.9 para el vsys mi-vsys1.

WebUI

Vsys > Configure > Enter (para mi-vsys1) > Network > Routing > Virtual Routers > New: Introduzca los siguientes datos, luego haga clic en Apply:

Virtual Router Name: vr-1aVirtual Router ID: Custom (seleccione)En el cuadro de texto, introduzca 10.1.1.9

CLI

set vsys mi-vsys1(mi-vsys1) set vrouter name vr-1a(mi-vsys1/vr-1a) set router-id 10.1.1.9(mi-vsys1/vr-1a) exit(mi-vsys1) exit

Teclee Y cuando aparezca la siguiente pregunta:

Configuration modified, save? [y]/n

untrust-vr (enrutador virtual a nivel de raíz compartido)

Correo

Untrust

DMZ

Finanzas

trust-vr

Trust Ingeniería

sistema raíz

vsys1

vsys2

vsys3

vsys1-vr

Trust-vsys2vsys2-vr

Trust-vsys3vsys3-vr

Automáticamente creados cuando crea vsys

Trust-vsys1



El VR de nivel vsys que se crea cuando usted crea el vsys es el VR predeterminado para un vsys. Puede cambiar el VR predeterminado de un vsys por un VR personalizado. Por ejemplo, puede hacer que el VR personalizado vr-1a creado anteriormente en este ejemplo sea el VR predeterminado para el vsys mi-vsys1:

WebUI

Vsys > Configure > Enter (para mi-vsys1) > Network > Routing > Virtual Routers > Edit (para vr-1a): Seleccione Make This Vrouter Default-Vrouter for the System y haga clic en Apply.

CLI

set vsys mi-vsys1(mi-vsys1) set vrouter vr-1a(mi-vsys1/vr-1a) set default-vrouter(mi-vsys1/vr-1a) exit(mi-vsys1) exit



La zona de seguridad predefinida Trust-nombresistvirt está asociada de forma predeterminada al VR de nivel vsys que se crea al crear el vsys. No obstante, puede asociar la zona de seguridad predefinida Trust-nombresistvirt y cualquier zona de seguridad de nivel vsys definida por el usuario a cualquier VR disponible para el vsys.

El untrust-vr es compartido de forma predefinida por todo el vsys. Aunque los VR de nivel vsys no se pueden compartir, puede definir cualquier VR de nivel raíz para ser compartido por el vsys. Esto le permite definir rutas en un VR de nivel vsys que utilizan un VR de nivel raíz como siguiente salto. Puede también configurar la redistribución de rutas entre un VR de nivel vsys y un VR de nivel raíz compartido.

Compartir rutas entre enrutadores virtualesEn este ejemplo, el VR de nivel raíz mi-enrutador contiene las entradas de la tabla de enrutamiento para la red 4.0.0.0/8. Si configura el VR de nivel raíz mi-enrutador como compartible por el vsys, puede definir una ruta en un VR de nivel vsys para el destino 4.0.0.0/8 con mi-enrutador como siguiente salto. En este ejemplo, el vsys es mi-vsys1 y el VR de nivel vsys es mi-vsys1-vr.

WebUI

Network > Routing > Virtual Routers > New: Introduzca los siguientes datos y haga clic en OK:

Virtual Router Name: mi-enrutadorShared and accessible by other vsys (seleccione)

Vsys > Configure > Enter (para mi-vsys1) > Network > Routing > Routing Entries > New (para mi-vsys1-vr): Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 40.0.0.0 255.0.0.0Next Hop Virtual Router Name: (seleccione) mi-enrutador



30

CLI

set vrouter name mi-enrutador sharableset vsys mi-vsys1(mi-vsys1) set vrouter mi-vsys1-vr route 40.0.0.0/8 vrouter mi-enrutador(mi-vsys1) exit



Limitación del número máximo de entradas de la tabla de enrutamientoA cada VR se le asignan las entradas de la tabla de enrutamiento que necesita de entre un conjunto del sistema. El número máximo de entradas disponibles depende del dispositivo de seguridad y del número de VR configurados en el dispositivo. Puede limitar el número máximo de entradas de la tabla de enrutamiento que pueden ser asignadas para un VR concreto. Esto sirve para prevenir que un VR utilice todas las entradas del sistema.

En este ejemplo, ajustará a 20 el número máximo de entradas de la tabla de enrutamiento para el trust-vr.

WebUI

Network > Routing > Virtual Routers > Edit (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Maximum Route Entry:Set limit at: (seleccione), 20

CLI

set vrouter trust-vr max-routes 20save

Ejemplos y funciones del enrutamiento

Después de configurar los VR requeridos para su red, puede determinar qué funciones de enrutamiento desea emplear. Estas funciones afectan el comportamiento del enrutamiento y los datos de la tabla de enrutamiento. Estas funciones se aplican a protocolos de enrutamiento estático y dinámico.

Esta sección contiene los siguientes temas:

“Selección de rutas” en la página 31

“Configuración del enrutamiento multidireccional de igual coste” en la página 36

NOTA: Consulte la hoja de datos del producto pertinente para determinar el número máximo de entradas de la tabla de enrutamiento disponible en su dispositivo de seguridad de Juniper Networks.




“Exportación e importación de rutas entre enrutadores virtuales” en la página 43

Selección de rutasPueden existir varias rutas con el mismo prefijo (dirección IP y máscara) en la tabla de enrutamiento. Cuando la tabla de enrutamiento contiene varias rutas para el mismo destino, se comparan los valores de preferencia de cada ruta. Se selecciona la que tiene el valor de preferencia más bajo. Si los valores de preferencia son iguales, se comparan los valores de métrica. En ese caso, se selecciona la ruta que tiene el valor de métrica más bajo.

Establecimiento de una preferencia de rutaUna preferencia de ruta es un peso añadido a la ruta que influye en la determinación del mejor camino para que el tráfico alcance su destino. Cuando se importa o añade una ruta a la tabla de enrutamiento, el VR añade un valor de preferencia, determinado por el protocolo por el cual es reconocida. Se prefiere un valor de preferencia bajo (un número próximo a 0) a un valor de preferencia alto (un número alejado de 0.)

En un VR, puede establecer el valor de preferencia para rutas de acuerdo con el protocolo. La Tabla 2 detalla los valores de preferencia predeterminados para rutas de cada protocolo.

Tabla 2: Valores de preferencia predeterminados de las rutas

También puede ajustar el valor de preferencia de la ruta para dirigir el tráfico por el camino preferido.

NOTA: Si hay varias rutas para el mismo destino con los mismos valores de preferencia y los mismos valores de métrica, entonces cualquiera de ellas puede resultar seleccionada. En este caso, la elección de una ruta concreta sobre otra no está garantizada ni es predecible.

ProtocoloPreferencia predeterminada

Conectado 0

Estático 20

Autoexportado 30

EBGP 40

OSPF 60

RIP 100

Importado 140

OSPF externo de tipo 2 200

IBGP 250

Ejemplos y funciones del enrutamiento 31


32

En este ejemplo, especifica un valor de 4 como preferencia para cualquier ruta “conectada” añadida a la tabla de rutas del untrust-vr.

WebUI

Network > Routing > Virtual Routers > Edit (para untrust-vr): Introduzca los siguientes datos y haga clic en OK:

Route Preference:Connected: 4

CLI

set vrouter untrust-vr preference connected 4save

Métricas de rutaLas métricas de ruta determinan el mejor camino que un paquete puede tomar para alcanzar un destino dado. Los enrutadores utilizan las métricas de ruta para sopesar dos rutas al mismo destino y determinar la elección de una ruta sobre la otra. Cuando hay varias rutas hacia la misma red de destino con el mismo valor de preferencia, prevalece la ruta con la métrica más baja.

Una métrica de ruta se puede basar en cualquier elemento o bien en una combinación de éstos:

Número de enrutadores que un paquete debe atravesar para alcanzar un destino

Velocidad y ancho de banda relativas de la ruta

Costo de los vínculos que conforman la ruta

Otros factores

Cuando las rutas son reconocidas dinámicamente, el enrutador contiguo al de origen de la ruta proporciona la métrica. La métrica predeterminada para rutas conectadas siempre es 0. La métrica predeterminada para rutas estáticas es 1.

NOTA: Si la preferencia de la ruta cambia para un tipo de ruta (por ejemplo, las rutas OSPF de tipo 1), la nueva preferencia aparece en la tabla de rutas, pero no tiene efecto hasta que la ruta sea reconocida de nuevo (lo cual se consigue inhabilitando y a continuación habilitando el protocolo de enrutamiento dinámico), o, en el caso de rutas estáticas, eliminándola y volviéndola a añadir.

Si cambia la preferencia de ruta no afectará a las rutas existentes. Para aplicar cambios a las rutas existentes, debe borrar las rutas y luego volver a agregarlas. Para las rutas dinámicas, debe deshabilitar el protocolo, luego volver a habilitarlo o reiniciar el dispositivo.

Una ruta es conectada cuando el enrutador tiene una interfaz con una dirección IP en la red de destino.



Cambio de la secuencia predeterminada de consulta de rutasSi habilita tanto el enrutamiento basado en el origen como el enrutamiento basado en interfaz de origen en un VR, el VR realiza consultas de rutas, comprobando el paquete entrante con las tablas de enrutamiento en un orden específico. Esta sección describe la secuencia de consulta de la ruta predeterminada y cómo puede modificar dicha secuencia configurando los valores de preferencia para cada tabla de enrutamiento.

Si un paquete entrante no coincide con una sesión existente, el dispositivo de seguridad ejecuta los pasos restantes con procesamiento del primer paquete. La Figura 8 muestra la secuencia predeterminada de consulta de rutas.

Figura 8: Secuencia predeterminada de consulta de rutas

1. Si el enrutamiento basado en la interfaz de origen se habilita en el VR, el dispositivo de seguridad primero comprueba la tabla de enrutamiento basada en la interfaz de origen para ver si existe una entrada de ruta que coincida con la interfaz en la que llegó el paquete. Si el dispositivo de seguridad encuentra una entrada de ruta para la interfaz de origen en la tabla de enrutamiento basada en la interfaz de origen, reenvía los paquetes según lo especificado por la entrada de enrutamiento correspondiente. Si el dispositivo de seguridad no encuentra una entrada de enrutamiento para la interfaz de origen en la tabla de enrutamiento basada en la interfaz de origen, el dispositivo comprueba si el enrutamiento basado en el origen está habilitado en el VR.

paquete entrante

SIBR habilitado

No

¿La ruta se encontró en tabla SIBR?

No

No

No

Sí

Sí

Sí

Sí

¿La ruta se encontró en tabla SBR?

¿Se encontró la

ruta en DRT?

Descartar el paquete

Reenvíe el paquete en la interfaz de salida especificada o de siguiente salto

SBR habilitado

No



34

2. Si el enrutamiento basado en el origen se habilita en el VR, el dispositivo de seguridad comprueba la tabla de enrutamiento basada en el origen para ver si existe una entrada de ruta que coincida con la dirección IP de origen del paquete. Si el dispositivo de seguridad encuentra una entrada de enrutamiento que coincida con la dirección IP de origen, reenvía el paquete según lo especificado por la entrada. Si el dispositivo de seguridad no encuentra una entrada de enrutamiento para la dirección IP de origen en la tabla de enrutamiento basada en el origen, el dispositivo comprueba la tabla de enrutamiento basada en los destinos.

3. El dispositivo de seguridad comprueba la tabla de enrutamiento basada en los destinos en consulta de una entrada de enrutamiento que coincida con la dirección IP de destino del paquete. Si el dispositivo de seguridad encuentra una entrada de enrutamiento que coincida con la dirección IP de destino, reenvía el paquete según lo especificado por la entrada. Si el dispositivo no encuentra una entrada de enrutamiento que coincida exactamente con la dirección IP de destino pero hay una ruta predeterminada configurada para el VR, el dispositivo reenvía el paquete según lo especificado por la ruta predeterminada. Si el dispositivo de seguridad no encuentra una entrada de enrutamiento para la dirección IP de destino y no hay ruta predeterminada configurada para el VR, el paquete se descarta.

El orden en el que el dispositivo de seguridad comprueba las tablas de enrutamiento para encontrar una ruta que coincida está determinado por un valor de preferencia asignado a cada tabla de enrutamiento. La tabla de enrutamiento con el valor de preferencia más alto se comprueba primero mientras que la tabla de enrutamiento con el valor de preferencia más bajo es la última en comprobarse. De forma predeterminada, la tabla de enrutamiento basada en la interfaz de origen tiene el valor de preferencia más alto (3), la tabla de enrutamiento basada en el origen tiene el siguiente valor de preferencia más alto (2) y la tabla de enrutamiento basada en los destinos tiene el valor de preferencia más bajo (1).

Puede reasignar nuevos valores de preferencia a una tabla de enrutamiento para modificar el orden en el que el dispositivo de seguridad realiza la consulta de rutas en un VR. Recuerde que el dispositivo comprueba las tablas de enrutamiento del valor de preferencia más alto al más bajo.

En el ejemplo siguiente, habilitará tanto el enrutamiento SIBR como el enrutamiento basado en el origen en el enrutador trust-vr. Desea que el dispositivo de seguridad lleve a cabo operaciones de consulta de rutas en las tablas de enrutamiento con el siguiente orden: Enrutamiento basado en el origen primero, SIBR, y luego enrutamiento basado en destinos Para configurar esta secuencia de consulta en la tabla de enrutamiento, debe configurar el enrutamiento basado en el origen con un valor de preferencia más alto que el de SIBR — en este ejemplo, asignará un valor de preferencia de 4 al enrutamiento basado en el origen.

WebUI

Network > Routing > Virtual Router > Edit (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Route Lookup Preference (1-255): (seleccione)For Source Based Routing: 4

Enable Source Based Routing: (seleccione)Enable Source Interface Based Routing: (seleccione)



CLI

set vrouter trust-vr sibr-routing enableset vrouter trust-vr source-routing enableset vrouter trust-vr route-lookup preference source-routing 4save

Consulta de rutas en múltiples enrutadores virtualesSólo puede especificar otro VR como el salto siguiente para una entrada de enrutamiento basada en destinos, y no para una entrada de enrutamiento basada en el origen o en la interfaz. Por ejemplo, la ruta predeterminada en la tabla de enrutamiento basada en destinos puede especificar el untrust-vr como el siguiente salto, luego la entrada del untrust-vr puede especificar otro VR, como DMZ. El dispositivo verificará hasta un total de tres VR. Donde la consulta de rutas en un VR da lugar a consultas de rutas en otro VR, el dispositivo de seguridad siempre lleva a cabo las segundas operaciones de consulta de rutas en la tabla de enrutamiento basada en destinos.

En el ejemplo, habilitará el enrutamiento basado en origen tanto en las tablas de enrutamiento trust-vr como en las tablas de enrutamiento untrust-vr. Trust-vr posee las siguientes entradas de enrutamiento:

Una entrada de enrutamiento basada en origen para la subred 10.1.1.0/24, con ethernet3 como la interfaz de reenvío y el enrutador en 1.1.1.1 como el siguiente salto

Una ruta predeterminada, con el untrust-vr como el siguiente salto

El untrust-vr posee las siguientes entradas de enrutamiento:

Una entrada de enrutamiento basada en origen para la subred 10.1.1.0/24, con ethernet4 como la interfaz de reenvío y el enrutador en 2.2.2.2 como el siguiente salto

Una ruta predeterminada, con ethernet3 como la interfaz de reenvío y el enrutador en 1.1.1.1 como el siguiente salto

La Figura 9 muestra cómo el tráfico de la subred 10.1.2.0/24 siempre se reenvía a través de ethernet3 al enrutador en 1.1.1.1.

Figura 9: Consulta de rutas en múltiples VR

10.1.1.0/24

10.1.2.0/24

ethernet1

ethernet2

ethernet3

ethernet4

ISP11.1.1.1

ISP22.2.2.2



36

La tabla de enrutamiento basada en el origen para el trust-vr incluye la siguiente entrada:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys* 1 10.1.1.0/24 eth3 2.2.2.250 S 20 1 Root

La tabla de enrutamiento basada en destinos para el untrust-vr incluye la siguiente entrada:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys* 1 0.0.0.0/24 n/a untrust-vr S 20 0 Root

El tráfico desde la subred 10.1.2.0/24 llega en el dispositivo de seguridad en ethernet2. Puesto que no hay entrada de enrutamiento basada en el origen que coincida, el dispositivo de seguridad realiza consultas de rutas en la tabla de enrutamiento basada en destinos. La ruta predeterminada en la tabla de enrutamiento basada en destinos especifica el untrust-vr como el salto siguiente.

A continuación, el dispositivo de seguridad no comprueba la tabla de enrutamiento basada en el origen del untrust-vr para que busque la siguiente entrada:


En su lugar, el dispositivo de seguridad comprueba la tabla de enrutamiento con base en destinos y busca la siguiente entrada:


En el untrust-vr, el dispositivo de seguridad sólo realiza consultas de rutas en la tabla de enrutamiento basada en destinos, incluso si la tabla de enrutamiento basada en origen del untrust-vr contiene una entrada que coincida con el tráfico. La ruta que coincide en la tabla de enrutamiento basada en destinos (la ruta predeterminada) reenvía el tráfico en la interfaz ethernet3.

Configuración del enrutamiento multidireccional de igual costeLos dispositivos de seguridad de Juniper Networks admiten el enrutamiento multidireccional de igual coste (ECMP) de forma específica en cada sesión. Las rutas de igual coste tienen los mismos valores de preferencia y de métrica. Una vez que un dispositivo de seguridad asocia una sesión con una ruta, el dispositivo de seguridad utiliza dicha ruta hasta que memoriza otra mejor o hasta que la actual deja de ser utilizable. Las rutas elegibles deben tener interfaces de salida que pertenezcan a las misma zona.

NOTA: Si las interfaces de salida no pertenecen a las misma zona y el paquete de vuelta va a una zona diferente a la prevista, no se podrá producir una coincidencia de sesiones y es posible que el tráfico no pueda pasar.



ECMP asiste con equilibrio de cargas entre dos a cuatro rutas al mismo destino o aumenta la eficacia de utilización del ancho de banda entre dos o más destinos. Cuando el ECMP está habilitado, los dispositivos de seguridad utilizan las rutas definidas estáticamente o memorizan dinámicamente varias rutas al mismo destino mediante un protocolo de enrutamiento. El dispositivo de seguridad asigna rutas de igual coste en el modo de ronda recíproca (round robin).

Sin ECMP, el dispositivo de seguridad utiliza únicamente la primera ruta aprendida o definida. Las otras rutas que sean de igual coste no se utilizan hasta que la ruta activa deje de estarlo.

Por ejemplo, considere las dos rutas siguientes que aparecen en la tabla de enrutamiento basad en destinos trust-vr:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 8 0.0.0.0/0 ethernet3 1.1.1.250 C 0 1 Root 9 0.0.0.0/0 ethernet2 2.2.2.250 S 20 1 Root

En este ejemplo, hay dos rutas predeterminadas para proporcionar conexiones a dos ISP diferentes, y el objetivo es utilizar ambas rutas predeterminadas con ECMP.

Las dos rutas tienen los mismos valores métricos; sin embargo, la primera ruta es una ruta conectada (C con una preferencia de 0). El dispositivo de seguridad adquirió la primera ruta a través de DHCP o de PPP y el dispositivo adquirió la ruta predeterminada a través de la configuración manual. La segunda ruta es una ruta estática configurada manualmente (S con una preferencia automática de 20). Con ECMP deshabilitado, el dispositivo de seguridad reenvía todo el tráfico a la ruta conectada en ethernet3.

NOTA: Cuando el ECMP se habilita y las interfaces salientes son diferentes y están en el modo NAT, las aplicaciones (como HTTP) que crean sesiones múltiples no funcionarán correctamente. Las aplicaciones (como telnet o SSH) que crean una sesión, deberían funcionar correctamente.

NOTA: Al usar ECMP, si tiene dos dispositivos de seguridad en una relación de vecindad y observa la pérdida de un paquete y un equilibrio de cargas incorrecto, compruebe la configuración del protocolo de resolución de direcciones (ARP) del dispositivo vecino para asegurarse de que la función arp always-on-dest está deshabilitada (predeterminado). Para obtener más información acerca de los comandos relacionados con ARP, consulte “Interfaces fuera de línea y flujo de tráfico” en la página 2-73.



38

Para alcanzar equilibrio de carga con ambas rutas, cambie la preferencia de ruta de la ruta estática a cero (0) para que coincida con la ruta conectada introduciendo el comando set vrouter trust-vr preference static 0 y luego habilitando ECMP. Con ECMP habilitado, la carga del dispositivo de seguridad equilibra el tráfico alternando entre dos rutas ECMP válidas. La siguiente pantalla muestra la tabla de enrutamiento actualizada.

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 8 0.0.0.0/0 ethernet3 1.1.1.250 C 0 1 Root* 9 0.0.0.0/0 ethernet2 2.2.2.250 S 0 1 Root

Si habilita ECMP y el dispositivo de seguridad encuentra más de una ruta coincidente del mismo coste en una tabla de enrutamiento, el dispositivo selecciona una ruta diferente de igual coste para cada consulta de ruta. Con las rutas indicadas anteriormente, el dispositivo de seguridad alterna entre ethernet3 y ethernet2 para reenviar el tráfico a la red 0.0.0.0/0.

Si hay más de dos rutas de igual coste en la red, el dispositivo de seguridad realiza una selección de las rutas en orden rotativo (ronda recíproca) hasta el máximo configurado de modo que el dispositivo seleccione una ruta ECMP diferente para cada consulta de ruta.

ECMP está inhabilitado de forma predeterminada (el número máximo de rutas es 1). Para habilitar el enrutamiento ECMP, debe especificar el número máximo de rutas de igual coste por enrutador. Puede especificar hasta cuatro rutas. Una vez que establezca el número máximo de rutas, el dispositivo de seguridad no añadirá o modificará rutas aunque reconozca más.

En el siguiente ejemplo, establecerá el número máximo de rutas ECMP en el trust-vr en 2. Aunque puede haber 3 ó 4 rutas de igual coste dentro de la misma zona y en la tabla de enrutamiento, el dispositivo de seguridad únicamente alterna entre el número configurado de rutas elegibles. En este caso, los datos sólo se redireccionan a lo largo de las 2 rutas ECMP especificadas.

WebUI

Network > Routing > Virtual Routers > Edit (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Maximum ECMP Routes:Set Limit at: (seleccione), 2

CLI

set vrouter trust-vr max-ecmp-routes 2save

Redistribución de rutasLa tabla de enrutamiento de un VR contiene rutas agrupadas según todos los protocolos de enrutamiento dinámico que se ejecutan en el VR, así como las rutas estáticas y las rutas conectadas directamente. De forma predeterminada, un protocolo de enrutamiento dinámico (como OSPF, RIP o BGP) notifica a sus adyacentes o interlocutores sólo las rutas que cumplen las siguientes condiciones:

Las rutas deben estar activas en la tabla de enrutamiento.



Las rutas deben ser reconocidas por el protocolo de enrutamiento dinámico.

Para que un protocolo de enrutamiento dinámico pueda notificar rutas previamente reconocidas por otro protocolo, incluidas la rutas configuradas estáticamente, es necesario redistribuir las rutas del protocolo origen al protocolo que realiza la notificación.

Puede redistribuir las rutas reconocidas por un protocolo de enrutamiento (incluidas la rutas configuradas estáticamente) a otro protocolo de enrutamiento diferente en el mismo VR. Esto permite al protocolo de enrutamiento receptor notificar las rutas redistribuidas. Cuando se importa una ruta, el dominio actual tiene que traducir toda la información, en particular las rutas conocidas, del otro protocolo al suyo propio. Por ejemplo, si un dominio de enrutamiento utiliza OSPF y conecta con un dominio de enrutamiento que utiliza el protocolo BGP, el dominio OSPF tiene que importar todas las rutas del dominio BGP para informar a todos sus vecinos OSPF sobre cómo llegar a los dispositivos del dominio BGP.

Las rutas se distribuyen entre los protocolos según una regla de redistribución que define el administrador del sistema o de la red. Cuando se añade una ruta a la tabla de enrutamiento de un enrutador virtual, se le aplican una a una todas las reglas de redistribución definidas en el VR para determinar si la ruta tiene que ser redistribuida. Cuando se elimina una ruta de la tabla de enrutamiento de un enrutador virtual, se le aplican una a una todas las reglas de redistribución definidas en el VR para determinar si la ruta tiene que ser eliminada de otro protocolo de enrutamiento del VR. Observe que todas las reglas de redistribución se aplican cuando se añade o se elimina una ruta. No existe el concepto de orden de las reglas o de “primera regla aplicable” para las reglas de redistribución.

En el dispositivo de seguridad, se configura un mapa de rutas para especificar qué rutas van a ser redistribuidas y los atributos de las rutas redistribuidas.

Configuración de un mapa de rutasUn mapa de rutas consiste en un conjunto de declaraciones que se aplican en orden secuencial a una ruta. Cada declaración del mapa de rutas define una condición que se comprueba con la ruta. Una ruta se compara con cada declaración de un mapa de rutas determinado en orden creciente del número de secuencia hasta que haya una coincidencia, entonces se realiza la acción especificada en la declaración. Si la ruta cumple la condición de la declaración del mapa de rutas, la ruta es aceptada o rechazada. Una declaración del mapa de rutas puede también modificar ciertos atributos de una ruta coincidente. Hay un rechazo implícito al final de todo mapa de rutas; esto es, si una ruta no coincide con ninguna entrada del mapa de rutas, se rechaza. La Tabla 3 detalla las condiciones de comparación del mapa de rutas y ofrece una descripción de cada una.

NOTA: OSPF, RIP, y BGP también notifican las rutas conectadas de las interfaces de ScreenOS en las que estos protocolos están habilitados.

NOTA: Sólo puede definir una regla de redistribución entre dos protocolos cualesquiera.



40

Tabla 3: Condiciones de comparación del mapa de rutas

Para cada condición de comparación, especifica si una ruta que cumple la condición es aceptada (permit) o rechazada (deny). Si una ruta cumple la condición y es aceptada, puede opcionalmente dar valor a los atributos para la ruta. La Tabla 4 detalla los atributos del mapa de rutas y las descripciones de cada uno.

Tabla 4: Atributos del mapa de rutas

Condición de comparación Descripción

BGP AS Path Compara con una lista de acceso AS path determinada. Consulte “Filtrado de rutas” en la página 41.

BGP Community Compara con una lista de comunidades determinada. Consulte “Filtrado de rutas” en la página 41.

OSPF route type Compara con un OSPF interno, externo de tipo 1 o externo de tipo 2.

Interface Compara con una interfaz determinada.

IP address Compara con una lista de acceso determinada. Consulte “Filtrado de rutas” en la página 41.

Metric Compara con un valor de métrica de ruta determinado.

Next-hop Compara con una lista de acceso determinada. Consulte “Filtrado de rutas” en la página 41.

Tag Compara con una dirección IP o etiqueta de ruta determinada.

Atributos establecidos Descripción

BGP AS Path Añade una lista de acceso AS path determinada al principio de la lista de atributos de camino de la ruta coincidente.

BGP Community Establece el atributo de comunidad de la ruta coincidente a la lista de comunidades especificada.

BGP local preference Establece el atributo local-pref de la ruta coincidente al valor especificado.

BGP weight Establece el peso de la ruta coincidente.

Offset metric Aumenta la métrica de la ruta coincidente hasta el valor especificado. Esto aumenta la métrica en una ruta menos deseable. Para las rutas RIP, puede aplicar el incremento tanto a las rutas notificadas (route-map out) o a las rutas reconocidas (route-map in). Para otras rutas, puede aplicar el incremento a las rutas que se exportan a otro VR.

OSPF metric type Establece el tipo de métrica OSPF de la ruta coincidente a externo tipo 1 o externo tipo 2.

Metric Establece la métrica de la ruta coincidente al valor especificado.

Next-hop of route Establece el siguiente salto de la ruta coincidente a la dirección IP especificada.

Preserve metric Preserva la métrica de una ruta coincidente que se exporta a otro VR.

Preserve preference Conserva el valor de preferencia de la ruta coincidente que se exporta a otro VR.

Tag Establece la etiqueta de la ruta coincidente al valor especificado o la dirección IP.



Filtrado de rutasEl filtrado de rutas le permite controlar qué rutas se admiten en un VR, cuáles se notifican a los interlocutores y cuáles se redistribuyen de un protocolo de enrutamiento a otro. Puede aplicar filtros a las rutas entrantes enviadas por un interlocutor de enrutamiento o a rutas salientes enviadas por el VR de seguridad a los enrutadores de interlocución. Puede utilizar los siguientes mecanismos de filtrado:

Lista de acceso: Consulte ”Configuración de una lista de acceso” para obtener información sobre la configuración de la lista de acceso.

Lista de acceso BGP AS-path: Un atributo AS-path es una lista de los sistemas autónomos por los que ha pasado una notificación de ruta y es parte de la información de ruta. Una lista de acceso AS-path es un conjunto de expresiones regulares que representan AS específicos. Puede utilizar una lista de acceso AS-path para filtrar las rutas según el AS por el que ha pasado la ruta. Consulte “Configuración de una lista de acceso AS-Path” en la página 124 para obtener información sobre la configuración de una lista de acceso AS-path.

Lista de comunidades BGP: Un atributo de comunidad contiene los identificadores de las comunidades a las que pertenece una ruta BGP. Una lista de comunidades BGP es un conjunto de comunidades BGP que puede utilizar para filtrar las rutas según las comunidades a las que pertenecen. Consulte “Comunidades BGP” en la página 133 para obtener información sobre la configuración de la lista de comunidades BGP.

Configuración de una lista de accesoUna lista de acceso es una lista de declaraciones de secuencia con la que se compara la ruta. Cada declaración especifica la dirección/máscara IP de un prefijo de red y el estado de reenvío (acepta o rechaza la ruta). Por ejemplo, una declaración de una lista de acceso puede permitir las rutas de la subred 1.1.1.0/24. Otra de la misma lista de acceso puede rechazar rutas de la subred 2.2.2.0/24. Si una ruta coincide con la declaración de la lista de acceso, se aplica el estado de reenvío especificado.

La secuencia de declaraciones de una lista de acceso es importante, puesto que una ruta se compara ordenadamente con todas las declaraciones desde la primera hasta que coincide con una. Si hay una coincidencia, todas las demás de la lista se ignoran. Debe colocar las declaraciones más específicas antes de las menos específicas. Por ejemplo, colocar la declaración que rechaza las rutas de la subred 1.1.1.1/30 antes de la que permite las rutas de la subred 1.1.1.0/24.

También puede utilizar listas de acceso para controlar el flujo del tráfico multicast. Para obtener información, consulte “Listas de acceso” en la página 161.

En este ejemplo, creará una lista de acceso en el trust-vr. La lista de acceso tiene las siguientes características:

Identifier: 2 (debe especificar un identificador de lista de acceso cuando se configura la lista de acceso)

Forwarding Status: permit



42

IP Address/Netmask Filtering: 1.1.1.1/24

Sequence Number: 10 (sitúa esta declaración con respecto a otras en la lista de acceso)

WebUI

Network > Routing > Virtual Routers > Access List: > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Access List ID: 2Sequence No.: 10IP/Netmask: 1.1.1.1/24Action: Permit

CLI

set vrouter trust-vr access-list 2 permit ip 1.1.1.1/24 10save

Redistribución de rutas en OSPFEn este ejemplo, redistribuirá determinadas rutas BGP que han pasado por el sistema autónomo 65000 en OSPF. Primero configura una lista de acceso AS-path que permite las rutas que han pasado por el AS 65000. (Para obtener más información sobre la configuración de una lista de acceso AS-path, consulte “Configuración de una lista de acceso AS-Path” en la página 124.) Luego, configurará un mapa de rutas “mapa_rutas1” que selecciona las rutas de la lista de acceso AS-path. Por último, en OSPF especificará una regla de redistribución que utilizará el mapa de rutas “mapa_rutas1” y luego especificará BGP como protocolo de origen de las rutas.

WebUI

1. Lista de acceso BGP AS-pathNetwork > Routing > Virtual Routers > Edit (para el trust-vr) > Edit BGP Instance > AS Path: Introduzca los siguientes datos y haga clic en Add:

AS Path Access List ID: 1Permit: (seleccione)AS Path String: _65000_

2. Mapa de rutasNetwork > Routing > Virtual Routers > Route Map > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Map Name: mapa_rutas1Sequence No.: 10Action: Permit (seleccione)Match Properties:

AS Path: (seleccione), 1



3. Regla de redistribuciónNetwork > Routing > Virtual Router > Edit (para el trust-vr) > Edit OSPF Instance > Redistributable Rules: Seleccione los siguientes datos y haga clic en Add:

Route Map: mapa_rutas1Protocol: BGP

CLI

1. Lista de acceso BGP AS-pathset vrouter trust-vr protocol bgp as-path-access-list 1 permit _65000_

2. Mapa de rutasset vrouter trust-vrdevice(trust-vr)-> set route-map name mapa_rutas1 permit 10device(trust-vr/mapa_rutas1-10)-> set match as-path 1device(trust-vr/mapa_rutas1-10)-> exitdevice(trust-vr)-> exit

3. Regla de redistribuciónset vrouter trust-vr protocol ospf redistribute route-map mapa_rutas1 protocol

bgpsave

Exportación e importación de rutas entre enrutadores virtualesSi tiene dos VR configurados en un dispositivo de seguridad, puede permitir que rutas especificadas en un VR sean reconocidas por el otro VR. Para hacerlo, debe definir reglas de exportación en el VR origen que exporten las rutas al VR destino. Cuando se exportan rutas, un enrutador virtual permite a otros VR reconocer su red. En el VR destino, puede configurar opcionalmente reglas de importación para controlar las rutas que pueden ser importadas del VR origen. Si no hay reglas de importación en el VR destino, se aceptan todas las rutas exportadas.

Para exportar e importar rutas entre enrutadores virtuales:

1. Defina una regla de exportación en el VR origen.

2. Defina una regla de importación en el VR destino (opcional). Aunque este paso es opcional, una regla de importación le permite un mayor control de las rutas que el enrutador virtual de destino acepta del enrutador virtual de origen.

En el dispositivo de seguridad, se configura una regla de exportación o importación con las especificaciones que se dan a continuación:

El enrutador virtual de destino (para las reglas de exportación) o el enrutador virtual de origen (para las reglas de importación)

El protocolo de las rutas que van a ser exportadas/importadas

Qué rutas van a ser exportadas/importadas

Los atributos nuevos o modificados de las rutas exportadas/importadas (opcional)



44

La configuración de una regla de exportación o importación es similar a la de una regla de redistribución. Los mapas de rutas se configuran para especificar qué rutas van a ser exportadas/importadas y los atributos de las mismas.

Puede configurar la exportación automática de todas las entradas de la tabla de rutas del trust-vr al untrust-vr. Puede configurar también que un enrutador virtual definido por el usuario exporte automáticamente rutas a otro enrutador virtual. Las rutas de las redes directamente conectadas a las interfaces en modo NAT no pueden ser exportadas.

Configuración de una regla de exportaciónEn este ejemplo, las rutas OSPF de la red 1.1.1.1/24 del enrutador virtual trust-vr se exportan al dominio de enrutamiento del untrust-vr. Primero creará una lista de acceso para el prefijo de red 1.1.1.1/24, que luego se utilizará en el mapa de rutas “mapa_rutas1” para filtrar las rutas de la red 1.1.1.1/24. En segundo lugar, creará una regla de exportación de rutas para exportar las rutas OSPF coincidentes del trust-vr al enrutador virtual untrust-vr.

WebUI

trust-vr

1. Lista de accesosNetwork > Routing > Virtual Routers > Access List: > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:


2. Mapa de rutasNetwork > Routing > Virtual Routers > Route Map > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Map Name: mapa_rutas1Sequence No.: 10Action: Permit (seleccione)Match Properties:

Access List: (seleccione), 2

3. Regla de exportaciónNetwork > Routing > Virtual Routers > Export Rules > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Destination Virtual Router: untrust-vrRoute Map: mapa_rutas1Protocol: OSPF

CLI

trust-vr

1. Lista de accesosset vrouter trust-vrdevice(trust-vr)-> set access-list 2 permit ip 1.1.1.1/24 10



2. Mapa de rutasdevice(trust-vr)-> set route-map name mapa_rutas1 permit 10device(trust-vr/mapa_rutas1-10)-> set match ip 2device(trust-vr/mapa_rutas1-10)-> exit

3. Regla de exportacióndevice(trust-vr)-> set export-to vrouter untrust-vr route-map mapa_rutas1

protocol ospfdevice(trust-vr)-> exitsave

Configuración de la exportación automáticaPuede configurar la exportación automática de todas las rutas del trust-vr al untrust-vr.

Si define reglas de importación para el untrust-vr, sólo se importan las rutas que cumplan las reglas de importación. En este ejemplo, el trust-vr exporta automáticamente todas las rutas al untrust-vr, pero una regla de importación del untrust-vr permite que se exporten sólo las rutas de OSPF interno.

WebUI

trust-vrNetwork > Routing > Virtual Router > Edit (para el trust-vr): Seleccione Auto Export Route to Untrust-VR, luego haga clic en OK.

untrust-vrNetwork > Routing > Virtual Router > Route Map (para untrust-vr) > New: Introduzca los siguientes datos y haga clic en OK:

Map Name: from-ospf-trustSequence No.: 10Action: Permit (seleccione)Route Type: internal-ospf (seleccione)

CLI

trust-vrset vrouter trust-vr auto-route-export

untrust-vrset vrouter untrust-vrdevice(untrust-vr)-> set route-map name from-ospf-trust permit 10device(untrust-vr/from-ospf-trust-10)-> set match route-type internal-ospfdevice(untrust-vr/from-ospf-trust-10)-> exitdevice(untrust-vr)-> set import-from vrouter trust-vr route-map from-ospf-trust

protocol ospfdevice(untrust-vr)-> exitsave

PRECAUCIÓN: Esta función puede anular el aislamiento entre trust-vr y untrust-vr al poner a la vista todas las rutas fiables en la red no fiable.



46

Capítulo 3

Abrir primero la ruta más corta

En este capítulo se describe el protocolo de enrutamiento OSPF (Open Shortest Path First) en los dispositivos de seguridad. Incluye las siguientes secciones:


“Áreas” en la página 48

“Clasificación de enrutadores” en la página 49

“Protocolo de saludo” en la página 50

“Tipos de redes” en la página 50

“Notificaciones de estado de conexiones” en la página 51

“Configuración básica de OSPF” en la página 51

“Creación y eliminación de una instancia de enrutamiento OSPF” en la página 53

“Creación y eliminación de un área OSPF” en la página 54

“Asignación de interfaces a un área OSPF” en la página 55

“Habilitación de OSPF en interfaces” en la página 56

“Verificación de la configuración” en la página 57

“Redistribución de rutas en protocolos de enrutamiento” en la página 59

“Resumen de rutas redistribuidas” en la página 60

“Parámetros globales de OSPF” en la página 61

“Notificación de la ruta predeterminada” en la página 62

“Conexiones virtuales” en la página 62

“Ajuste de parámetros OSPF de interfaz” en la página 64

47


48

“Configuración de seguridad” en la página 67

“Autenticación de vecinos” en la página 67

“Configuración de una lista de vecinos de OSPF” en la página 68

“Rechazo de rutas predeterminadas” en la página 69

“Protección contra inundaciones” en la página 69

“Creación de un circuito de demanda OSPF en una interfaz de túnel” en la página 71

“Interfaz de túnel punto a multipunto” en la página 71

“Establecer el tipo de conexión OSPF” en la página 72

“Inhabilitación de la restricción Route-Deny” en la página 72

“Creación de una red punto a multipunto” en la página 73

Vista general

El protocolo de enrutamiento OSPF (Open Shortest Path First, abrir primero la ruta más corta) es un protocolo de puerta de enlace interior (IGP) desarrollado para ejecutarse dentro de un único sistema autónomo. Un enrutador que ejecute OSPF distribuye su información de estado (como interfaces disponibles para el uso y accesibilidad por parte de equipos vecinos) inundando periódicamente el sistema autónomo con notificaciones de estado de conexiones (LSA, link-state advertisements).

Los enrutadores OSPF utilizan las LSA de los enrutadores contiguos para actualizar una base de datos de estado de conexiones. Esta base de datos es una tabla que informa de la topología y el estado de las redes de un área. La distribución constante de las LSA a través del dominio de enrutamiento permite a todos los enrutadores de un sistema autónomo disponer de bases de datos de estado de conexiones idénticas.

El protocolo OSPF utiliza la base de datos de estado de conexiones para determinar cuál es la mejor ruta a una red cualquiera dentro del sistema autónomo. Esto se consigue generando un árbol de ruta más corta, que es una representación gráfica de la ruta más corta a una determinada red dentro del sistema autónomo. Aunque todos los enrutadores tienen la misma base de datos de estado de conexiones, sus árboles de ruta más corta son exclusivos, ya que los enrutadores generan estos árboles situándose a sí mismos en su raíz.

ÁreasDe forma predeterminada, todos los enrutadores se agrupan en una única área troncal llamada area 0 o “backbone” (normalmente es el área 0.0.0.0). Sin embargo, las redes de gran tamaño que se encuentran dispersas geográficamente se suelen segmentar en múltiples áreas. A medida que la red se amplía, las bases de datos de estado de conexión también crecen y se dividen en grupos más pequeños para mejorar su posibilidad de ampliación.

Vista general

Capítulo 3: Abrir primero la ruta más corta

Las áreas reducen el volumen de información de enrutamiento que pasa a través de la red, ya que cada enrutador sólo tiene que actualizar la base de datos de estado del área a la que pertenece. No necesita actualizar la información de estado de las redes o enrutadores que se encuentran en otras áreas. Un enrutador conectado a múltiples áreas mantiene una base de estado de conexiones por cada área a la que está conectado. Las áreas deben estar conectadas directamente al área 0, excepto cuando crean una conexión virtual. Para obtener más información sobre conexiones virtuales, consulte la página 62.

Las notificaciones externas de AS describen rutas a destinos en otros sistemas AS y se inundan en todo un AS. Ciertas áreas OSPF se pueden configurar como áreas de rutas internas (stub areas); de este modo, las notificaciones externas de sistemas autónomos no inundarán estas áreas. En OSPF se utilizan normalmente dos tipos de áreas habituales:

Área de ruta interna: área que recibe resúmenes de ruta del área troncal pero que no recibe notificaciones de estado de conexiones de otras áreas acerca de enrutadores reconocidos por protocolos distintos a OSPF (BGP, por ejemplo). Un área de ruta interna se puede considerar un área exclusiva de rutas internas (totally stubby) si en ella no se admiten rutas de resumen.

Área NSSA: al igual que las áreas de rutas internas normales, las NSSA (Not So Stubby Area, áreas no exclusivas de rutas internas) no pueden recibir enrutadores de protocolos distintos de OSPF fuera del área actual. Sin embargo, los enrutadores externos conocidos dentro del área también se pueden reconocer en otras áreas, y así pasar a ellas.

Clasificación de enrutadoresLos enrutadores que participan en el enrutamiento OSPF se clasifican de acuerdo con su función o su posición en la red:

Enrutador interno: enrutador cuyas interfaces pertenecen a la misma área.

Enrutador de área troncal: enrutador con una interfaz en el área troncal.

Enrutador de límite de área: enrutador conectado a dos o más áreas. Este tipo de enrutador resume las rutas desde distintas áreas para su distribución al área troncal. En los dispositivos de seguridad con OSPF, el área troncal se crea de forma predeterminada. Si se crea una segunda área en un enrutador virtual, el dispositivo funcionará como enrutador de límite de área.

Enrutador de límite de sistema autónomo: cuando un área OSPF limita con otro sistema autónomo, el enrutador situado entre los dos sistemas autónomos se considera el enrutador de límite. Estos enrutadores se encargan de distribuir la información de enrutamiento de los sistemas autónomos externos por su sistema autónomo.

Vista general 49


50

Protocolo de saludoDos enrutadores con interfaces en la misma subred se consideran vecinos. Los enrutadores utilizan el protocolo de saludo para establecer y mantener estas relaciones de vecindad. Cuando dos enrutadores establecen comunicación bidireccional, se dice que han establecido una adyacencia. Si dos enrutadores no establecen una relación de adyacencia, no podrán intercambiar información de enrutamiento.

Cuando hay múltiples enrutadores en una red, es necesario configurar un enrutador como enrutador designado y otro como enrutador designado de respaldo. El enrutador designado es responsable de inundar la red con LSA que contengan una lista de todos los enrutadores que admitan OSPF incorporados a la red. El enrutador designado es el único que puede formar adyacencias con otros enrutadores de la red. Así, el enrutador designado es el único de la red que puede proporcionar información de enrutamiento al resto de enrutadores. El enrutador designado de respaldo sustituye al enrutador designado en caso de que éste falle.

Tipos de redesLos dispositivos de seguridad de Juniper Networks admiten los siguientes tipos de redes OSPF:

Redes de difusión

Redes punto a punto

Redes punto a multipunto

Redes de difusiónUna red de difusión (broadcast) es una red que interconecta varios enrutadores y que puede enviar (o difundir) un único mensaje físico a todos los enrutadores conectados. Se parte de la base de que dos enrutadores cualesquiera en una red de difusión son capaces de comunicarse entre sí. Ethernet es un ejemplo de red de difusión.

En las redes de difusión, el enrutador OSPF detecta dinámicamente los enrutadores vecinos enviando paquetes de saludo a la dirección multidifusión 224.0.0.5. En las redes de difusión, el protocolo de saludo decide cuál será el enrutador designado y el enrutador designado de respaldo para la red.

Una red que no sea de difusión conecta varios enrutadores entre sí pero no puede difundir mensajes a los enrutadores conectados. En las redes que no son de difusión, los paquetes del protocolo OSPF (que normalmente son multidifusión) se tienen que enviar a cada uno de los enrutadores vecinos. Los dispositivos de seguridad Juniper Networks no admiten OSPF en redes que no sean de difusión.

Redes punto a puntoUna red punto a punto une dos enrutadores a través de una red de área extensa (WAN). Un ejemplo de red punto a punto serían dos dispositivos de seguridad conectados a través de un túnel VPN IPSec. En las redes punto a punto, el enrutador OSPF detecta dinámicamente los enrutadores vecinos enviando paquetes de saludo a la dirección multicast 224.0.0.5.

Vista general


Redes punto a multipuntoUna red punto a multipunto es una red que no es de difusión en la que OSPF trata las conexiones entre enrutadores como vínculos punto a punto. Para la red no existe ninguna elección de un enrutador designado ni de inundación LSA. Un enrutador en una red punto a multipunto envía paquetes de saludo a todos los vecinos con quienes pueda comunicarse directamente.

Notificaciones de estado de conexionesCada enrutador OSPF envía notificaciones de estado de conexiones (LSA) que definen la información de estado local del enrutador. Además, hay otros tipos de LSA que un enrutador envía, dependiendo de la función de OSPF del enrutador. La Tabla 5 detalla los tipos de LSA, dónde se inunda cada tipo de LSA y el contenido de cada tipo de LSA.

Tabla 5: Resumen del contenido y tipos de LSA

Configuración básica de OSPF

Creará OSPF por cada enrutador virtual en un dispositivo de seguridad. Si dispone de varios enrutadores virtuales (VR) en un sistema, podrá habilitar una instancia de OSPF por cada enrutador virtual.

NOTA: En dispositivos de seguridad, la configuración punto a multipunto del OSPF solamente se admite en interfaces de túnel y se debe inhabilitar route-deny para que la red funcione correctamente. No se puede configurar una interfaz física Ethernet para conexiones punto a multipunto. Para obtener más información, consulte “Interfaz de túnel punto a multipunto” en la página 71.

Tipo de LSA Enviado porDistribuido en Información enviada en la LSA

LSA de enrutador

Todos los enrutadores OSPF Área Describe el estado de todas las interfaces de enrutador en toda el área.

LSA de red Enrutador designado en redes de difusión y NBMA

Área Contiene una lista de todos los enrutadores conectados a la red.

LSA de resumen

Enrutadores de límite de área Área Describe una ruta a un destino fuera del área, pero dentro del sistema autónomo. Hay dos tipos:

Las LSA de resumen de tipo 3 describen rutas a redes.

Las LSA de resumen de tipo 4 describen rutas limítrofes con otros sistemas autónomos.

Externo de sistema autónomo

Enrutador de límite de sistema autónomo

Sistema autónomo

Rutas a redes en otro sistema autónomo. A menudo, se trata de la ruta predeterminada (0.0.0.0/0).

NOTA: Antes de configurar un protocolo de enrutamiento dinámico en el dispositivo de seguridad, deberá asignar una ID de enrutador virtual, tal y como se describe en el Capítulo 2,“Enrutamiento.”

Configuración básica de OSPF 51


52

En esta sección se describen los pasos básicos para configurar OSPF en un enrutador virtual ubicado en un dispositivo de seguridad:

1. Crear y habilitar la instancia de enrutamiento OSPF en un enrutador virtual. En este paso también se crea automáticamente un área troncal de OSPF, con una ID de área de 0.0.0.0, que no se podrá eliminar.

2. (Opcional) A menos que todas las interfaces OSPF se conecten al área troncal, tendrá que configurar una nueva área OSPF con su propia ID de área. Por ejemplo, si el dispositivo de seguridad va a funcionar como enrutador de límite de área, tendrá que crear otra área OSPF además del área troncal. La nueva área que se cree podrá ser normal, de rutas internas o no exclusiva de rutas internas.

3. Asignar una o varias interfaces a cada área OSPF. Las interfaces se deben agregar a un área OSPF explícitamente, incluyendo el área troncal.

4. Habilitar OSPF en cada interfaz.

5. Comprobar que el protocolo OSPF está configurado correctamente y funciona.

En este ejemplo configuraremos el dispositivo de seguridad como enrutador de límite de área conectándolo al área 0 a través de la interfaz ethernet3 y al área 10 a través de ethernet1. Consulte la Figura 10.

Figura 10: Ejemplo de configuración de OSPF

Opcionalmente también es posible configurar otros parámetros de OSPF, como:

Parámetros globales, como conexiones virtuales, que se configuran en el enrutador virtual para el protocolo OSPF (consulte “Parámetros globales de OSPF” en la página 61).

Parámetros de interfaz, como la autenticación, que se configuran en la interfaz para el protocolo OSPF (consulte “Ajuste de parámetros OSPF de interfaz” en la página 64).

Parámetros OSPF relacionados con la seguridad, que se configuran en el enrutador virtual o en la interfaz (consulte “Configuración de seguridad” en la página 67).

Zona Trust ethernet1 ethernet3 Zona Untrust

Internet

Área 0Área 10

10.1.1.0/24 10.1.2.0/24



Creación y eliminación de una instancia de enrutamiento OSPFEs posible crear y habilitar una instancia de enrutamiento OSPF en un VR específico ubicado en un dispositivo de seguridad. Para eliminar una instancia de enrutamiento OSPF, desactive la instancia OSPF y luego elimínela. Al crear la instancia de enrutamiento OSPF se crea automáticamente el área troncal OSPF. Si crea y habilita una instancia de enrutamiento OSPF en un enrutador virtual, OSPF podrá transmitir y recibir paquetes en todas las interfaces habilitadas para OSPF del enrutador.

Creación de una instancia de OSPFEn el siguiente ejemplo, en primer lugar asignará 0.0.0.10 como ID de enrutador a trust-vr. A continuación creará una instancia de enrutamiento OSPF en él. (Para obtener más información sobre VR y la configuración de un VR en dispositivos de seguridad, consulte “Enrutamiento” en la página 13).

WebUI

1. ID de enrutadorNetwork > Routing > Virtual Router (trust-vr) > Edit: Introduzca los siguientes datos y haga clic en OK:

Virtual Router ID: Custom (seleccione)En el cuadro de texto, introduzca 0.0.0.10

2. Instancia de enrutamiento OSPFNetwork > Routing > Virtual Router (trust-vr) > Edit > Create OSPF Instance: Seleccione OSPF Enabled, luego haga clic en OK.

CLI

1. ID de enrutadorset vrouter trust-vr router-id 10

2. Instancia de enrutamiento OSPFset vrouter trust-vr protocol ospfset vrouter trust-vr protocol ospf enablesave

Eliminación de una instancia de OSPFEn este ejemplo inhabilitará la instancia de enrutamiento OSPF en el enrutador virtual trust-vr. OSPF dejará de transmitir y procesar paquetes OSPF en todas las interfaces habilitadas para OSPF en el enrutador trust-vr.

WebUI

Network > Routing > Virtual Routers (trust-vr) > Edit > Edit OSPF Instance: Desactive OSPF Enabled, luego haga clic en OK.

Network > Routing > Virtual Routers (trust-vr) > Edit > Delete OSPF Instance, luego haga clic en OK en el mensaje de confirmación.

NOTA: En la línea de comandos CLI, tendrá que crear la instancia de enrutamiento OSPF antes de poder habilitarla. Por lo tanto, tendrá que ejecutar dos comandos CLI para habilitar una instancia de enrutamiento OSPF.



54

CLI

unset vrouter trust-vr protocol ospfdeleting OSPF instance, are you sure? y/[n]save

Creación y eliminación de un área OSPFLas áreas reducen el volumen de información de enrutamiento que tiene que pasar por la red, ya que los enrutadores OSPF sólo actualizan la base de datos de estado de conexiones del área a la que pertenecen. No necesitan actualizar la información de estado de las redes o enrutadores que se encuentran en otras áreas.

Todas las zonas deben conectarse a la zona 0, que se crea al configurar una instancia de enrutamiento OSPF en el enrutador virtual. Si es necesario crear un área OSPF adicional, también es posible definirla como área de rutas internas o área no exclusiva de rutas internas. Si desea más información sobre estos tipos de áreas, consulte “Áreas” en la página 48.

La Tabla 6 detalla los parámetros de área, con descripciones de cada parámetro, e indica el valor predeterminado de cada uno de éstos.

Tabla 6: Parámetros de áreas de OSPF y sus valores predeterminados

Creación de un área OSPFEn el siguiente ejemplo creará un área OSPF con la ID de area 10.

WebUI

Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance > Area: Introduzca los siguientes datos y haga clic en OK:

Area ID: 10Type: normal (seleccione)Action: Add

NOTA: En CLI, confirme la eliminación de la instancia OSPF.

Parámetro de área DescripciónValor predeterminado

Metric for default route (Sólo áreas NSSA y de rutas internas.) Especifica la métrica para la notificación de ruta predeterminada

1

Metric type for the default route

(Sólo área NSSA.) Especifica el tipo de métrica externa (1 ó 2) para la ruta predeterminada

1

No summary (Sólo áreas NSSA y de rutas internas.) Especifica que las LSA de resumen no se difundirán por el área

Las LSA de resumen se difunden por el área

Range (Todas las áreas.) Especifica un rango de direcciones IP que se notificarán en las LSA de resumen, y si éstas se notificarán o no

—



CLI

set vrouter trust-vr protocol ospf area 10save

Eliminación de un área OSPFAntes de que pueda eliminar un área de OSPF, debe desactivar el proceso de OSPF para VR. En el siguiente ejemplo, detenga el proceso de OSPF y luego elimine un área de OSPF con una ID de área de 10.

WebUI

Network > Routing > Virtual Routers (trust-vr) > Edit > Edit OSPF Instance: Elimine la selección OSPF Enabled, luego haga clic en OK.

Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance > Area: Haga clic en Remove.

CLI

unset vrouter trust-vr protocol ospf enableunset vrouter trust-vr protocol ospf area 0.0.0.10save

Asignación de interfaces a un área OSPFUna vez que se ha creado un área, es posible asignarle una o varias interfaces, ya sea utilizando la WebUI o el comando CLI set interface.

Asignación de interfaces a áreasEn el siguiente ejemplo asignará la interfaz ethernet1 al area OSPF 10 y la interfaz ethernet3 al area OSPF 0.

WebUI

Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance > Area > Configure (Area 10): Utilice el botón Add para mover la interfaz ethernet1 de la columna Available Interface(s) a la columna Selected Interfaces. Haga clic en OK.

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Area > Configure (Area 0): Utilice el botón Add para mover la interfaz ethernet3 de la columna Available Interface(s) a la columna Selected Interfaces. Haga clic en OK.

CLI

set interface ethernet1 protocol ospf area 10set interface ethernet3 protocol ospf area 0save



56

Configuración de un rango de áreasDe forma predeterminada, un enrutador de límite de área no agrega las rutas enviadas de un área a otra. Si configura un rango de áreas permitirá que un grupo de subredes en un área se consolide en una única dirección de red para notificarse en otras áreas por medio de una única notificación de conexión de resumen. Al configurar un rango de áreas, deberá especificar si desea notificar o retener el rango de áreas definido en las notificaciones.

En el siguiente ejemplo definirá los siguientes rangos de áreas para el area 10:

10.1.1.0/24, se notificará.

10.1.2.0/24, no se notificará.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Area > Configure (0.0.0.10): Introduzca los siguientes datos en la sección Area Range y haga clic en Add:

IP/Netmask: 10.1.1.0/24Type: (seleccione) Advertise

Introduzca los siguientes datos en la sección Area Range y haga clic en Add:

IP/Netmask: 10.1.2.0/24Type: (seleccione) No Advertise

CLI

set vrouter trust-vr protocol ospf area 10 range 10.1.1.0/24 advertiseset vrouter trust-vr protocol ospf area 10 range 10.1.2.0/24 no-advertisesave

Habilitación de OSPF en interfacesDe forma predeterminada, el protocolo OSPF está inhabilitado en todas las interfaces del enrutador virtual (VR). Este protocolo se debe habilitar explícitamente en una interfaz antes de poder asignarla a un área. Si se desactiva OSPF en una interfaz, dejará de transmitir o recibir paquetes en esa interfaz, pero sus parámetros de configuración se conservarán.

Habilitación de OSPF en interfacesEn este ejemplo habilitará la instancia de enrutamiento OSPF en la interfaz ethernet1 (que previamente se había asignado al area 10) y en la interfaz ethernet3 (que previamente se asignó al area 0).

NOTA: Si se desactiva la instancia de enrutamiento OSPF en el enrutador virtual (consulte “Eliminación de una instancia de OSPF” en la página 53), OSPF dejará de transmitir y procesar paquetes en todas las interfaces del enrutador que tengan este protocolo habilitado.



WebUI

Network > Interfaces > Edit (para ethernet1) > OSPF: Seleccione Enable Protocol OSPF, luego haga clic en Apply.

Network > Interfaces > Edit (para ethernet3) > OSPF: Seleccione Enable Protocol OSPF, luego haga clic en Apply.

CLI

set interface ethernet1 protocol ospf enableset interface ethernet3 protocol ospf enablesave

Inhabilitar OSPF en una interfazEn este ejemplo inhabilitará la instancia de enrutamiento OSPF únicamente en la interfaz ethernet1. Las demás interfaces del enrutador virtual trust-vr (VR) en que se habilitó OSPF seguirán transmitiendo y procesando paquetes OSPF.

WebUI

Network > Interfaces > Edit (para ethernet1) > OSPF: Elimine Enable Protocol OSPF, luego haga clic en Apply.

CLI

unset interface ethernet1 protocol ospf enablesave

Verificación de la configuraciónPuede ver la configuración introducida para trust-vr ejecutando el siguiente comando CLI:

device-> get vrouter trust-vr protocol ospf configVR: trust-vr RouterId: 10.1.1.250----------------------------------set protocol ospfset enableset area 0.0.0.10 range 10.1.1.0 255.255.255.0 advertiseset area 0.0.0.10 range 10.1.2.0 255.255.255.0 no-advertiseset interface ethernet1 protocol ospf area 0.0.0.10set interface ethernet1 protocol ospf enableset interface ethernet3 protocol ospf area 0.0.0.0set interface ethernet3 protocol ospf enable

NOTA: Si se desactiva la instancia de enrutamiento OSPF en el enrutador virtual, OSPF dejará de transmitir y procesar paquetes en todas las interfaces del enrutador que tengan este protocolo habilitado (consulte “Eliminación de una instancia de OSPF” en la página 53).



58

Puede verificar si OSPF se está ejecutando en el enrutador virtual con el comando get vrouter trust-vr protocol ospf.

device-> get vrouter trust-vr protocol ospfVR: trust-vr RouterId: 10.1.1.250----------------------------------OSPF enabledSupports only single TOS(TOS0) routeEnrutador internoAutomatic vlink creation is disabledNumbers of areas is 2Number of external LSA(s) is 0SPF Suspend Count is 10 nodesHold time between SPFs is 3 second(s)Advertising default-route lsa is offDefault-route discovered by ospf will be added to the routing tableRFC 1583 compatibility is disabled.Hello packet flooding protection is not enabledLSA flooding protection is not enabledArea 0.0.0.0 Total number of interfaces is 1, Active number of interfaces is 1 SPF algorithm executed 2 times Number of LSA(s) is 1Area 0.0.0.10 Total number of interfaces is 1, Active number of interfaces is 1 SPF algorithm executed 2 times Number of LSA(s) is 0

Las zonas resaltadas muestran que OSPF se está ejecutando y verifican las zonas OSPF activas y las interfaces activas en cada zona OSPF.

Puede verificar si OSPF está habilitado en las interfaces y ver el estado de las interfaces con el comando get vrouter trust-vr protocol ospf interface.

device-> get vrouter trust-vr protocol ospf interfaceVR: trust-vr RouterId: 10.1.1.250----------------------------------Interface IpAddr NetMask AreaId Status State--------------------------------------------------------------------------------ethernet3 2.2.2.2 255.255.255.0 0.0.0.0 enabled Designated Routerethernet1 10.1.1.1 255.255.255.0 0.0.0.10 enabled Up

Puede configurar la prioridad del enrutador virtual que desee seleccionar: el enrutador designado (DR) o el enrutador designado de respaldo (BDR). En el ejemplo anterior, la columna de estado (State) indica la prioridad del enrutador virtual.

NOTA: Es recomendable asignar una ID de enrutador de forma explícita, en lugar de utilizar el valor predeterminado. Para obtener más información sobre cómo configurar una ID de enrutador, consulte “Enrutamiento” en la página 13.



Puede verificar si la instancia de enrutamiento OSPF en el dispositivo de seguridad ha establecido adyacencias con los vecinos OSPF ejecutando el comando get vrouter trust-vr protocol ospf neighbor.

device-> get vrouter trust-vr protocol ospf neighborVR: trust-vr RouterId: 10.1.1.250---------------------------------- Neighbor(s) on interface ethernet3 (Area 0.0.0.0)IpAddr/If Index RouterId Priority State Options------------------------------------------------------------------------------2.2.2.2 2.2.2.250 1 Full ENeighbor(s) on interface ethernet1 (Area 0.0.0.10)IpAddr/If Index RouterId Priority State Options------------------------------------------------------------------------------10.1.1.1 10.1.1.252 1 Full E

En la columna “State” del ejemplo anterior, “Full” indica adyacencias OSPF completas con vecinos.

Redistribución de rutas en protocolos de enrutamiento

La redistribución de rutas es el intercambio de información sobre rutas entre protocolos de enrutamiento. Por ejemplo, se pueden redistribuir los siguientes tipos de rutas en la instancia de enrutamiento OSPF de un mismo enrutador virtual:

Rutas reconocidas por BGP o RIP

Rutas conectadas directamente

Rutas importadas


Cuando se configura la redistribución de rutas, primero se debe especificar un mapa de rutas para filtrar las rutas que se vayan a redistribuir. Para obtener más información sobre la creación de mapas de rutas para la redistribución, consulte el Capítulo 2, “Enrutamiento.”

En el siguiente ejemplo redistribuirá en el dominio de enrutamiento OSPF actual una ruta originada en un dominio de enrutamiento BGP. Tanto en el ejemplo de la WebUI como en el de la CLI, partiremos de la base de que ya ha creado un mapa de rutas llamado add-bgp.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Redistributable Rules: Introduzca los siguientes datos y haga clic en Add:

Route Map: add-bgpProtocol: BGP

CLI

set vrouter trust-vr protocol ospf redistribute route-map add-bgp protocol bgpsave

Redistribución de rutas en protocolos de enrutamiento 59


60

Resumen de rutas redistribuidas

En las grandes redes, donde pueden coexistir miles de direcciones de red, algunos enrutadores podrían llegar a congestionarse por la gran cantidad de información de ruta. Si ya redistribuyó rutas de un protocolo externo en la instancia de enrutamiento OSPF actual, podrá reunir las rutas en una ruta de red general o resumida. Al resumir múltiples direcciones, hará que un grupo de rutas se reconozcan como una sola, simplificando así el proceso de consulta.

Una de las ventajas de crear resúmenes de rutas en redes grandes y complejas es que se pueden aislar los cambios topológicos de otros enrutadores. Por ejemplo, si una conexión específica en un dominio falla continuamente, la ruta resumida no cambiaría, de modo que ningún enrutador externo al dominio tendría que modificar una y otra vez su tabla de enrutamiento debido a los fallos de conexión.

Además de crear menos entradas en las tablas de enrutamiento de los enrutadores troncales, la generación de resúmenes evita que las LSA se propaguen por otras áreas cuando una de las redes incluidas en el resumen queda fuera de línea o vuelve a ponerse en línea. En los resúmenes también se pueden incluir rutas interzonales y rutas externas.

En ocasiones, una ruta resumida puede crear oportunidades para que se produzcan bucles. Puede configurar una ruta hacia una interfaz NULL para evitar bucles. Al final de esta sección encontrará un ejemplo de creación de una ruta resumida y un ejemplo de establecer una interfaz NULL.

Resumen de rutas redistribuidasEn este ejemplo redistribuirá las rutas BGP a la instancia de enrutamiento OSPF actual. A continuación resumirá el conjunto de rutas importadas en la dirección de red 2.1.1.0/24.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Redistributable Rules: Introduzca los siguientes datos y haga clic en Add:

Route Map: add-bgpProtocol: BGP

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Summary Import: Introduzca los siguientes datos y haga clic en Add:

IP/Netmask: 2.1.1.0/24

CLI

set vrouter trust-vr protocol ospf redistribute route-map add-bgp protocol bgpset vrouter trust-vr protocol ospf summary-import ip 2.1.1.0/24save

Resumen de rutas redistribuidas


Parámetros globales de OSPF

En esta sección se describen parámetros globales de OSPF que se pueden configurar de forma opcional en un enrutador virtual (VR). Cuando se configura un parámetro OSPF en el nivel de enrutador virtual, los datos de configuración afectarán a las operaciones de todas las interfaces que tengan habilitado el protocolo OSPF. Es posible modificar los valores de los parámetros globales del protocolo de enrutamiento OSPF por medio de las interfaces CLI y WebUI.

La Tabla 7 detalla los parámetros globales de OSPF y sus valores predeterminados.

Tabla 7: Parámetros globales de OSPF y sus valores predeterminados

Parámetros globales de OSPF Descripción

Valor predeterminado

Advertise default route

Especifica que una ruta predeterminada activa (0.0.0.0/0) en la tabla de rutas del enrutador virtual se notifica en todas las áreas OSPF. También es posible especificar el valor de métrica o si la métrica original de la ruta se preservará, así como el tipo de métrica (ASE tipo 1 o tipo 2). También se puede especificar que la ruta predeterminada siempre se notifique.

La ruta predeterminada no se notifica.

Reject default route Especifica que cualquier ruta predeterminada reconocida en OSPF no se agregará a la tabla de rutas.

La ruta predeterminada reconocida en OSPF se agrega a la tabla de rutas.

Automatic virtual link

Especifica que el VR creará una conexión virtual automáticamente si no puede acceder al área troncal de OSPF.

Desactivado.

Maximum hello packets

Especifica el número máximo de paquetes de saludo OSPF que el VR puede recibir en un intervalo de saludo.

10.

Maximum LSA packets

Especifica el número máximo de paquetes LSA de OSPF que el VR puede recibir dentro del intervalo en segundos especificado.

No hay valor predeterminado.

RFC 1583 compatibility

Especifica que la instancia de enrutamiento OSPF es compatible con la norma RFC 1583, una versión anterior de OSPF.

OSPF versión 2, tal y como se define en RFC 2328.

Enrutamiento multidireccional de igual coste (ECMP)

Especifica el número máximo de rutas (1-4) a utilizar para equilibrar cargas con los destinos que tengan múltiples rutas de igual coste. Consulte la “Configuración del enrutamiento multidireccional de igual coste” en la página 36.

Disabled (1).

Virtual link configuration

Configura el área OSPF y la ID de enrutador para la conexión virtual. De forma opcional también puede configurar el método de autenticación, el intervalo de saludo y el de retransmisión, el retardo de transmisión o el intervalo de interlocutor muerto para la conexión virtual.

No hay conexión virtual configurada.

Parámetros globales de OSPF 61


62

Notificación de la ruta predeterminadaLa ruta predeterminada, 0.0.0.0/0, coincide con cada red de destino en una tabla de rutas, aunque un prefijo más específico anulará la ruta predeterminada.

En este ejemplo, usted anunciará la ruta predeterminada de la instancia de enrutamiento OSPF actual.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance: Seleccione Advertising Default Route Enable, luego haga clic en OK.

CLI

set vrouter trust-vr protocol ospf advertise-default-route metric 1 metric-type 1save

Conexiones virtualesAunque todas las áreas deben estar conectadas directamente al área troncal, algunas veces debe crear un área nueva que no se puede conectar físicamente al área troncal. Para resolver este problema se puede configurar una conexión virtual. Una conexión virtual proporciona un área remota con una ruta lógica al área troncal a través de otra área.

En los enrutadores, la conexión virtual se debe configurar en los dos extremos de la conexión. Para configurar una conexión virtual en el dispositivo de seguridad, debe definir:

La ID del área OSPF que va a cruzar la conexión virtual. No es posible crear una conexión virtual que cruce el área troncal o un área de rutas internas.

La ID del enrutador al otro extremo de la conexión virtual.

La Tabla 8 detalla los parámetros opcionales para las conexiones virtuales.

Tabla 8: Parámetros opcionales para conexiones virtuales

NOTA: En la WebUI, la métrica predeterminada (1) 62 debe introducirse manualmente y el tipo de métrica predeterminado es ASE tipo 1.

Parámetro de conexión virtual Descripción


Authentication Especifica la autenticación por contraseña de texto no encriptado o la autenticación MD5.

Sin autenticación

Dead interval Especifica el intervalo en segundos en que no se producirá respuesta desde un dispositivo OSPF vecino antes de que se determine que éste no funciona.

40 segundos

Hello interval Especifica el tiempo en segundos entre dos saludos OSPF.

10 segundos

Parámetros globales de OSPF


Creación de una conexión virtualEn el siguiente ejemplo creará una conexión virtual a través del área OSPF 10 desde el dispositivo-A con ID de enrutador 10.10.1.250 al dispositivo-B con la ID de enrutador 10.1.1.250. Consulte “Enrutamiento” en la página 13 para obtener más información sobre la configuración de ID de enrutadores en los dispositivos de seguridad). También puede configurar la conexión virtual con un retardo de tránsito de 10 segundos. En cada dispositivo de seguridad, tendrá que identificar la ID de enrutador del dispositivo en el otro extremo de la conexión virtual.

La Figura 11 muestra el ejemplo de configuración de red para una conexión virtual.

Figura 11: Creación de una conexión virtual

WebUI (dispositivo-A)

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Virtual Link: Introduzca los siguientes datos y haga clic en Add:

Area ID: 10 (seleccione)Router ID: 10.1.1.250

> Configure: En el campo Transmit Delay, escriba 10 y haga clic en OK.

Retransmit interval

Especifica el tiempo en segundos que transcurrirá antes de que la interfaz reenvíe una LSA a un vecino que no respondió a la primera LSA.

5 segundos

Transmit delay Especifica el tiempo en segundos entre las transmisiones de paquetes de actualización de estado de conexión enviados a una interfaz.

1 segundo

Parámetro de conexión virtual Descripción


Área 10

Área 20

ethernet1

Dispositivo B

ethernet2

Área 0

InternetID de enrutador 10.1.1.250

El dispositivo-A y el dispositivo-B tienen una conexión virtual entre sí a través del área OSPF 10.

Dispositivo A ethernet 1

ethernet 2

ID de enrutador10.1.1.250

NOTA: Debe habilitar OSPF en ambas interfaces de cada dispositivo y cerciorarse de que OSPF se esté ejecutando en las interfaces de los dispositivos A y B antes de que la conexión virtual se active.

Parámetros globales de OSPF 63


64

CLI (dispositivo-A)

set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.1.1.250set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.1.1.250 transit-delay

10save

WebUI (dispositivo-B)

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance > Virtual Link: Introduzca los siguientes datos y haga clic en Add:

Area ID: 10Router ID: 10.10.1.250

> Configure: En el campo Transmit Delay, escriba 10 y haga clic en OK.

CLI (dispositivo-B)

set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.10.1.250 set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.10.1.250

transit-delay 10save

Creación de una conexión virtual automáticaPuede hacer que un enrutador virtual (VR) cree automáticamente una conexión virtual para las instancias en las que no sea posible acceder al área troncal de la red. Si el enrutador virtual crea conexiones virtuales automáticamente se ahorrará el tiempo necesario para crear cada una de las conexiones virtuales de forma manual. En el siguiente ejemplo configuraremos la creación automática de conexiones virtuales.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance: Seleccione Automatically Generate Virtual Links, luego haga clic en OK.

CLI

set vrouter trust-vr protocol ospf auto-vlinksave

Ajuste de parámetros OSPF de interfaz

En esta sección se describen los parámetros OSPF que se pueden configurar en el nivel de interfaz. Cuando se configura un parámetro OSPF en el nivel de interfaz, los datos de configuración afectan únicamente al funcionamiento OSPF de la interfaz especificada. Puede modificar los ajustes de los parámetros de la interfaz mediante comandos de interfaz en la CLI o utilizando la WebUI.

NOTA: En la interfaz CLI, primero tendrá que crear la conexión virtual y, a continuación, configurar cualquier parámetro opcional para la conexión. Así, en el ejemplo anterior, tendrá que ejecutar dos comandos distintos para crear y después configurar la conexión virtual.



La Tabla 9 detalla los parámetros opcionales de interfaz de OSPF y sus valores predeterminados.

Tabla 9: Parámetros opcionales de interfaz de OSPF y sus valores predeterminados

Parámetro OSPF de interfaz Descripción Valor predeterminado

Authentication Especifica si la comunicación OSPF de la interfaz se verificará mediante autenticación por contraseña de texto no encriptado o por MD5 (Message Digest 5). La contraseña de texto no encriptado debe ser una cadena de hasta 8 dígitos, mientras que la contraseña para autenticación MD5 puede ser una cadena de hasta 16 dígitos. Para la contraseña MD5 también es necesario que se configuren cadenas clave.

No se utiliza autenticación.

Cost Especifica la métrica de la interfaz. El coste asociado a una interfaz depende del ancho de banda de la conexión que tenga establecida dicha interfaz. Cuanto mayor sea el ancho de banda, menor será el valor del coste (preferible).

1 para una conexión de 100 MB o más10 para una conexión de 10 MB100 para una conexión de 1 MB

Dead interval Especifica el intervalo en segundos en que no se producirá respuesta desde un dispositivo OSPF vecino antes de que OSPF determine que no funciona.

40 segundos.

Hello interval Especifica el intervalo en segundos que transcurrirá entre el envío de un paquete de saludo a la red y el siguiente.

10 segundos.

Link type Especifica una interfaz de túnel como vínculo punto a punto o como vínculo punto a multipunto. Consulte la “Interfaz de túnel punto a multipunto” en la página 71.

Las interfaces Ethernet se tratan como interfaces de difusión.

De forma predeterminada, las interfaces de túnel asociadas a las zonas OSPF son punto a punto.

Neighbor list Especifica subredes, en forma de lista de acceso, en las que residen vecinos OSPF que pueden utilizarse para formar adyacencias.

Ninguna (las adyacencias se forman con todos los vecinos de la interfaz).

Passive Interface

Especifica que la dirección IP de la interfaz se notificará en el dominio OSPF como ruta OSPF y no como ruta externa, pero que la interfaz no transmitirá ni recibirá paquetes OSPF. Esta opción resulta útil cuando en la interfaz también se ha habilitado BGP.

Las interfaces con OSPF habilitado transmiten y reciben paquetes OSPF.

Priority Especifica la prioridad del enrutador virtual que se elegirá: enrutador designado o enrutador designado de respaldo. El enrutador con el valor de prioridad más alto tiene más posibilidades de ser elegido (aunque no se garantiza).

1.

Retransmit interval

Especifica el tiempo en segundos que transcurrirá antes de que la interfaz reenvíe una LSA a un vecino que no respondió a la primera LSA.

5 segundos.

Ajuste de parámetros OSPF de interfaz 65


66

En el siguiente ejemplo, configuramos los siguientes parámetros OSPF para la interfaz ethernet1:

Aumentar el intervalo entre los mensajes de saludo en OSPF a 15 segundos.

Aumentar el intervalo entre las retransmisiones OSPF a 7 segundos.

Aumentar el intervalo entre las transmisiones de LSA a 2 segundos.

WebUI

Network > Interfaces > Edit (para ethernet1) > OSPF: Introduzca los siguientes datos, luego haga clic en Apply:

Hello Interval: 15Retransmit Interval: 7Transit Delay: 2

CLI

set interface ethernet1 protocol ospf hello-interval 15set interface ethernet1 protocol ospf retransmit-interval 7set interface ethernet1 protocol ospf transit-delay 2save

Transit delay Especifica el tiempo en segundos entre las transmisiones de paquetes de actualización de estado de conexión enviados a la interfaz.

1 segundo.

Demand circuit (Sólo interfaces de túnel) Configura una interfaz de túnel como circuito de demanda, según RFC 1793. Consulte “Creación de un circuito de demanda OSPF en una interfaz de túnel” en la página 71.

Desactivado.

Reduce flooding Especifica la reducción de inundaciones LSA en un circuito de demanda.

Desactivado.

Ignore MTU Especifica que se pase por alto cualquier incoherencia en los valores de la unidad de transmisión máxima (MTU) entre las interfaces locales y remotas que se encuentre durante las negociaciones de la base de datos OSPF será ignorada. Esta opción sólo debe utilizarse cuando la MTU de la interfaz local sea más lenta que la MTU de la interfaz remota.

Desactivado.

Parámetro OSPF de interfaz Descripción Valor predeterminado

NOTA: Para formar adyacencias, todos los enrutadores OSPF de un área deben utilizar los mismos valores en el intervalo de saludo, el intervalo muerto y el intervalo de retransmisión.



Configuración de seguridad

En esta sección se describen posibles problemas de seguridad en el dominio de enrutamiento OSPF y métodos de prevención de ataques.

Autenticación de vecinosUn enrutador OSPF se puede suplantar fácilmente, ya que las LSA no se encriptan y la mayoría de los analizadores de protocolo permiten desencapsular paquetes OSPF. La mejor forma de acabar con el riesgo de este tipo de ataques será autenticando los vecinos OSPF.

OSPF ofrece dos formas de validar los paquetes OSPF recibidos de los vecinos: por autenticación de contraseña simple y por autenticación MD5. Todos los paquetes OSPF recibidos en la interfaz que no se autentiquen se descartarán. De forma predeterminada, ninguna interfaz OSPF tiene la autenticación habilitada.

Para la autenticación MD5 se necesita la misma clave utilizada para los enrutadores OSPF de envío y recepción. Puede especificar más de una clave MD5 en el dispositivo de seguridad, cada una de las cuales tendrá su propia clave. Si configura varias claves MD5 en el dispositivo de seguridad, podrá seleccionar un identificador para la clave que se utilizará para autenticar las comunicaciones con el enrutador vecino. De esta forma es posible cambiar periódicamente las claves MD5 por parejas de enrutadores minimizando el riesgo de que algún paquete se descarte.

Configuración de una contraseña de texto no cifradoEn este ejemplo, crearemos la contraseña de texto no encriptado 12345678 para OSPF en la interfaz ethernet1.

WebUI


Password: (seleccione), 12345678

CLI

set interface ethernet1 protocol ospf authentication password 12345678save

Configuración de una contraseña MD5En el siguiente ejemplo, creará dos claves MD5 distintas para la interfaz ethernet1 y seleccionará una de ellas para que sea la clave activa. Cada clave MD5 puede tener 16 caracteres. El número identificador de clave debe estar entre 0 y 255. El identificador de clave predeterminado es 0, de manera que no es necesario especificar el identificador de clave para la primera clave MD5 que introduzca.

NOTA: Para que OSPF sea más seguro, todos los enrutadores de un dominio OSPF deben configurarse con el mismo nivel de seguridad. De lo contrario, un solo enrutador OSPF peligroso podría llegar a dejar fuera de línea todo el domino de enrutamiento OSPF.

Configuración de seguridad 67


68

WebUI


Authentication:MD5 Keys: (seleccione)

12345678901234569876543210987654Key ID: 1Preferred: (seleccione)

CLI

set interface ethernet1 protocol ospf authentication md5 1234567890123456set interface ethernet1 protocol ospf authentication md5 9876543210987654

key-id 1set interface ethernet1 protocol ospf authentication md5 active-md5-key-id 1save

Configuración de una lista de vecinos de OSPFLos entornos de acceso múltiple permiten que los dispositivos, incluyendo los enrutadores, se puedan conectar a una red de forma relativamente sencilla. Esto puede provocar problemas de estabilidad o rendimiento si el dispositivo conectado no es fiable.

De forma predeterminada, la instancia de enrutamiento OSPF en el enrutador virtual (VR) ScreenOS forma adyacencias con todos los vecinos OSPF que se comunican en una interfaz con OSPF. Es posible limitar los dispositivos de una interfaz que pueden formar adyacencias con la instancia de enrutamiento OSPF definiendo una lista de subredes que contengan vecinos OSPF que se puedan elegir. Sólo los hosts o enrutadores que se encuentren en la subredes definidas podrán formar adyacencias con la instancia de enrutamiento OSPF. Para especificar las subredes que contienen vecinos OSPF válidos, se debe definir una lista de acceso a las subredes en el nivel del enrutador virtual (VR).

En este ejemplo configuraremos una lista de acceso que permitirá la comunicación con los hosts de la subred 10.10.10.130/27. A continuación especificaremos la lista de acceso para que configure vecinos OSPF válidos.

WebUI

Network > Routing > Virtual Router (trust-vr) > Access List > New: Introduzca los siguientes datos y haga clic en OK:

Access List ID: 4Sequence No.: 10IP/Netmask: 10.10.10.130/27Action: Permit (seleccione)


Neighbor List: 4



CLI

set vrouter trust-vr access-list 4 set vrouter trust-vr access-list 4 permit ip 10.10.10.130/27 10set interface ethernet1 protocol ospf neighbor-list 4 save

Rechazo de rutas predeterminadasEn los ataques con desvío de rutas, un enrutador inyecta una ruta predeterminada (0.0.0.0/0) en el dominio de enrutamiento para que los paquetes se desvíen a él. El enrutador puede descartar los paquetes, causando una interrupción en el servicio, o puede entregar información crítica a los paquetes antes de reenviarlos. En los dispositivos de seguridad de Juniper Networks, OSPF acepta en principio cualquier ruta predeterminada reconocida en OSPF y agrega la ruta predeterminada a la tabla de rutas.

En el siguiente ejemplo especificaremos que una ruta predeterminada no se reconozca en OSPF.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance: Seleccione la casilla de verificación Do Not Add Default-route Learned in OSPF, luego haga clic en OK.

CLI

set vrouter trust-vr protocol ospf reject-default-routesave

Protección contra inundacionesUn enrutador peligroso o que no funcione correctamente puede inundar a sus vecinos con paquetes de saludo OSPF o con LSA. Cada enrutador capta la información de las LSA enviadas por otros enrutadores en la red para recuperar la información de rutas para la tabla de enrutamiento. La protección contra inundaciones de LSA permite determinar el número de LSA que entrarán en el enrutador virtual (VR). Si éste recibe demasiadas LSA, el enrutador fallará por una inundación LSA. Los ataques por LSA se producen cuando un enrutador genera un número excesivo de LSA en un periodo corto de tiempo, puesto que hace que los demás enrutadores OSPF de la red se mantengan ocupados ejecutando el algoritmo SPF.

En los enrutadores virtuales que utilizan ScreenOS, es posible configurar el número máximo de paquetes de saludo por intervalo de saludo y el número máximo de LSA que recibirá una interfaz OSPF durante un intervalo determinado. Los paquetes que excedan el límite configurado se descartarán. De forma predeterminada, el límite de paquetes de saludo OSPF es de 10 paquetes por intervalo de saludo (el intervalo de saludo predeterminado para una interfaz OSPF es de 10 segundos). No hay ningún límite de LSA predefinido; si no impone un límite de LSA, se aceptarán todas.



70

Configuración de un umbral de saludoEn el siguiente ejemplo configuraremos un umbral de 20 paquetes por intervalo de saludo. Este intervalo, que se puede configurar independientemente en cada interfaz OSPF, no variará; seguirá ajustado a 10 segundos.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance: Introduzca los siguientes datos y haga clic en OK:

Prevent Hello Packet Flooding Attack: OnMax Hello Packet: 20

CLI

set vrouter trust-vr protocol ospf hello-threshold 20save

Configuración de un umbral de LSAEn este ejemplo estableceremos un límite OSPF de 10 paquetes LSA cada 20 segundos para evitar ataques por inundación de LSA.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF Instance: Introduzca los siguientes datos y haga clic en OK:

LSA Packet Threshold Time: 20Maximum LSAs: 10

CLI

set vrouter trust-vr protocol ospf lsa-threshold 20 10save

Habilitación de la inundación reducidaPuede habilitar la característica de reducción de inundaciones para suprimir la inundación LSA en las interfaces de punto a punto, como serie, de túnel o línea asíncrona de abonado digital (ADSL), o interfaces de difusión, como las interfaces de Ethernet. En el ejemplo siguiente, habilitará la supresión periódica de LSA sin afectar al flujo de paquetes de saludo hacia la interfaz tunnel.1.

WebUI

Network > Interfaces > Edit (para tunnel.1) > OSPF: Introduzca los siguientes datos, luego haga clic en Apply:

Reduce Flooding: (seleccione)

CLI

set interface tunnel.1 protocol ospf reduce-floodingsave



Creación de un circuito de demanda OSPF en una interfaz de túnel

Los circuitos de demanda de OSPF, según lo definido en la norma RFC 1793, son segmentos de red en los que el tiempo de conexión o de utilización afecta al coste de uso de dichas conexiones. En un circuito de demanda, el tráfico generado por OSPF necesita limitarse a los cambios en la topología de la red. En los dispositivos de seguridad de Juniper Networks, únicamente las interfaces de punto a punto, como las interfaces serie, de túnel o de línea asíncrona de abonado digital (ADSL), pueden ser circuitos de demanda, y para que funcionen adecuadamente, ambos extremos del túnel se deben configurar manualmente como circuitos de demanda.

En interfaces de túnel configuradas como circuitos de demanda, el dispositivo de seguridad suprime el envío de paquetes de saludo OSPF y la actualización periódica de inundaciones LSA para disminuir la sobrecarga. Cuando el vecino OSPF alcanza el estado completo “Full” (los saludos “Hello”coinciden y los LSA del enrutador y de la red reflejan a todos los vecinos adyacentes), el dispositivo de seguridad suprime los paquetes de saludo periódicos y el LSA se actualiza. El dispositivo de seguridad inunda solamente LSA cuyo contenido haya cambiado.

En el ejemplo siguiente, configurará la interfaz tunnel.1 como un circuito de demanda.

WebUI

Network > Interfaces > Edit > OSPF: Introduzca los siguientes datos, luego haga clic en Apply:

Demand Circuit: (seleccione)

CLI

set interface tunnel.1 protocol ospf demand-circuitsave

Interfaz de túnel punto a multipunto

Al asociar una interfaz de túnel a una zona OSPF en un dispositivo de seguridad, de forma predeterminada se crea un túnel OSPF punto a punto. La interfaz de túnel punto a punto puede formar una adyacencia con solamente un enrutador OSPF en el extremo remoto. Si la interfaz de túnel local va a ser asociada a múltiples túneles, debe configurar la interfaz de túnel local como interfaz punto a multipunto e inhabilitar la característica route-deny en la interfaz de túnel.

NOTA: Deberá configurar la interfaz de túnel del interlocutor remoto como un circuito de demanda. Sin embargo, no necesita configurar la inundación LSA reducida en el interlocutor remoto.

Creación de un circuito de demanda OSPF en una interfaz de túnel 71


72

Para ver un ejemplo de asociación de túneles múltiples a una interfaz de túnel, consulte “Binding Automatic Route and NHTB Table Entries” en la página 5-278. Las siguientes secciones incluyen ejemplos para:

Configurar el tipo de conexión (consulte “Establecer el tipo de conexión OSPF” en la página 72)

Establecer la función de rechazo de ruta (consulte “Inhabilitación de la restricción Route-Deny” en la página 72)

Configurar una red con una interfaz de túnel de punto a multipunto (consulte “Creación de una red punto a multipunto” en la página 73)

Establecer el tipo de conexión OSPFSi se propone formar adyacencias OSPF en múltiples túneles, necesitará establecer el tipo de conexión como punto a multipunto (p2mp).

En el siguiente ejemplo establecerá el tipo de conexión de tunnel.1 en punto a multipunto (p2mp) para cumplir con los requisitos de su red.

WebUI

Network > Interface > Edit > OSPF: Seleccione Point-to-Multipoint de la lista de botones de opción “Link Type”.

CLI

set interface tunnel.1 protocol ospf link-type p2mpsave

Inhabilitación de la restricción Route-DenyDe forma predeterminada, el dispositivo de seguridad puede enviar y recibir paquetes a través de la misma interfaz a menos que esté configurado explícitamente para no enviarlos y recibirlos en la misma interfaz. En un entorno punto a multipunto, este comportamiento puede ser deseable. Para configurar el dispositivo de seguridad para enviar y recibir en la misma interfaz, debe inhabilitar la restricción route-deny. En este ejemplo inhabilitará la restricción route-deny mediante CLI en la interfaz de túnel punto a multipunto tunnel.1.

WebUI

NOTA: Debe configurar una interfaz de túnel como interfaz punto a multipunto antes de habilitar OSPF en la interfaz. Una vez configurada la interfaz como interfaz punto a multipunto, ya no podrá configurarla como circuito de demanda (consulte “Creación de un circuito de demanda OSPF en una interfaz de túnel” en la página 71). No obstante, puede configurar la interfaz para la inundación LSA reducida.

NOTA: Para establecer la restricción route-deny debe utilizarse la CLI.



CLI

unset interface tunnel.1 route-denysave

Creación de una red punto a multipuntoLa Figura 12 muestra una empresa de tamaño mediano con su oficina central (OC) en San Francisco y delegaciones en Chicago, Los Angeles, Montreal y Nueva York. Cada oficina tiene un solo dispositivo de seguridad.

Los siguientes son los requisitos de configuración específicos del dispositivo de seguridad en la OC:

1. Configurar el VR para que ejecute una instancia de OSPF, habilitar OSPF y, a continuación, configurar la interfaz tunnel.1.

2. Configurar las cuatro VPN y asociarlas a la interfaz tunnel.1.

Los siguientes son los requisitos de configuración propios de los dispositivos de seguridad remotos:

1. Configurar el VR para que ejecute una instancia de OSPF, habilitar OSPF y, a continuación, configurar la interfaz tunnel.1.

2. Configurar la VPN y asociarla a la interfaz tunnel.1.

Los valores de temporizadores para todos los dispositivos deben coincidir para que las adyacencias puedan formarse. La Figura 12 muestra el escenario descrito de la red.

Interfaz de túnel punto a multipunto 73


74

Figura 12: Ejemplo de red punto a multipunto

En la Figura 12, se originan cuatro VPN en el dispositivo de seguridad de San Francisco e irradian hacia las oficinas remotas en Nueva York, Los Angeles, Montreal y Chicago.

En este ejemplo, configurará los siguientes ajustes en el dispositivo de seguridad de la oficina central OC:

1. Interfaces y zona de seguridad

2. VPN

3. Rutas y OSPF

Para completar la configuración de la red, configurará los siguientes ajustes en cada uno de los cuatro dispositivos de seguridad de las oficinas remotas:

1. Interfaz y OSPF

2. VPN

3. Directiva

Los Angeles Montreal

Chicago

tunnel.1 10.0.0.4 untrust 4.4.4.4

tunnel.1 10.0.0.3 untrust 3.3.3.3

Nueva York

tunnel.1 10.0.0.2 Untrust 2.2.2.2

tunnel.1 10.0.0.5 Untrust 5.5.5.5

VPN 1

VPN 2

Internet

VPN 3

VPN 4

San Francisco (OC) ethernet3 1.1.1.1 tunnel.1 10.0.0.1 4 VPN asociadas a tunnel.1



WebUI (dispositivo de la oficina central)

1. Interfaces y zona de seguridadNetwork > Interfaces > Haga clic en New Tunnel IF y continúe en la página de configuración.

Network > Interfaces > Edit (para ethernet3) y configure la zona y la dirección IP.

Network > Interface > Edit (para tunnel.1) > OSPF: Seleccione Point-to-Multipoint de la lista de botones de opción “Link Type”.

2. VPNVPNs > AutoKey Advanced > Gateway

3. Rutas y OSPFNetwork > Routing > Virtual Routers > Haga clic en Edit para el enrutador virtual y configure los parámetros de OSPF.

CLI (dispositivo de la oficina central)

1. Interfaces y zona de seguridadset interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24set interface tunnel.1 zone untrustset interface tunnel.1 ip 10.10.10.1/24

2. VPNset ike gateway gw1 address 2.2.2.2 main outgoing-interface ethernet3 preshare

ospfp2mp proposal pre-g2-3des-shaset ike gateway gw2 address 3.3.3.3 main outgoing-interface ethernet3 preshare



ospfp2mp proposal pre-g2-3des-shaset vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn1 monitor rekeyset vpn1 id 1 bind interface tunnel.1set vpn vpn2 gateway gw2 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn2 monitor rekeyset vpn2 id 2 bind interface tunnel.1set vpn vpn3 gateway gw3 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn3 monitor rekeyset vpn3 id 3 bind interface tunnel.1set vpn vpn4 gateway gw4 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn4 monitor rekeyset vpn4 id 4 bind interface tunnel.1

NOTA: Los procedimientos de WebUI aparecen abreviados debido a que el ejemplo es muy largo. La porción CLI del ejemplo está completa. Puede consultar en la porción CLI los ajustes y valores exactos que deben utilizarse.



76

3. Rutas y OSPFset vrouter trust router-id 10set vrouter trust protocol ospfset vrouter trust protocol ospf enableset interface tunnel.1 protocol ospf area 0set interface tunnel.1 protocol ospf enableset interface tunnel.1 protocol ospf link-type p2mpunset interface tunnel.1 route-denysave

Puede seguir estos pasos para configurar el dispositivo de seguridad de la oficina remota. Los dispositivos de seguridad de Juniper Networks aprenden sobre sus vecinos a través de LSA.

Para completar la configuración mostrada en la Figura 12 en la página 74, debe repetir la sección siguiente por cada dispositivo remoto y cambiar las direcciones IP, los nombres de puerta de enlace y los nombres de VPN, así como establecer directivas para cumplir las necesidades de la red. En cada sitio remoto, las zonas trust y untrust cambian.

WebUI (dispositivo de oficina remota)

1. Interfaz y OSPFNetwork > Interfaces > Haga clic en New Tunnel IF y continúe con la página de configuración.


3. DirectivaDirectivas (de todas las zonas a todas las zonas) > Haga clic en New

CLI (dispositivo de oficina remota)

1. Interfaz y OSPFset vrouter trust protocol ospfset vrouter trust protocol ospf enableset interface untrust ip 2.2.2.2/24set interface tunnel.1 zone untrustset interface tunnel.1 ip 10.0.0.2/24set interface tunnel.1 protocol ospf area 0set interface tunnel.1 protocol ospf enable

NOTA: De forma predeterminada, route-deny está inhabilitado. Sin embargo, si habilitó la característica route-deny en algún momento, necesitará inhabilitar la característica para que la interfaz de túnel punto a multipunto funcione correctamente.




2. VPNset ike gateway gw1 address 1.1.1.1/24 main outgoing-interface untrust preshare

ospfp2mp proposal pre-g2-3des-shaset vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn1 monitor rekeyset vpn vpn1 id 1 bind interface tunnel.1

3. Directiva (configure como sea necesario)set policy id 1 from trust to untrust any any any permitset policy id 2 from untrust to trust any any any permitsave

Puede ver los nuevos cambios ejecutando el comando get vrouter enrut_virtual protocol ospf config.



78

Capítulo 4

Protocolo de información de enrutamiento

En este capítulo se describe la versión 2 del protocolo de información de enrutamiento (RIP) en los dispositivos de seguridad de Juniper Networks. Incluye las siguientes secciones:


“Configuración básica de RIP” en la página 81

“Creación y eliminación de una instancia RIP” en la página 82

“Habilitación y deshabilitación de RIP en interfaces” en la página 83


“Visualización de la información de RIP” en la página 85

“Visualización de la base de datos RIP” en la página 85

“Visualización de los detalles de RIP” en la página 86

“Visualización de información de vecino RIP” en la página 87

“Visualización de detalles de RIP para una interfaz específica” en la página 88

“Parámetros globales de RIP” en la página 89

“Notificación de la ruta predeterminada” en la página 90

“Configuración de los parámetros de interfaz de RIP” en la página 90


“Autenticar vecinos al establecer una contraseña” en la página 92

“Configuración de vecinos fiables” en la página 93


“Protección contra inundaciones” en la página 94

79


80

“Configuraciones opcionales de RIP” en la página 96

“Configuración de la versión de RIP” en la página 96

“Habilitación e inhabilitación de un resumen de prefijos” en la página 98

“Establecimiento de rutas alternas” en la página 99

“Circuitos de demanda en interfaces de túnel” en la página 101

“Configuración de un vecino estático” en la página 102

“Configuración de una interfaz de túnel punto a multipunto” en la página 102

Vista general

El protocolo de información de enrutamiento RIP (Routing information protocol) es un protocolo de vector distancia que se utiliza como protocolo de puerta de enlace interior (IGP) en sistemas autónomos (AS) de tamaño moderado. ScreenOS admite la versión 2 de RIP (RIPv2) tal como se define en la norma RFC 2453. Mientras que RIPv2 sólo admite la autenticación de contraseña simple (texto sin formato), la implementación RIP de ScreenOS también admite extensiones de autenticación MD5, tal como se definen en la norma RFC 2082.

El protocolo RIP administra la información de rutas en redes pequeñas y homogéneas, como las LAN corporativas. La ruta más larga admitida en una red RIP es de 15 saltos. Un valor métrico de 16 indica un destino no válido o inaccesible (este valor también se denomina “infinito” ya que excede el máximo de 15 saltos permitidos para las redes RIP).

El protocolo RIP no está diseñado para grandes redes o para redes en las que las rutas se eligen en función de parámetros en tiempo real, como carga, fiabilidad o retardo medido. El protocolo RIP admite redes punto a punto (utilizadas con VPN) y redes Ethernet de difusión/multidifusión (broadcast/multicast). El protocolo RIP admite las conexiones de "punto a multipunto" a través de las interfaces de túnel con o sin tener configurado un circuito de demanda. Para obtener más información sobre circuitos de demanda, consulte “Circuitos de demanda en interfaces de túnel” en la página 101.

El protocolo RIP envía mensajes que contienen la tabla de enrutamiento completa a todos los enrutadores vecinos cada 30 segundos. Estos mensajes se envían normalmente como multidifusiones (multicast) a la dirección 224.0.0.9 del puerto RIP.

NOTA: El protocolo RIP no se admite en interfaces de túnel sin numerar. Se deben numerar todas las interfaces que utilizan protocolo RIP. Cualquier intento por configurar y ejecutar una interfaz sin numerar utilizando RIP puede provocar un fallo impredecible en el enrutamiento.

Vista general

Capítulo 4: Protocolo de información de enrutamiento

La base de datos de enrutamiento RIP contiene una entrada para cada destino que sea accesible a través de la instancia de enrutamiento RIP. La base de datos de enrutamiento RIP incluye la siguiente información:

Dirección IPv4 de un destino. Recuerde que RIP no distingue entre redes y hosts.

Dirección IP del primer enrutador de la ruta hacia el destino (el siguiente salto).

Interfaz de red utilizada para acceder al primer enrutador.

Valor métrico que indica la distancia (o coste) para alcanzar el destino. La mayoría de implementaciones RIP utilizan un valor métrico de 1 para cada red.

Un temporizador que indica el tiempo que ha transcurrido desde la última actualización de la entrada de la base de datos.

Configuración básica de RIP

Creará RIP por cada enrutador virtual en un dispositivo de seguridad. Si dispone de varios enrutadores virtuales (VR) dentro de un sistema, podrá habilitar múltiples instancias de RIP, una instancia de la versión 1 o de la 2 por cada enrutador virtual. De forma predeterminada, los dispositivos de seguridad de Juniper Networks admiten la versión 2 de RIP.

En esta sección se describen los pasos básicos para configurar el protocolo RIP en un dispositivo de seguridad:

1. Crear la instancia de enrutamiento RIP en un enrutador virtual.

2. Habilitar la instancia RIP.

3. Habilitar RIP en las interfaces que conectan con otros enrutadores RIP.

4. Redistribuir las rutas reconocidas de otros protocolos de enrutamiento (como OSPF, BGP, o rutas configuradas de forma estática) en la instancia RIP.

En esta sección se describe la correcta ejecución de cada una de estas tareas utilizando la interfaz WebUI y la línea de comandos CLI.

NOTA: Antes de configurar un protocolo de enrutamiento dinámico en el dispositivo de seguridad, deberá asignar una ID de enrutador virtual, tal y como se describe en “Enrutamiento” en la página 13.

Configuración básica de RIP 81


82

Opcionalmente, es posible configurar parámetros de RIP, como:

Parámetros globales, como temporizadores y vecinos RIP fiables, que se configuran en el VR para el protocolo RIP (consulte “Parámetros globales de RIP” en la página 89)

Parámetros de interfaz, como la autenticación de dispositivos vecinos, que se configuran en la interfaz para el protocolo RIP (consulte “Configuración de los parámetros de interfaz de RIP” en la página 90)

Parámetros RIP relacionados con la seguridad, que se configuran en el enrutador virtual o en la interfaz (consulte “Configuración de seguridad” en la página 92)

Creación y eliminación de una instancia RIPCada instancia de enrutamiento de RIP se crea y se habilita en un enrutador virtual (VR) específico ubicado en un dispositivo de seguridad. Cuando se crea y se habilita una instancia de enrutamiento de RIP en un enrutador virtual, RIP transmite y recibe paquetes en todas las interfaces habilitadas para RIP de dicho enrutador.

Cuando se elimina una instancia de enrutamiento de RIP en un enrutador virtual, se eliminan las configuraciones RIP correspondientes para todas las interfaces de dicho enrutador.

(Para obtener más información sobre VR y su configuración en dispositivos de seguridad, consulte “Enrutamiento” en la página 13.

Creación de una instancia RIPCree una instancia de enrutamiento RIP en el trust-vr y a continuación habilite el RIP.

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit: Escriba una Virtual Router ID y luego seleccione Create RIP Instance.

Seleccione Enable RIP y haga clic en OK.

CLI


2. Instancia de enrutamiento de RIPset vrouter trust-vr protocol ripset vrouter trust-vr protocol rip enablesave

NOTA: En CLI, el proceso de crear una instancia de enrutamiento RIP se realiza en dos etapas. Cree la instancia RIP y, a continuación, habilite RIP.



Eliminación de una instancia RIPEn este ejemplo, inhabilitará la instancia de enrutamiento de RIP en trust-vr. RIP dejará de transmitir y procesar paquetes en todas las interfaces habilitadas para RIP en trust-vr.

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance: Anule la selección de Enable RIP y haga clic en OK.

Network > Routing > Virtual Router (trust-vr) > Edit > Delete RIP Instance y luego haga clic en OK en el mensaje de confirmación.

CLI

unset vrouter trust-vr protocol rip enableunset vrouter trust-vr protocol ripsave

Habilitación y deshabilitación de RIP en interfacesDe forma predeterminada, el protocolo RIP está inhabilitado en todas las interfaces del enrutador virtual (VR) y es necesario habilitarlo de forma explícita en una interfaz. Si se inhabilita RIP a nivel de interfaz, RIP no transmitirá ni recibirá paquetes en la interfaz especificada. Los parámetros de configuración de interfaz se conservan cuando se inhabilita RIP en una interfaz.

Habilitar RIP en una interfazEn este ejemplo, habilitará RIP en la interfaz Trust.

WebUI

Network > Interface > Edit (para Trust) > RIP: Seleccione Protocol RIP Enable, luego haga clic en Apply.

CLI

set interface trust protocol rip enablesave

Inhabilitación de RIP en una interfazEn este ejemplo, inhabilitará RIP en la interfaz Trust. Para eliminar completamente la configuración de RIP introduzca el segundo comando CLI antes de guardar.

WebUI

Network > Interface (para Trust) > RIP: Elimine el Protocol RIP Enable, luego haga clic en Apply.

NOTA: Si se desactiva la instancia de enrutamiento de RIP en el enrutador virtual (consulte “Eliminación de una instancia RIP” en la página 83), RIP dejará de transmitir y procesar paquetes en todas las interfaces del enrutador que tengan este protocolo habilitado.

Configuración básica de RIP 83


84

CLI

unset interface trust protocol rip enableunset interface trust protocol ripsave

Redistribución de rutasLa redistribución de rutas es el intercambio de información sobre rutas entre protocolos de enrutamiento. Por ejemplo, los siguientes tipos de rutas se pueden redistribuir en la instancia de enrutamiento de RIP de un mismo enrutador virtual (VR):

Rutas reconocidas por el protocolo BGP

Rutas reconocidas por el protocolo OSPF


Rutas importadas


Es necesario configurar un mapa de rutas para filtrar las rutas distribuidas. Para obtener más información sobre la creación de mapas de rutas para la redistribución, consulte “Enrutamiento” en la página 13.

Las rutas importadas en RIP a partir de otros protocolos tienen un valor métrico predeterminado de 10. Este valor se puede modificar (consulte “Parámetros globales de RIP” en la página 89).

En este ejemplo, redistribuirá rutas estáticas que se encuentran en la subred 20.1.0.0/16 entre dispositivos vecinos RIP ubicados en el enrutador virtual trust-vr. Para ello, primero deberá crear una lista de acceso para permitir las direcciones en la subred 20.1.0.0/16. A continuación, configure un mapa de rutas que permita las direcciones incluidas en la lista de acceso que acaba de generar. Utilice el mapa de rutas para especificar la redistribución de rutas estáticas en la instancia de enrutamiento de RIP.

WebUI



Network > Routing > Virtual Router (trust-vr) > Route Map > New: Introduzca los siguientes datos y haga clic en OK:

Map Name: rtmap1Sequence No.: 1Action: Permit (seleccione)Match Properties:

Access List: (seleccione), 20 (seleccione)



Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance > Redistributable Rules: Introduzca los siguientes datos y haga clic en Add:

Route Map: rtmap1 (seleccione)Protocol: Static (seleccione)

CLI

set vrouter trust-vr access-list 20 permit ip 20.1.0.0/16 1set vrouter trust-vr route-map name rtmap1 permit 1set vrouter trust-vr route-map rtmap1 1 match ip 20set vrouter trust-vr protocol rip redistribute route-map rtmap1 protocol staticsave

Visualización de la información de RIP

Después de modificar los parámetros RIP, puede visualizar los siguientes tipos de detalles de RIP:

Base de datos, que muestra la información de enrutamiento

Protocolo, que proporciona los detalles de interfaz y de RIP de un enrutador virtual (VR)

Vecinos

Visualización de la base de datos RIPPuede verificar la información de enrutamiento de RIP desde la CLI. Puede elegir visualizar una lista completa de todas las entradas de la base de datos RIP o de una sola entrada.

En este ejemplo, visualiza la información detallada desde la base de datos RIP. Puede visualizar todas las entradas de la base de datos o limitar el resultado a una sola entrada de la base de datos añadiendo la dirección IP y la máscara del VR que desee.

En este ejemplo, especifica trust-vr y añade el prefijo y la dirección IP 10.10.10.0/24 para visualizar una sola entrada de la tabla.

WebUI

CLI

get vrouter trust-vr protocol rip database prefix 10.10.10.0/24save

NOTA: Debe utilizar la CLI para visualizar la base de datos RIP.

Visualización de la información de RIP 85


86

Después de introducir el siguiente comando CLI, puede visualizar la entrada de la base de datos RIP:

device-> get vrouter trust-vr protocol rip database 10.10.10.0/24VR: trust-vr-------------------------------------------------------------------------Total database entry: 3Flags : Added in Multipath - M, RIP - R, Redistributed - I, Default (advertised) - D, Permanent - P, Summary - S, Unreachable - U, Hold - HDBID Prefix Nexthop Ifp Cost Flags Source 7 10.10.10.0/24 20.20.20.1 eth1 2 MR 20.20.20.1-------------------------------------------------------------------------

La base de datos RIP contiene los campos siguientes:

DBID, el identificador de base de datos de la entrada

Prefix, el prefijo y la dirección IP

Nexthop, la dirección del salto siguiente (enrutador)

Ifp, el tipo de conexión (Ethernet o túnel)

La métrica de coste asignada para indicar la distancia desde el origen

Los indicadores (flags) pueden ser uno o varios de los siguientes: multidireccional (M), RIP (R), redistribuido (I), notificado de forma predeterminada (D), permanente (P), resumen (S), inaccesible (U) o retención (H).

En este ejemplo, el identificador de base de datos es 7, la dirección IP y el prefijo es 10.10.10.0/24 y el salto siguiente es 20.20.20.1. Es una conexión Ethernet con un coste de 2. Los indicadores son M y R e indican que esta ruta es multidireccional y usa RIP.

Visualización de los detalles de RIPPuede visualizar los detalles de RIP para verificar que la configuración de RIP coincida con sus necesidades de red. Puede limitar el resultado solamente a la tabla de resumen de la interfaz añadiendo interface al comando CLI.

Puede visualizar la información de RIP completa para comprobar una configuración o verificar que los cambios guardados estén activos.

WebUI

CLI

get vrouter trust-vr protocol rip

NOTA: Debe utilizar la CLI para visualizar los detalles de RIP.



Este comando produce resultados similares al siguiente resultado:

device-> get vrouter trust-vr protocol ripVR: trust-vr---------------------------------------------------------------------------- State: enabledVersion: 2Default metric for routes redistributed into RIP: 10Maximum neighbors per interface: 16Not validating neighbor in same subnet: disabledRIP update transmission not scheduledMaximum number of Alternate routes per prefix: 2Advertising default route: disabledDefault routes learnt by RIP will not be acceptedIncoming routes filter and offset-metric: not configuredOutgoing routes filter and offset-metric: not configuredUpdate packet threshold is not configuredTotal number of RIP interfaces created on vr(trust-vr): 1Update| Invalid| Flush| DC Retransmit| DC Poll| Hold Down (Timers in seconds)---------------------------------------------------------------------------- 30| 180| 120| 5| 40|90Flags : Split Horizon - S, Split Horizon with Poison Reverse - P, Passive - I Demand Circuit - DInterface IP-Prefix Admin State Flags NbrCnt Metric Ver-Rx/Tx-----------------------------------------------------------------------------tun.1 122.1.2.114/8 enabled disabled SD 1 1 v1v2/v1v

Puede visualizar los valores de RIP, los detalles del paquete, la información del temporizador RIP y una tabla de interfaz resumida.

Visualización de información de vecino RIPPuede visualizar los detalles sobre los vecinos RIP de un enrutador virtual (VR). Puede recuperar una lista de información de todos los vecinos o una entrada de un vecino específico añadiendo la dirección IP del vecino que desee. Puede comprobar el estado de una ruta y verificar la conexión entre el vecino y el dispositivo de seguridad desde estas estadísticas.

En el ejemplo siguiente, visualice la información de vecino RIP para el trust-vr.

WebUI

CLI

get vrouter trust-vr protocol rip neighbors


device-> get vrouter trust-vr protocol rip neighborsVR: trust-vr--------------------------------------------------------------------------------Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U, Poll - P, Demand Circuit Init - INeighbors on interface tunnel.1--------------------------------------------------------------------------------IpAddress Version Age Expires BadPackets BadRoutes Flags--------------------------------------------------------------------------------10.10.10.1 v2 - - 0 0 TSD

NOTA: Debe utilizar la CLI para visualizar la información de vecino RIP.

Visualización de la información de RIP 87


88

Además de visualizar la dirección IP y la versión de RIP, puede visualizar la información siguiente del vecino RIP:

Antigüedad de la entrada

Tiempo de vencimiento

Número de paquetes incorrectos

Número de rutas incorrectas

Indicadores: estática (S), circuito de demanda (T), NHTB (N), fuera de línea (D), en línea (U), sondeo (P) o inicio de circuito de demanda (I)

Visualización de detalles de RIP para una interfaz específicaPuede visualizar toda la información pertinente de RIP de todas las interfaces y un resumen de los detalles del enrutador vecino. Opcionalmente, puede añadir la dirección IP de un vecino específico para limitar el resultado.

En el ejemplo siguiente, puede visualizar la información sobre la interfaz tunnel.1 del vecino que reside en la dirección IP 10.10.10.2.

WebUI

CLI

get interface tunnel.1 protocol rip neighbor 10.10.10.2


device-> get interface tunnel.1 protocol ripVR: trust-vr----------------------------------------------------------------------------Interface: tunnel.1, IP: 10.10.10.2/8, RIP: enabled, Router: enabledReceive version v1v2, Send Version v1v2State: Down, Passive: NoMetric: 1, Split Horizon: enabled, Poison Reverse: disabledDemand Circuit: configuredIncoming routes filter and offset-metric: not configuredOutgoing routes filter and offset-metric: not configuredAuthentication: noneCurrent neighbor count: 1Update not scheduledTransmit Updates: 0 (0 triggered), Receive Updates: 0Update packets dropped because flooding: 0Bad packets: 0, Bad routes: 0Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U, Poll - PNeighbors on interface tunnel.1----------------------------------------------------------------------------IpAddress Version Age Expires BadPackets BadRoutes Flags----------------------------------------------------------------------------10.10.10.1 - - - 0 0 TSD

f

NOTA: Debe utilizar la CLI para visualizar los detalles de la interfaz RIP.



Desde este resumen de información puede visualizar el número de paquetes incorrectos o de rutas incorrectas presentes, verificar qué gasto de procesamiento añade RIP a la conexión y ver la configuración de la autenticación.

Parámetros globales de RIP

En esta sección se describen los parámetros globales de RIP que se pueden configurar en un enrutador virtual (VR). Cuando se configura un parámetro RIP a nivel de enrutador virtual, los datos de configuración afectarán a las operaciones de todas las interfaces que tengan habilitado el protocolo RIP. Es posible modificar los valores de los parámetros globales del protocolo de enrutamiento RIP por medio de las interfaces CLI y WebUI.

La Tabla 10 detalla los parámetros globales de RIP y sus valores predeterminados.

Tabla 10: Parámetros globales de RIP y sus valores predeterminados

Parámetro global de RIP Descripción

Valores predeterminados

Default metric Valor métrico predeterminado para rutas importadas en RIP a partir de otros protocolos, como OSPF y BGP.

10

Update timer Indica (en segundos) cuándo enviar actualizaciones de rutas RIP a los dispositivos vecinos.

30 segundos

Maximum packets per update

Indica el número máximo de paquetes recibidos por actualización. Sin máximo

Invalid timer Indica el tiempo (en segundos) que tiene que transcurrir para que una ruta deje de ser válida desde el momento en el que un vecino deja de notificar la ruta.

180 segundos

Flush timer Indica el tiempo (en segundos) que tiene que transcurrir para que se elimine una ruta desde el momento de su invalidación.

120 segundos

Maximum neighbors Indica el número máximo de vecinos RIP permitidos. Depende de la plataforma

Trusted neighbors Indica una lista de acceso en la que se definen los vecinos RIP. Si no se especifica ningún vecino, RIP utiliza la difusión o la multidifusión para detectar vecinos en una interfaz. Consulte “Configuración de vecinos fiables” en la página 93.

Todos los vecinos son fiables

Allow neighbors on different subnet

Indica que se admiten vecinos RIP de otras subredes. Desactivado

Advertise default route Indica si se notifica la ruta predeterminada (0.0.0.0/0). Desactivado

Reject default routes Indica si RIP debe rechazar una ruta predeterminada reconocida de otro protocolo. Consulte “Rechazo de rutas predeterminadas” en la página 94.

Desactivado

Incoming route map Indica el filtro para las rutas que debe reconocer RIP. Ninguno

Outgoing route map Indica el filtro para las rutas que debe notificar RIP. Ninguno

Maximum alternate routes

Especifica el número máximo de rutas RIP para el mismo prefijo que se puede añadir a la base de datos de la ruta RIP. Consulte “Establecimiento de rutas alternas” en la página 99.

0

Summarize advertised routes

Especifica la notificación de una ruta de resumen que corresponde a todas las rutas incluidas dentro de un rango de resumen. Consulte “Habilitación e inhabilitación de un resumen de prefijos” en la página 98.

Ninguno

RIP protocol version Especifica la versión de RIP que utiliza el VR. Puede ignorar la versión interfaz a interfaz. Consulte “Configuración de la versión de RIP” en la página 96.

Versión 2

Parámetros globales de RIP 89


90

Notificación de la ruta predeterminada

Puede cambiar la configuración de RIP incluyendo la notificación de la ruta predeterminada (una ruta que no es RIP) y modificando la métrica asociada con la ruta predeterminada presente en una tabla de enrutamiento de VP determinada.

De forma predeterminada, la ruta predeterminada (0.0.0.0/0) no se notifica a los vecinos RIP. El siguiente comando notifica la ruta predeterminada a los vecinos RIP en el enrutador virtual trust-vr con un valor métrico de 5 (hay que introducir un valor métrico). La ruta predeterminada debe existir en la tabla de enrutamiento.

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance: Introduzca los siguientes datos y haga clic en OK:

Advertising Default Route: (seleccione)Metric: 5

CLI

set vrouter trust-vr protocol rip advertise-def-route metric number 5save

Configuración de los parámetros de interfaz de RIP

En esta sección se describen los parámetros RIP que se pueden configurar en el nivel de interfaz. Cuando se configura un parámetro RIP en el nivel de interfaz, los datos de configuración afectan únicamente al funcionamiento RIP de la interfaz especificada. Puede modificar los ajustes de los parámetros de la interfaz mediante comandos de interfaz en la CLI o utilizando la WebUI.

Hold-timer Evita el ‘flapping’ (rechazo) de una ruta a la tabla de rutas. Puede especificar un valor entre los valores mínimo (tres veces el valor del temporizador de actualización (update)) y máximo (suma del temporizador de actualización (update) y el de retención (hold), sin exceder el valor del temporizador flush).

90 segundos

Retransmit timer Especifica el intervalo de retransmisión de las respuestas desencadenadas en un circuito de demanda. Puede establecer el temporizador de retransmisión y asignar una cuenta de reintentos que se ajuste a sus necesidades de red.

5 segundos10 reintentos

Poll-timer Comprueba el vecino remoto del circuito de demanda para ver si está en línea. Puede configurar el temporizador de sondeo en minutos y asignar una cuenta de reintentos que se ajuste a sus necesidades de red. Una cuenta de reintentos de cero (0) supone un sondeo interminable.

180 segundos0 reintentos

Parámetro global de RIP Descripción

Valores predeterminados

NOTA: Consulte el Manual ScreenOS CLI Reference Guide: IPv4 Command Descriptions para obtener más información sobre los parámetros globales que puede configurar en el contexto del protocolo de enrutamiento de RIP.

Notificación de la ruta predeterminada


La Tabla 11 detalla los parámetros de interfaz de RIP y sus valores predeterminados.

Tabla 11: Parámetros de interfaz de RIP y sus valores predeterminados

Puede definir mapas de rutas de entrada y salida en el nivel del enrutador virtual o en el nivel de la interfaz. Un mapa de rutas definido en el nivel de la interfaz tiene preferencia sobre un mapa de rutas definido en el nivel del enrutador virtual. Por ejemplo, si define un mapa de rutas de entrada en el nivel del enrutador virtual y otro mapa de rutas de entrada en el nivel de la interfaz, éste último tendrá preferencia sobre el primero. Para obtener más información, consulte “Configuración de un mapa de rutas” en la página 39.

En el siguiente ejemplo, configuramos los siguientes parámetros RIP para la interfaz trust:

Active la autenticación MD5 con la clave 1234567898765432 y la ID de clave 215.

Habilite la opción de horizonte dividido con rutas inalcanzables para la interfaz.

Parámetro RIP de interfaz Descripción Valor predeterminado

Split-horizon Indica si está habilitada la opción de horizonte dividido (no notificar rutas reconocidas de una interfaz en actualizaciones enviadas a dicha interfaz, "split horizon"). Si está habilitada la opción de horizonte dividido con rutas inalcanzables (poison reverse), las rutas reconocidas de una interfaz se notifican con un valor métrico de 16 en las actualizaciones enviadas a dicha interfaz.

La opción de horizonte dividido está habilitada. Las rutas inalcanzables están inhabilitadas.

RIP metric Especifica la métrica RIP de la interfaz. 1.

Authentication Especifica la autenticación por contraseña de texto no encriptado o la autenticación MD5. Consulte “Autenticar vecinos al establecer una contraseña” en la página 92.

No se utiliza autenticación.

Passive mode Indica que la interfaz puede recibir, pero no transmitir paquetes RIP.

No.

Incoming route map Indica el filtro para las rutas que debe reconocer RIP. Ninguna.

Outgoing route map Indica el filtro para las rutas que debe notificar RIP. Ninguna.

RIP version for sending or receiving updates

Especifica la versión de protocolo RIP utilizada para enviar o recibir actualizaciones en la interfaz. La versión de la interfaz utilizada para enviar actualizaciones no necesita ser la misma que la versión para recibir las actualizaciones. Consulte “Configuración de la versión de RIP” en la página 96.

Versión configurada para el enrutador virtual.

Route summarization Especifica si los resúmenes de rutas están habilitados en la interfaz. Consulte “Habilitación e inhabilitación de un resumen de prefijos” en la página 98.

Desactivado.

Demand-circuit Especifica el circuito de demanda en una interfaz de túnel especificada. El dispositivo de seguridad envía mensajes de actualización solamente cuando se producen cambios. Consulte “Circuitos de demanda en interfaces de túnel” en la página 101.

Ninguna.

Static neighbor IP Especifica la dirección IP de un vecino RIP asignado manualmente.

Ninguna.

Configuración de los parámetros de interfaz de RIP 91


92

WebUI

Network > Interfaces > Edit (para Trust) > RIP: Introduzca los siguientes datos y haga clic en OK:

Authentication: MD5 (seleccione)Key: 1234567898765432Key ID: 215Split Horizon: Enabled with poison reverse (seleccione)

CLI

set interface trust protocol rip authentication md5 1234567898765432 key-id 215

set interface trust protocol rip split-horizon poison-reversesave


En esta sección se describen posibles problemas de seguridad en el dominio de enrutamiento RIP y métodos de prevención de ataques.

Autenticar vecinos al establecer una contraseñaUn enrutador RIP se puede suplantar fácilmente, ya que los paquetes RIP no se encriptan, y la mayoría de los analizadores de protocolo permiten desencapsular paquetes RIP. La mejor forma de acabar con el riesgo de este tipo de ataques será autenticando los vecinos RIP.

RIP ofrece dos formas de validar los paquetes RIP recibidos de los vecinos: por autenticación de contraseña simple y por autenticación MD5. Todos los paquetes RIP recibidos en la interfaz que no se autentiquen se descartarán. De forma predeterminada, ninguna interfaz RIP tiene la autenticación habilitada.

Para la autenticación MD5 es necesario utilizar la misma clave para los enrutadores RIP de envío y recepción. Puede especificar más de una clave MD5 en el dispositivo de seguridad, cada una de las cuales tendrá su propia clave. Si configura varias claves MD5 en el dispositivo de seguridad, podrá seleccionar un identificador para la clave que se utilizará para autenticar las comunicaciones con el enrutador vecino. De esta forma es posible cambiar periódicamente las claves MD5 por parejas de enrutadores minimizando el riesgo de que algún paquete se descarte.

En el siguiente ejemplo, creará dos claves MD5 distintas para la interfaz ethernet1 y seleccionará una de ellas para que sea la clave activa. El identificador de clave predeterminado es 0, de forma que no tendrá que especificar el identificador para la primera clave MD5 que introduzca.

NOTA: Para que RIP sea más seguro, todos los enrutadores de un dominio RIP deben configurarse con el mismo nivel de seguridad. De lo contrario, un solo enrutador RIP comprometido podría llegar a dejar inservible todo el domino de enrutamiento RIP.



WebUI

Network > Interfaces > Edit (para ethernet1) > RIP: Introduzca los siguientes datos, luego haga clic en Apply:

MD5 Keys: (seleccione)1234567890123456 (primer campo de clave)9876543210987654 (segundo campo de clave)Key ID: 1Preferred: (seleccione)

CLI

set interface ethernet1 protocol rip authentication md5 1234567890123456set interface ethernet1 protocol rip authentication md5 9876543210987654

key-id 1set interface ethernet1 protocol rip authentication md5 active-md5-key-id 1save

Configuración de vecinos fiablesLos entornos de acceso múltiple permiten que los dispositivos, incluyendo los enrutadores, se puedan conectar a una red de forma relativamente sencilla. Esto puede provocar problemas de estabilidad o rendimiento si los dispositivos conectados no son fiables. Con objeto de evitar este problema, puede utilizar una lista de acceso para filtrar los dispositivos admitidos como vecinos RIP. De forma predeterminada, sólo se admiten como vecinos RIP los dispositivos ubicados en la misma subred que el enrutador virtual (VR).

En este ejemplo, configurará los siguientes parámetros globales para la instancia de enrutamiento RIP que se está ejecutando en el trust-vr:

El número máximo de vecinos RIP es 1.

La dirección IP del vecino fiable, 10.1.1.1, figura en una lista de acceso.

WebUI




Trusted Neighbors: (seleccione), 10Maximum Neighbors: 1



94

CLI

set vrouter trust-vrdevice(trust-vr)-> set access-list 10 permit ip 10.1.1.1/32 1device(trust-vr)-> set protocol ripdevice(trust-vr/rip)-> set max-neighbor-count 1device(trust-vr/rip)-> set trusted-neighbors 10device(trust-vr/rip)-> exitdevice(trust-vr)-> exitsave

Rechazo de rutas predeterminadasEn los ataques con desvío de rutas, un enrutador inyecta una ruta predeterminada (0.0.0.0/0) en el dominio de enrutamiento para que los paquetes se desvíen a él. El enrutador puede descartar los paquetes, causando una interrupción en el servicio, o puede entregar información crítica a los paquetes antes de reenviarlos. En los dispositivos de seguridad de Juniper Networks, RIP acepta en principio cualquier ruta predeterminada reconocida en RIP y agrega la ruta predeterminada a la tabla de rutas.

En el siguiente ejemplo, configurará la instancia de enrutamiento RIP que se está ejecutando en el trust-vr para que rechace todas las rutas predeterminadas reconocidas en RIP.

WebUI


Reject Default Route Learnt by RIP: (seleccione)

CLI

set vrouter trust-vr protocol rip reject-default-routesave

Protección contra inundacionesUn enrutador que se encuentre comprometido o que no funcione correctamente puede inundar a sus vecinos con paquetes de actualización de enrutamiento RIP. En el enrutador virtual (VR), es posible configurar el número máximo de paquetes de actualización que se pueden recibir en una interfaz RIP durante un intervalo de actualización para impedir la inundación con paquetes de actualización. Todos los paquetes de actualización que excedan el umbral de actualización configurado se descartarán. Si no se establece ningún umbral de actualización, se aceptarán todos los paquetes de actualización.

Es necesario actuar con cuidado al configurar un umbral de actualización cuando los vecinos tienen tablas de enrutamiento de grandes dimensiones, ya que el número de actualizaciones de enrutamiento puede ser bastante elevado durante un intervalo determinado debido a las actualizaciones flash. Los paquetes de actualización que excedan el umbral se descartan, y es posible que no se reconozcan rutas válidas.



Configuración de un umbral de actualizaciónEn este ejemplo, ajustará a 4 el número máximo de paquetes de actualización de enrutamiento que RIP puede recibir en una interfaz.

WebUI


Maximum Number Packets per Update Time: (seleccione), 4

CLI

set vrouter trust-vr protocol rip threshold-update 4save

Habilitación de RIP en interfaces de túnelEn el siguiente ejemplo se crea y habilita una instancia de enrutamiento RIP en el trust-vr del Dispositivo-A. RIP se habilita en la interfaz de túnel VPN y en la interfaz de zona Trust. Sólo las rutas que se encuentran en la subred 10.10.0.0/16 se notifican al vecino RIP del Dispositivo-B. Esto se realiza configurando en primer lugar una lista de acceso que sólo permita las direcciones de la subred 10.10.0.0/16 y especificando después un mapa de rutas abcd que permita las rutas que coincidan con la lista de acceso. A continuación, se indica el mapa de rutas para filtrar las rutas notificadas a los vecinos RIP.

La Figura 13 muestra el escenario descrito de la red.

Figura 13: Ejemplo de interfaz de túnel con RIP

WebUI

Network > Routing > Virtual Router > Edit (para trust-vr) > Create RIP Instance: Seleccione Enable RIP y haga clic en OK.

Network > Routing > Virtual Router > Access List (para trust-vr) > New: Introduzca los siguientes datos y haga clic en OK:


Zona Trust

10.20.0.0/16

10.10.0.0/16

Dispositivo-A (RIP)

Enrutador RIP tunnel.1 Enrutador RIP

Internet Dispositivo-B (RIP) 1.1.1.1/16

2.2.2.2/16

Zona Untrust

Túnel VPN



96

Network > Routing > Virtual Router > Route Map (para trust-vr) > New: Introduzca los siguientes datos y haga clic en OK:

Map Name: abcdSequence No.: 10Action: PermitMatch Properties:Access List: (seleccione), 10

Network > Routing > Virtual Router > Edit (para trust-vr) > Edit RIP Instance: Seleccione los siguientes datos y haga clic en OK:

Outgoing Route Map Filter: abcd

Network > Interfaces > Edit (para tunnel.1) > RIP: Introduzca los siguientes datos, luego haga clic en Apply:

Enable RIP: (seleccione)

Network > Interfaces > Edit (para trust) > RIP: Introduzca los siguientes datos, luego haga clic en Apply:

Enable RIP: (seleccione)

CLI

set vrouter trust-vr protocol ripset vrouter trust-vr protocol rip enableset interface tunnel.1 protocol rip enable set interface trust protocol rip enableset vrouter trust-vr access-list 10 permit ip 10.10.0.0/16 10set vrouter trust-vr route-map name abcd permit 10set vrouter trust-vr route-map abcd 10 match ip 10set vrouter trust-vr protocol rip route-map abcd outsave

Configuraciones opcionales de RIP

Esta sección describe las diversas funciones de RIP que puede configurar.

Configuración de la versión de RIPEn los dispositivos de seguridad de Juniper Networks, puede configurar la versión de Routing Information Protocol (RIP) para el enrutador virtual (VR) y para cada interfaz RIP que envíe y reciba actualizaciones. Según RFC 2453, el VR puede ejecutar una versión de RIP diferente de la instancia de RIP ejecutada en una interfaz determinada. Puede configurar también diversas versiones de RIP para enviar y recibir actualizaciones en una interfaz RIP.

En el VR, puede configurar la versión 1 o la versión 2 de RIP; el valor predeterminado es la versión 2. Para enviar actualizaciones en interfaces RIP, puede configurar la versión 1, la versión 2 o el modo compatible con la versión 1 de RIP (descrito en RFC 2453). Para recibir actualizaciones en interfaces RIP, puede configurar la versión 1 o la versión 2 de RIP o ambas versiones; 1 y 2.



Para enviar y recibir actualizaciones en interfaces RIP, la versión predeterminada de RIP es la versión que está configurada para el VR.

En el ejemplo siguiente, establece la versión 1 de RIP en trust-vr. Para la interfaz ethernet3, establece la versión 2 de RIP tanto para enviar como para recibir actualizaciones.

WebUI

Network > Routing > Virtual Router > Edit (para trust-vr) > Edit RIP Instance: Seleccione V1 for Version, luego haga clic en Apply.

Network > Interfaces > Edit (para ethernet3) > RIP: Seleccione V2 for Sending and Receiving in Update Version, luego haga clic en Apply.

CLI

set vrouter trust-vr protocol rip version 1set interface ethernet3 protocol rip receive-version v2set interface ethernet3 protocol rip send-version v2save

Para verificar la versión de RIP en el VR y en las interfaces RIP, puede introducir el comando get vrouter trust-vr protocol rip.

device-> get vrouter trust-vr protocol ripVR: trust-vr ----------------------------------State: enabledVersion: 1Default metric for routes redistributed into RIP: 10Maximum neighbors per interface: 512Not validating neighbor in same subnet: disabledNext RIP update scheduled after: 14 secAdvertising default route: disabledDefault routes learnt by RIP will be acceptedIncoming routes filter and offset-metric: not configuredOutgoing routes filter and offset-metric: not configuredUpdate packet threshold is not configuredTotal number of RIP interfaces created on vr(trust-vr): 1Update Invalid Flush (Timers in seconds)------------------------------------------------------------- 30 180 120Flags : Split Horizon - S, Split Horizon with Poison Reverse - P, Passive - I Demand Circuit - DInterface IP-Prefix Admin State Flags NbrCnt Metric Ver-Rx/Tx--------------------------------------------------------------------------------ethernet3 20.20.1.2/24 enabled enabled S 0 1 2/2

En el ejemplo de arriba, el dispositivo de seguridad está ejecutando la versión 1 de RIP en trust-vr; pero se está ejecutando la versión 2 de RIP en la interfaz ethernet3 para enviar y recibir actualizaciones.

NOTA: No se recomienda usar ambas versiones 1 y 2 a la vez. Entre la versión 1 y 2 del protocolo pueden producirse complicaciones de red.

Configuraciones opcionales de RIP 97


98

Habilitación e inhabilitación de un resumen de prefijosPuede configurar una ruta de resumen que englobe el rango de prefijos de ruta al que deberá notificar RIP. El dispositivo de seguridad notificará solamente la ruta que corresponde al rango de resumen en lugar de notificar individualmente cada ruta incluida en el rango del resumen. Esto puede reducir el número de entradas de ruta enviadas en las actualizaciones de RIP y reducir el número de entradas que los vecinos RIP necesitan almacenar en sus tablas de enrutamiento. Habilite el resumen de ruta en la interfaz RIP desde la que el dispositivo envía. Puede elegir resumir las rutas en una interfaz y enviar las rutas sin el resumen en otra interfaz.

Al configurar la ruta de resumen, no puede especificar los rangos de prefijos múltiples solapados. Tampoco puede especificar un rango de prefijos que incluya la ruta predeterminada. Puede especificar opcionalmente una métrica para la ruta de resumen. Si no especifica una métrica, se utilizará la métrica más grande para todas las rutas incluidas en el rango de resumen.

En ocasiones, una ruta resumida puede crear oportunidades para que se produzcan bucles. Puede configurar una ruta hacia una interfaz NULL para evitar bucles. Para obtener más información sobre cómo establecer una interfaz NULL, consulte“Evitar bucles creados por las rutas resumidas” en la página 11.

Habilitación de un resumen de prefijosEn el ejemplo siguiente, configure una ruta de resumen 10.1.0.0/16, que englobe los prefijos 10.1.1.0/24 y 10.1.2.0/24. Para permitir que ethernet3 envíe la ruta de resumen en las actualizaciones de RIP, necesita habilitar el resumen en la interfaz.

WebUI

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit RIP Instance > Summary IP: Introduzca los siguientes datos y haga clic en Add:

Summary IP: 10.1.0.0Netmask: 16Metric: 1

Network > Interface > Edit (for ethernet3) > RIP: Seleccione Summarization, luego haga clic en Apply.

CLI

set vrouter trust-vr protocol rip summary-ip 10.1.0.0/16set interface ethernet3 protocol rip summary-enablesave

NOTA: No puede habilitar selectivamente el resumen para un rango de resumen específico; cuando habilita el resumen en una interfaz, todas las rutas de resumen configuradas aparecen en las actualizaciones de enrutamiento.



Inhabilitar un resumen de prefijoEn el ejemplo siguiente, inhabilite una ruta de resumen del prefijo para ethernet3 en el trust-vr.

WebUI

Network > Interfaces > Edit > RIP: Desactive Summarization, luego haga clic en Apply.

CLI

unset vrouter trust-vr protocol rip summary-ip 10.1.0.0/16unset interface ethernet3 protocol rip summary-enablesave

Establecimiento de rutas alternasEl dispositivo de seguridad mantiene una base de datos RIP para las rutas que ha aprendido el protocolo y las rutas que se redistribuyen en RIP. De forma predeterminada, solamente se mantiene la mejor ruta de un prefijo dado en la base de datos. Puede permitir la existencia de una, dos o tres rutas alternativas de RIP para el mismo prefijo en la base de datos RIP. Si permite las rutas alternativas para un prefijo en la base de datos RIP, las rutas al mismo prefijo con un origen RIP o un ‘siguiente salto’ diferente se añaden a la base de datos RIP. Esto hace que RIP pueda admitir los circuitos de demanda y la conmutación por error rápida.

Solamente se añade a la tabla de enrutamiento de un enrutador virtual (VR) y se anuncia en actualizaciones RIP la mejor ruta de la base de datos RIP de un prefijo dado. Si se elimina la mejor ruta de la tabla de enrutamiento de un VR, el RIP añade la siguiente ruta mejor para el mismo prefijo de la base de datos RIP. Si se añade a la base de datos RIP una ruta nueva, que es mejor que la mejor ruta existente en la tabla de enrutamiento de un VR, RIP se actualiza para utilizar la nueva ruta mejor a la tabla de enrutamiento y deja de utilizar la ruta antigua. Según el límite de la ruta alternativa que haya configurado, RIP puede o no eliminar la ruta antigua de la base de datos RIP.

Puede visualizar la base de datos RIP ejecutando este comando CLI: get vrouter enrut_virtual protocol rip database. En el ejemplo siguiente, el número de rutas alternativas para la base de datos RIP se ajusta a un número mayor que 0. La base de datos RIP muestra dos entradas para el prefijo 10.10.70.0/24 en la base de datos RIP, una con un coste de 2 y otra con un coste de 4. La mejor ruta para el prefijo, la ruta con el coste más bajo, se incluye en la tabla de enrutamiento de VR.

NOTA: Recomendamos el uso de rutas alternativas con los circuitos de demanda. Para obtener más información sobre los circuitos de demanda, consulte “Circuitos de demanda en interfaces de túnel” en la página 101.



100

device-> get vrouter trust-vr protocol rip databaseVR: trust-vr --------------------------------------------------------------------------------Total database entry: 14Flags : Added in Multipath - M, RIP - R, Redistributed - I Default (advertised) - D, Permanent - P, Summary - S Unreachable - U, Hold - HDBID Prefix Nexthop Interface Cost Flags Source-------------------------------------------------------------------------------- . . . 47 10.10.70.0/24 10.10.90.1 eth4 2 MR 10.10.90.1 46 10.10.70.0/24 10.10.90.5 eth4 4 R 10.10.90.5

. .

Si está habilitado el enrutamiento multidireccional de igual coste (ECMP) (consulte “Configuración del enrutamiento multidireccional de igual coste” en la página 36) y existen rutas múltiples de igual coste en la base de datos RIP para un prefijo dado, el protocolo RIP añade las rutas múltiples para el prefijo en la tabla de enrutamiento del VR hasta el límite de ECMP. En algunos casos, el límite de la ruta alternativa en la base de datos RIP puede hacer que las rutas RIP no se añadan a la tabla de enrutamiento del VR. Si el límite de ECMP es inferior o igual al límite de la ruta alternativa en la base de datos RIP, las rutas RIP que no se añadan a la tabla de enrutamiento del VR permanecerán en la base de datos RIP; estas rutas se añaden a la tabla de enrutamiento del VR solamente si se elimina una ruta anteriormente añadida o si ya no es la “mejor” ruta RIP para el prefijo de red.

Por ejemplo, si el límite de ECMP es 2 y el límite de la ruta alternativa en la base de datos RIP es 3, solamente podrá haber dos rutas RIP para el mismo prefijo con el mismo coste en la tabla de enrutamiento del VR. Puede haber otras rutas con el mismo prefijo/mismo coste en la base de datos RIP, pero solamente se añaden dos rutas a la tabla de enrutamiento del VR.

En el ejemplo siguiente, establezca en 1 el número de rutas alternativas permitidas para un prefijo de la base de datos RIP en trust-vr. Esto permite que haya una ruta “mejor” y una ruta alternativa en cualquier prefijo dado de la base de datos RIP en el VR.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit RIP Instance: Introduzca 1 en el campo Maximum Alternative Route, luego haga clic en Apply.

CLI

set vrouter trust-vr protocol rip alt-route 1save



Circuitos de demanda en interfaces de túnelUn circuito de demanda es una conexión de punto a punto entre dos interfaces de túnel. La carga de procesamiento de la red es mínima en lo que respecta a la cantidad de mensajes que pasan entre los extremos del circuito de demanda. Los circuitos de demanda de RIP, definidos en la norma RFC 2091 para las redes de área extensa, admiten grandes cantidades de vecinos RIP en los túneles VPN de los dispositivos de seguridad de Juniper Networks.

Los circuitos de demanda de RIP eliminan la transmisión periódica de los paquetes RIP a través de la interfaz de túnel. Para miticar la carga de procesamiento de la red, el dispositivo de seguridad envía la información de RIP solamente cuando se producen cambios en la base de datos de enrutamiento. El dispositivo de seguridad retransmite también las actualizaciones y peticiones hasta que se reciben los reconocimientos válidos. El dispositivo de seguridad aprende los vecinos RIP mediante la configuración de vecinos estática; y si queda fuera de línea el túnel VPN, el protocolo RIP limpia las rutas aprendidas desde la dirección IP del vecino.

Las rutas aprendidas de los circuitos de demanda no caducan con los temporizadores RIP porque los circuitos de demanda están en un estado permanente. Las rutas en estado permanente se eliminan solamente bajo las condiciones siguientes:

Una ruta que antes estaba accesible pasa a estar inaccesible en una respuesta entrante

El túnel VPN queda fuera de línea o el circuito de demanda está fuera de línea debido a un número excesivo de retransmisiones no reconocidas

En el dispositivo de seguridad, también puede configurar una interfaz de túnel de punto a punto o de punto a multipunto como circuito de demanda. Debe inhabilitar route-deny (si está configurado) en un túnel de punto a multipunto de modo que todas las rutas puedan alcanzar sitios remotos. Aunque no se requiera, también puede inhabilitar el horizonte dividido en la interfaz de punto a multipunto con los circuitos de demanda. Si inhabilita el horizonte dividido, los puntos extremos podrán reconocerse mutuamente.

Debe configurar la supervisión de VPN con reencriptación en los túneles VPN para aprender el estado del túnel.

Después de configurar el circuito de demanda y los vecinos estáticos, puede ajustar el temporizador/retransmisor RIP, el temporizador de sondeo, y el temporizador de retención para ajustarse a sus requisitos de red.

Los ejemplos sobre cómo configurar un circuito de demanda y un vecino estático se muestran después de esta sección. Un ejemplo de configuración de red RIP con circuitos de demanda a través de interfaces de túnel de punto a multipunto empieza en la página 103.

En el ejemplo siguiente, configurará la interfaz_tunnel.1 para que actúe como circuito de demanda y guardará la configuración.

WebUI

Network > Interfaces > Edit > RIP: Seleccione Demand Circuit, luego haga clic en Apply.



102

CLI

set interface tunnel.1 protocol rip demand-circuitsave

Después de habilitar un circuito de demanda, puede activar su estado y sus temporizadores con el comando get vrouter enrut_virtual protocol rip database. La Tabla 12 detalla sugerencias para solucionar problemas de rendimiento provocados por ajustes del temporizador.

Tabla 12: Solución de problemas del temporizador de retransmisión del circuito de demanda

Configuración de un vecino estáticoUna interfaz de punto a multipunto que esté ejecutando RIP requiere vecinos configurados estáticamente. Para los circuitos de demanda de configuración manual, es la única forma de que un dispositivo de seguridad aprenda las direcciones vecinas en las interfaces de punto a multipunto. Para configurar un vecino estático RIP introduzca el nombre de la interfaz y la dirección IP del vecino RIP.

En el ejemplo siguiente configurará el vecino RIP con la dirección IP 10.10.10.2 de la interfaz tunnel.1.

WebUI

Network > Interfaces > (Edit) RIP: Haga clic en el botón Static Neighbor IP para avanzar a la tabla Static Neighbor IP. Introduzca la dirección IP del vecino estático y haga clic en Add.

CLI

set interface tunnel.1 protocol rip neighbor 10.10.10.2unset interface tunnel.1 protocol rip neighbor 10.10.10.2save

Configuración de una interfaz de túnel punto a multipunto

El protocolo RIP punto a multipunto se admite en las interfaces de túnel numeradas de las versiones 1 y 2 de RIP.

Rendimiento del circuito de demanda Sugerencia

Relativamente lento Puede reconfigurar el temporizador de retransmisión a un valor superior para reducir el número de retransmisiones.

Sin pérdidas Puede reconfigurar el temporizador de retransmisiones para reducir la cuenta de reintentos.

Congestionado y con pérdidas Puede reconfigurar el temporizador de retransmisiones a una cuenta de reintentos superior para dar al vecino estático más tiempo de respuesta antes de forzar al vecino estático a un estado de sondeo (POLL).



Debe inhabilitar el horizonte dividido en un túnel de interfaz de punto a multipunto que configure con circuitos de demanda de modo que los mensajes alcancen todos los sitios remotos. Para una interfaz de túnel punto a multipunto sin circuitos de demanda, puede dejar habilitada la opción de horizonte dividido (predeterminada). RIP aprende dinámicamente sobre los vecinos. El protocolo RIP envía todos los mensajes transmitidos a la dirección multicast 224.0.0.9 y los reduplica a todos los túneles según convenga.

Si desea configurar RIP como túnel punto a multipunto con circuitos de demanda, debe diseñar su red en una configuración radial “hub and spoke”.

La red de este ejemplo pertenece a una empresa de tamaño mediano con su oficina central (OC) en San Francisco y delegaciones en Chicago, Los Angeles, Montreal y Nueva York. Cada oficina tiene un solo dispositivo de seguridad. Consulte la Figura 14 en la página 104.

Los siguientes son los requisitos de configuración específicos del dispositivo de seguridad en la OC:

1. Configure el VR para que ejecute una instancia de RIP, habilitar RIP y, a continuación, configurar la interfaz tunnel.1.

2. Configure las cuatro VPN y asociarlas a la interfaz tunnel.1.

3. Configure vecinos estáticos RIP en el dispositivo de seguridad de la oficina central (OC).

4. No cambie los valores predeterminados del temporizador en este ejemplo.

Los siguientes son los requisitos de configuración propios de los dispositivos de seguridad remotos de Juniper Networks:

1. Configure el VR para que ejecute una instancia de RIP, habilite RIP y, a continuación, configure la interfaz tunnel.1.

2. Configure la VPN y asóciela a la interfaz tunnel.1.

3. No configure vecinos estáticos en los dispositivos de seguridad de la oficina remota. Los dispositivos de la oficina remota solamente tienen un dispositivo vecino que será descubierto por las peticiones multicast iniciales.

PRECAUCIÓN: RIP no se admite en interfaces de túnel sin numerar. Se debe numerar todas las interfaces que utilizan protocolo RIP. Cualquier intento de configurar y ejecutar una interfaz sin numerar utilizando RIP puede provocar un fallo impredecible en el enrutamiento.

NOTA: En este ejemplo, únicamente se hace referencia a las interfaces de línea de comandos y no describimos zonas y otros pasos de configuración necesarios.

Configuración de una interfaz de túnel punto a multipunto 103


104

Figura 14: Ejemplo de red punto a multipunto con interfaz de túnel

En el diagrama de red que se muestra en la Figura 14, se originan cuatro VPNs en el dispositivo de seguridad de San Francisco e irradian hacia las oficinas remotas en Nueva York, Los Angeles, Montreal y Chicago.

En este ejemplo, configurará los siguientes ajustes en el dispositivo de seguridad de la oficina central OC:


2. VPN

3. Rutas y RIP

4. Vecinos estáticos

5. Ruta de resumen

Para poder comprobar el estado del circuito en el dispositivo de la oficina central OC, debe habilitar la supervisión de VPN.

Para completar la configuración de la red, configurará los siguientes ajustes en cada uno de los cuatro dispositivos de seguridad de las oficinas remotas:


2. VPN

NOTA: No es necesario cambiar los valores predeterminados del temporizador en este ejemplo.

Los Angeles

Nueva York Chicago

tunnel.1 10.0.0.5 Untrust 1.1.1.5

tunnel.1 10.0.0.2 Untrust 1.1.1.2

VPN 1

VPN 2Internet

VPN 4

VPN 3

San Francisco (OC) ethernet3 1.1.1.1 tunnel.1 10.0.0.1 4 VPN asociadas a tunnel.1

tunnel.1 10.0.0.3 Untrust 1.1.1.3

tunnel.1 10.0.0.4 Untrust 1.1.1.4

Montreal



3. Rutas y RIP

4. Vecinos estáticos

5. Ruta de resumen

WebUI (dispositivo de la oficina central)

1. Zonas e interfaces de seguridadNetwork > Interfaces > Haga clic en New Tunnel IF y continúe en la página de configuración.

Network > Interfaces > Edit (para ethernet3)


3. Rutas y RIPNetwork > Routing > Virtual Routers > Haga clic en Edit para el enrutador virtual y haga clic en Create RIP Instance, luego habilite RIP en el enrutador virtual.

Network > Interfaces > Edit > Haga clic en Edit y luego haga clic en RIP, posteriormente habilite RIP en la interfaz.

4. Vecinos estáticosNetwork > Interfaces > Edit > RIP > Static Neighbor IP y luego en Add Neighbor IP Address.

5. Ruta de resumenNetwork > Routing > Virtual Router Edit (RIP) > Haga clic en Summary IP y configure la dirección IP del resumen.

CLI (dispositivo de la oficina central)

1. Zonas e interfaces de seguridadset interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24set interface tunnel.1 zone untrustset interface tunnel.1 ip 10.0.0.1/24

2. VPNset ike gateway gw1 address 1.1.1.2 main outgoing-interface ethernet3 preshare

ripdc proposal pre-g2-3des-shaset ike gateway gw2 address 1.1.1.3 main outgoing-interface ethernet3 preshare



ripdc proposal pre-g2-3des-sha




106

set vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn1 monitor rekeyset vpn vpn1 bind interface tunnel.1




3. Rutas y RIPset vrouter trust protocol ripset vrouter trust protocol rip enableset vrouter protocol rip summary-ip 100.10.0.0/16

set interface tunnel.1 protocol rip set interface tunnel.1 protocol rip enableset interface tunnel.1 protocol rip demand-circuit

4. Vecinos estáticosset interface tunnel.1 protocol rip neighbor 10.0.0.2set interface tunnel.1 protocol rip neighbor 10.0.0.3set interface tunnel.1 protocol rip neighbor 10.0.0.4set interface tunnel.1 protocol rip neighbor 10.0.0.5

5. Ruta de resumenset interface tunnel.1 protocol rip summary-enablesave

Puede seguir estos pasos para configurar el dispositivo de seguridad de la oficina remota. Al configurar la oficina remota, no necesita configurar vecinos estáticos. En un entorno de circuito de demanda, solamente existe un vecino para el dispositivo remoto y éste aprende la información del vecino cuando envía un mensaje multicast durante el arranque.

Para completar la configuración mostrada en el diagrama de la página 104, debe repetir esta sección por cada dispositivo remoto y cambiar las direcciones IP, los nombres de puerta de enlace y los nombres de VPN para cumplir las necesidades de la red. En cada sitio remoto, las zonas trust y untrust cambian.




WebUI (dispositivo de oficina remota)

1. Zonas e interfaces de seguridadNetwork > Interfaces > Haga clic en New Tunnel IF y continúe en la página de configuración.

Network > Interfaces > Edit (para ethernet3)


3. Rutas y RIPNetwork > Routing > Virtual Routers > Haga clic en Edit para el enrutador virtual y haga clic en Create RIP Instance, luego habilite RIP en el enrutador virtual.

Network > Interfaces > Edit > Haga clic en Edit y luego haga clic en RIP, posteriormente habilite RIP en la interfaz.

4. Directiva (configure como sea necesario)Directivas (de todas las zonas a todas las zonas) > Haga clic en New

CLI (dispositivo de oficina remota)

1. Protocolo de enrutamiento e interfazset vrouter trust-vr protocol ripset vrouter trust-vr protocol rip enableset interface untrust ip 1.1.1.1/24set interface tunnel.1 zone untrustset interface tunnel.1 ip 10.0.0.2/24

2. VPNset ike gateway gw1 address 1.1.1.1/24 main outgoing-interface untrust preshare

ripdc proposal pre-g2-3des-shaset vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-shaset vpn vpn1 monitor rekeyset vpn vpn1 id 1 bind interface tunnel.1

3. Rutas y RIPset interface tunnel.1 protocol ripset interface tunnel.1 protocol rip demand-circuitset interface tunnel.1 protocol rip enable

4. Directiva (configure como sea necesario)set policy id 1 from trust to untrust any any any permitset policy id 2 from untrust to trust any any any permitsave

Puede ver los nuevos cambios ejecutando el comando get vrouter enrut_virtuale protocol rip neighbors. Los vecinos de un circuito de demanda aparecen en la tabla de vecinos; la información del vecino no envejece ni expira. Puede ver la base de datos RIP ejecutando el comando get vrouter enrut_virtuale protocol rip database. Aparece una P de permanent junto a las entradas de los circuitos de demanda.



108

Capítulo 5

Protocolo de puertas de enlace de límite

En este capítulo se describe el protocolo de puertas de enlace de límite (Border Gateway Protocol, BGP) en los dispositivos de seguridad de Juniper Networks. Incluye las siguientes secciones:


“Tipos de mensajes BGP” en la página 110

“Atributos de ruta” en la página 111

“BGP externo e interno” en la página 112

“Configuración básica de BGP” en la página 112

“Creación y habilitación de una instancia de BGP” en la página 113

“Habilitación e inhabilitación de BGP en interfaces” en la página 114

“Configuración de grupos de interlocutores e interlocutores BGP” en la página 115

“Comprobación de la configuración BGP” en la página 119


“Autenticación de vecinos BGP” en la página 120


“Redistribución de rutas en BGP” en la página 123

“Configuración de una lista de acceso AS-Path” en la página 124

“Agregar rutas a BGP” en la página 125

“Capacidad de route-refresh” en la página 127

“Configuración de la reflexión de rutas” en la página 128

“Configurar una confederación” en la página 131

109


110

“Comunidades BGP” en la página 133

“Agregación de rutas” en la página 134

Vista general

El protocolo BGP es un protocolo de vectores de rutas que se utiliza para transportar información de enrutamiento entre sistemas autónomos (AS). Un AS es un conjunto de enrutadores que se encuentran en el mismo dominio administrativo.

La información de enrutamiento BGP incluye la secuencia de números de los AS que un prefijo de red (una ruta) ha atravesado. La información de ruta asociada al prefijo se utiliza para prevenir bucles y reforzar las directivas de enrutamiento. ScreenOS es compatible con la versión 4 de BGP (BGP-4) tal y como se define en la norma RFC 1771.

Dos interlocutores BGP establecen una sesión BGP para intercambiar información de enrutamiento. Un enrutador BGP puede participar en sesiones BGP con distintos interlocutores. En primer lugar, los interlocutores BGP deben establecer una conexión TCP entre sí para abrir una sesión BGP. Una vez establecida la conexión inicial, los interlocutores intercambian las tablas de enrutamiento completas. A medida que cambian las tablas de enrutamiento, los enrutadores BGP intercambian mensajes de actualización con los interlocutores. Cada enrutador BGP mantiene actualizadas las tablas de enrutamiento de todos los interlocutores con los que tiene sesiones, enviándoles periódicamente mensajes de mantenimiento de conexión para verificar las conexiones.

El interlocutor BGP sólo notifica las rutas que está utilizando en ese momento. Cuando un interlocutor BGP notifica una ruta a su vecino, incluye atributos de ruta que describen sus características. El enrutador BGP compara los atributos de ruta y el prefijo para elegir la mejor ruta de todas las disponibles para un destino determinado.

Tipos de mensajes BGPEl protocolo BGP utiliza cuatro tipos de mensajes para la comunicación con los interlocutores:

Los mensajes de Open permiten que los interlocutores BGP se identifiquen mutuamente antes de iniciar la sesión GP. Estos mensajes se envían cuando los interlocutores han establecido una sesión TCP. Durante el intercambio de mensajes de apertura, los interlocutores BGP especifican su versión de protocolo, número de AS, tiempo de espera e identificador BGP.

Los mensajes de Update notifican rutas al interlocutor y descartan las rutas notificadas previamente.

Los mensajes de Notification indican errores. La sesión BGP se termina y se cierra la sesión TCP.

Vista general

Capítulo 5: Protocolo de puertas de enlace de límite

Los mensajes de Keepalive se utilizan para el mantenimiento de la sesión BGP. De forma predeterminada, el dispositivo de seguridad envía mensajes de mantenimiento de conexión a los interlocutores cada 60 segundos. Este intervalo se puede configurar.

Atributos de rutaLos atributos de ruta BGP son un grupo de parámetros que describen las características de una ruta. El protocolo BGP empareja los atributos con la ruta que describen y, a continuación, compara todas las rutas disponibles para un destino para así seleccionar la mejor ruta de acceso a ese destino. Los atributos de ruta obligatorios y bien conocidos son:

Origin describe el origen de la ruta (puede ser IGP, EGP o estar incompleto).

AS-Path contiene una lista de sistemas autónomos a través de los cuales ha pasado la notificación de ruta.

Next-Hop es la dirección IP del enrutador al que se envía tráfico para la ruta.

Los atributos de ruta opcionales son:

Multi-Exit Discriminator (MED) es una métrica para aquellas rutas en las que hay múltiples vínculos entre sistemas autónomos (un AS configura el MED y otro AS lo utiliza para elegir una ruta).

Local-Pref es una métrica utilizada para informar a los interlocutores BGP de las preferencias del enrutador local para elegir una ruta.

Atomic-Aggregate informa a los interlocutores BGP de que el enrutador local seleccionó una ruta menos específica de un conjunto de rutas superpuestas recibidas de un interlocutor.

Aggregator especifica el AS y el enrutador que realizaron la agregación de la ruta.

Communities especifica una o varias comunidades a las que pertenece la ruta.

Cluster List contiene una lista de los clústeres de reflexión a través de los cuales ha pasado la ruta.

Un enrutador BGP puede decidir si desea agregar o modificar los atributos de ruta opcionales antes de notificársela a los interlocutores.

NOTA: El dispositivo de seguridad no enviará un mensaje de notificación a un interlocutor si, durante el intercambio de mensajes de apertura, el interlocutor indica que admite protocolos con los que el dispositivo de seguridad no es compatible.

Vista general 111


112

BGP externo e internoEl protocolo BGP externo (EBGP) se utiliza entre sistemas autónomos, p. ej., cuando distintas redes ISP se conectan entre sí o una red empresarial se conecta a una red ISP. El protocolo BGP interno (IBGP) se utiliza dentro de un sistema autónomo, p. ej., una red de una empresa. El objetivo principal de IBGP es distribuir los enrutadores reconocidos por EBGP en los enrutadores del AS. Un enrutador IBGP puede notificar a sus interlocutores IBGP rutas reconocidas por sus interlocutores EBGP, pero no puede notificar rutas reconocidas por sus interlocutores IBGP a otros interlocutores IBGP. Esta restricción impide que se formen bucles de notificación de ruta dentro de la red, pero también implica que una red IBGP debe estar absolutamente mallada (es decir, cada enrutador BGP de la red debe tener una sesión con cada uno de los otros enrutadores de la red).

Algunos atributos de ruta sólo son aplicables a EBGP o a IBGP. Por ejemplo, el atributo MED sólo se utiliza en mensajes EBGP, mientras que el atributo LOCAL-PREF sólo está presente en mensajes IBGP.

Configuración básica de BGP

En un dispositivo de seguridad, cada instancia BGP se crea individualmente por cada enrutador virtual (VR). Si dispone de varios VR en un dispositivo, podrá habilitar múltiples instancias de BGP, una por cada enrutador virtual.

Los cinco pasos básicos para configurar BGP en un VR en un dispositivo de seguridad son:

1. Crear y habilitar la instancia de enrutamiento de BGP en un enrutador virtual, asignando primero un número de sistema autónomo a la instancia de BGP y habilitando después la instancia.

2. Habilitar BGP en la interfaz conectada al interlocutor.

3. Habilitar cada interlocutor BGP.

4. Configurar uno o varios interlocutores BGP remotos.

5. Comprobar que el protocolo BGP está configurado correctamente y funciona.

Esta sección describe cómo realizar cada una de estas tareas utilizando CLI o WebUI para el siguiente ejemplo. La Figura 15 muestra el dispositivo de seguridad como un interlocutor BGP en AS 65000. Tiene que configurar el dispositivo de seguridad para que pueda establecer una sesión BGP con el interlocutor en AS 65500.

NOTA: Antes de configurar un protocolo de enrutamiento dinámico en el dispositivo de seguridad, deberá asignar una ID de enrutador virtual, tal y como se describe en el Capítulo 2, “Enrutamiento.”



Figura 15: Ejemplo de configuración BGP

Creación y habilitación de una instancia de BGPCada instancia de enrutamiento de BGP se crea y se habilita en un enrutador virtual (VR) específico ubicado en un dispositivo de seguridad. Para crear una instancia de enrutamiento BGP, primero se debe especificar el número de sistema autónomo en el se que se encuentra el VR. Si el enrutador virtual es un enrutador IBGP, el número de sistema autónomo será el mismo que el de otros enrutadores IBGP de la red. Cuando se habilita la instancia de enrutamiento BGP en un VR, la instancia de enrutamiento BGP será capaz de establecer contacto e iniciar una sesión con los interlocutores BGP que configure.

Creación de una instancia BGPEn el siguiente ejemplo, en primer lugar asignará 0.0.0.10 como ID de enrutador a trust-vr. A continuación creará y habilitará una instancia de enrutamiento BGP en el trust-vr, que se encuentra en el dispositivo de seguridad en AS 65000. (Para obtener más información sobre enrutadores virtuales y cómo configurar un enrutador virtual en dispositivos de seguridad, consulte “Enrutamiento” en la página 13).

Número del sistema autónomo Sistemas autónomos

Número del sistema autónomo

Enrutador remotoDispositivo de seguridad local

ID del enrutador 1.1.1.250

Dirección IP de interfaz 1.1.1.1/24 BGP habilitado

Dirección IP de interfaz 2.2.2.2/24 BGP habilitado

ID de enrutador 2.2.2.250

AS 65500

Interlocutores BGP

AS 65000

NOTA: Los números de sistemas autónomos (AS) son números únicos a nivel global que se utilizan para intercambiar información de enrutamiento EBGP y para identificar el sistema autónomo. Las siguientes entidades asignan números de AS: American Registry for Internet Numbers (ARIN), Réseaux IP Européens (RIPE) y Asia Pacific Network Information Center (APNIC). Los números 64512 a 65535 son de uso privado y no para su notificación global en Internet.

Configuración básica de BGP 113


114

WebUI

1. ID de enrutadorNetwork > Routing > Virtual Router (trust-vr) > Edit: Introduzca los siguientes datos y haga clic en OK:

Virtual Router ID: Custom (seleccione)In the text box, enter 0.0.0.10

2. Instancia de enrutamiento de BGPNetwork > Routing > Virtual Routers > Edit (para trust-vr) > Create BGP Instance: Introduzca los siguientes datos y haga clic en OK:

AS Number (obligatorio): 65000BGP Enabled: (seleccione)

CLI


2. Instancia de enrutamiento de BGPset vrouter trust-vr protocol bgp 65000set vrouter trust-vr protocol bgp enablesave

Eliminación de una instancia de BGPEn este ejemplo inhabilitará y eliminará la instancia de enrutamiento de BGP en el enrutador trust-vr. BGP detendrá todas las sesiones con los interlocutores.

WebUI

Network > Routing > Virtual Routers (trust-vr) > Edit > Edit BGP Instance: Anule la selección de BGP Enabled y haga clic en OK.

Network > Routing > Virtual Routers (trust-vr) > Edit: Seleccione Delete BGP Instance, luego haga clic en OK cuando aparezca el mensaje de confirmación.

CLI

unset vrouter trust-vr protocol bgp enableunset vrouter trust-vr protocol bgp 65000save

Habilitación e inhabilitación de BGP en interfacesEs necesario habilitar BGP en la interfaz donde resida el interlocutor. (De forma predeterminada, las interfaces del dispositivo de seguridad no están asociadas a ningún protocolo de enrutamiento).

Habilitación de BGP en interfacesEn este ejemplo habilitará BGP en la interfaz ethernet4.

WebUI

Network > Interfaces > Edit> BGP: Marque la opción Protocol BGP enable, y luego haga clic en OK.



CLI

set interface ethernet4 protocol bgpsave

Inhabilitación de BGP en interfacesEn este ejemplo inhabilitará BGP en la interfaz ethernet4. En las demás interfaces en las que haya habilitado BGP podrán continuar transmitiendo y procesando paquetes BGP.

WebUI

Network > Interfaces > Configure (para ethernet4): Elimine la marca de la opción Protocol BGP enable, y luego haga clic en OK.

CLI

unset interface ethernet4 protocol bgpsave

Configuración de grupos de interlocutores e interlocutores BGPAntes de que dos dispositivos BGP puedan comunicarse e intercambiar rutas, necesitan identificarse mutuamente para poder iniciar una sesión BGP. Es necesario especificar las direcciones IP de los interlocutores BGP y, opcionalmente, configurar parámetros para establecer y mantener la sesión. Los interlocutores pueden ser interlocutores internos (IBGP) o externos (EBGP). Si se trata de un interlocutor EBGP, habrá que especificar el sistema autónomo en el que reside el interlocutor.

Todas las sesiones BGP se autentican comprobando el identificador de interlocutor BGP y el número de AS notificado por los interlocutores. Las conexiones correctas con un interlocutor se registran. Si surge algún problema durante la conexión con el interlocutor, el interlocutor enviará o recibirá un mensaje de notificación BGP, lo que hará que la conexión falle o se cierre.

Es posible configurar parámetros para direcciones de interlocutores individuales. También se pueden asignar interlocutores a un grupo de interlocutores, lo que permitirá configurar parámetros para el grupo en su conjunto.

La Tabla 13 describe parámetros que se pueden configurar para interlocutores BGP y sus valores predeterminados. Una “X” en la columna Interlocutor indica un parámetro que se puede configurar para la dirección IP de un interlocutor, mientras que una “X” en la columna Grupo de interlocutores indica un parámetro que se puede configurar para un grupo de interlocutores.

NOTA: No es posible asignar interlocutores IBGP y EBGP al mismo grupo de interlocutores.



116

Tabla 13: Parámetros de interlocutores BGP y grupos de interlocutores y valores predeterminados

Parámetro BGP InterlocutorGrupo de interlocutores Descripción Valor predeterminado

Advertise default route

X Notifica la ruta predeterminada en el enrutador virtual a interlocutores BGP.

La ruta predeterminada no se notifica

EBGP multihop X X Número de nodos entre el BGP local y el vecino.

0 (desactivado)

Force connect X X Hace que la instancia de BGP descarte una conexión BGP existente con el interlocutor especificado y acepte una nueva conexión. Este parámetro resulta de utilidad cuando hay una conexión con un enrutador que queda fuera de línea y luego vuelve a ponerse en línea e intenta restablecer una conexión BGP, ya que permite un restablecimiento más rápido de la conexión entre interlocutores1.

N/A

Hold time X X Tiempo transcurrido sin que lleguen mensajes de un interlocutor antes de que se considere fuera de línea.

180 segundos

Keepalive X X Tiempo entre transmisiones de mantenimiento de conexión (keepalive).

1/3 del tiempo de retención (hold-time)

MD5 authentication

X X Configura la autenticación MD-5. Sólo se comprueba el identificador de interlocutor y el número de AS

MED X Configura el valor de atributo MED. 0

Next-hop self X X En las rutas enviadas al interlocutor, el atributo de ruta al salto siguiente se ajusta en la dirección IP de la interfaz del enrutador virtual local.

Atributo de salto siguiente no cambiado

Reflector client X X El interlocutor es un cliente de reflexión cuando el protocolo BGP local se configura como el reflector de rutas.

Ninguno

Reject default route

X No tiene en cuenta las notificaciones de ruta predeterminada procedentes de los interlocutores BGP.

Las rutas predeterminadas de los interlocutores se agregan a la tabla de enrutamiento

Retry time X X Tras un intento fallido de inicio de sesión, tiempo que se tarda en reintentar iniciar la sesión BGP.

120 segundos

Send community

X X Transmite el atributo de comunidad al interlocutor.

Atributo de comunidad no enviado a los interlocutores

Weight X X Prioridad de ruta entre el BGP local y el interlocutor.

100

1.Puede utilizar el comando exec neighbor disconnect para hacer que la instancia de BGP descarte una conexión BGP con el interlocutor especificado y acepte una nueva conexión. El uso de este comando de ejecución no modifica la configuración del interlocutor BGP. Por ejemplo, puede utilizarlo si desea cambiar la configuración del mapa de rutas que se aplica a este interlocutor.



Es posible configurar algunos parámetros en el nivel de interlocutores y en el de protocolo (consulte “Configurar una confederación” en la página 131). Por ejemplo, puede configurar el valor de tiempo de espera para un interlocutor específico con un valor de 210 segundos, mientras que el valor de tiempo de espera predeterminado en el nivel de protocolo es de 180 segundos; en tal caso, la configuración del interlocutor tendrá preferencia. Los valores MED ajustados en el nivel de protocolo y en el nivel de interlocutor pueden ser distintos; el valor MED ajustado en el nivel de interlocutor sólo se aplicará a las rutas que se notifiquen a esos interlocutores.

Configuración de un interlocutor BGPEn el siguiente ejemplo configuraremos y habilitaremos un interlocutor BGP. Este interlocutor tiene los siguientes atributos:

Dirección IP 1.1.1.250

Reside en AS 65500

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Neighbors: Introduzca los siguientes datos y haga clic en Add:

AS Number: 65500Remote IP: 1.1.1.250

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Neighbors > Configure (para el interlocutor que acabe de agregar): Seleccione Peer Enabled y luego haga clic en OK.

CLI

set vrouter trust-vr protocol bgp neighbor 1.1.1.250 remote-as 65500set vrouter trust-vr protocol bgp neighbor 1.1.1.250 enablesave

Configuración de un grupo de interlocutores IBGPAhora configurará un grupo de interlocutores IBGP llamado ibgp que contendrá las siguientes direcciones IP: 10.1.2.250 y 10.1.3.250. Una vez haya definido un grupo de interlocutores, podrá configurar parámetros (como la autenticación MD5) que se aplicarán a todos los miembros del grupo de interlocutores.

NOTA: Deberá habilitar cada conexión de interlocutor que configure.

NOTA: Deberá habilitar cada conexión de interlocutor que configure. Si configura interlocutores como parte de un grupo, tendrá que habilitar las conexiones de los interlocutores una a una.



118

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Peer Group: Escriba ibgp en el campo Group Name, luego haga clic en Add.

> Configure (para ibgp): En el campo Peer authentication, introduzca verify03 y haga clic en OK.


AS Number: 65000Remote IP: 10.1.2.250Peer Group: ibgp (seleccione)

Introduzca los siguientes datos y haga clic en Add:

AS Number: 65000Remote IP: 10.1.3.250Peer Group: ibgp (seleccione)

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Neighbors > Configure (para 10.1.2.250): Seleccione Peer Enabled y luego haga clic en OK.

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Neighbors > Configure (para 10.1.3.250): Seleccione Peer Enabled y luego haga clic en OK.

CLI

set vrouter trust-vr protocol bgp neighbor peer-group ibgpset vrouter trust-vr protocol bgp neighbor peer-group ibgp remote-as 65000set vrouter trust-vr protocol bgp neighbor peer-group ibgp md5-authentication

verify03set vrouter trust-vr protocol bgp neighbor 10.1.2.250 remote-as 65000set vrouter trust-vr protocol bgp neighbor 10.1.2.250 peer-group ibgpset vrouter trust-vr protocol bgp neighbor 10.1.3.250 remote-as 65000set vrouter trust-vr protocol bgp neighbor 10.1.3.250 peer-group ibgpset vrouter trust-vr protocol bgp neighbor 10.1.2.250 enableset vrouter trust-vr protocol bgp neighbor 10.1.3.250 enablesave



Comprobación de la configuración BGPPuede revisar la configuración introducida a través de WebUI o CLI ejecutando el comando get vrouter enrut_virtual protocol bgp config.

device-> get vrouter trust-vr protocol bgp configset protocol bgp 65000set enableset neighbor peer-group "ibgp"set neighbor peer-group "ibgp" md5-authentication "cq1tu6gVNU5gvfsO60CsvxVPNnntOPwY/g=="set neighbor 10.1.2.250 remote-as 65000

output continues...

exit

Para comprobar si BGP se está ejecutando en el enrutador virtual, ejecute el comando get vrouter enrut_virtual protocol bgp .

device-> get vrouter trust-vr protocol bgpAdmin State: habilitarLocal Router ID: 10.1.1.250Local AS number: 65000Hold time: 180Keepalive interval: 60 = 1/3 hold time, defaultLocal MED is: 0Always compare MED: disableLocal preference: 100Route Flap Damping: disableIGP synchronization: disableRoute reflector: disableCluster ID: not set (ID = 0)Confederation based on RFC 1965Confederation (confederación): disable (confederation ID = 0)Member AS: noneOrigin default route: disableIgnore default route: disable

Puede visualizar el estado administrativo del enrutador virtual (VR) y de la identificación del enrutador, así como todos los demás parámetros configurados relativos al BGP.

Para comprobar si un interlocutor o grupo de interlocutores BGP está habilitado y Ver el estado de la sesión BGP, ejecute el comando get vrouter enrut_virtual protocol bgp neighbor.device-> get vrouter trust-vr protocol bgp neighborPeer AS Remote IP Local IP Wt Status State ConnID 65500 1.1.1.250 0.0.0.0 100 Enabled ACTIVE upTotal 1 BGP peers shown

En este ejemplo puede verificar si el interlocutor BGP está habilitado y si la sesión está activa.

NOTA: Es recomendable asignar una ID de enrutador de forma explícita, en lugar de utilizar la ID predeterminada. Para más información sobre cómo configurar una ID de enrutador, consulte “Enrutamiento” en la página 13.



120

El estado puede ser uno de los que aquí se indican:

Idle: primer estado de la conexión.

Connect: BGP está esperando una conexión de transporte TCP correcta.

Active: BGP está iniciando una conexión de transporte.

OpenSent: BGP está esperando un mensaje de apertura (OPEN) del interlocutor.

OpenConfirm: BGP está esperando un mensaje de mantenimiento de conexión (KEEPALIVE) o notificación (NOTIFICATION) del interlocutor.

Established: BGP está intercambiado paquetes de actualización (UPDATE) con el interlocutor.


En esta sección se describen posibles problemas de seguridad en el dominio de enrutamiento BGP y ciertos métodos de prevención de ataques.

Autenticación de vecinos BGPUn enrutador BGP se puede suplantar fácilmente, ya que los paquetes BGP no se encriptan, y la mayoría de los analizadores de protocolo permiten desencapsular paquetes BGP. La mejor forma de acabar con el riesgo de este tipo de ataques será autenticando los interlocutores BGP.

BGP ofrece autenticación MD5 para validar los paquetes BGP recibidos de un interlocutor. Para la autenticación MD5 es necesario utilizar la misma clave para los enrutadores BGP de envío y de recepción. Todos los paquetes BGP recibidos de un determinado interlocutor que no se autentiquen se descartarán. De forma predeterminada, para un determinado interlocutor BGP sólo se comprobarán el identificador de interlocutor y el número de AS.

En el siguiente ejemplo configuraremos un interlocutor BGP con la dirección IP remota 1.1.1.250 en AS 65500. A continuación configuraremos el interlocutor para la autenticación MD5 utilizando la clave 1234567890123456.

NOTA: Un estado de sesión que cambia continuamente entre Active y Connect podría indicar un problema con la conexión entre interlocutores.

NOTA: Para que BGP sea más seguro, todos los enrutadores de un dominio BGP deben configurarse con el mismo nivel de seguridad. De lo contrario, un solo enrutador BGP comprometido podría llegar a dejar fuera de línea todo el domino de enrutamiento BGP.



WebUI



> Configure (para IP remota 1.1.1.250): Introduzca los siguientes datos y haga clic en OK:

Peer Authentication: Enable (seleccione)MD5 password: 1234567890123456Peer Enabled: (seleccione)

CLI

set vrouter trust-vr(trust-vr)-> set protocol bgp(trust-vr/bgp)-> set neighbor 1.1.1.250 remote-as 65500(trust-vr/bgp)-> set neighbor 1.1.1.250 md5-authentication 1234567890123456(trust-vr/bgp)-> set neighbor 1.1.1.250 enable(trust-vr/bgp)-> exit(trust-vr)-> exitsave

Rechazo de rutas predeterminadasEn los ataques con desvío de rutas, un enrutador inyecta una ruta predeterminada (0.0.0.0/0) en el dominio de enrutamiento para que los paquetes se desvíen a él. El enrutador puede descartar los paquetes, causando una interrupción en el servicio, o puede eliminar información crítica de los paquetes antes de reenviarlos. En los dispositivos de seguridad, BGP acepta en principio cualquier ruta predeterminada enviada por interlocutores BGP y agrega la ruta predeterminada a la tabla de rutas.

En este ejemplo, configurará la instancia de enrutamiento BGP que se está ejecutando en el trust-vr para que no tenga en cuenta las rutas predeterminadas enviadas por interlocutores BGP.

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance: Introduzca los siguientes datos y haga clic en OK:

Ignore default route from peer: (seleccione)

CLI

set vrouter trust-vr protocol bgp reject-default-routesave



122

Configuraciones opcionales de BGP

En esta sección se describen los parámetros que se pueden configurar para el protocolo de enrutamiento BGP en el enrutador virtual. Es posible configurarlos con los comandos contextuales BGP de la interfaz de línea de comandos o con la WebUI. Esta sección explica parte de las configuraciones de parámetros más complejas. La Tabla 14 describe los parámetros de BGP y sus valores predeterminados.

Tabla 14: Parámetros opcionales de BGP y sus valores predeterminados

Parámetro del protocolo BGP Descripción Valor predeterminado

Advertise default route Notifica la ruta predeterminada en el enrutador virtual a interlocutores BGP.

La ruta predeterminada no se notifica

Aggregate Crea rutas agregadas. Consulte “Agregación de rutas” en la página 134.

Desactivado

Always compare MED Compara los valores MED de las rutas. Desactivado

AS path access list Crea una lista de acceso a rutas AS para permitir o denegar rutas.

—

Community list Crea listas de comunidades. Consulte “Comunidades BGP” en la página 133.

—

AS confederation Crea confederaciones. Consulte “Configurar una confederación” en la página 131.

—

Equal cost multipath (ECMP)

Se pueden agregar rutas múltiples de igual coste para proporcionar equilibrio de cargas. Consulte “Configuración del enrutamiento multidireccional de igual coste” en la página 36.

Desactivado (predeterminado = 1)

Flap damping Bloquea las notificaciones de una ruta hasta que es estable.

Desactivado

Hold time Tiempo transcurrido sin que lleguen mensajes de un interlocutor antes de que se considere fuera de línea.

180 segundos

Keepalive Tiempo entre transmisiones de mantenimiento de conexión (keepalive).

1/3 del tiempo de espera (hold-time)

Local preference Configura la métrica de LOCAL_PREF. 100

MED Configura el valor de atributo MED. 0

Network Agrega entradas estáticas de red y de subred en BGP. BGP anuncia estas rutas estáticas a todos los interlocutores BGP. Consulte “Agregar rutas a BGP” en la página 125.

—

Route redistribution Importa rutas a BGP desde otros protocolos de enrutamiento.

—

Reflector Configura la instancia BGP local como reflector de rutas para clientes. Consulte “Configuración de la reflexión de rutas” en la página 128.

Desactivado



Redistribución de rutas en BGPLa redistribución de rutas es el intercambio de información sobre rutas entre protocolos de enrutamiento. Por ejemplo, se pueden redistribuir los siguientes tipos de rutas en la instancia de enrutamiento de RIP de un mismo enrutador virtual:

Rutas reconocidas por OSPF o RIP


Rutas importadas


Cuando se configura la redistribución de rutas, primero se debe especificar un mapa de rutas para filtrar las rutas que se vayan a redistribuir. Para obtener más información sobre la creación de mapas de rutas para la redistribución, consulte el Capítulo 2, “Enrutamiento.”

En el siguiente ejemplo redistribuirá en el dominio de enrutamiento BGP actual una ruta originada en un dominio de enrutamiento OSPF. Tanto en el ejemplo de la WebUI como en el de la CLI, partiremos de la base de que ya ha creado un mapa de rutas llamado add-ospf.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Redist. Rules: Introduzca los siguientes datos y haga clic en Add:

Route Map: add-ospfProtocol: OSPF

CLI

set vrouter trust-vr protocol bgp redistribute route-map add-ospf protocol ospfsave

Reject default route No tiene en cuenta las notificaciones de ruta predeterminada procedentes de los interlocutores BGP.

Las rutas predeterminadas de los interlocutores se agregan a la tabla de enrutamiento

Retry time Tiempo que debe transcurrir desde un establecimiento de sesión BGP fallido con un interlocutor para que se vuelva a intentar establecer la sesión.

12 segundos

Synchronization Permite la sincronización con un protocolo de puerta de enlace interior, como OSPF o RIP.

Desactivado

Parámetro del protocolo BGP Descripción Valor predeterminado

Configuraciones opcionales de BGP 123


124

Configuración de una lista de acceso AS-PathEl atributo AS-path contiene una lista de sistemas autónomos (AS) que atraviesa una ruta determinada. BGP añade el número de AS local al atributo AS-path cuando una ruta pasa por el AS. Para filtrar rutas de acuerdo con la información de AS-path es posible utilizar una lista de acceso AS-path. Esta lista está formada por un conjunto de expresiones regulares que definen la información de ruta del sistema autónomo e indican si las rutas que coinciden con esa información se deben permitir o denegar. Por ejemplo, podemos utilizar una lista de acceso AS-path para filtrar rutas que han pasado por un AS determinado o rutas que proceden de un AS.

Las expresiones regulares son un método para definir la búsqueda de un patrón específico en el atributo AS-path. Es posible utilizar símbolos y caracteres especiales para construir una expresión regular. Por ejemplo, para buscar rutas que hayan pasado por AS 65000, puede utilizar la expresión regular _65000_ (los guiones equivalen a un número cualquiera de caracteres delante o detrás de 65000). También puede utilizar la expresión regular “65000$” para buscar rutas originadas en AS 65000 (el signo de dólar indica el final del atributo AS-path, que podría ser el AS donde se originó la ruta).

En el siguiente ejemplo configuraremos una lista de acceso AS-path para el trust-vr que permitirá las rutas que hayan pasado por AS 65000, pero no las que hayan sido originadas en AS 65000.

WebUI

Network > Routing > Virtual Routers > Edit (para el trust-vr) > Edit BGP Instance > AS Path: Introduzca los siguientes datos y haga clic en Add:

AS Path Access List ID: 2Deny: (seleccione)AS Path String: 65000$

Network > Routing > Virtual Routers > Edit (para el trust-vr) > Edit BGP Instance > AS Path: Introduzca los siguientes datos y haga clic en Add:

AS Path Access List ID: 2Permit: (seleccione)AS Path String: _65000_

CLI

set vrouter trust-vr protocol bgp as-path-access-list 2 deny 65000$set vrouter trust-vr protocol bgp as-path-access-list 2 permit _65000_save



Agregar rutas a BGPPara permitir que el BGP anuncie las rutas de red, es necesario redistribuir las rutas desde el protocolo de origen al protocolo de notificación (BGP) en el mismo enrutador virtual (VR). También puede agregar rutas estáticas directamente en BGP. Si el prefijo de red es accesible desde el VR, el BGP anuncia esta ruta a los interlocutores sin exigir que la ruta esté redistribuida en BGP. Al agregar un prefijo de red en BGP, puede especificar varias opciones:

Seleccionando “Yes” en la opción de comprobación de accesibilidad, puede especificar si desde el VR debe ser accesible un prefijo de red diferente antes de que BGP anuncie la ruta a los interlocutores. Por ejemplo, si el prefijo que desea que el BGP anuncie se debe alcanzar a través de una interfaz de enrutador específica, asegúrese de que la interfaz del enrutador sea accesible antes de que el BGP anuncie la red a los interlocutores. Si la interfaz del enrutador que especifique es accesible, BGP anuncia la ruta a sus interlocutores. Si la interfaz del enrutador que especifique no es accesible, la ruta no se agregará al BGP y, consecuentemente, no se anunciará a los interlocutores del BGP. Si la interfaz del enrutador que especifique deja de ser accesible, el BGP retira la ruta a sus interlocutores.

Seleccionando “No” en la opción de comprobación de accesibilidad, puede especificar que el prefijo de red sea anunciado tanto si es accesible desde el VR como si no. De forma predeterminada, el prefijo de red debe ser accesible desde el VR antes de que el BGP anuncie la ruta a los interlocutores. Si habilita la comprobación de accesibilidad, la ruta se puede conectar.

Puede asignar un peso al prefijo de la red. El peso es un atributo que se puede asignar localmente a una ruta; no se anuncia a los interlocutores. Si existe más de una ruta hacia un destino, tiene prioridad la ruta con el valor de peso más alto.

Puede establecer los atributos de la ruta tomándolos de un mapa de rutas (consulte “Configuración de un mapa de rutas” en la página 39). El BGP anuncia la ruta con los atributos de ruta especificados en el mapa de rutas.

Notificación de ruta condicionalEn el ejemplo siguiente, agregará una ruta estática a la red 4.4.4.0/24. Especificará que la interfaz del enrutador 5.5.5.0/24 debe ser accesible desde el enrutador virtual para que el BGP pueda anunciar la ruta 4.4.4.0/24 a los interlocutores. Si no es posible acceder a la red 5.5.5.0.24, BGP no notificará la red 4.4.4.0/24. Consulte la Figura 16.



126

Figura 16: Ejemplo de notificación de ruta BGP condicional

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Networks: Introduzca los siguientes datos y haga clic en Add:

IP/Netmask: 4.4.4.0/24Check Reachability:

Yes: (seleccione), 5.5.5.0/24

CLI

set vrouter trust-vr protocol bgp network 4.4.4.0/24 check 5.5.5.0/24save

Establecimiento del peso de la rutaEn el ejemplo siguiente establecerá un valor de 100 para el peso de la ruta 4.4.4.0/24. (Puede especificar un valor de peso entre 0 y 65535).

WebUI


IP/Netmask: 4.4.4.0/24Weight: 100

CLI

set vrouter trust-vr protocol bgp network 4.4.4.0/24 weight 100save

Establecimiento datributos de rutaEn el ejemplo siguiente configurará un setattr del mapa de ruta que establecerá la métrica de la ruta en 100. A continuación, configurará una ruta estática en BGP que utilice el setattr del mapa de rutas. (No es necesario establecer el mapa de rutas de forma que coincida con el prefijo de red de la entrada de la ruta).

4.4.4.0/24

5.5.5.0/24

Internet

La ruta a 4.4.4.0/24 sólo se anuncia si 5.5.5.0/24 se vuelve inaccesible.



WebUI

Network > Routing > Virtual Routers > Route Map (para trust-vr) > New: Introduzca los siguientes datos y haga clic en OK:

Map Name: setattrSequence No.: 1Action: Permit (seleccione)Set Properties:

Metric: (seleccione), 100


IP/Netmask: 4.4.4.0/24Route Map: setattr (seleccione)

CLI

set vrouter trust-vr route-map name setattr permit 1set vrouter trust-vr route-map setattr 1 metric 100set vrouter trust-vr protocol bgp network 4.4.4.0/24 route-map setattrsave

Capacidad de route-refreshLa característica de route-refresh de BGP definida en RFC 2918 ofrece un mecanismo de restablecimiento suave que permite el intercambio dinámico de información sobre enrutamiento y solicitudes de actualización de rutas entre los interlocutores de BGP y la nueva notificación de la tabla de enrutamiento entrante y saliente.

Las directivas de enrutamiento para un interlocutor BGP que utiliza mapas de rutas podrían afectar las actualizaciones de la tabla de enrutamiento entrante o saliente ya que cuando se modifica una directiva de enrutamiento, la nueva directiva entra en vigencia únicamente después de que se restablece la sesión BGP. Una sesión BPG se puede borrar mediante un restablecimiento suave o abrupto.

Un restablecimiento suave permite que se aplique una directiva nueva o modificada sin borrar una sesión BGP activa. La característica de route-refresh permite que se realice un restablecimiento suave por vecino y no requiere configuración previa o memoria adicional.

Los restablecimientos suaves entrantes y dinámicos se utilizan para generar actualizaciones entrantes de un vecino. Un restablecimiento suave saliente se utiliza para enviar un nuevo conjunto de actualizaciones a un vecino. Los restablecimientos salientes no requieren configuración previa o almacenamiento de las actualizaciones de la tabla de enrutamiento.

NOTA: Un restablecimiento abrupto es perjudicial porque las sesiones BGP activas se interrumpen y se vuelven a recuperar.



128

La característica de enrutamiento y actualización requiere que ambos interlocutores BGP notifiquen que admiten la función route-refresh en el mensaje de apertura (OPEN). Si el método de route-refresh se negocia satisfactoriamente, cualquier interlocutor BGP puede utilizar la característica de route-refresh para solicitar información completa sobre el enrutamiento desde el otro extremo.

Solicitud de una actualización de la tabla de enrutamiento entranteEn este ejemplo, usted solicita que se envíe la tabla de enrutamiento entrante del intelocutor vecino en 10.10.10.10 al trust-vr del interlocutor BGP local utilizando el comando soft-in.

WebUI

Esta característica no está disponible en WebUI.

CLI

clear vrouter trust-vr protocol bgp neighbor 10.10.10.10 soft-in

Solicitud de una actualización de la tabla de enrutamiento salienteEn este ejemplo, usted envía la tabla de enrutamiento completa para trust-vr a través de las actualizaciones del interlocutor BGP local al interlocutor vecino en 10.10.10.10 utilizando el comando soft-out.

WebUI

Esta característica no está disponible en WebUI.

CLI

clear vrouter trust-vr protocol bgp neighbor 10.10.10.10 soft-out

Configuración de la reflexión de rutasComo un enrutador IBGP no puede notificar rutas reconocidas por un interlocutor IBGP a otro interlocutor IBGP (consulte “BGP externo e interno” en la página 112), es necesaria una malla completa de sesiones IBGP, donde cada enrutador en un AS BGP será interlocutor de todos los demás enrutadores del AS.

NOTA: Utilice el comando get neighbor dir_ip, un administrador puede verificar si se negoció la capacidad de route-refresh. El comando también muestra contadores, como el número de veces en que se envió o recibió la solicitud de route-refresh.

NOTA: Si la característica de route-refresh no está disponible, el comando lanza una excepción cuando el administrador intenta utilizarla.

NOTA: Una malla completa no implica que cada par de enrutadores esté conectado directamente, sino que cada enrutador tiene que ser capaz de establecer y mantener una sesión IBGP con cada uno de los demás enrutadores.



Una configuración de malla completa en las sesiones IBGP puede presentar problemas de ampliación. Por ejemplo, en un AS con 8 enrutadores, cada uno de los 8 enrutadores necesitaría intercomunicarse con los otros 7 enrutadores, lo que puede calcularse con esta fórmula:

Para un AS con 8 enrutadores, el número de sesiones IBGP de malla completa sería de 28.

La reflexión de rutas es un método para solucionar el problema de escalabilidad IBGP (descrito en RFC 1966). Un reflector de ruta es un enrutador que entrega rutas reconocidas por IBGP a los vecinos IBGP especificados (clientes), eliminando así la necesidad de sesiones de malla completa. El reflector de rutas y sus clientes forman un clúster, que se puede identificar por medio de una ID de clúster. Los enrutadores situados fuera de ese clúster lo consideran una única entidad, en lugar de intercomunicarse de forma independiente con cada enrutador en malla completa. De esta forma se reduce la carga de procesamiento. Los clientes intercambian rutas con el reflector, mientras que éste refleja rutas entre clientes.

El enrutador virtual (VR) local del dispositivo de seguridad puede actuar como reflector de rutas y se le puede asignar una identificación de clúster. Si especifica una identificación de clúster, la instancia de enrutamiento de BGP añade la identificación del clúster al atributo Cluster-List de una ruta. La ID de clúster contribuye a evitar la formación de bucles, puesto que la instancia de enrutamiento de BGP local descarta una ruta cuando su ID de clúster aparece en la lista de clústeres de la ruta.

Después de configurar un reflector de rutas en el enrutador virtual local, se definen los clientes del reflector. Es posible especificar direcciones IP individuales o un grupo de interlocutores para los clientes. No es necesario llevar a cabo ninguna configuración en los clientes.

En el siguiente ejemplo, el enrutador EBGP notifica el prefijo 5.5.5.0/24 al cliente 3. Sin reflexión de rutas, el cliente 3 notificará la ruta al dispositivo-A, pero el dispositivo-A no notificará esa ruta nuevamente a los clientes 1 y 2. Si configura el dispositivo-A como reflector de rutas y cliente 1, cliente 2 y cliente 3 como sus clientes, el dispositivo-A notificará las rutas recibidas del cliente 3 a los clientes 1 y 2. Consulte la Figura 17.

NOTA: Antes de poder configurar una ID de clúster, es necesario inhabilitar la instancia de enrutamiento de BGP.



130

Figura 17: Ejemplo de reflexión de rutas BGP

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance: Introduzca los siguientes datos, luego haga clic en Apply:

Route reflector: EnableCluster ID: 99

> Neighbors: Introduzca los siguientes datos y haga clic en Add:






> Configure (para IP remota 1.1.2.250): Seleccione Reflector Client, luego haga clic OK.

> Configure (para Remote IP 1.1.3.250): Seleccione Reflector Client, luego haga clic OK.

> Configure (para Remote IP 1.1.4.250): Seleccione Reflector Client, luego haga clic OK.

Sistemas autónomos


Cliente 1 ID de enrutador 1.1.3.250

AS 65000

ID de enrutador 2.2.2.250

Dispositivo A ID de enrutador del reflector de rutas 1.1.1.250

Cliente 3 ID del enrutador 1.1.1.250

Cliente 2ID del enrutador 1.1.4.250

Interlocutor EBGP que notifica la ruta a 5.5.5.0/24

AS 65500




CLI

set vrouter trust-vr protocol bgp reflectorset vrouter trust-vr protocol bgp reflector cluster-id 99set vrouter trust-vr protocol bgp neighbor 1.1.2.250 remote-as 65000set vrouter trust-vr protocol bgp neighbor 1.1.2.250 reflector-clientset vrouter trust-vr protocol bgp neighbor 1.1.3.250 remote-as 65000set vrouter trust-vr protocol bgp neighbor 1.1.3.250 reflector-clientset vrouter trust-vr protocol bgp neighbor 1.1.4.250 remote-as 65000set vrouter trust-vr protocol bgp neighbor 1.1.4.250 reflector-clientsave

Configurar una confederaciónAl igual que la reflexión de rutas (consulte “Configuración de la reflexión de rutas” en la página 128), las confederaciones ofrecen otra forma de resolver el problema de ampliación de las mallas completas en entornos IBGP y se describen en la norma RFC 1965. Una confederación divide un sistema autónomo en varios AS más pequeños, con cada subsistema autónomo funcionando como una red IBGP de malla completa. Cualquier enrutador situado fuera de la confederación verá la confederación completa como un único sistema autónomo con un solo identificador; las redes de los subsistemas no son visibles fuera de la confederación. Las sesiones entre enrutadores en dos subsistemas distintos de la misma confederación, conocidas como sesiones EIBGP, no son más que sesiones EBGP entre sistemas autónomos, pero en las que los enrutadores también intercambian información de enrutamiento como si fueran interlocutores IBGP. La Figura 18 ilustra las confederaciones BGP.

Figura 18: Confederaciones BGP

Hay que especificar los siguientes datos por cada enrutador de una confederación:

El número de subsistema autónomo (número de AS especificado cuando se crea la instancia de enrutamiento BGP).

La confederación a la que pertenece el subsistema autónomo (número de AS visible para los enrutadores BGP fuera de la confederación).

Los números de los otros subsistemas de la confederación.

Si la confederación admite las normas RFC 1965 (predeterminado) o RFC 3065.

Sistemas autónomos

AS 65000 (confederación)

Subsistema AS 65001

IBGP

EBGP

Subsistemas autónomos

AS 65500 Subsistema AS 65003Subsistema AS 65002

EBGPEBGP

IBGPIBGP



132

Figura 19muestra el dispositivo de seguridad como un enrutador BGP en el subsistema autónomo 65003 que pertenece a la confederación 65000. Los otros subsistemas de la confederación 65000 son 65002 y 65003.

Figura 19: Ejemplo de configuración de confederación BGP

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Create BGP Instance: Introduzca los siguientes datos, luego haga clic en Apply:

AS Number (obligatorio): 65003> Confederation: Introduzca los siguientes datos y haga clic en Apply:

Enable: (seleccione)ID: 65000Supported RFC: RFC 1965 (seleccione)


Peer member area ID: 65001


Peer member area ID: 65002

> Parámetros: Seleccione BGP Enable

CLI

set vrouter trust-vr protocol bgp 65003set vrouter trust-vr protocol bgp confederation id 65000set vrouter trust-vr protocol bgp confederation peer 65001set vrouter trust-vr protocol bgp confederation peer 65002set vrouter trust-vr protocol bgp enablesave

NOTA: El atributo AS-Path (consulte “Atributos de ruta” en la página 111) se compone normalmente de una secuencia. Los ASs atravesados por la actualización de enrutamiento. La norma RFC 3065 permite que el atributo AS-Path incluya todos los AS que forman parte de la confederación local atravesados por la actualización de enrutamiento.

Subsistema AS 65001

AS 65000 (confederación)

Subsistema AS 65002 Subsistema AS 65003

Subsistemas autónomos

Dispositivo de seguridad



Comunidades BGPEl atributo de ruta Communities ofrece un modo de agrupar destinos (llamados comunidades), que un enrutador BGP podrá después utilizar para controlar las rutas que acepta, prefiere o redistribuye a los equipos vecinos. Un enrutador BGP puede agregar comunidades a una ruta (si la ruta no tiene el atributo Communities) o modificar las comunidades de una ruta (si ésta incluye el atributo de ruta Communities). Este atributo ofrece una técnica alternativa para distribuir información de rutas de acuerdo con los prefijos de direcciones IP o el atributo AS-path. Puede utilizar el atributo Communities de muchas formas, pero su principal objetivo es simplificar la configuración de directivas de enrutamiento en entornos de redes completos.

La norma RFC 1997 describe el funcionamiento de las comunidades BGP. Un administrador de AS puede asignar a una comunidad una serie de rutas que precisen de las mismas decisiones de enrutamiento; a esto se le llama en ocasiones coloreado de rutas. Por ejemplo, es posible asignar un valor de comunidad a las rutas con acceso a Internet y otro valor de comunidad a las rutas que no tienen acceso.

Hay dos tipos de comunidades:

Una comunidad específica está formada por un identificador de AS y un identificador de comunidad. Este último es definido por el administrador de AS.

Una comunidad bien conocida implica un manejo especial de las rutas que contienen esos valores de comunidad. A continuación se muestran valores de comunidad bien conocida que se pueden especificar para las rutas BGP en el dispositivo de seguridad:

no-export: las rutas con este atributo de ruta Communities no se notifican fuera de una confederación BGP.

no-advertise: las rutas con este atributo de ruta Communities no se notifican a otros interlocutores BGP.

no-export-subconfed: las rutas con este atributo de ruta Communities no se notifican a interlocutores EBGP.

Puede utilizar un mapa de rutas para filtrar las rutas que coinciden con los datos de una lista de comunidad especificada, eliminar o asignar atributos a las rutas, agregar comunidades a la ruta o eliminarlas de ella.

Por ejemplo, si un proveedor de servicios de Internet (ISP) ofrece conectividad a Internet a sus clientes, cada una de las rutas de esos clientes podrá recibir un número de comunidad específico. A continuación, esas rutas de clientes se notificarán a los ISP vecinos. Las rutas de otros ISP recibirán otros números de comunidad y no se notificarán a los ISP vecinos.



134

Agregación de rutasLa agregación es una técnica para resumir rangos de direcciones de enrutamiento (conocidas como rutas contribuyentes) en una sola entrada de ruta. Hay varios parámetros opcionales que se pueden establecer al configurar una ruta agregada. Esta sección contiene ejemplos de configuración de rutas agregadas.

Agregación de rutas con diferentes AS-PathsAl configurar una ruta agregada, puede especificar que el campo AS-Set del atributo de ruta AS-Path de BGP incluya las rutas AS de todas las rutas contribuyentes. Para especificar esto, utilice la opción AS-Set en la configuración de rutas agregadas.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Aggregate Address: Introduzca los siguientes datos, luego haga clic en Apply:

Aggregate State: Enable (seleccione)IP/Netmask: 1.0.0.0/8AS-Set: (seleccione)

CLI

set vrouter trust protocol bgpset vrouter trust protocol bgp aggregateset vrouter trust protocol bgp aggregate 1.0.0.0/8 as-setset vrouter trust protocol bgp enablesave

Supresión de las rutas más específicas en actualizacionesAl configurar una ruta agregada, puede especificar que las rutas más específicas (More-Specific) sean filtradas (excluidas) de las actualizaciones de enrutamiento. (Un interlocutor BGP prefiere una ruta más específica, si está anunciada, a una ruta agregada). Puede suprimir las rutas más específicas de cualquiera de estas dos maneras:

Utilice la opción Summary-Only en la configuración de rutas agregadas para suprimir todas las rutas más específicas.

Utilice la opción Supress-Map en la configuración de rutas agregadas para suprimir las rutas especificadas en un mapa de rutas.

En el ejemplo siguiente, el BGP anuncia la ruta agregada 1.0.0.0/8, pero las rutas más específicas son excluidas mediante filtro de las actualizaciones de rutas salientes.

NOTA: Si utiliza la opción AS-Set con una ruta agregada, un cambio en una ruta contribuyente puede provocar que el atributo de la ruta agregada también cambie. Esto provoca que BGP vuelva a anunciar la ruta agregada con el atributo de ruta cambiado.

NOTA: Debe habilitar la agregación de BGP antes de habilitar BGP.



WebUI


Aggregate State: Enable (seleccione)IP/Netmask: 1.0.0.0/8Suppress Option: Summary-Only (seleccione)

CLI

set vrouter trust protocol bgp aggregate 1.0.0.0/8 summary-onlysave

En el ejemplo siguiente, filtrará las rutas del rango 1.2.3.0/24 para que sean eliminadas de las actualizaciones que incluyan la ruta agregada 1.0.0.0/8. Para ello, primero configurará una lista de accesos que especifique las rutas a filtrar (1.2.3.0/24). A continuación, configurará un mapa de rutas ‘noadvert’ para permitir las rutas 1.2.3.0/24. Después configurará una ruta agregada 1.0.0.0/8 y especificará el mapa de ruta ‘noadvert’ como opción de supresión para las actualizaciones salientes.

WebUI

Network > Routing > Virtual Routers > Access List (para trust-vr) > New: Introduzca los siguientes datos y haga clic en OK:



Map Name: noadvertSequence No.: 2Action: Permit (seleccione)Match Properties:

Access List (seleccione), 1 (seleccione)


Aggregate State: Enable (seleccione)IP/Netmask: 1.0.0.0/8Suppress Option: Route-Map (seleccione), noadvert (seleccione)

CLI

set vrouter trust-vr access-list 1 permit ip 1.2.3.0/24 777set vrouter trust-vr route-map name noadvert permit 2set vrouter trust-vr route-map noadvert 2 match ip 1set vrouter trust protocol bgp aggregate 1.0.0.0/8 suppress-map noadvertsave



136

Selección de rutas para el atributo PathAl configurar una ruta agregada, puede especificar qué rutas deben o no deben ser utilizadas para construir el atributo de ruta AS-Path del BGP de la ruta agregada. Utilice la opción Advertise-Map en la configuración de rutas agregadas para seleccionar las rutas. Puede utilizar esta opción con la opción AS-Set para seleccionar rutas anunciadas con el atributo AS-Set.

En el ejemplo siguiente, configurará una ruta agregada 1.0.0.0/8 que se anunciará con el atributo AS-Set. El atributo AS-Set anunciado consiste en todas las rutas más específicas que caigan en el rango de prefijo 1.5.0.0/16, pero no las rutas que caigan en el rango de prefijo 1.5.6.0/24; configurará los rangos de prefijo a incluir y excluir en el mapa de rutas “advertset”.

WebUI


Access List ID: 3Sequence No.: 888IP/Netmask: 1.5.6.0/24Action: Deny (seleccione)




Map Name: advertsetSequence No.: 4Action: Permit (seleccione)Match Properties:

Access List (seleccione), 3 (seleccione)


Aggregate State: Enable (seleccione)IP/Netmask: 1.0.0.0/8Advertise Map: advertset (seleccione)

CLI

set vrouter trust-vr access-list 3 deny ip 1.5.6.0/24 888set vrouter trust-vr access-list 3 permit ip 1.5.0.0/16 999set vrouter trust-vr route-map name advertset permit 4set vrouter trust-vr route-map advertset 4 match ip 3set vrouter trust protocol bgp aggregate 1.0.0.0/8 advertise-map advertsetsave



Cambiar atributos de una ruta agregadaAl configurar una ruta agregada, puede establecer sus atributos basándose en un mapa de ruta especificado. En el ejemplo siguiente, configurará una ruta agregada 1.0.0.0/8 que se anunciará con la métrica 1111 en las actualizaciones salientes.

WebUI


Map Name: aggmetricSequence No.: 5Action: Permit (seleccione)Set Properties: (seleccione)Metric: 1111


Aggregate State: Enable (seleccione)IP/Netmask: 1.0.0.0/8Attribute Map: aggmetric (seleccione)

CLI

set vrouter trust-vr route-map name aggmetric permit 5set vrouter trust-vr route-map aggmetric 5 metric 1111set vrouter trust protocol bgp aggregate 1.0.0.0/8 attribute-map aggmetricsave

Cambiar atributos de una ruta agregadaAl configurar una ruta agregada, puede establecer sus atributos basándose en un mapa de ruta especificado. En el ejemplo siguiente, configurará una ruta agregada 1.0.0.0/8 que se anunciará con la métrica 1111 en las actualizaciones salientes.

WebUI


Map Name: aggmetricSequence No.: 5Action: Permit (seleccione)Set Properties: (seleccione)Metric: 1111


Aggregate State: Enable (seleccione)IP/Netmask: 1.0.0.0/8Attribute Map: aggmetric (seleccione)

CLI

set vrouter trust-vr route-map name aggmetric permit 5set vrouter trust-vr route-map aggmetric 5 metric 1111set vrouter trust protocol bgp aggregate 1.0.0.0/8 attribute-map aggmetricsave



138

Capítulo 6

Enrutamiento basado en directivas

El enrutamiento basado en directivas (PBR) proporciona un mecanismo flexible para reenviar los paquetes de datos basados en directivas que un administrador de red configura.

Este capítulo consta de las siguientes secciones:

“Vista general del enrutamiento basado en directivas” en la página 140

“Listas de acceso extendidas” en la página 140

“Grupos de coincidencias” en la página 141

“Grupos de acciones” en la página 141

“Consulta de rutas con enrutamiento basado en directivas” en la página 142

“Configuración del enrutamiento basado en directivas” en la página 143

“Configuración de una lista de acceso extendida” en la página 143

“Configuración de un grupo de coincidencias” en la página 145

“Configuración de un grupo de acciones” en la página 145

“Configuración de una directiva de PBR” en la página 146

“Enlace de una directiva de enrutamiento basado en directivas” en la página 146

“Visualización de la salida de enrutamiento basado en directivas” en la página 147

“Visualización de una lista de acceso extendida” en la página 147

“Visualización de un grupo de coincidencias” en la página 148

“Visualización de un grupo de acciones” en la página 148

“Visualización de la configuración de una directiva de enrutamiento basado en directivas” en la página 149

139


140

“Visualización de la configuración completa de enrutamiento basado en directivas” en la página 150

“Ejemplo de PBR avanzado” en la página 150

“PBR avanzado con alta disponibilidad y posibilidad de ampliación” en la página 155

Vista general del enrutamiento basado en directivas

El enrutamiento PBR le permite implementar directivas que ocasiona que los paquetes tomen rutas distintas de manera selectiva. El enrutamiento PBR proporciona un mecanismo de enrutamiento para las redes que se basan en el soporte de la capa de aplicación, como el antivirus (AV), deep inspection (DI) o antispam, filtrado de web o que requieren de una vía automática para aplicaciones específicas.

Como primera parte del proceso de consulta de rutas, ScreenOS revisa si hay PBR y la revisión de PBR es transparente para todo el tráfico que no es PBR, cuando un paquete entra en el dispositivo de seguridad. PBR está habilitado en el nivel de interfaz y configurado dentro de un contexto de enrutador virtual; pero puede elegir la asociación de las directivas de PBR a una interfaz, una zona, un enrutador virtual (VR) o una combinación de interfaz, zona o VR.

Se utilizan los siguientes tres módulos para crear una directiva de PBR:

Listas de acceso extendidas

Grupos de coincidencias

Grupos de acciones

Listas de acceso extendidasLas listas de acceso extendido enumeran los criterios de coincidencia que define para las directivas de PBR. Los criterios de coincidencia de PBR determinan la ruta de un flujo determinado de tráfico de datos. Los criterios de coincidencia incluyen los siguientes:

Dirección IP de origen

Dirección IP destino

Puerto de origen

Puerto de destino

Protocolo, como HTTP

Prioridad de calidad de servicio (QoS) (opcional)

Vista general del enrutamiento basado en directivas

Capítulo 6: Enrutamiento basado en directivas

Grupos de coincidenciasLos grupos de coincidencias proporcionan una manera de organizar (por grupo, nombre y prioridad) las listas de acceso extendidas. Los grupos de coincidencias asocian el número de ID de lista de acceso extendida con un nombre de grupo de coincidencias única y un número de ID de grupo de coincidencias. Este número de ID de grupo de coincidencias define el orden en el cual desea que el dispositivo de seguridad procese las listas de ACL extendidas. Puede asignar varias listas de acceso extendidas al mismo grupo de coincidencias.

Grupos de accionesLos grupos de acciones especifican la ruta que desea que tome el paquete. Se especifica la “acción” de la ruta al definir la siguiente interfaz, el salto siguiente o ambos.

Cada entrada de acción configurada se supervisa para revisar la accesibilidad como se muestra a continuación:

Accesibilidad únicamente de la siguiente interfaz

Si asocia la entrada de acción únicamente con la siguiente interfaz, el estado de conexiones determina la accesibilidad.

Si la siguiente interfaz está activa, la entrada de acción es posible. Cualquier interfaz, incluyendo todas las interfaces lógicas, tales como de túnel, agregadas o redundantes, que son visibles en el VR en el cual reside la directiva, son candidatas para la siguiente interfaz.

Por ejemplo, si configura la entrada de acción con una interfaz NULL, la entrada de acción es alcanzable todo el tiempo. Con una interfaz NULL como la siguiente interfaz, la consulta de PBR siempre tiene éxito, de manera que ScreenOS detiene la consulta de rutas y descarta los paquetes.

Accesibilidad únicamente de salto siguiente

Si asocia el grupo de acciones únicamente con el salto siguiente, éste debe ser alcanzable a través de una entrada de ruta en la tabla de enrutamiento de las rutas de destino. El salto siguiente configurado es alcanzable en tanto exista una ruta válida en la tabla de enrutamiento de rutas de destino para resolver el salto siguiente.

Accesibilidad de la siguiente interfaz y de salto siguiente

Si configura la accesibilidad tanto para el salto siguiente como para la siguiente interfaz, el salto siguiente configurado debe ser alcanzable a través de la siguiente interfaz configurada.

NOTA: La supervisión de la accesibilidad no se refiere a las consultas del Protocolo de resolución de dirección (ARP) de la capa 2 o seguimiento de la capa 3.

Vista general del enrutamiento basado en directivas 141


142

Si el salto siguiente es alcanzable a través de la siguiente interfaz, la entrada de acción es alcanzable. Cualquier interfaz incluyendo todas las interfaces lógicas, tal como túnel, agregado o redundante, que son visibles en VR en el cual reside la directiva, son candidatas para ser la siguiente interfaz.

ScreenOS descarta el paquete si el salto siguiente es alcanzable pero la siguiente interfaz es una interfaz NULL. Si configura la entrada de acción con una interfaz NULL como la siguiente interfaz y el salto siguiente como ruta estática, ScreenOS pasa los paquetes a la ruta estática.

En el momento de la configuración, también asigna un número de secuencia para especificar el orden en el cual desea que se procese la entrada de grupo de acciones.

Consulta de rutas con enrutamiento basado en directivas

Cuando se habilita el enrutamiento basado en directivas en una interfaz, ScreenOS revisa todo el tráfico enviado a esa interfaz para ver si incluye enrutamiento basado en directivas. Cuando un paquete entra al dispositivo de seguridad, ScreenOS revisa la interfaz de entrada para una configuración de directiva de PBR. Si PBR está habilitado en esa interfaz de entrada, se aplican las siguientes acciones al paquete:

1. ScreenOS aplica la directiva de PBR asociada a la interfaz de entrada al paquete.

2. Si no existe una directiva de PBR al nivel de la interfaz, entonces ScreenOS aplica la directiva de PBR unida a la zona asociada con la interfaz de entrada al paquete.

3. Si no existe una directiva de PBR al nivel de zona, entonces ScreenOS aplica la directiva de PBR unida a VR asociado con la interfaz de entrada al paquete.

ScreenOS encuentra el grupo de coincidencias y luego procesa las entradas de grupo de acciones. La primera entrada de acción alcanzable del grupo de acciones con una ruta válida es la que se utiliza para reenviar el paquete. Si no existen rutas alcanzables entre las entradas de acción, entonces se realiza una consulta de rutas regular.

Si la entrada de acción es alcanzable, ScreenOS realiza una consulta de rutas con la interfaz preferida como la siguiente interfaz (si se especifica) y el salto siguiente como la dirección IP (si se especifica) en lugar de utilizar el IP de destino. Si una ruta coincide con la siguiente interfaz y salto siguiente indicados, ScreenOS reenvía el paquete. De lo contrario, ScreenOS utiliza la dirección IP de destino.

NOTA: Para obtener más información sobre la consulta de rutas, consulte el Volumen 2: Fundamentos.

Consulta de rutas con enrutamiento basado en directivas


Configuración del enrutamiento basado en directivas

La Figura 20 muestra una manera en que PBR diferencia las rutas de tráfico de servicio enviando el tráfico de HTTP a lo largo de una ruta y el tráfico de HTTPS a lo largo de otra. La Figura 20 muestra dos nodos, uno en 172.18.1.10 y otro en 172.18.2.10. Cuando el dispositivo de seguridad recibe el tráfico de HTTP, ScreenOS enruta el tráfico a través del enrutador 172.24.76.1; y cuando el dispositivo de seguridad recibe el tráfico de HTTPS, ScreenOS enruta el tráfico a través del enrutador 172.24.76.2.

Lo contrario sucede en el nodo 172.18.2.10. El tráfico de HTTP del nodo 172.18.2.10 fluye al enrutador 172.24.76.2 y el tráfico de HTTPS fluye al enrutador 172.24.76.1.

Figura 20: Enrutamiento del tráfico de HTTP y HTTPS con enrutamiento basado en directivas

Configuración de una lista de acceso extendidaPuede configurar una lista de acceso extendida con la interfaz de usuario web (WebUI) o la interfaz de línea de comandos (CLI) desde dentro de un contexto de enrutador virtual. Primero, configure la lista de acceso extendida en el enrutador virtual (VR) de ingreso.

En este ejemplo que se encuentra en la página 143, el VR de ingreso es trust-vr. Si utiliza CLI, necesita introducir el contexto del enrutador virtual. Este ejemplo requiere de dos listas de acceso: 10 y 20. El número de secuencia de acceso es un número de 1 a 99. Las entradas 1 y 2 son necesarias para cada lista de acceso extendida.

172.24.76.2Enrutador derecho

172.24.76.1Enrutador izquierdo

172.24.76.71/22

10.25.10.0/24

172.18.2.10/24172.18.1.10/24

El tráfico de HTTP fluye de 172.18.2.10/24 al enrutador 172.24.76.2El tráfico de HTTPS fluye de 172.18.1.10/24 al enrutador 172.24.76.1

NOTA: Opcionalmente, puede agregar también el número de tipo de servicio (TOS), el cual es un número de 1 a 255. En este ejemplo no se requiere un número TOS.

Configuración del enrutamiento basado en directivas 143


144

La lista de acceso 10 define la dirección IP de origen como 172.18.1.10, el puerto de destino como 80 y el protocolo como TCP. El punto de destino para la lista de acceso 10 define la dirección IP de destino como 172.18.2.10, el puerto de destino como 443 y el protocolo como TCP.

La lista de acceso 20 define la dirección IP de origen como 172.18.2.10, el puerto de destino como 443 y el protocolo como TCP. El punto de destino para la lista de acceso 10 define la dirección IP de destino como 172.18.1.10, el puerto de destino como 80 y el protocolo como TCP.

En la CLI después de realizar la configuración de la lista de acceso extendida, usted sale del contexto del enrutador virtual. El ejemplo de WebUI únicamente muestra la creación de la lista de acceso 10.

WebUI

Network > Routing > PBR > Extended ACL List: Seleccione el enrutador virtual de la lista desplegable, luego haga clic en New para ver la página Configuration.

Introduzca la siguiente información para crear las entradas de la lista de acceso 10:

Creación de la lista de acceso 10Extended ACL ID: 10Sequence No.: 1Source IP Address/Netmask: 172.18.1.10/32 Destination Port: 80-80Protocol: TCP

Haga clic en OK. ScreenOS vuelve a una lista de listas de acceso.

Haga clic en New para configurar una segunda entrada para la lista de acceso 10 e introduzca la siguiente información:

Creación de la lista de acceso 10Extended ACL ID: 10Sequence No.: 2Source IP Address/Netmask: 172.18.2.10/32 Destination Port: 443-443Protocol: TCP

Haga clic en OK. ScreenOS lo regresa a una lista de listas de acceso.

CLI

set vrouter trust-vrset access-list extended 10 src-ip 172.18.1.10/32 dest-port 80-80 protocol tcp

entry 1set access-list extended 10 src-ip 172.18.2.10/32 dest-port 443-443 protocol tcp



entry 2exit



Configuración de un grupo de coincidenciasPuede configurar un grupo de coincidencias desde dentro de un contexto de enrutador virtual.

En el ejemplo de la página 143, necesita configurar dos grupos de coincidencias: Enrutador izquierdo y enrutador derecho. Puede asociar una lista de acceso 10 extendida con el enrutador izquierdo y una lista de acceso 20 extendida con el enrutador derecho. Un nombre de grupo de coincidencias es un identificador único de no más de 31 caracteres alfanuméricos.

El VR de ingreso es trust-vr. Si utiliza CLI, necesita introducir el contexto del enrutador virtual. En la CLI, después de realizar la configuración de la lista de acceso extendida, se sale del contexto del enrutador virtual.

El ejemplo de WebUI únicamente muestra la creación de un grupo de coincidencias para el enrutador izquierdo.

WebUI

Network > Routing > PBR > Match Group > Seleccione el enrutador virtual correcto de la lista desplegable, luego haga clic en New para ver la página Match Group Configuration. Introduzca la siguiente información para configurar el enrutador izquierdo:

Match Group Name: enrutador_izquierdoSequence No.: 1Extended ACL: Seleccione 10 de la lista desplegable.

CLI

set vrouter trust-vrset match-group name enrutador_izquierdoset match-group left ext-acl 10 match-entry 1set match-group name enrutador_derechoset match-group right ext-acl 20 match-entry 1exit

Configuración de un grupo de accionesPuede configurar un grupo de acciones dentro de un contexto de enrutamiento virtual.

En el ejemplo que se encuentra en la página 143 es posible que existan dos grupos de acciones diferentes: el dispositivo de seguridad puede reenviar el tráfico al enrutador izquierdo o al enrutador derecho. Por esta razón, necesita configurar dos diferentes grupos de acciones.

Para configurar estos dos grupos de acciones, realice las siguientes tareas:

1. Entre al contexto de enrutamiento virtual. En este ejemplo, el enrutador virtual es trust-vr.

2. Denomine el grupo de acciones con un nombre único y con significado. En este ejemplo, los nombres acci-derecha y acci-izquierda son descriptivos de los flujos de tráfico posibles.

Configuración del enrutamiento basado en directivas 145


146

3. Configure los detalles del grupo de acciones. En este ejemplo, establecerá la dirección de salto siguiente para cada grupo de acciones y luego asignará un número para indicar la prioridad de procesamiento. En este ejemplo, la prioridad de cada grupo de acciones es 1.

WebUI

Network > Routing > PBR > Action Group > Haga clic en New para ver la página Configuration

CLI

set vrouter trust-vrset action-group name acci-derechaset action-group acci-derecha next-hop 172.24.76.2 action-entry 1set action-group name acci-izquierdaset action-group acci-izquierda next-hop 172.24.76.1 action-entry 1exit

Configuración de una directiva de PBRPuede configurar una directiva de PBR desde dentro de un contexto de enrutador virtual.

Cada directiva de PBR necesita tener un nombre único. En este ejemplo, la directiva se denomina directiva-redireccionar.

Una directiva de PBR puede contener un nombre de grupo de coincidencias y un nombre de grupo de acciones. En este ejemplo, el tráfico puede fluir de dos diferentes formas, así que se necesitan dos instrucciones diferentes: acci-izquierda con el número de secuencia 1 y acci-derecha con el número de secuencia 2. La instrucción de directiva con el número de secuencia 1 se procesa primero.

WebUI

Network > Routing > PBR > Policy > Haga clic en New para ver la página Configuration

CLI

set vrouter trust-vrset pbr policy name directiva-redireccionarset pbr policy directiva-redireccionar match-group left action-group acci-izquierda 1set pbr policy directiva-redireccionar match-group right action-group acci-derecha 2exit

Enlace de una directiva de enrutamiento basado en directivasPuede asociar una directiva de PBR a una interfaz, una zona o un enrutador virutal dentro de un contexto de enrutador virtual.

Enlace de una directiva de enrutamiento basado en directivas a una interfazPuede asociar la directiva de PBR directiva-redireccionar a la interfaz de ingreso. En este ejemplo, la interfaz es la interfaz trust.



WebUI

Network > Routing > PBR > Policy Binding

CLI

set interface trust pbr directiva-redireccionar

Enlace de una directiva de enrutamiento basado en directivas a una zonaPuede asociar la directiva de PBR directiva-redireccionar a una zona. En este ejemplo, la zona es la zona Trust.

WebUI


CLI

set zone trust pbr directiva-redireccionar

Enlace de una directiva de enrutamiento basado en directivas a un enrutador virtualPuede asociar la directiva de PBR directiva-redireccionar a un enrutador virtual. En este ejemplo, el enrutador virtual es trust-vr.

WebUI


CLI

set vrouter trust-vr pbr directiva-redireccionar

Visualización de la salida de enrutamiento basado en directivas

Puede ver la información relacionada con el enrutamiento basado en directivas con WebUI o CLI.

Visualización de una lista de acceso extendidaPuede ver la lista completa de las listas de acceso extendidas desde WebUI o CLI.

En CLI puede especificar ver una lista de acceso extendida determinada. En el segundo ejemplo de CLI, el ejemplo muestra que existen dos listas de acceso extendidas en trust-vr, pero el usuario indicó la lista de acceso extendido 2. Según se especificó, ScreenOS regresó dos entradas de lista de acceso, 10 y 20, únicamente para la segunda lista de acceso extendida.

WebUI

Network > Routing > PBR > Access List Ext

CLI 1

get vrouter trust-vr pbr access-list configuration

Visualización de la salida de enrutamiento basado en directivas 147


148

Ejemplo:

set access-list extended 1 src-ip 172.16.10.10/32 dest-ip 192.169.10.10/32 dest-port 80-80 protocol tcp entry 1set access-list extended 1 src-port 200-300 entry 2set access-list extended 2 dest-port 500-600 protocol udp entry 10set access-list extended 2 dest-ip 50.50.50.0/24 protocol udp entry 20

CLI 2

get vrouter trust-vr pbr access-list 2

Ejemplo:

PBR access-list: 2 in vr: trust-vr, number of entries: 2------------------------------------------------PBR access-list entry: 10------------------------dest port range 500-600protocols: udp PBR access-list entry: 20------------------------dest ip-address 50.50.50.0/24protocols: udp

Visualización de un grupo de coincidenciasPuede ver los detalles de grupo de coincidencias desde WebUI o CLI.

WebUI

Network > Routing > PBR > Match Group

CLI

get vrouter trust-vr pbr match-group config

Ejemplo:

set match-group name pbr1_mgset match-group pbr1_mg ext-acl 1 match-entry 1set match-group name pbr1_mg2set match-group pbr1_mg2 ext-acl 2 match-entry 10

Visualización de un grupo de accionesPuede ver los detalles de grupo de acciones desde WebUI o CLI.

WebUI

Network > Routing > PBR > Action Group

CLI 1

get vrouter trust-vr pbr action-group configuration

Visualización de la salida de enrutamiento basado en directivas


Ejemplo:

set action-group name pbr1_agset action-group pbr1_ag next-interface ethernet2 next-hop 10.10.10.2

action-entry 1set action-group name pbr1_ag2set action-group pbr1_ag2 next-hop 30.30.30.30 action-entry 10set action-group pbr1_ag2 next-interface ethernet3 action-entry 20set action-group pbr1_ag2 next-interface ethernet3 next-hop 60.60.60.60

action-entry 30

CLI 2

get vrouter trust-vr pbr match-group name pbr1_ag2

Ejemplo:

device-> get vr tr pbr action-group name pbr1_ag2PBR action-group: pbr1_ag2 in vr: trust-vr number of entries: 3------------------------------------------------PBR action-group entry: 10next-interface: N/A, next-hop: 30.30.30.30------------------------PBR action-group entry: 20next-interface: ethernet3, next-hop: 0.0.0.0------------------------PBR action-group entry: 30next-interface: ethernet3, next-hop: 60.60.60.60------------------------

Visualización de la configuración de una directiva de enrutamiento basado en directivasPuede ver la configuración de directivas de enrutamiento basado en directivas desde WebUI o CLI. En la CLI puede escoger ver la configuración o puede introducir el nombre de directiva para ver una configuración de directiva individual.

WebUI

Network > Routing > PBR > Policy

CLI

get vrouter trust-vr pbr policy config

Ejemplo:

set pbr policy name pbr1_policyset pbr policy pbr1_policy match-group pbr1_mg2 action-group pbr1_ag2 50set pbr policy pbr1_policy match-group pbr1_mg action-group pbr1_ag 256

Visualización de la salida de enrutamiento basado en directivas 149


150

CLI

get vrouter trust-vr pbr policy name pbr1_policy

Ejemplo:

PBR policy: pbr1_policy in vr: trust-vr number of entries: 2------------------------------------------------PBR policy entry: 50match-group: pbr1_mg2, action-group: pbr1_ag2------------------------PBR policy entry: 256match-group: pbr1_mg, action-group: pbr1_ag------------------------

Visualización de la configuración completa de enrutamiento basado en directivasPuede ver la configuración de enrutamiento basado en directivas desde WebUI o CLI.

WebUI

Network > Routing > PBR > Access List ExtNetwork > Routing > PBR > Match GroupNetwork > Routing > PBR > Action GroupNetwork > Routing > PBR > Policy

CLI

get vrouter trust-vr pbr configuration

Ejemplo:

set access-list extended 1 src-ip 172.16.10.10/32 dest-ip 192.169.10.10/32 dest-port 80-80 protocol tcp entry 1set access-list extended 1 src-port 200-300 entry 2set access-list extended 2 dest-port 500-600 protocol udp entry 10set access-list extended 2 dest-ip 50.50.50.0/24 protocol udp entry 20set match-group name pbr1_mgset match-group pbr1_mg ext-acl 1 match-entry 1set match-group name pbr1_mg2set match-group pbr1_mg2 ext-acl 2 match-entry 10set action-group name pbr1_agset action-group pbr1_ag next-interface ethernet2 next-hop 10.10.10.2 action-entry 1set action-group name pbr1_ag2set action-group pbr1_ag2 next-hop 30.30.30.30 action-entry 10set action-group pbr1_ag2 next-interface ethernet3 action-entry 20set action-group pbr1_ag2 next-interface ethernet3 next-hop 60.60.60.60 action-entry 30set pbr policy name pbr1_policyset pbr policy pbr1_policy match-group pbr1_mg2 action-group pbr1_ag2 50set pbr policy pbr1_policy match-group pbr1_mg action-group pbr1_ag 256

Ejemplo de PBR avanzado

PBR le permite definir y descargar únicamente los tipos de tráfico que ScreenOS necesita procesar. Durante el procesamiento de tipos específicos de tráfico, como el tráfico que necesita análisis antivirus (AV), la red no se satura porque no analiza los tipos de paquetes que no requieren análisis en busca de virus.



Puede combinar varios tipos de dispositivos de seguridad de Juniper Networks para que trabajen conjuntamente y proporcionen los servicios al mismo tiempo que mantienen una buena velocidad de procesamiento en la red y generan una carga de análisis de AV aceptable. La Figura 21 muestra un dispositivo de seguridad que ejecuta PBR para dividir el tráfico de AV de todo el otro tráfico (derecha).

Figura 21: Enrutamiento selectivo por tipo de tráfico

Por ejemplo, si desea utilizar PBR para descargar únicamente el tráfico de HTTP, SMTP y POP3 para el procesamiento de AV, por lo menos necesita utilizar un dispositivo de seguridad con cuatro interfaces 10/100 disponibles para proporcionar enrutamiento y un dispositivo de seguridad para proporcionar el soporte de la aplicación (AV).

En el siguiente ejemplo, realice los siguientes pasos para configurar el dispositivo de seguridad que proporciona las rutas de enrutamiento:

1. Configure el enrutamiento.

2. Configure PBR.

3. Enlace las directivas de PBR a las interfaces apropiadas.

Las siguientes secciones explican cada uno de estos pasos. Los ejemplos muestran únicamente los comandos CLI y la salida.

Para obtener más información sobre la configuración de AV, consulte el Volumen 4: Detección ataques y mecanismos de defensa.

NOTA: También podría configurar PBR para enviar tráfico específico para antispam, deep inspection (DI), prevención y detección de intrusión (IDP), filtrado de web o caché.

Tráfico TCP

Analizador de AV

Las directivas de PBR envían el tráfico de HTTP, SMTP y POP3 a un analizador de AV.

Dispositivo de seguridad con PBR configurado

NOTA: Si únicamente tiene tres interfaces 10/100 disponibles, puede colocar un conmutador entre los dos dispositivos de seguridad y utilizar el etiquetado VLAN (802.1q) para configurar las mismas rutas para el tráfico.

Ejemplo de PBR avanzado 151


152

EnrutamientoEn este ejemplo, necesita crear dos zonas personalizadas.

av-dmz-1 para trust-vr

av-dmz-2 para untrust-vr

Para configurar las zonas, introduzca los siguientes comandos:

set zone name av-dmz-1set zone name av-dmz-2

Con la información que se muestra en la Tabla 15, configurará cuatro interfaces 10/100 Ethernet.

Tabla 15: Configuración de interfaz para enrutamiento

Para configurar las interfaces, introduzca los siguientes comandos:

set interface e1 zone trust vrouter trust-vr ip 10.251.10.0/24set interface e2 zone av-dmz-1 vrouter trust-vr ip 192.168.100.1/24set interface e3 zone av-dmz-2 vrouter untrust-vr ip 192.168.101.1/24set interface e4 zone untrust vrouter untrust-vr ip 172.24.76.127/24

Después de configurar las zonas, las interfaces y las rutas, necesita realizar las siguientes dos tareas:

1. Configure una ruta estática de untrust-vr a trust-vr. Asigne una dirección IP de la puerta de enlace de 10.251.10.0/24 y un valor de preferencia de 20 a la entrada:

set vrouter "untrust-vr"set route 10.251.10.0/24 vrouter "trust-vr" preference 20 exit

2. Configure la interfaz NULL con un valor de preferencia mayor que cero (0) de la interfaz Trust a la interfaz Untrust:

set vrouter "trust-vr"set route 0.0.0.0/0 vrouter "untrust-vr" preference 20 exit

Nombre de interfaz Zona Enrutador virtual Dirección de IPv4

E1 trust trust-vr 10.251.10.0/24

E2 av-dmz-1 trust-vr 192.168.100.1/24

E3 av-dmz-2 untrust-vr 192.168.101.1/24

E4 untrust untrust-vr 172.24.76.127/24



Puede verificar los cambios con el comando get route:

Routing Table:IPv4 Dest-Routes for <untrust-vr> (6 entries)---------------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys----------------------------------------------------------------------------* 6 0.0.0.0/0 eth4 172.24.76.1 C 0 1 Root* 3 10.251.10.0/24 n/a trust-vr S 20 0 Root* 4 172.24.76.0/22 eth4 0.0.0.0 C 0 0 Root* 2 192.168.101.1/32 eth3 0.0.0.0 H 0 0 Root* 5 172.24.76.127/32 eth4 0.0.0.0 H 0 0 Root* 1 192.168.101.0/24 eth3 0.0.0.0 C 0 0 Root

IPv4 Dest-Routes for <trust-vr> (5 entries)------------------------------------------------------------ ID IP-Prefix Interface Gateway P Pref Mtr Vsys------------------------------------------------------------* 5 0.0.0.0/0 n/a untrust-vr S 20 0 Root* 1 10.251.10.0/24 eth1 0.0.0.0 C 0 0 Root* 4 192.168.100.1/32 eth2 0.0.0.0 H 0 0 Root* 3 192.168.100.0/24 eth2 0.0.0.0 C 0 0 Root* 2 10.251.10.1/32 eth1 0.0.0.0 H 0 0 Root

Ahora está listo para configurar PBR.

Elementos PBRDespués de configurar las interfaces y rutas, puede configurar PBR. Para que PBR funcione correctamente, debe configurar los siguientes elementos para trust-vr:

Lista de acceso extendida

Grupo de coincidencias

Grupo de acciones

Directiva de PBR

Listas de acceso extendidasPara este ejemplo, determinará que desea enviar el tráfico de HTTP (puerto 80), SMTP (puerto 110) y POP3 (puerto 25) para el procesamiento de AV. Para enviar estos tres tipos de paquetes a un dispositivo de seguridad, configure una lista de acceso extendido en trust-vr.

Cuando cualquier cliente en la subred 10.251.10.0/24 inicia el tráfico que utiliza TCP al puerto 80, 110 ó 25, desea que ScreenOS compare ese tráfico con los criterios de lista de acceso extendida y realice la acción asociada con la lista de acceso. La acción obliga a ScreenOS a enrutar el tráfico como usted indica, y no como otro tráfico. Cada lista de acceso necesita tres entradas, una para cada tipo de tráfico de TCP al que se dirige.

NOTA: No necesita configurar una lista de acceso extendida para el tráfico de regreso ya que el dispositivo de seguridad realiza una consulta de sesión antes que una consulta de rutas y luego aplica una directiva de PBR según sea necesario. El tráfico de retorno tiene una sesión existente.

Ejemplo de PBR avanzado 153


154

Para configurar la lista de acceso extendida para trust-vr, introduzca los siguientes comandos:

set vrouter "trust-vr"set access-list extended 10 src-ip 10.251.10.0/24 dest-port 80-80 protocol tcp

entry 1 set access-list extended 10 src-ip 10.251.10.0/24 dest-port 110-110 protocol

tcp entry 2 set access-list extended 10 src-ip 10.251.10.0/24 dest-port 25-25 protocol tcp

entry 3 exit

Grupos de coincidenciasUn grupo de coincidencias asocia una lista de acceso extendida con un nombre significativo al que se hace referencia en la directiva de PBR. Primero introduzca un contexto de enrutador virtual, luego cree un grupo de coincidencias y finalmente agregue una entrada que asocia el nombre del grupo de coincidencias recientemente creado con una lista de acceso y el número de entrada.

Para crear grupos de coincidencias en trust-vr, introduzca los siguientes comandos:

set vrouter trust-vrset match-group name av-match-trust-vrset match-group av-match-trust-vr ext-acl 10 match-entry 1 exit

Grupos de accionesA continuación, creará un grupo de acciones, el cual indica a donde enviar el paquete. Para este ejemplo, creará un grupo de acciones para trust-vr con la acción establecida para enviar el tráfico al salto siguiente.

Con el salto siguiente, la acción se resuelve con el protocolo de resolución de dirección (ARP).

Para trust-vr, reenviará el tráfico con la instrucción de siguiente salto a través de 192.168.100.254 por medio de los siguientes comandos:

set vrouter trust-vrset action-group name av-action-redirect-trust-vr set action-group

av-action-redirect-trust-vr next-hop 192.168.100.254 action-entry 1 exit

Directivas de PBRA continuación, definirá la directiva de PBR, que requiere de los siguientes elementos:

Nombre de la directiva de PBR

PRECAUCIÓN: Si la acción es enviar el tráfico a la siguiente interfaz, el cambio de estado de enlace activará/desactivará la directiva de enrutamiento.



Nombre del grupo de coincidencias

Nombre del grupo de acciones

Para configurar la directiva de PBR, introduzca los siguientes comandos:

set vrouter trust-vrset pbr policy name av-redirect-policy-trust-vr set pbr policy av-redirect-policy-trust-vr match-group av-match-trust-vr

action-group av-action-redirect-trust-vr 1 exit

Asociación de interfacesFinalmente, asociará la directiva de PBR a la interfaz de ingreso, e1.

Para asociar la directiva de PBR a su interfaz de ingreso, introduzca los siguientes comandos:

set interface e1 pbr av-redirect-policy-trust-vr

PBR avanzado con alta disponibilidad y posibilidad de ampliación

Con el ejemplo anterior de PBR como base, puede mejorar la flexibilidad de su red con alta disponibilidad (HA) o posibilidad de ampliación.

Solución de resistencia en PBR Una solución sólida de PBR puede incluir las siguientes configuraciones de dispositivo:

Dos dispositivos de seguridad que proporcionan red

Otros dos dispositivos de seguridad que proporcionan análisis de AV

Cada par de dispositivos ejecuta el protocolo de redundancia de NetScreen (NSRP) en una configuración activa/pasiva para proporcionar protección de cambio en caso de fallo. Para los dos dispositivos de seguridad que ejecutan el enrutamiento, un dispositivo se encarga de la función de enrutamiento si ocurre un fallo del hardware. En caso del par que proporciona el análisis de AV, si ocurre un fallo en uno de los dispositivos, el otro dispositivo se encarga de la función de análisis.

NOTA: Para obtener más información, consulte el Volumen 11: Alta Disponibilidad.

PBR avanzado con alta disponibilidad y posibilidad de ampliación 155


156

Solución con posibilidad de ampliación en PBRLas soluciones PBR se amplían bien. Si necesita más capacidad, puede agregar más dispositivos de seguridad. Al dividir la subred /24 en dos subredes /25, puede configurar una lista de acceso extendida para la subred inferior /25 y otra lista de acceso extendido para la subred superior /25, luego agregue dos dispositivos de seguridad para proporcionar servicios de análisis en DMZ.

También puede implementar el equilibrio de carga si crea una configuración de NSRP activa/activa. Un dispositivo puede procesar el tráfico de la subred inferior /25 y el otro dispositivo puede procesar el tráfico de la subred superior /25. Cada dispositivo respalda al otro.

PBR avanzado con alta disponibilidad y posibilidad de ampliación

Capítulo 7

Enrutamiento multicast

Este capítulo presenta los conceptos básicos sobre el enrutamiento multicast. Incluye las siguientes secciones:

“Vista general” en esta página

“Direcciones multicast” en la página 158

“Reenvío por rutas inversas” en la página 158

“Enrutamiento multicast en dispositivos de seguridad” en la página 159

“Tabla de enrutamiento multicast” en la página 159

“Configuración de una ruta multicast estática” en la página 160

“Listas de acceso” en la página 161

“Configurar Encapsulado de enrutamiento genérico en interfaces de túnel” en la página 161

“Directivas multicast” en la página 163

Vista general

Las empresas utilizan el enrutamiento multicast para transmitir tráfico, como secuencias de datos o vídeo, desde un origen a un grupo de receptores simultáneamente. Cualquier host puede ser un origen y los receptores pueden estar en cualquier punto de Internet.

El enrutamiento IP multicast proporciona un método eficiente para reenviar tráfico a múltiples hosts, porque los enrutadores habilitados para multicast transmiten tráfico multicast solamente a los hosts que desean recibirlo. Los hosts deben indicar su interés por recibir datos multicast y deben unirse a un grupo multicast para recibir los datos. Los enrutadores habilitados para multicast reenvían el tráfico multicast solamente a los receptores interesados en recibirlo.

Vista general 157


158

Los entornos de enrutamiento multicast requieren los siguientes elementos para reenviar información multicast:

Un mecanismo que se ejecute entre hosts y enrutadores para comunicar la información de miembros del grupo multicast. Los dispositivos de seguridad admiten las versiones 1, 2 y 3 del protocolo de administración de grupo (IGMP). Los enrutadores y hosts utilizan IGMP sólo para transmitir la información de miembros, no para reenviar ni enrutar tráfico multicast. (Para obtener información sobre IGMP, consulte “Protocolo de administración de grupos de Internet” en la página 165.)

Un protocolo de enrutamiento multicast para alimentar la tabla de rutas multicast y reenviar datos a los hosts a través de la red. Los dispositivos de seguridad de Juniper Networks admiten multicast independiente de protocolo – modo Sparse (PIM-SM) y multicast independiente de protocolo – modo de origen específico (PIM-SSM). (Para obtener información sobre PIM-SM y PIM-SSM, consulte el “Multicast independiente de protocolo” en la página 191).

Alternativamente, puede utilizar la función IGMP proxy para reenviar tráfico multicast sin sobrecargar la CPU con la ejecución de un protocolo de enrutamiento multicast. (Para obtener más información, consulte “Proxy de IGMP” en la página 173).

Las siguientes secciones presentan los conceptos básicos utilizados en el enrutamiento multicast.

Direcciones multicastCuando un origen envía tráfico multicast, la dirección de destino es una dirección del grupo multicast. Las direcciones del grupo multicast son direcciones de clase D desde la 224.0.0.0 hasta la 239.255.255.255.

Reenvío por rutas inversasCuando un enrutador multicast recibe paquetes multicast, utiliza un proceso denominado reenvío por rutas inversas (reverse path forwarding o RPF) para comprobar la validez de los paquetes. Antes de crear una ruta multicast, el enrutador realiza operaciones de consulta de rutas en la tabla de rutas unicast para comprobar si la interfaz en la cual recibió el paquete (interfaz de entrada) es la misma interfaz que debe utilizar para enviar los paquetes de vuelta al remitente. Si lo es, el enrutador crea la entrada de la ruta multicast y reenvía el paquete al enrutador del salto siguiente. Si no lo es, el enrutador descarta el paquete. Los enrutadores multicast no efectúan esta comprobación de RPF para rutas estáticas. La Figura 22 muestra el dispositivo de seguridad y el flujo de procesamiento de paquetes multicast.

Vista general

Capítulo 7: Enrutamiento multicast

Figura 22: Reenvío por rutas inversas

Enrutamiento multicast en dispositivos de seguridad

Los dispositivos de seguridad de Juniper Networks tienen dos enrutadores virtuales predefinidos (VR): trust-vr y untrust-vr. Cada enrutador virtual es un componente de enrutamiento independiente, con sus propias tablas de rutas unicast y multicast. (Para obtener información sobre tablas de rutas unicast, consulte “Enrutamiento estático” en la página 1.) Cuando el dispositivo de seguridad recibe un paquete multicast entrante, consulta la ruta entre las rutas indicadas en la tabla de rutas multicast.

Tabla de enrutamiento multicastLa tabla de rutas multicast se alimenta con las rutas estáticas multicast o las rutas aprendidas a través del protocolo de enrutamiento multicast. El dispositivo de seguridad utiliza la información de la tabla de rutas multicast para reenviar tráfico multicast. Los dispositivos de seguridad mantienen una tabla de enrutamiento multicast para cada protocolo de enrutamiento de un enrutador virtual.

La tabla de enrutamiento multicast contiene información específica sobre el protocolo de enrutamiento más la información siguiente:

Cada entrada comienza con el estado de reenvío. El estado de reenvío puede tener uno de los siguientes formatos: (*, G) o (S, G). El formato (*, G) se denomina entrada “asterisco coma G”, donde el * se refiere a cualquier origen y G es una dirección de grupo multicast específica. El formato (S, G) se denomina entrada “S coma G”, donde S es la dirección IP de origen y G es la dirección del grupo multicast.

Las interfaces de sentido ascendente y descendente.

El vecino de reenvío por rutas inversas (RPF).

Origen 3.3.3.6

enrutador externo 1.1.1.250

El dispositivo de seguridad comprueba si la interfaz de entrada coincide con la de salida para los paquetes destinados al remitente.

ethernet1 1.1.1.1

El paquete multicast procedente de 1.1.1.250 llega a ethernet1.

ethernet3 10.1.1.1

3a. En caso afirmativo, enviar los paquetes multicast al destino.

Consulta en la tabla de rutas

3b. En caso negativo, descartar el paquete.

DST IF GATE 0.0.0.0.eth1 --- 10.1.1.0 eth3 ---- 1.1.1.0 eth1 ---

Enrutamiento multicast en dispositivos de seguridad 159


160

A continuación se incluye un ejemplo de una tabla de enrutamiento multicast PIM-SM en el enrutador virtual trust-vr:

trust-vr - PIM-SM routing table-----------------------------------------------------------------------------Register - R, Connected members - C, Pruned - P, Pending SPT Alert - GForward - F, Null - N , Negative Cache - E, Local Receivers - LSPT - T, Proxy-Register - X, Imported - I, SGRpt state - Y, SSM Range Group - STurnaround Router - K-----------------------------------------------------------------------------Total PIM-SM mroutes: 2(*, 236.1.1.1) RP 20.20.20.10 0:06:24/- Flags: LF Zone: Untrust Upstream : ethernet1/2 State : Joined RPF Neighbor : local Expires : - Downstream : ethernet1/2 00:06:24/00:02:57 Join 0.0.0.0 FC(20.20.20.200/24, 236.1.1.1) 00:06:24/00:00:36 Flags: TXLF Register Prune Zone: Untrust Proxy register : (10.10.10.1, 238.1.1.1) of zone Trust Upstream : ethernet1/1 State : Joined RPF Neighbor : local Expires : - Downstream : ethernet1/2 0:06:24/- Join 236.1.1.1 20.20.20.200 FC

Configuración de una ruta multicast estáticaPuede definir una ruta multicast estática desde un origen a un grupo multicast (S, G) o utilizar comodines tanto para el origen como para el grupo multicast, o para ambos. Las rutas multicast estáticas se utilizan típicamente para admitir el reenvío de datos multicast desde hosts pertenecientes a interfaces en modo “proxy de enrutador IGMP” a los enrutadores en sentido ascendente de las interfaces en el modo host de IGMP. (Para obtener más información, consulte “Proxy de IGMP” en la página 173). También puede utilizar rutas multicast estáticas para permitir el reenvío multicast entre dominios. Puede crear una ruta estática para una pareja (S, G) con cualquier interfaz de entrada o de salida. También puede crear una ruta estática y definir mediante comodines el origen o el grupo multicast, o ambos, indicando 0.0.0.0. Al configurar una ruta estática, también puede especificar la dirección del grupo multicast original y una dirección diferente para el grupo multicast en la interfaz saliente.

En este ejemplo configurará una ruta multicast estática desde un origen con la dirección IP 20.20.20.200 hasta el grupo multicast 238.1.1.1. Configure el dispositivo de seguridad para traducir el grupo multicast de 238.1.1.1 a 238.2.2.1 en la interfaz saliente.

WebUI

Network > Routing > MCast Routing > New: Introduzca los siguientes datos y haga clic en OK:

Source IP: 20.20.20.200MGroup: 238.1.1.1Incoming Interface: ethernet1 (seleccione)Outgoing Interface: ethernet3(seleccione)Translated MGroup: 238.2.2.1



CLI

set vrouter trust-vr mroute mgroup 238.1.1.1 source 20.20.20.200 iif ethernet1 oif ethernet3 out-group 238.2.2.1

save

Listas de accesoUna lista de acceso es una lista de una secuencia de declaraciones con la que se compara la ruta. Cada declaración especifica la dirección/máscara IP de un prefijo de red y el estado de reenvío (acepta o rechaza la ruta). En el enrutamiento multicast, una instrucción también puede contener una dirección de grupo multicast. En el enrutamiento multicast, usted crea listas de acceso para permitir el tráfico multicast a determinados grupos o hosts multicast. Por lo tanto, el estado de la acción o del reenvío siempre es Permit. No se pueden crear listas de acceso para denegar el acceso a determinados grupos o hosts. (Para obtener información adicional sobre listas de acceso, consulte “Configuración de una lista de acceso” en la página 41.)

Configurar Encapsulado de enrutamiento genérico en interfaces de túnelEl encapsulado de paquetes multicast en paquetes unicast es un método común para transmitir paquetes multicast a través de una red no preparada para multicast y a través de túneles IPSec. La versión 1 del protocolo de Encapsulado de enrutamiento genérico (GRE) es un mecanismo que encapsula cualquier tipo de paquete dentro de paquetes unicast IPv4. Los dispositivos de seguridad de Juniper Networks admiten GREv1 para encapsular paquetes IP en paquetes unicast IPv4. Para obtener información adicional sobre GRE, consulte RFC 1701, Encapsulado de enrutamiento genérico (GRE).

En los dispositivos de seguridad, usted habilita la encapsulación GRE en interfaces de túnel.

Si desea transmitir paquetes multicast a través de un túnel VPN IPSec entre un dispositivo de seguridad de Juniper Networks y un dispositivo o enrutador de otro fabricante, debe habilitar GRE.

Los dispositivos de seguridad tienen limitaciones específicas de cada plataforma en cuanto al número de interfaces salientes a través de las cuales se pueden transmitir paquetes multicast. En grandes entornos de VPN radiales (“hub-and-spoke” o “cubo y radios”), en los que el dispositivo de seguridad es el cubo, se puede evitar esta limitación al crear un túnel GRE entre el enrutador de sentido ascendente del dispositivo de seguridad situado en el “cubo” y los dispositivos de seguridad situados en los radios.

NOTA: Puede habilitar GRE en una interfaz de túnel asociada a una interfaz de bucle invertido, siempre que la interfaz de bucle invertido se encuentre en la misma zona que la interfaz saliente. Para obtener información sobre las interfaces de bucle invertido, consulte “Interfaces de bucle invertido” en la página 2-57.

Enrutamiento multicast en dispositivos de seguridad 161


162

En la Figura 23, el enrutador-A se encuentra en sentido ascendente con respecto al dispositivo-A. El enrutador-A tiene dos túneles GRE que terminan en el dispositivo-1 y dispositivo-2. El dispositivo-A está conectado al dispositivo-1 y al dispositivo-2 a través de túneles VPN. Antes de que el enrutador-A transmita paquetes multicast, primero los encapsula en paquetes unicast IPv4. El dispositivo-A recibe estos paquetes como paquetes unicast y los envía al dispositivo-1 y al dispositivo-2.

Figura 23: GRE en interfaces de túnel

En este ejemplo, configurará la interfaz de túnel en el dispositivo-1. Realizará los pasos siguientes:

1. Crear la interfaz tunnel.1 y asociarla a ethernet3 y a la zona Untrust en trust-vr.

2. Habilitar la encapsulación de GRE en el tunnel.1.

3. Especificar los puntos terminales local y remoto del túnel GRE.

Este ejemplo muestra la configuración de GRE solamente para el dispositivo de seguridad. (Para obtener información sobre las VPN, consulte el Volume 5: Virtual Private Networks).

Receptores Receptores

Dispositivo-2

Túneles VPN con GRE

Túneles GRE

Enrutador-A

Internet

Origen

Dispositivo-1



WebUI

Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos, luego haga clic en Apply:

Tunnel Interface Name: tunnel.1Zone (VR): Untrust (trust-vr)Unnumbered: (seleccione)Interface: ethernet3 (trust-vr)

Network > Interfaces > Tunnel (tunnel.1): Introduzca los siguientes datos, luego haga clic en Apply:

Encap: GRE (seleccione)Local Interface: ethernet3Destination IP: 3.3.3.1

CLI

set interface tunnel.1 zone untrustset interface tunnel.1 ip unnumbered interface ethernet3set interface tunnel.1 tunnel encap greset interface tunnel.1 tunnel local-if ethernet3 dst-ip 3.3.3.1save

Directivas multicast

De forma predeterminada, los dispositivos de seguridad de Juniper Networks no permiten que el tráfico de control multicast, como mensajes IGMP o PIM, pase por los dispositivos de seguridad. Para permitir tráfico de control multicast entre las zonas, debe configurar una directiva multicast que especifique lo siguiente:

Origen: La zona desde la que se inicia el tráfico

Destino: La zona a la que se envía el tráfico

Grupo Multicast: El grupo multicast cuyo tráfico de control multicast desea que el dispositivo de seguridad permita. Puede especificar uno de los siguientes:

La dirección IP del grupo multicast

Una lista de accesos que defina a los grupos multicast a los que los hosts pueden unirse

La palabra clave any, para permitir el tráfico de control multicast para cualquier grupo multicast

Tráfico de control multicast: El tipo de mensaje de control multicast: mensajes IGMP o mensajes PIM. (Para obtener información sobre IGMP, consulte “Protocolo de administración de grupos de Internet” en la página 165. Para obtener información sobre PIM, consulte “Multicast independiente de protocolo” en la página 191.)

Directivas multicast 163


164

Además, puede especificar lo siguiente:

Dirección multicast traducida: El dispositivo de seguridad puede traducir una dirección del grupo multicast de una zona interna a una dirección distinta en la interfaz de salida. Para traducir una dirección de grupo, debe especificar tanto la dirección multicast original como la dirección del grupo multicast traducida en la directiva multicast.

Bi-direccional: Puede crear una directiva bidireccional para aplicarla a ambos sentidos del tráfico.

No ordene directivas multicast como haría con las directivas de cortafuegos. De este modo, la directiva multicast más reciente no sobrescribe ninguna anterior en caso de conflicto. En lugar de ello, el dispositivo de seguridad selecciona la coincidencia más larga para resolver cualquier conflicto, igual que hacen otros protocolos de enrutamiento. Si encuentra una subred más pequeña que cumpla el criterio de consulta, utilizará esa directiva.

NOTA: Las directivas multicast solamente controlan el flujo del tráfico de control de multicast. Para permitir el paso del tráfico de datos (tanto unicast como multicast) entre las zonas, debe configurar directivas de cortafuegos. (Para obtener información sobre las directivas, consulte el Volumen 2: Fundamentos).

NOTA: Para ver un ejemplo de configuración de una directiva multicast para mensajes IGMP, consulte “Creación de una directiva de grupo multicast para IGMP” en la página 178. Para ver un ejemplo de configuración de una directiva multicast para mensajes PIM, consulte “Definición de una directiva de grupo multicast para PIM-SM” en la página 201.

Directivas multicast

Capítulo 8

Protocolo de administración de grupos de Internet

Este capítulo describe el protocolo multicast para administración de grupos de Internet (IGMP) en dispositivos de seguridad de Juniper Networks. Incluye las siguientes secciones:


“Hosts” en la página 166

“Enrutadores multicast” en la página 167

“IGMP en dispositivos de seguridad” en la página 167

“Habilitación e inhabilitación de IGMP en interfaces” en la página 167

“Configuración de una lista de accesos para grupos aceptados” en la página 168

“Configuración de IGMP” en la página 169

“Verificación de una configuración de IGMP” en la página 171

“Parámetros operativos de IGMP” en la página 172

“Proxy de IGMP” en la página 173

“Configuración del proxy de IGMP” en la página 176

“Configuración de un proxy de IGMP en una interfaz” en la página 176

“Directivas multicast para configuraciones de IGMP y proxy de IGMP” en la página 178

“Configuración de un proxy de remitente de IGMP” en la página 185

165


166

Vista general

El protocolo multicast para administración de grupos de Internet (IGMP) se utiliza entre hosts y enrutadores para establecer y mantener miembros de grupos multicast en una red. Los dispositivos de seguridad admiten las siguientes versiones de IGMP:

IGMPv1, según lo definido en la norma RFC 1112, Extensiones de host para multicast IP, define las operaciones básicas para miembros de grupos multicast.

IGMPv2, según lo definido en la norma RFC 2236, Protocolo de administración de grupos de Internet, versión 2, amplía la funcionalidad de IGMPv1.

IGMPv3, según lo definido en la norma RFC 3376, Protocolo de administración de grupos de Internet, Versión 3, permite la filtración de orígenes. Los hosts que ejecutan IGMPv3 indican a qué grupos multicast desean unirse y desde qué orígenes esperan recibir tráfico multicast. IGMPv3 es necesario para ejecutar multicast independiente de protocolo en modo de origen específico (PIM-SSM). (Para obtener más información, consulte “PIM-SSM” en la página 197).

El protocolo IGMP proporciona un mecanismo para que hosts y enrutadores puedan mantener los miembros de grupos multicast. Los protocolos de enrutamiento multicast, como PIM, procesan la información de miembros IGMP, crean entradas en la tabla de enrutamiento multicast y reenvían el tráfico multicast a los hosts a través de la red.

Las secciones siguientes explican los diversos tipos de mensajes IGMP que hosts y enrutadores intercambian para mantener actualizada la información de miembro de grupos a través de la red. Los hosts y los enrutadores que ejecutan versiones más recientes de IGMP pueden funcionar con los que ejecuten versiones de IGMP anteriores.

HostsLos hosts envían mensajes IGMP para unirse a grupos multicast y mantenerse como miembros en esos grupos. Los enrutadores aprenden qué hosts son miembros de grupos multicast al escuchar estos mensajes IGMP en sus redes locales. La Tabla 16 enumera los mensajes de IGMP que los hosts envían y el destino de los mensajes.

Tabla 16: Mensajes de host IGMP

Versión de IGMP Mensaje de IGMP Destino

IGMPv1 y v2 Un host envía un informe de miembro la primera vez que se une a un grupo multicast y periódicamente, una vez que ya es miembro del grupo. El informe de miembros indica a qué grupo multicast desea unirse el host.

Dirección IP del grupo multicast al que el host desea unirse

IGMPv3 Un host envía un informe de miembro la primera vez que se une a un grupo multicast y periódicamente, una vez que ya es miembro del grupo. El informe de miembro contiene la dirección multicast del grupo, el modo de filtración, que es incluir o excluir y una lista de orígenes. Si el modo de filtración es incluir, entonces los paquetes procedentes de las direcciones de la lista de origen se aceptan. Si el modo de filtración es excluir, entonces los paquetes procedentes de orígenes distintos a los de la lista de origen se aceptan.

224.0.0.22

IGMPv2 Un host envía un mensaje Leave group cuando desea dejar el grupo multicast y dejar de recibir datos para ese grupo.

“grupo de todos los enrutadores” (224.0.0.2)

Vista general

Capítulo 8: Protocolo de administración de grupos de Internet

Enrutadores multicastLos enrutadores utilizan IGMP para aprender qué grupos multicast tienen miembros en su red local. Cada red selecciona un enrutador designado, denominado el consultador. Generalmente, hay un consultador para cada red. El consultador envía mensajes IGMP a todos los hosts de la red para solicitar información de miembros de grupo. Cuando los hosts responden con sus informes de miembros, los enrutadores toman la información de estos mensajes y actualizan su lista de miembros de grupos basándose en cada interfaz. Los enrutadores IGMPv3 mantienen una lista que incluye la dirección del grupo multicast, el modo de filtración (incluir o excluir) y la lista de orígenes.

La Tabla 17 describe los mensajes que un contestador envía y los destinos.

Tabla 17: Mensajes del consultador IGMP

IGMP en dispositivos de seguridad

En algunos enrutadores, IGMP se habilita automáticamente cuando habilita un protocolo de enrutamiento multicast. En los dispositivos de seguridad de Juniper Networks, debe habilitar explícitamente IGMP y un protocolo de enrutamiento multicast.

Habilitación e inhabilitación de IGMP en interfacesDe forma predeterminada, IGMP está desactivado en todas las interfaces. Debe habilitar IGMP en el modo de enrutador en todas las interfaces que estén conectadas a hosts. En el modo de enrutador, el dispositivo de seguridad ejecuta IGMPv2 de forma predeterminada. Puede cambiar el ajuste predeterminado y ejecutar IGMPv1, IGMPv2 y v3 o solamente IGMPv3.

NOTA: Con IGMPv1, cada protocolo de enrutamiento multicast determina el consultador de una red. Con IGMPv2 y v3, el consultador es la interfaz de enrutador con la dirección IP más baja de la red.

Versión de IGMP Mensaje de IGMP Destino

IGMPv1, v2 y v3

El consultador envía periódicamente consultas generales para solicitar la información de miembros de grupos.

grupo de “todos los hosts” (224.0.0.1).

IGMPv2 y v3 El consultador envía una consulta específica de grupo cuando recibe un mensaje Leave Group de IGMPv2 o un informe de miembros IGMPv3 que indique un cambio en los miembros del grupo. Si el consultador no recibe ninguna respuesta en un plazo especificado, asume que no hay miembros para ese grupo en su red local y deja de reenviar el tráfico multicast a ese grupo.

El grupo multicast del que va a salir el host.

IGMPv3 El consultador envía una consulta específica de grupo y origen para verificar si hay algún receptor para ese grupo y origen específico.

El grupo multicast del que va a salir el host.

IGMP en dispositivos de seguridad 167


168

Habilitación de IGMP en una interfazEn este ejemplo, habilita IGMP en modo enrutador en la interfaz ethernet1 que está conectada con un host.

WebUI

Network > Interfaces > Edit (para ethernet1) > IGMP: Introduzca los siguientes datos, luego haga clic en Apply:

IGMP Mode: Router (seleccione)Protocol IGMP: Enable (seleccione)

CLI

set interface ethernet1 protocol igmp routerset interface ethernet1 protocol igmp enablesave

Desactivación de IGMP en una interfazEn este ejemplo, desactivará IGMP en la interfaz ethernet1. El dispositivo de seguridad mantiene la configuración de IGMP, pero la desactiva.

WebUI

Network > Interfaces > Edit (para ethernet1) > IGMP: Clear Protocol IGMP Enable, luego haga clic en Apply.

CLI

unset interface ethernet1 protocol igmp enablesave

Para borrar la configuración de IGMP introduzca el comando unset interface interfaz protocol igmp router.

Configuración de una lista de accesos para grupos aceptadosHay algunos problemas de seguridad que debe tener en cuenta al ejecutar IGMP. Los usuarios maliciosos pueden falsificar consultas IGMP, informes de miembros y dejar mensajes. En los dispositivos de seguridad, puede restringir el tráfico multicast sólo a los hosts y grupos multicast conocidos. Además, también puede especificar los consultadores permitidos en su red. Estas restricciones se establecen por medio de la creación de listas de accesos y su aplicación a una interfaz.

Una lista de acceso es una secuencia de declaraciones que especifica una dirección IP y un estado de reenvío (permit o deny). En IGMP, las listas de accesos siempre deben tener un estado de reenvío permit y deben especificar uno de los siguientes:

Grupos multicast a los que los hosts se pueden unir

Hosts desde los que la interfaz del enrutador IGMP puede recibir mensajes IGMP

Consultadores desde los que la interfaz del enrutador de IGMP puede recibir mensajes IGMP



Después de crear una lista de accesos, aplíquela a una interfaz. Una vez que aplique una lista de accesos a una interfaz, ésta aceptará tráfico solamente de los orígenes especificados en la lista de accesos. Por lo tanto, para denegar tráfico procedente de un determinado grupo, host o consultador multicast, simplemente exclúyalo de la lista de accesos. (Para obtener información adicional sobre listas de accesos, consulte “Configuración de una lista de acceso” en la página 41).

En este ejemplo, creará una lista de acceso en el trust-vr. La lista de accesos especifica lo siguiente:

La identificación de la lista de accesos es 1.

Permitir el tráfico a un grupo multicast 224.4.4.1/32.

El número secuencial de esta declaración es 1.

Después de crear la lista de accesos, permita que los hosts de ethernet1 se unan al grupo multicast especificado en la lista de accesos.

WebUI



Network > Interfaces > Edit (para ethernet1) > IGMP: Introduzca los siguientes datos y haga clic en OK:

Accept Group’s Access List ID: 1

CLI

set vrouter trust-vr access-list 1 permit ip 224.4.4.1/32 1set interface ethernet1 protocol igmp accept groups 1save

Configuración de IGMPPara ejecutar IGMP en un dispositivo de seguridad de Juniper Networks, simplemente habilítelo en modo enrutador en las interfaces que están conectadas directamente a los hosts. Para garantizar la seguridad de la red, utilice las listas de accesos para limitar el tráfico multicast sólo a grupos, hosts y enrutadores multicast conocidos.

En la Figura 24, los hosts de la zona Trust protegida por el dispositivo de seguridad NS1 son receptores potenciales del flujo multicast procedente del origen en la zona Untrust. Las interfaces ethernet1 y ethernet2 están conectadas a los hosts. El origen multicast está transmitiendo datos al grupo multicast 224.4.4.1. Realice los pasos siguientes para configurar IGMP en las interfaces que están conectadas a los hosts:

1. Asigne direcciones IP a las interfaces y enlácelas a zonas.

2. Cree una lista de accesos que especifique el grupo multicast 224.4.4.1/32.



170

3. Habilite IGMP en modo enrutador en ethernet1 y ethernet2.

4. Restrinja las interfaces (ethernet1 y ethernet2) para que reciban mensajes IGMP del grupo multicast 224.4.4.1/32.

Figura 24: Ejemplo de configuración de IGMP

WebUI

1. Zonas e interfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en OK:

Zone Name: TrustIP Address/Netmask: 10.1.1.1/24

Network > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK:



Zone Name: UntrustIP Address/Netmask: 1.1.1.1/24

2. Lista de accesosNetwork > Routing > Virtual Routers > Access List: > New (para el trust-vr): Introduzca los siguientes datos y haga clic en OK:

Access List ID: 1Sequence No.: 1IP/Netmask: 224.4.4.1/32

Action: Permit

Origen

ethernet1 10.1.1.1/24

ethernet 2 10.1.2.1/24

ethernet3 1.1.1.1/24

Enrutador designado de origen

Zona Untrust

NS1

Zona Trust



3. IGMPNetwork > Interfaces > Edit (para ethernet1) > IGMP: Introduzca los siguientes datos, luego haga clic en Apply:

IGMP Mode: Router (seleccione)Protocol IGMP: Enable (seleccione)Accept Group’s Access List ID: 1


IGMP Mode: Router (seleccione)Protocol IGMP: Enable (seleccione)Accept Group’s Access List ID: 1

CLI

1. Zonas e interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.1.1/24set interface ethernet2 zone trustset interface ethernet2 ip 10.2.1.1/24

2. Lista de accesosset vrouter trust access-list 1 permit ip 224.4.4.1/32 1

3. IGMPset interface ethernet1 protocol igmp routerset interface ethernet1 protocol igmp accept groups 1set interface ethernet1 protocol igmp enableset interface ethernet2 protocol igmp routerset interface ethernet2 protocol igmp accept groups 1set interface ethernet2 protocol igmp enablesave

Después de configurar IGMP en ethernet1 y ethernet2, debe configurar un protocolo de enrutamiento multicast, como PIM, para reenviar el tráfico multicast. (Para obtener información sobre PIM, consulte “Multicast independiente de protocolo” en la página 191).

Verificación de una configuración de IGMPPara verificar la conectividad y asegurarse de que IGMP se esté ejecutando correctamente, existe una serie de comandos exec y get que puede utilizar.

Para enviar consultas generales o específicas de grupos a una interfaz en particular, utilice el comando exec igmp interface interfaz query. Por ejemplo, para enviar una consulta general desde ethernet2, introduzca el siguiente comando:

exec igmp interface ethernet2 query

Para enviar una consulta específica de grupo desde ethernet2 al grupo multicast 224.4.4.1, introduzca el siguiente comando:

exec igmp interface ethernet2 query 224.4.4.1



172

Para enviar un informe de miembros de una interfaz en particular, utilice el comando exec igmp interface interfaz report. Por ejemplo, para enviar un informe de miembro desde ethernet2, introduzca el siguiente comando:

exec igmp interface ethernet2 report 224.4.4.1

Puede revisar los parámetros IGMP de una interfaz al introducir el comando siguiente:

device-> get igmp interfaceInterface trust support IGMP version 2 router. It is enabled.IGMP proxy is disabled.Querier IP is 10.1.1.90, it has up 23 seconds. I am the querier.There are 0 multicast groups active. Inbound Router access list number: not set Inbound Host access list number: not set Inbound Group access list number: not set query-interval: 125 segundos query-max-response-time 10 seconds leave-interval 1 seconds last-member-query-interval 1 seconds

Este resultado enumera la siguiente información:

IGMP versión (2)

Estado del consultador (yo soy el consultador.)

Set and unset parameters

Para mostrar información sobre grupos multicast, ejecute el siguiente comando CLI:

device-> get igmp group

total groups matched: 1multicast group interface last reporter expire ver*224.4.4.1 trust 0.0.0.0 ------ v2

Parámetros operativos de IGMPCuando habilita IGMP en modo de enrutador en una interfaz, la interfaz se inicia como consultador. Como consultador, la interfaz utiliza determinados ajustes predeterminados que usted puede modificar. Cuando establece parámetros en este nivel, solamente resulta afectada la interfaz que se haya especificado. La Tabla 18 enumera los parámetros de interfaz del consultador de IGMP y sus valores predeterminados.



Tabla 18: Parámetros de la interfaz del consultador de IGMP y valores predeterminados

De forma predeterminada, un enrutador habilitado para IGMPv2/v3 solamente acepta paquetes IGMP con la opción router-alert IP y descarta los paquetes que no tienen esta opción. Los paquetes IGMPv1 no tienen esta opción y, por lo tanto, un dispositivo de seguridad que ejecuta IGMPv2/v3 descarta los paquetes IGMPv1 de forma predeterminada. Puede configurar el dispositivo de seguridad para dejar de comprobar si los paquetes IGMP contienen la opción router-alert IP y aceptar todos los paquetes IGMP, haciéndolo compatible con versiones anteriores de enrutadores IGMPv1. Por ejemplo, para permitir que la interfaz ethernet1 acepte todos los paquetes IGMP:

WebUI

Network > Interfaces > Edit (para ethernet1) > IGMP: Seleccione los siguientes datos y haga clic en OK:

Packet Without Router Alert Option: Permit (seleccione)

CLI

set interface ethernet1 protocol igmp no-check-router-alertsave

Proxy de IGMP

Los enrutadores esperan y envían mensajes IGMP sólo a sus hosts conectados; no reenvían mensajes IGMP más allá de su red local. Puede permitir que las interfaces de un dispositivo de seguridad de Juniper Networks reenvíen mensajes IGMP un salto más allá de su red local habilitando el proxy de IGMP. El proxy de IGMP permite a las interfaces reenviar mensajes IGMP en sentido ascendente hacia el origen sin sobrecargar la CPU con un protocolo de enrutamiento multicast.

Cuando ejecuta un proxy IGMP en un dispositivo de seguridad, las interfaces conectadas a hosts funcionan como enrutadores y aquellas conectadas a enrutadores en sentido ascendente funcionan como hosts. Las interfaces de host y enrutador generalmente están en zonas diferentes. Para permitir que los mensajes de IGMP pasen entre zonas, debe configurar una directiva multicast. Luego, para permitir que el tráfico de datos multicast pase entre zonas, también debe configurar una directiva de cortafuegos.

Parámetros de la interfaz IGMP Descripción


General query interval El intervalo en el cual la interfaz consultadora envía consultas generales al grupo de “todos los hosts” (224.0.0.1).

125 segundos

Maximum response time

El tiempo máximo entre una consulta general y la respuesta procedente del host.

10 segundos

Last Member Query Interval

El intervalo en el que la interfaz envía una consulta específica de grupo. Si no recibe ninguna respuesta después de la segunda consulta específica de grupo, asume que no hay más miembros en ese grupo en su red local.

1 segundo

Proxy de IGMP 173


174

En los dispositivos que admiten múltiples sistemas virtuales, debe configurar una interfaz en el sistema virtual raíz (vsys) y la otra interfaz en vsys separados. A continuación, cree una directiva multicast para permitir tráfico de control multicast entre los dos sistemas virtuales. (Para obtener más información sobre los sistemas virtuales, consulte el Volumen 10: Sistemas virtuales.)

Mientras las interfaces reenvían información de miembros IGMP, crean entradas en la tabla de rutas multicast del enrutador virtual al que están asociadas, formando un árbol de distribución multicast desde los receptores hasta el origen. Las siguientes secciones describen cómo las interfaces de hosts y enrutadores IGMP reenvían la información de miembros de IGMP en sentido ascendente hacia el origen, y cómo reenvían datos multicast en sentido descendente desde el origen hasta el receptor.

Informes de miembros en sentido ascendente hacia el origenCuando un host conectado a una interfaz de enrutador en un dispositivo de seguridad se une a un grupo multicast, envía un informe de miembros al grupo multicast. Cuando la interfaz del enrutador recibe el informe de miembros del host que se acaba de conectar, comprueba si tiene una entrada para el grupo multicast. A continuación, el dispositivo de seguridad lleva a cabo una de las acciones siguientes:

Si la interfaz del enrutador tiene una entrada para el grupo multicast, ignora el informe de miembros.

Si la interfaz del enrutador no tiene ninguna entrada para el grupo multicast, comprueba si hay una directiva multicast para el grupo que especifique a qué zona la interfaz del enrutador debe enviar el informe.

Si no hay ninguna directiva multicast para el grupo, la interfaz del enrutador no reenvía el informe.

Si hay alguna directiva multicast para el grupo, la interfaz del enrutador crea una entrada para el grupo multicast y reenvía el informe de miembros a la interfaz del host proxy en la zona especificada en la directiva multicast.

Cuando una interfaz del host proxy recibe el informe de miembros, comprueba si tiene una entrada (*, G) para ese grupo multicast.

Si tiene una entrada (*, G) para el grupo, la interfaz del host agrega la interfaz del enrutador a la lista de las interfaces de salida para esa entrada.

Si no contiene ninguna entrada (*, G) para ese grupo, la crea; la interfaz de entrada es la interfaz del host proxy y la interfaz de salida es la interfaz del enrutador. A continuación, la interfaz del host proxy reenvía el informe a su enrutador en sentido ascendente.

Proxy de IGMP


Datos multicast en sentido descendente a los receptoresCuando la interfaz del host en el dispositivo de seguridad recibe datos multicast para un grupo multicast, comprueba si hay una sesión existente para ese grupo.

Si hay una sesión para el grupo, la interfaz reenvía los datos multicast basándose en la información de la sesión.

Si no hay sesión para el grupo, la interfaz comprueba si el grupo tiene una entrada (S, G) en la tabla de rutas multicast.

Si hay una entrada (S, G), la interfaz reenvía los datos multicast en consecuencia.

Si no hay ninguna entrada (S, G), la interfaz comprueba si hay alguna entrada (*, G) para el grupo.

Si no hay ninguna entrada (*, G) para el grupo, la interfaz descarta el paquete.

Si no hay ninguna entrada (*, G) para el grupo, la interfaz crea una entrada (S, G). Cuando la interfaz recibe paquetes multicast subsiguientes para ese grupo, reenvía el tráfico a la interfaz del enrutador (la interfaz de salida) que, a su vez, reenvía el tráfico a su host conectado.

La Figura 25 muestra un ejemplo de una configuración de host proxy de IGMP.

Figura 25: Configuración del host proxy de IGMP

3. La interfaz del host proxy de IGMP comprueba si tiene una entrada (*, G) para el grupo multicast:

• En caso afirmativo, agrega la interfaz del enrutador a las interfaces salientes en una entrada multicast de la tabla de rutas.

• En caso negativo, crea la entrada y reenvía el informe de miembros al enrutador en sentido ascendente.

2. La interfaz del enrutador proxy de IGMP comprueba si hay alguna entrada para el grupo multicast:

• En caso afirmativo, ignora el informe de miembros.

• En caso negativo y si no hay ninguna directiva multicast para el grupo, descarta el informe de miembros.

• En caso negativo, pero si existe alguna directiva multicast para el grupo, crea una entrada (*, G) en la tabla de rutas multicast, con el host como iif y el enrutador como oif. Reenvía el informe en sentido ascendente hacia la interfaz del host en la zona especificada en la directiva multicast.

1. Los hosts envían informes de miembros en sentido ascendente.

4. El origen envía datos multicast en sentido descendente hacia el receptor.

5. La interfaz del host proxy de IGMP comprueba si existe alguna sesión para el grupo:

• En caso afirmativo, reenvía los datos multicast.

• En caso negativo, compruebe si hay alguna entrada (S, G) para el grupo:

• En caso afirmativo, reenvía los datos multicast.

• En caso negativo, compruebe si hay alguna entrada (*, G):

• En caso negativo, descarta los datos.

• En caso afirmativo, crea una entrada (S, G) y reenvía datos utilizando la interfaz de entrada y de salida desde la entrada (*, G).

6. La interfaz del enrutador proxy de IGMP reenvía datos a los receptores.

Origen

Interfaz del host proxy de IGMP

Enrutador designado de origen

Internet

Zona Trust

Zona Untrust

Interfaz del enrutador proxy de IGMP

Receptores

Proxy de IGMP 175


176

Configuración del proxy de IGMP En esta sección se describen los pasos básicos necesarios para configurar IGMP proxy en un dispositivo de seguridad de Juniper Networks:

1. Habilitar IGMP en el modo host en interfaces en sentido ascendente. De forma predeterminada, el proxy de IGMP está habilitado en las interfaces de hosts.

2. Habilitar IGMP en el modo enrutador en interfaces en sentido descendente.

3. Habilitar IGMP proxy en interfaces de enrutador.

4. Configurar una directiva multicast que permita que el tráfico de control multicast pase de una zona a otra.

5. Configurar una directiva para entregar tráfico de datos entre zonas.

Configuración de un proxy de IGMP en una interfazCuando ejecute IGMP proxy en un dispositivo de seguridad, la interfaz en sentido descendente se configura en modo enrutador y la interfaz en sentido ascendente en modo host. (Observe que una interfaz puede estar en modo host o en modo enrutador, pero no en ambos). Además, para que una interfaz de enrutador reenvíe el tráfico multicast, debe ser el consultador en la red local. Para permitir que una interfaz no consultadora reenvíe el tráfico multicast, debe especificar la palabra clave always al habilitar IGMP en la interfaz.

De forma predeterminada, una interfaz IGMP sólo acepta los mensajes IGMP de su propia subred. Ignora los mensajes IGMP procedentes de orígenes externos. Debe habilitar el dispositivo de seguridad para que acepte mensajes IGMP procedentes de orígenes de otras subredes cuando ejecute IGMP proxy.

En este ejemplo, la interfaz ethernet1 tiene la dirección IP 10.1.2.1/24 y está conectada al enrutador en sentido ascendente. Configure lo siguiente en ethernet1:

Habilite IGMP en el modo host

Permita que acepte mensajes IGMP desde todos los orígenes, sin importar la subred

La interfaz ethernet3 tiene la dirección IP 10.1.1.1/24 y está conectada a los hosts. Configure lo siguiente en ethernet3:

Habilite IGMP en el modo enrutador.

Permita que reenvíe tráfico multicast aunque no sea un consultador.

Permita que acepte mensajes IGMP procedentes de orígenes de otras subredes.

Proxy de IGMP


WebUI

1. Zonas e interfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en OK:


Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos, luego haga clic en Apply:



IGMP Mode: Host (seleccione)Protocol IGMP: Enable (seleccione)Packet From Different Subnet: Permit (seleccione)


IGMP Mode: Router (seleccione)Protocol IGMP: Enable (seleccione)Packet From Different Subnet: Permit (seleccione)Proxy: (seleccione)Always (seleccione)

CLI

1. Zonas e interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.2.1/24set interface ethernet3 zone trustset interface ethernet1 ip 10.1.1.1/24

2. IGMPset interface ethernet1 protocol igmp hostset interface ethernet1 protocol igmp enableset interface ethernet1 protocol igmp no-check-subnetset interface ethernet3 protocol igmp routerset interface ethernet3 protocol igmp proxyset interface ethernet3 protocol igmp proxy alwaysset interface ethernet3 protocol igmp enableset interface ethernet3 protocol igmp no-check-subnetsave

Proxy de IGMP 177


178

Directivas multicast para configuraciones de IGMP y proxy de IGMPNormalmente, un dispositivo de seguridad intercambia mensajes IGMP sólo con sus hosts conectados. Con IGMP proxy, los dispositivos de seguridad podrían necesitar enviar mensajes IGMP a un host o a un enrutador en otra zona. Para permitir el envío de mensajes IGMP entre zonas, debe configurar una directiva multicast que lo permita específicamente. Cuando cree una directiva multicast, debe especificar lo siguiente:

Origen: La zona desde la que se inicia el tráfico

Destino: La zona a la que se envía el tráfico

Grupo multicast: Puede ser un grupo multicast, una lista de accesos que especifique grupos multicast o “any”

Además, puede especificar que la directiva sea bidireccional para aplicar la directiva a ambos sentidos del tráfico.

Creación de una directiva de grupo multicast para IGMPEn este ejemplo, la interfaz del enrutador se encuentra en la zona Trust y la interfaz del host en la zona Untrust. Defina una directiva multicast que permita que los mensajes IGMP para el grupo multicast 224.2.202.99/32 puedan pasar entre las zonas Trust y Untrust. Utilice la palabra clave bidirectional para permitir el tráfico en ambos sentidos.

WebUI

MCast Policies (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK:

MGroup Address: IP/Netmask (seleccione) 224.2.202.99/32Bidirectional: (seleccione)IGMP Message: (seleccione)

CLI

set multicast-group-policy from trust mgroup 224.2.202.99/32 to untrust igmp-message bi-directional

save

Creación de una configuración de proxy de IGMPComo se indica en la Figura 26, se configura IGMP proxy en los dispositivos de seguridad NS1 y NS2. Están interconectados a través de un túnel VPN. Realice los pasos siguientes en los dispositivos de seguridad de ambas ubicaciones:

1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas de seguridad.

2. Crear los objetos de direcciones.

Proxy de IGMP


3. Habilitar IGMP en las interfaces del host y del enrutador, y habilitar IGMP proxy en la interfaz del enrutador. (De forma predeterminada, IGMP proxy está habilitado en las interfaces de host).

a. Especificar la palabra clave always (siempre) en ethernet1 de NS1 para permitir que reenvíe el tráfico multicast aunque no sea consultador.

b. De forma predeterminada, una interfaz IGMP sólo acepta paquetes IGMP de su propia subred. En el ejemplo, las interfaces están en subredes diferentes. Cuando habilite IGMP, permita que las interfaces acepten paquetes IGMP (consultas, informes de miembros y mensajes leave) procedentes de cualquier subred.

4. Configurar las rutas.

5. Configurar el túnel VPN.

6. Configurar una directiva para transmitir tráfico de datos entre zonas.

7. Configurar una directiva multicast para entregar mensajes IGMP entre zonas. En este ejemplo, restringirá el tráfico multicast a un grupo multicast (224.4.4.1/32).

Figura 26: Configuración de IGMP proxy entre dos dispositivos

WebUI (NS1)

1. InterfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos, luego haga clic en Apply:

Zone Name: TrustStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 10.2.2.1/24Seleccione los siguientes datos y haga clic en OK:Interface Mode: NAT

Elementos relacionados con NSI

OrigenInternet

Enrutador designado

ethernet1 10.2.2.1/24

Zona Trust

Receptores

Zona TrustZona Untrust

Zona Untrust

Interfaz de túnel, tunnel.1



Interfaz de túnel, tunnel.1Túnel VPN

NS1

Elementos relacionados con NS2

ethernet1 10.3.1.1/24

NS2

Proxy de IGMP 179


180



Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos y haga clic en OK:

Tunnel Interface Name: tunnel.1Zone (VR): Untrust (trust-vr)Unnumbered: (seleccione)

Interface: ethernet3 (trust-vr)

2. DireccionesPolicy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:

Address Name: branchIP Address/Domain Name:




Network > Interfaces > Edit (para tunnel.1) > IGMP: Introduzca los siguientes datos, luego haga clic en Apply:

IGMP Mode: Router (seleccione)Protocol IGMP: Enable (seleccione)Packet From Different Subnet: Permit (seleccione)Proxy (seleccione): Always (seleccione)

4. RutasNetwork > Routing > Routing Entries > New: Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 10.3.1.0/24Gateway (seleccione):

Interface: tunnel.1 (seleccione)

5. VPNVPN > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK.

Gateway Name: To_BranchSecurity Level: CompatibleRemote Gateway Type:Static IP Address: (seleccione), IP Address/Hostname: 3.1.1.1Preshared Key: fg2g4h5jOutgoing Interface: ethernet3

Proxy de IGMP


>> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return para regresar a la página de configuración básica de puerta de enlace:

Security Level: CompatiblePhase 1 Proposal (para nivel de seguridad compatible): pre-g2-3des-shaMode (Initiator): Main (Protección de la identificación)

6. DirectivaPolicies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK:

Source Address: Address Book Entry: (seleccione), branch

Destination Address: Address Book Entry: (seleccione), any (seleccione)

Service: anyAction: Permit

7. Directiva multicastMCast Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK:

Mgroup Address: IP/Netmask (seleccione): 224.4.4.1/32Bidirectional: (seleccione)IGMP Message: (seleccione)

WebUI (NS2)

1. InterfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en OK:




Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos, luego haga clic en Apply:




Address Name: mgroup1IP Address/Domain Name:

IP/Netmask: (seleccione), 224.4.4.1/32Zone: Trust

Proxy de IGMP 181


182


Address Name: source-drIP Address/Domain Name:



IGMP Mode: Router (seleccione)Protocol IGMP: Enable (seleccione)Proxy (seleccione): Always (seleccione)

Network > Interfaces > Edit (para tunnel.1) > IGMP: Introduzca los siguientes datos, luego haga clic en Apply:


4. RutasNetwork > Routing > Routing Entries > New (trust-vr): Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 10.2.2.0/24Gateway (seleccione):

Interface: tunnel.1 (seleccione)

5. VPNVPN > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK:

Gateway Name: To_CorpSecurity Level: CompatibleRemote Gateway Type:Static IP Address: (seleccione), IP Address/Hostname: 1.1.1.1Preshared Key: fg2g4hvjOutgoing Interface: ethernet3

> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return para regresar a la página de configuración básica de puerta de enlace:


Proxy de IGMP



Source Address: Address Book Entry: (seleccione), source-dr

Destination Address: Address Book Entry: (seleccione), mgroup1

Service: ANYAction: Permit

7. Directiva multicastMCast Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK:


CLI (NS1)

1. Interfaces Set interface ethernet1 zone trustset interface ethernet1 ip 10.2.2.1/24set interface ethernet3 zone untrust set interface ethernet3 ip 2.2.2.2/24set interface tunnel.1 zone untrustset interface tunnel.1 ip unnumbered interface ethernet3

2. Direccionesset address untrust branch1 10.3.1.0/24

3. IGMPset interface ethernet1 protocol igmp hostset interface ethernet1 protocol igmp enableset interface ethernet1 protocol igmp no-check-subnetset interface tunnel.1 protocol igmp routerset interface tunnel.1 protocol igmp proxyset interface tunnel.1 protocol igmp proxy alwaysset interface tunnel.1 protocol igmp enableset interface tunnel.1 protocol igmp no-check-subnet

4. Rutasset route 10.3.1.0/24 interface tunnel.1

5. Túnel VPNset ike gateway To_Branch address 3.1.1.1 main outgoing-interface ethernet3

preshare fg2g4h5j proposal pre-g2-3des-shaset vpn Corp_Branch gateway To_Branch sec-level compatibleset vpn Corp_Branch bind interface tunnel.1set vpn Corp_Branch proxy-id local-ip 10.2.2.0/24 remote-ip 10.3.1.0/24 any

6. Directivasset policy name To_Branch from untrust to trust branch1 any any permit

Proxy de IGMP 183


184

7. Directivas multicastset multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust

igmp-message bi-directionalsave

CLI (NS2)


2. Direccionesset address trust mgroup1 224.4.4.1/32set address untrust source-dr 10.2.2.1/24

3. IGMPset interface ethernet1 protocol igmp routerset interface ethernet1 protocol igmp proxy set interface ethernet1 protocol igmp proxy alwaysset interface ethernet1 protocol igmp enableset interface tunnel.1 protocol igmp hostset interface tunnel.1 protocol igmp enableset interface tunnel.1 protocol igmp no-check-subnet

4. Rutasset route 10.2.2.0/24 interface tunnel.1

5. Túnel VPNset ike gateway To_Corp address 2.2.2.2 main outgoing-interface ethernet3

preshare fg2g4hvj proposal pre-g2-3des-shaset vpn Branch_Corp gateway To_Corp sec-level compatibleset vpn Branch_Corp bind interface tunnel.1set vpn Branch_Corp proxy-id local-ip 10.3.1.0/24 remote-ip 10.2.2.0/24 any

6. Directivaset policy from untrust to trust source-dr mgroup1 any permit

7. Directiva multicastset multicast-group-policy from untrust mgroup 224.4.4.1/32 to trust


Proxy de IGMP


Configuración de un proxy de remitente de IGMPEn IGMP proxy, el tráfico multicast generalmente viaja en sentido descendente desde la interfaz del host a la interfaz del enrutador. En determinadas situaciones, el origen puede estar en la misma red que la interfaz del enrutador. Cuando un origen se conecta a una interfaz que se encuentra en la misma red a la que la interfaz del proxy del enrutador IGMP envía tráfico multicast, el dispositivo de seguridad comprueba si hay lo siguiente:

Una directiva del grupo multicast que permite el tráfico desde la zona de origen a la zona de la interfaz del host IGMP proxy

Una lista de accesos de los orígenes aceptables

Si no hay ninguna directiva multicast entre la zona de origen y la zona de la interfaz IGMP proxy o si el origen no se encuentra en la lista de orígenes aceptables, el dispositivo de seguridad descarta el tráfico. Si existe una directiva multicast entre la zona de origen y la zona de la interfaz IGMP proxy, y el origen aparece en la lista de orígenes aceptables, el dispositivo crea una entrada (S, G) para esa interfaz en la tabla de rutas multicast; la interfaz entrante es la interfaz a la que el origen está conectado y la interfaz saliente es la interfaz del host IGMP proxy. Luego, el dispositivo de seguridad envía los datos en sentido ascendente a la interfaz del host IGMP proxy, que envía los datos a todas sus interfaces de enrutador proxy conectadas, salvo a la interfaz conectada con el origen.

La Figura 27 muestra un ejemplo del proxy de remitente de IGMP.

Figura 27: Proxy de remitente de IGMP

ethernet2Internet

ethernet1

Tabla de rutas multicastiff = ethernet2oif = ethernet3 Origen

Receptores

tráfico multicast

La interfaz del IGMP proxy de ethernet envía tráfico multicast a todas las interfaces de enrutador proxy

Receptores

Proxy de IGMP 185


186

En la Figura 28, el origen está conectado a la interfaz ethernet2, enlazada a la zona DMZ en NS2. Está enviando tráfico multicast al grupo multicast 224.4.4.1/32. Hay receptores conectados a la interfaz ethernet1 enlazada a la zona Trust en NS2. Tanto ethernet1 como ethernet2 son interfaces de enrutador IGMP proxy. La interfaz ethernet3 asociada a la zona Untrust de NS2 es una interfaz de host de IGMP proxy. También hay receptores conectados a la interfaz ethernet1 enlazada a la zona Trust en NS1. Realice los pasos siguientes en NS2:

1. Asignar direcciones IP a las interfaces físicas enlazadas a las zonas de seguridad.

2. Crear los objetos de direcciones.

3. En ethernet1 y ethernet2:

a. Habilitar IGMP en el modo enrutador y habilitar IGMP proxy.

b. Especifique la palabra clave always (siempre) para permitir que las interfaces reenvíen tráfico multicast incluso aunque no sean consultadores.

4. Habilitar IGMP en modo host en ethernet3.

5. Configurar la ruta predeterminada.

6. Configurar las directivas de cortafuegos entre las zonas.

7. Configurar las directivas multicast entre las zonas.

Figura 28: Ejemplo de red de proxy de remitente de IGMP

NOTA: Este ejemplo sólo contiene la configuración de NS2, no la de NS1.

Nota: Las zonas de seguridad no se muestran en esta ilustración.

Receptores

ethernet1 10.2.2.1/24Zona Trust

ethernet1 1.1.1.1/24Zona Untrust

ethernet3 2.2.2.2/24 Host del proxy IGMP de la zona Untrust

Internet

NS2NS1

ethernet1, 10.2.2.1 Proxy del enrutador IGMP de zona Trust

Origen 3.2.2.5

Receptores

ethernet2, 3.2.2.1/24 Zona DMZ, proxy del enrutador de IGMP

Proxy de IGMP


WebUI (NS2)




Zone Name: DMZStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 3.2.2.1/24


Zone Name: UntrustStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 2.2.2.2/24






IP/Netmask: (seleccione), 3.2.2.5/32Zone: DMZ


Address Name: proxy-hostIP Address/Domain Name:


Proxy de IGMP 187


188







4. RutaNetwork > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:



5. DirectivaPolicies > (From: DMZ, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK:

Source Address: Address Book Entry: source-dr



Policies > (From: DMZ, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK:




Proxy de IGMP


Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK:

Source Address: Address Book Entry: (seleccione), proxy-host



6. Directiva multicastMCast Policies > (From: DMZ, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK:


MCast Policies > (From: DMZ, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK:


MCast Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK:


CLI (NS2)

1. Interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.2.2.1/24set interface ethernet1 natset interface ethernet2 zone dmzset interface ethernet2 ip 3.2.2.1/24set interface ethernet3 zone untrust set interface ethernet3 ip 2.2.2.2/24

2. Direccionesset address trust mgroup1 224.4.4.1/32set address dmz source-dr 3.2.2.5/32set address untrust proxy-host 2.2.2.2/32

3. IGMPset interface ethernet1 protocol igmp routerset interface ethernet1 protocol igmp proxy alwaysset interface ethernet1 protocol igmp enableset interface ethernet2 protocol igmp routerset interface ethernet2 protocol igmp proxy alwaysset interface ethernet2 protocol igmp enableset interface ethernet3 protocol igmp hostset interface ethernet3 protocol igmp no-check-subnetset interface ethernet3 protocol igmp enable

Proxy de IGMP 189


190

4. Rutaset vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250

5. Directivasset policy from dmz to trust source-dr mgroup1 any permitset policy from dmz to untrust source-dr mgroup1 any permitset policy from untrust to trust proxy-host mgroup1 any permit

6. Directivas multicastset multicast-group-policy from dmz mgroup 224.4.4.1/32 to untrust

igmp-message bi-directionalset multicast-group-policy from dmz mgroup 224.4.4.1/32 to trust igmp-message

bi-directionalset multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust


Proxy de IGMP

Capítulo 9

Multicast independiente de protocolo

En este capítulo se describe el pulticast independiente de protocolo (PIM) en los dispositivos de seguridad de Juniper Networks. Contiene las siguientes secciones:


“PIM-SM” en la página 193

“Árboles de distribución multicast” en la página 194

“Enrutador designado” en la página 194

“Asignación de puntos de encuentro a grupos” en la página 195

“Reenvío de tráfico a través del árbol de distribución” en la página 195

“Configuración de PIM-SM en dispositivos de seguridad” en la página 198

“Habilitación y eliminación de una instancia PIM-SM en un VR” en la página 199

“Habilitación e inhabilitación de PIM-SM en interfaces” en la página 200

“Directivas de grupo multicast” en la página 200

“Ajuste de una configuración de PIM-SM básica” en la página 202

“Verificación de la configuración” en la página 207

“Configuración de puntos de encuentro” en la página 209

“Configuración de un punto de encuentro estático” en la página 209

“Configuración de un punto de encuentro candidato” en la página 210

“Consideraciones sobre seguridad” en la página 211

“Restricción de grupos multicast” en la página 211

“Restricción de orígenes multicast” en la página 212

“Restricción de puntos de encuentro” en la página 213

191


192

“Parámetros de la interfaz PIM-SM” en la página 214

“Definición de una directiva vecina” en la página 214

“Definición de un límite bootstrap” en la página 215

“Configuración de un punto de encuentro del proxy” en la página 215

“PIM-SM e IGMPv3” en la página 225

Vista general

El Multicast independiente de protocolo (PIM) es un protocolo de enrutamiento multicast que se ejecuta entre enrutadores. Mientras que el protocolo de administración de grupos de Internet (IGMP) se ejecuta entre equipos y enrutadores para intercambiar información de miembros del grupo multicast, PIM se ejecuta entre enrutadores para reenviar el tráfico multicast a los miembros del grupo multicast de toda la red. (Para obtener información sobre IGMP, consulte “Protocolo de administración de grupos de Internet” en la página 165.)

Figura 29: IGMP

Origen

Los protocolos de enrutamiento multicast, tales como PIM-SM, completan la tabla de rutas multicast y redireccionan los datos a los hosts de toda la red.

Hosts y enrutadores utilizan IGMP para intercambiar información de miembros del grupo multicast.

Internet

Vista general

Capítulo 9: Multicast independiente de protocolo

Para ejecutar PIM, también debe configurar rutas estáticas o un protocolo de enrutamiento dinámico. PIM se denomina protocolo independiente porque utiliza la tabla de rutas del protocolo de enrutamiento unicast subyacente para realizar sus comprobaciones RPF (reenvío por rutas inversas), pero no depende de la funcionalidad del protocolo de enrutamiento unicast. (Para obtener información sobre RPF, consulte “Reenvío por rutas inversas” en la página 158).

PIM puede funcionar de los modos siguientes:

El modo PIM-Dense (PIM-DM) envía grandes cantidades de tráfico multicast a través de la red y luego corta las rutas a hacia los receptores que no desean recibir tráfico multicast.

El modo PIM-Sparse (PIM-SM) reenvía el tráfico multicast solamente a los receptores que lo soliciten. Los enrutadores que ejecuten PIM-SM pueden utilizar el árbol de ruta compartida o el árbol de ruta más corta (SPT) para reenviar la información multicast. (Para obtener más información, consulte “Árboles de distribución multicast” en la página 194).

El modo multicast específico del origen PIM (PIM-SSM) está derivado del PIM-SM. Igual que PIM-SM, reenvía tráfico multicast sólo a los receptores interesados. A diferencia de PIM-SM, forma inmediatamente un SPT al origen.

Los dispositivos de seguridad de Juniper Networks admiten PIM-SM, según la definición draft-ietf-pim-sm-v2-new-06, así como PIM-SSM según la definición RFC 3569, Vista general de Multicast específico de origen (SSM). Para obtener información sobre PIM-SM, consulte “PIM-SM.” Para obtener información sobre PIM-SSM, consulte “PIM-SSM” en la página 197.

PIM-SMPIM-SM es un protocolo de enrutamiento multicast que reenvía tráfico multicast sólo a los receptores interesados. Puede utilizar un árbol de distribución compartido o el árbol de ruta más corta (SPT) para reenviar tráfico multicast a través de la red. (Para obtener información sobre árboles de distribución multicast, consulte “Árboles de distribución multicast” en la página 194). De forma predeterminada, PIM-SM utiliza el árbol de distribución compartido con un punto de encuentro (RP) en la raíz del árbol. Todos los orígenes de un grupo envían sus paquetes al RP, y el RP envía datos en dirección descendente por el árbol de distribución compartido a todos los receptores de la red. Cuando se alcanza un umbral configurado, los receptores pueden formar un SPT al origen, reduciendo el tiempo que lleva a los receptores recibir los datos multicast.

Con independencia del árbol utilizado para distribuir el tráfico, sólo los receptores que explícitamente se unan a un grupo multicast pueden recibir el tráfico enviado a ese grupo. PIM-SM utiliza la tabla de enrutamiento unicast para realizar sus operaciones de reenvío por rutas inversas (RPF) al recibir mensajes de control multicast y utiliza la tabla de enrutamiento multicast para enviar tráfico de datos multicast a los receptores.

NOTA: De forma predeterminada, los dispositivos de seguridad de Juniper Networks conmutan al SPT en el momento de recibir el primer byte.

Vista general 193


194

Árboles de distribución multicastLos enrutadores multicast reenvían el tráfico multicast en sentido descendente desde el origen a los receptores a través de un árbol de distribución multicast. Hay dos tipos de árboles de distribución multicast:

El árbol de la ruta más corta (SPT): El origen se encuentra en la raíz del árbol y reenvía los datos multicast en sentido descendente a cada receptor. Denominada también árbol específico del origen.

Árbol de distribución compartido: El origen transmite el tráfico multicast al punto de encuentro (RP), que típicamente es un enrutador en el núcleo de la red. A continuación, el RP reenvía el tráfico en sentido descendente a los receptores del árbol de distribución.

Figura 30: PIM

Enrutador designadoCuando en una red de área local (LAN) multiacceso hay varios enrutadores multicast, los enrutadores eligen un enrutador designado (DR). El DR en la LAN del origen es responsable de enviar los paquetes multicast desde el origen al RP y a los receptores que están en el árbol de distribución específico del origen. El DR en la LAN de los receptores es responsable de reenviar mensajes join-prune desde los receptores al RP, y de enviar el tráfico de datos multicast a los receptores de la LAN. Los receptores envían mensajes join-prune cuando desean unirse a un grupo multicast o salir de él.

El DR se selecciona a través de un proceso de selección. Cada enrutador PIM-SM de una LAN tiene una prioridad DR que el usuario configura. Los enrutadores de PIM-SM anuncian sus prioridades DR mediante mensajes de saludo (“hello”) que envían periódicamente a sus vecinos. Cuando los enrutadores reciben los mensajes de saludo, seleccionan el enrutador con la prioridad DR más alta como DR para la LAN. Si varios enrutadores coinciden en tener la prioridad DR más alta, el enrutador con la dirección IP más alta se convertirá en el DR de la LAN.

Árbol de distribución compartido

2. El origen envía tráfico multicast en sentido descendente hacia el punto de encuentro (RP).

3. El RP reenvía el tráfico multicast en sentido descendente a los receptores.

Árbol de la ruta más corta

1. El origen envía tráfico multicast en sentido descendente a los receptores.

RP


Árbol de la ruta más corta

Árbol de distribución compartido

Vista general


Asignación de puntos de encuentro a gruposUn punto de encuentro (RP) envía paquetes multicast para grupos multicast determinados. Un dominio PIM-SM es un grupo de enrutadores PIM-SM con las mismas asignaciones de grupo RP. Hay dos maneras de asignar grupos multicast a un RP: estáticamente y dinámicamente.

Asignación de RP estática

Para crear una asignación estática entre un RP y un grupo multicast, debe configurar el RP para el grupo multicast en cada enrutador de la red. Cada vez que cambie la dirección del RP, deberá volver a configurar la dirección del RP.

Asignación de RP dinámica

PIM-SM también proporciona un mecanismo de asignación dinámica de RP a grupos multicast. En primer lugar, configure los puntos de encuentro de candidatos (C-RP) para cada grupo multicast. A continuación, los C-RP envían anuncios Candidate-RP a un enrutador de la LAN, denominado enrutador “bootstrap” (BSR). Los anuncios contienen el grupo multicast para el cual el enrutador actúa como RP y la prioridad del C-RP.

El BSR recoge estos anuncios C-RP y los emite en un mensaje BSR a todos los enrutadores del dominio. Los enrutadores recogen estos mensajes BSR y utilizan un algoritmo hash bien conocido para seleccionar un RP activo por cada grupo multicast. Si el RP seleccionado falla, el enrutador selecciona una nueva asignación de grupo RP entre los RP candidatos. Para obtener información sobre el proceso de selección de BSR, consulte draft-ietf-pim-sm-bsr-03.txt.

Reenvío de tráfico a través del árbol de distribuciónEsta sección describe la manera en la cual los enrutadores PIM-SM envían mensajes “join” al punto de encuentro (RP) de un grupo multicast y la manera en la cual el RP envía datos multicast a los receptores de la red. En un entorno de red multicast, un dispositivo de seguridad puede funcionar como RP, como enrutador designado en la red del origen o en la red de los receptores, o como enrutador intermedio.

El origen envía datos a un grupo

Cuando un origen comienza a enviar paquetes multicast, transmite esos paquetes a través de la red. Cuando el enrutador designado (DR) en esa red de área local (LAN) recibe los paquetes multicast, consulta la interfaz saliente y la dirección IP del salto siguiente hacia el RP en la tabla de rutas unicast. A continuación, el DR encapsula los paquetes multicast en paquetes unicast, denominados mensajes REGISTER y los reenvía a la dirección IP del siguiente salto. Cuando el RP recibe los mensajes REGISTER, desencapsula los paquetes y envía los paquetes multicast en sentido descendente por el árbol de distribución hacia los receptores.

Vista general 195


196

Figura 31: Envío de datos desde el origen

Si la velocidad de transmisión de los datos del DR de origen alcanza un umbral configurado, el RP envía un mensaje PIM-SM join hacia el DR de origen, de modo que el RP pueda recibir datos multicast nativos, en lugar de los mensajes REGISTER. Cuando el DR de origen recibe el mensaje join, envía los paquetes multicast y los mensajes REGISTER hacia el RP. Cuando el RP recibe los paquetes multicast del DR, envía al DR un mensaje register-stop. Cuando el DR recibe el mensaje register-stop, deja de enviar los mensajes REGISTER y envía los datos multicast nativos, que el RP envía en sentido descendente a los receptores.

El host se une a un grupo

Cuando un host se une a un grupo multicast, envía un mensaje IGMP join a ese grupo multicast. Cuando el DR de la LAN del host recibe el mensaje IGMP join, consulta el grupo en el RP. Crea una entrada (*, G) en la tabla de rutas multicast y envía un mensaje PIM-SM join a su RPF vecino en sentido ascendente hacia el RP. Cuando el enrutador de sentido ascendente recibe los mensajes PIM-SM join, realiza el mismo proceso de consulta RP y también comprueba si el mensaje join viene de un RPF vecino. Si es así, remite el mensaje PIM-SM join hacia el RP. Este proceso se repite hasta que el mensaje PIM-SM join alcanza el RP. Cuando el RP recibe el mensaje join, envía los datos multicast en sentido descendente hacia el receptor.

1.El origen envía los paquetes multicast en sentido descendente.

2. El DR encapsula los paquetes y envía mensajes REGISTER al RP.

Enrutador designado (DR)

Punto de encuentro (RP)

Origen

3. El RP desencapsula los mensajes REGISTER y envía paquetes multicast a los receptores.


Vista general


Figura 32: El host se une a un grupo

Cada enrutador en sentido descendente realiza una comprobación del RPF cuando recibe los datos multicast. Cada enrutador comprueba si recibió los paquetes multicast de la interfaz que utiliza para enviar tráfico de datos hacia el RP. Si la comprobación del RPF es correcta, el enrutador busca una entrada de reenvío (*, G) coincidente en la tabla de rutas multicast. Si encuentra la entrada (*, G), coloca el origen en la entrada, que se convierte en una entrada (S, G) y reenvía los paquetes multicast en sentido descendente. Este proceso continúa en sentido descendente a lo largo del árbol de distribución hasta que el host recibe los datos multicast.

Cuando la velocidad de transmisión de datos alcanza un umbral configurado, el DR de la LAN del host puede formar el árbol de ruta más corta directamente al origen multicast. Cuando el DR comienza a recibir tráfico de datos directamente del origen, envía un mensaje prune específico del origen en sentido ascendente hacia el RP. Cada enrutador intermedio “corta” del árbol de distribución la conexión con el host, hasta que el mensaje prune alcanza el RP, que en ese momento deja de enviar tráfico de datos multicast en sentido descendente hacia esa rama en particular del árbol de distribución.

PIM-SSMAdemás de PIM-SM, los dispositivos de seguridad también admiten multicast específico de origen PIM (SSM). PIM-SSM sigue el modelo de origen específico (SSM) donde el tráfico multicast se transmite a los canales, no sólo a los grupos multicast. Un canal consiste en un origen y un grupo multicast. Un receptor se suscribe a un canal con un origen conocido y un grupo multicast. Los receptores proporcionan información sobre el origen a través de IGMPv3. El enrutador designado en la LAN envía mensajes al origen y no a un punto de encuentro (RP).

Enrutador designado (DR)

Hosts/Receptores

Punto de encuentro RP

3. RP envía datos multicast en sentido descendente a los receptores.

Hosts/Receptores

1. Los hosts envían mensajes join de IGMP para el grupo multicast.

2. DR envía mensajes IGMPjoin al RP.

Origen

Vista general 197


198

El IANA ha reservado el rango de direcciones multicast 232/8 para el servicio SSM en IPv4. Si IGMPv3 se ejecuta en un dispositivo junto con PIM-SM, las operaciones PIM-SSM están garantizadas dentro de este rango de direcciones. El dispositivo de seguridad manipula los informes de miembros IGMPv3 para los grupos multicast dentro del rango de direcciones 232/8 tal y como se muestra a continuación:

Si el informe contiene un modo de filtro include, el dispositivo envía el informe directamente a los orígenes de la lista de origen.

Si el informe contiene un modo de filtro exclude, el dispositivo descarta el informe. No procesa informes (*, G) para los grupos multicast del rango de direcciones 232/8.

Los pasos para configurar PIM-SSM en un dispositivo de seguridad son iguales a los necesarios para configurar PIM-SM pero con las siguientes diferencias:

Debe configurar IGMPv3 en interfaces conectadas con receptores. (IGMPv2 está habilitado de forma predeterminada en los dispositivos de seguridad).

Cuando configure una directiva de grupo multicast, autorice los mensajes join-prune. (Los mensajes bootstrap no se utilizan).

No configure un punto de encuentro.

Las siguientes secciones explican la manera de configuración de PIM-SM en dispositivos de seguridad.

Configuración de PIM-SM en dispositivos de seguridad

Los dispositivos de seguridad de Juniper Networks tienen dos enrutadores virtuales predefinidos (VR): trust-vr y untrust-vr. Cada enrutador virtual es un componente de enrutamiento independiente con sus propias tablas de rutas. El multicast independiente de protocolo – Modo Sparse (PIM-SM) utiliza la tabla de rutas del enrutador virtual en el cual está configurado para consultar la interfaz de reenvío por rutas inversas (PIM-SM) y la dirección IP siguiente. Por lo tanto, para ejecutar PIM-SM en un dispositivo de seguridad, primero debe configurar rutas estáticas o un protocolo de enrutamiento dinámico en un enrutador virtual, y luego tiene que configurar el PIM-SM en el mismo enrutador virtual. (Para obtener más información sobre enrutadores virtuales, consulte “Enrutamiento” en la página 13.) Los dispositivos de seguridad admiten los siguientes protocolos de enrutamiento dinámico:

Abrir primero la ruta más corta (OSPF). Para obtener más información, consulte “Abrir primero la ruta más corta” en la página 47.

Protocolo de información de enrutamiento (RIP). Para obtener más información, consulte “Protocolo de información de enrutamiento” en la página 79.

Protocolo de puerta de enlace de límite (BGP). Para obtener más información, consulte “Protocolo de puertas de enlace de límite” en la página 109.



Las siguientes secciones describen los pasos básicos para la configuración de PIM-SM en un dispositivo de seguridad.

Creación y habilitación de una instancia PIM-SM en un VR

Habilitación de PIM-SM en las interfaces

Configuración de una directiva multicast para permitir que los mensajes PIM-SM pasen por el dispositivo de seguridad

Habilitación y eliminación de una instancia PIM-SM en un VRPuede configurar una instancia PIM-SM para cada enrutador virtual. PIM-SM utiliza la tabla de rutas unicast del enrutador virtual para realizar su comprobación del RPF. Después de crear y habilitar una instancia de enrutamiento PIM-SM en un enrutador virtual, puede habilitar el PIM-SM en las interfaces del enrutador virtual.

Habilitación de una instancia PIM-SM En este ejemplo, creará y habilitará una instancia PIM-SM para el enrutador virtual trust-vr.

WebUI

Network > Routing > Virtual Routers > Edit (para trust-vr) > Create PIM Instance: Seleccione Protocol PIM: Enable, luego haga clic en Apply.

CLI

device-> set vrouter trust-vrdevice(trust-vr)-> set protocol pimdevice(trust.vr/pim)-> set enabledevice(trust.vr/pim)-> exitdevice(trust-vr)-> exitsave

Eliminación de una instancia PIM-SM En este ejemplo eliminará la instancia PIM-SM del enrutador virtual trust-vr. Cuando elimine la instancia PIM-SM de un enrutador virtual, el dispositivo de seguridad inhabilita el PIM-SM en las interfaces y borra todos los parámetros de la interfaz PIM-SM.

WebUI

Network > Routing > Virtual Router (trust-vr) > Edit > Delete PIM Instance, luego haga clic en OK en el mensaje de confirmación.

CLI

unset vrouter trust-vr protocol pimdeleting PIM instance, are you sure? y/[n] ysave

Configuración de PIM-SM en dispositivos de seguridad 199


200

Habilitación e inhabilitación de PIM-SM en interfacesDe forma predeterminada, PIM-SM está desactivado en todas las interfaces. Después de crear y habilitar el PIM-SM en un enrutador virtual, debe habilitar PIM-SM en las interfaces de ese enrutador virtual que transmiten tráfico de datos multicast. Si una interfaz está conectada con un receptor, también debe configurar IGMP en modo enrutador en esa interfaz. (Para obtener información sobre IGMP, consulte “Protocolo de administración de grupos de Internet” en la página 165.)

Cuando habilita PIM-SM en una interfaz que está asociada a una zona, PIM-SM se habilita automáticamente en la zona a la que pertenece dicha interfaz. A continuación, puede configurar los parámetros PIM-SM para dicha zona. De forma similar, cuando se desactivan los parámetros PIM-SM de interfaces en una zona, todos los parámetros PIM-SM relacionados con dicha zona se eliminan automáticamente.

Habilitación de PIM-SM en una interfazEn este ejemplo habilitará PIM-SM en la interfaz ethernet1.

WebUI

Network > Interfaces > Edit (para ethernet1) > PIM: Introduzca los siguientes datos, luego haga clic en Apply:

PIM Instance: (seleccione)Protocol PIM: Enable (seleccione)

CLI

set interface ethernet1 protocol pimset interface ethernet1 protocol pim enablesave

Desactivación de PIM-SM en una interfazEn este ejemplo deshabilitará PIM-SM en la interfaz ethernet1. Recuerde que cualquier otra interfaz en la que haya habilitado PIM-SM todavía sigue transmitiendo y procesando los paquetes PIM-SM.

WebUI

Network > Interfaces > Edit (para ethernet1) > PIM: Desactive Protocol PIM Enable, luego haga clic en Apply.

CLI

unset interface ethernet1 protocol pim enablesave

Directivas de grupo multicastDe forma predeterminada, los dispositivos de seguridad no permiten que los mensajes de tráfico de control multicast, como por ejemplo mensajes PIM-SM, pasen de una zona a otra. Debe configurar una directiva de grupo multicast para permitir que los mensajes PIM-SM pasen de una zona a otra. Las directivas de grupo multicast controlan dos tipos de mensajes PIM-SM: los mensajes static-RP-BSR y los mensajes join-prune.



Mensajes Static-RP-BSRLos mensajes Static-RP-BSR contienen información sobre los puntos de encuentro estáticos (RP) y las asignaciones de grupo RP dinámicas. La configuración de una directiva multicast que permita asignaciones estáticas de RP y mensajes bootstrap (BSR) de una zona a otra, habilita el dispositivo de seguridad para que comparta las asignaciones de grupo RP de una zona a otra dentro de un enrutador virtual o entre dos enrutadores virtuales. Los enrutadores son capaces de memorizar las asignaciones de grupos RP de otras zonas, de modo que no tenga que configurar los RP en todas las zonas.

Cuando el dispositivo de seguridad recibe un mensaje BSR, comprueba que venga de su vecino de reenvío por rutas inversas (RPF). A continuación comprueba si hay directivas multicast para los grupos multicast del mensaje BSR. Filtra los grupos que no estén autorizados en la directiva multicast y envía el mensaje BSR a los grupos permitidos en todas las zonas de destino que están autorizadas por la directiva.

Mensajes Join-PruneLas directivas de grupo multicast también controlan los mensajes join-prune. Cuando el dispositivo de seguridad recibe un mensaje join-prune para un origen y grupo o un origen y RP en su interfaz de sentido descendente, consulta en el RPF vecino y la interfaz de la tabla de enrutamiento unicast.

Si la interfaz RPF se encuentra en la misma zona que la interfaz en sentido descendente, la validación de la directiva multicast no es necesaria.

Si la interfaz RPF se encuentra en otra zona, el dispositivo de seguridad comprueba si hay una directiva multicast que permita mensajes join-prune para el grupo entre la zona de interfaz en sentido descendente y la zona de la interfaz RPF.

Si hay una directiva multicast que permite mensajes join-prune entre las dos zonas, el dispositivo de seguridad reenvía el mensaje a la interfaz RPF.

Si no hay directiva multicast que permita mensajes join-prune entre las dos zonas, se descarta el mensaje join-prune.

Definición de una directiva de grupo multicast para PIM-SMEn este ejemplo, definirá una directiva de grupo multicast bidireccional que permita todos los mensajes PIM-SM entre las zonas Trust y Untrust para el grupo 224.4.4.1.

WebUI

Policies (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK:

MGroup Address: IP/Netmask (seleccione) 224.4.4.1/32Bidirectional: (seleccione)PIM Message: (seleccione)BSR-Static RP: (seleccione)Join/Prune: (seleccione)

Configuración de PIM-SM en dispositivos de seguridad 201


202

CLI

set multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust pim-message bsr-static-rp join-prune bi-directional

save

Ajuste de una configuración de PIM-SM básica

Un dispositivo de seguridad puede funcionar como un punto de encuentro (RP), como un enrutador designado de origen (DR), como un receptor DR y como un enrutador intermedio. No puede funcionar como un enrutador bootstrap.

Puede configurar PIM-SM en un enrutador virtual (VR) o a través de dos enrutadores virtuales. Realice los siguientes pasos para configurar PIM-SM en un enrutador virtual:

1. Configure las zonas y las interfaces.

2. Configure rutas estáticas o un protocolo de enrutamiento dinámico, como por ejemplo el protocolo de información de enrutamiento (RIP), el protocolo de puerta de enlace de límite (BGP) o abrir primero la ruta más corta (OSPF), en un enrutador virtual específico del dispositivo de seguridad.

3. Cree una directiva de cortafuegos para que el tráfico de datos unicast y multicast pase de una zona a otra.

4. Cree y habilite una instancia de enrutamiento PIM-SM en el mismo enrutador virtual en el que haya configurado las rutas estáticas o un protocolo del enrutamiento dinámico.

5. Habilite PIM-SM en interfaces que reenvíen el tráfico en sentido ascendente hacia el origen o el RP, y en sentido descendente hacia los receptores.

6. Habilite IGMP en las interfaces conectadas a los hosts.

7. Configure una directiva multicast para permitir que los mensajes de PIM-SM pasen de una zona a otra.

Cuando configure PIM-SM entre dos enrutadores virtuales, debe configurar el RP en la zona del enrutador virtual en la que se encuentre el RP. A continuación, configure una directiva de grupo multicast que permita los mensajes join-prune y los mensajes BSR-static-RP entre las zonas en cada enrutador virtual. También debe exportar las rutas unicast entre los dos enrutadores virtuales para asegurar la exactitud de la información de reenvío por rutas inversas (RPF). Para obtener información acerca de la exportación de rutas, consulte “Exportación e importación de rutas entre enrutadores virtuales” en la página 43.

NOTA: Si un dispositivo de seguridad se configura con varios enrutadores virtuales, todos los enrutadores virtuales deben tener las mismas opciones PIM-SM.



Algunos dispositivos de seguridad de Juniper Networks admiten varios sistemas virtuales. (Para obtener información sobre los sistemas virtuales, consulte Volumen 10: Sistemas virtuales). La configuración de PIM-SM en un sistema virtual es igual que la configuración de PIM-SM en el sistema raíz. Si va a configurar PIM-SM en dos enrutadores virtuales que se encuentran en sistemas virtuales diferentes, debe configurar un proxy RP. (Para obtener información sobre la configuración de un proxy RP, consulte “Configuración de un punto de encuentro del proxy” en la página 215.)

En este ejemplo, configurará PIM-SM en un enrutador trust-vr. Desea que los hosts de la zona Trust reciban tráfico de datos multicast para el grupo multicast 224.4.4.1/32. Configurará el RIP como el protocolo de enrutamiento unicast en el enrutador trust-vr y cree una directiva de cortafuegos para permitir el tráfico de datos entre las zonas Trust y Untrust. Creará una instancia PIM-SM en el enrutador trust-vr y habilitará PIM-SM en ethernet1 y ethernet2 en la zona Trust, y en ethernet3 en la zona Untrust. Todas las interfaces están en modo de ruta. A continuación, configurará IGMP en ethernet1 y ethernet2, que están conectados con los receptores. Finalmente, creará una directiva multicast que permita los mensajes static-RP-BSR y join-prune entre las zonas.

Ajuste de una configuración de PIM-SM básica 203


204

Figura 33: Configuración PIM-SM básica

WebUI

1. Zonas e interfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos, luego haga clic en Apply:

Zone Name: TrustStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 10.1.1.1/24

Seleccione los siguientes datos y haga clic en OK:

Interface Mode: NAT

Zona Untrust

Receptores

ethernet1 10.1.1.1/24

Zona Trust ethernet2 10.1.2.1/24

Receptoresethernet3 1.1.1.1/24

Punto de encuentro

Enrutador bootstrap

Enrutador designado

Origen













3. IGMPNetwork > Interfaces > Edit (para ethernet1) > IGMP: Introduzca los siguientes datos y haga clic en OK:




4. RIPNetwork > Routing > Virtual Router (trust-vr) > Edit > Create RIP Instance: Seleccione Enable RIP y haga clic en OK.

Network > Interfaces > Edit (para ethernet3) > RIP: Introduzca los siguientes datos, luego haga clic en Apply:

RIP Instance: (seleccione)Protocol RIP: Enable (seleccione)

Ajuste de una configuración de PIM-SM básica 205


206

5. PIM-SMNetwork > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance: Seleccione los siguientes datos, luego haga clic en OK.

Protocol PIM: Enable (seleccione)











7. Directiva multicastMCast Policies (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK:

MGroup Address: IP/Netmask (seleccione) 224.4.4.1/32Bidirectional: (seleccione)PIM Message: (seleccione)BSR Static RP: (seleccione)Join/Prune: (seleccione)

CLI

1. Zonas e interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.1.1/24set interface ethernet1 natset interface ethernet2 zone trustset interface ethernet2 ip 10.1.2.1/24set interface ethernet2 natset interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24



2. Direccionesset address trust mgroup1 224.4.4.1/32set address untrust source-dr 6.6.6.1/24

3. IGMPset interface ethernet1 protocol igmp routerset interface ethernet1 protocol igmp enableset interface ethernet2 protocol igmp routerset interface ethernet2 protocol igmp enable

4. RIP set vrouter trust-vr protocol ripset vrouter trust-vr protocol rip enableset interface ethernet3 protocol rip enable

5. PIM-SM set vrouter trust-vr protocol pimset vrouter trust-vr protocol pim enableset interface ethernet1 protocol pimset interface ethernet1 protocol pim enableset interface ethernet2 protocol pimset interface ethernet2 protocol pim enableset interface ethernet3 protocol pimset interface ethernet3 protocol pim enable

6. Directivaset policy from untrust to trust source-dr mgroup1 any permit

7. Directiva multicastset multicast-group-policy from trust mgroup 224.4.4.1/32 any to untrust

pim-message bsr-static-rp join bi-directionalsave

Verificación de la configuración

Para verificar la configuración de PIM-SM, ejecute el siguiente comando:

device-> get vrouter trust protocol pimPIM-SM enabledNumber of interfaces : 1SPT threshold : 1 BpsPIM-SM Pending Register Entries Count : 0Multicast group accept policy list: 1Virtual Router trust-vr - PIM RP policy--------------------------------------------------Group Address RP access-listVirtual Router trust-vr - PIM source policy--------------------------------------------------Group Address Source access-list

Verificación de la configuración 207


208

Para visualizar las entradas de la ruta multicast, ejecute el comando siguiente:

device-> get igmp grouptotal groups matched: 1multicast group interface last reporter expire ver*224.4.4.1 trust 0.0.0.0 ------ v2

device->get vrouter trust protocol pim mroute trust-vr - PIM-SM routing table-----------------------------------------------------------------------------Register - R, Connected members - C, Pruned - P, Pending SPT Alert - GForward - F, Null - N , Negative Cache - E, Local Receivers - LSPT - T, Proxy-Register - X, Imported - I, SGRpt state - Y, SSM Range Group - STurnaround Router - K-----------------------------------------------------------------------------Total PIM-SM mroutes: 2

(*, 236.1.1.1) RP 20.20.20.10 01:54:20/- Flags: LF Zone: Untrust Upstream : ethernet1/2 State : Joined RPF Neighbor : local Expires : - Downstream : ethernet1/2 01:54:20/- Join 0.0.0.0 FC

(10.10.10.1/24, 238.1.1.1) 01:56:35/00:00:42 Flags: TLF Register Prune Zone: Trust Upstream : ethernet1/1 State : Joined RPF Neighbor : local Expires : - Downstream : ethernet1/2 01:54:20/- Join 236.1.1.1 20.20.20.200 FC

En cada entrada de la ruta puede verificar lo siguiente:

El estado (S, G) o estado de reenvío (*, G)

Si el estado de reenvío es (*, G), la dirección IP del RP; si el estado de reenvío es (S, G), la dirección IP de origen

Zona que posee la ruta

El estado de “join” y las interfaces entrantes y salientes

Valores del temporizador

Para visualizar los puntos de encuentro en cada zona, ejecute el siguiente comando:

device-> get vrouter trust protocol pim rpFlags : I - Imported, A - Always(override BSR mapping) C - Static Config, P - Static Proxy-----------------------------------------------------------------------------Trust 238.1.1.1/32 RP: 10.10.10.10 192 Static - C Registering : 0 Active Groups : 1 238.1.1.1Untrust 236.1.1.1/32 RP: 20.20.20.10 192 Static - P Registering : 0 Active Groups : 1 236.1.1.1

Verificación de la configuración


Para verificar que hay un vecino de reenvío por rutas inversas, ejecute el siguiente comando:

device-> get vrouter trust protocol pim rpfFlags : RP address - R, Source address - SAddress RPF Interface RPF Neighbor Flags-------------------------------------------------------10.10.11.51 ethernet3 10.10.11.51 R10.150.43.133 ethernet3 10.10.11.51 S

Para visualizar el estado de los mensajes join-prune que el dispositivo de seguridad envía a cada vecino de un enrutador virtual, ejecute el siguiente comando:

device-> get vrouter untrust protocol pim joinNeighbor Interface J/P Group Source---------------------------------------------------------------------1.1.1.1 ethernet4:1 (S,G) J 224.11.1.1 60.60.0.1 (S,G) J 224.11.1.1 60.60.0.1

Configuración de puntos de encuentro

Puede configurar un punto de encuentro estático (RP) si desea asociar un RP específico a uno o más grupos multicast. Puede configurar múltiples RP estáticos con cada RP asignado a un grupo multicast diferente.

Debe configurar un RP estático cuando en la red no haya enrutador bootstrap. Aunque un dispositivo de seguridad puede recibir y procesar mensajes bootstrap, no realiza funciones de enrutador bootstrap.

Puede configurar un enrutador virtual como RP candidato (C-RP) cuando desee asignar RP a grupos multicast de forma dinámica. Puede crear un C-RP para cada zona.

Configuración de un punto de encuentro estáticoCuando configure un RP estático, debe especificar lo siguiente:

La zona del RP estático

La dirección IP del RP estático

Una lista de accesos que define los grupos multicast del RP estático (para obtener más información, consulte “Listas de acceso” en la página 161).

Para asegurarse de que los grupos multicast de la lista de acceso siempre utilicen el mismo RP, incluya la palabra clave always. Si no incluye esta palabra clave, y el dispositivo de seguridad descubre que hay otro RP asignado dinámicamente a los mismos grupos multicast, utilizará el RP dinámico.

En este ejemplo, creará una lista de accesos para el grupo multicast 224.4.4.1, y a continuación creará un RP estático para dicho grupo. La dirección IP del RP estático es 1.1.1.5/24. Especifique la palabra clave always para asegurarse de que el dispositivo de seguridad utilice siempre el mismo RP para eso.

Configuración de puntos de encuentro 209


210

WebUI



Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance > RP Address > New: Seleccione los siguientes datos y haga clic en OK:

Zone: Trust (seleccione)Address: 1.1.1.5Access List: 2Always: (seleccione)

CLI

set vrouter trust-vr access-list 2 permit ip 224.4.4.1/32 1set vrouter trust-vr protocol pim zone trust rp address 1.1.1.5 mgroup-list 2 alwayssave

Configuración de un punto de encuentro candidatoCuando configura un enrutador virtual como C-RP candidato, debe especificar lo siguiente:

La zona en la que se configura el C-RP

La dirección IP de la interfaz que se notifica como C-RP

Una lista de acceso que define los grupos multicast del C-RP

La prioridad de C-RP notificada

En este ejemplo, habilitará PIM-SM en la interfaz ethernet1 que está asociada a la zona Trust. Creará una lista de acceso que defina los grupos multicast del C-RP. A continuación creará un C-RP en la zona Trust del enrutador trust-vr. Establecerá la prioridad del C-RP a 200.

WebUI





Configuración de puntos de encuentro


Select Add No Seq: Introduzca los siguientes datos y haga clic en OK:

Sequence No.: 2IP/Netmask: 224.3.3.1/32Action: Permit

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance > RP Candidate > Edit (Trust Zone): Seleccione los siguientes datos, luego haga clic en OK.

Interface: ethernet1 (seleccione)Access List: 1 (seleccione)Priority: 200

CLI

set interface ethernet1 protocol pimset interface ethernet1 protocol pim enableset vrouter trust-vr access-list 1 permit ip 224.2.2.1/32 1set vrouter trust-vr access-list 1 permit ip 224.3.3.1/32 2set vrouter trust-vr protocol pim zone trust rp candidate interface ethernet1

mgroup-list 1 priority 200save

Consideraciones sobre seguridad

Al ejecutar PIM-SM, hay algunas opciones que se pueden configurar en un enrutador virtual (VR) para controlar el tráfico hacia y desde el enrutador virtual. Los ajustes definidos en el enrutador virtual afectan a todas las interfaces PIM-SM habilitadas en el enrutador virtual.

Cuando una interfaz recibe mensajes de tráfico de control multicast (mensajes IGMP o PIM-SM) de otras zonas, el dispositivo de seguridad comprueba primero si hay una directiva multicast que permita dicho tráfico. Si el dispositivo de seguridad encuentra una directiva multicast que permita el tráfico, comprueba las opciones del enrutador virtual que se pudieran aplicar al tráfico. Por ejemplo, si configura el enrutador virtual para aceptar mensajes join-prune desde grupos multicast especificados en una lista de acceso, el dispositivo de seguridad comprueba si dicho tráfico es para un grupo multicast de la lista. Si es así, el dispositivo permite el tráfico. En caso contrario, el dispositivo descarta el tráfico.

Restricción de grupos multicastPuede restringir un VR para que sólo reenvíe mensajes join-prune de PIM-SM de un conjunto de grupos multicast determinado. Indique los grupos multicast autorizados en una lista de accesos. Cuando utilice esta función, el VR descarta los mensajes join-prune que son para los grupos que no están en la lista de acceso.

En este ejemplo, creará una lista de acceso con en número de identificación 1 que autoriza a los siguientes grupos: 224.2.2.1/32 y 224.3.3.1/32. A continuación, configure el enrutador trust-vr para aceptar mensajes join-prune de los grupos multicast que se encuentran en la lista de acceso.

Consideraciones sobre seguridad 211


212

WebUI





Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance: Seleccione los siguientes datos y haga clic en Apply:

Access Group: 1 (seleccione)

CLI

set vrouter trust-vr access-list 1 permit ip 224.2.2.1/32 1set vrouter trust-vr access-list 1 permit ip 224.3.3.1/32 2set vrouter trust-vr protocol pim accept-group 1save

Restricción de orígenes multicastPuede controlar los orígenes desde los que un grupo multicast recibe datos. Identifique los orígenes permitidos en una lista de acceso, y seguidamente vincule la lista de acceso a los grupos multicast. Esto evita que orígenes no autorizados envíen datos a su red. Si utiliza esta función, el dispositivo de seguridad descarta datos multicast de los orígenes que no se encuentran en la lista. Si el enrutador virtual es el punto de encuentro de la zona, comprobará la lista de acceso antes de aceptar un mensaje REGISTER de un origen. El dispositivo de seguridad descarta los mensajes REGISTER que no provienen de un origen autorizado.

En este ejemplo, primero creará una lista de acceso con el número de identificación 5, que especifica el origen autorizado 1.1.1.1/32. A continuación configurará el enrutador trust-vr para que acepte datos multicast para el grupo multicast 224.4.4.1/32 desde el origen especificado en la lista de acceso.

WebUI



Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance > MGroup: Seleccione los siguientes datos y haga clic en Add:

MGroup: 224.4.4.1/32Accept Source: 5 (seleccione)

Consideraciones sobre seguridad


CLI

set vrouter trust-vr access-list 5 permit ip 1.1.1.1/32 1set vrouter trust-vr protocol pim mgroup 224.4.4.1/32 accept-source 5save

Restricción de puntos de encuentroPuede controlar qué puntos de encuentro (RP) están asignados a un grupo multicast. Identifique los RP autorizados en una lista de acceso, a continuación vincule la lista de acceso a los grupos multicast. Cuando el enrutador virtual (VR) recibe un mensaje bootstrap para un determinado grupo, comprueba la lista de RP autorizados para dicho grupo. Si no encuentra una coincidencia, no selecciona ningún RP para el grupo multicast.

En este ejemplo, creará una lista de accesos con el número de identificación 6, que especifica el RP autorizado, 2.1.1.1/32. A continuación, configurará el enrutador trust-vr para que acepte el RP de la lista de acceso para el grupo multicast 224.4.4.1/32.

WebUI



Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance > MGroup: Seleccione los siguientes datos y haga clic en Add:

MGroup: 224.4.4.1/32Accept RP: 6 (seleccione)

CLI

set vrouter trust-vr access-list 6 permit ip 2.1.1.1/32 1set vrouter trust-vr protocol pim mgroup 224.4.4.1/32 accept-rp 6save

Consideraciones sobre seguridad 213


214

Parámetros de la interfaz PIM-SM

Puede cambiar determinados elementos predeterminados de cada interfaz en la que habilite PIM-SM. Cuando ajuste los parámetros en este nivel, únicamente afectará a la interfaz que usted especifique.

La Tabla 19 describe los parámetros de la interfaz PIM-SM y sus valores predeterminados:

Tabla 19: Parámetros PIM-SIM

Definición de una directiva vecinaPuede controlar los elementos vecinos con los que una interfaz puede formar una adyacencia. Los enrutadores PIM-SM envían periódicamente mensajes de saludo para anunciarse como enrutadores PIM-SM. Si utiliza esta función, la interfaz comprueba su lista de vecinos autorizados o rechazados y forma adyacencias con aquellos que estén autorizados.

En este ejemplo, se creará una lista de acceso que especifique lo siguiente:

El número de identificación es 1.

La primera instrucción permite 2.1.1.1/24.

La segunda instrucción permite 2.1.1.3/24.

A continuación, especificará que ethernet 1 puede formar una adyacencia con los vecinos de la lista de acceso.

Parámetros de la interfaz PIM-SIM Descripción


Neighbor policy Controla adyacencias vecinas. Para obtener información adicional, consulte “Definición de una directiva vecina” en la página 214.

Desactivado

Hello interval Especifica el intervalo en el que la interfaz envía mensajes de saludo a sus enrutadores vecinos.

30 segundos

Designates router priority Especifica la prioridad de la interfaz para la elección del enrutador designado.

1

Join-Prune interval Especifica el intervalo, en segundos, en el que la interfaz envía mensajes join-prune.

60 segundos

Bootstrap border Especifica que la interfaz es un límite bootstrap. Para obtener información adicional, consulte “Definición de un límite bootstrap” en la página 215.

Desactivado

Parámetros de la interfaz PIM-SM


WebUI






Accepted Neighbors: 1

CLI

set vrouter trust-vr access-list 1 permit ip 2.1.1.1/24 1set vrouter trust-vr access-list 1 permit ip 2.1.1.3/24 2set interface ethernet1 protocol pim neighbor-policy 1save

Definición de un límite bootstrapUna interfaz que es un límite bootstrap (BSR) recibe y procesa mensajes BSR, pero no los reenvía a otras interfaces aunque tengan una directiva de grupo multicast que autorice mensajes BSR de una zona a otra. Así se asegura que las asignaciones RP-a-grupo permanezcan siempre dentro de una zona.

En este ejemplo, configurará ethernet1 como límite bootstrap.

WebUI

Network > Interfaces > Edit (para ethernet1) > PIM: Seleccione Bootstrap Border, luego haga clic en Apply.

CLI

set interface ethernet1 protocol pim boot-strap-bordersave

Configuración de un punto de encuentro del proxy

Un dominio PIM-SM es un grupo de enrutadores PIM-SM que poseen las mismas asignaciones de punto de encuentro (RP) a grupo. En un dominio PIM-SM con asignaciones RP-grupo dinámicas, los enrutadores PIM-SM de un dominio escuchan los mensajes del mismo enrutador bootstrap (BSR) para seleccionar sus asignaciones RP-grupo. En un dominio PIM-SM con asignaciones RP-grupo estáticas, debe configurar el RP estático en cada enrutador en el dominio. (Para obtener información sobre asignaciones RP-grupo, consulte “Configuración de puntos de encuentro” en la página 209.)

Configuración de un punto de encuentro del proxy 215


216

En los dispositivos de seguridad de Juniper Networks, las interfaces asociadas a zonas de capa 3 se pueden ejecutar en modo NAT o en modo de ruta. Para ejecutar PIM-SM en un dispositivo con interfaces que funcionan en modos diferentes, cada zona se debe encontrar en un dominio PIM-SM diferente. Por ejemplo, si las interfaces de la zona Trust están en modo NAT y las interfaces de la zona Untrust están en modo de ruta, cada zona se debe encontrar en un dominio PIM-SM diferente. Además, al configurar PIM-SM a través de dos enrutadores virtuales que se encuentran en dos sistemas virtuales diferentes, cada enrutador virtual debe estar en un dominio PIM-SM independiente.

Puede notificar grupos multicast desde un dominio PIM-SM a otro configurando un RP proxy. Un RP proxy actúa como un RP para grupos multicast memorizado de otro dominio PIM-SM, ya sea a través de un RP estático o a través de mensajes bootstrap autorizados por la directiva de grupo multicast. Para los receptores de su dominio, funciona como la raíz del árbol de distribución compartido y puede formar el árbol de ruta más corta al origen.

Puede configurar un RP proxy por cada zona en un enrutador virtual. Para configurar un RP proxy en una zona, debe configurar un RP candidato (C-RP) en dicha zona. A continuación, el dispositivo de seguridad notifica la dirección IP del C-RP como la dirección IP del RP proxy. Cuando configure el C-RP, no especifique cualquier grupo multicast en la lista de grupo multicast. Esto permite que el C-RP actúe como el RP proxy de cualquier grupo importado de otra zona. Si especifica grupos multicast, el C-RP funciona como el RP verdadero para los grupos especificados en la lista.

Si hay un BSR en la zona, el RP proxy se notifica a sí mismo como el RP para los grupos multicast importados de otras zonas. Si no hay BSR en la zona del RP proxy, éste funciona como el RP estático para los grupos multicast importados de otras zonas. A continuación debe configurar la dirección IP del C-RP como el RP estático en todos los demás enrutadores de la zona.

El RP proxy admite el uso de IP asignadas (MIP) para la traducción de la dirección de origen. Una MIP es una asignación directa (“1:1”) de una dirección IP a otra. Puede configurar una MIP cuando desee que el dispositivo de seguridad traduzca a otra dirección una dirección privada de una zona cuyas interfaces estén en modo NAT. Cuando un host de la MIP en la zona de un proxy RP envía un mensaje REGISTER, el dispositivo de seguridad traduce el origen IP a dirección MIP y envía un nuevo mensaje REGISTER al RP verdadero. Cuando el dispositivo de seguridad recibe el mensaje join-prune para una dirección MIP, el dispositivo asigna la MIP a la dirección origen inicial y la envía al origen.

El RP proxy también admite la traducción de direcciones de grupos multicast entre las zonas. Puede configurar una directiva multicast que especifique la dirección original del grupo multicast y la dirección del grupo multicast traducida. Cuando el dispositivo de seguridad recibe un mensaje join-prune en una interfaz de la zona del RP proxy, traduce el grupo multicast, si es necesario, y envía el mensaje join al RP verdadero.



Considere el siguiente caso:

ethernet1 en la zona Trust está en modo NAT, y ethernet3 en la zona Untrust está en modo de ruta.

Hay una MIP para el origen en la zona Trust.

El origen en la zona Trust envía tráfico multicast al grupo multicast 224.4.4.1/32.

Hay receptores tanto en la zona Trust como en la zona Untrust.

Hay una directiva multicast que permite el paso de mensajes PIM-SM entre las zonas Trust y Untrust.

La zona Trust se configura como el RP proxy.

El RP y el BSR están en la zona Untrust.

Figura 34: Ejemplo de punto de encuentro del proxy

A continuación se indica el flujo de datos:

1. El origen envía datos al grupo multicast 224.4.4.1/32.

2. El enrutador designado (DR) encapsula los datos y envía mensajes REGISTER hacia el RP.

3. El proxy del RP de la zona Trust recibe el mensaje REGISTER, y cambia a dirección IP del origen inicial a la dirección IP de la MIP. A continuación reenvía el mensaje hacia el RP para el grupo multicast.

4. El proxy RP envía entradas (*, G) al RP verdadero.

5. Los receptores de la zona Trust envían mensajes join al RP proxy.

6. El RP proxy envía los paquetes multicast a los receptores de la zona Trust.

ethernet1, modo NAT

Enrutador bootstrap (BSR)

Receptores

ethernet3, modo de rutas

Origen

Receptores

Zona Untrust

Punto de encuentro (RP)

Zona Trust



218

Para configurar un RP proxy, debe hacer lo siguiente:

1. Cree una instancia PIM-SM en un enrutador virtual específico.

2. Habilite PIM-SM en las interfaces apropiadas.

3. Configure el RP candidato en la zona del proxy RP.

4. Configure el RP proxy.

En este ejemplo, los dispositivos de seguridad NS1 y NS2 están conectados a través de un túnel VPN. Ambos dispositivos ejecutan el protocolo de enrutamiento dinámico, BGP. Configure PIM-SM en ethernet1 y tunnel.1 en NS1 y en NS2. A continuación, en NS2, configure ethernet1 como RP estático, y cree un RP proxy en la zona Trust del enrutador trust-vr.

Figura 35: Ejemplo de configuración del RP proxy

WebUI (NS1)

1. InterfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en OK:


Receptore

Origen

Punto de encuentro actual

Enrutador bootstrap

NS1

ethernet1 10.2.2.1/24


Zona Trust

Zona Untrust


Zona Trust



VPN

Punto de encuentro del proxyNS2



Receptores

Zona Untrust

ethernet1 10.4.1.1/24












Address Name: branchIP Address/Domain Name:


3. PIM-SMNetwork > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance: Seleccione Protocol PIM: Enable, luego haga clic en OK.



Network > Interfaces > Edit (para tunnel.1) > PIM: Introduzca los siguientes datos, luego haga clic en Apply:


4. VPN VPN > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK.

Gateway Name: To_BranchSecurity Level: CompatibleRemote Gateway Type:Static IP Address: (seleccione), IP Address/Hostname: 4.1.1.1Preshared Key: fg2g4h5jOutgoing Interface: ethernet3



220

> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return para regresar a la página de configuración básica de Gateway:


5. BGPNetwork > Routing > Virtual Router (trust-vr) > Edit: Introduzca los siguientes datos y haga clic en OK:

Virtual Router ID: Custom (seleccione)En el cuadro de texto, escriba 0.0.0.10.

Network > Routing > Virtual Router (trust-vr) > Edit: Seleccione Create BGP Instance.


Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance > Neighbors: Introduzca los siguientes datos y haga clic en Add:

AS Number: 65000Remote IP: 4.1.1.1Outgoing Interface: ethernet3

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance > Neighbors > Configure (para el interlocutor que acaba de agregar): Seleccione Peer Enabled y luego haga clic en OK.

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance > Networks: Escriba 2.2.2.0/24 en el campo IP/Netmask, luego haga clic en Add. A continuación, introduzca 10.2.2.0/24 en el campo IP/Netmask, y haga clic en Add de nuevo.

Network > Interfaces > Edit (para ethernet3) > BGP: Introduzca los siguientes datos, luego haga clic en Apply:

Protocol BGP: Enable (seleccione)


Source Address: Address Book Entry: (seleccione), branch






MGroup Address: IP/Netmask (seleccione) 224.4.4.1/32Bidirectional: (seleccione)PIM Message: (seleccione)BSR Static IP: (seleccione)Join/Prune: (seleccione)

WebUI (NS2)


Zone Name: TrustStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 10.4.1.1/24Seleccione NAT y luego haga clic en Apply.

> IGMP: Introduzca los siguientes datos, luego haga clic en Apply:

IGMP Mode: RouterProtocol IGMP: Enable (seleccione)










Address Name: corpIP Address/Domain Name:




222

3. PIM-SMNetwork > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance: Seleccione Protocol PIM: Enable, luego haga clic en OK.



Network > Interfaces > Edit (para tunnel.1) > PIM: Introduzca los siguientes datos, luego haga clic en Apply:


Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance > RP Address > New: Seleccione los siguientes datos y haga clic en OK:

Zone: Trust (seleccione)Address:10.4.1.1/24

4. VPN VPN > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK:

Gateway Name: To_CorpSecurity Level: CompatibleRemote Gateway Type:Static IP Address: (seleccione), IP Address/Hostname: 2.2.2.2Preshared Key: fg2g4h5jOutgoing Interface: ethernet3

> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return para regresar a la página de configuración básica de Gateway:


5. BGPNetwork > Routing > Virtual Router (trust-vr) > Edit: Introduzca los siguientes datos y haga clic en OK:

Virtual Router ID: Custom (seleccione)In the text box, enter 0.0.0.10

Network > Routing > Virtual Router (trust-vr) > Edit: Seleccione Create BGP Instance.




Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance > Neighbors: Introduzca los siguientes datos y haga clic en Add:

AS Number: 65000Remote IP: 2.2.2.2Outgoing Interface: ethernet3

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance > Neighbors > Configure (para el interlocutor que acaba de agregar): Seleccione Peer Enabled y luego haga clic en OK.

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance > Networks:

En el campo IP/Netmask, introduzca 4.1.1.0/24 y luego haga clic en Add.

En el campo IP/Netmask, introduzca 10.4.1.0/24, luego haga clic en Add.

Network > Interfaces > Edit (para ethernet3) > BGP: Seleccione Protocol BGP: Enable, luego haga clic en Apply.


Source Address:Address Book Entry: (seleccione), corp




MGroup Address: IP/Netmask (seleccione) 224.4.4.1/32Bidirectional: (seleccione)PIM Message: (seleccione)BSR Static IP: (seleccione)Join/Prune: (seleccione)

CLI (NS1)


2. Direccionesset address trust mgroup1 224.4.4.1/32set address untrust branch 10.4.1.0/24



224

3. PIM-SM set vrouter trust-vrset vrouter trust-vr protocol pim enableset interface ethernet1 protocol pimset interface ethernet1 protocol pim enableset interface tunnel.1 protocol pimset interface tunnel.1 protocol pim enable

4. Túnel VPNset ike gateway To_Branch address 4.1.1.1 main outgoing-interface ethernet3

preshare fg2g4h5j proposal pre-g2-3des-shaset vpn Corp_Branch gateway To-Branch3 sec-level compatibleset vpn Corp_Branch bind interface tunnel.1set vpn Corp_Branch proxy-id local-ip 10.2.2.0/24 remote-ip 10.4.1.0/24

5. BGPset vrouter trust-vr router-id 10set vrouter trust-vr protocol bgp 6500set vrouter trust-vr protocol bgp enableset vrouter trust-vr protocol bgp neighbor 4.1.1.1set vrouter trust-vr protocol bgp network 2.2.2.0/24set vrouter trust-vr protocol bgp network 10.2.2.0/24set interface ethernet3 protocol bgp enableset interface ethernet3 protocol bgp neighbor 4.1.1.1

6. Directivaset policy name To-Branch from untrust to trust branch any any permit



CLI (NS2)

1. Interfacesset interface ethernet 1 zone trustset interface ethernet 1 ip 10.4.1.1/24set interface ethernet 1 protocol igmp routerset interface ethernet 1 protocol igmp enableset interface ethernet 3 zone untrustset interface ethernet 3 ip 4.1.1.1/24set interface tunnel.1 zone untrustset interface tunnel.1 ip unnumbered interface ethernet3

2. Direccionesset address trust mgroup1 224.4.4.1/32set address untrust corp 2.2.2.0/24

3. PIM-SMset vrouter trust protocol pimset interface ethernet1 protocol pimset interface ethernet1 protocol pim enableset interface tunnel.1 protocol pimset interface tunnel.1 protocol pim enableset vrouter trust protocol pim zone trust rp proxyset vrouter trust protocol pim zone trust rp candidate interface ethernet1set vrouter trust protocol pim enable



4. Túnel VPNset ike gateway To_Corp address 2.2.2.2 main outgoing-interface ethernet3

preshare fg2g4h5j proposal pre-g2-3des-shaset vpn Branch_Corp gateway To_Corp sec-level compatibleset vpn Branch_Corp bind interface tunnel.1set vpn Branch_Corp proxy-id local-ip 10.4.1.0/24 remote-ip 10.2.2.0/24

5. BGPset vrouter trust-vr router-id 10set vrouter trust-vr protocol bgp 6500set vrouter trust-vr protocol bgp enableset vrouter trust-vr protocol bgp neighbor 2.2.2.2set vrouter trust-vr protocol bgp network 4.1.1.0/24set vrouter trust-vr protocol bgp network 10.4.1.0/24set interface ethernet3 protocol bgp neighbor 2.2.2.2

6. Directivaset policy name To-Corp from untrust to trust corp any any permit



PIM-SM e IGMPv3

Los dispositivos NetScreen admiten las versiones 1, 2 y 3 del protocolo de administración de grupos de Internet (IGMP). Si ejecuta PIM-SM con interfaces en IGMP v1 o v2, los hosts que reciben los datos para un grupo multicast pueden recibir datos desde cualquier origen que envíe datos al grupo multicast. Los informes de miembros de IGMP v1 y v2 sólo indican a qué grupos multicast desean unirse los hosts. No contienen información sobre los orígenes del tráfico de datos multicast. Cuando PIM-SM recibe informes de miembros IGMP v1 y v2, crea entradas (*, G) en la tabla de rutas multicast, permitiendo que cualquier origen realice envíos al grupo multicast. A esto se le llama modelo any-source-multicast (ASM), donde los receptores se unen a un grupo multicast sin conocer el origen que envía datos al grupo. La red cuenta con la información sobre el origen.

Los hosts que ejecutan IGMPv3 indican a qué grupos multicast desean unirse y desde qué orígenes esperan recibir tráfico multicast. El informe de miembro IGMPv3 contiene la dirección del grupo multicast, el modo de filtración, que es “include” o “exclude” y una lista de orígenes.

Si el modo de filtro es include, los receptores aceptan tráfico multicast solamente de las direcciones de la lista de origen. Cuando PIM-SM recibe un informe de miembros IGMPv3 con una lista de origen y un modo de filtro include, crea entradas (S, G) en la tabla de rutas multicast para todos los orígenes de la lista de origen.

PIM-SM e IGMPv3 225


226

Si el modo de filtro es exclude, los receptores no aceptan tráfico multicast de los orígenes que se encuentran en la lista; aceptan tráfico multicast del resto de orígenes. Cuando PIM-SM recibe un informe de miembros IGMPv3 con lista de origen y un modo del filtro exclude, crea una entrada (*, G) para el grupo y envía un mensaje prune para los orígenes de la lista de origen. En este caso, puede ser que necesite configurar un punto de encuentro si los receptores no conocen la dirección del origen.

PIM-SM e IGMPv3

Capítulo 10

Protocolo de descubrimiento de enrutador de ICMP

Este capítulo explica el protocolo de descubrimiento del enrutador del protocolo de mensajes de control de internet (ICMP) como se define en la norma RFC 1256. Incluye las siguientes secciones:


“Configuración del protocolo de descubrimiento de enrutador de ICMP” en la página 228

“Habilitación del protocolo de descubrimiento de enrutador de ICMP” en la página 228

“Configuración del protocolo de descubrimiento del enrutador de ICMP desde WebUI” en la página 228

“Configuración del protocolo de descubrimiento del enrutador de ICMP desde CLI” en la página 229

“Deshabilitación de IRDP” en la página 231

“Visualización de los ajustes de IRDP” en la página 231

Vista general

El protocolo de descubrimiento del enrutador de ICMP (IRDP) es un intercambio de mensajes de ICMP entre un host y un enrutador. El dispositivo de seguridad es el enrutador y notifica la dirección de IP de una interfaz especificada periódicamente o según solicitud. Si el host está configurado para escuchar, puede configurar el dispositivo de seguridad para que envíe notificaciones periódicamente. Si de manera explícita, el host envía solicitudes al enrutador, puede configurar el dispositivo de seguridad para que responda según la solicitud.

NOTA: IRDP no está disponible en todas las plataformas. Revise su hoja de datos para verificar si esta función está disponible a través de su dispositivo de seguridad.

Vista general 227


228

ScreenOS admite un IRDP por interfaz. Debe asignar una dirección de IP antes que el IRDP esté disponible en esa interfaz. De forma predeterminada, esta función está desactivada. Puede configurar esta función en un ambiente de alta disponibilidad (HA) con el protocolo de redundancia NetScreen (NSRP).

Configuración del protocolo de descubrimiento de enrutador de ICMP

Puede habilitar y deshabilitar el IRDP y configurar o ver los ajustes del IRDP con la WebUI o la CLI.

Habilitación del protocolo de descubrimiento de enrutador de ICMPCuando habilita el IRDP en una interfaz, ScreenOS inicia una notificación inmediata de IRDP en la red. Para obtener información sobre la configuración de una interfaz, consulte “Interfaces” en la página 2-33.

En el siguiente ejemplo, puede configurar IRDP para la interfaz Trust.

WebUI

Network > Interfaces (edit) > IRDP: Seleccione la casilla de verificación IRDP Enable.

CLI

set interface trust protocol irdp enable

Configuración del protocolo de descubrimiento del enrutador de ICMP desde WebUIPara configurar IRDP desde WebUI:

Network > Interface > Edit > IRDP: Introduzca los ajustes deseados, luego haga clic en OK.

La Tabla 20 enumera los parámetros de IRDP, valores predeterminados y ajustes disponibles.


Capítulo 10: Protocolo de descubrimiento de enrutador de ICMP

Tabla 20: Ajustes de IRDP en WebUI

Configuración del protocolo de descubrimiento del enrutador de ICMP desde CLIPuede configurar varios parámetros de IRDP desde la CLI para controlar cómo se lleva a cabo la notificación y solicitud.

Notificación de una interfazDe forma predeterminada, ScreenOS notifica la dirección IP primaria del dispositivo de seguridad; sin embargo, la dirección IP no se notifica para WebAuth y la administración.

También puede asociar un estado de preferencia para un dispositivo de seguridad. El estado de preferencia es un número del -1 al 2147483647. Los números mayores tienen una mayor preferencia. Puede asignar diferentes valores de preferencia para diferentes dispositivos de seguridad. Por ejemplo, puede asignar un número de preferencia mayor para el dispositivo de seguridad que principalmente maneja el tráfico de la red. Para un dispositivo de seguridad de respaldo, puede asignar un número de preferencia más bajo.

Para notificar la interfaz Untrust con una dirección IP de 10.10.10.10 con una preferencia de 250, introduzca los siguientes comandos.

set interface untrust protocol irdp 10.10.10.10 advertiseset interface untrust protocol irdp 10.10.10.10 preference 250save

Difusión de la direcciónDe forma predeterminada, excepto para el mensaje de notificación de difusión inicial cuando IRDP se habilita, la interfaz no envía notificaciones de difusión. La dirección predeterminada es 224.0.0.1 (todos los hosts en la red).

Para configurar la dirección de difusión predeterminada para la interfaz Untrust, introduzca el siguiente comando:

set interface untrust protocol irdp broadcast-address

Parámetro Ajustes predeterminados Ajustes alternativos

IPv4 address Direcciones de IP primaria y secundaria notificadas

Direcciones de IP de administración y de webauth no notificadas

Notificación, puede agregar un valor de preferencia (-1 al 2147483647)

Broadcast-address Desactivado Habilitada

Init Advertise Interval 16 segundos 1 a 32 segundos

Init Advertise Packet 3 1 al 5

Lifetime tres veces el valor del intervalo máximo de notificación

Valor de intervalo máximo de notificación de hasta 9000 segundos

Max Advertise Interval 600 segundos 4 a 1800 segundos

Min Advertise Interval 75% del valor del intervalo máximo de notificación

3 a través del valor del intervalo máximo de notificación

Response Delay 2 segundos 0 a 4 segundos

Configuración del protocolo de descubrimiento de enrutador de ICMP 229


230

Configuración de un intervalo máximo de notificaciónEl intervalo máximo de notificación es el número máximo de segundos que transcurre entre las notificaciones de ICMP. Este intervalo puede ser un valor de 4 a 1800 segundos. El valor predeterminado es de 600 segundos.

Para establecer el intervalo máximo de notificación en 800 segundos para la interfaz Untrust, introduzca los siguientes comandos:

set interface untrust protocol irdp max-adv-interval 800save

Configuración de un intervalo mínimo de notificaciónEl intervalo mínimo de notificación es el límite menor (en segundos) del período de notificación, el cual se calcula en el 75 por ciento del valor máximo de notificación. El rango del valor del intervalo mínimo de notificación es de 3 hasta el valor máximo de notificación. Cuando cambia el valor máximo de notificación, el valor del intervalo mínimo de notificación se calcula automáticamente.

Cuando establece el intervalo máximo de notificación en 800 segundos, ScreenOS vuelve a calcular automáticamente el intervalo mínimo de notificación en 600 segundos.

Para establecer el intervalo mínimo de notificación en 500 segundos para la interfaz Untrust, introduzca los siguientes comandos:

set interface untrust protocol irdp min-adv-interval 500save

Configuración de un valor de duración de la notificaciónDe forma predeterminada, el valor de duración de la notificación es tres veces el intervalo máximo de notificación. Puede establecer el valor de duración de la notificación. El rango del valor es el valor del intervalo máximo de notificación (4 a 1800 segundos) durante 9000 segundos.

Para establecer el valor de duración de la notificación en 5000 segundos para la interfaz Untrust, introduzca los siguientes comandos:

set interface untrust protocol untrust lifetime 5000save

Configuración de un retardo de respuestaDe forma predeterminada, el dispositivo de seguridad espera de 0 a 2 segundos antes de responder a una petición del cliente. Puede cambiar el ajuste de retardo de la respuesta a sin retardo (0 segundos) hasta un retardo de respuesta de cuatro segundos. Por ejemplo, si configura el retardo de respuesta en 4 segundos, el dispositivo de seguridad espera de 0 a 4 segundos antes de responder.

Para establecer un retardo, el valor de retardo de la respuesta en 4 segundos para la interfaz Untrust, introduzca los siguientes comandos:

set interface untrust protocol irdp response-delay 4save


Capítulo 10: Protocolo de descubrimiento de enrutador de ICMP

Configuración de un intervalo de notificación inicialEl intervalo de notificación inicial es el número de segundos durante el período de inicio del IRDP asignado para la notificación. De forma predeterminada, este intervalo es de 16 segundos. El rango del valor para este intervalo es de 1 a 32 segundos.

Para establecer el Intervalo de notificación inicial en 24 segundos para la interfaz Untrust, introduzca los siguientes comandos:

set interface untrust protocol irdp init-adv-intervalsave

Configuración de un número de paquetes de notificación inicialDe forma predeterminada, el dispositivo de seguridad envía tres paquetes de notificación durante el período de inicio especificado. Puede cambiar este ajuste de 1 al 5.

Para cambiar el número de paquetes iniciales enviados a 5, introduzca los siguientes comandos:

set interface untrust protocol irdp init-adv-packet 5save

Deshabilitación de IRDP

Puede inhabilitar una interfaz para impedirle la ejecución de IRDP, pero en tal caso ScreenOS borrará toda la memoria relacionada con la configuración original.

Para inhabilitar la interfaz Trust e impedirle que ejecute IRDP, introduzca el siguiente comando:

unset interface trust protocol irdp enable

Visualización de los ajustes de IRDP

Puede ver la información de IRDP en la WebUI o en la CLI.

Para ver los ajustes de IRDP, introduzca los comandos get irdp o get irdp interface nombre_interfaz.

WebUI

Network > Interface > Edit > IRDP: Puede ver si el IRDP está habilitado.

CLI 1

device> get irdp

Total 1 IRDP instance enabled----------------------------------------------------------------interface dest-addr lifetime adv-interval Next-Adv(sec)----------------------------------------------------------------untrust 255.255.255.255 6000 450 to 600 358

Deshabilitación de IRDP 231


232

CLI 2

device-> get irdp interface untrust

IRDP enabled on untrust:advertisement interval : 450 to 600 secnext advertisement in : 299 secadvertisement lifetime : 6000 secadvertisement address : 255.255.255.255initial advertise interval : 16 secinitial advertise packet : 3solicitation response delay : 4 sec10.100.37.90 : pref 250, advertise YES

Visualización de los ajustes de IRDP

Índice
AÁreas OSPF.....................................................................48
definición .................................................................54interfaces, asignación a ..........................................55

BBGP

atributos de ruta ....................................................111comunidades .........................................................133confederaciones ....................................................131configuraciones, seguridad ..................................120configuraciones, verificación ...............................119enrutador ...............................................................112enrutador virtual, creación de una instancia en113equilibrio de carga ..................................................37expresiones regulares ...........................................124interno ....................................................................112introducción al protocolo .....................................110lista de acceso AS-path .........................................124parámetros.............................................................122tipos de mensaje ...................................................110vecinos, autenticación ..........................................120

BGP, configuracióngrupos de interlocutores.......................................115interlocutores.........................................................115pasos.......................................................................112

BGP, habilitaciónen interfaz ..............................................................114en VR ......................................................................113

Ccircuitos de demanda, RIP..........................................101configuración punto a multipunto

OSPF .........................................................................71consulta de rutas

múltiple VR ..............................................................35secuencia..................................................................33

Ddirectivas

multicast.................................................................163

EECMP.........................................................................37, 61Encapsulado de enrutamiento genérico (GRE).........161Enrutadores BGP

adición ....................................................................125agregación..............................................................134atributos, configuración........................................126notificación condicional........................................125peso, establecimiento ...........................................126predeterminado, rechazo .....................................121redistribución.........................................................123reflexión .................................................................129supresión ................................................................134

Enrutadores OSPFadyacencia ...............................................................50creación de instancia OSPF en enrutador

virtual .....................................................................53designado .................................................................50designado de respaldo............................................50tipos ..........................................................................49

Enrutadores RIPalternativa ................................................................99rechazo predeterminado ........................................94redistribución...........................................................84resumen, configuración..........................................98

enrutadores virtualesvéase VR

enrutamiento estático ...........................................1, 2 a 9configuración .............................................................4Interfaz Null, reenvío en.........................................10multicast .................................................................160utilización ...................................................................3

enrutamiento multicastIGMP .......................................................................165PIM..........................................................................191

enrutamiento según el origen (SBR)............................18enrutamiento según la interfaz de origen (SIBR) .......20enrutamiento, multicast..............................................157equilibrio de cargas según coste de cada ruta......37, 61

IIGMP

configuración, básica ............................................169configuración, verificación...................................171consultador ............................................................167

Índice IX-I

IX-II


directivas, multicast.............................................. 178interfaces, habilitar en.......................................... 167listas de accesos, uso............................................ 168Mensajes de host................................................... 166parámetros .................................................... 171, 172

interfaces, habilitar IGMP en...................................... 167Interfaz Null, definiendo las rutas con........................ 10

Llistas de acceso

enrutamiento multicast ........................................ 161IGMP ....................................................................... 168para rutas ................................................................. 41PIM-SM ................................................................... 211

Mmulticast

árboles de distribución......................................... 194direcciones............................................................. 158directivas................................................................ 163directivas para IGMP............................................. 178reenvío por rutas inversas ................................... 158rutas estáticas........................................................ 160tablas de enrutamiento ........................................ 159

Multicast independiente de protocolovéase PIM

NNúmeros de sistema autónomo (AS) ........................ 113

OOpen Shortest Path First

véase OSPFOSPF

área de rutas internas............................................. 49área no exclusiva de rutas internas ...................... 49conexiones virtuales ............................................... 62configuración de seguridad.................................... 67equilibrio de carga .................................................. 37interfaces, asignación a áreas ............................... 55interfaces, túnel....................................................... 71inundación, LSA reducida ...................................... 71inundaciones, protección contra........................... 69LSA, supresión......................................................... 70notificaciones de estado de conexiones............... 48parámetros de interfaz........................................... 64parámetros globales ............................................... 61pasos de configuración........................................... 52protocolo de saludo ................................................ 50punto a multipunto ................................................. 71red punto a punto ................................................... 50redes de difusión..................................................... 50soporte de ECMP..................................................... 61tipo de conexión, establecimiento........................ 72

vecinos, autenticación ............................................67vecinos, filtrado.......................................................68

PPIM-SM..........................................................................193

configuración de puntos de encuentro...............209configuraciones de seguridad ..............................211enrutador designado.............................................194IGMPv3 ...................................................................225instancias, creación ..............................................199parámetros de interfaz .........................................214pasos de configuración.........................................198proxy RP ................................................................215puntos de encuentro.............................................195tráfico, reenvío ......................................................195

PIM-SSM........................................................................197Protocolo de administración de grupos de Internet

véase IGMPProtocolo de información de enrutamiento

véaseRIPProxies de IGMP ..........................................................173

emisor.....................................................................185en interfaces ..........................................................176

RRIP

autenticación de vecinos........................................92base de datos...........................................................99configuración de circuito de demanda...............101equilibrio de carga ..................................................37filtrado de vecinos...................................................93instancias, creación en VR.....................................82interfaces, habilitar en............................................83inundaciones, protección contra...........................94parámetros de interfaz ...........................................90parámetros globales................................................89punto a multipunto ...............................................103resumen de prefijo..................................................98versiones ..................................................................96versiones, protocolo................................................96

RIP, configuracióncircuitos de demanda ...........................................101pasos.........................................................................81seguridad..................................................................92

RIP, visualizaciónbase de datos...........................................................86detalles de interfaz..................................................88detalles de protocolo...............................................86información de vecinos..........................................87

rutasexportación..............................................................43filtrado ......................................................................41importar ...................................................................43mapas .......................................................................39

Índice

Índice

métricas....................................................................32preferencia...............................................................31redistribución...........................................................38selección...................................................................31

Rutas BGP, agregadasagregación..............................................................134AS-Path en..............................................................136AS-Set en ................................................................134atributos de ............................................................137

Rutas OSPFpredeterminadas, rechazo .....................................69redistribución...........................................................59redistribuido, resumen ...........................................60restricción route-deny, inhabilitación...................72

SSupresión de notificaciones de estado de conexiones

(LSA) .............................................................................70

Ttablas de enrutamiento .................................................15

consulta ....................................................................33consulta en múltiples VR........................................35multicast.................................................................159selección de rutas....................................................31tipos ..........................................................................15

VVR ............................................................................38 a 44

BGP ...............................................................112 a 120ECMP ........................................................................37en vsys......................................................................27ID de enrutador .......................................................23listas de acceso ........................................................41métricas de ruta ......................................................32modificar ..................................................................22OSPF .................................................................51 a 70RIP.....................................................................81 a 96SBR............................................................................18SIBR...........................................................................20uso de dos ................................................................24

VR, rutasexportación ..............................................................43filtrado ......................................................................41importar....................................................................43mapas .......................................................................39preferencia ...............................................................31redistribución...........................................................38selección...................................................................31

VR, tablas de enrutamientoconsulta ....................................................................33consulta en múltiples VR........................................35entradas máximas...................................................30

Índice IX-III

IX-IV


Índice

juniper

Documents

provide reasonable

consideraciones

haga clic

en caso afirmativo

en primer

en caso negativo

convenciones

en este caso