Mostrando las entradas con la etiqueta redes. Mostrar todas las entradas
Mostrando las entradas con la etiqueta redes. Mostrar todas las entradas

viernes, 23 de enero de 2009

La comunicación es un asunto de capas

¿Alguna vez has tratado de entender cómo es ese asunto de las capas del modelo OSI o del conjunto de protocolos TCP/IP? Algunos maestros, en lugar de ayudar a comprenderlo sólo lograron confundir a más de cuatro, estoy seguro. Y al final sigue quedando la gran incógnita: ¿qué función tienen las capas en un modelo como OSI o TCP/IP? Esto lo escucho una y otra vez cada vez que doy un curso de redes y en realidad es algo muy simple. La gente encargada de definir el modelo pensó en una manera de representar que dentro de una comunicación intervienen una serie de elementos que, si bien son diferentes entre sí, se interrelacionan de una manera tal que pueden conseguir que una transmisión de datos se lleve a cabo. El concepto de capas es simplemente una forma de representar la individualidad de cada tarea en la comunicación y cómo se relaciona con otras tareas para lograr una colaboración de todo el conjunto.

En esta ocasión, como estoy de buen humor (como casi siempre ;)), les voy a platicar una alegoría para intentar explicar un aspecto fundamental en las comunicaciones entre dos equipos en una red de datos que usa TCP/IP. Después de contar la historia, trataré de aplicarla al concepto de comunicación del que estamos hablando, tengan paciencia.

La capa de Aplicación, en el origen
Yo vivo en Monterrey, México, y tengo un amigo, Guillermo Alegría (la versión mexicana de Bill Joy :D), que vive en la Ciudad de México. Mi amigo me ha pedido ayuda porque quiere aprender UNIX, así que pensé en enviarle unos manuales que tengo por ahí guardados.

La capa de Transporte, en el origen
Como son varios libros y quiero asegurarme de que mi amigo los reciba, he pensado que la mejor manera de enviarlos será uno a la vez, y una vez que tenga la confirmación de que recibió el primer libro, le envío el segundo y así sucesivamente (soy un poco desconfiado, por eso mejor me aseguro de que los va recibiendo, uno a la vez). Para que no se maltraten, envuelvo cada libro en un paquete.

La capa de Internet, en el origen
Por supuesto que para enviar un paquete necesito escribir el nombre y la dirección de Guillermo, y también la mía en caso de que mi amigo ya no viviera en ese domicilio y tuvieran que devolverme el paquete (no puedo darme el lujo de perder un libro de UNIX). Mi amigo vive en la célebre calle Chopo, en el número ocho, y así lo escribo en el paquete.

La capa de Enlace de Datos, en el origen
Llego a la empresa de mensajería, una de confianza. El encargado observa el paquete y me pregunta por qué medio quiero enviarlo: "¿Por avión o por carretera?" -me pregunta. Me interesa que mi amigo comience a estudiar cuanto antes, pero no tanto como para pagar la diferencia de un envío aéreo. "Por carretera" -le respondo.

El medio físico
Y ahí va el libro, viajando por carretera hasta la Ciudad de México. Diez horas de camino. En México encuentran mucho tráfico, como siempre, lo que retrasa el envío dos horas más. Ni hablar, todo sea en aras del saber.

La capa de Enlace de Datos, en el destino
Al fin la camioneta de reparto llega a Chopo 8, se aseguran de estar en el domicilio indicado y tocan el timbre. Mi amigo abre la puerta y se alegra de recibir el envío. A simple vista el paquete parece estar en buenas condiciones, de lo contrario, si llegara abierto por ejemplo, no lo aceptaría y me sería devuelto, o posiblemente sí lo recibiría, haciendo la observación pertinente al que lo entrega.

La capa de Internet, en el destino
Le preguntan a mi amigo: "¿Es usted Guillermo Alegría?", y él responde afirmativamente, por supuesto, y le entregan el paquete.

La capa de Transporte, en el destino
Le dan a firmar un acuse de recibo, porque recuerden que yo quería asegurarme de que recibiera el paquete, así que pedí que por cada paquete que él recibiera, firmara un recibo indicando que efectivamente tenía ya en su poder el paquete, así yo sabría que podría enviar el siguiente libro con mayor confianza. Mi amigo ya no puede esperar, le quita la envoltura al libro y observa que es el volumen 1, lo que quiere decir que seguramente deberá esperar más libros como ese. Si en el siguiente envío yo le mandara el volumen 3, seguramente él me mandaría a avisar que le faltó el volumen 2 y que no puede saltarse del 1 al 3, que necesita el 2. Al menos eso haría yo.

La capa de Aplicación, en el destino
Sentado cómodamente en su sillón, con un refresco y unas frituras, mi amigo Memo (es que así le decimos en México a los que se llaman Guillermo) se dispone a leer el libro de UNIX y se da cuenta de que podrá hacer muchas cosas ahora que aprenda a usarlo. Sólo espero que un día de éstos no me diga que ejecutó "rm -r /", siendo root. ;-)

¿Y qué tiene que ver esto con TCP/IP?
Mucho. TCP/IP es un conjunto de protocolos (reglas de comunicación) que tienen su propia función y que en conjunto pueden llevar a cabo la comunicación entre, al menos, dos dispositivos en una red. La división en capas nos ayuda a entender que en la capa de Aplicación se preparan los datos que serán enviados desde una Aplicación X a una Aplicación Y en otro dispositivo; como los datos que se envían seguramente son muchos, la capa de Transporte puede segmentar dichos datos en segmentos o datagramas que sean más fáciles de enviar, por tener un tamaño más manejable para los dispositivos de red. Como posiblemente sean varios segmentos de datos, se enumeran para que, una vez que lleguen a su destino, el destinatario (el que los recibe) sepa que han llegado todos los datos o si tal vez faltó alguno para pedir que se envíe nuevamente. Ahora bien, ninguna comunicación confiable será completa si no hay un adecuado direccionamiento, o si no se conoce el domicilio o dirección de quien recibirá los datos, y es precisamente la capa de Internet la encargada de identificar en cada paquete de datos la dirección de quien envía y de quien recibirá dichos datos. Una vez que ya se tienen listos los datos, en la capa de Enlace de Datos se prepara una trama (frame) para que los datos puedan ser enviados por algún medio físico, usando un cable, por ejemplo, o a través de ondas por el aire. Como cada medio es diferente y exige diferentes tipos de controles, las tramas se preparan para cada medio en particular, de acuerdo a los estándares.

Cuando los datos llegan al destinatario ocurre la operación contraria, pues las tramas llegan por un medio físico, y cada protocolo de cada capa va tomando la información que requiere de su contraparte que envió los datos. Por ejemplo, la capa de Enlace de Datos se asegura de que la trama realmente vaya dirigida a ese dispositivo físico de la red y pasa el paquete a la capa de Internet para que haga lo mismo; en la capa de Internet se verifica que la dirección de destino sea efectivamente la actual y se pasa a la capa de Transporte para que verifique a su vez que el segmento forma parte de la secuencia esperada y, en muchos casos, preparar una confirmación de haber recibido los datos, para que se envíen más. Al final, los datos son colocados en orden y pasados a la capa de Aplicación, que hará que sean presentados o recibidos por la Aplicación Y de una manera legible, ya sin todo el "empaque" que se colocó en los datos al ser enviados.

Obviamente esta es una explicación muy simplificada de lo que realmente ocurre. No hablé, por ejemplo, del famoso three-way handshake para TCP, por ejemplo, ni de otras características igualmente importantes, pero para eso hay muy buenos libros y otros recursos de consulta. Este es solamente mi sencilla aportación para tratar de explicar algo como a mi me hubiera gustado que me lo explicaran.

Fin de la transmisión.

:wq!

jueves, 17 de abril de 2008

¿'Networker' o 'Programmer'? ...esa es la cuestión

Esta semana di un seminario de Java, enfocado a demostrar cómo utilizar la tecnología Java para comunicar dos programas en una arquitectura cliente-servidor utilizando Sockets de TCP/IP. El tema en sí es interesante, desde mi punto de vista, y más porque tuve que explicar un poco sobre cómo ocurre la comunicación entre dos equipos en una red, por TCP/IP, antes de mostrar (y demostrar) el código Java de los programas cliente y servidor, para lograr que se comunicaran. Fue un seminario interesante, especialmente porque el tema era nuevo para muchos, y eso es lo que lo hace interesante.

Al final alguien me preguntó qué era más difícil aprender: redes o programación. Es una pregunta difícil, pues hablamos de dos áreas que, aunque relacionadas por la tecnología, son muy distintas entre sí. En primer lugar, porque las redes de computadoras se basan en tecnologías de comunicación que requieren varias disciplinas de las ciencias, mientras que la programación requiere una habilidad muy particular para idear la lógica que permita la ejecución correcta de los algoritmos necesarios para lograr algo. En sí el trabajo con redes requiere implementar una serie de principios ya probados y que funcionan prácticamente por sí solos mientras se cumplan las condiciones requeridas, tal es el caso de los protocolos de red, o de las tecnologías de interconexión que ya se han estandarizado. Pero programar es un arte, un arte que precisa imaginación, habilidad para resolver un problema de la manera más simple y eficiente posible y plasmarlo en un código comprensible para una computadora; programar es crear, es inventar. En resumen, son disciplinas muy distintas entre sí.

Semanas atrás un amigo me pedía mi recomendación para que le dijera qué curso le convenía tomar: uno de redes o uno de programación. Mi respuesta fue: "aprende lo que te guste hacer más". Al final decidió tomar el de programación, y espero que le esté yendo bien. Los últimos años he estado dando cursos de capacitación en programación en Java y cursos de redes (networking) con equipos Cisco, específicamente para aquellos que quieren certificarse como CCNA, y son definitivamente mundos distintos.

Yo comencé programando a la edad de 12 años, ya lo había comentado anteriormente, con una computadora Timex Sinclair y una Radio Shack de bolsillo que me dio mi tío Israel. Mi tío me regaló también mi primer libro de programación y con ese libro aprendí (en otra ocasión contaré la anécdota). Años después conocí acerca de las redes para transmisión de datos, de protocolos y tecnologías de redes, pero como dicen por ahí: "nadie puede negar su origen".

¿Entonces qué soy?, ¿networker o programmer? Un poco de todo, creo yo.

:wq!

martes, 12 de febrero de 2008

Conjugando el inexistente verbo "subnetear" (Episodio II)

Hay dos razones por las que he decidido dar continuación al tema de la obtención de sub-redes (subnetear, pues, para los que insisten): una es la creciente cantidad de referencias de búsquedas que he visto desde Google hasta este blog, referentes a "subnetear" o "subredes"; y otra es por pedido específico de una lectora que recientemente pidió que ejemplificara el caso para una red de clase A y otro de clase B. Pues bien, en esta segunda parte explicaré el procedimiento con una red de clase B (posiblemente haga una tercera parte con un ejemplo de clase A, dependiendo del interés).

Ok, partamos de un caso concreto: tenemos la red 150.14.0.0/16. Hay que recordar que el sufijo /16 indica que los bits que representan la máscara de sub-red (que para las redes clase B, antes de ser "subneteadas", siempre es 16 o sea, 2 octetos de 8 bits). En una red de esta clase (clase B), la cantidad de hosts está determinada por los 16 bits restantes de la parte de hosts, por lo que 216-2=65,534 hosts posibles... ni hablar del desperdicio de direcciones.

Nuestra máscara /16, que en decimal es lo mismo que 255.255.0.0, se representa en binario de la siguiente manera.

11111111.11111111.00000000.00000000
<-------------red*host------------>

Ahora la parte crucial: ¿cómo comenzar a dividir la red? Simple: debemos partir de una necesidad: ¿qué requerimos?, ¿cierta cantidad de redes o cierta cantidad de direcciones de host por red? Tal vez son ambas cosas. En este ejemplo supondremos que el requerimiento es obtener de la dirección dada por lo menos 500 sub-redes con capacidad para 100 hosts cada una. Vamos a aplicar una sencilla regla para determinar cuántos bits necesitamos pedir (recuerden que no es un préstamo, sino un obsequio :-D):

Como necesitamos que haya 500 sub-redes, necesitamos encontrar un número tal que elevando la base 2 a dicho número nos de la cantidad de sub-redes necesaria, o un poco más. Como ya lo mencioné anteriormente, podemos obtener la potencia por aproximación (al "ojo por ciento") o usando logaritmos. Al final puse una breve explicación de ambos procedimientos, para quien tenga interés.

Lo importante es que obtuvimos el número que buscamos: 9 bits. Con 9 bits podemos obtener 512 combinaciones, lo que nos da alegremente la posibilidad de obtener tranquilamente las 500 sub-redes que nos piden. Ahora sólo nos resta verificar que cada sub-red (de las 512) pueda efectivamente incluir al menos 100 hosts. Para esto basta con obtener la cantidad de combinaciones que nos dan los bits restantes. Recuerda que una dirección IP está formada por 32 bits, y para nuestro caso 16 bits ya están siendo usados por la dirección clase B, y 9 bits son los que acabamos de calcular que necesitamos para obtener las 512 sub-redes. Así que, si la aritmética no nos falla, nos quedan 7 bits para obtener direcciones de hosts (sí, mira: 32-16-9=7). Con 7 posiciones podemos obtener 128 combinaciones de "0" y "1" (bits), y aún restándole las 2 direcciones de ley (al total de direcciones de hosts siempre restamos dos, porque una será la dirección de la sub-red y otra será la dirección de broadcast) nos da un número (126) que nos permite cumplir, también tranquilamente, con el requerimiento de 100 direcciones. Con "bolitas y palitos" (literalmente) queda de la siguiente manera:

11111111.11111111.11111111.10000000
<--red original--><-subred->
<--nueva máscara de subred->
11111111.11111111.11111111.10000000

Y esta nueva máscara de sub-red en decimal sería: 255.255.255.128 (él último octeto sólo tiene un bit 1 en la posición más significativa, y es el número 128).

Lo interesante de este caso es obtener las direcciones de sub-red, pues hay que observar que los bits de sub-redes abarcan dos octetos (9 bits). No se asusten, no pondré las 512. Voy a poner sólo las primeras combinaciones de sub-redes para los dos últimos octetos. Así tenemos:

00000000.00000000 (es decir, 0.0)
00000000.10000000 (es decir, 0.128)
00000001.00000000 (es decir, 1.0)
00000001.10000000 (es decir, 1.128)
00000010.00000000 (es decir, 2.0)
00000010.10000000 (es decir, 2.128)

Quiero hacer notar una cosa: el bit menos significativo de la nueva máscara es precisamente el que está en la posición 128 del cuarto octeto (y, por cierto, 128 es el número que resulta de 27, antes de restarle 2). Si lo que queremos es obtener más rápido las direcciones de red (¿quién no quiere?), puede hacerse con incrementos de 128 (el bit menos significativo de la máscara) en el octeto correspondiente. Sólo que hay un detalle: comenzamos con 0 (cero), luego sumamos 128, pero si sumamos 128 a 128 nos da 256, que no puede expresarse con sólo 8 bits (256=100000000, 9 bits). Lo que hacemos es exactamente lo mismo que con las horas y minutos del reloj: después de 59 minutos se incrementa en 1 la hora, y los minutos quedan en cero; por lo tanto, si tenemos 0.128, el siguiente número NO es 0.256, sino 1.0. ¿Está claro?

Ahora sí, poniendo las direcciones completas, quedarían:

150.14.0.0/25
150.14.0.128/25
150.14.1.0/25
150.14.1.128/25
150.14.2.0/25
150.14.2.128/25
etc.

"¡Espera! ¿De dónde salió el '/25'?". Originalmente teníamos 16 bits en la parte de la red, pero como pedimos 9 bits a la parte de hosts, sumando 16 mas 9 nos quedan ni más ni menos que 25 bits, por eso la nueva máscara es /25.

Muy bien, hasta este momento hemos obtenido las combinaciones de sub-redes. Ahora necesitamos obtener las direcciones de host para cada una de las sub-redes obtenidas. Eso es fácil. Hagámoslo primero en binario. Para cada sub-red vamos a calcular su dirección de broadcast:

00000000.01111111 (este es 0.127)
00000000.11111111 (este es 0.255)
00000001.01111111 (este es 1.127)
00000001.11111111 (este es 1.255)
00000010.01111111 (este es 2.127)
00000010.11111111 (este es 2.255)
etc.

No hay que olvidar la regla: "las direcciones de red tienen todos los bits de host en cero (0), y las direcciones de broadcast tienen todos los bits de host en uno (1)".

De esta manera, obtener los rangos de direcciones de host válidas es mucho más sencillo, pues la primera dirección válida será una más que la dirección de red, y la última dirección válida será una menos que la dirección de broadcast. Sencillo, ¿no?

Para la sub-red 150.14.0.0/25
150.14.0.0/25 (dirección de red)
150.14.0.1/25 (primera dirección de host válida)
150.14.0.126/25 (última dirección de host válida)
150.14.0.127/25 (dirección de broadcast)

Para la sub-red 150.14.0.128/25
150.14.0.128/25 (dirección de red)
150.14.0.129/25 (primera dirección de host válida)
150.14.0.254/25 (última dirección de host válida)
150.14.0.255/25 (dirección de broadcast)

Para la sub-red 150.14.1.0/25
150.14.1.0/25 (dirección de red)
150.14.1.1/25 (primera dirección de host válida)
150.14.1.126/25 (última dirección de host válida)
150.14.1.127/25 (dirección de broadcast)

Si observan, la cantidad de direcciones entre la primera y la última válida son exactamente las 128 que dijimos (aunque sólo necesitamos 100, pero no es lo mismo "desperdiciar" 28 que 15,000).

Y con esto hemos terminado de "subnetear" la red de clase B (¡perdón!, la palabra "subnetear" sigue sin existir en español) sin desperdiciar muchas direcciones.

(Ningún bit salió lastimado durante esta división de sub-redes).
:-D


:wq!







Procedimiento usando logaritmos


Me voy a permitir hacer un pequeño recordatorio matemático y pondré el procedimiento para obtener la potencia usando logaritmos:

Sabemos que:
x=bn

y que:
n=logbx

Si la base (b) fuera 10, obtener n con la calculadora es directo. El problema con una calculadora sería obtener n siendo la base (b) diferente de 10, como en nuestro caso que es 2. Para esto podemos usar la siguiente identidad:

log2 x=(log x)/(log 2)

De tal manera que la fórmula quedaría:
n=(log x)/(log 2)

Sustituyendo:
n=(log x)/(log 2) = (log 500)/(log 2)
n=2.7/0.3
n=9

Porque:
29=512

El resultado indica que necesitamos 9 bits para obtener las sub-redes. Este procedimiento es el más complejo y requiere usar calculadora o tablas de logaritmos, pero sirve por lo menos para impresionar a más de dos. ;-) Esto me recuerda lo que decía mi maestro de Ecuaciones Diferenciales, cuando nos motivaba a comprar el libro de texto. Él decía: "muchachos: compren el libro. Les aseguro que si no aprenden, por lo menos podrán impresionar a las muchachas con el puro título". :-D ¡Cuánta razón tenía!.

Procedimiento por aproximación

Perdón por haber puesto el procedimiento anterior, pero varios se habían quedado con la duda de cómo se resolvía por logaritmos, si es que realmente se podía. La realidad es que muchos de los que regularmente calculan sub-redes no usan ese procedimiento (y muchos ni siquiera lo conocen). Mejor hagámoslo de la manera tradicional, aunque no se vea tan nerd.

Si lo que necesitamos es un número al que podamos elevar (potencia) el 2 (la base) para que nos dé 500 redes, yéndonos por potencias de 2 podemos encontrarlo relativamente rápido:

n=9, pues
29=512 (porque 2*2*2*2*2*2*2*2*2=512)

El "secreto" es ir multiplicando 2*2, llevando la cuenta de cuántos "2" llevas, hasta que encuentres el número que buscas... ;) Este procedimiento es más práctico que el anterior; tal vez no impresiones a nadie (o ¿quién sabe?), pero al menos llegarás rápido al número que necesitas. ;-)

:wq!

jueves, 22 de febrero de 2007

Conjugando el inexistente verbo "subnetear"

[Actualización, 12 de febrero de 2008: He publicado un ejemplo del procedimiento mostrado a continuación, ligeramente más detallado, pero para una red Clase B en esta entrada. Espero que sea de utilidad.]

Debido a numerosas preguntas que he recibido acerca de cómo dividir una red TCP/IP en sub-redes (¿tan mal maestro soy?), he decidido poner un ejemplo paso a paso para hacerlo con una red de clase C. Les advierto que lo que van a leer a continuación (si es que deciden continuar leyendo) requiere un conocimiento previo de conceptos como red, máscara de sub-red, dirección IP, VLSM y CIDR, etc. y no es apto para cardíacos... :-D

Supongamos que tenemos la red 192.16.3.0/24. El /24 es notación CIDR y representa a una máscara de 24 bits ( 255.255.255.0 ). En esta red nos quedan 8 bits en la parte de hosts, así que tenemos (28)-2 posibles combinaciones, es decir, 256-2 = 254 hosts. Esto puede ser un gran desperdicio de direcciones, por esta razón se nos pide dividirla.

La máscara /24 en binario, es tan fácil como 24 bits "1" consecutivos, y el resto "0"s:

255.255.255.0
11111111.11111111.11111111.00000000
<--------------------- red*host--->

Supongamos que, para no desperdiciar la red, nos piden obtener sub-redes con capacidad para 50 hosts cada una. Para dividir la red, necesitamos pedir "prestados" (aunque en realidad son "regalados", porque nunca los devolvemos ;)) los bits necesarios para obtener las sub-redes que tengan capacidad para los 50 hosts que necesitamos por cada sub-red. Así tenemos:

El número de hosts por sub-red debe ser mayor o igual que 50:
2n-2 >= 50
Al buscar 'n', "sabemos" que (26)-2=64-2=62, por lo tanto 6 bits de hosts nos cubren muy bien los 50 que necesitamos. Si n fuera 5, 25=32, y 32 no nos alcanzan para los 50. ¿de acuerdo? (Hay un procedimiento para obtener 'n' usando logaritmos, pero como son ingenieros sé que ya se lo saben, así que ya no lo pongo).

Bueno, como ahora sabemos que necesitamos 6 bits de hosts para cubrir los 50 y en la máscara original (/24) nos sobraban 8 bits, eso quiere decir que para las nuevas sub-redes tendremos sólo 2 bits, de esta manera:

255.255.255.192
11111111.11111111.11111111.11000000
<------------------------red*host->

(la máscara es ahora de 26 bits, o sea, /26 en CIDR, porque a los 24 originales le sumamos los 2 que nos regalaron).

(el número binario 11000000 es el 192 decimal).
¿Notas que al principio del último octeto puse los 2 bits "1" que dijimos?

Hasta este punto hemos determinado la cantidad de bits que vamos a usar para crear nuevas sub-redes con hasta 62 hosts cada una (recuerda que nos pidieron 50).

Ahora viene lo bueno: necesitamos saber las direcciones de red de las nuevas sub-redes. Para esto voy a concentrarme únicamente en los 2 bits que me regalaron del último octeto, para sacar las posibles combinaciones:

.00000000 (este es el 0 decimal)
.01000000 (este es el 64 decimal)
.10000000 (este es el 128 decimal)
.11000000 (este es el 192 decimal)
^^

Por lo tanto, las nuevas direcciones de red serán:

192.16.3.0/26
192.16.3.64/26
192.16.3.128/26
192.16.3.192/26

Fácil, ¿no? Ahora sólo nos resta conocer, para cada nueva sub-red, las direcciones de hosts válidas.

Ahora prepárense para la siguiente definición: La primera dirección obtenida de una sub-red es la propia dirección de la sub-red (ya sé, se oyó muy cantinflesco, pero así es), y son justamente las que acabamos de obtener. Ahora bien, la última dirección de una sub-red es la dirección de broadcast, y corresponde a poner todos los bits de host en "1":

.00111111 (este es el 63 decimal)
.01111111 (este es el 127 decimal)
.10111111 (este es el 191 decimal)
.11111111 (este es el 255 decimal)
^^


Aquí hay que ser muy observadores: fíjate que los primeros 2 bits están exactamente igual que en las combinaciones que usamos para sacar las direcciones de red. Lo único que cambié fueron los últimos 6 bits "0" por "1", y ya tenemos las direcciones de broadcast para cada sub-red.

Por lo tanto, lo que necesitamos ahora es obtener las direcciones que nos quedan para hosts en cada una de las sub-redes obtenidas:

sub-red 1
192.16.3.0/26 (dirección de red)
192.16.3.63/26 (dirección de broadcast)
192.16.3.1/26 hasta 192.16.3.62/26 (rango de direcciones para host: son 62)

sub-red 2
192.16.3.64/26
192.16.3.127/26 (dirección de broadcast)
192.16.3.65/26 hasta 192.16.3.126/26 (rango de direcciones para host: son 62)

sub-red 3
192.16.3.128/26
192.16.3.191/26 (dirección de broadcast)
192.16.3.129/26 hasta 192.16.3.190/26 (rango de direcciones para host: son 62)

sub-red 4
192.16.3.192/26
192.16.3.255/26 (dirección de broadcast)
192.16.3.193/26 hasta 192.16.3.254/26 (rango de direcciones para host: son 62)

Y eso es todo. Hay que poner mucha atención en las máscaras usadas para no confundirse y recuerden: el verbo "subnetear" no existe. ;-)

:wq!

Actualización, 12 de febrero de 2008: He publicado un ejemplo del procedimiento ligeramente más detallado, pero para una red Clase B en esta entrada. Espero que sea de utilidad.