Podcast: Descargar (31.5MB)
Si sois un ISP o una empresa ya con un tamaño, tenéis vuestro propio Sistema Autónomo y al menos dos tránsitos de BGP estáis en disposición de montar dos routers frontera de BGP y de independizaros un poco de las empresas que hasta ahora os estaban proporcionando la conectividad a Internet para vuestra infraestructura.
Os sorprendería la cantidad de ISPs que tenemos por ahí rondando que utilizan IPs de su proveedor, todo por ahorrarse un poco de dinero en tener su infraestructura en condiciones.
Por no exponer a ningún ISP o empresa en esa situación voy a hablaros de Neodigit, bien, cuando compramos Neodigit la empresa utilizaba direccionamiento de su proveedor de transito, es decir, las IPs no eran de Neodigit, sino en este caso de Cogent y la empresa dependía de Cogent para todo.
No podía dar de baja Cogent porque perdería el direccionamiento IP, no podría anunciar el rango por otro proveedor a no ser que Cogent lo permitiera expresamente cambiando el objeto en RIPE, etc…
Todo inconvenientes y muy mala idea. Bueno, pues llegamos nosotros, y lo primero que hicimos tras una migración bastante compleja fue cambiar el direccionamiento IP de todos los servidores a IPs de Tecnocrática, es decir, nuestras y empezar a trabajar con nuestro propio sistmea autónomo y nuestros propios routers, esto permitió poder trabajar con otros proveedores.
Al trabajar sólo con un proveedor de transito si este se cayese perderíamos la conectividad con todo lo que hubiera detrás, si nos quedaramos sin IPs dependeríamos que nuestro proveedor nos dijese más y al precio que quisiera, etc…
Pero quizás lo peor es que no podríamos migrar a otro proveedor porque nuestros servicios estarían atados a IPs que no son nuestras.
En definitiva, estar atado a un proveedor es muy muy muy mala idea, y hay que hacer lo posible para escapar de esa situación.
La solución pasa por levantar nuestro propio sistema autónomo, usar nuestras propias IPs y levantar nuestros routers BGP para poder tener conectividad con quien quisieramos.
Así que en el capítulo de hoy voy a contaros qué es lo que hay que hacer para conseguir todo eso.
El primer paso no tiene ninguna dificultar técnica, pero sí administrativa pues hay que rellenar una documentación para solicitar una serie de cosas. Por mi parte yo lo que os recomiendo es que os hagáis LIR (Local Internet Registry) y que pidáis un AS y el /22 que va con cada AS en la fase de agotamiento de direccionamiento en la que nos encontramos. Un /22 recordad que son 1000 IPs, más que suficiente para empezar dignamente para el 99% de las empresas o ISPs que existen actualmente. Obviamente también podéis solicitar vuestro /32 de IPv6, lo cual os recomiendo que también solicitéis.
Una vez tengáis todo eso asignado es hora de ponerse a trabajar y aquí es donde entra la parte técnica. La solución estándar se hace con 4 routers, dos de frontera, que serán los que corran BGP y otros dos de core que no correrán BGP y que serán los que sean los gateways de las redes que tengamos.
Entre los routers frontera y los de core configuraremos OSPF, recordad que ya hablé de OSPF en el capítulo 11 (https://www.eduardocollado.com/2017/02/11/podcast-11-ospf-en-unico-area/) de este mismo podcast.
Os recomiendo hacer conexiones /30 con enlaces punto a punto de OSPF. De esta forma conectaremos los dos cores con los dos borders o frontera y el gateway de la LAN os recomiendo HSRP, VRRP o similar, para dar una redundancia interna..
La parte de OSPF nos es el objetivo de este audio y no quiero tampoco hablar demasiado de eso, pero necesitáis un IGP por debajo para que BGP por encima funcione y OSPF es un IGP estupendo para este tipo de cosas.
Llegados aquí tenemos dos routers, los borders o frontera y conectados por debajo dos routers más que están unidos por OSPF que es donde están las redes definidas, por ejemplo todo dividido en /24 y según las vayamos utilizando las iremos viendo en los borders como /24 aprendidos por OSPF, este punto es fundamental porque BGP no va a anunciar nada que no haya aprendido por algún protocolo interno o ruta estátitca.
De hecho es probable que hayáis visto en algún router las famosas rutas a null, rutas que no apuntan a ningún lado, esto es porque BGP va a ver esas rutas en la tabla y por tanto va a proceder a anunciarlas, en un ratito os cuento cómo funciona esta pequeña trampa lógica.
Ahora tenemos que saber que tenemos dos tipos de BGP, el eBGP (externo) y el iBGP (interno), teniendo el externo una distancia administrativa de 20 y el interno de 200, recordad que a menor distancia administrativa más prioridad de esa ruta, y ya de paso aprovecho y os digo que OSPF tiene distancia administrativa de 110, así que si vemos una ruta por iBGP y por OSPF, si es exactamente la misma ruta vamos a elegir siempre la información que os de OSPF al tener menor distancia administrativa.
Para configurar BGP lo primero que vamos a configurar es la parte de iBGP, es decir, vamos a conectar un router frontera con su hermano, el otro router frontera. No lo he dicho, pero son dos por si uno cae, para que siempre tengamos otro funcionando.
La configuración del iBGP en principio no es demasiado compleja, añadiremos al router, dentro de la parte de BGP un vecino o neighbor, que será la IP del otro router y le diremos que el AS de destino es el mismo que el nuestro. El router al ver que el AS del vecino es el mismo que el nuestro ya sabe que es iBGP, no hace falta indicarle más.
En este momento tenemos los dos routers conectados, pero no se comparten nada, así que tenemos que añadir a mano, a no ser que lo automaticemos de alguna manera, las redes, o mejor dicho prefijos, se llaman así en BGP, que queramos anunciar y que obvimente serán nuestras.
Por ejemplo configuramos entre los routers el prefijo 1.2.2.0/23, que incluye el 1.2.2.0/24 y el 1.2.3.0/24, pero vemos que el vecino no recibe nada, ese puede ser porque el vecino que lo anuncia tiene en su tabla los dos /24, pero no el /23 y como ese prefijo no lo tiene no lo anuncia, no anuncia la red entera porque solo tiene ruta a las dos mitades de la red.
Aquí si no estáis muy sueltos con el protocolo es probable que os volváis locos un ratos porque vosotros llegáis a máquinas de ambas redes, algo raro pasa. Pero es el comportamiento normal, entonces para que esto funcione podríamos meter una ruta a null del /23, lo que hemos comentado antes, entonces BGP ya verá la ruta como una estática y la anunciará por BGP.
Pero esa ruta a null no nos va a hacer ningún daño, porque si se cae la primera parte, el primer /24 llegará el tráfico y como no lo podrá encaminar porque no tendrá el /24 lo mandará a null haciendo caso del /23 porque primero mirará la ruta más restrictiva y al no existir mirará la siguiente que es null, así que el tráfico morirá.
Puede parece un poco retorcido, pero se hace así en entornos como este en el que tengamos sólo dos routers de BGP.
De todos modos ya sabéis que en caso de que haya BGP y OSPF dentro del AS siempre mirará OSPF porque tiene menor distancia administrativa que iBGP.
Bueno, con esto tendríamos solventada la parte de iBGP y ahora configuraríamos los tránsitos de eBGP, para eso podríamos la IP y el sistema autónomo de nuestro vecino y normalmente siempre una auntenticación y empezaríamos a anunciar los prefijos que tuvieramos definidos en nuestro network.
Pero aquí una vez más podría ser que nuestro tránsito no lo aceptara, eso podría ser porque nuestro tránsito no ha actualizado sus filtros, bien porque nosotros no le hemos especificado qué prefijos vamos a anunciar o bien porque no lo hayamos configurado bien en RIPE el objeto ruta, que es donde muchos proveedores de tránsito sacan la información.
Con esto ya tendríamos una conectividad primitiva a Internet, y digo primitiva porque no controlaríamos qué tránsitos usar para destinos concretos, etc…
Para hacer eso podríamos usar lo que se llaman atributos de BGP.
Para controlar por que tránsito preferimos recibir un prefijo entero la opción más sencilla sería la del prepend. Un prepend no es algo más complicado que introducir en el AS Path, es decir, la lista de AS que atraviesa el prefijo varias veces el mismo prefijo, de forma que el AS Path sea más largo de lo que debiera, por ejemplo si metieramos 5 veces el mismo AS para que el AS Path sea más largo nos ahorraríamos muchísimo tráfico ya que esa ruta no va a ser elegida pues es muchísimo más larga, que otra aprendida por otro lado y que ha sido anunciada por el otro tránsito sin utilizar prepend, por lo tanto con un AS Path más corto.
De todos modos pensad que Internet y los protocolos que la componen no están pensados para influir en las decisiones de otros sino en las de uno mismo, es decir, en todo lo que no sea modificar nuestras decisiones de routing no podemos decidir sino simplemente sugerir e intentar influir, así que si algún vecino dice que el trafico nos lo va a mandar por el transito que no queremos no tenemos nada que hacer.
Ahora, si lo que queremos es por ejemplo que todo el tráfico que vaya a una red concreta en vez de ir por el tránsito que toca vaya por otro sí podremos hacer algo, porque es tráfico saliente, en este caso lo que podemos hacer es modificar la local preference y modificar para que sea mayor y se prefiera ese transito o menor y que ese enlace no se prefiera, tenemos las dos opciones.