Protocol Os

UNIVERSIDAD CATÓLICA BOLIVIANA

―SAN PABLO‖

LA PAZ - BOLIVIA

CARRERA: Ingenieria de Sistemas

TÍTULO: PROTOCOLOS DE ALTA DISPONIBILIDAD Y REDUNDANCIA EN WINDOWS

ALUMNO(S): CRISTIAN ISRAEL CONDORI PAIVA JUAN MANUEL VALDEZ VALDA VIDANGOS PHILIPPSBERG ULRICH MATTHEW GASTON ALDO CALLA CLAVIJO FRANCO ANTONIO SAAVEDRA PEÑA DOCENTE: JESUS BERNARDO RUIZ FLORES MATERIA: MÉTODOS Y TÉCNICAS DE INVESTIGACIÓN FECHA DE ENTREGA: 06/11/2014

Protocolos de alta disponibilidad y redundancia en Windows

Existen varios protocolos de redundancia, balanceo de carga y alta disponibilidad pero los principales y más

utilizados son: HSRP, VRRP y GLBP. Para ello se describirá cada protocolo y las opciones que tiene para ver

con más detalle su comportamiento.

Es importante que en redes de producción se utilicen enlaces y dispositivos redundantes para mantener la alta

disponibilidad del servicio. Para ello se puede utilizar dispositivos como switches de capa 3 o routers para

poder completar esta función.

Para empezar hablaremos de los tres protocolos y de sus características y seguidamente realizaremos la

topología para cada uno de ellos.

HSRP (Hot Standby Routing Protocol ).

Es un Protocolo propietario de Cisco

Pertenece al RFC 2281

Crea una Virtual IP address y una Virtual Mac-address para realizar la redundancia

Existen tres tipos de routers : Active Router, el Standby Router y Virtual Router.

Active Router : Es el router activo que recive el tráfico para ser reenviado a su destino .

Standby Router : Es el router de backup en caso de que el Active Router se caiga.

Virtual Router : No es un router, pero representa al grupo HSRP como un router virtual y es el actual default

gateway para los hosts.

En realidad el host tiene configurado el default gateway del Virtual Router que realmente pertenecerá al

Active router que será el encargado de reenviar los paquetes al destino.

Este protocolo envía mensajes de Hello como los de los protocolo de routing para saber si su vecino

está vivo . Estos mensajes se envían cada 3 segundos mediante la dirección multicast 224.0.0.2 y el

puerto UDP 1985.

Para determinar quién será el Active Router se decide mediante la Standby Priority. Que podremos

poner valores entre 0 – 255. Por defecto viene a 100 y el que tenga la prioridad más alta es el que se

escoje como Active Router. En caso de empatar con las prioridades, el router que tenga la IP address

más grande será el Active Router.

En caso de no configurar la opción “preempt” sucedera que el primer router que inicie será el

escogido como Active Router . Esto lo veremos más tarde dado que esta opción permite recuperar a

un Active Router cuando vuelve a estar operativo.

En cuanto se escoje el Active Router los demás routers están en modo monitor a la posible espera de

poder ser Active Router en caso de fallo. Esto sucede en cuando el hold time de los hello’s llega a

los 10 segundos, que es el parámetro por defecto . En ese momento el Standby Router pasa a ser el

Active Router y se consigue que no haya pérdida de disponibilidad.

Para determinar qué tipo de FHRP está utilizando la red podemos fijarnos en el arp -a de un host y veremos

la Mac-address del router gateway de la red que será el Active Router. Recordamos que es en formato

hexadecimal. En caso de haber letras tendremos que pasarlas a decimal para saber a qué ID pertenecen.

C:\>arp -a

Interfaz: 192.168.1.129 — 0×2

Dirección IP Dirección física Tipo

192.168.1.1 00-00-0c-07-ac-01 dinámico

Podremos distinguir el siguiente :

Vendor Code : 00-00-0c –> Cisco

Protocolo : 07-ac –> HSRP

ID grupo : 01 –> Grupo 1

Este protocolo también es capaz de soportar autenticación mediante texto plano y en caso más seguro

en MD5.

ESTADOS HSRP

Los routers antes de pasar a tener un rol, tienen que pasar por varios estados :

Initial State : Todos los routers inician con este estado. Este estado se da cuando se ha realizado algún

cambio en la configuración o cuando se ha iniciado una interface.

Learn State : En este estado aún no se ha determinado la Virtual IP address y no se ha recibido ningún hello

del Active Router. El router está esperando y escuchando para recibir algún hello del Active Router.

Listen State : El router conoce la Virtual IP address, pero no es ni el Active Router ni el Standby Router.

Todos los routers del grupo HSRP persisten en este modo incluso el Active y Standby router.

Speak State : Este estado permite a los routers hablar periódicamente mediante hello’s y participar en la

elección del Active Router y el Standby Router. El router se queda en el estado Speak al menos que se

convierta en un Active o Standby router.

Standby State : Este estado coloca al router en modo backup y envía mensajes hello periódicamente . En de

perdida de conectividad con el Active Router el Standby Router pasa a ser el Active . Tiene que haber como

mínimo un router de Standby.

Active State : Este estado, el router es el encargado de reenviar los paquetes que llegan a la Virtual IP y mac-

address del grupo HSRP. El router activo también envía periódicamente mensajes Hello.

HSRP LOAD BALANCING

Se puede realizar balanceo de carga mediante grupos HSRP y mientras que un router es Active Router de un

grupo, también puede ser Standby Router de otro grupo .

INTERFACE TRACKING

En ocasiones tendremos la topología que en este caso trataremos y para saber si un router tiene una caída en

una de las interfaces que tienen acceso al Backbone o en este caso a Internet, tendremos que marcarlas con el

tracking para que en caso de fallo sea capaz de disminuir la prioridad y así conseguir que el Standby Router

pase a ser el Active Router. En caso de no configurarlo experimentaremos problemas dado que se caerá la

interfaz pero los hosts intentaran seguir enviando paquetes al gateway que teóricamente funciona. Hay que

manejar los trackings correctamente porque en caso de fallo se restara la cantidad de tracking que indiquemos

a la prioridad. El decremento por defecto es de 10.

Una vez os he dado la barra con el protocolo y sus datos técnicos vamos a lo que interesa. La Topología será

la siguiente :

Empezaremos con las configuraciones :

CONFIGURACIÓN DE R1

R1#conf t

R1(config)#int f0/0.10

R1(config-subif)#standby 10 ip 192.168.10.254 – Esta era la IP del gateway

R1(config-subif)#standby 10 preempt – Configuramos preempt porque en caso de que se levante el Router

queremos que sea de nuevo el Active Router

R1(config-subif)#standby 10 priority 115 - Configuramos priority para que sea Active Router

R1(config-subif)#standby 10 authentication md5 key-chain pass - Configuramos autenticación MD5

porque es más segura que la de texto plano

R1(config-subif)#standby 10 track serial0/0 20 - Configuramos tracking en la interface s0/0 para que en

caso de que se caiga la inerfaz decremente en este caso 20 en la priority y el Active Router pase a se el R2

R1(config-subif)#standby 11 ip 192.168.10.253 – Configuramos la IP de balanceo de carga. Util para redes

con muchos host o trafico

R1(config-subif)#standby 11 preempt

R1(config-subif)#standby 11 priority 100 - Configuramos la default priority porque el grupo 11 del Router

R2 sera el Active para este caso

R1(config-subif)#standby 11 authentication md5 key-chain pass

R1(config-subif)#exit

R1(config-subif)#int f0/0.20

R1(config-subif)#standby 20 ip 192.168.20.254


R1(config-subif)#standby 20 priority 100






R1(config-subif)#standby 21 track serial0/0 20












R1(config)#exit

CONFIGURACIÓN DE R2


































Fijaros que hemos definido para cada grupo 10 , 20 y 30 un grupo de balanceo de carga que seran :

– Para el grupo 10 – 11



Los hosts de la red los configuraremos con los gateways diferentes uno con 192.168.10.254 y el otro

192.168.10.253. Entonces veremos lo siguiente :

PC1 – VLAN 10 – Gateway 192.168.10.253

C:\>ping 1.1.1.1

Haciendo ping a 1.1.1.1 con 32 bytes de datos:

Respuesta desde 1.1.1.1: bytes=32 tiempo=19ms TTL=254




Estadísticas de ping para 1.1.1.1:

Paquetes: enviados = 4, recibidos = 4, perdidos = 0

(0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

Mínimo = 18ms, Máximo = 19ms, Media = 18ms

C:\>arp -a

Interfaz: 192.168.10.200 — 0×10004


192.168.10.1 00-13-80-63-f9-ef dinámico

192.168.10.253 00-00-0c-07-ac-0b dinámico

Podemos ver que el host aprendió mediante ARP que su gateway o Virtual Router es 192.168.10.253 tiene la

mac-address 00-00-0c-07-ac-0b, que pertenece al grupo 11 ( 0b = 11 ) .

C:\>tracert 1.1.1.1

Traza a 1.1.1.1 sobre caminos de 30 saltos como máximo.

1 2 ms <1 ms 1 ms 192.168.10.2

2 26 ms 26 ms 26 ms 1.1.1.1

Traza completa.

En el tracer vemos como realmente vamos al Active Router del grupo 11, que es la 192.168.10.2. Veamos el

resumen de la configuración de HSRP actual y comprobamos que el Active router para el grupo 11 es

el local y el standby es 192.168.10.1 que es R1.

R2#show standby brief

P indicates configured to preempt.

|

Interface Grp Prio P State Active Standby Virtual IP

Fa0/0.10 10 100 P Standby 192.168.10.1 local 192.168.10.254

Fa0/0.10 11 115 P Active local 192.168.10.1 192.168.10.253 Fa0/0.20 20 115 P Active local 192.168.20.1 192.168.20.254



Fa0/0.30 31 115 P Active local 192.168.30.1 192.168.30.253

PC2 – VLAN 10 – Gateway 192.168.10.254

C:\>ping 1.1.1.1

Haciendo ping a 1.1.1.1 con 32 bytes de datos:





Estadísticas de ping para 1.1.1.1:

Paquetes: enviados = 4, recibidos = 4, perdidos = 0

(0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

Mínimo = 18ms, Máximo = 19ms, Media = 18ms

C:\>arp -a

Interfaz: 192.168.10.200 — 0×10004


192.168.10.1 00-13-80-63-f9-ef dinámico

192.168.10.2 00-14-a8-1f-e4-fd dinámico

192.168.10.254 00-00-0c-07-ac-0a dinámico

Podemos ver que el host aprendió mediante ARP que su gateway o Virtual Router es 192.168.10.254 tiene la

mac-address 00-00-0c-07-ac-0a, que pertenece al grupo 10 ( 0a = 10 ) y podemos ver que también ha resuelto

la verdadera ip del Active Router, 192.168.10.1 y el Standby Router que es la 192.168.10.2 .

C:\>tracert 1.1.1.1

Traza a 1.1.1.1 sobre caminos de 30 saltos como máximo.

1 2 ms <1 ms 1 ms 192.168.10.1

2 26 ms 26 ms 26 ms 1.1.1.1

Traza completa.

En el tracer vemos como realmente vamos al Active Router del grupo 10, es la 192.168.10.1. Veamos el

resumen de la configuración de HSRP actual y comprobamos que el Active router para el grupo 10 es

el local y el standby es 192.168.10.2 que es R2.

R1#show standby brief

P indicates configured to preempt.

|

Interface Grp Prio P State Active Standby Virtual IP

Fa0/0.10 10 115 P Active local 192.168.10.2 192.168.10.254 Fa0/0.10 11 100 P Standby 192.168.10.2 local 192.168.10.253


Fa0/0.20 21 115 P Active local 192.168.20.2 192.168.20.253

Fa0/0.30 30 115 P Active local 192.168.30.2 192.168.30.254


VRRP.

Es un protocolo definido por el estándar IEEE, muy parecido al protocolo HSRP, de hecho hay polémica entre

Cisco e IEEE porque Cisco dice que le han copiado la patente. En este caso la IP del router virtual puede ser

una IP real, por lo que si lo configuramos en el perímetro de la red con IPs públicas nos ahorramos una IP

pública. Ante un fallo, el tiempo de no disponibilidad es mucho menor, aproximadamente 3 segundos. Por

ejemplo la siguiente imagen muestra como la gente de Cisco ofrece soluciones de este tipo para un router

virtual (VPN 3000).

Si nos fijamos en lo que hacen los de Nokia con sus Firewall Checkpoint tenemos prácticamente lo mismo, en

este caso lo que se duplica es el Firewall (cada uno con un ISP) pero después los servicios que cuelgan detrás

no están redundados. ¿Cómo funciona este protocolo exactamente? Si nos vamos a la ―interesante‖ RFC 3678

(digo Interesante porque he de confesar que necesito una fuerte necesidad y/ò aburrimiento para ponerme a

leer estas cosas) podemos ver que un dispositivo maestro enviará periódicamente paquetes VRRP a todos los

dispositivos del mismo nivel, es decir podemos redundar 1, 2, 3 y todas las veces que queramos. Los paquetes

VRRP se encapsulan en paquetes IP (seguimos en el nivel 3 de la arquitectura OSI) que son enviados por

multicast, en esa información el Master informa de que está vivo, la prioridad (máximo 255), Interfaz Virtual,

tiempo entre mensajes y los campos habituales de todo paquete IP.

http://es.wikipedia.org/wiki/Modelo_OSI

http://bp1.blogger.com/_aMmOCnP1gUU/SEsifZfDJiI/AAAAAAAAABY/wFCm-PbtUpc/s1600-h/VRRP1.jpg

La teoría nos dice que, en la habitual Alta Disponibilidad con 2 dispositivos 1 estará UP (Master) y el otro

Down (Slave). Si lo pensamos bien eso implicaría tener 1 máquina comprada, pagada, mantenida, etc. sin

sacarle rendimiento alguno en el 99.9% del tiempo (se presupone). ¿Cómo explotar mejor este protocolo,

conseguir Alta Disponibilidad y no tener máquinas ociosas? Esto es lo que en el negocio se llama como Alta

Disponibilidad Activo – Activo, que viene a significar que ambos Firewall se encontrarán trabajando a unos

niveles de carga estimados en un 50%, de esta forma si uno de ellos falla, se colapsa, es atacado o le ocurre

cualquier mal que os podáis imaginar, el otro podrá asumir el servicio sin verse sobrepasado (50 + 50 =

―100‖).

Si bien esta redundancia es virtual en muchos casos (1 Firewall físico, 2 virtuales) suele venir apoyada por un

balanceador que se ocupará de distribuir las peticiones a cada uno de los Firewall. Ni que decir tiene que las

políticas de seguridad deben ser las mismas en ambos dispositivos, ídem con el protocolo de enrutamiento

(RIPv2 es una buena opción).

Ahora bien, si queremos llegar un poco más lejos y especializar estos dispositivos podemos usar el modo

pasivo / activo. Esto es, por defecto ciertos servicios irán a la máquina FW1, y por ejemplo las peticiones al

SQL Server irán al FW2, el balanceador estará configurado de esta forma, en caso de que la petición no esté

http://en.wikipedia.org/wiki/Routing_Information_Protocol

http://bp2.blogger.com/_aMmOCnP1gUU/SEsi0X4457I/AAAAAAAAABg/e8iED0gSPHY/s1600-h/VRRP2.jpg

http://bp3.blogger.com/_aMmOCnP1gUU/SEsjFH7OoNI/AAAAAAAAABo/eJ-7GdhRbLs/s1600-h/VRRP3.jpg

http://bp2.blogger.com/_aMmOCnP1gUU/SEsi0X4457I/AAAAAAAAABg/e8iED0gSPHY/s1600-h/VRRP2.jpg

http://bp3.blogger.com/_aMmOCnP1gUU/SEsjFH7OoNI/AAAAAAAAABo/eJ-7GdhRbLs/s1600-h/VRRP3.jpg

especificada irá alternándose de uno a otro. Ahora bien, ¿y si FW2 falla?, no pasa nada, cuando FW1 se entere

(que será exactamente cuando el tiempo de refresco expire sin novedad) comenzará a asumir las peticiones

SQL Server y –si todo funciona como debería- asumirá la carga de ese servicio (u otros) hasta que FW2 se

recupere, es lo que se llama Firewall Sync, las 2 máquinas conocerán en todo momento como está la otra, se

podrán intercambiar las peticiones según el estado del tráfico, conocerán las rutas de encaminamiento, etc.

etc.

Ni que decir tiene que estas soluciones, si los estudios de rendimiento / capacidad son acertados, desde el

punto de vista de la seguridad pueden ser muy buenas, y del negocio podrá proporcionarnos confianza para

comprometernos con SLAs del 99.9%.

GLBP.

Es un protocolo propietario de Cisco que permite balancear la carga asignando varias direcciones MAC a una

misma IP virtual, esto es posible debido a que existe un router con el rol de AVG (Active Virtual Gateway)

que es el encargado de responder a las solicitudes ARP de los usuarios, AVG responderá con la dirección

MAC de un router AVF (Active Virtual Forwarder) según el algoritmo de balanceo seleccionado.

Ejemplo

Configurando GLBP en el R1.

R1(config)# interface g0/1

R1(config-if)# glbp 1 ip 192.168.1.254

R1(config-if)# glbp 1 preempt

R1(config-if)# glbp 1 priority 150

R1(config-if)# glbp 1 load-balancing round-robin

Configure GLBP en el R3.

R3(config)# interface g0/1

R3(config-if)# glbp 1 ip 192.168.1.254

R3(config-if)# glbp 1 load-balancing round-robin

Verificando GLBP en el R1 y el R3.

R1# show glbp brief

Interface Grp Fwd Pri State Address Active router Standby router

Gi0/1 1 - 150 Active 192.168.1.254 local 192.168.1.3

Gi0/1 1 1 - Active 0007.b400.0101 local -

Gi0/1 1 2 - Listen 0007.b400.0102 192.168.1.3 -

R3# show glbp brief

Interface Grp Fwd Pri State Address Active router Standby router

Gi0/1 1 - 100 Standby 192.168.1.254 192.168.1.1 local

Gi0/1 1 1 - Listen 0007.b400.0101 192.168.1.1 -

Gi0/1 1 2 - Active 0007.b400.0102 local -

NIC.

Network Interface Card (NIC) teaming en Windows Server 2012, es una tecnología que se basa en unir dos o

más NIC´s para dar redundancia aumentando nuestro ancho de banda o garantizar en caso de fallo la total

funcionalidad de la red (―Failover‖) . NIC teaming es también conocido en la industria como ―NIC bonding‖,

―Network Adapter Teaming‖, ―Load Balancing and Failover (LBFO)‖.

VISION GENERAL

Históricamente, el NIC teaming está unido a fabricantes de hardware particulares. Típicamente, estas NICs

unidas son incompatibles con los servicios de Windows Server. Windows Server 2008 R2 solo soporta NIC

teaming con los protocolos de los fabricantes. Windows Server 2012 incorpora NIC teaming también con

protocolos estándar. Los administradores de Windows podrán hacer uso de estas nuevas funcionalidades:

Failover. Si una de nuestras tarjetas de red fallase, de forma totalmente transparente, la otra tarjeta

de red asignada al NIC teaming asumirá el tráfico de red.

Balanceo de Carga. Podemos repartir las cargas del tráfico de la red entre todas las tarjetas de red

unidas al NIC teaming. También se podrá combinar el ancho de banda de varios adaptadores de red

individuales como si se tratase de un único adaptador. Por lo tanto si tuviéramos unidos dos

adaptadores de red de 1 Gbps podríamos disponer de un ancho de banda efectivo de 2 Gbps.

COMO FUNCIONA EL “NIC TEAMING”

Un NIC team se puede considerar como un solo adaptador de red virtual. Por lo tanto, no hay que configurar

los paramentos TCP/IP de los adaptadores del equipo de forma individual, en su lugar, se asigna una dirección

IP a la NIC virtual. El NIC teaming soporta de 2 a 32 adaptadores.

A la hora de crear un NIC team se han de tomar varias decisiones para conectar los adaptadores entre sí.

―Switch independent mode‖: Los adaptadores de este NIC team se pueden conectar a switches

independientes y toda la topología lógica se realiza en la máquina anfitrión Windows Server. La

ventaja de elegir este modo es que el ―failover‖ será transparente para otro adaptador del mismo NIC

team en caso de fallo. Así lo protegeremos de un posible fallo en el switch.

o ―Switch-dependent mode‖: Con este modo, todos nuestros adaptadores del NIC team están

conectados con el mismo switch. Esta configuración (en general) requiere la configuración

del switch asi como la configuración también en Windows Server. Los dos modos de

configuración del switch son los siguientes. ―Generic or static teaming‖. Este modo siempre

requiere una configuración manual para NIC teaming en el switch de destino.

o ―IEEE 802.1ax Link Aggregation Control Protocol (LACP) teaming‖. Este modo configura

dinámicamente el switch de destino del NIC teaming, sin embargo, todavía hará falta una

posible configuración manual en el switch.

Por ultimo necesitaremos decidir el algoritmo de distribución del tráfico de red que se va a asignar a nuestro

NIC team. Estas son los que podremos elegir:

―Address Hashing‖: Este algoritmo toma componentes de la dirección de cada paquete (direccion

MAC, direccion IP, etc.) y calcula los valores hash que se utilizan en el servidor y / o switch para

asignar el tráfico a un adaptador de red en particular.

―Hyper-V switch port.‖ Este algoritmo puede usar las direcciones MAC de las máquinas virtuales

“invitado” para asignar paquetes a interfaces especificas del NIC team. Recordemos que Microsot

Hyper-V se pone al frente de la virtualización de Windows Server 2012 y que podemos crear NIC

teamings tanto físicos como virtuales. Un ejemplo es crear un NIC teaming para uno o más switches

virtuales. Y después de toda la teoría vamos a realizar una configuración del NIC teaming de

Microsoft Windows Server 2012 tanto en interfaz gráfica como por Power Shell 3 en línea de

comandos.

CONFIGURACION DEL NIC TEAMING

Como se menciona anteriormente se puede crear un NIC teaming en Power Shell 3.0 o con el administrador

de servidores.

Mediante el administrador de servidores se deberá cambiar la propiedad de NIC teaming de ―disabled‖ a

―enabled‖.

Figura 1 - Activando un NIC team

A habilitar la opción anterior, aparecerá el siguiente cuadro de dialogo en el que deberemos desplegar el menú

contextual que se muestra en la siguiente imagen, para implementar nuestros adaptadores de red al nuevo NIC

Team.

http://www.windowstecnico.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/windowstecnico/nic1_5F00_09994F1F.jpg

Figura 2- Añadir Adaptadores al NIC team

A continuación aparecerá el cuadro de diálogo que aparece en la siguiente imagen, desde el que podemos

visualizar nuestras tarjetas de red, el nombre del NIC Team y establecer las propiedades del mismo.

http://www.windowstecnico.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/windowstecnico/nic2_5F00_4006AEC9.jpg

Figura 3- Configuración del NIC teaming

Si hacemos clic en el desplegable podremos seleccionar el adaptador de red que permanecerá a la espera para

realizar el Failover NIC team.

http://www.windowstecnico.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/windowstecnico/nic3_5F00_53DFF5C5.jpg

Figura 4 - Failover NIC team

Una vez implementado el NIC team, en la carpeta conexiones de red aparecerá una nueva entrada

―Adaptador de Red de Microsoft Multiplexor‖ como se muestra en la siguiente imagen.

http://www.windowstecnico.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/windowstecnico/nic4_5F00_74570FAA.jpg

Figura 5 - Adaptador de Red de Microsoft Multiplexor.

En este momento se podrá configurar la dirección IP al conjunto de adaptadores del NIC teaming.

NIC TEAMING EN POWER SHELL 3.0

Para crear un NIC teaming con nuestra Power Shell podemos utilizar los siguientes cmdlets:

New-NetLbfoTeam para crear un nuevo NIC teaming

Rename-NetLbfoTeam para renombrar el NIC teaming

Remove-NetLbfoTeam para eliminar el NIC teaming

Get-NetLbfoTeam para un resumen de nuestro NIC teaming.

Podéis encontrar toda la documentación con los cmdlets aquí.

http://technet.microsoft.com/en-us/library/jj130849.aspx

http://www.windowstecnico.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/windowstecnico/nic5_5F00_755BD2FC.jpg

Figura 6 - NIC teaming en Power Shell 3.0

http://www.windowstecnico.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/windowstecnico/nic6_5F00_2C090834.jpg

Date post:	03-Feb-2016
Category:	Documents
Upload:	cristian-israel-condori-paiva
View:	225 times
Download:	0 times

Protocol Os

Documents