el
10-19-2022
09:10 AM
- fecha de última edición
10-19-2022
09:15 AM
por
Hilda Arteaga
Este evento tuvo lugar el 27 de Septiembre a las 10:00hrs CDT (utc -6)
La sesión se enfoca en BGP (Boarder Gateaway Protocol), uno de los protocolos más usados hoy día, y en cómo mejorar la seguridad cuando se usa el protocolo. La escalabilidad y capacidad de ruteo de BGP le hacen por defecto la elección para la comunicación en Internet, sin embargo, no es un protocolo que se preocupe por la seguridad de la información que maneja. Los expertos de Cisco y Lacnic hablan de la importancia de la seguridad en BGP, comparten tips y mejores prácticas para asegurar lo mejor posible las sesiones de BGP y con ello apoyar la estabilidad de las redes y la comunicación.
Expertos en Destaque
Alejandro Acosta es coordinador de I+D en LACNC y miembro de diferentes organizaciones relacionadas a Internet. Anteriormente fue Chair de LAC-TF (IPv6 Task Force), Gerente de IT y Soporte para British Telecom (BT), y miembro de la Comisión Electoral de LACNIC. Fue docente de TCP/IP por más de 10 años a nivel universitario y coordinador de eventos de FLIP-6 e IPv6 en Latinoamérica. Cuenta con 3 especializaciones en el área de tecnologías de la Universidad de Michigan y Maryland. Hector Carranza es un Technical Leader para las tecnologías de Service Provider XR. Cuenta con más de 14 años de experiencia en IT y se especializa en diversas tecnologías soportadas en las plataformas XR de Cisco; como, protocolos de ruteo, switching, MPLS, L3VPN, L2VPN, MLDP, VSM. También se especializa en la arquitectura de las plataformas de la familia de ASR9000, NCS5000, NCS5500, NCS540, CRS. Hector es un Ingeniero en Sistemas Computacionales egresado del instituto de Estudios Superiores de Monterrey (ITESM, CEM). Y cuenta con la certificación de CCIE Enterprise Infrastructure (#42717). Ignacio Magaña es un Technical Consulting Engineer en el área especializada en Service Providers a nivel mundial en Cisco México. Tiene más de 10 años de experiencia en redes y telecomunicaciones. Se especializa en tecnologías y protocolos utilizados por los Service Providers como, MPLS, OSPF, IS-IS, SR, BGP, BNG y Multicast principalmente. Así como en las plataformas de Service Provider en las que se encuentran, ASR9000, ASR9900, NCS y CRS. Es egresado de la carrera de Ingeniería en Control y Automatización de la Escuela Superior de Ingeniería Mecánica y Eléctrica (ESIME) del Instituto Politécnico Nacional (IPN). Cuenta con las certificaciones de eITIL, RedHat, Juniper, DevNet Associate y un CCIE Service Provider (#53583). |
Horarios
|
Encuentre más información relacionada en la categoria de Routing & Switching.
Puede descargar los slides en formato PFD aquí y el video de la sesión aquí.
R: Sobre el tránsito de BGP, la oración correcta es: "un sistema autónomo de tránsito". Ejemplo de un AS que hace tránsito: Tipicamente un proveedor de Internet que tiene clientes con los que sostiene sesiones BGP y estos clientes anuncian sus prefijos, el ISP los aprende, se los anuncia a sus upstream providers.
R: Sobre los bucles, sería routing loops. El principal mecanismo que tiene BGP para prevenir routing loops es no aprender prefijos donde su mismo AS aparezca en el AS_PATH (claro, sin produndizar también existen otras cosas que se puede hacer en esto).
R: Si no aprendes toda la tabla de rutas (DFZ) será necesario también aprender al menos una ruta por defecto (claro, pierder un poco de ingeniería de tráfico). Aquí te dejo un link donde escribí algo al respecto, quizás te ayude: https://blog.acostasite.com/2017/03/bgp-filtrar-por-tamano-de-la-red-en-bgp.html
R: Pienso esto es muy particular del operador. El warning only solo creará el "log" y la sesión BGP seguirá operando. Si tu router no tienen memoria/cpu suficiente vas a tener inconveniente de que el mismo siga operando. Si la sesión BGP se reinicia, tienes que pensar en el impacto de que esto ocurra. Extra: recientemente viví un caso de un operador que estaba redistribuyendo sus prefijos IPv6 vía BGP. Su upstream provider tenía su max prefixes configurado y la sesión BGP quedaba en shut.
R: En el slide 32 de esta sesión hay más detalles del laboratorio. Puedes ver los slides aquí: https://bit.ly/slides-sep27
El laboratorio esta corriendo en un servidor UCS, pero les podemos compartir igual las capacidades de recursos. Además peuden encontrar la topoogía y las configuraciones en los recuersos extras de la sesión: https://community.cisco.com/t5/documentos-routing-y-switching/material-extra-seguridad-en-bgp-mejores-pr%C3%A1cticas/ta-p/4695030
R: Secuestro de Prefijos - RPKI - BGP
• https://www.youtube.com/watch?v=X5RNSs8y8Ao [Parte 1]
• https://www.youtube.com/watch?v=m51WtuEZOKI [Parte 2]
R: Con TTL security lo que se intenta es darle al equipo un mecanismo para prevenir que equipos no validos levanten una sesión de eBGP, tomando en cuenta que eBGP considera que el vecino estará directamente conectado. Pero a veces por temas de diseño o requerimiento de ciertos proveedores piden establecer las sesiones con su loopback address y es donde será útil el ocupar el eBGP multihop para establecer la vecindad.
R: En Cisco, principalmente XR, pues ya se tienen valores por defecto en el número máximo de prefijos que se pueden recibir. Más detalles en: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_010.html
Ahora bien, en la sección de BGP Default Limits lo puedes ver. En dado caso de que no se tenga acuerdo, esos son los máximos por address family que se tienen.
R: Pueden ser temas físicos, por la caída o falla de un enlace. Pero igual si por algún otro motivo los keepalives de BGP no se reciben, pues la sesión se tirará. Esto puede ser por temas de congestión, algun defecto de SW (bug), falla en el procesamiento del paquete, etc. Por lo que podría ser lógico y físico, dependiendo.
R: Sí, pueden encontrarles en los materiales extra de la sesión: https://community.cisco.com/t5/documentos-routing-y-switching/material-extra-seguridad-en-bgp-mejores-pr%C3%A1cticas/ta-p/4695030
R: El único método disponible de autenticación de BGP es utilizando MD5, esto para todas las plataformas ocupando IOS, IOS XE o IOS XR.
R: En equipos XR podrías ocupar el debug bgp update u ocupar el deug bgp all neighbor x.x.x.x, para limitar la revisión a un vecino en particular y así poder analizar todo el proceso de actualización y sincronización de rutas. De la misma forma te dejo un documento de Cisco Live que me parece interesante en cuanto a la revisión y troubleshooting de varios escenarios comunes de falla de BGP: https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKRST-3320.pdf
R: La cantidad de rutas que un equipo puede aprender depende directamente de las capacidades de memoria de los equipos. Mientras más memoria, más rutas o prefijos se pueden aprender. Hablando en particular de los ISPs, los equipos que Cisco ofrecen para esta gama del mercado incluyen ASR9K, NCS5500, Cisco 8000 que generalmente soportan grandes cantidades de rutas. Pero es recomendable revisar la documentación de cada producto en cuanto a escalabilidad para asegurar que es el adecuado para las necesidades de tú red.
R: La cantidad de rutas que un equipo puede aprender depende directamente de las capacidades de memoria de los equipos. Mientras más memoria, más rutas o prefijos se pueden aprender. Hablando en particular de los ISPs, los equipos que Cisco ofrecen para esta gama del mercado incluyen ASR9K, NCS5500, Cisco 8000 que generalmente soportan grandes cantidades de rutas. Pero es recomendable revisar la documentación de cada producto en cuanto a escalabilidad para asegurar que es el adecuado para las necesidades de tú red.
R: Encuentre la respuesta en el foro Ask Me Anything del evento aquí.
R: Desafortunadamente las imágenes no se pueden compartir por temas de Copyright. Sin embargo, si tienes cuenta y usuario de cisco.com con provilegios suficientes puedes descargar las imagenes de XRv y IOSv.
El lab y las configuraciones puedes descargarlas en el siguiente link:
https://1drv.ms/f/s!Ajacm8dDgObUdF9r3JPHjzVCptI
R: El ocupar o no el TTL-SECURITY o cualquier otra práctica de seguridad siempre dependerá del diseño de cada red. Generalmente al establecer una sesión de eBGP con un proveedor, está se hace con la IP de la interfaz conectada donde el TTL Security tiene sentido. Pero algunos proveedores o implementaciones requieren se establezca la sesión con interfaces loopback o no conectadas (Ej. Inter-AS VPN) donde este tipo de prácticas de seguridad no aplican. Los best practices que se compartieron son prácticas sencillas para intentar asegurar las vecindades de BGP, pero el aplicarlas o no igual podrá depender del diseño e implementación de cada red.
R: La siguiente liga, te puede acyudar a complementar y entender el lenguaje de RPL utilizado en la plataforma XR.
https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-understanding-and-using-rpl-route-policy-language/ta-p/3117050
R: Para esto es recomendable visitar la página del IANA
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
Y validar cuales son los segmentos de red privados y reservados. Estos son los que hay que evitar en el anuncio y aprendizaje de rutas. De la misma forma se puede buscar en internet organizaciones que mantienen estas listas actualizadas.
R: Encuentre la respuesta en el foro Ask Me Anything del evento aquí.
R: No, no existe un comando que realice esto. Aunque podrías intentarlo con algún debug de BGP.
R: El cifrado MD5 es débil, sí, y simple. Pero es un mecanismo para autenticar las sesiones de BGP. Puedes considerar también la opción de keychain que es más robusta.
R: Depende del caso, en al demo de la sesión va hacía el incomming.
R: EVE-NG--> https://www.eve-ng.net/. En su Versión Free Community, es decir, aquellos interesados podrían probarlo de forma gratuita.
R: Como toda buena práctica, es bueno tenerlas en consideración para todos los escenarios, sin embargo, no son absolutamente necesarios para levantar la vecindad y tener la funcionalidad que brinda el protocolo. Aunque la recomendación es implementar la mayoría para evitar algún problema futuro o de compliance con el Peer que presta o recibe el servicio, o para evitar un ataque como hemos mencionado durante la presentación.
R: Se puede ocupar el as-path set ^$ en conjunto con la funcionalidad del remove-private AS. Esto con el objetivo de anunciar únicamente las redes que se generan localmente en ese sistema autónomo (evitando que tú AS se ocupe como tránsito para llegar a otras redes) y al mismo tiempo eliminar los AS privados. O de la misma forma generar varias reglas con un RPL o route-maps para evitar la propagación de rutas con AS privados.
R: Hay varios factores que afectan esto, en primera los protocolos de detección de falla y de monitoreo de BGP tiene timers muy extensos por lo que una falla toma tiempo en ser detectada. Esto igual aunado a la cantidad de prefijos y rutas que soporta BGP, mientras más grande es la tabla de BGP más tardado es el procesamiento de estas y de detectar una posible falla. Recuerda que el diseño de BGP está basado en su capacidad de transporte de rutas, no en su seguridad o velocidad, por lo que es necesario ocupar mecanismos de detección en otros protocolos o niveles para mejorar la velocidad de convergencia.
R: Es correto.
R: Sí, en la topología parte 503 se muestra (parte de arriba).
R: Para el tema de recursos es necesario considerar que cada versión XRv e IOS utilizadas en este escenario utilizan:
XRv, 1 vCPU y 4 GB de RAM .
Respecto a los demás dispositivos (No XR) usan 1 vCPU y 512 MB de RAM.
R: No, pero pueden ser encontrados en los buscadores. Proejemplo, algunos de ellos peuden ser allados en Google, depende de lo que se busque.
R: Sí, pueden encontrarles en: https://community.cisco.com/t5/documentos-routing-y-switching/material-extra-seguridad-en-bgp-mejores-pr%C3%A1cticas/ta-p/4695030
R: Encuentre la respuesta en el foro Ask Me Anything del evento aquí.
Vea los Slides Foro de la sesión Material de la Demo Vea el Video
¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.
Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco:
Navegue y encuentre contenido personalizado de la comunidad