¿Es posible influir remotamente en BGP localpref?

17

Un colega está tratando de implementar Internet multihoming activo / pasivo. El diseño implica el envío de comunidades (enumeradas a continuación) al proveedor pasivo para reducir la preferencia local en ASes remotos para las rutas anunciadas. La documentación establece repetidamente que las comunidades son para uso del cliente y que no somos clientes de estos proveedores. Creo que dar a Internet en general la capacidad de alterar las preferencias locales es un gran riesgo de seguridad. ¿Tendría esto la posibilidad de una bola de nieve en el infierno de realmente funcionar?

1273:70     cable and wireless plc local pref 70
2828:1507   xo local pref 70
3356:70     level3 local pref 70
3549:100    global crossing local pref 100
4323:80     twtelecom local pref 80
1299:50     teliasonera local pref 50

bgp

— Dennis Olvany
fuente

1

¿Es 'onestep' su propio proveedor de respaldo? Si es así, entonces asegúrese de que deberían funcionar bien cuando se anuncian en 'onestep' y, en mi opinión, es preferible el diseño antes que el prepend. De lo contrario, son inútiles, incluso si sus rutas los pasaran, es poco probable que trabajen de sus pares. ¿Su vecino directo no proporciona una lista comparable?

— ytti 01 de

One Step no es nuestro proveedor. Por lo que deduzco, One Step no es un proveedor en absoluto. El vecino directo puede tener esa lista. Tendré que investigar un poco.

— Dennis Olvany 01 de

2

OneStep es una consultoría que agrega guías comunitarias de todos los NSP.

— generalnetworkerror

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.

— Ron Maupin

15

Es poco probable (pero no imposible) que las comunidades que etiquete en sus rutas se propaguen más allá de su río arriba. La mayoría de los proveedores despojarán a las comunidades antes de volver a leer las rutas hacia arriba / abajo.

Si desea influir en múltiples ASes remotos de esta manera, necesitará usar AS_PATH antes de. Anteponga 2-3 veces a su proveedor de respaldo / pasivo, y luego la mayoría / todo el tráfico fluirá por su ruta activa hasta que falle. Luego, el tráfico debe cambiar a su ruta pasiva una vez que se retire la ruta fallida.

— Justin Seabrook-Rocha
fuente

44

Si el cliente A tiene tránsito del proveedor P1 y P2 y antepone a P2. Luego, otro cliente B de P2 puede recibir rutas local_pref recibidas de P2 (tal vez sea más barato), es decir, el hecho de anteponer no garantiza que todo el tráfico cambiará y no hay una forma real de garantizar esto en BGP, además de extraer la ruta de las rutas no preferidas o filtrando más detalles al socio preferido, ninguno de los cuales puede ser recomendado.

— ytti 01 de

2

¡Correcto! De ahí la eterna lucha de la ingeniería de tráfico, cómo influir en una red con la que no tiene relación. Probablemente debería haber dicho "la mayoría" en lugar de "todos", pero el antecedente y más detalles son realmente las dos únicas opciones que realmente pueden tener un efecto en este caso.

— Justin Seabrook-Rocha

3

Como dijo ytti, los trucos de AS_PATH son, en el mejor de los casos, una sugerencia. Al final del día, las preferencias del administrador local ganarán. Si quiero que el tráfico a una red específica cruce un enlace específico, lo hará ; Internet no puede hacer nada para cambiar mi configuración de enrutamiento.

— Ricky Beam

6

El proveedor debe tener un filtro entrante para garantizar que estas comunidades solo sean aceptadas por los clientes. Si no, entonces ese es el problema de los proveedores.

Sin embargo, algunos proveedores de Nivel 1 aceptan este tipo de comunidades desde cualquier lugar. Esto se basa en RFC 1998: http://tools.ietf.org/html/rfc1998.html

— mellowd
fuente

El consenso parece claro. Parece que influir en la preferencia local de AS remotos es casi imposible.

— Dennis Olvany 01 de

5

Lo mejor que puede hacer generalmente es buscar comunidades con su proveedor que le permitan indicar los preparativos por par de su proveedor. Esto supone que su proveedor tiene tales comunidades y tiene las relaciones de pares para que esto funcione. Anteponer sus propios anuncios a sus pares no tendría variación aguas arriba de su proveedor. Aunque este método no altera localpref one AS eliminado de su proveedor, tiene un impacto similar al hacer que ese camino de regreso a usted sea menos deseable. Hay una excepción para influir en localpref aguas arriba que describiré en la parte inferior, aunque probablemente sea un caso extremo.

Algunos proveedores como XO [AS2828] le permiten anunciar sus prefijos de tal manera que su proveedor anuncie sus rutas con antecedentes específicos para ciertos pares de ellos.

Por ejemplo, XO acepta:

2828:1108se antepone una vez para AT&T, se
2828:1207antepone dos veces para el Nivel
2828:13033 y tres veces para Sprint

En Savvis, la comunidad es la 3561:30151que antecede una vez a AT&T.

Estos proveedores generalmente tienen comunidades para indicar las comunidades conocidas de NO_EXPORT o NO_ADVERTISE a pares específicos.

Un proveedor de Nivel 2 que conozco, InterNAP, es capaz de influir en la preparación local aguas arriba porque compran transporte público, por lo que son clientes de Nivel 1. Tienen comunidades que puede utilizar cuando intentan traducirlas en comunidades específicas de Nivel 1 para sus anuncios ascendentes que establecen la preferencia local en valores de nivel de pares , medios o altos. Ver http://www.onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf .

Referencias de ejemplo:
Comunidades XO que cambian anuncios de clientes a ciertos pares en AS2828 Border
Savvis prefieren atributos de la comunidad

No estoy afiliado con los proveedores utilizados en los ejemplos, aparte de la experiencia directa como cliente.

— generalnetworkerror
fuente