Computing">
CCN-STIC-666 Cisco ACI
CCN-STIC-666 Cisco ACI
CCN-STIC-666 Cisco ACI
CCN-STIC-666
SEPTIEMBRE 2020
CCN-STIC-666 Infraestructura centralizada en aplicaciones (CISCO ACI) v1.0
LIMITACIÓN DE RESPONSABILIDAD
El presente documento se proporciona de acuerdo con los términos en él recogidos, rechazando expresamente
cualquier tipo de garantía implícita que se pueda encontrar relacionada. En ningún caso, el Centro Criptológico
Nacional puede ser considerado responsable del daño directo, indirecto, fortuito o extraordinario derivado de la
utilización de la información y software que se indican incluso cuando se advierta de tal posibilidad.
AVISO LEGAL
Quedan rigurosamente prohibidas, sin la autorización escrita del Centro Criptológico Nacional, bajo las sanciones
establecidas en las leyes, la reproducción parcial o total de este documento por cualquier medio o
procedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de ejemplares del
mismo mediante alquiler o préstamo públicos.
PRÓLOGO
En un mundo cada vez más complejo y globalizado, en el que las tecnologías de la información
y la comunicación (TIC) desempeñan un papel de suma importancia, hemos de ser conscientes de que
la gestión adecuada de la ciberseguridad constituye un reto colectivo al que necesariamente hemos
de enfrentar. Resulta necesario garantizar la protección de la capacidad económica, tecnológica y
política de nuestro país, máxime cuando la proliferación de ataques dirigidos y el robo de información
sensible representan una realidad incontestable.
Por ello, resulta imprescindible estar al día de las amenazas y vulnerabilidades asociadas al uso
de las nuevas tecnologías. El conocimiento de los riesgos que se ciernen sobre el ciberespacio ha de
servir para implementar con garantías las medidas, tanto procedimentales como técnicas y
organizativas, que permitan un entorno seguro y confiable.
La Ley 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia (CNI), encomienda
al Centro Nacional de Inteligencia el ejercicio de las funciones relativas a la seguridad de las tecnologías
de la información y de protección de la información clasificada, a la vez que confiere a su Secretario de
Estado Director la responsabilidad de dirigir el Centro Criptológico Nacional (CCN).
Partiendo del conocimiento y la experiencia del CNI sobre amenazas y vulnerabilidades en
materia de riesgos emergentes, el Centro realiza, a través del Centro Criptológico Nacional, regulado
por el Real Decreto 421/2004, de 12 de marzo, diversas actividades directamente relacionadas con la
seguridad de las TIC, orientadas a la formación de personal experto, al empleo de tecnologías de
seguridad adecuadas y a la aplicación de políticas y procedimientos de seguridad.
Precisamente, esta serie de documentos CCN-STIC es un claro reflejo de la labor que este
organismo lleva a cabo en materia de implementación de seguridad, permitiendo la aplicación de
políticas y procedimientos, pues las guías han sido elaboradas con un claro objetivo: mejorar el grado
de ciberseguridad de las organizaciones, conscientes de la importancia que tiene el establecimiento
de un marco de referencia en esta materia que sirva de apoyo para que el personal de la
Administración lleve a cabo la difícil tarea de proporcionar seguridad a los sistemas de las TIC
bajo su responsabilidad.
Con esta serie de documentos, el Centro Criptológico Nacional, en cumplimiento de sus
cometidos y de lo reflejado en el Real Decreto 3/2010 por el que se regula el Esquema Nacional en el
ámbito de la Administración electrónica, contribuye a mejorar la ciberseguridad española y mantener
las infraestructuras y los sistemas de información de todas las administraciones públicas con unos
niveles óptimos de seguridad. Todo ello, con el fin de generar confianza y garantías en el uso de estas
tecnologías, protegiendo la confidencialidad de los datos y garantizando su autenticidad,
integridad y disponibilidad.
septiembre de 2020
ÍNDICE
2. INTRODUCCIÓN
El actual uso de tecnologías emergentes que permiten la virtualización de los sistemas de las
Tecnologías de la Información y la Comunicación (TIC), en adelante Sistemas, se ha hecho crítica
con la extensión del empleo de dichas tecnologías a todos los ámbitos.
Las amenazas asociadas a un sistema, que pueden afectar a la confidencialidad, integridad y
disponibilidad de la información manejada, o a la propia integridad y disponibilidad del sistema,
son tenidas en cuenta a la hora de establecer los requisitos de seguridad mínimos, de tal manera,
que las medidas de protección que se implementan tienen por objeto hacer frente a dichas
amenazas reduciendo la superficie de exposición y minimizando el impacto de las mismas.
La seguridad se tratará desde la fase de diseño del sistema, donde se definirán las
salvaguardas a implementar, permitiendo de esta manera que el análisis y gestión de riesgos de
seguridad estén presentes en el proceso de desarrollo del sistema.
La Política STIC determina que todos los sistemas que requieran manejar información
clasificada deberán ser previamente acreditados, de acuerdo con el procedimiento que, para tal
fin, apruebe la Autoridad de Acreditación de Seguridad (AAS).
El procedimiento de acreditación de seguridad, entre otros requisitos, confirmará que las
medidas de seguridad que satisfacen los requisitos STIC se encuentran implementadas en los
Sistemas antes de manejar información clasificada.
3. OBJETO
El objeto de esta instrucción técnica es establecer los requisitos STIC mínimos, que deben
realizarse en los sistemas CIS que contemplen la implementación de una infraestructura
centralizada en aplicaciones de Cisco (ACI), cuando manejen información clasificada.
El presente informe proporciona los detalles específicos de aplicación e implementación de
las recomendaciones de seguridad y buenas prácticas necesarias para la prevención de los
riesgos, amenazas, y vulnerabilidades de seguridad a las que están expuestas las arquitecturas
virtuales sobre las que se implementa un sistema que va a manejar información clasificada.
Por su parte, a los sistemas del Sector Público que no traten información clasificada les será
de aplicación el Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Seguridad (ENS), de conformidad con lo dispuesto en la Ley 40/2015, de Régimen Jurídico del
Sector Público y atendiendo a lo señalado en la Ley 39/2019, de Procedimiento Administrativo
Común de las Administraciones Públicas, ambas de 1 de octubre.
4. ALCANCE
El propósito del presente documento es realizar un análisis general de los mecanismos y la
configuración de seguridad destinada a proporcionar una serie de recomendaciones de seguridad
para la protección de los datos, comunicaciones e información que almacenan los sistemas con
implementaciones Cisco ACI.
En los Sistemas que manejen información clasificada, se determinarán las autoridades y
responsables relacionados con la seguridad de los mismos a lo largo de su ciclo de vida
(determinación de la necesidad, diseño, desarrollo, implantación, operación, mantenimiento
y retirada).
Dichas autoridades tendrán en cuenta los requisitos STIC a implementar en las diferentes fases
del ciclo de vida debiendo constar y estar presentes en la documentación de seguridad
asociada al Sistema.
La Autoridad de Acreditación de Seguridad podrá determinar la aplicación de esta instrucción
técnica a cualquier otro tipo de Sistema bajo su responsabilidad.
La guía ha sido desarrollada con el objetivo de dotar a la aplicación Cisco ACI, con la seguridad
adecuada, dependiendo del entorno sobre el que se aplique, teniendo en consideración el
ámbito y nivel de seguridad de la información a tratar. Es posible que algunas de las
funcionalidades esperadas hayan sido desactivadas, y por lo tanto, pueda ser necesario aplicar
acciones adicionales para habilitar servicios, roles o características deseadas.
El espíritu de estas guías no está dirigido a remplazar políticas de seguridad consolidadas y
probadas de las organizaciones, sino a servir como línea base de seguridad.
Esta línea deberá ser adaptada a las necesidades propias de cada organización, pero sin
desviarse de la seguridad mínima necesaria para el manejo de información clasificada.
ARQUITECTURAS SDN
Aunque están en una continua evolución y cambio, las principales arquitecturas de SDN se
pueden dividir en:
a) Switch-based SDN (SDN basado en Switches): La idea del SDN se basó originalmente en el
modelo basado en Switches, que procesan paquetes con un sistema como OpenFlow, que
dicta el comportamiento de los nodos de la red. Esto proporciona un punto de control
central que gestiona cómo los nodos manejan el tráfico de la red (pueden ser virtuales o
físicos, siempre que sean compatibles con OpenFlow).
b) SDN overlay (Superposición de SDN): El modelo de superposición de SDN crea túneles
virtuales a través de la red física para ejecutar múltiples topologías de red virtual (VN) sobre
una infraestructura existente. Esto permite que una VN sea una red de capa 2 o capa 3, y
que una red física sea de capa 2 o capa 3, según el tipo de superposición.
c) Hybrid SDN (SDN híbrido): Un modelo hibrido de SDN combina protocolos tradicionales de
las redes Legacy y SDN. Un administrador de red, por ejemplo, puede configurar el plano
de control de la SDN para gestionar flujos de tráfico específicos, mientras que los
protocolos de red tradicionales gestionan los demás flujos de tráfico de la red. La SDN
híbrida utiliza diversos tipos de redes, como VPN, Ethernet, MPLS, entre otras, para
conectar múltiples lugares y trabajadores. El enfoque de la SDN híbrida proporciona
flexibilidad al utilizar las tecnologías más recientes de SDN para satisfacer las demandas de
cada lugar.
Cuando un flujo llega a un nodo de la red (switch) se realiza un mapeo de la tabla de flujos y
en caso de no existir una entrada se realiza una consulta al controlador para recibir información.
Se detallan los tres modos:
En el modo reactivo, el controlador actúa después de recibir estas peticiones y se ajustan
constantemente creando una regla en la tabla de flujos para el paquete correspondiente, ya que
los cambios se hacen inmediatamente como reacción a las condiciones actuales de la red
(generalmente se asocia con SDN y OpenFlow). Este es el modelo básico de gestión de la
volatilidad en el que hay una alta tasa de cambio en la ubicación de los puntos finales
(normalmente máquinas virtuales) y OpenFlow se utiliza para actualizar continuamente la
ubicación y el camino a través de la red hasta cada punto final.
En el modo proactivo anticipan los problemas de la red e intentan abordarlos antes de que se
conviertan en un problema real (lo que requeriría una reacción). El modo proactivo crea una tabla
de flujos para cada posible coincidencia de tráfico en ese nodo de la red (Switch) dando así
solución a conocer el camino que deberá tomar el tráfico de datos.
El modo predictivo es el modelo híbrido que combina el modo reactivo y proactivo
beneficiando en las ventajas de ambos, que utiliza datos históricos sobre el rendimiento de la red
para ajustar las rutas y los flujos periódicamente. Este enfoque es menos perturbador, ya que se
produce con menos frecuencia, pero aun así, permite que las tendencias en el flujo y el volumen
de datos informen las rutas apropiadas.
A continuación, se exponen de forma resumida, algunas de las principales ventajas que puede
aportar una solución SDN
a) Agilidad y flexibilidad. SDN permite a los administradores de red desplegar servicios,
aplicaciones e infraestructuras de forma rápida permitiendo así alcanzar los objetivos
marcados en el menor tiempo posible.
b) Permite innovación. Los entornos SDN permiten crear nuevos tipos de aplicaciones y
modelos de negocio por parte de las empresas.
c) Reduce el gasto operacional. La tecnología SDN permite el control de elementos de red
mediante el uso de programas, como switches/routers. En consecuencia, permite una
reducción del tiempo de gestión por parte de los administradores y reduce
considerablemente la probabilidad de un error humano.
d) Reduce el gasto en hardware. Los entornos SDN permiten reutilizar el hardware existente,
alargando así su vida útil. Además, permite a los administradores de redes disponer de
hardware de diferentes fabricantes siempre que sea posible la integración de dicho
fabricante con la tecnología SDN.
Dado que se centraliza la administración de la red, el controlador, se convierte en el centro de
control y de toma de decisión de la red, por lo tanto, hay que protegerlo y asegurarlo, ya que un
problema en el controlador afectará a toda la red.
Los principales riesgos del controlador en un entorno SDN son:
a) Escalabilidad: Un aumento repentino, o no programado de trabajo puede provocar que el
controlador se transforme en un “cuello de botella” o incluso llegar a “saturarse”, y de esta
manera afectar a toda la red.
b) Seguridad: los ataques al controlador podrían afectar al funcionamiento de toda la red.
Para su protección se pueden utilizar las herramientas de seguridad que se aplican en las
redes convencionales y también mecanismos de seguridad específicos para SDN.
La seguridad Cisco ACI permite una administración unificada del ciclo de vida de la política de
seguridad con capacidad para hacer cumplir las políticas en cualquier lugar del centro de datos a
través de cargas de trabajo físicas y virtuales. Ofrece automatización completa de las políticas de
seguridad de la capa 4 a la 7 y admite una estrategia de defensa profunda con un amplio soporte
de ecosistema a la vez que posibilita alta visibilidad, cumplimiento automatizado de políticas y
detección y mitigación aceleradas de las amenazas.
f) Marco de seguridad abierto: Cisco ACI ofrece un marco de seguridad abierto (que incluye
API y el protocolo de OpFlex) para admitir la incorporación de servicios avanzados para los
servicios críticos de seguridad de capas 4 a 7, como sistemas de detección de intrusiones
(IDS) y sistemas de prevención de intrusiones (IPS), además de servicios de firewall de
próxima generación en el flujo de la aplicación, independientemente de su ubicación en el
centro de datos. Esta función permite una estrategia de seguridad de defensa profunda y
la protección de las inversiones.
g) Alta visibilidad y detección acelerada de ataques: Cisco ACI reúne datos de tráfico de red
con marca de tiempo y admite contadores atómicos para ofrecer inteligencia de red en
tiempo real y alta visibilidad a través de los límites de red física y virtual. Gracias a esta
función, se permite una detección de manera acelerada y temprana de los ataques.
h) Respuesta automatizada ante incidentes: Cisco ACI admite la respuesta automatizada ante
amenazas identificadas en la red ya que permite la integración con las plataformas de
seguridad mediante las API ascendentes.
COMPORTAMIENTOS CONOCIDOS
ID DESCRIPCIÓN VERSIONADO
CDP no está habilitado en las interfaces de administración 4.0 (3c) y
CSCuu17314
para los switches leaf y los switches spine. posterior
Las estadísticas para una regla de cambio de hoja dada no 4.0 (3c) y
CSCvd43548
se pueden ver si se hace doble clic en una regla. posterior
No se puede llegar a un servicio utilizando la administración 4.0 (3c) y
CSCve84297 fuera de banda APIC que existe dentro de la subred posterior
172.17.0.0/16.
Se anunciará una ruta, pero no contendrá el valor de 4.0 (3c) y
CSCvf70411
etiqueta establecido en la política de etiqueta de ruta VRF. posterior
Al configurar un L3Out bajo un “tenant” de usuario que está 4.0 (3c) y
asociado con una instancia de VRF que está bajo el “tenant” posterior
CSCvg70246 común, una política de temporizador BGP personalizada
que se adjunta a la instancia de VRF no se aplica al L3Out
(par BGP) en el “tenant” del usuario.
Habilitar la multidifusión bajo el VRF en uno o más dominios 4.0 (3c) y
puente es difícil debido a cómo está diseñado el menú posterior
CSCvh59843
desplegable. Esta es una solicitud de mejora para hacer que
se pueda buscar en el menú desplegable.
ID DESCRIPCIÓN VERSIONADO
Los archivos de registro APIC son extremadamente grandes, 4.0 (3c) y
CSCvi41092 lo que lleva una cantidad considerable de tiempo para posterior
cargar, especialmente para usuarios w
Esta es una mejora que permite ordenar la conmutación por 4.0 (3c) y
error, categorizar enlaces ascendentes como activos o en posterior
CSCvi80543
espera, y categorizar enlaces ascendentes no utilizados para
cada EPG en dominios VMware del APIC.
Cuando se autentica con Cisco APIC usando ISE (TACACS), 4.0 (3c) y
CSCvi82903
todos los inicios de sesión de más de 31 caracteres fallan. posterior
El proceso de Virtual Machine Manager (vmmmgr) se 4.0 (3c) y
CSCvj89771
bloquea y genera un archivo central. posterior
4.0 (3c) y
CSCvj91789 Cisco APIC M5 usa solo 2 de 4 puertos en una nueva NIC.
posterior
No hay registro de quién reconoció una falla en Cisco APIC, 4.0 (3c) y
CSCvk04072
ni cuándo ocurrió el reconocimiento. posterior
Un solo usuario puede enviar consultas para sobrecargar la 4.0 (3c) y
CSCvm63668
puerta de enlace API. posterior
Se pueden observar problemas con dominios puente, 4.0 (3c) y
CSCvm88517 subredes y programación de instancias VRF en la ruta de posterior
datos.
El proceso svc_ifc_policye consume el 100% de los ciclos de 4.0 (3c) y
la CPU. Los siguientes mensajes se observan en posterior
svc_ifc_policymgr.bin.log:
8816||18-10-12
CSCvm89559
11:04:19.101||route_control||ERROR||co=doer:255:127:0
xff00000000c42ad2:11||Route entry order exceeded max
for st10960-2424833-any-2293761-33141-shared-svc-int
Order:18846Max:17801||
Un CSA SHA2 para el certificado HTTPS ACI no se puede 4.0 (3c) y
CSCvn00576
configurar en la GUI APIC. posterior
Al actualizar desde algunas versiones 3.2 o 3.1 a 4.0, 4.0 (3c) y
algunos o todos los grupos de mantenimiento del “leaf posterior
CSCvn79128 switch” comenzarán a actualizarse inmediatamente sin ser
activados por el usuario. Este problema ocurre tan pronto
como los APIC terminan de actualizarse.
Es posible que las pantallas de exploración de utilización de 4.0 (3c) y
CSCvo04679 recursos y medio ambiente no muestren datos para ciertos posterior
nodos después de desmantelar un APIC de Cisco.
Después de actualizar los APIC de una versión anterior a la 4.0 (3c) y
4.0 a 4.0 o posterior, los modificadores de hoja no se posterior
CSCvp25660
actualizarán, o los modificadores se actualizarán y luego
volverán automáticamente a la versión anterior.
ID DESCRIPCIÓN VERSIONADO
Algunos “tenants” dejan de recibir actualizaciones de su 4.0 (3c) y
estado en el APIC. Los registros de ayuda al objetivo tienen posterior
CSCvp38627 mensajes similares al siguiente ejemplo:
“An unexpected error has occurred while reconciling tenant
tn-prj_...: long int too large to convert to float”
Después de que un VC se desconectó y se volvió a conectar 4.0 (3c) y
al APIC, se eliminaron los fallos operativos (por ejemplo, la posterior
CSCvp57131
falta de coincidencia de descubrimiento entre APIC y VC),
incluso si todavía existía la condición defectuosa.
Syslog no se envía con ningún cambio en la estructura. Los 4.0 (3c) y
CSCvp79454 eventos se generan correctamente, pero no se envía Syslog posterior
desde los puertos oobmgmt de ninguno de los APIC.
El APIC Licensemgr genera un archivo central mientras 4.0 (3c) y
CSCvp94085
analiza una respuesta XML. posterior
Los encabezados de control de acceso no están presentes 4.0 (3c) y
CSCvp95407
en las solicitudes no válidas. posterior
Los tenants que comienzan con la palabra "infra" son 4.0 (3c) y
CSCvp97092
tratados como el tenant "infra" predeterminado. posterior
El asistente de solución de problemas no responde en el 4.0 (3c) y
CSCvp99430
APIC. posterior
La GUI es lenta cuando se accede a las políticas de acceso. 4.0 (3c) y
CSCvp99508 Esta es una solicitud de mejora para agregar paginación posterior
para resolver este problema.
La API y la CLI de APIC permiten la configuración de varias 4.0 (3c) y
VLAN nativas en la misma interfaz. Cuando un puerto de posterior
switch leaf tiene más de una VLAN nativa configurada (que
es una configuración incorrecta) en su lugar, y un usuario
CSCvq04110 intenta configurar un encap de VLAN nativa en otro puerto
en el mismo switch leaf, se genera un error de validación
que indica un problema con el puerto mal configurado. Este
error ocurrirá incluso si el puerto de destino actual no tiene
configuraciones incorrectas en su lugar.
El agente de Hyper-V está en estado DETENIDO. Los 4.0 (3c) y
registros del agente de Hyper-V indican que el proceso se posterior
CSCvq14177
está deteniendo en el comando "Set-ExecutionPolicy
Unrestricted".
"show external-l3 interfaces node <id> detail" mostrará 4.0 (3c) y
CSCvq31358 "missing" tanto para "Oper Interface" como para "Oper IP", posterior
a pesar de que L3Out funciona como se esperaba.
Cuando hace clic en Reiniciar para el agente del 4.0 (3c) y
Administrador de máquina virtual (SCVMM) de Microsoft posterior
CSCvq39764 System Center en una configuración escalada, el servicio
puede detenerse. Puede reiniciar el agente haciendo clic en
Inicio.
ID DESCRIPCIÓN VERSIONADO
Las combinaciones específicas del sistema operativo y la 4.0 (3c) y
versión del navegador no se pueden utilizar para iniciar posterior
sesión en la GUI APIC.
CSCvq39922
Algunos navegadores que se sabe que tienen este problema
incluyen (pero no se limitan a) Google Chrome versión
75.0.3770.90 y Apple Safari versión 12.0.3 (13606.4.5.3.1).
Al abrir una subred externa, un usuario no puede ver las 4.0 (3c) y
CSCvq43101 casillas de verificación Exportar / Importar agregadas posterior
establecidas en la GUI aunque ya estén configuradas.
El error F3206 para "Error en la configuración de la política 4.0 (3c) y
uni / infra / nodeauthpol-default, debido a un error de EPg posterior
o errorVlan está vacío" aparece en la estructura cuando se
CSCvq45710 usa la política de autenticación de nodo 802.1x
predeterminada en el Grupo de políticas de switch. En este
escenario, la EPG y la VLAN Fail-auth no se han configurado,
ya que la característica 802.1x no está en uso.
Los fallos relacionados con el inventario de VMM se 4.0 (3c) y
CSCvq58304 generan para el inventario de VMware vCenter, que VMM posterior
no administra.
El proceso SNMP se bloquea repetidamente en los APIC. El 4.0 (3c) y
CSCvq61877 clúster y los fragmentos se ven en buen estado y no tienen posterior
problemas de uso de CPU o memoria.
Cuando se usa Open vSwitch, que se usa como parte de la 4.0 (3c) y
integración de ACI con Kubernetes o Red Hat Open Shift, posterior
CSCvq63491
hay algunos casos en que el consumo de memoria de Open
vSwitch crece con el tiempo.
Al realizar un cambio de configuración a un L3Out (como la 4.0 (3c) y
eliminación o adición de un contrato), las aletas pares BGP posterior
o el objeto bgpPeerP se eliminan del Switch leaf. En los
CSCvq74727
rastreos de elementos de política de cambio de hoja,
'isClassic = 0, wasClassic = 1' se establece después de la
actualización desde el APIC de Cisco.
Bajo un caso de esquina, la base de datos del clúster APIC 4.0 (3c) y
de Cisco puede divergir parcialmente después de actualizar posterior
a una versión que introduce nuevos servicios. Una nueva
versión que introduce un nuevo servicio DME (como el
domainmgr en la versión 2.3) podría no recibir la
CSCvq86573 actualización del vector de fragmentos de tamaño completo
en la primera ventana de dos minutos, lo que hace que el
nuevo archivo de bandera de servicio se elimine antes de
que todo el líder local los fragmentos pueden iniciarse en el
modo de campo verde. Esto da como resultado que la base
de datos del clúster APIC de Cisco se desvíe parcialmente.
ID DESCRIPCIÓN VERSIONADO
Los objetos vmmPLInf se crean con epgKey y DN que tienen 4.0 (3c) y
CSCvr30815
nombres EPG truncados (truncados en "."). posterior
La opción descendente no funcionará para la tabla Puertos 4.0 (3c) y
CSCvr36851 estáticos. Incluso cuando el usuario hace clic en posterior
descendente, el orden predeterminado es ascendente.
Las políticas pueden tardar mucho tiempo (más de 10 4.0 (3c) y
minutos) en programarse en los switches leaf. Además, el posterior
CSCvr41750
APIC extrae inventario de VMware vCenter repetidamente,
en lugar de seguir el intervalo habitual de 24 horas.
Al intentar rastrear una dirección IP de punto final AVE, 4.0 (3c) y
ejecutar el comando "show “endpoint” ip xxxx" en la CLI de posterior
CSCvr85515 Cisco APIC para ver la dirección IP y verificar la dirección IP
en el punto final EP en la GUI muestra nombres de VPC
incorrectos o múltiples.
El alcance de las rutas de host debe ser configurable; sin 4.0 (3c) y
CSCvr92169 embargo, la opción para definir el alcance no está posterior
disponible.
Al migrar un dominio AVS VMM a Cisco ACI Virtual Edge, el 4.0 (3c) y
Cisco ACI Virtual Edge que se implementa se configura en posterior
modo VLAN en lugar de modo VXLAN. Debido a esto, se
CSCvr98638 pueden observar fallos para las EPG con el siguiente
mensaje de error:
"No hay un identificador de encapsulación válido asignado
para el epg".
Se genera un error al crear una imagen de contenedor ACI 4.0 (3c) y
CSCvs10076 debido a un conflicto con el paquete /opt/ciscoaci-tripleo- posterior
heat-templates/tools/build_openstack_aci_containers.py.
No se puede cambiar el nombre de un grupo de puertos. 4.0 (3c) y
CSCvm32345 Esta es una solicitud de mejora para habilitar el cambio de posterior
nombre de los grupos de puertos.
Después de cambiar la asociación de la instancia VRF de un 4.0 (3c) y
dominio de puente de servicios compartidos, una ruta de posterior
CSCvo42420
servicios compartidos todavía está presente en la antigua
instancia VRF.
Se genera un archivo core eventmgr cuando un usuario 4.0 (3c) y
CSCvq38191
ejecuta el comando de depuración syslog "logit". posterior
CSCuo52668 Cisco APIC no valida las direcciones IP duplicadas que se 4.0 (3c) y
asignan a dos grupos de dispositivos. La comunicación a los posterior
dispositivos o la configuración de los dispositivos de servicio
pueden verse afectados.
CSCuo79243 En algunos de los datos estadísticos de 5 minutos, el 4.0 (3c) y
recuento de muestras de diez segundos es 29 en lugar de posterior
30.
ID DESCRIPCIÓN VERSIONADO
CSCuo79250 La política de ID de nodo se puede replicar desde un 4.0 (3c) y
dispositivo antiguo que está fuera de servicio cuando se une posterior
a un clúster.
CSCup47703 El valor DSCP especificado en un grupo de punto final 4.0 (3c) y
externo no tiene efecto en las reglas de filtro en el “leaf posterior
switch”.
CSCup79002 La resolución del nombre de host del servidor syslog falla en 4.0 (3c) y
los switches leaf y spine sobre la conectividad en banda. posterior
CSCuq21360 Después de un FEX o una recarga del interruptor, las 4.0 (3c) y
etiquetas de interfaz configuradas ya no se configuran posterior
correctamente.
CSCur39124 Los switches se pueden degradar a una versión 1.0 (1) si la 4.0 (3c) y
configuración importada consiste en una política de posterior
firmware con una versión deseada establecida en 1.0 (1).
CSCur71082 Si el APIC de Cisco se reinicia usando el reinicio de energía 4.0 (3c) y
CIMC, el sistema entra en fsck debido a un disco dañado. posterior
CSCus15627 El servicio APIC de Cisco (ApicVMMService) se muestra 4.0 (3c) y
como detenido en el Administrador de servicios de posterior
Microsoft (services.msc en el panel de control>
herramientas de administración> servicios). Esto sucede
cuando una cuenta de dominio no tiene el privilegio
correcto en el dominio para reiniciar el servicio
automáticamente.
CSCut51929 El tráfico destinado a un grupo de puntos finales del 4.0 (3c) y
proveedor de servicios compartidos elige una ID de clase posterior
incorrecta (PcTag) y se descarta.
CSCuu09236 El tráfico de una red externa de Capa 3 se permite cuando 4.0 (3c) y
se configura como parte de un consumidor vzAny (una posterior
colección de grupos de puntos finales dentro de un
contexto).
CSCuu61998 Las configuraciones de EPG de microsegmento recién 4.0 (3c) y
agregadas deben eliminarse antes de pasar a una versión de posterior
software que no lo admite.
CSCuu64219 La degradación de la estructura que comienza con el switch 4.0 (3c) y
leaf provocará fallas como el fallo de implementación de posterior
política con el código de falla F1371.
CSCva32534 Crear o eliminar una política fabricSetupP da como 4.0 (3c) y
resultado un estado inconsistente. posterior
ID DESCRIPCIÓN VERSIONADO
CSCva60439 Después de que se crea un pod y se agregan nodos en el 4.0 (3c) y
pod, al eliminar el pod se obtienen entradas obsoletas del posterior
pod que están activas en la estructura. Esto ocurre porque
Cisco APIC utiliza DHCP de código abierto, lo que crea
algunos recursos que Cisco APIC no puede eliminar cuando
se elimina un pod.
CSCva86794 Cuando se está actualizando un clúster de Cisco APIC, el 4.0 (3c) y
clúster de Cisco APIC puede entrar en el estado minoritario posterior
si hay problemas de conectividad. En este caso, los inicios
de sesión de los usuarios pueden fallar hasta que la mayoría
de los APIC de Cisco finalicen la actualización y el clúster
salga de la minoría.
CSCva97082 Al bajar a una versión 2.0 (1), los “spines” y sus interfaces 4.0 (3c) y
deben moverse de infra L3out2 a infra L3out1. Después de posterior
que aparezca Infra L3out1, elimine L3out2 y su
configuración relacionada, y luego baje a una versión 2.0
(1).
CSCvb39702 No se genera ninguna falla al usar la misma VLAN de 4.0 (3c) y
encapsulación en un dispositivo de copia en tenant común, posterior
a pesar de que se debe generar una falla.
CSCvg41711 En el modo hoja, el comando "template route group 4.0 (3c) y
<group-name> tenant <tenant-name>" falla, declarando posterior
que el tenant pasado no es válido.
CSCvg79127 Cuando la seguridad del primer salto está habilitada en un 4.0 (3c) y
dominio de puente, el tráfico se interrumpe. posterior
CSCvg81856 Los pares BGP de Cisco ACI Multi-Site Orchestrator están 4.0 (3c) y
inactivos y se genera un error por un rtrId en conflicto en el posterior
objeto administrado fvRtdEpP durante la configuración de
L3extOut.
Es posible que los detalles de la PSU SPROM no se muestren 4.0 (3c) y
CSCvh76076 en la CLI tras la extracción e inserción del switch. posterior
Si se programan dos reglas de rechazo intra-EPG, una con la
prioridad class-eq-deny y otra con la prioridad class-eq-
4.0 (3c) y
filter, cambiar la acción de la segunda regla para "denegar"
posterior
hace que la segunda regla sea redundante y tenga sin
CSCvh93612 efecto. El tráfico todavía se niega, como se esperaba.
El comando "show run leaf | spine <nodeId>" puede 4.0 (3c) y
CSCvj26666 producir un error para configuraciones ampliadas. posterior
Las actualizaciones del switch fallan con el siguiente error: 4.0 (3c) y
CSCvm71833 Versión no compatible. posterior
COMPATIBILIDAD DE VIRTUALIZACIÓN
Nota: Todas las actualizaciones de VMware vSphere son compatibles a menos que se mencione
explícitamente. La alta disponibilidad (HA) con múltiples vRO no es compatible en todas las versiones.
Además, El complemento Cisco ACI CNI es compatible con las siguientes soluciones de contenedor:
- Kubernetes canónicos en Ubuntu 18.04
- Red Hat Openshift en RHEL 7
- Docker Enterprise en RHEL 7
e) Los comandos “show” ejecutados en la CLI de estilo NX-OS está sujeta a cambios en futuras
versiones de software. No se recomienda la utilización de los comandos “show” para la
automatización.
f) La CLI solo es compatible con usuarios con privilegios de inicio de sesión administrativo.
g) Si FIPS está habilitado en las configuraciones de Cisco ACI, entonces el soporte SHA256 es
obligatorio en el Cliente SSH. Además, para tener compatibilidad con SHA256, el cliente
OpenSSH debe ejecutar la versión 6.6.1 o superior.
6.5.3.4 DIRECCIONES IP
Para el uso relacionado con las direcciones IP, se enumeran a continuación las principales
pautas a seguir para el software Cisco APIC:
a) Para los siguientes servicios, se deberá usar un nombre de host basado en DNS con
conectividad de administración fuera de banda. Las direcciones IP se pueden usar con
conectividad de administración dentro y fuera de banda.
i. Servidor Syslog
ii. Llame al servidor SMTP de inicio
iii. Servidor de exportación de soporte técnico
iv. Servidor de exportación de configuración
v. Servidor de exportación de estadísticas
b) El rango de la dirección IP de la infraestructura no debe solaparse con otras direcciones IP
utilizadas en la estructura para redes dentro y fuera de banda.
c) Si se configura una dirección IP en uno de los dos “endpoint’s” para los que está
configurando una política, debe usar una política basada en IP y no una política basada en
“endpoint”.
d) Una implementación “multi-pod” requiere que el sistema Global IP Outside (GIPo) se
encuentre configurado con la ip 239.255.255.240 en la red pod (IPN) como un rango PIM
BIDIR. Esta configuración de rango 239.255.255.240 PIM BIDIR en los dispositivos IPN se
puede evitar mediante el uso de Infra GIPo como característica del sistema GIPo. La función
Infra GIPo como sistema GIPo debe habilitarse solo después de actualizar todos los
switches en la estructura Cisco ACI, incluidos los “leaf switches” y los “spine switches” a la
última versión de Cisco APIC.
e) Cisco ACI no admite una dirección de clase E como una dirección VTEP.
b) Si definió varios dominios de inicio de sesión, se puede elegir el dominio de inicio de sesión
que desea utilizar al iniciar sesión en un APIC de Cisco. De manera predeterminada, la lista
desplegable de dominios está vacía, y si no elige un dominio, el dominio “DefaultAuth” se
usa para la autenticación. Esto puede provocar un error de inicio de sesión si el nombre de
usuario no está en el dominio de inicio de sesión “DefaultAuth”. Como tal, debe ingresar
las credenciales basadas en el dominio de inicio de sesión elegido.
c) Un grupo de mantenimiento de firmware debe contener un máximo de 80 nodos.
d) Cuando los contratos no están asociados con un grupo de “endpoint”, el DSCP no es
compatible con un VRF con un “vzAny”. DSCP se envía a un “leaf switch” junto con la regla
“actrl”, pero un “vzAny” no tiene una regla actrl. Por lo tanto, el valor DSCP no se puede
enviar.
e) Los APIC de Cisco deben tener 1 SSD y 2 HDD, y ambos volúmenes RAID deben estar en
buen estado antes de actualizar a la última versión. Cisco APIC podría no iniciarse si la SSD
no está instalada.
f) En una configuración “multi-pod”, si se agrega un nuevo “spine switch” a un pod, primero
debe conectarse al menos a un “leaf switch” en el pod. Entonces el “spine switch” realizará
un descubrimiento para la unión.
Nota: Si se instalan enlaces de 1 Gigabit Ethernet (GE) o 10GE entre los “leaf switch” y los “spine switch”,
existe el riesgo de que se pierdan paquetes en lugar de reenviarse debido a un ancho de banda
inadecuado. Para evitar el riesgo, use enlaces 40GE o 100GE entre los “leaf switch” y los “spine switch”.
g) Para una consulta de API APT REST de Cisco de registros de eventos, el sistema APIC de
Cisco limita la respuesta a un máximo de 500,000 registros de eventos. Si la respuesta es
más de 500,000 eventos, devuelve un error. Por tanto, se recomienda usar filtros para
acotar las consultas.
h) Los nombres alternativos del sujeto (SAN) contienen uno o más nombres alternativos y
utilizan cualquier variedad de formularios de nombres para la entidad vinculada por la
Autoridad de certificación (CA) a la clave pública certificada. Estos nombres alternativos se
denominan "Nombres alternativos de sujeto" (SAN). Los posibles nombres incluyen:
i. Nombre DNS
ii. Dirección IP
i) Si un nodo tiene perfiles de puerto implementados, algunas configuraciones de puerto no
se eliminan si retira el nodo. Debe eliminar manualmente las configuraciones después de
desmantelar el nodo para que los puertos vuelvan al estado predeterminado. Para hacer
esto, inicie sesión en el switch, ejecute el script “setup-clean-config.sh”, espere a que se
complete el script, luego ingrese el comando reload.
j) Al utilizar la función de agregación de capturas SNMP, si retira los APIC de Cisco, el servidor
de reenvío de capturas recibirá capturas redundantes.
k) Si no realiza la configuración “over-provisioning” del SSD en los “spine switches” Cisco N9K-
C9364C y N9K-C9336C-FX2, Cisco APIC genera el fallo F2972. la configuración “over-
provisioning” del SSD se aplica automáticamente durante el proceso de arranque del switch
después de responder al fallo. la configuración “over-provisioning” del SSD puede tardar
hasta una hora por spine switch en completarse. Después de que el switch se vuelve a
cargar, no es necesario que realice ninguna otra acción para solventar el fallo.
l) Si se actualizó desde una versión anterior a la versión 3.2 (1) de Cisco APIC y éste poseía
alguna aplicación instalada antes de la actualización, las aplicaciones ya no funcionarán.
Para usar las aplicaciones nuevamente, debe desinstalarlas y reinstalarlas.
m) Los filtros de conectividad quedaron en desuso en la versión 3.2 (4). La degradación de la
función implica que no se han realizado más pruebas y que Cisco recomienda eliminar todas
y cada una de las configuraciones que utilizan esta función. El uso de filtros de conectividad
puede dar como resultado una resolución inesperada de la política de acceso, que en
algunos casos llevará a que las VLAN se eliminen / reprogramen en las interfaces de los
“leaf switch”. Puede buscar la existencia de filtros de conectividad utilizando los siguientes
comandos en el APIC:
i. > moquery -c infraConnPortBlk
ii. > moquery -c infraConnNodeBlk
iii. > moquery -c infraConnNodeS
iv. > moquery -c infraConnFexBlk
v. > moquery -c infraConnFexS
n) Los puertos de conectividad de estructura pueden funcionar a velocidades de 10G o 25G
(según el modelo del servidor APIC) cuando se conectan a las interfaces de host del “leaf
switch”. Se recomienda conectar dos “uplinks” por cada “leaf switch” separado o por cada
par de “leaf switches” vPC.
o) Para APIC-M3 / L3, la tarjeta de interfaz virtual (VIC) 1445 tiene cuatro puertos (puerto-1,
puerto-2, puerto-3 y puerto-4 de izquierda a derecha). El puerto 1 y el puerto 2 forman un
solo par correspondiente a eth2-1 en el servidor APIC; port-3 y port-4 forman otro par
correspondiente a eth2-2 en el servidor APIC. Solo se permite una única conexión para cada
par. Por ejemplo, puede conectar un cable al puerto 1 o al puerto 2 y otro cable al puerto
3 o al puerto 4, pero no 2 cables a ambos puertos en el mismo par. Conectar 2 cables a
ambos puertos en el mismo par crea inestabilidad en el servidor APIC. Todos los puertos
deben configurarse para la misma velocidad: 10G o 25G.
p) Cuando crea un selector de puerto de acceso en un archivo de “leaf switch”, la propiedad
“fexId” se configura con un valor predeterminado de 101 a pesar de que un “FEX” no está
conectado y la interfaz no es una interfaz “FEX”. La propiedad “fexId” solo se usa cuando el
selector de puerto está asociado con un objeto administrativo “infraFexBndlGrp”.
En cisco ACI se requiere de dependencias de flujo de trabajo para garantizar una segregación
en los derechos de acceso, un ejemplo de ello son las reglas RBAC de Cisco Application Centric
Infrastructure (ACI). Éstas, permiten o restringen el acceso a parte o todo el “fabric”. Por ejemplo,
para configurar un leaf switch para el acceso al servidor, el administrador registrado debe tener
derechos para el dominio infra. Por defecto, un administrador de “tenant” no tiene derechos
para el dominio infra. En este caso, un administrador de “tenants” que planea utilizar un servidor
“bare metal” conectado a un leaf switch no podría completar todos los pasos necesarios para
hacerlo.
El administrador del “tenant” tendría que coordinarse con un administrador del “fabric” que
tenga derechos sobre el dominio infra. El administrador del “fabric” configuraría las políticas del
switch que el administrador del “tenant” utilizaría para implementar una política de aplicación
que utiliza el servidor conectado a un leaf switch ACI. Se pueden revisar los roles y privilegios que
proporciona el Application Policy Infrastructure Controller (APIC) en
“Admin”>AAA>”Security”>”Roles”.
c) El APIC contiene una cuenta de usuario y está habilitada con los siguientes permisos:
i. Creación de un proveedor TACACS +.
d) Creación de cuentas de usuario local en los dominios de seguridad de destino. Si el dominio
de destino es “all”, la cuenta de inicio de sesión utilizada para crear el nuevo usuario local
debe ser un administrador de toda la estructura al que tenga acceso “all”. Si el dominio de
destino es un “tenant”, la cuenta de inicio de sesión utilizada para crear el nuevo usuario
local debe ser un administrador de “tenants” que tenga derechos completos de acceso de
lectura y escritura para el dominio de “tenant” de destino.
Una vez comprobadas las configuraciones y permisos anteriores se deberá realizar lo
siguiente:
a) En la barra de menú, elija “Admin”>AAA y haga clic en “Users” y seleccione “Local Users”
donde se deberá verificar que el usuario administrador por defecto (admin) está presente.
b) Haga clic en la lista desplegable del icono de tareas y seleccione “Create Local User”.
c) Se abrirá la ventana de “Create Local User” donde se deberán configurar los campos con
los parámetros que más convengan a su organización y pulse “Next”.
e) Finalmente, en el menú “Roles” se deberán seleccionar los roles del usuario a crear
añadiéndolos por medio del icono “+". Una vez completado se deberá pulsar “Finish” para
finalizar.
f) Nuevamente en el apartado User, haciendo clic derecho sobre el nuevo usuario creado se
desplegará un menú donde podrá elegir la opción “Create X509 Certificate”. En este
apartado podrá crear un certificado X509
Para realizar modificaciones en la política de seguridad de los usuarios locales, deberá realizar
las siguientes tareas:
a) En la barra de menú elija “Admin”>AAA>”Security. Una vez allí, deberá seleccionar
“Management Settings”>”Policy”.
RADIUS
Una de las características más importantes del protocolo RADIUS es su capacidad de manejar
sesiones, notificando cuándo comienza y termina una conexión, así que al usuario se le podrá
determinar su consumo y facturar en consecuencia; los datos se pueden utilizar con propósitos
estadísticos.
Nota: La implementación de una solución de autenticación RADIUS, supone asumir las siguientes
vulnerabilidades conocidas:
- Los mensajes RADIUS no viajan cifrados, a excepción de aquellos datos especialmente sensibles como
las contraseñas.
- RADIUS utiliza MD5 como algoritmo criptográfico de hashing, lo que lo hace vulnerable a ataques de
colisión.
- La comunicación se realiza a través del protocolo UDP, lo que permite que las direcciones IP puedan
ser fácilmente falseadas y susceptible de suplantación de identidad.
- Las especificaciones para la clave compartida no son lo suficientemente robustas y es reutilizada por
el servidor con los clientes. Por tanto, es vulnerable a ataques de fuerza bruta. Una vez obtenida la
clave, el campo "Autenticator" utilizado en mensajes de autenticación (Access-Request) es fácilmente
generado.
Para configurar el acceso RADIUS mediante el APIC de cisco deberá comprobar las siguientes
configuraciones:
a) ACI fabric está instalado, los Controladores de Infraestructura de Políticas de Aplicación
(APIC) están en línea y el clúster APIC está formado y en buen estado.
b) El nombre de host del servidor RADIUS o la dirección IP, el puerto, el protocolo de
autorización y la clave están disponibles.
c) El grupo de administración “endpoint” APIC está disponible.
Una vez comprobadas las configuraciones citadas anteriormente, se describen los pasos
necesarios para la configuración de un servidor RADIUS en el APIC de cisco.
a) Creación de un proveedor RADIUS en el APIC.
i. En la barra de menú, elija “Admin”>AAA. Posteriormente en el panel de navegación ,
haga clic en “Authentication” y luego haga clic en la pestaña “RADIUS”.
ii. En la ventana “Create Login Domain” elija las opciones que convengan y en el apartado
“Providers”, pulse en el icono de “+” y seleccione el servidor RADIUS configurado
anteriormente. Pulse “Update” y posteriormente “Submit” para completar el proceso.
TACACS+
El sistema de control de acceso (TACACS) se refiere a una familia de protocolos que manejan
la autenticación remota y los servicios relacionados para el control de acceso en red a través de
un servidor centralizado. El protocolo original TACACS, derivó a dos protocolos más actuales:
a) Extended TACACS (XTACACS): Es una extensión patentada de TACACS introducida por Cisco
Systems en 1990 sin compatibilidad con el protocolo original. TACACS y XTACACS permiten
que un servidor de acceso remoto se comunique con un servidor de autenticación para
determinar si el usuario tiene acceso a la red.
ii. En la ventana “Create Login Domain” elija las opciones que convengan y en el apartado
“Providers”, pulse en el icono de “+” y seleccione el servidor TACACS+ configurado
anteriormente. Pulse “update” y posteriormente “Submit” para completar el proceso.
LDAP
Una vez comprobadas las configuraciones citadas anteriormente, se describen los pasos
necesarios para la configuración de un servidor LDAP en el APIC de cisco.
a) En la barra de menú, elija “Admin”>AAA. Posteriormente en el panel de navegación, haga
clic en “Authentication” y luego haga clic en la pestaña “LDAP”.
ii. Especifique el nombre de host LDAP (o la dirección IP), el puerto, el Bind DN, el Base DN,
etc. Completando los parámetros necesarios para su organización y que doten al LDAP
de una mayor seguridad. Pulse “Submit” para continuar.
ii. En la ventana “Create Login Domain” elija las opciones que convengan y en el apartado
“Providers”, pulse en el icono de “+” y seleccione el servidor “LDAP” configurado
anteriormente. Pulse “update” y posteriormente “Submit” para completar el proceso.
b) Modo de host múltiple: permite múltiples hosts por puerto, pero solo el primero se
autentica. El puerto se mueve al estado autorizado después de la autorización exitosa del
primer host. No se requiere que los hosts posteriores estén autorizados para obtener
acceso a la red una vez que el puerto esté en el estado autorizado. Si el puerto queda sin
autorización cuando falla la re-autenticación o se recibe un mensaje de cierre de sesión de
EAPOL, a todos los hosts conectados se les niega el acceso a la red. La capacidad de la
interfaz para apagarse en caso de violación de la asociación de seguridad se deshabilita en
modo de host múltiple. Este modo es aplicable tanto para topologías de switch a switch
como de host a switch.
c) Modo de autenticación múltiple: Permite que varios hosts y todos los hosts se autentiquen
por separado.
d) Modo de dominio múltiple: Para datos separados y dominio de voz. Para usar con teléfonos
IP.
ACI 802.1X admite los siguientes modos de autenticación:
a) EAP: El autenticador envía un marco EAP de solicitud/identidad al solicitante para solicitar
su identidad (por lo general, el autenticador envía un marco de solicitud/identidad inicial
seguido de una o más solicitudes de información de autenticación). Cuando el solicitante
recibe la trama, responde con una trama EAP de solicitud/identidad.
b) MAB: La omisión de autenticación de MAC (MAB) se admite como modo de autenticación
alternativa. MAB habilita el control de acceso basado en el puerto utilizando la dirección
MAC del punto final. Un puerto habilitado para MAB se puede habilitar o deshabilitar
dinámicamente en función de la dirección MAC del dispositivo que se conecta a él. Antes
de MAB, la identidad del punto final es desconocida y todo el tráfico está bloqueado. El
switch examina un solo paquete para aprender y autenticar la dirección MAC de origen.
Una vez que MAB tiene éxito, se conoce la identidad del punto final y se permite todo el
tráfico de ese punto final. El switch realiza el filtrado de la dirección MAC de origen para
ayudar a garantizar que solo el punto final autenticado por MAB pueda enviar tráfico.
La autenticación basada en el puerto por el estándar IEEE 802.1X tiene las siguientes pautas y
limitaciones de configuración:
a) Cisco ACI admite la autenticación 802.1X solo en puertos físicos.
b) Cisco ACI no admite la autenticación 802.1X en “port channels” o subinterfaces.
c) Cisco ACI admite la autenticación 802.1X a los miembros de un “port channel” pero no en
el “port channel” en sí.
d) Los puertos miembros con y sin configuración 802.1X pueden coexistir en un “port
channel”. Sin embargo, debe asegurarse de que la configuración 802.1X sea idéntica en
todos los puertos miembros para que la canalización funcione con 802.1X
e) Cuando habilita la autenticación 802.1X, los solicitantes se autentican antes de que
cualquier otra característica de Capa 2 o Capa 3 se habilite en una interfaz Ethernet.
f) 802.1X solo se admite en un chasis tipo “leaf” que es de tipo EX o FX.
g) 802.1X solo es compatible con los puertos de acceso de Fabric. 802.1X no es compatible
con “port channels” o “Virtual-Port-Channels”.
h) IPv6 no es compatible con clientes dot1x en la versión 3.2 (1).
Para realizar esta configuración en la GUI Cisco APIC, deberá poseer de un servidor RADIUS y
configurar una política para el mismo.
a) En la barra de menú, haga clic en “Fabric”>”Access Policies” y despliegue los menús
”Policies”>”Interface”, entonces seleccione “802.1x Port Authentication” y realice las
siguientes acciones:
i. Haga clic con el botón derecho en “802.1x Port Authentication“ y pulse en “Create
802.1x Port Authentication”.
i. Haga clic derecho en “Leaf Access Port”, para abrir “Create Leaf Access Port Policy
Group”.
Para realizar esta configuración con la GUI Cisco APIC, deberá poseer de un servidor RADIUS y
configurar una política para el mismo.
a) En la barra de menú, haga clic en “Fabric”>”Access Policies” y despliegue los menús
”Policies”>”Switch”, entonces seleccione “802.1x Node Authentication” y realice las
siguientes acciones:
i. Haga clic con el botón derecho en “802.1x Node Authentication“ y pulse en “Create
802.1x Node Authentication”.
i. Haga clic derecho en “Policy Groups” y seleccione “Create Access Switch Policy Group”.
c) Para asociar la política de autenticación de nodo 802.1X a un perfil de interfaz leaf switch,
diríjase a “Fabric”>”Access Policies” y despliegue los siguientes menús: ”Interfaces”>”Leaf
Interfaces”. Seleccione “Profiles” y realice las siguientes acciones:
ii. En el campo “Name”, ingrese un nombre para la política. Y pulse el icono “+”
iii. Se abrirá el cuadro de diálogo “Create Access Port Selector” donde deberá ingresar la
información de Nombre e ID de interfaz.
iv. En el campo “Interface Policy Group”, seleccione la política creada previamente y haga
clic en “OK” y posteriormente “Submit”.
En el APIC, el usuario puede configurar la seguridad del puerto (Port Security) en los puertos
del switch. Una vez que el límite MAC ha excedido el valor máximo configurado en un puerto, se
reenvía todo el tráfico de las direcciones MAC excedidas. Se admiten los siguientes atributos:
a) Port Security Timeout: el rango actual admitido para el valor de tiempo de espera es de 60
a 3600 segundos.
b) Violation Action: la acción de infracción está disponible en modo de protección. En el modo
de protección, el aprendizaje MAC está deshabilitado y las direcciones MAC no se agregan
a la tabla CAM. El aprendizaje de Mac se vuelve a habilitar después del valor de tiempo de
espera configurado.
c) Maximum Endpoints: El rango admitido actual para el valor configurado de puntos finales
máximos es de 0 a 12000. Si el valor máximo de puntos finales es 0, la política de seguridad
del puerto está deshabilitada en ese puerto.
Las pautas y restricciones para la correcta configuración son las siguientes:
a) La seguridad del puerto se configura en el puerto.
b) La seguridad de puertos es compatible con puertos físicos, canales de puertos y canales de
puertos virtuales (vPC).
c) Se admiten direcciones MAC estáticas y dinámicas.
d) Los movimientos de direcciones MAC (MAC MOVE) son compatibles desde puertos seguros
a puertos no seguros y desde puertos no seguros a puertos seguros.
e) El límite de la dirección MAC se aplica solo en la dirección MAC y no se aplica en una
dirección MAC e IP.
f) La seguridad del puerto no es compatible con Fabric Extender (FEX).
a) Haga clic con el botón derecho en “Port Security” y haga clic en “Create Port Security
Policy”.
b) En el cuadro de diálogo “Create Port Security Policy”, realice las siguientes acciones:
i. En el campo “Name”, ingrese un nombre para la política.
ii. En el campo “Port Security Timeout”, elija el valor deseado para el tiempo de espera
antes de volver a habilitar el aprendizaje MAC en una interfaz.
iii. En el campo “Maximum Endpoints”, elija el valor deseado para el número máximo de
puntos finales que se pueden aprender en una interfaz.
iv. En el campo “Violation Action”, la opción disponible es proteger (protect).
Posteriormente pulse “Submit”.
Nota: Si no se mostrara la representación gráfica del switch deseado, pulse en el icono “+” y agregue el
switch.
h) Elija el puerto apropiado para configurar la interfaz, y pulse sobre la ruta que aparece en el
campo “Resources”
La mayoría de las funciones de FHS se configuran en dos pasos: en primer lugar, define una
política que describe el comportamiento de la función, en segundo lugar, aplica esta política a un
"dominio" (que es el tenant bridge domain o el tenant “endpoint” group). Se pueden aplicar
diferentes políticas que definen diferentes comportamientos a diferentes dominios que se
cruzan. La decisión de usar una política específica la toma el dominio más específico al que se
aplica la política.
Las opciones de política se pueden definir desde la GUI APIC de Cisco que se encuentra en la
pestaña Nombre del Tenant>Policies>Protocol>First Hop Security.
PAUTAS Y LIMITACIONES
d) Cuando IP Source Guard está habilitado, el tráfico IPv6 que se origina usando la dirección
IPv6 Link Local como dirección de origen IP no está sujeto a la aplicación IP Source Guard
(es decir, cumplimiento de Source Mac <=> enlaces de IP de origen asegurados por la
función de inspección IP). Este tráfico está permitido de manera predeterminada,
independientemente de los fallos de verificación vinculantes.
e) FHS no es compatible con las interfaces L3Out.
f) FHS no es compatible con TOR basados en N9K-M12PQ.
g) FHS en ACI Multi-Site es una capacidad local del sitio, por lo tanto, solo se puede habilitar
en un sitio desde el clúster APIC. Además, FHS en ACI Multi-Site solo funciona cuando BD y
EPG es local y no se extiende a través de los sitios. La seguridad de FHS no se puede habilitar
para BD o EPG extendidos.
h) FHS no es compatible con un “bridge domain” de capa 2 solamente.
i) La activación de la función FHS puede interrumpir el tráfico durante 50 segundos porque el
EP en el BD se vacía y el aprendizaje EP en el BD se desactiva durante 50 segundos.
i. En el campo “Name”, ingrese un nombre para la política de seguridad del primer salto.
ii. Verifique que los campos “IP Inspection”, “Source Guard” y “Router Advertisement”
estén habilitados, se deberán modificar los demás parámetros acorde a su organización,
y finalmente pulse “Submit”.
b) En el panel de navegación, expanda “First Hop Security” y haga clic con el botón derecho
en “Trust Control Policies” para abrir “Create Trust Control Policy” y realizar las siguientes
acciones:
i. En el campo Política de “First Hop Security”, seleccione la política que acaba de crear y
haga clic en “Submit”. Esto completa la configuración de FHS.
COOP
El Protocolo del Consejo de Oracle (COOP) se utiliza para comunicar la información de mapeo
(ubicación e identidad) al spine proxy. Un leaf switch reenvía la información de la dirección del
“endpoint” al spine switch 'Oracle' utilizando Zero Message Queue (ZMQ). COOP que se ejecuta
en los nodos spine asegurará que todos los nodos spine mantengan una copia coherente de la
dirección del “endpoint” y la información de ubicación y, además, mantendrá el depósito de la
tabla hash distribuida (DHT) de la identidad del “endpoint” a la base de datos de mapeo de
ubicación.
La comunicación de ruta de datos COOP proporciona alta prioridad al transporte mediante
conexiones seguras. COOP se ha mejorado para aprovechar la opción MD5 para proteger los
mensajes COOP de la inyección de tráfico malicioso. El controlador APIC y los switches admiten
la autenticación del protocolo COOP.
El protocolo COOP se ha mejorado para admitir dos modos de autenticación ZMQ: estricto y
compatible.
a) Modo estricto: COOP solo permite conexiones ZMQ autenticadas con MD5.
b) Modo compatible: COOP acepta conexiones ZMQ autenticadas y no autenticadas MD5 para
el transporte de mensajes.
Para admitir la compatibilidad de autenticación COOP Zero Message Queue (ZMQ) en todo el
entramado de Infraestructura céntrica de aplicaciones (ACI) de Cisco, el Controlador de
infraestructura de políticas de aplicación (APIC) admite la contraseña MD5 y también el modo
seguro COOP.
Configuración del tipo de autenticación COOP ZMQ: coop:AuthP: se agrega un nuevo objeto
administrado a la base de datos del Motor de administración de datos (DME) / COOP (coop / inst
/ auth). El valor predeterminado para el tipo de atributo es "compatible", y los usuarios tienen la
opción de configurar el tipo para que sea "estricto".
Autenticación COOP ZMQ por contraseña MD5: El APIC proporciona un objeto administrado
(fabric:SecurityToken), que incluye un atributo que se utilizará para la contraseña MD5. Un
atributo en este objeto administrado, llamado "token", es una cadena que cambia cada hora.
COOP obtiene la notificación del DME para actualizar la contraseña para la autenticación ZMQ.
El valor del token de atributo no se muestra.
Nota: Durante una actualización de la estructura ACI, el modo estricto COOP no se permite hasta que se
actualicen todos los interruptores. Esta protección evita el rechazo inesperado de una conexión COOP que
podría activarse al habilitar prematuramente el modo estricto.
Para la configuración de COOP usando la GUI Cisco APIC siga y adapte los siguientes pasos
según proceda:
a) En la barra de menú, elija “System”>“System Settings”.
EIGRP
EIGRP combina los beneficios de los protocolos de vector de distancia con las características
de los protocolos de estado de enlace. EIGRP envía mensajes de saludo periódicos para el
descubrimiento de activos de la red. Una vez que EIGRP se entera de un nuevo activo, envía una
actualización única de todas las rutas y métricas de ruta locales de EIGRP. El enrutador EIGRP
receptor calcula la distancia de ruta en función de las métricas recibidas y el costo asignado
localmente del enlace a ese activo. Después de esta actualización inicial de la tabla de ruta
completa, EIGRP envía actualizaciones incrementales solo a los activos afectados por el cambio
de ruta. Este proceso acelera la convergencia y minimiza el ancho de banda utilizado por EIGRP.
Para Cisco APIC, la autenticación EIGRP utiliza la infraestructura de llavero de “Route-map”
para la autenticación MD5. Se necesitan dos parámetros para configurar la autenticación entre
dos pares EIGRP. Los parámetros son:
a) Mode
b) Keychain
Nota: El protocolo EIGRP solo admite la autenticación MD5, por tanto, se recomienda su uso en los casos
donde las necesidades de la organización requieran del mismo, limitando su utilización a la comunicación
entre elementos más internos de la infraestructura.
Para la configuración de EIGRP usando la GUI Cisco APIC siga y adapte los siguientes pasos
según proceda:
a) En la barra de menú, elija “Tenant” y pulse doble clic sobre el tenant a aplicar configuración.
Para habilitar FIPS mediante la GUI Cisco APIC siga los siguientes pasos:
a) En la barra de menú, elija “System”>”System Settings”>”Fabric Security”.
Nota: Las opciones para el modo FIPS son Deshabilitar y Habilitar. El valor por defecto es Deshabilitado.
c) Se mostrará una advertencia sobre la seguridad de protocolos y encriptaciones que se
utilizará con motivo de habilitación del estándar FIPS. Si está conforme pulse “YES”.
d) Cada vez que cambie el modo, debe reiniciar para completar la configuración.
Las comunicaciones EPG requieren un contrato, la comunicación EPG a EPG no está permitida
sin un contrato. El APIC presenta el modelo de política completo, incluidos los contratos y sus
EPG asociadas, en el modelo concreto en cada cambio. Al ingresar, cada paquete que ingresa al
“fabric” se marca con los detalles de la política requerida. Debido a que los contratos deben
seleccionar qué tipos de tráfico pueden pasar entre las EPG, los contratos aplican políticas de
seguridad. Si bien los contratos satisfacen los requisitos de seguridad manejados por las listas de
control de acceso (ACL) en la configuración de red convencional, son una solución de política de
seguridad más flexible, manejable e integral.
Las listas de control de acceso tradicionales (ACL) tienen una serie de limitaciones que el
modelo de seguridad de ACI “fabric” aborda. La ACL tradicional está muy unida a la topología de
la red. Por lo general, se configuran por interfaz de entrada y salida de router o switch y se
personalizan para esa interfaz y el tráfico que se espera que fluya a través de esas interfaces.
Debido a esta personalización, a menudo no se pueden reutilizar en las interfaces, y mucho
menos en los routers o switches.
Las ACL tradicionales pueden ser muy complicadas y crípticas porque contienen listas de
direcciones IP, subredes y protocolos específicos que están permitidos, así como muchos que no
están permitidos específicamente. Esta complejidad hace que sean difíciles de mantener y, a
menudo, simplemente crecen, ya que los administradores son reacios a eliminar las reglas de
ACL por temor a crear un problema. Su complejidad ocasiona que generalmente solo se
implementen en puntos específicos en la red. En muchas ocasiones, los beneficios de seguridad
de las ACL no se explotan como por ejemplo, dentro de una organización o en el tráfico en el
centro de datos.
Otro problema es el posible gran aumento en el número de entradas en una sola ACL. Los
usuarios a menudo desean crear una ACL que permita que un conjunto de orígenes se comunique
con un conjunto de destinos mediante el uso de un conjunto de protocolos. En el peor de los
casos, si X orígenes están hablando con Y destinos utilizando Z protocolos, puede haber X * Y *
Z entradas en la ACL. La ACL debe enumerar cada fuente que se comunica con cada destino para
cada protocolo. No se necesitan muchos dispositivos o protocolos antes de que la ACL sea muy
extensa.
El modelo de seguridad de ACI “fabric” aborda estos problemas de ACL. El modelo de
seguridad de ACI “fabric” expresa directamente la intención del administrador. Los
administradores usan los objetos gestionados por contrato, filtro y etiqueta para especificar
cómo los grupos de “endpoint” pueden comunicarse. Estos objetos administrados no están
vinculados a la topología de la red porque no se aplican a una interfaz específica. Son
simplemente reglas que la red debe aplicar independientemente de dónde estén conectados
estos grupos de “endpoint”. Esta independencia de topología facilita que estos objetos
administrados se puedan implementar y reutilizar fácilmente en todo el centro de datos, no solo
como puntos de demarcación específicos.
El modelo de seguridad de ACI “fabric” utiliza la construcción de agrupación de “endpoint”
directamente, por lo que la idea de permitir que grupos de servidores se comuniquen entre sí es
simple. Una sola regla puede permitir que un número arbitrario de orígenes se comunique con
un número igualmente arbitrario de destinos. Esta simplificación mejora drásticamente su
escalabilidad y facilidad de mantenimiento, lo que también significa que son más fáciles de usar
en todo el centro de datos.
Los contratos contienen las políticas que rigen la comunicación entre las EPG. El contrato
especifica qué se puede comunicar y las EPG especifican el origen y el destino de las
comunicaciones. Los contratos vinculan las EPG.
Los “endpoints” en un EPG pueden comunicarse con los “endpoints” de otro EPG y viceversa
si el contrato lo permite. Esta estructura de políticas es muy flexible. Puede haber muchos
contratos entre EPG’s, puede haber más de dos EPG que usen un contrato, y los contratos se
pueden reutilizar en múltiples conjuntos de EPG.
También hay direccionalidad en la relación entre EPG y contratos. Las EPG pueden
proporcionar o poseer un contrato. Una EPG que proporciona un contrato suele ser un conjunto
de “endpoints” que proporcionan un servicio a un conjunto de dispositivos cliente. Los
protocolos utilizados por ese servicio están definidos en el contrato. Por otra parte, una EPG que
posee un contrato suele ser un conjunto de “endpoints” clientes de ese servicio. Cuando el
“endpoint” del cliente intenta conectarse a un “endpoint” del servidor (proveedor), el contrato
verifica si esa conexión está permitida. A menos que se especifique lo contrario, ese contrato no
permitiría que un servidor inicie una conexión con un cliente. Sin embargo, otro contrato entre
las EPG podría permitir fácilmente una conexión en esa dirección.
Esta relación proveedor/cliente generalmente se muestra gráficamente con flechas entre las
EPG y el contrato. Tenga en cuenta la dirección de las flechas que se muestran a continuación.
EPG 1 <------- cliente del contrato------ CONTRACT <----- servidor del contrato ------ EPG 2
Por ejemplo, puede definir un filtro llamado HTTP que especifique el puerto TCP 80 y el puerto
TCP 8080 y otro filtro llamado HTTPS que especifique el puerto TCP 443. Luego puede crear un
contrato llamado “webCtrct” que tiene dos conjuntos de temas. “openProv” y “openCons” son
los temas que contienen el filtro HTTP. “secureProv” y “secureCons” son los temas que contienen
el filtro HTTPS. Este contrato de “webCtrct” se puede utilizar para permitir el tráfico web seguro
y no seguro entre las EPG que proporcionan el servicio web y las EPG que contienen “endpoints”
clientes de ese servicio.
Estas mismas construcciones también se aplican a las políticas que rigen los hipervisores de
máquinas virtuales. Cuando se coloca una EPG en un dominio de administrador de máquina
virtual (VMM), el APIC descarga todas las políticas asociadas con la EPG a los “leaf switch” con
interfaces que se conectan al dominio VMM. Cuando se crea esta política, el APIC la configura a
un dominio VMM que especifica qué switches permiten la conectividad para los “endpoints” en
las EPG. El dominio VMM define el conjunto de switches y puertos que permiten la conexión de
“endpoints” en una EPG. Cuando un “endpoint” entra en línea, se asocia con las EPG apropiadas.
Cuando envía un paquete, la EPG de origen y la EPG de destino se derivan del paquete y la política
definida por el contrato correspondiente que verifica si el paquete está permitido. En caso
afirmativo, se reenvía el paquete. Si no, el paquete se descarta.
En detalle, los contratos se componen de los siguientes elementos:
a) Nombre: Todos los contratos propiedad de un tenant deben tener nombres diferentes
(incluidos los contratos creados bajo el “tenant common” o el “tenant itself”).
b) Subjects: Un grupo de filtros para una aplicación o servicio específico.
c) Filtros: Se utilizan para clasificar el tráfico según los atributos de la capa 2 a la capa 4 (como
el tipo de Ethernet, el tipo de protocolo, los indicadores TCP y los puertos).
d) Acciones: Acciones a realizar en el tráfico filtrado. Se admiten las siguientes acciones:
i. Permitir el tráfico (solo contratos regulares).
ii. Marcar el tráfico (DSCP / CoS) (solo contratos regulares).
iii. Redireccionar el tráfico (solo contratos regulares, a través de un gráfico de servicio).
iv. Replicar tráfico (solo contratos regulares, a través de un gráfico de servicio o SPAN).
vi. En la lista desplegable “Name”, elija una opción; por ejemplo, haga clic en ”arp”,
“default”, “est” o “icmp”, o elija un filtro configurado previamente.
vii. En la lista desplegable Directivas, seleccione el parámetro que más convenga.
viii. (Opcional) Elija la acción de permitir o denegar según convenga en el apartado “Action”.
Nota: Con la directiva: “log” seleccionada, si la acción para este tema es Permitir, los registros de permiso
ACL rastrean los flujos y paquetes que están controlados por el “Subject” y el contrato. Si la acción para
este “Subject” es Denegar, los registros de denegación de ACL rastrean los flujos y los paquetes.
ix. (Opcional) Establezca la prioridad para el “Subject”. Pulse en “Update” para finalizar la
configuración.
x. Finalmente pulse “OK” en la ventana “Create Contract Subject” y “Submit” en la ventana
de “Create Contract”.
ACCESO HTTPS
Los certificados “wildcard” (como *.cisco.com) y su clave privada asociada generada en otro
lugar no son compatibles con el APIC, ya que no hay soporte para ingresar la clave privada o
contraseña en el APIC. Además, no se admite la exportación de claves privadas para ningún
certificado, incluidos los certificados “wildcard”.
Se deben descargar e instalar los certificados de CA pública intermedia o raíz (root) antes de
generar una Solicitud de firma de certificado (CSR). Aunque técnicamente no se requiere un
certificado de CA raíz (root) para generar una CSR, Cisco requiere el certificado de CA raíz antes
de generar la CSR para evitar desajustes entre la autoridad de CA prevista y la actual utilizada
para firmar la CSR. El APIC verifica que el certificado enviado esté firmado por la CA configurada.
Para usar las mismas claves públicas y privadas para la generación y renovación de
certificados, debe cumplir con las siguientes pautas:
a) Debe conservar la CSR de origen, ya que contiene la clave pública que se empareja con la
clave privada en el anillo de claves (key ring).
b) La misma CSR utilizada para el certificado de origen debe volver a presentarse para el
certificado renovado si desea reutilizar las claves públicas y privadas en el APIC.
c) No elimine el “key ring” original cuando use las mismas claves públicas y privadas para el
certificado renovado. Al eliminar el “key ring”, se eliminará automáticamente la clave
privada asociada que se usa con las CSR.
Para la implementación de certificados en Cisco APIC se debe tener en consideración las
siguientes premisas:
a) Multisitio, VCPlugin, VRA y SCVMM no son compatibles con la autenticación basada en
certificados.
b) Solo un certificado basado en raíz (root) puede estar activo por pod.
c) La autenticación basada en certificados debe deshabilitarse si desea disminuir de versión
desde la versión 4.0 (1).
d) Para finalizar la sesión de autenticación basada en certificados, el usuario debe cerrar
sesión y luego quitar la tarjeta CAC.
Se describen a continuación los pasos a seguir para la implementación mediante la GUI de un
certificado personalizado de acceso a Cisco ACI HTTPS:
Nota: Esta tarea deberá realizarse dolo durante una ventana de mantenimiento ya que podría provocar
un corte extenso en el servicio. El tiempo de inactividad afecta al acceso al clúster APIC y a los switches
de usuarios o sistemas externos. El proceso NGINX en los switches también se verá afectado, pero eso
será solo para la conectividad externa y no para el plano de datos del fabric. El acceso al APIC, la
configuración, la administración, la resolución de problemas y demás se verán afectados. Deberá por
tanto, esperar al reinicio de todos los servidores web en la “fabric” durante esta operación.
c) Una vez finalizado deberá reflejarse en el menú de trabajo algo similar a la siguiente
imagen.
d) Sin salir del menú “Public Key Management”, elija el menú “Key Rings”. Elija el icono
Acciones/trabajo y seleccione “Create Key Ring”.
e) En el cuadro de diálogo “Create Key Ring” deberá completar los siguientes campos:
i. En el campo “Name”, ingrese un nombre.
ii. El campo “Certificate” deberá quedar vacío
iii. En el campo “Modulus” elija el que más se adapte con su organización
iv. En “Create Authority” deberá seleccionar la autoridad certificadora creada en el paso
anterior.
Nota: No elimine el almacén de claves (key ring). Al eliminar el “key ring”, se eliminará automáticamente
la clave privada asociada que se usa con las CSR.
g) En la ventana emergente “Create Certificate Request” complete los campos con los datos
de su organización y una contraseña segura. El campo “Subject” deberá contener el FQDN
o nombre representativo del dispositivo. Pulse “Submit” para continuar.
h) Pulse doble clic sobre el almacén de claves creado anteriormente y deslizando la flecha
hacia abajo, verá que se muestran los datos configurados anteriormente. Copie todo el
contenido del apartado “Request” para enviarlo a la entidad certificadora para su firma.
Pulse “Close” si no ha realizado ningún cambio adicional, por el contrario, pulse “Submit”.
i) Copie el certificado firmado por la entidad certificadora y pulse doble clic, nuevamente,
sobre el almacén de claves creado anteriormente y en el campo “Certificate” ingrese el
certificado firmado por la entidad certificadora. Posteriormente, pulse “Submit” y “Submit
Changes” para completar el proceso.
Nota: Si el CSR no fue firmado por la Autoridad de certificación indicada en el conjunto de claves, o si el
certificado tiene terminaciones de línea MS-DOS, se muestra un mensaje de error y no se acepta el
certificado. Elimine las terminaciones de línea de MS-DOS.
BANNER DE LA APLICACIÓN
En este apartado se detallan las pautas para configurar un mensaje disuasorio (banner) para
advertir a los operadores y de este modo, diferenciar los distintos APIS a los que se está
accediendo.
Para realizar esta configuración mediante la GUI de Cisco APIC, deberá realizar las siguientes
configuraciones:
a) Diríjase a “System”>“System Settings” y seleccione “System Alias and Banners”
b) Deberá configurar el apartado “Controller CLI Banner”, “Switch CLI Banner” con el mensaje
que más convenga a su organización y posteriormente habilitar el “check” del apartado
“Show Application Banner” e introducir el mensaje nuevamente cuando el campo se
habilite. Finalmente seleccione la opción “Warning” para el apartado “Banner Severity”
para que así se muestre. Para guardar las configuraciones pulse “Submit”.
El cifrado AES-256 es una opción de configuración global. Cuando está habilitado, todas las
propiedades seguras se ajustan a la configuración de AES. Una parte de la configuración de la
estructura ACI se puede exportar utilizando la exportación de configuración con un “targetDn”
específico. Sin embargo, no es posible utilizar REST API para exportar solo una parte de la
estructura ACI, como una configuración de “tenant” con propiedades seguras y cifrado AES. Las
propiedades seguras no se incluyen durante las solicitudes de API REST. Se muestra a
continuación, pautas para habilitar el cifrado global AES utilizando la GUI.
a) Sitúese sobre el menú “System” y haciendo clic sobre él, diríjase a los siguientes submenús
y apartados: “System Settings”>”Global AES Passphrase Encryption Settings”.
b) En el submenú “Global AES Encryption Settings for all Configuration Import and
Export”>”Policy”, en el apartado “Properties” seleccione la casilla “Enable Encryption” y
configure una contraseña segura en los apartados “Passphrase y Confirm Passphrase”. Para
aplicar los cambios pulse “Submit”.
c) Posteriormente se abrirá una ventana emergente que advertirá sobre las políticas que
sufrirán cambios con la aplicación de esta configuración. Revise la columna de “Policies
using This policy” y si no entra en conflicto con configuraciones de su organización, pulse
el botón “Submit Changes”.
d) Deberá comprobar que se han aplicado los cambios, si ha salido del menú, vaya a
“System”>”System Setting”>”Global AES Encryption Settings for all Configuration Import
and Export”. Compruebe que en el apartado “Propierties” está señalado “Enable
Encryption” y que se ha generado un hash correcto en el apartado “Encrypted Passphrase”
Nota: Después de habilitar el cifrado, no puede configurar una frase de paso o contraseña al crear una
nueva política de importación o exportación. La frase de contraseña que configuró anteriormente ahora
es global en todas las configuraciones de este cuadro y en todos los “tenant”. Si exporta una configuración
desde esta pestaña “you have configured a passphrase and enabled encryption”, obtendrá un archivo de
copia de seguridad completa. Si el cifrado no está habilitado, obtendrá un archivo de copia de seguridad
con las propiedades seguras eliminadas. Estos archivos de respaldo son útiles cuando se exporta a
personal que no debe conocer todos los campos seguros.
APLICACIONES ADICIONALES
Para añadir una nueva aplicación desde la GUI de Cisco APIC, siga los siguientes pasos:
a) sitúese sobre el menú “Apps”>”Apps” y haga clic en el icono “Add Application”
b) Se abrirá una ventana llamada “Add application to APIC”. Pulse en “Browse..” y seleccione
la ruta hacia la aplicación que se desea añadir, cuando ésta se encuentre seleccionada,
pulse en “Submit”.