Mostrando entradas con la etiqueta CCIE Datacenter. Mostrar todas las entradas
Mostrando entradas con la etiqueta CCIE Datacenter. Mostrar todas las entradas

martes, 2 de junio de 2015

Nexus: Consideraciones de diseño al usar VDC



Introducción:

Este artículo pertenece a un grupo de artículos dedicados a tecnologías específicas de los equipos Nexus que pertenecen a la gama de Datacenter de Cisco. En estos artículos pretendo explicar brevemente cómo funcionan ciertas tecnologías que son propias de los Nexus, y que tienen poco que ver con el resto de switches.

Una interfaz solo puede estar en un único VDC:

Por lo general una interfaz tan solo puede pertenecer a un único VDC, pero hay dos claras excecpiones a esto.

Todos los VDC comparten la misma interfaz de management, esta interfaz puede tener asignada diferente ip en cada VDC(todos en la misma red), y esto permitiría administrar todos los VDC cada uno con su IP. No está permitido el tráfico de interfaz de management de un VDC a interfaz de management de otro VDC.

Una interfaz puede asignarse al VDC de storage, y a otro VDC al mismo tiempo, de modo que  el tráfico FCoE va al VDC de storage, y el tráfico Ethernet al VDC “normal”.

El tipo de tarjeta influye mucho:

Cuando vas a asignar puertos no todas las tarjetas permiten asociar un único puerto a un VDC, esto es porque hay tarjetas que tienen un chip dedicado por puerto, y otras que tienen un chip dedicado por grupo de puertos(sobresuscripción).

Para ilustrar dejo algunos ejemplos de la página de Cisco de cuan diferente puede ser la distribución de puertos según el tipo de tarjeta, cada dos puertos, cada cuatro, o sin restricciones. Recomiendo encarecidamente hacer clic en los links de abajo a la página de Cisco Systems para comprobar cómo se reparten los puertos en cada tarjeta.





Escenarios típicos:

Separación de entornos de firewall: 



En este ejemplo en lugar de comprar equipos físicos diferentes para la zona segura y no segura, lo que se hace es configurar un VDC para proveer de puertos a lo que consideramos la zona no segura, y otro VDC para la zona segura. Si lo hiciésemos en un solo equipo sin VDC cualquier fallo de configuración de VLANs permitiría acceder al core.

Consolidación modelo tres capas:






En este ejemplo en lugar de tener dos equipos de Core, dos de Distribución, y N de Acceso lo que hacemos es juntar las capas de Core y Distribución en dos dispositivos físicos, pero que realmente se dividen en dos VDC, uno de Distribución y otro de Core. 

VDC OTV:



Aquí lo que hacemos es crear un VDC que va a ejecutar la funcionalidad de OTV, y como clientes de OTV tendrá a uno o varios VDC.


Artículos recomendados:

domingo, 31 de mayo de 2015

Nexus: Virtual Device Context(VDC)



Introducción:


Este artículo pertenece a un grupo de artículos dedicados a tecnologías específicas de los equipos Nexus que pertenecen a la gama de Datacenter de Cisco. En estos artículos pretendo explicar brevemente cómo funcionan ciertas tecnologías que son propias de los Nexus, y que tienen poco que ver con el resto de switches.



Que es VDC:

Virtual Device Context es una tecnología propietaria de cisco para la gama Nexus, que permite la creación de dispositivos virtuales a partir de un dispositivo físico. No estamos hablando de únicamente tablas de routing virtuales como en el caso de los VRF, en este caso hablamos de separación de entornos completos, permitiendo que cada VDC tenga su propia configuración de Radius por poner un ejemplo. Por supuesto dentro de cada VDC puedes crearte también VRF, y cada VRF es local a su propio VDC.

Que equipos soportan VDC:

Los Nexus 7000 y los Nexus 9000k. No los Nexus 5000 no soportan VDC, todos sus puertos están asignados al VDC default. Hay que tener en cuenta que según el modelo de procesadora que tenga tu Nexus tendrá a su disposición un número mayor o menor de VDCs.



Configuración de VDC:
 

NX1# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
NX1(config)# vdc FRONTEND
Note: Creating VDC, one moment please ...
NX1(config)# vdc BACKEND
Note: Creating VDC, one moment please ...
NX1(config-vdc)# show vdc
vdc_id vdc_namestate mactype lc
--------------------------------------------
1 NX1                    active 50:00:00:02:00:2f                Ethernet m1f1m1xl
2 FRONTEND     active 50:00:00:02:00:2f                Ethernet m1f1m1xl
3 BACKEND        active 50:00:00:02:00:2f                Ethernet m1f1m1xl


Aquí como puede verse lo que hacemos es crear dos VDC a parte del principal, uno sería el Frontend y otro sería el Backend.


NX1(config-vdc)# allocate interface e1/1-12
Moving ports will cause all config associated to them in source vdc to be removed. Are you sure you want to move the ports (y/n)? [yes] yes
NX1(config-vdc)# show vdc membership
vdc_id: 3 vdc_name: BACKEND interfaces:
Ethernet1/1 Ethernet1/2 Ethernet1/3
Ethernet1/4 Ethernet1/5 Ethernet1/6
Ethernet1/7 Ethernet1/8 Ethernet1/9
Ethernet1/10 Ethernet1/11 Ethernet1/12


Desde dentro de Backend lo que hacemos es asignarle un grupo de interfaces a ese VDC. Lo que hacemos es asignarle interfaces físicas, y luego ya dentro de cada VDC se las podrá configurar como en cualquier router normal.

Interconectar VDC:

Una pregunta que seguro se te ha venido a la cabeza es ¿Cómo conecto dos VDC?. Pues con un cable :-) . Eso o pones un switch entre medias, pero el caso es que son equipos diferentes un VDC del otro, por tanto ambos ejecutan CDP,  y se ven por CDP como si fuesen equipos diferentes.

Conectarse a un VDC:

A la hora de conectarte a un VDC puedes entrar con un simple telnet siempre y cuando tengas configurado el Telnet/SSH dentro del VDC, y la otra opción es usar el comando switchto vdc NOMBRE. Con este comando puedes saltar desde el VDC default a cualquier otro VDC. Si quisiésemos volver al VDC principal es tan fácil como el comando switchback.

viernes, 30 de mayo de 2014

Siguiente objetivo: CCIE Service Provider

 En los últimos meses tras haberme sacado el CCIE de Routing &Switching la verdad es que he estado bastante vaguete, también es cierto que entre vacaciones, cambio de trabajo y demás no he tenido demasiado tiempo libre.

Sin embargo llevaba ya tiempo pensando en la posibilidad de sacarme un segundo CCIE, quizá no sea tan interesante como tener el primer CCIE cuando te dan el número, pero lo cierto es que por el camino se aprende un montón, y nunca viene mal para reforzar tu carrera.



Estuve planteándome que path seguir, lo bueno que tiene haberme sacado R&S es que te da una visión general de las redes, y quizá resulta mas facil el salto a otros CCIE.

Por interés personal quizá el que mas me gustaba era el CCIE Datacenter pero el problema es la emulación de hardware para los ejercicios, y si terminas haciendo algún rack rental vas a tener que empeñar algún órgano.

Mi segunda opción fue pensar en el CCIE Security, hace años me saqué el CCSP y estuve trabajando en ese area, pero lo cierto es que como materia me aburre bastante, personalmente me parece mucho mas entretenido el trabajo de construir una red escalable, que el tema de seguirdad.

El tercero que apareció en mi mente fue el CCIE de Service Provider, que quizá para mi sea el CCIE mas natural por el hecho de que me muevo mucho en entornos ISP, y si bien me siento bastante confiado cuando te preparas un CCIE alcanzas un dominio de la tecnología increíble, por tanto sería algo que podría ayudarme en mi trabajo, y no sería un cambio drástico.

Por tanto a finales de verano tengo mi cita ineludible con Bruselas para otra gran batalla contra la máquina, quizá no siento esa necesidad tan imperiosa como cuando buscaba el primer CCIE, pero lo cierto es que mi presión también mucho menor al ya tener mi número de CCIE.

Durante las próximas semanas vereis regularmente publicarse un par de artículos semanales vinculados a la temática de Service Provider, fruto de algunas decenas de tardes que ya he dedicado al tema.