Solución al Desafío - Parte 2 con Mohamed Sobair
Metodología de Diseño de Redes en Acción:
Solución del Desafío

 

En mi primer blog de la serie “Desafío de Diseño” propuse un desafío de diseño de red con la meta de aplicar la metodología descrita en el blog “¿Ahora qué?”. Vamos a analizar el desafío y a encontrar la opción de diseño que mejor se ajusta de acuerdo a esa metodología.

 

 

Enlistar los requerimientos en este desafío:

  • Vision Tier-2 ISP quiere una solución económica.
  • Vision Tier-2 ISP requiere continuidad de negocio.
  • Vision Tier-2 ISP quiere proveer servicios de data (unicast y multicast), voz y VPN a lo largo de sus 3 ciudades.

 

Enlistar los requerimientos técnicos en este desafío:


  • Escalabilidad de la solución.
  • Simplicidad de la solución.
  • Resiliencia para la capa física y el núcleo.
  • Granularidad aumentada en control de políticas.
  • Conectividad dentro de la ciudad (Intra-POP) connectivity.
  • Conectividad entre ciudades (Inter-POP) connectivity.

 

Comparar y contrastar todas las opciones lado a lado contra los requerimientos y limitaciones:

Para resolver el desafío podemos realizar un resumen de todos los requerimientos y las soluciones propuestas, haciendo uso de una tabla como la siguiente.


Diseño jerárquico de RRs con 2 RRs horizontales en un cluster BGP (Opción de diseño número 1)Diseño jerárquico de RRs con 2 RRs verticales en un cluster BGP (Opción de diseño número 2)Diseño jerárquico de RRs con todos los RRs de la ciudad en un único cluster BGP (Opción de diseño número 3)Confederación BGP en cada ciudad con RRs en clusters BGP únicos (Opción de diseño número 4)Confederación BGP con 2 RRs horizontales en cada ciudad, cada uno en un cluster BGP diferente (Opción de diseño número 5)Confederación BGP con 2 RRs verticales en cada ciudad, cada uno en un cluster BGP diferente (Opción de diseño número 6)
Continuidad de negocio / resilienciaSatisface requerimientos completamenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos completamenteSatisface requerimientos parcialmente
EscalabilidadSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmente
SimplicidadSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmente
Control de políticasSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamente
Capabilidad MP-BGPSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamenteSatisface requerimientos completamente
Conectividad Intra-POPSatisface requerimientos completamenteNo Satisface los requerimientosNo Satisface los requerimientosNo Satisface los requerimientosSatisface requerimientos completamenteNo satisface los requerimientos
Conectividad Inter-POP Satisface requerimientos completamenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos parcialmenteSatisface requerimientos completamenteSatisface requerimientos parcialmente


Justificar la opción seleccionada (¿Por qué es correcta?) y las opciones sin seleccionar (¿Por qué son incorrectas?)


Opción Número 1 - La mejor opción en este caso. Diseño jerárquico de RRs con 2 RRs horizontales en un cluster proporciona lo siguiente:

  • Resiliencia: Con el Diseño jerárquico de RRs con 2 RRs horizontales en un clúster BGP, hay resiliencia para los POPs así como también para el núcleo: en caso de que un cluster falle, el segundo toma el rol y proporciona conectividad dentro de la ciudad y entre ciudades. Lo mismo aplica si hay alguna falla de un enlace físico.
  • Escalabilidad: Esta opción es muy escalable ya que no hay necesidad de que todos los routers PE establezcan sesiones entre ellos, sino que establezcan sesiones sólo con los RRs en el cluster correspondiente. Un LSP será creado de extremo a extremo entre los routers PE, minimizando el número total de conexiones TCP.
  • Simplicidad: Route reflection es un mecanismo más simple y escalable que confederaciones. Es más sencillo de configurar y administrar y no posee la complejidad adicional del requerimiento de malla completa dentro de la confederación BGP del sub-AS.
  • Control de políticas: Los RRs proveen control de políticas limitado en comparación con las confederaciones. Las políticas de RR jerárquicos pueden ser proporcionadas aun fuera de los límites o fronteras. Sin embargo, con confederaciones las políticas de BGP pueden ser proporcionadas dentro del Sub-AS y fuera de las fronteras.
  • Conectividad dentro de la ciudad (Intra-POP): La conectividad dentro de la ciudad (Intra-POP) es posible ya que los RRs horizontales para cada POP están en un cluster BGP diferente, lo cual asegura que los anuncios de BGP no sean rechazados, proporcionando un camino secundario entre los POPs superiores e inferiores en caso de que un RR falle. Dentro de un mismo cluster BGP, un RR proporciona la conectividad entre los POPs y el RR secundario está en standby.
  • Conectividad entre ciudades (Inter-POP) connectivity: La conectividad entre ciudades (Inter-POP) es posible debido al diseño jerárquico de RR. Ambos RR de ciudad “1” y ciudad “3” establecen sesiones con el RR de ciudad “2” en un cluster BGP diferente, proporcionando conectividad entre ciudades. Esta es una solución escalable y funcional para la conectividad entre ciudades, la cual permite que los RR en un cluster sean clientes de un RR en un cluster BGP diferente. Esto también proporciona el mecanismo de prevención de loops necesario.


Opción Número 2 - Diseño jerárquico de RRs con 2 RRs verticales en un clúster BGP: El riesgo y problema con esta opción es que la resiliencia puede solo aplicar para la parte superior o inferior de la red. Esta opción no proporciona Conectividad dentro de la ciudad (Intra-POP) y solo conectividad parcial entre ciudades (Inter-POP), así que la resiliencia sólo puede ser parcial porque básicamente, divide el núcleo en dos mitades. Los POPs superiores e inferiores están aislados entre ellos. Además, el control de políticas es sólo parcial con este diseño de RR BGP ya que es aplicado fuera del límite BGP.


Opción Número 3 - Diseño jerárquico de RRs con todos los RRs de la ciudad en un único clúster BGP: Se presenta el mismo problema que en la opción número 2.


Opción Número 4 - Confederación BGP en cada ciudad con RRs en clusters BGP únicos: Las mismas razones que con las opciones 2 y 3. Adicionalmente, la simplicidad sólo es parcial porque una confederación BGP no es simple de configurar, administrar y los problemas que puedan presentarse no son sencillos de resolver, como con Route Reflection. Además, las confederaciones BGP no son tan escalables como BGP Route Reflection o Route Reflection Jerárquico. BGP RR no elimina la necesidad de una malla completa entre los peers iBGP, pero una confederación BGP requiere que todos los iBGP peers están en malla completa dentro del Sub-AS.


Opción Número 5 - Confederación BGP con 2 RRs horizontales en cada ciudad, cada uno en un cluster BGP diferente: Podría ser una segunda opción justo después de la opción número 1; sin embargo, con esta opción hay limitaciones en cuanto a simplicidad y escalabilidad como en la opción número 4, lo cual la hace menos deseable que la opción número 1.


Opción Número 6 - Confederación BGP con 2 RRs verticales en cada ciudad, cada uno en un clúster BGP diferente: Se presenta el mismo problema que en la opción número 4.


Conclusión: Es una parte integral del diseño de redes tener un dominio amplio de tecnologías para poder aplicar ese conocimiento en comparar y contrastar soluciones diferentes para satisfacer los requerimientos de los clientes, pero también para justificar tu selección de diseño. A veces, la mejor opción no es tan obvia como podría parecer, especialmente con muchos requerimientos involucrados.


Sobre el Autor


Blog16-17- Mohamed Sobair pic.pngMohamed Sobair, CCIE # 29645, MSc, ITILv3, JNCIS y PMP tiene más de 10 años de experiencia profesional en la industria de TI, proporcionando soluciones y servicios de consultoría para varios clientes, incluyendo empresas, organismos de telecomunicaciones y proveedores de servicio de internet (ISP). Actualmente trabaja como SME para el programa Expert-level de Cisco. Mohamed es un apasionado del diseño y la arquitectura, generalmente participa en discusiones y hace contribuciones relacionadas con las tecnologías de Cisco en CLN y la Comunidad Cisco.



Traductor voluntario del blog en Español: David Peñaloza


A continuación, algunas maneras adicionales para integrarnos y mantener la conversación: