Configuración de directivas de enrutamiento

Bloques de creación: Reglas básicas de filtrado

A continuación, abordaremos las directivas que se mencionarán con otras políticas. No son únicos por cliente/igual/tránsito y sólo deben definirse una vez.

En esta sección no se muestran las políticas reales. Sin embargo, cortará y pegará las listas de prefijos relevantes y los grupos de rutas, que se utilizan en las políticas más adelante en el capítulo.

Rechazar Bogon números de sistema autónomos

Un anuncio de BGP ruta contiene un campo, llamado ruta, queconsta de los números de sistema autónomo de todas las redes que propagan el anuncio de ruta para llegar a su destino, el número de sistema autónomo original.

Las rutas AS que ve en su tabla de enrutamiento se crean automáticamente a medida que cada red que propaga un anuncio de ruta antepone su número de sistema autónomo propio a la ruta de acceso. Por último, es posible anteponer manualmente un número de sistema autónomo para influir en las decisiones de enrutamiento.

Además de los números de sistemas autónomos públicos asignados por el RIRs, existen números de sistemas autónomos privados que deben usarse para distintos fines (como un emparejamiento privado con redes que no necesitan un número de sistema autónomo asignado a RIR).

Todos los números de sistema autónomos solían ser números de 16 bits (desde 0 hasta 65.535), pero estos días se admiten universalmente números de sistema autónomos de 32 bits. Los distintos tipos de sistemas autónomos núm-BERS son:

• 0: Reservados

• 1 a 64.495: números del sistema autónomo público

• 64.496 a 64.511: reservado para usar en la documentación

• 64.512 a 65.534: números de sistemas autónomos privados

• 65,535: Reservados

• 4,2 mil millones a 4.294.967.294: números de sistemas autónomos privados de 32 bits

Un uso popular de números de sistemas autónomos privados consiste en utilizar dichos números (de una lista de números de sistemas autónomos privados) para las redes que no tienen un número de sistema autónomo asignado por un RIR con el fin de establecer una sesión BGP con una red upstream. En este caso, los errores son fáciles de hacer. Los números de sistemas autónomos privados pueden perderse accidentalmente en una ruta de acceso pública. O, en ocasiones, un operador de red escribirá el número de sistema autónomo que desea anteponer, contaminando la ruta de acceso que ha recibido. Por lo tanto, debe rechazar los anuncios de ruta que contengan un número de sistema autónomo privado o reservado.

Los números de sistema autónomos de Bogon se definen en las RFC. La siguiente lista muestra exactamente qué RFC describe el número de sistema autónomo de Bogon, por lo que si desea obtener más información acerca de por qué un determinado número de sistema autono-Mous no debe encontrarse en su tabla de enrutamiento segura, puede consultar la RFC pertinente.

Definir un as-path Grupo que enumera los números del sistema autónomo de Bogon:

Para ello, escriba los siguientes comandos:

Recuerde que aún no se trata de la política real. La política que llama a estas listas de prefijos está próxima, por lo que debe leer algunos párrafos más.

Con esta Directiva, los enrutadores filtrarán las rutas que reciba desde fuera y que pueden contener un número de sistema autónomo privado. Para evitar que se anuncien (envíen) números de sistemas autónomos privados desde su red, es una buena práctica en las operaciones DFZ para permitir el remove-private opción en sesiones de EBGP.

Por ejemplo:

Asegúrese de que tiene esta opción establecida en todas las sesiones de EBGP.

Rechazar Bogon prefijos

Un prefijo de Bogon no debe ser visible en la tabla de enrutamiento global, ya que estos prefijos están diseñados para uso interno (RFC 1918), redes de prueba (RFC 4737), multidifusión y otros fines internos. Por lo tanto, estos prefijos nunca deben aceptarse ni anunciarse a DFZ.

Puede crear una lista de prefijos como se indica a continuación:

Para ello, escriba los siguientes comandos:

Lo mismo para comandos IPv6:

La política que llama a estas listas de prefijos es próxima, solo unos cuantos párrafos más!

Rechazar prefijos largos

La tabla de enrutamiento global de la DFZ se expande diariamente, a medida que cada vez más redes comienzan anuncian más y más prefijos. En principio, no hay ningún problema al anunciar las rutas de cualquier – longitud técnicamente, ni siquiera una ruta/32 (para una dirección IPv4 única). Sin embargo, el crecimiento no controlado de la tabla de enrutamiento no es sostenible (simplemente calcule cuánto más grande sería el DFZ si todo el espacio IPv4 se anunciase como/32). Muchas redes han empezado a filtrar por su longitud de prefijo.

En estos días normalmente es posible que se descarte el anuncio si se anuncia un prefijo de/25 o más, es decir, una subred de 128 direcciones IPv4 o menos). La siguiente política configura su red para hacer lo mismo, por lo que todas estas rutas’molestas nos/28 y/32 no lo convierten en su nervio. Esto mismo se aplica a IPv6 donde colocamos el límite en/48 subredes.

Las políticas para filtrar rutas para estos prefijos largos aparecen más adelante en este capítulo. Constan de dos pasos: una directiva genérica a la que se llama y que sólo devuelve prefijos de longitud suficiente, y una directiva que toma esta lista y filtra solo las rutas relevantes de la misma.

Rechazar durante un tiempo como rutas

Vemos’que antes de que cada red de la ruta genere “” automáticamente un ruta as, agregando su propio número de sistema autónomo al principio de la ruta as de la ruta anunciada. En la práctica, dado que BGP busca la ruta más corta de forma predeterminada, la mayoría de las rutas activas que usa su red tendrán una ruta de acceso de solo 1-6 de números de sistema autónomos. Es posible que a veces un path sea más largo y, por supuesto, existe un manual como ruta de acceso pendiente (como medida de ingeniería de tráfico), lo que hace que se vean rutas más largas en la tabla. Pero generalmente hablando, un camino tan largo como una docena de sistemas autónomos puede considerarse inútil. Si observa una duración tan larga como ruta de acceso, es probable que sea el trabajo de un administrador de red que necesite una copia de este libro.

La razón más común de tiempo que dura la espera de las rutas de la ruta. El uso de dos a tres veces su propio número de sistema autónomo en una Prepend es, cuando es necesario, considerado una buena práctica para influir en las rutas. Sin embargo, en espera de más de la’t tiene sentido. Observando el DFZ, en el momento de escribir este punto, existen algunos prefijos con una ruta de acceso de unos 40 números de sistema autónomos, lo que es muy útil. Deje’que un s tome un margen seguro y considere la posibilidad de todo lo que tenga un camino de más de 50 para ser inútil y que permita filtrarse en nuestra tabla de enrutamiento segura.

Como siempre, defina lo que desea filtrar primero:

Y, a continuación, siga leyendo para llegar a la Directiva en la que llamamos a esta definición. Solo un bloque de creación más.

Rechazar rutas que contengan números de sistemas autónomos en tránsito o en red de gran tamaño

Las redes más grandes del mundo (conocidas principalmente como “nivel 1”) nunca compran tránsito entre sí o desde redes pequeñas (“de nivel 2”). Por ejemplo, sería muy extraño que el cliente o el interlocutor empezara a enviar rutas que tienen AS2914 (NTT) o AS1299 (Telia) en su ruta de AS; no es muy probable que NTT o Telia compre el tránsito de su cliente. Por lo tanto, la Directiva de importación también contiene como filtros de ruta de acceso que rechazan rutas “que tienen” el número as de los nombres grandes. Si los recibiera legítimamente de un cliente o un interlocutor, es probable que usted no sea el público al que va dirigido este libro.

Lo mismo ocurre con algunas de las otras redes de gran tamaño, como Facebook, Google, Microsoft y CloudFlare. Es probable que no compren el tránsito de sus colegas, por lo que si recibe sus vías de sus colegas, debe realizarse algún pez pesquero . Entonces, ¿por qué no asegurarse’de que ganó el uso de cualquiera de estas rutas, lo que sabe que no es correcto en primer lugar?

Primero, deje’que defina el grupo de rutas as:

Si utiliza esto como grupo de ruta en la’Directiva que se está acumulando, se protegerá de la aceptación de rutas que sus clientes o sus colegas no pierdan accidentalmente. Más adelante se mostrará cómo esto encaja en la imagen más grande.

Asegúrese de agregar esta directiva solo a las sesiones del cliente y del mismo nivel BGP (y no a los tránsitos), o bien que acabe con una tabla de enrutamiento muy pequeña (y muy limitada) de uso.

Rechace el resto

De forma predeterminada, la última acción de la Junos OS implementación de BGP es permitir todo lo que queda después de las directivas. El comportamiento predeterminado será configurable en el futuro para cumplir con las especificaciones BGP-4 y según se define en la https://tools.ietf.org/html/rfc8212. Sin embargo, en el momento de redactar este libro, RFC8212’hasn t ha sido implementado, por lo que debe asegurarse de que dispone de una política para rechazar el resto.

Defina una directiva que simplemente rechace todas las rutas que vea:

O en comandos cortar y pegar:

Esta Directiva se utiliza más adelante para crear un rechazo explícito, lo que significa que no depende de lo que el protocolo (BGP) haga al final de una cadena de políticas. Siempre es mejor hacer su configuración clara y explícita (piense en su administrador de red más Junior teniendo que solucionar un corte de la red a las 4 AM).

Filtrado de rutas de clientes

Por último,’es hora de configurar alguna directiva de enrutamiento real. En primer lugar’, veamos cómo filtrar rutas que reciba de sus clientes y cómo configurar una directiva para anunciar rutas a sus clientes, tanto para la ruta predeterminada como para las situaciones de tabla completa.

Aceptación de rutas de clientes

La comprobación de las rutas aceptadas por los clientes es la más importante en la configuración de su red. Al final, debe anunciar las rutas del cliente’s a otras personas. Estos anuncios deben estar limpios y contener únicamente información – de enrutamiento correcta, por lo’que es posible que s empiece por aceptar sólo rutas limpias’y, por lo tanto, no tiene que preocuparse de poner la detención de Internet.

La Directiva de enrutamiento que utilizará para filtrar las rutas recibidas de los clientes incluirá una lista de los prefijos que puede anunciar el cliente. En este ejemplo, puede configurar manualmente la lista de prefijos, pero’en el apéndice ll encontrará la manera de obtener las listas de prefijos para actualizar automáticamente. Después de finalizar este libro, debe sentirse cómodo con esta configuración para filtrar’las rutas del cliente y’no olvidarse de implementar actualizaciones automáticas de prefijos de lista para que la tabla de enrutamiento permanezca segura.

La siguiente configuración supone que su cliente’es el número 123 y que estará anunciando 192.0.2.0/24 y 2001: db8::/32. También se supone que el propio número es el 456:

Para configurarlos, debe especificar:

Además, supongamos’que cree dos BGP comunidades que usen las políticas, así como una más que necesitará más adelante, según:

Al crear una ruta ‘’ de delimitador de descarte para que origine su prefijo, puede unir esta comunidad a la misma:

Ahora, en las políticas que aceptarán realmente las rutas’del cliente. Todo comienza aceptando el prefijo exacto que se permite que anuncien según el prefix-list:

Para configurar esto, escriba:

Esta política es exclusiva de cada BGP cliente que tenga, igual que cada lista de prefijos es exclusiva de cada cliente BGP. Aplica esta política de importación en la sesión de BGP con su cliente en la cadena de directivas de importación.

Agregamos la comunidad BGP MYCUSTOMER a las rutas aceptadas del cliente. Esto facilita la tarea de exportar estas rutas posteriormente.

A continuación, su cliente puede anunciar prefijos más específicos para usted. La entrada de la lista de prefijos puede tener definido un/22, por ejemplo, pero desea permitir a su cliente que anuncie hasta el/24. Simplemente con prefix-list-filter AS123 orlonger ’no funciona, ya que esto permitiría al cliente anunciar hasta el/32. Por lo tanto, cree primero una directiva que permita rutas hasta/24 y, a continuación, combínelo con la Directiva que permite estas rutas si se encuentran en la lista de prefijos de clientes:

Tenga en cuenta que policy-statement MORE-SPECIFIC-UPTO-24 es genérico – sólo se configura una vez en el enrutador y se utiliza para todos los clientes. El servicio policy-statement IMPORT-123 No obstante, es único para cada cliente, por lo que debe configurarse una vez por cliente.

Estas políticas se configuran especificando:

La política MORE-SPECIFIC-UPTO-24 solo se debe definir una vez. No se’hace referencia a los clientes como o prefijos en esta Directiva. La política IMPORT-123 sin embargo, debe definirse una vez por cliente.

La misma lógica se aplica a las políticas de IPv6, donde acepta rutas hasta/48:

Para configurar esto, escriba:

Al igual que con las políticas de IPv4, la Directiva MORE-SPECIFIC-UPTO-48-INET6 solo se debe definir una vez. No se’hace referencia a los clientes como o prefijos en esta Directiva. La política IMPORT-123-INET6 sin embargo, debe definirse una vez por cliente.

Por último, puede optar por permitir que sus clientes anuncien a usted – más enrutas específicas que a/24. Por ejemplo, podrían utilizar estas rutas para la ingeniería del tráfico. Si bien puede llevarlos a la red, no debe anunciarlos a otros clientes, colegas o tránsitos. Esta es la razón por la que lo aceptaremos aquí, pero agregar el conocido“NO-EXPORT”BGP comunidad:

Para configurar esto, escriba:

Y para IPv6:

Para configurar esto, debe escribir:

Ahora que se’ha definido la política de importación para las’rutas del cliente, es posible que se pregunte dónde final reject la Directiva que rechazará las rutas que no se permita que anuncie el cliente sea. Se’renueva correctamente del – curso esta es la Directiva completa que se utilizará para importar rutas de sus clientes:

La configuración BGP

La última parte de la configuración para importar las rutas de clientes consiste en configurar las políticas como políticas de importación en la BGP sesión con el cliente. Recuerde que la primera Directiva, TRANSIT-CUSTOMER-GENERIC, es genérico y debe definirse solo una vez; la segunda política es tan específica. Cada cliente cuenta con tres políticas encadenadas:

1. La Directiva genérica que rechaza las rutas no deseadas;

2. La política específica del cliente que acepta las rutas’del cliente;

3. Política de rechazo final que rechaza todo lo demás.

Por ejemplo:

Otro cliente sería:

Anuncio de las rutas a los clientes

Sus clientes reciben las rutas’de red s, lo que les permite utilizar su red para enviar tráfico. Puede ser una tabla completa o una ruta predeterminada. Si desea enviar a sus clientes una ruta predeterminada, asegúrese de generar uno mediante la creación de una ruta predeterminada de descarte.

Después de leer los ejemplos para exportar las exportaciones de la tabla completa y la ruta predeterminada, debe ser fácil crear un reabastecimiento de políticas a aquellos clientes que deseen recibir una tabla completa, así como una ruta predeterminada.

Anunciar una tabla completa a los clientes

La Directiva para enviar una tabla completa es más complicada de lo que parecería. Es necesario quitar rutas que tengan el NO-EXPORT comunidad, por ejemplo. ’Y no se olvide de agregar un término que acepte las rutas que su propia red tiene – un error muy común es enviar al cliente de tránsito sólo las rutas que ha aprendido a través de EBGP (que es BGP comportamiento predeterminado) y no incluir sus propias rutas:

O en el formato de cortar y pegar:

Anuncio de un valor predeterminado para los clientes

Las políticas para enviar una ruta predeterminada a los clientes son sencillas:

O en comandos cortar y pegar:

Esto funcionará si ya tiene una ruta predeterminada en su red. Recuerde nuestra ADVERTENCIA anterior en caso de que’no disponga de una.

La configuración BGP

La última parte de la configuración para exportar rutas a los clientes es configurar las políticas como políticas de exportación en la BGP sesión con el cliente. Todas las políticas de exportación son genéricas y sólo deben definirse una vez. Cada cliente cuenta con dos políticas encadenadas:

1. La Directiva genérica que acepta rutas de tabla predeterminadas o completas.

2. Política de rechazo final que rechaza todo lo demás.

Por ejemplo:

Otro cliente sería:

Filtrado de rutas de interconexión de tráfico

Las políticas para los interlocutores son un poco distintas a las de los clientes, pero no de forma muy importante. Para los pares, rechaza las mismas rutas que para los clientes y usted acepta rutas dentro de su conjunto como (si se ha implementado el filtrado automático de prefijos). Por supuesto, rechaza rutas predeterminadas, RPKI inválidas, Long AS paths y bogons. Los únicos cambios importantes consisten en tener una preferencia local distinta (por debajo de las rutas de clientes), sin agregar el BGP comunidad para exportar las rutas de iguales, y no permitir un prefijo mayor que/24.

Aceptar rutas de los interlocutores

Se trata de la instrucción de Directiva completa para la importación de rutas desde los elementos del mismo nivel:

O en el formato de cortar y pegar:

La configuración BGP

La última parte de la configuración para importar rutas de igual es configurar las directivas como políticas de importación en la sesión de BGP con el interlocutor. Recuerde que la primera Directiva, PEER-GENERIC, es genérico y debe definirse solo una vez; la segunda política es tan específica. Cada interlocutor tiene tres políticas encadenadas:

1. La Directiva genérica que rechaza las rutas no deseadas.

2. La Directiva específica del mismo nivel que acepta las’rutas del mismo nivel.

3. Política de rechazo final que rechaza todo lo demás.

Por ejemplo:

Anuncio de las rutas a los interlocutores

Sus colegas deben recibir sus propias rutas y las rutas de sus clientes. Afortunadamente, hemos utilizado BGP las comunidades para etiquetar estas rutas, por lo que es muy fácil crear las correspondientes instrucciones de políticas:

O en el formato de cortar y pegar:

La configuración BGP

La última parte de la configuración para exportar rutas a los pares consiste en configurar las políticas como políticas de exportación en la sesión de BGP con el interlocutor. Todas las políticas de exportación son genéricas y sólo deben definirse una vez. Cada interlocutor tiene dos políticas encadenadas:

1. La Directiva genérica que acepta las rutas y rutas de clientes.

2. Política de rechazo final que rechaza todo lo demás.

Por ejemplo:

Filtrar rutas de tránsito

Las políticas de los proveedores de tránsito vuelven de nuevo un poco diferentes de las que se aplican a los colegas, pero de nuevo no lo son de mucho. Para los tránsitos, rechaza las mismas rutas que para los interlocutores: rutas predeterminadas, inRPKI invalids, Long AS paths y bogons. Los únicos cambios importantes consisten en aceptar rutas “de las” redes de gran tamaño en lugar de rechazarlas, tomando una preferencia local distinta (más bajas que las rutas de los homólogos), sin agregar el BGP comunidad para exportar las rutas de tránsito, y aceptar todas las rutas restantes en lugar de rechazarlas.

Aceptación de rutas de tránsitos

Se trata de la declaración de la Directiva completa para la importación de rutas desde tránsitos:

O en el formato de cortar y pegar:

La configuración BGP

La última parte de la configuración para importar las rutas de tránsito consiste en configurar las políticas como políticas de importación en la sesión de BGP con el proveedor de tránsito. Recuerde que la primera política, genérica de tránsito, es genérica y debe definirse solo una vez; la segunda política es tan específica. Cada tránsito tiene tres políticas encadenadas:

1. La Directiva genérica que rechaza las rutas no deseadas.

2. La Directiva específica de tránsito que acepta las rutas’s de tránsito.

3. Política de rechazo final que rechaza todo lo demás.

Por ejemplo:

Anuncio de rutas a los tránsitos

Los traspasos deben recibir sus propias rutas y las rutas de sus clientes. Al igual que con la exportación de rutas a los colegas, aquí usamos las comunidades de BGP para etiquetar estas rutas, por lo que es muy sencillo crear las instrucciones de directiva relevantes:

Y en el formato de cortar y pegar:

La configuración BGP

La última parte de la configuración para exportar rutas a tránsitos consiste en configurar las políticas como políticas de exportación en la BGP sesión con el tránsito. Todas las políticas de exportación son genéricas y sólo deben definirse una vez. Cada tránsito tiene dos políticas encadenadas:

1. La Directiva genérica que acepta las rutas y rutas de clientes.

2. Política de rechazo final que rechaza todo lo demás.

Por ejemplo:

Conclusión

Desde una perspectiva de políticas, los enrutadores ahora tienen lo que se necesita para filtrar rutas, crear una tabla de enrutamiento segura y comunicarse BGP con sus clientes, colegas y proveedores de tránsito. Su red debe estar en buenas formas. ¡ Bien hecho!

Es posible que haya observado que no configuramos políticas para filtrar las rutas que se originan en las sesiones del cliente, del mismo nivel y de tránsito. Esto se hizo a propósito, ya que, por naturaleza BGP, filtrará los anuncios que contengan un número propio para evitar los bucles. Si recibe un anuncio de ruta que contiene el prefijo pero originado por un número distinto, RPKI lo filtrará si ha creado ROAs. Sin embargo, nunca es malo filtrar explícitamente sus propias rutas en todas las sesiones eBGP.

A continuación, algunas maneras de comprobar si las cosas son correctos y qué hacer si’no son así.