Dummies Book Esla PDF

Redes definidas
por software (SDN)
Edición especial de Cisco
por Brian Underdahl

y Gary Kinghorn
Redes definidas por software (SDN) para Dummies®, edición especial de Cisco
Publicado por
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2015 por John Wiley & Sons, Inc., Hoboken, New Jersey
Queda prohibido reproducir, almacenar en un sistema de recuperación o transmitir en el modo o
por el medio que fuera (electrónico, mecánico, fotocopiado, grabado, escaneado, etc.) cualquier
parte de esta publicación, a excepción de lo que autorizan las secciones 107 o 108 de la Ley de Dere-
chos de Autor de Estados Unidos de 1976, sin la autorización previa por escrito de la Editorial. Las
solicitudes de permisos dirigidas a la Editorial deben enviarse a Permissions Department, John
Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, o por
Internet en http://www.wiley.com/go/permissions.
Marcas comerciales: Wiley, For Dummies, el logo del hombrecito de Dummies, The Dummies Way, Dummies.
com, Making Everything Easier y las formas de presentación del producto relacionadas son marcas comercia-
les o marcas comerciales registradas de John Wiley & Sons, Inc. y/o de sus filiales en los Estados Unidos y
otros países, y no se pueden usar sin autorización por escrito. Cisco y el logotipo de Cisco son marcas
registradas o marcas comerciales de Cisco y/o de sus filiales en los Estados Unidos y en otros países. Todas
las demás marcas comerciales pertenecen a sus respectivos propietarios. John Wiley & Sons, Inc. no tiene
relación con ningún producto o proveedor mencionado en este libro.
LÍMITE DE RESPONSABILIDAD/EXCLUSIÓN DE GARANTÍAS: LA EDITORIAL Y EL AUTOR NO HACEN

NINGÚN TIPO DE DECLARACIÓN NI OFRECEN GARANTÍA ALGUNA CON RESPECTO A LA PRECISIÓN O
INTEGRIDAD DEL CONTENIDO DE ESTE PRODUCTO Y DENIEGAN ESPECÍFICAMENTE TODAS LAS
GARANTÍAS, INCLUIDAS, ENTRE OTRAS, LAS GARANTÍAS DE IDONEIDAD PARA UN FIN EN PARTICULAR.
QUEDA PROHIBIDO CREAR O EXTENDER GARANTÍAS A TRAVÉS DE MATERIALES DE VENTA O
PROMOCIÓN. ES PROBABLE QUE EL ASESORAMIENTO Y LAS ESTRATEGIAS QUE INCLUYE EL PRESENTE
DOCUMENTO NO SEAN ADECUADOS PARA TODOS LOS CASOS POR IGUAL. ESTE PRODUCTO SE VENDE
A SABIENDAS DE QUE LA EDITORIAL NO SE DEDICA A PRESTAR SERVICIOS LEGALES, CONTABLES NI
DE NINGUNA OTRA ÍNDOLE PROFESIONAL. EN CASO DE ASISTENCIA PROFESIONAL, DEBERÁ
SOLICITARSE LOS SERVICIOS DE ALGÚN PROFESIONAL COMPETENTE. NI LA EDITORIAL NI EL AUTOR
ASUMIRÁN RESPONSABILIDAD ALGUNA EN CASO DE SURGIR DAÑOS A PARTIR DEL PRESENTE
DOCUMENTO. LA MENCIÓN DE ALGUNA ORGANIZACIÓN O SITIO WEB EN ESTE TRABAJO COMO CITA
O POSIBLE FUENTE DE INFORMACIÓN ADICIONAL NO IMPLICA QUE EL AUTOR NI LA EDITORIAL
ADHIERAN A LA INFORMACIÓN QUE LA ORGANIZACIÓN O EL SITIO WEB PUDIERAN PROPORCIONAR
NI A LAS RECOMENDACIONES QUE PUDIERAN BRINDAR. ASIMISMO, LOS LECTORES DEBEN TENER EN
CUENTA QUE LOS SITIOS WEB DE INTERNET MENCIONADOS EN ESTE PRODUCTO PUDIERON HABERSE
MODIFICADO O INCLUSO HABER DESAPARECIDO EN EL LAPSO ENTRE QUE SE ELABORÓ Y SE LEYÓ
ESTE PRODUCTO.
Si desea obtener información general sobre nuestros otros productos y servicios o si desea saber cómo
editar un libro For Dummies personalizado para su empresa u organización, comuníquese con nuestro depar-
tamento de desarrollo comercial de EE. UU. al teléfono 877-409-4177, por correo electrónico a la dirección
info@dummies.biz o mediante el sitio web www.wiley.com/go/custompub. Si desea obtener informa-
ción sobre las licencias de la marca For Dummies para productos o servicios, escriba a
BrandedRights&Licenses@Wiley.com.
ISBN 978-1-119- 16445-6 (pbk); ISBN 978-1-119-16447-0 (ebk)
Producido en Estados Unidos de América
10 9 8 7 6 5 4 3 2 1
Agradecimientos de la editorial
Algunas de las personas que ayudaron a publicar este libro:
Editor del proyecto: Jennifer Bingham Representante de desarrollo comercial:

Editor de adquisiciones: Katie Mohr Karen Hattan
Gerente editorial: Rev Mengle
Contenido
Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Acerca de este libro................................................................................1
Íconos utilizados en este libro..............................................................1
Más allá del libro.....................................................................................2
Capítulo 1: Introducción a las redes definidas

por software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Conceptos básicos sobre las SDN.......................................................3
¿Dónde estábamos antes de las SDN?....................................5
¿Adónde nos llevan las SDN?....................................................6
Analizar por qué hay tanto entusiasmo.............................................7
Las SDN facilitan la virtualización de servidores
y las redes en la nube.............................................................7
Las SDN giran principalmente en torno a la
automatización basada en políticas...................................8
Capítulo 2: Analizar los beneficios y casos de uso

de las SDN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
La automatización de las SDN genera dinamismo empresarial....9
Un nuevo enfoque para las políticas de la red....................10
Administración de políticas centralizada
con puntos de control distribuidos..................................11
Algunos casos de uso populares para implementar las SDN......13
Llegar más allá de la red y el centro de datos.................................14
Capítulo 3: Comprender la tecnología. . . . . . . . . . . . . . . . . . . 15

Comprender los controladores de SDN...........................................15
Comprender las políticas....................................................................17
Evaluación de las redes complementarias en entornos de SDN....
19
Automatización de la nube a través de SDN...................................21
Capítulo 4: Consideraciones y requisitos clave de SDN. . 23

Enfoque en las aplicaciones................................................................23
Mantener la apertura...........................................................................25
SDN: protocolos abiertos, arquitecturas abiertas,
ecosistemas abiertos y código abierto........................................25
Mantener lo que ya tiene mediante Cisco ACI................................27
iv Redes definidas por software (SDN) para Dummies _____________
Capítulo 5: Diez datos importantes sobre la

evaluación de soluciones de SDN. . . . . . . . . . . . . . . . . . . . 31
Programación vs. administración manual.......................................31
Dar lugar a una implementación de políticas más fácil................32
Compatibilidad con ecosistemas de varios proveedores............32
Comprender la importancia del controlador..................................33
Emplear el lenguaje correcto..............................................................33
Utilizar una línea ascendente.............................................................33
Usar las herramientas de automatización en la nube...................34
Tener en cuenta una arquitectura extensible.................................34
Seleccionar cuidadosamente una plataforma de SDN
de código abierto..............................................................................35
Mantener la transparencia..................................................................36
Acrónimos de SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Introducción
¿ Está intentando descubrir qué son exactamente las redes defi-
nidas por software y si deben formar parte de los proyectos
tecnológicos de su organización? Si es así, este libro está diseñado
para ayudarlo.
Las redes definidas por software (SDN) son una nueva manera de
analizar de qué manera las soluciones de red y de nube deben ser
automatizadas, eficientes y escalables en un nuevo mundo donde
los servicios de aplicaciones se pueden proporcionar localmente,
por medio del centro de datos o incluso a través de la nube. Esto es
imposible de lograr con un sistema poco flexible que resulte difícil
de administrar, mantener y actualizar. En un futuro, necesitará flexi-
bilidad, simplicidad y la posibilidad de crecer rápidamente y satisfa-
cer las necesidades empresariales y de TI en constante cambio.
Acerca de este libro

Redes definidas por software (SDN) para Dummies, una edición espe-
cial de Cisco, le muestra qué son las SDN, cómo funcionan y cómo
puede elegir la solución de SDN adecuada. Este libro también lo
ayudará a comprender la terminología, la jerga y los acrónimos que
conforman la definición de SDN.
Durante el desarrollo del libro, verá algunos ejemplos de la tecnolo-
gía vanguardista actual de las SDN y de qué manera las SDN pueden
ayudar a su organización.
Íconos utilizados en este libro

Este libro emplea los siguientes íconos para llamar su atención a la
información que puede resultarle útil de maneras particulares.
La información que esté señalizada con este ícono es importante y,
por lo tanto, se reiterará para darle énfasis. De esta manera, podrá
identificar fácilmente la información importante cuando consulte el
libro más adelante.
Este ícono destaca la información sumamente útil.
2 Redes definidas por software (SDN) para Dummies _____________
Este ícono marca los puntos donde se analizan cuestiones técnicas,

como la jerga de SDN y demás. Disculpe, no es posible ayudarlo,
aunque hacemos todo lo posible para serle útil.
Los párrafos que estén marcados con el ícono de advertencia infor-
man sobre las dificultades comunes que pueden surgir.
Más allá del libro

Visite los siguientes sitios si desea encontrar información adicional
sobre la opinión de Cisco acerca de las SDN:
✓✓ http://cisco.com/go/aci
✓✓ http://cisco.com/go/sdn
✓✓ http://blogs.cisco.com/tag/sdn
Capítulo 1
Introducción a las redes

definidas por software
En este capítulo
▶▶Familiarizarse con las SDN
▶▶Analizar la publicidad y el entusiasmo
L as redes se han convertido en un elemento absolutamente

fundamental para el entorno de negocios moderno de la actua-
lidad. Las redes (independientemente de que estén implementadas
por completo en las instalaciones, en la nube, de modo híbrido o
combinado) proporcionan los enlaces de comunicación esenciales
que las organizaciones necesitan para ejecutar sus aplicaciones,
prestar servicios y mantener la competitividad. Las redes definidas
por software (SDN) representan una manera totalmente nueva de
concebir la configuración, el control y el funcionamiento de las redes.
En este capítulo, se desarrolla una introducción a las SDN, se explica
por qué son necesarias y se demuestra por qué los usuarios están
tan entusiasmados con la llegada de las soluciones para SDN.
Conceptos básicos sobre las SDN

Existen diferentes tipos de definiciones de SDN. Probablemente por-
que las SDN evolucionan a medida que avanza la tecnología y se
introducen soluciones. En general, SDN comúnmente significa que las
redes están controladas por aplicaciones de software y controlado-
res de SDN, y no por medio de consolas y comandos de administra-
ción de redes tradicionales que generan muchos gastos administra-
tivos y cuya administración a gran escala podría resultar tediosa.
En un principio, había mucho entusiasmo en torno a las SDN simple-
mente porque el control basado en el software era mucho más flexi-
ble que las consolas de administración y las interfaces de línea de
comandos (CLI) antiguas y rígidas.
Esta capacidad para controlar las redes a través del software rápida-
mente llevó a la conclusión de que muchas tareas complejas de TI
que debían implementarse por medio de herramientas de adminis-
tración anticuadas ahora podían automatizarse y realizarse de modo
mucho más eficiente. La velocidad y la automatización son requisi-
tos clave para las redes emergentes, en la nube y de varios abona-
dos, que necesitan más escala y que no pueden quedarse estan-
cados en tareas administrativas tediosas. De hecho, la automatiza-
ción en la nube (en sus diversas formas) surgió rápidamente como
un caso de uso principal para la tecnología de SDN. Actualmente,
muchas de las soluciones para SDN son en realidad plataformas
para alojar soluciones de automatización en la nube.
Cuando las SDN aparecieron por primera vez en el panorama tecno-
lógico, los conceptos sobre cómo debían ser las arquitecturas de
SDN y cómo debía definirse una solución de SDN eran muy poco
flexibles. En la actualidad, los clientes tienen una visión más amplia
de cuál es el tipo de solución de SDN indicado para ellos. Como el
caso de uso principal de las SDN evolucionó hacia la automatización
en la nube, los clientes consideran lo que buscan en una solución de
automatización basada en políticas y no solo en los datos específi-
cos de la tecnología de SDN subyacente.
Además, las SDN son verdaderamente una tecnología abierta. Esto
genera más interoperabilidad, más innovación y soluciones más
flexibles y rentables. Si una red cumple con los estándares de SDN
adecuados, podría estar controlada por varias aplicaciones de con-
trolador de SDN. Esa opción es preferible a que cada plataforma de
red tenga sus propios comandos y su propia consola de administra-
ción, que aumentan las limitaciones con respecto a los proveedores
posibles y que complican aún más la administración de la red.
Actualmente, existen diversos estándares de SDN que evolucionan
en diferentes áreas; las estrategias útiles en materia de SDN se basa-
rán siempre en ecosistemas de varios proveedores, abiertos e inte-
roperables, con protocolos estandarizados o tecnologías de código
abierto clave.
Junto con la evolución hacia las SDN, hay varias tendencias tecnoló-
gicas que afectan la arquitectura y el diseño de modernos centros
de datos y redes empresariales, que deben tenerse en cuenta dentro
de los requisitos tecnológicos de las SDN. En la mayoría de las orga-
nizaciones, el centro de datos se está alejando de las arquitecturas
cliente-servidor tradicionales para enfocarse en modelos en los que
se envían muchísimos más datos entre servidores dentro del centro
de datos (comúnmente denominado tráfico entre nodos). Esto
requiere más escalabilidad de la red y políticas más sofisticadas
para la asignación de recursos. Además, muchos departamentos de
�� Capítulo 1: Introducción a las redes definidas por software 5
TI están demostrando un importante interés en migrar a entornos
de nube pública, privada o híbrida.
Gracias a los servicios de nube pública de empresas como Amazon,
Microsoft y Google, los departamentos de TI corporativos han
podido vislumbrar el autoservicio en TI. Estas empresas demues-
tran lo dinámicos que pueden ser los servicios y las aplicaciones.
Las organizaciones ahora exigen los mismos niveles de servicio de
sus propios departamentos de TI. De hecho, se considera que las
SDN son un colaborador clave para aumentar la agilidad de TI y
mejorar las ofertas de TI de autoservicio.
Las empresas también están invirtiendo en aplicaciones de datos
masivos para mejorar la toma de decisiones empresariales. Estos
tipos de aplicaciones requieren un procesamiento paralelo masivo
en cientos o miles de servidores. La exigencia para administrar enor-
mes conjuntos de datos genera mucha presión para la red y acentúa
la necesidad de aumentar la capacidad y la automatización.
Todos estos elementos desempeñan un rol importante en la exigen-
cia de entornos de redes corporativas más eficientes, ágiles y de
mayor rendimiento. Las SDN están destinadas a satisfacer esas
exigencias.
Los beneficios de nivel superior de una estrategia de SDN repercu-
ten en todas las áreas de la organización. Obtendrá una ventaja com-
petitiva porque su infraestructura será más productiva. Aumentará
la velocidad del negocio, se reducirá el costo total de propiedad y
disminuirán los riesgos gracias al aumento de la seguridad.
¿Dónde estábamos antes de las SDN?

Para comprender mejor por qué las SDN ahora son tan importantes,
debe analizar qué había antes de las SDN. Las arquitecturas de redes
tradicionales tienen importantes limitaciones que deben superarse
para satisfacer los requisitos de TI de la actualidad. Las redes actua-
les deben ampliarse para poder admitir grandes cargas de trabajo
con mayor agilidad y, al mismo tiempo, mantener bajos los costos.
Pero el enfoque tradicional tiene limitaciones importantes:
✓✓Complejidad: la abundancia de protocolos y funciones de
redes para casos de uso específicos aumentó considerable-
mente la complejidad de la red. Las tecnologías antiguas solían
reciclarse a modo de correcciones rápidas para poder respon-
der a los nuevos requisitos empresariales. Las funciones solían
ser específicas de un proveedor o se implementaban mediante
comandos patentados.
✓✓Políticas incoherentes: las políticas de seguridad y calidad

de servicio (QoS) de las redes actuales deben configurarse
manualmente o mediante scripts en cientos o miles de dispo-
sitivos de red. Debido a este requisito, a las organizaciones les
resulta extremadamente complicado implementar cambios
de políticas sin realizar grandes inversiones en habilidades o
herramientas relativas al lenguaje de programación de scripts
que puedan automatizar los cambios de configuración. La
configuración manual es propensa a producir errores; puede
llevar muchas horas descubrir qué línea de política de seguri-
dad o lista de control de acceso (ACL) se introdujo de manera
incorrecta en un dispositivo determinado. Además, cuando se
eliminan aplicaciones, es casi imposible eliminar todas las polí-
ticas asociadas en todos los dispositivos, lo que aumenta aún
más la complejidad.
✓✓ Imposibilidad de ampliación: a medida que las cargas de
trabajo de la aplicación cambian y exigen un incremento del
ancho de banda de la red, el departamento de TI necesita una
red estática con exceso de suscripciones o bien crecer con las
exigencias de la organización. Desafortunadamente, la mayoría
de las redes tradicionales se aprovisionan de modo estático;
por eso, para aumentar la cantidad de terminales, servicios o
ancho de banda, es necesario planificar y rediseñar sustancial-
mente la red.
¿Adónde nos llevan las SDN?

En un principio, hubo mucha publicidad en torno a las SDN antes de
comprender los casos de uso reales de los clientes. Pero lo que
emerge lentamente e impulsa toda la inversión, los pilotos y los dise-
ños de productos es una mejor manera de administrar la WAN
empresarial, los centros de datos y las redes en la nube, y de auto-
matizar las tareas de TI para que la infraestructura pueda responder
con dinamismo a las condiciones y requisitos empresariales que
cambian rápidamente. La sagacidad para hacerlo realidad es migrar
de las consolas de administración de dispositivos y de los dispositi-
vos de red a los controladores de administración de políticas centra-
lizados y basados en SDN.
Lo que provocó la evolución más grande de las SDN es la certeza de
que muy pocas organizaciones tienen realmente el deseo, la habili-
dad y los incentivos para elaborar una nueva clase de aplicaciones
para programar la red. La gran mayoría de las organizaciones solo
busca automatizar las tareas de TI, acelerar la implementación de
aplicaciones, aportar más flexibilidad a las redes de la nube y ajustar
�� Capítulo 1: Introducción a las redes definidas por software 7
mejor su infraestructura de TI a los requisitos empresariales. El enfo-
que ha cambiado; las SDN son plataformas capaces de alojar un sin-
fín de soluciones de organización y automatización de flujos de
trabajo de TI que dirigen a los clientes hacia su objetivo final. Los
administradores de redes no necesariamente deberán desarrollar
nuevas aplicaciones; comprarán nuevas soluciones de automatiza-
ción listas para usar, basadas en plataformas y tecnologías de SDN.
Analizar por qué hay tanto entusiasmo

Las SDN ya generaron mucho interés y entusiasmo en la comunidad
de TI. En las siguientes secciones, se analizan brevemente algunas
de las razones de este suceso.
Las SDN facilitan la virtualización

de servidores y las redes en la nube
Tradicionalmente, las organizaciones han respondido de modo sim-
ple a la demanda creciente de capacidad de datos y a las necesida-
des cada vez mayores de ancho de banda; es decir, a la necesidad de
contar con capacidad de hardware adicional (y costosa).
Desafortunadamente, la mayoría de las corporaciones ya no pueden
solventar un enfoque tan costoso, especialmente a la luz del creci-
miento exponencial de la demanda. La competitividad extrema de
los mercados representa un obstáculo para solucionar este pro-
blema. Entre los beneficios, las SDN ayudan a aprovechar la virtuali-
zación de servidores para aumentar la eficiencia de los recursos,
reducir la complejidad de la red y simplificar los procesos manuales
de TI para implementar, administrar y ajustar aplicaciones y redes.
Un motivo por el que resultaba tan costoso el enfoque tradicional
para resolver la necesidad de aumentar los recursos de computa-
ción es que el modelo tradicional asignaba toda una unidad de com-
putación a una única tarea. Por ejemplo, cada usuario tenía su
propia computadora exclusiva, y cada servidor de red estaba com-
puesto por una computadora física ubicada en el rack de un centro
de datos. El enfoque más moderno usa la virtualización de servido-
res para que un único servidor físico funcione como si fueran en
realidad varios servidores: cada uno dedicado a ejecutar diferentes
tareas y a utilizar la capacidad total del servidor. Las SDN utilizan la
virtualización para ampliar significativamente la eficiencia de la red
y brindar soluciones a la necesidad de un aumento de la capacidad,
sin que resulte demasiado costoso y mediante la simplificación de la
administración de esos recursos consolidados.
Las SDN giran principalmente en torno

a la automatización basada en políticas
A medida que las redes crecen, su administración y mantenimiento
se tornan mucho más complejos. En el modelo tradicional, esta
complejidad significa que es necesario contar cada vez con más
recursos de TI para administrar procesos como el aprovisiona-
miento, la configuración y la corrección. En pocas palabras, general-
mente se trata de procesos manuales, por lo que ampliar la red de
decenas a centenares de nodos implicaba que alguien tenía que
intervenir y configurar manualmente diez veces más dispositivos.
Las SDN cambian esa ecuación de manera sustancial: automatizan
procesos como el aprovisionamiento, la configuración y la correc-
ción a través del software. En lugar de que un empleado de TI deba
configurar físicamente cada pieza de hardware, las SDN le permiten
implementar cambios en la red mediante el envío de actualizaciones
de software.
No todas las implementaciones de SDN son iguales. Por ejemplo, la
estructura de la Infraestructura centrada en aplicaciones (ACI) de
Cisco incluye dispositivos de redes inteligentes que simplifican
muchísimo la automatización de los procesos de red, ya que no es
necesario abordar específicamente cada dispositivo para propagar
correctamente esos procesos a donde deben aplicarse. Es recomen-
dable asegurarse de que la solución de SDN que se elija sea total-
mente compatible con las funciones de automatización que se nece-
sitan para aprovechar todos los beneficios de la migración a SDN.
ACI, la solución de SDN más completa de Cisco, acelera sustancial-
mente los tiempos de distribución de aplicaciones gracias a proce-
sos de TI simplificados y automatizados (consulte la Figura 1-1).
Figura 1-1: Cómo puede ayudar ACI.

Capítulo 2
Analizar los beneficios y

casos de uso de las SDN
En este capítulo
▶▶Aplicar algunas ideas nuevas
▶▶Conocer dónde se aplican las SDN
L as corporaciones por lo general no siguen las tendencias solo

porque son populares. En cambio, toman las decisiones en fun-
ción del retorno de la inversión (ROI). Algo como las SDN debe ofrecer
beneficios reales y cuantificables para justificar su implementación.
En este capítulo, se explican los tipos de beneficios que pueden alcan-
zar las organizaciones gracias a las SDN. También se demuestra de
qué manera los beneficios de las SDN van mucho más allá del centro
de datos corporativo.
La automatización de las SDN

genera dinamismo empresarial
A mayor dinamismo de TI, mayor será su capacidad de respuesta a las
exigencias de las aplicaciones y el negocio en constante cambio, y
mayor será la coordinación de TI con los objetivos empresariales, lo
que genera más oportunidades de ingresos y ventaja competitiva a
través de TI. El dinamismo y la coordinación de TI con los objetivos
empresariales en gran medida se logran gracias a los niveles infinita-
mente superiores de automatización de los procesos y la infraestruc-
tura de TI.
La automatización toma los pasos de la administración manual en
serie, dispositivo por dispositivo y componente por componente,
y los convierte en una plataforma de automatización basada en el soft-
ware que acelera los procesos de la infraestructura de manera
exponencial. Por ejemplo, el centro de datos habilitado para Cisco

ACI se construye sobre una plataforma de automatización basada en
políticas y centrada en aplicaciones que simplifica drásticamente la
representación de los requisitos del negocio y la aplicación.
Un nuevo enfoque para las políticas de la red

Cisco ha adoptado un enfoque de las políticas muy diferente a la de
varios de los proveedores de soluciones de SDN. Las políticas tradi-
cionales de SDN especificaban cómo debía comportarse la red en
términos de redes. Un mejor enfoque consiste en crear un lenguaje
de políticas que especifique lo que necesitan de la red las aplicacio-
nes empresariales. Las políticas se definen para grupos o clases de
aplicaciones y la red se ajusta a los requisitos de las aplicaciones.
El modo de implementación de la red no es directamente relevante
para las políticas empresariales globales de la organización. Pero el
modo de funcionamiento de las aplicaciones está estrechamente
relacionado con políticas y objetivos empresariales de alto nivel.
Esto coordina inmediatamente los departamentos de TI con las polí-
ticas de la empresa y otorga a TI una mayor capacidad de respuesta
a los requisitos empresariales.
Cisco denomina este nuevo enfoque política basada en grupos (GBP):
un modelo de políticas centrado en aplicaciones que separa la infor-
mación sobre los requisitos de conectividad de las aplicaciones de la
información sobre los detalles subyacentes de la infraestructura de
red. GBP simplifica mucho más la administración de la red y es uno
de los beneficios de la solución de SDN de Cisco.
Este enfoque ofrece varias ventajas, incluidas las siguientes:
✓✓ Una manera de expresar políticas más simple y orientada a la
aplicación: con la creación de políticas que reflejen la semán-
tica de la aplicación, este marco proporciona un mecanismo
más simple, que se documenta a sí mismo, para capturar los
requisitos de las políticas.
✓✓ Automatización mejorada: la agrupación de políticas permite
que las herramientas de automatización de alto nivel manipu-
len de manera fácil y simultánea grupos de terminales de red y
aplicaciones.
✓✓ Uniformidad: con la agrupación de terminales y la aplicación
de políticas a grupos de aplicaciones, el marco ofrece un modo
uniforme y conciso de administrar los cambios de políticas,
así como uniformidad en todas las cargas de trabajo físicas y
virtuales, y en los servicios de aplicaciones y dispositivos de
seguridad físicos y virtuales.
�� Capítulo 2: Analizar los beneficios y casos de uso de las SDN 11
A qué se refiere Cisco con las políticas

Las organizaciones tienen (al menos) un equilibrador de carga con una calidad
dos tipos de políticas: una política de servicio garantizada”.
empresarial y una política de TI. Las
La mayoría de las soluciones de SDN
políticas empresariales suelen expre-
están orientadas a configurar solamente
sarse en términos comerciales reales,
la red, en términos de redes; por ejem-
no técnicos, como: “Autorizamos el uso
plo: “Permitir tráfico en el puerto: 80”,
de este conjunto de aplicaciones en la
“Asignar VM a la VLAN 100”, etc. Como
nube cuando resulte rentable hacerlo o
las aplicaciones son la esencia de una
cuando se presente un umbral de activi-
empresa, resulta mucho más fácil coor-
dad determinado”. Las políticas de TI se
dinar las políticas empresariales con
reflejan generalmente en las funcionali-
las políticas de TI cuando las políticas
dades de los dispositivos (como servido-
de TI están centradas en aplicaciones;
res, switches o firewalls); por ejemplo:
es decir, pueden expresarse y adminis-
“Permitir tráfico en el puerto: 80 hacia
trarse en términos de los requisitos de la
este servidor” o “Descartar tráfico de
aplicación (como reflejo de la actividad
este dominio a alguna subred”.
comercial).
Resulta un verdadero desafío traducir las
Entonces, a diferencia de otras solucio-
políticas empresariales en políticas de TI
nes de SDN que, históricamente, se han
cuando las políticas de TI están orienta-
centrado en el lenguaje de la red, ACI
das a los dispositivos. Usan lenguajes
se centra en un nivel superior; expresa
completamente diferentes que se basan
las políticas en el lenguaje de los requi-
en conceptos diferentes. Una política
sitos de las aplicaciones. Esto acelera
de TI centrada en aplicaciones admite
la capacidad de respuesta de TI a las
comandos que se enfocan en la aplica-
exigencias comerciales, aumenta el
ción y no en el dispositivo. Por ejemplo:
dinamismo de la empresa y coordina la
“La aplicación X puede conectarse a la
empresa con las capacidades de TI.
aplicación Y a través de un firewall y de
✓✓ Modelo de políticas extensible: como el modelo de políticas

es abierto y se puede extender a otros proveedores y tipos de
dispositivos, puede incorporar fácilmente switches, routers,
seguridad, servicios de capa 4 a 7, etc.
Administración de políticas centralizada

con puntos de control distribuidos
Frente a los sistemas poco flexibles de administración de redes tra-
dicionales, las soluciones modernas de SDN proporcionan un enfo-
que completamente diferente para administrar redes; es mucho más
potente, eficaz y flexible. En lugar de solicitarle a un administrador
A qué se refiere Cisco

con centrarse en las aplicaciones
En muchas soluciones de SDN tradicio- un modelo de políticas centrado en apli-
nales o anteriores, la política de soft- caciones es muchísimo más relevante
ware era específica del componente de para la actividad comercial que otras
infraestructura o del tipo de dispositivo. políticas basadas en la red o en otras
Las reglas de políticas se expresaban en infraestructuras. De ese modo, es más
el lenguaje de los conceptos de redes fácil para TI implementar políticas y obje-
tradicionales, como flujos de red, direc- tivos comerciales. También permite que
ciones IP, VLAN, etc. El centro de datos el modelo de políticas se extienda más
centrado en aplicaciones de Cisco se allá de cualquier componente de infraes-
basa en un modelo de políticas que arti- tructura por sí solo (por ejemplo, la red
cula los requisitos de las aplicaciones en SDN) y que incluya la infraestructura
en términos de conectividad y políticas completa (redes, servidores, almacena-
de seguridad, y no de la infraestructura miento, seguridad, servicios de aplica-
(servidores y dispositivos de red). ciones) en un solo lenguaje de políticas
unificado. Con este modelo de políticas
La plataforma de automatización de ACI
centrado en aplicaciones, Cisco unifica
convierte estas reglas específicas de la
las operaciones y la infraestructura del
aplicación en la administración de toda
centro de datos en un solo sistema.
la infraestructura. La gran ventaja es que
que intervenga con cada dispositivo, este nuevo enfoque propor-

ciona un control de software programático desde un punto central
que ya no está restringido por los límites del sistema de administra-
ción de la red y que tampoco requiere conocer la interfaz de línea de
comandos (CLI) de los switches de la red y demás dispositivos. Los
repositorios de políticas centralizados permiten modificar y auditar
las políticas con mucha más facilidad. La distribución de esas políti-
cas a toda la red o infraestructura de nube desde un punto central
también permite ahorrar mucho tiempo, si lo comparamos con la
actualización de un nodo a la vez.
Cisco ACI utiliza un componente denominado Controlador de infraes-
tructura de política de aplicación (APIC). APIC se implementa como
un clúster de tres dispositivos para obtener los beneficios de la esca-
labilidad y la tolerancia a fallas. La función principal del clúster del
controlador es proporcionar mecanismos de aplicación de autoridad
y resolución de políticas. El sistema no participa directamente en el
reenvío del plano de datos ni en la aplicación de políticas en flujos de
redes individuales. Por eso, cualquier falla o desconexión completa
de todos los elementos de un clúster no dará lugar a ninguna pérdida
de funcionalidad en el centro de datos actual.
�� Capítulo 2: Analizar los beneficios y casos de uso de las SDN 13
De hecho, este nuevo enfoque utiliza software para indicar a los nodos
de red lo que usted desea que hagan, no cómo tienen que hacerlo. Los
diversos dispositivos son lo suficientemente inteligentes para com-
prender cómo aplicar las políticas, de manera que no es necesario
configurar individualmente cada dispositivo para que la red funcione
como se desea.
Algunos casos de uso populares

para implementar las SDN
Entre los casos de uso frecuentes de las SDN más allá de la automatiza-
ción de TI, el centro de datos y la nube en general, están incluidos los
siguientes:
✓✓ DevOps: DevOps, la integración sinérgica del desarrollo y las ope-
raciones, es un método de desarrollo de aplicaciones para organi-
zaciones de TI que aflora rápidamente con el objetivo de acelerar
la innovación de TI y la prestación de servicios (casualmente,
algunos de los mismos objetivos de SDN). La incorporación
de un enfoque basado en la tecnología de SDN puede facilitar
DevOps con la automatización de implementaciones y actuali-
zaciones de aplicaciones, y de los componentes de la infraes-
tructura de TI a medida que se implementan las aplicaciones y
plataformas de DevOps. DevOps permite que los desarrolladores
controlen mejor el entorno de TI, que no implica solamente una
capacidad de SDN subyacente. También es posible gracias a un
enfoque centrado en aplicaciones con respecto a las políticas, ya
que DevOps está muy orientado a la aplicación de software.
✓✓ Datos masivos y todo como servicio: los datos se recopilan e
intercambian de manera sistemática en la nueva economía. Los
datos masivos conllevan una nueva clase de aplicaciones con
uso intensivo de datos y servidores que representan una enorme
oportunidad para que las organizaciones alcancen una mayor efi-
cacia y competitividad. Pero deben implementarse sistemas para
aprovechar, administrar y obtener esos datos masivos de modo
eficaz y eficiente.
Las nubes están adoptando diversas formas: privadas, públicas
e híbridas (y muchas se combinan en entornos multinube). Los
procesos empresariales están cambiando; los sectores de servi-
cios están explorando modelos como servicio, en línea y virtua-
les para acelerar el negocio y su captación de clientes, partners y
proveedores. Las SDN pueden ayudar a automatizar e implemen-
tar estas nuevas arquitecturas de aplicaciones y a lograr que la
infraestructura se adapte rápidamente a los cambiantes requisi-
tos de las aplicaciones.
✓✓ Aplicaciones de movilidad e Internet de las cosas (IdC): la

tecnología para el consumidor está transformando las expec-
tativas tecnológicas en el trabajo. Se trata de un cambio demo-
gráfico hacia la movilidad: cada vez más clientes y empleados
exigirán a TI que les permita integrarse con las redes sociales
y que les ofrezcan más opciones en lo que respecta a los espa-
cios de trabajo flexibles y las tecnologías de colaboración.
Además, cada vez se conectan más cosas (a través de Internet
de las cosas o IdC), con la perspectiva de continuar expandién-
dose para conectar personas, procesos, datos y dispositivos
(Internet de todo o IdT). La naturaleza evolutiva de estos tipos
de aplicaciones y las exigencias de flexibilidad que imponen
en toda la infraestructura de red se pueden abordar más fácil-
mente con soluciones de SDN que con enfoques anteriores.
Llegar más allá de la red

y el centro de datos
A medida que las organizaciones descubren de qué manera se puede
beneficiar TI con la automatización de la red, comienzan a buscar
extender los beneficios fuera de la red y el centro de datos. Las SDN
se pueden aplicar en toda la infraestructura de computación, no solo
en la red, a fin de extender el control programático a todos los recur-
sos de TI que requieren las aplicaciones. Por ejemplo, la seguridad,
los diversos servicios de aplicaciones y los servidores pueden con-
formar una infraestructura más grande definida por software.
También se produce la consumerización de TI, ya que los usuarios
exigen más flexibilidad BYOD (Traiga su propio dispositivo) para
poder usar PC portátiles, tablets y smartphones personales para
acceder a la información corporativa. Un resultado de esta tendencia
es la necesidad de poner más énfasis en la protección de los datos
corporativos con políticas de seguridad y su aplicación. También en
este sentido, las SDN pueden desempeñar un rol fundamental en la
distribución de políticas en toda la infraestructura.
Cisco ACI incluye el módulo empresarial APIC EM, que extiende las
políticas de ACI del centro de datos a la red del campus, a la WAN y
al perímetro de acceso. El controlador APIC EM, que se basa en la
arquitectura de OpenDaylight Controller, es sumamente programable
mediante API abiertas (API de transferencia de estado representacio-
nal o RESTful y OSGi). Permite que los desarrolladores de software
independientes y de terceros creen aplicaciones y servicios de red
innovadores para fomentar el crecimiento comercial.
Capítulo 3
Comprender la tecnología
En este capítulo
▶▶Comprender los controladores
▶▶Conocer el rol de las políticas
▶▶Familiarizarse con las redes complementarias
▶▶Automatizar con SDN
L
os beneficios de una solución de SDN surgen de aplicar la
tecnología de maneras innovadoras. En algunos casos, la tec-
nología en sí es nueva; en otros, las SDN utilizan tecnologías
existentes, pero con un enfoque diferente del que se utilizaba en el
pasado.
En este capítulo, se analizan datos importantes que debe saber

acerca de la tecnología de SDN, de cómo se utiliza y de cómo se
adapta a los entornos de TI.
Comprender los controladores de SDN

La complejidad se convirtió en un obstáculo para la calidad y la
prestación del servicio de red empresarial en el momento justo.
Necesita un enfoque a la red abierto y programable a través de inter-
faces de programación de aplicaciones (API) abiertas para la admi-
nistración y la seguridad basadas en políticas. Básicamente, necesita
una manera de automatizar lo que ha sido, por tradición, la configu-
ración manual tediosa.
Un controlador de SDN es un repositorio centralizado de políticas e

instrucciones de control para la infraestructura de red o aplicacio-
nes. Una solución ideal ofrece servicios de red de manera constante
y proporciona información y análisis de la red a todos los recursos
de la red: infraestructuras físicas y virtuales, cableadas e inalámbri-
cas, y de LAN y WAN. Cuando desarrolla software de control para
implementar las políticas deseadas, por lo general, programa el con-

trolador y utiliza las API en el controlador.
El controlador acorta la brecha entre los elementos de red abiertos

y programables, y las aplicaciones que se comunican con ellos. Se
automatiza el aprovisionamiento (configuración y administración)
de toda la infraestructura, incluidos la red, los servicios y las
aplicaciones.
El controlador le proporciona una interfaz programática (a veces

denominada interfaz ascendente) para establecer políticas y aprovi-
sionar servicios en toda la red. Usted lo utiliza para eliminar la com-
plejidad de la red y ejecutar sin más la red física y virtual de manera
automática.
Para reducir la carga de administración de la red, el controlador con-

vierte la política empresarial directamente en una política a nivel de
los dispositivos de red. Automatiza la implementación, la verifica-
ción del cumplimiento y la aplicación de políticas de red en todo el
entorno. Un controlador también proporciona:
✓✓Uniformidad en la red empresarial, para minimizar el tiempo

de inactividad y reducir la complejidad operativa y el costo
relacionado.
✓✓ Aprovisionamiento y configuración automatizados y comple-
tos para permitir una rápida implementación de aplicaciones y
servicios.
✓✓ Soporte para implementaciones nuevas y existentes, que per-
mite implementar la programabilidad y la automatización en la
infraestructura actual.
En Cisco ACI, el controlador de APIC administra una política cen-

trada en aplicaciones que unifica los equipos de redes, seguridad,
servidores, almacenamiento, aplicaciones y la nube en torno a los
requisitos de infraestructura de las aplicaciones empresariales críti-
cas. Consulte la Figura 3-1.
Figura 3-1: APIC proporciona un controlador

�� Capítulo 3: Comprender la tecnología 17
de SDN común para los equipos

de TI.
Comprender las políticas

Las empresas deben implementar, ampliar y optimizar aplicaciones
a pedido para aumentar el dinamismo de la empresa y reducir los
costos operativos. Las SDN lo logran con extensiones programáticas
a la red para poder implementar las políticas en el software y que el
software pueda automatizar las tareas de administración de redes.
Así se reduce la necesidad de realizar operaciones manuales. Esto
permite alcanzar una escala similar a la de la nube, que admite cien-
tos de miles de servidores y millones de cargas de trabajo. Básica-
mente, las políticas de SDN de Cisco son instrucciones que le
indican al controlador cómo deben lidiar con la red y el tráfico de
aplicaciones los diversos elementos de la red.
El concepto central de ACI es el del perfil de red de aplicaciones

(ANP) (consulte la Figura 3-2 para ver una imagen de esto). El ANP
es una política que define los requisitos de la aplicación en términos
de los recursos de la red y de cómo se conectan los componentes
de la aplicación. Cuando se requieren nuevas instancias de una apli-
cación (para ampliar la capacidad o en una nueva ubicación), el ANP
se utiliza como plantilla. El ANP muestra cómo implementar la apli-
cación y todos los recursos y servicios que esta necesita donde-
quiera que pueda ubicarse de modo óptimo en la estructura de la
nube. ACI convierte esta plantilla replicable en una extensa serie de
comandos para dispositivos individuales a fin de configurar correcta
y automáticamente todos los servicios y componentes de la infraes-
tructura. Estos pasos tediosos ya no están a cargo de los administra-
dores (ni de varios equipos de administradores, lo que sería más
probable). Esta automatización acelera los procesos de TI, los coor-
dina con las necesidades empresariales y reduce los errores en las
implementaciones a gran escala.
Figura 3-2: Una política de red de aplicaciones que define la conectividad de las
cargas de trabajo, la seguridad y las políticas de servicio.
Para implementar políticas, Cisco utiliza una arquitectura abierta

que incluye el controlador de SDN y el repositorio de políticas, como
así también los nodos de la infraestructura (por ejemplo, dispositi-
vos de redes, switches virtuales, servicios de red, etc.) que monito-
rea el controlador. Además, existe un protocolo de comunicación
abierta entre el controlador y los nodos de la infraestructura (tam-
bién denominado protocolo o interfaz de tráfico descendente).
OpFlex es el nombre del protocolo de comunicación entre el contro-

lador y los dispositivos administrados en el sistema de Cisco ACI. El
diseño de OpFlex se pensó basándose en un modelo de políticas
centrado en aplicaciones. Con OpFlex, los dispositivos como swit-
ches y firewalls siguen aplicando las políticas en Cisco ACI. Este
enfoque ofrece la centralización de la administración de políticas
con control distribuido, lo que permite automatizar la infraestruc-
tura completa sin limitar la escalabilidad a través de un punto de
control centralizado ni crear un punto único de falla catastrófica.
Cisco ACI y OpFlex implementan lo que se denomina un modelo de

administración declarativo. Esto significa que la política está centrali-
zada, no así la aplicación de la política, que es distribuida (la ejecu-
tan los nodos de red que deciden sobre la mejor manera de aplicar
la política). Esto se compara con el modelo imperativo, en el que el
controlador emite todas las instrucciones de control en el momento
preciso, esto requiere que el controlador comprenda todos los esta-
dos de los dispositivos en tiempo real, lo que puede resultar poco
práctico. El modelo imperativo básicamente centraliza las políticas y
su aplicación, lo que puede resultar un obstáculo o crear un punto
único de falla.
Este diseño declarativo tiene sentido si tenemos en cuenta que las

maneras en que se configuran los dispositivos y se aplican las políti-
cas en los nodos de red varían considerablemente según los provee-
dores y los modelos. Estos detalles podrían sumarle complejidad al
modelo de políticas o generar una política que no permita aprove-
char por completo todas las funcionalidades de cada dispositivo si
todo llegara a ejecutarse directamente dentro del controlador. El
resultado probable sería un sistema patentado con dispositivos con-
trolados que siguen el modelo de una pequeña cantidad de tipos de
dispositivos o productos de un mismo proveedor.
OpFlex utiliza declaraciones de políticas de alto nivel y orientadas a

la aplicación que se envían a los nodos de red, y delega a esos dispo-
sitivos la decisión sobre el modo de implementación de las políticas.
Tras realizarse las configuraciones de dispositivos, como la configu-
ración de un controlador de distribución de aplicaciones para dar
soporte a un determinado servicio, la comunicación entre el contro-
lador y la infraestructura puede requerirse únicamente cuando
deban actualizarse las políticas.
OpFlex es un protocolo de comunicación bidireccional. Además de

la comunicación en forma de comandos desde el controlador hasta
los dispositivos administrados, pueden enviarse métricas útiles del
estado, el rendimiento y la condición desde los nodos de red hasta
el controlador o hasta un motor de análisis externo (también deno-
minado observador).
Evaluación de las redes

complementarias en entornos de SDN
Con la amplia adopción de la virtualización de servidores, las redes
virtuales son cada vez más importantes para la infraestructura gene-
ral del centro de datos y la nube. Por lo tanto, los casos de uso prin-
cipales de las SDN incluyen redes en la nube y aplicaciones
virtuales. Las redes virtuales proporcionan una infraestructura flexi-
ble y programable que las SDN pueden aprovechar. Una red virtual
puede denominarse red complementaria cuando define una nueva
topología lógica por encima de una red física subyacente.
Las redes superpuestas virtuales son redes virtuales separadas lógi-

camente de los nodos interconectados que comparten una red física
subyacente y que permiten la implementación de aplicaciones que
requieren topologías de red específicas sin la necesidad de modifi-
car la red física o subyacente. Por lo general, se utilizan para aislar
abonados y aplicaciones que comparten la misma red física, como
es el caso de un proveedor de la nube. Un abonado es un usuario de
los recursos de nube compartidos. Un abonado podría ser una orga-
nización con todas sus aplicaciones o una aplicación que incluya
varias cargas de trabajo conectadas lógicamente, pero aisladas del
resto de las redes de la aplicación.
Las redes superpuestas ofrecen distintos beneficios que ayudan a

resolver algunos de los desafíos del centro de datos moderno:
✓✓Escalabilidad y flexibilidad de la estructura: las tecnologías

de superposición permiten que la red se amplíe con un enfo-
que en los dispositivos perimetrales de la red superpuesta. Si
las superposiciones se utilizan en el perímetro de la estructura,
los dispositivos principales y centrales ya no deben agregar
información del host final a sus tablas de reenvío. Además,
la ubicación de los hosts finales es más flexible porque la red
superpuesta virtual ya no necesita limitarse a una única ubica-
ción física.
✓✓ Conectividad arbitraria de Capa 2 sobre Capa 3 subyacente:
otro beneficio de las tecnologías de redes superpuestas es que
pueden desacoplar los servicios de red proporcionados a los
hosts finales de la topología que se utiliza en la red física. Por
ejemplo, a través de ciertas tecnologías de redes superpuestas,
los servicios que requieren una red de Capa 2 pueden exten-
derse a través de una topología de Capa 3 con routing.
✓✓ Superposición de direcciones: la mayoría de las tecnologías
de superposición utilizadas en el centro de datos permiten que
las ID de redes virtuales alcancen e identifiquen de manera
exclusiva redes privadas individuales. Este alcance facilita una
posible superposición de direcciones MAC e IP entre los abo-
nados. El encapsulado de superposiciones también permite
administrar el espacio para la dirección postal de la infraes-
tructura subyacente aparte del espacio para la dirección postal
del abonado.
✓✓ Separación de roles y responsabilidades: con el encapsulado
utilizado en las tecnologías de superposición, también se
pueden separar los dominios de administración. El administra-
dor de la estructura de la nube (infraestructura) puede quedar
a cargo de las direcciones, la disponibilidad y el equilibrio de
carga de la estructura, mientras que los abonados individuales
pueden quedar a cargo de sus propias políticas y servicios de
direccionamiento sin afectar las políticas de la infraestructura.
VXLAN (red de área local virtual extensible) es un protocolo de

superposición desarrollado inicialmente por Cisco y que VMware,
Red Hat, Citrix y otros proveedores de infraestructura de virtualiza-
ción transformaron en estándar. Se utiliza en muchas instalaciones
de SDN, especialmente donde se emplean hipervisores de VMware o
KVM. Otra tecnología de red complementaria común es NVGRE
(virtualización de red mediante encapsulado de routing genérico),
que es común en los entornos de centros de datos de Microsoft.
VXLAN y NVGRE son dos ejemplos de redes complementarias que

abarcan no solo las redes físicas de Capa 2, sino también las redes
con routing de Capa 3. Esto significa que puede tener una red
VXLAN que se extiende mediante conexiones de Capa 3 a otros cen-
tros de datos y proveedores de la nube. Tienen el alcance que usted
necesite.
Estas redes complementarias se implementan mediante el encapsu-

lado de paquetes de red dentro de un nuevo encabezado de paque-
tes superpuestos que pueden o no reconocer los dispositivos de
red. Solo los switches de borde que representan el inicio y el final
del túnel de superposición deben encapsular o desencapsular el
paquete. Los dispositivos de red intermedios pueden dejar pasar los
paquetes sin impedimentos.
Cualquier plataforma de automatización en la nube que se ejecute

en una arquitectura de SDN necesariamente deberá comprender
cómo instalar y configurar estas redes superpuestas virtuales para
dar soporte a las implementaciones de aplicaciones y establecer
nuevos abonados en entornos de nube. Los switches virtuales,
firewalls virtuales, etc. también deberán integrarse a la infraestruc-
tura de SDN (comunicarse mediante los protocolos correctos, por
ejemplo, e interactuar con el controlador de SDN).
Automatización de la nube
a través de SDN
La infraestructura del centro de datos está pasando de ser un
entorno que admite cargas de trabajo relativamente estáticas limita-
das a silos de infraestructura específicos a ser un entorno de nube
sumamente dinámico en el que cualquier carga de trabajo puede
aprovisionarse en cualquier lugar y ampliarse a pedido según las
necesidades de la aplicación. Gracias a esta transición, los desarro-
lladores pueden crear la próxima generación de aplicaciones de TI;
al mismo tiempo, también surgen nuevos requisitos para la infraes-
tructura de computación, almacenamiento y red.
Las soluciones de SDN pueden ofrecer una estructura sólida para

alojar y agregar valor a soluciones de automatización en la nube,
que brindan servicios de automatización de procesos y flujos de
trabajo de nivel superior, y delegan a la estructura subyacente de

SDN la programación, el aprovisionamiento y la configuración de los
nodos de la infraestructura. La estructura ideal de SDN podrá alojar
una gran variedad de herramientas de automatización en la nube y
de flujos de trabajo a través de interfaces ascendentes abiertas en el
controlador de SDN. Esta flexibilidad dará a los clientes la posibili-
dad de elegir las herramientas de automatización para sus
necesidades.
OpenStack es una herramienta de organización en la nube líder y de

código abierto que está disponible actualmente y que cuenta con el
respaldado de más de 125 empresas. OpenStack fue diseñada como
bloque funcional para nubes públicas y privadas; permite la admi-
nistración automatizada y sumamente flexible de recursos de com-
putación, almacenamiento y redes.
Cisco ACI y OpenStack fueron diseñados para ayudar a los adminis-

tradores de TI a atravesar la transición a las arquitecturas en la
nube. Cisco está extendiendo el marco de políticas de ACI a los
entornos OpenStack para que los clientes puedan elaborar políticas
de red enriquecidas e impulsadas por aplicaciones en sus entornos
de nube. Además de ACI, las organizaciones ahora pueden tener una
solución OpenStack certificada, compatible y lista para usar.
La estructura de ACI ofrece funcionalidad nativa con encadena-

miento de servicio que permite a un usuario insertar o quitar servi-
cios (como un controlador de distribución de aplicaciones o un
firewall) con transparencia entre dos terminales. Estos servicios son
parte del contrato entre dos grupos de terminales (EPG) en la arqui-
tectura de ACI. La estructura se puede configurar en tiempo real
mediante la API del dispositivo de servicio (por ejemplo, el firewall),
lo que simplifica la implementación de aplicaciones complejas y de
políticas de seguridad de modo absolutamente automatizado.
Capítulo 4
Consideraciones
y requisitos clave de SDN
En este capítulo
▶▶Comprender por qué debe centrarse en la aplicación
▶▶Conocer cómo se pueden mantener abiertas las opciones
▶▶Mantener lo que ya tiene
E l surgimiento de las redes definidas por software (SDN) promete

una nueva era de herramientas de automatización con adminis-
tración centralizada y basadas en políticas que podrían acelerar la
administración, la optimización y la corrección de redes. Para alcan-
zar esos objetivos, debe conocer algunas consideraciones y requisitos
relacionados con las SDN; por eso, en este capítulo se analizan diver-
sos temas importantes que lo ayudarán a comprender lo que necesita.
Enfoque en las aplicaciones

Las empresas buscan herramientas de automatización en la nube y
arquitecturas de SDN para acelerar la distribución de aplicaciones,
reducir los costos operativos y aumentar el dinamismo de la empresa.
El éxito de una solución de automatización de TI o la nube depende,
en gran medida, de las políticas empresariales que puede aplicar la
infraestructura mediante una arquitectura de SDN. Necesita un len-
guaje de políticas de aplicación más relevante para la empresa, más
escalabilidad a través de un sistema de aplicación distribuida y no del
control centralizado, y más visibilidad de la red.
Históricamente, los departamentos de TI han buscado más automati-
zación para superar los desafíos de la aplicación de procesos manua-
les a tareas críticas. Hace alrededor de 20 años, era imprescindible
automatizar la administración de equipos de escritorio y PC. Hace
unos 10 años, la automatización de servidores cobró importancia a

medida que las aplicaciones comenzaron a migrar a una gran canti-
dad de sistemas. Actualmente, con la consolidación de los centros
de datos, TI debe abordar no solo la proliferación de aplicaciones y
datos, sino también el surgimiento de la virtualización de aplicacio-
nes a gran escala y de las implementaciones en la nube.
Se necesita una estructura de red diseñada como una red inteligente
centrada en aplicaciones, en la que el modelo de políticas se defina
de manera descendente como un motor de aplicación de políticas
centrado en la aplicación propiamente dicha y donde se abstraigan
las funciones de red subyacentes.
Este modelo de políticas se basa en una serie de uno o más abona-
dos, que permiten aislar la administración de la infraestructura de
red y los flujos de datos. Los abonados pueden ser clientes, unida-
des de negocios o grupos, según las necesidades de la organización.
Por debajo de los abonados, el modelo brinda una serie de objetos
que definen la aplicación propiamente dicha. En el sistema Cisco
ACI, estos objetos son grupos de terminales (EPG) y las políticas
que definen sus relaciones. La relación entre dos terminales, que
podrían ser dos máquinas virtuales conectadas en una aplicación
web de varios niveles, se puede implementar mediante el routing del
tráfico que circula entre los terminales hacia los firewalls y controla-
dores de distribución de aplicaciones (ADC) que aplican las políticas
adecuadas para esa aplicación.
Las soluciones de SDN anteriores que estaban orientadas a los pro-
tocolos de red y no a los requisitos empresariales y la aplicación no
pueden igualar la escalabilidad, flexibilidad ni integración de las
estructuras más integrales que cuentan con un modelo centrado en
aplicaciones.
La infraestructura de Cisco ACI admite un enfoque centrado en apli-
caciones y los requisitos de un modelo de políticas basado en gru-
pos, a través de:
✓✓El modelo de control declarativo inherente a través del proto-
colo de OpFlex
✓✓ El lenguaje de las políticas basado en los requisitos de la apli-
cación
✓✓ La flexibilidad para incorporar una amplia gama de dispositi-
vos de red como puntos de control de políticas para implemen-
tar directivas de políticas
�� Capítulo 4: Consideraciones y requisitos clave de SDN 25
Mantener la apertura
Durante el último tiempo, muchos personas del sector de computa-
ción adoptaron maneras de trabajar abiertas o genéricas. Este enfo-
que abierto evita que un mismo proveedor lo limite a comprarle
siempre a él, lo cual aumenta la competitividad del mercado. En lugar
de quedar limitado a una única fuente, el mercado puede elegir los
mejores productos de diferentes proveedores. La mayoría de los
defensores del código abierto sienten que esta apertura lleva a mejo-
rar los productos, reducir los costos y aumentar el retorno de la
inversión.
SDN es un enfoque abierto y transparente a las necesidades en desa-
rrollo de las redes en la nube y la administración del centro de datos.
De hecho, algunos de los nombres más importantes del sector de
computación (incluidos Arista Networks, Big Switch Networks,
Brocade, Cisco, Citrix, Ericsson, HP, IBM, Juniper Networks,
Microsoft, NEC, Nuage Networks, PLUMgrid, Red Hat y VMware) fun-
daron el proyecto OpenDaylight en 2013 para colaborar en el diseño
de una arquitectura de controlador de SDN de código abierto. Cisco
también aportó componentes clave de sus tecnologías de SDN a gru-
pos de estándares como IETF, el consorcio OpenStack y el proyecto
OpenDaylight en sí.
Si bien SDN comenzó como un enfoque abierto, no significa que
todas las soluciones de SDN sean iguales. Es probable que algunos
proveedores de SDN lo limiten a usar ciertos componentes si usted
adopta sus ofertas de SDN, como tener la obligación de usar su hiper-
visor o plataforma de automatización en la nube, incluso si algunos
de los componentes cumplen con estándares de SDN específicos.
SDN: protocolos abiertos,

arquitecturas abiertas, ecosistemas
abiertos y código abierto
Un marco de automatización de centros de datos de SDN, como Cisco
ACI, no puede ser una arquitectura monolítica patentada. Las organi-
zaciones requieren una arquitectura abierta, extensible y de varios
proveedores que incorpore una amplia gama de productos de infraes-
tructura y soluciones de código abierto. ACI fue diseñado como un
sistema abierto, que incluye lo siguiente:
✓✓Gran ecosistema de ACI: desde principios de 2015, Cisco ACI

ha desarrollado, con los principales partners, un ecosistema
de soluciones para centros de datos de varios proveedores,
grande y compatible. Este ecosistema incluye:
• Servicios
• de aplicaciones de capa 4 a 7: A10 Networks,
Citrix, Embrane, F5 y Radware
• Soluciones
• de seguridad: Catbird, Check Point, Cisco
ASA, SourceFire y Symantec
• Infraestructura
• de virtualización y servidores:
Canonical Ubuntu, Microsoft, Red Hat y VMware
• Organización
• en la nube: Cisco UCS Director,
Cloudstack, Microsoft System Center y Azure,
OpenStack, y VMware vCenter y vCloud Automation
Center
• Soluciones
• de DevOps: Puppet, Chef y CFEngine
• Herramientas
• de monitoreo, administración y análisis:
CA Technologies, Cisco Prime NAM, Emulex, NetScout,
NetQoS y Splunk
• Infraestructura
• convergente, de servidores, almace-
namiento y aplicaciones: bmc, Cloudera, EMC, MapR,
NetApp, Nutanix, Panduit, VCE y SAP
✓✓ API abiertas: las interfaces ascendentes abiertas en el contro-
lador de APIC son compatibles con varias herramientas comer-
ciales de organización y automatización, además del modelo
de políticas de ACI.
✓✓ Protocolos de comunicación abiertos: el protocolo de
comunicación (OpFlex) del controlador de APIC (interfaz
descendente) a los dispositivos administrados es un estándar
publicado, junto con el diseño del agente del lado del dis-
positivo (disponible como diseño de referencia y de código
abierto), de modo que los dispositivos compatibles (nuevos
switches, servicios de aplicaciones, etc.) puedan ser compati-
bles con ACI.
✓✓ Esfuerzos de código abierto: se ofrecieron componentes
de diseño clave de la arquitectura de ACI a la comunidad de
código abierto para aumentar la innovación, facilitar el desa-
rrollo de productos compatibles y fomentar aún más un ecosis-
tema compatible con varios proveedores, a saber:
• Se
• aportó la especificación del modelo de políticas de ACI
al proyecto OpenDaylight para que se incluya en el con-
trolador de código abierto.
• Se
• aportaron la especificación del modelo de políticas de
grupo y las especificaciones de interfaces al consorcio
OpenStack.
• Se
• distribuyó un agente de OpFlex para Open Virtual
Switch (OVS) a través de los principales provee-
dores de código abierto de Linux (Canonical y Red
Hat) y de Microsoft por su switch virtual basado en
Windows Server.
Mantener lo que ya tiene

mediante Cisco ACI
A la gran mayoría de las organizaciones, no le resulta razonable des-
cartar la inversión que han hecho en la infraestructura de redes
actual y empezar de cero. Sin dudas, lo ideal es aprovechar las venta-
jas de implementar una solución de SDN, pero también utilizar lo que
ya se posee. El desafío es encontrar la manera de hacer las dos cosas.
Cisco ACI introdujo un modelo de programabilidad y lenguaje cen-
trado en aplicaciones que se ajusta los objetivos comerciales y de la
aplicación para simplificar las implementaciones de políticas y coor-
dinar las necesidades empresariales del departamento de TI. ACI
también extiende los enfoques de SDN específicos de la red a la
infraestructura del centro de datos con la incorporación de servido-
res, almacenamiento, servicios de aplicaciones y seguridad en un
único modelo de políticas.
Para lograr esta nueva arquitectura de estructura, se incorporaron
funciones críticas a los switches Cisco Nexus de la serie 9000, inclui-
das las superposiciones optimizadas por hardware, que simplifican la
topología de la red y segmentan las redes de abonados y de la aplica-
ción. APIC, el controlador de infraestructura de ACI, mantiene las
políticas de la aplicación y las plantillas de dispositivos que configu-
ran, aprovisionan y administran los nodos de la estructura, incluidos
los servicios de aplicaciones, los dispositivos de seguridad y la
infraestructura virtual para dar soporte a la implementación y optimi-
zación automatizadas de la aplicación.
Esta arquitectura de ACI está diseñada para aplicar reglas de políticas
a un elemento fundamental de la aplicación, un terminal, o a una
clase de terminales similares, que se denomina grupo de terminales

(EPG). Los terminales básicamente son cargas de trabajo físicas o
virtuales con varios EPG que integran los diferentes niveles de una
aplicación de varios niveles.
Con la adopción y la migración a la arquitectura de ACI, un requisito
fundamental es que pueda utilizar sus inversiones actuales en swit-
ching de centros de datos en el hardware de Cisco Nexus anterior a
ACI. El objetivo es administrar las aplicaciones del centro de datos
como EPG que se administran en APIC, pero que se conectan a tra-
vés de otras redes (redes que no son de Cisco Nexus 9000). Además,
a medida que se desarrollan estructuras de ACI para preservar la
inversión que se hizo en los modelos actuales, se busca utilizarlos
en la nueva red de ACI desde una plataforma de organización común
y conforme a una política común siempre que sea posible.
La mayoría de los clientes que actualmente implementan las estruc-
turas de Cisco ACI tienen redes existentes de Cisco Nexus, por lo
general de tres niveles (perímetro, agregación y núcleo), sobre la
base de una combinación de dispositivos Cisco Nexus de las series
2000, 3000, 5000, 6000 y 7000. Estas redes existentes admiten una
combinación de cargas de trabajo físicas y virtuales, con cargas de
trabajo virtuales conectadas a extensores de estructura (FEX) o a
switches virtuales. Además de desarrollar nuevos POD basados en
ACI, le conviene utilizar la arquitectura existente para aplicar políti-
cas de ACI a los EPG conectados a la estructura.
Para cumplir con este requisito, Cisco extiende la compatibilidad de
la política de ACI a las cargas de trabajo de la aplicación en toda la
red existente a través de un switch virtual Nexus 1000V habilitado
para ACI, que se denomina switch virtual de aplicaciones (AVS). En
este caso, todo el tráfico de datos atraviesa la infraestructura previa
a la incorporación de ACI; el tráfico fluye hacia un switch de red
Nexus de la serie 9000 administrado por APIC. La red puede tener
cualquier cantidad de capas (puede ser una red de dos o tres nive-
les); los switches AVS se ejecutan en los servidores para conectarse
con las cargas de trabajo virtuales de EPG. Las cargas de trabajo
físicas pueden conectarse directamente a un switch Nexus 9000 Top
of Rack (ToR).
La conectividad de las cargas de trabajo de EPG a EPG dentro de esa
red en servidores separados podría administrarse con normalidad;
por ejemplo, a través de un túnel VXLAN entre servidores, sin llegar
al gateway para comunicarse con las cargas de trabajo de la red de
ACI. Todas las cargas de trabajo se pueden administrar y aprovisio-
nar como EPG, con políticas uniformes en todos los servidores y
segmentos de la red, y conforme a un único modelo de organización
y controlador de políticas. APIC también es compatible con software
de organización en la nube, como OpenStack y Cisco UCS Director,
a través de interfaces ascendentes en el controlador.
El modelo de políticas de ACI proporciona la capacidad para agru-
par los objetos del EPG según cuál sea el servicio que proporcionan
y cuáles sean la política y conectividad requeridas. Esta caracterís-
tica atenúa las restricciones que implican las redes actuales, que
exigen métodos de reenvío como el uso de VLAN y subredes para
este fin. En este modelo, se crean los grupos de objetos, y la aplica-
ción de políticas y la conectividad se integran a ellos.
Como la configuración de políticas es el cambio más complejo y
tedioso en una red cuando se agregan, quitan, expanden o migran
aplicaciones, es fundamental automatizar los cambios de políticas.
Las VLAN, subredes, etc. existentes ya se configuraron y no necesi-
tan modificaciones frecuentes. Son las políticas de dispositivos indi-
viduales que se asignan a cada aplicación las que cambian con
frecuencia. Por eso, los paquetes de dispositivos y las definiciones
de políticas dentro de APIC pueden automatizar completamente los
cambios de políticas, sin la necesidad de reconfigurar la topología
o el equipo de red existente.
El diseño de la estructura de ACI posibilita la incorporación de redes
Nexus de las series 2000, 3000, 5000, 6000 y 7000 en una plataforma
común de organización en la nube. También permite administrar las
cargas de trabajo de la aplicación conectadas a la red previas a la
incorporación de ACI; estas cargas de trabajo se administran como
grupos de terminales de APIC. Esta capacidad permite conservar la
inversión que se ha hecho en los switches existentes, que pueden
utilizarse en el nuevo modelo de estructura de ACI.
Capítulo 5
Diez datos importantes

sobre la evaluación de
soluciones de SDN
En este capítulo
▶▶Diez datos sobre SDN
E n los capítulos anteriores, ya abarcamos varios temas para

ponerlo al día sobre SDN. En este capítulo, reunimos toda esa
información para exponer diez datos importantes que querrá consi-
derar mientras evalúa las soluciones de SDN.
Programación vs.
administración manual
Una definición moderna y útil de SDN anuncia que la infraestructura
de red ahora puede programarse mediante software. Esta programa-
bilidad es un cambio muy importante frente al método tradicional
de administrar la red a través de la interfaz de línea de comandos o
de la interfaz gráfica de usuario (GUI) o consola de administración.
La programabilidad de SDN da lugar a una mayor flexibilidad, a polí-
ticas más sofisticadas y a redes más dinámicas en general.
Las SDN no necesariamente exigen separar el plano de control de la

red del plano de datos, tal como muchos lo definieron original-
mente. En la actualidad, existen varias tecnologías, protocolos y
arquitecturas interrelacionados que dan lugar a la automatización
basada en políticas y que alcanzan la visión original de SDN.
Dar lugar a una implementación

de políticas más fácil
Los programas de SDN que administran y controlan la infraestruc-
tura también se conocen como políticas. Pueden reflejar objetivos
sofisticados de políticas de aplicación, TI o la empresa; independien-
temente de lo que se pueda implementar en el software dentro del
marco de SDN. Con la implementación de políticas en el software en
lugar del misterioso lenguaje y las enigmáticas herramientas de
administración de los dispositivos de red, las políticas pueden ajus-
tarse más fácilmente a los requisitos del negocio e implementarse y
mantenerse de manera mucho más sencilla. Esto permite que SDN
sea la clave para la automatización basada en políticas, que reduce
la complejidad y los gastos operativos con la automatización de
muchas de sus tareas de TI y con la posibilidad de agregar mucha
más escalabilidad para las redes en la nube.
Compatibilidad con ecosistemas de

varios proveedores
No hay que olvidar otra consideración importante: para que el
modelo de políticas de SDN pueda automatizar toda la infraestruc-
tura de la aplicación, la plataforma de SDN debe dar soporte a un
gran ecosistema de varios proveedores con una cantidad impor-
tante de tipos de dispositivos de infraestructura. Debe tener en
cuenta cuáles son los firewalls, controladores de distribución de
aplicaciones y otros dispositivos de seguridad compatibles con los
estándares y la arquitectura de SDN propuesta.
Esta consideración también incluye la posibilidad de incorporar la

infraestructura de red existente en el entorno de SDN cuando esté
desarrollado o el grado de actualización del hardware conforme a
los dispositivos compatibles con SDN.
En el caso de Cisco ACI, hay un gran ecosistema de partners que

cumplen con ACI, incluidos F5, Citrix, Check Point, Cisco ASA con
servicios de seguridad FirePOWER y muchos otros.
Esta gran cantidad de proveedores y soluciones le proporciona
mucha más flexibilidad.
Capítulo 5:DiezdatosimportantessobrelaevaluacióndesolucionesdeSDN 33
Comprender la importancia
del controlador
En la mayoría de las plataformas de SDN, al repositorio de políticas
de software, que es el cerebro de la automatización de TI, por lo
general se lo denomina el controlador. La arquitectura del controla-
dor es la clave para muchas de las funciones de la plataforma de
SDN, para el modo de programación y para los dispositivos que pue-
den controlarse. Puede haber una variedad de controladores y plata-
formas para tener en cuenta cuando selecciona una estrategia de
SDN, por eso asegúrese de elegir un controlador que haga todo lo
que necesita. Un controlador registrado o que sea compatible con
un modelo acotado de políticas de SDN limitará sus capacidades en
el futuro.
Emplear el lenguaje correcto

El lenguaje (o modelo de políticas) de la política o el controlador de
SDN determina en gran medida cómo puede automatizarse la
infraestructura y la flexibilidad que tiene para programarla. Por
ejemplo, Cisco ACI presenta un modelo de políticas centrado en apli-
caciones que representa la política de SDN en términos de requisitos
y capacidades. Este modelo permite que una sola política se
extienda a toda la infraestructura de TI, incluidas las redes, la seguri-
dad, los servicios de aplicaciones, etc.
Si implementa el modelo de políticas correcto, podrá extender las

ventajas y la metodología de SDN más allá de la red, hasta la infraes-
tructura de aplicaciones completa y más allá del centro de datos,
hasta la WAN del campus y sitios remotos.
Utilizar una línea ascendente

Los programas de software personalizados que se desarrollan para
un entorno de SDN en general se ejecutan por encima del controla-
dor de SDN a través de una interfaz ascendente: una API que se eje-
cuta en el controlador y que aloja aplicaciones de software. Las
especificaciones de esta API ascendente también pueden influir con-
siderablemente en la flexibilidad para programar las acciones de la
infraestructura y su modo y en las tareas de automatización que
puede realizar su plataforma de SDN.
La API ascendente debe ser abierta y flexible, y debe estar muy inte-
grada con las funcionalidades de controlador. También debe ser
compatible con aplicaciones como las herramientas de organización
en la nube que deberá ejecutar.
Usar las herramientas de

automatización en la nube
Muchas de las aplicaciones de SDN de la nueva generación que resi-
den en la API ascendente del controlador son en sí herramientas de
automatización en la nube. Sirven para administrar flujos de trabajo
y tareas para implementar aplicaciones en la nube y administrar la
infraestructura. Estas herramientas dependen del controlador de
SDN para conectar y controlar los componentes individuales de la
infraestructura (switches, servidores, firewalls, etc.) de acuerdo con
la política de SDN y las herramientas de automatización de alto
nivel.
Algunos ejemplos de plataformas de automatización en la nube que

pueden implementarse por encima de las interfaces ascendentes del
controlador de SDN son OpenStack y Cisco UCS Director.
Escoja una plataforma de SDN que le brinde la máxima flexibilidad

en herramientas y plataformas de automatización en la nube, en
lugar de limitarse a la pila de la nube de un solo proveedor. Además
de las herramientas de administración de la nube, la plataforma de
SDN debe ser compatible con varias herramientas de monitoreo y
rendimiento que ayudan a analizar y automatizar la adaptación de
aplicaciones y la red, y a solucionar problemas.
Tener en cuenta una

arquitectura extensible
Como el controlador de SDN es el concentrador operativo de todos
sus esfuerzos de integración y automatización, debe ser una arqui-
tectura abierta y extensible de varias formas importantes (como una
API ascendente abierta y flexible para alojar varias aplicaciones o
herramientas de automatización en la nube). Debe tener una manera
abierta de comunicarse con una infraestructura de TI de switches,
routers, firewalls, controladores de distribución de aplicaciones, etc.
Capítulo 5:DiezdatosimportantessobrelaevaluacióndesolucionesdeSDN 35
de varios proveedores. Asegúrese de que la arquitectura de SDN
cumpla con todos los requisitos de apertura para dirigir y simplifi-
car correctamente las implementaciones.
OpenFlow fue uno de los primeros ejemplos de una manera abierta

de integrar switches de varios proveedores en un solo controlador
de SDN, pero ahora se han desarrollado protocolos y dispositivos
más sofisticados para las plataformas de SDN modernas. Por ejem-
plo, la plataforma Cisco ACI utiliza OpFlex como una manera abierta
y genérica de comunicarse con una amplia variedad de tipos de pla-
taformas y dispositivos de proveedores.
Seleccionar cuidadosamente una

plataforma de SDN de código abierto
La apertura e interoperabilidad son muy importantes para cualquier
estrategia de SDN; no es nada deseable quedar limitado a una plata-
forma de controlador en particular. También puede considerar utili-
zar un controlador de código abierto. Con esta opción, se puede
tener una arquitectura menos costosa al principio, pero es posible
que se restrinja la integración a una política más acotada que se eje-
cute en varios componentes de la infraestructura o bien que se
requiera mucha personalización e integración para cualquier requi-
sito de políticas o entorno de nube determinado.
Una plataforma de SDN abierta debe ser compatible con los princi-
pales sistemas operativos de servidores y plataformas de hiperviso-
res como VMware, Microsoft y Linux KVM para proporcionar lo
máximo en cobertura y flexibilidad.
Cuando consideramos un controlador de SDN de código abierto,

como OpenDaylight, un requisito importante es el tamaño del eco-
sistema de proveedores que admite, los proveedores clave que pue-
den proporcionar soluciones listas para usar en entornos
específicos, y un modelo de políticas abierto que facilite la máxima
flexibilidad en términos de automatización y programabilidad. Cisco
ACI, por ejemplo, aportó su modelo de políticas centrado en aplica-
ciones al proyecto del controlador OpenDaylight. Cisco también
admite la implementación comercial del controlador OpenDaylight
para redes empresariales y proveedores de servicios.
Mantener la transparencia
Como los entornos de nube se conforman de aplicaciones virtuales
e instaladas directamente en el hardware, así como de infraestructu-
ras físicas y virtuales (redes, firewalls, nodos de servicio), la plata-
forma de SDN, las políticas y las herramientas de automatización
deben funcionar de manera transparente en todo el espectro físico y
virtual. Muy a menudo, la automatización solo se aplica a la infraes-
tructura virtual o a una clase determinada de dispositivos físicos,
por ejemplo, a switches de un proveedor específico. Una estrategia
útil en materia de SDN debe abarcarlo todo; la estrategia de automa-
tización de TI debe incluir un conjunto común de políticas, herra-
mientas e infraestructura para que sea exitosa.
Apéndice
Acrónimos de SDN
S DN es un desarrollo bastante reciente, sin embargo resulta
imposible entenderlo con la ayuda de toda la terminología
especializada, la jerga y los acrónimos que se han desarrollado para
describir el tema. A veces, puede parecer que los expertos en SDN
hablan en otro idioma, un idioma extraño y exótico.
En este apéndice, se recopiló toda la terminología sobre SDN,

redes y seguridad que pudimos adaptar al espacio disponible
para que no se siga preguntando de qué están hablando los que
hablan de SDN. Las entradas aparecen en orden alfabético para
que le resulte más fácil y rápido buscar las definiciones, pero le
recomendamos que se tome el tiempo para leer toda la lista; es
probable que encuentre alguna información valiosa.
Abonado: contenedor lógico para la red virtual, los recursos, las

políticas y las aplicaciones que representa a la organización o
usuario de la nube.
ACI: Infraestructura centrada en aplicaciones; la arquitectura de

SDN más completa de Cisco.
ACL: Listas de control de acceso.
ADC: Controlador de distribución de aplicaciones.
Administrador de eventos: repositorio de todos los eventos y

fallas iniciados desde APIC o los nodos de la estructura.
Administrador de políticas: repositorio de políticas distribuido

responsable de la definición y la implementación de configura-
ciones basadas en políticas.
Administrador de topologías: mantiene actualizada la informa-

ción del inventario y la topología de Cisco ACI.
38 Redes definidas por software (SDN) para Dummies_____________
API ascendentes: métodos con los que las aplicaciones pueden

programar la red y solicitar servicios.
API descendentes: métodos utilizados para establecer la comu-

nicación entre el controlador de SDN y los switches, routers y
demás dispositivos de red que se controlen.
APIC: Controlador de infraestructura de política de aplicación; el

componente de controlador de Cisco ACI para la administración
y automatización de políticas desde un solo punto.
ARP: protocolo de resolución de direcciones.
ASA: Dispositivo de seguridad adaptable de Cisco.
ASIC: circuitos integrados específicos de la aplicación.
AVS: switch virtual de Cisco centrado en aplicaciones; compo-

nente de la arquitectura de ACI; un switch de software que reside
en el hipervisor y conecta cargas de trabajo virtuales a la red.
BCB: puente principal de red troncal.
BEB: puente perimetral de red troncal.
BGP: protocolo de gateway fronterizo.
BYOD: traiga su propio dispositivo.
CLI: interfaz de línea de comandos.
CMIP: protocolo de información de administración común.
CONGA: equilibrio de carga sensible a la congestión.
Contexto: representación de un espacio de nombres privado de

Capa 3 o de una red de Capa 3.
Contrato: política de ACI entre dos EPG, en la que se especifican

los servicios entre ellos.
DCI: solución Cisco Data Center Interconnect, para la conexión

en red entre sitios del centro de datos.
�� Apéndice: Acrónimos de SDN 39
Declarativo (modelo): modelo de organización en el cual el con-
trol se distribuye y aplica mediante dispositivos inteligentes
basados en políticas centralizadas, y no en un controlador cen-
tral que envía comandos de control específicos.
DevOps: desarrollo y operaciones; un nuevo modelo que com-

bina el desarrollo y la implementación de aplicaciones e incluye
ambas organizaciones.
Dispositivos concretos: dispositivos existentes conectados a la

estructura de red.
Dispositivos lógicos: abstracción de clústeres de pares de dispo-

sitivos activos y en espera, como firewalls y equilibradores de
carga.
Dominio de puente: contenedor de subredes.
DVS: switch virtual distribuido de VMware.
EID: identificadores de terminales.
EPG: grupos de terminales; clases de cargas de trabajo, como el

nivel web de una aplicación, que comparten el mismo conjunto
de políticas.
EVPN: red privada virtual Ethernet.
FEX: extensor de estructura.
Fragmentación: método de partición de bases de datos que

aumenta la redundancia y el rendimiento.
GBP: política basada en grupos; un modelo de políticas estándar

basado en grupos de terminales orientados a la aplicación.
Gráfico de servicio: variación del concepto de un contrato, que

especifica cómo se conectan e implementan servicios en una
red.
GUI: interfaz gráfica de usuario.

Imperativo (modelo): estilo descendente de administración de

dispositivos, en el que el controlador o administrador central
debe estar al tanto de los comandos de configuración de los
objetos subyacentes y de su estado actual de manera que el con-
trolador pueda ejecutar todos los comandos de control de la
SDN.
Inserción de servicios: capacidad para agregar dispositivos de

capa 4 a 7 en la trayectoria entre terminales mediante la especifi-
cación y el control del trayecto de routing hacia esos nodos de
servicio.
IS-IS: sistema intermedio a sistema intermedio; protocolo de rou-

ting de Capa 3 común.
ITR: routers de túnel de entrada.
JSON: notación de objetos JavaScript.
KVM: máquina virtual basada en el kernel de Linux; el hipervisor

estándar para las aplicaciones basadas en Linux.
LISP: protocolo de separación de ubicación/identificador.
LLDP: protocolo de detección de capa de enlace.
MDT: árbol de distribución de multidifusión.
MPLS: switching por etiquetas multiprotocolo.
MSS: tamaño de segmento máximo.
MST: árbol de expansión múltiple.
MTU: unidad máxima de transmisión.
Multitenencia: partición de la red en topologías de red lógicas

que se asignan a abonados independientes en un entorno de
nube.
NFS: sistema de archivos de red.
NMS: sistema de administración de redes.

NSH: encabezado de servicios de red; protocolo de encadena-
miento de servicio abierto.
NVGRE: virtualización de red mediante encapsulado de routing

genérico; protocolo de túnel o superposición alternativo a
VXLAN, por lo general en centros de datos habilitados para
Microsoft.
Observador: subsistema de monitoreo de Cisco APIC que sirve

como repositorio de datos del estado operativo, la condición y el
rendimiento de Cisco ACI.
ONF: Open Networking Forum; grupo de estándares del sector

de varias tecnologías de SDN.
OpenFlow: uno de los primeros protocolos clave de SDN, que

especifica cómo deben comunicarse los controladores y swit-
ches de SDN.
OpenStack: plataforma de organización en la nube de código

abierto.
OpFlex: API descendente de Cisco que controla la comunicación

desde el controlador de SDN/ACI hasta los dispositivos
individuales.
OTV: virtualización de transporte superpuesto Cisco.
OVS: Open vSwitch.
OVSDB: base de datos de Open vSwitch.
PBB: puente de red troncal de proveedor.
PE: elementos de políticas.
Plano de control: canal que usan los nodos de la estructura de

SDN para los comandos de administración y para distribuir polí-
ticas para la comunicación entre los nodos (aparte de los datos
subyacentes).
Plano de datos: sección de una estructura de SDN que contiene

la información en sí que circula entre los nodos de una red.
pNIC: tarjeta de interfaz de red física.

Python: lenguaje de programación de scripts, que suele usarse

para programar aplicaciones y controladores de SDN.
QoS: calidad de servicio.
RBridges: puentes de routing.
Registro de terminales (ER): registro de terminales conocidos

actualmente para Cisco ACI y el controlador de APIC.
Repositorio de políticas: recopilación de políticas y reglas que

se aplican a terminales existentes o hipotéticos.
RESTful: transferencia de estado representacional, que hace refe-

rencia habitualmente a un tipo de interfaz de programación de
aplicaciones (API) ascendente que es común a aplicaciones web
y SDN.
RLOC: localizadores de routing.
RPC: llamada de procedimiento remoto.
RSTP: protocolo de árbol de expansión rápida.
SCVMM: Microsoft System Center Virtual Machine Manager.
SDK: kit de desarrollo de software.
SNMP: protocolo simple de administración de redes.
SPB: puentes por la ruta más corta.
SSL: capa de sockets seguros.
Superposiciones: redes virtuales de nodos interconectados que

comparten una red física subyacente. Permiten implementar
aplicaciones que requieren topologías específicas sin la necesi-
dad de modificar la red.
Teoría de la promesa: sistema de administración de dispositivos

que depende de dispositivos subyacentes, como switches de
red, para administrar los cambios de estado e informar las
excepciones o fallas (equivalente al modelo declarativo).
Tráfico entre nodos: tráfico de red que se transmite entre los
componentes de la aplicación, generalmente dentro de la red de
aplicaciones de un abonado, y circula dentro del centro de datos.
VLAN: red de área local virtual.
VM: máquina virtual.
VNI: identificador de red VXLAN.
vNIC: tarjeta de interfaz de red virtual.
VNID: identificador de red virtual.
VRF: routing y reenvío virtuales.
VTEP: terminal de túnel de VXLAN.
VXLAN: LAN virtual extensible; protocolo de superposición o

túnel para crear particiones de red o redes de abonados.
WAN: red de área amplia.
XML: lenguaje de marcado extensible.


Dummies Book Esla PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dummies Book Esla PDF

Cargado por

Copyright:

Formatos disponibles

Redes definidas

Edición especial de Cisco

por Brian Underdahl

LÍMITE DE RESPONSABILIDAD/EXCLUSIÓN DE GARANTÍAS: LA EDITORIAL Y EL AUTOR NO HACEN

Editor del proyecto: Jennifer Bingham Representante de desarrollo comercial:

Capítulo 1: Introducción a las redes definidas

Capítulo 2: Analizar los beneficios y casos de uso

Capítulo 3: Comprender la tecnología. . . . . . . . . . . . . . . . . . . 15

Capítulo 4: Consideraciones y requisitos clave de SDN. . 23

Capítulo 5: Diez datos importantes sobre la

Acerca de este libro

Íconos utilizados en este libro

Este ícono marca los puntos donde se analizan cuestiones técnicas,

Más allá del libro

Introducción a las redes

L as redes se han convertido en un elemento absolutamente

Conceptos básicos sobre las SDN

¿Dónde estábamos antes de las SDN?

✓✓Políticas incoherentes: las políticas de seguridad y calidad

¿Adónde nos llevan las SDN?

Analizar por qué hay tanto entusiasmo

Las SDN facilitan la virtualización

Las SDN giran principalmente en torno

Figura 1-1: Cómo puede ayudar ACI.

Analizar los beneficios y

L as corporaciones por lo general no siguen las tendencias solo

La automatización de las SDN

exponencial. Por ejemplo, el centro de datos habilitado para Cisco

Un nuevo enfoque para las políticas de la red

A qué se refiere Cisco con las políticas

✓✓ Modelo de políticas extensible: como el modelo de políticas

Administración de políticas centralizada

A qué se refiere Cisco

que intervenga con cada dispositivo, este nuevo enfoque propor-

Algunos casos de uso populares

✓✓ Aplicaciones de movilidad e Internet de las cosas (IdC): la

Llegar más allá de la red

En este capítulo, se analizan datos importantes que debe saber

Comprender los controladores de SDN

Un controlador de SDN es un repositorio centralizado de políticas e

implementar las políticas deseadas, por lo general, programa el con-

El controlador acorta la brecha entre los elementos de red abiertos

El controlador le proporciona una interfaz programática (a veces

Para reducir la carga de administración de la red, el controlador con-

✓✓Uniformidad en la red empresarial, para minimizar el tiempo

En Cisco ACI, el controlador de APIC administra una política cen-

Figura 3-1: APIC proporciona un controlador

de SDN común para los equipos

Comprender las políticas

El concepto central de ACI es el del perfil de red de aplicaciones

cargas de trabajo, la seguridad y las políticas de servicio.

Para implementar políticas, Cisco utiliza una arquitectura abierta

OpFlex es el nombre del protocolo de comunicación entre el contro-

Cisco ACI y OpFlex implementan lo que se denomina un modelo de

Este diseño declarativo tiene sentido si tenemos en cuenta que las

OpFlex utiliza declaraciones de políticas de alto nivel y orientadas a

OpFlex es un protocolo de comunicación bidireccional. Además de

Evaluación de las redes

Las redes superpuestas virtuales son redes virtuales separadas lógi-

Las redes superpuestas ofrecen distintos beneficios que ayudan a

✓✓Escalabilidad y flexibilidad de la estructura: las tecnologías

VXLAN (red de área local virtual extensible) es un protocolo de

VXLAN y NVGRE son dos ejemplos de redes complementarias que

Figura 3-1: APIC proporciona un controlador