/home/blaster [ Blaster's blog ]

Archive for the ‘redes’ Category

Hub

Un HUB tal como dice su nombre es un concentrador. Simplemente une conexiones y no altera las tramas que le llegan. Para entender como funciona veamos paso a paso lo que sucede (aproximadamente) cuando llega una trama.

Visto lo anterior podemos sacar las siguientes conclusiones:

1 - El HUB envía información a ordenadores que no están interesados. A este nivel sólo hay un destinatario de la información, pero para asegurarse de que la recibe el HUB envía la información a todos los ordenadores que están conectados a él, así seguro que acierta.

2 - Este tráfico añadido genera más probabilidades de colisión. Una colisión se produce cuando un ordenador quiere enviar información y emite de forma simultánea que otro ordenador que hace lo mismo. Al chocar los dos mensajes se pierden y es necesario retransmitir. Además, a medida que añadimos ordenadores a la red también aumentan las probabilidades de colisión.

3 - Un HUB funciona a la velocidad del dispositivo más lento de la red. Si observamos cómo funciona vemos que el HUB no tiene capacidad de almacenar nada. Por lo tanto si un ordenador que emite a 100 megabit le trasmitiera a otro de 10 megabit algo se perdería el mensaje. En el caso del ADSL los routers suelen funcionar a 10 megabit, si lo conectamos a nuestra red casera, toda la red funcionará a 10, aunque nuestras tarjetas sean 10/100.

4 - Un HUB es un dispositivo simple, esto influye en dos características. El precio es baratito. El retardo, un HUB casi no añade ningún retardo a los mensajes.

Switch

Cuando hablamos de un switch lo haremos refiriéndonos a uno de nivel 2, es decir, perteneciente a la capa “Enlace de datos”. Normalmente un switch de este tipo no tiene ningún tipo de gestión, es decir, no se puede acceder a él. Sólo algunos switch tienen algún tipo de gestión pero suele ser algo muy simple. Veamos cómo funciona un “switch”.

Puntos que observamos del funcionamiento de los “switch”:

1 - El “switch” conoce los ordenadores que tiene conectados a cada uno de sus puertos (enchufes). Cuando en la especificación del un “switch” leemos algo como “8k MAC address table” se refiere a la memoria que el “switch” destina a almacenar las direcciones. Un “switch” cuando se enchufa no conoce las direcciones de los ordenadores de sus puertos, las aprende a medida que circula información a través de él. Con 8k hay más que suficiente. Por cierto, cuando un “switch” no conoce la dirección MAC de destino envía la trama por todos sus puertos, al igual que un HUB (“Flooding”, inundación). Cuando hay más de un ordenador conectado a un puerto de un “switch” este aprende sus direcciones MAC y cuando se envían información entre ellos no la propaga al resto de la red, a esto se llama filtrado.

El tráfico entre A y B no llega a C. Como decía, esto es el filtrado. Las colisiones que se producen entre A y B tampoco afectan a C. A cada parte de una red separada por un “switch” se le llama segmento.

2 - El “switch” almacena la trama antes de reenviarla. A este método se llama “store & forward”, es decir “almacenar y enviar”. Hay otros métodos como por ejemplo “Cut-through” que consiste en recibir los 6 primeros bytes de una trama que contienen la dirección MAC y a partir de aquí ya empezar a enviar al destinatario. “Cut-through” no permite descartar paquetes defectuosos. Un “switch” de tipo “store & forward” controla el CRC de las tramas para comprobar que no tengan error, en caso de ser una trama defectuosa la descarta y ahorra tráfico innecesario. El “store & forward” también permite adaptar velocidades de distintos dispositivos de una forma más cómoda, ya que la memoria interna del “switch” sirve de “buffer”. Obviamente si se envía mucha información de un dispositivo rápido a otro lento otra capa superior se encargará de reducir la velocidad.

Finalmente comentar que hay otro método llamado “Fragment-free” que consiste en recibir los primeros 64 bytes de una trama porque es en estos donde se producen la mayoría de colisiones y errores. Así pues cuando vemos que un “switch” tiene 512KB de RAM es para realizar el “store & forward”. Esta RAM suele estar compartida entre todos los puertos, aunque hay modelos que dedican un trozo a cada puerto.

3 - Un “switch” moderno también suele tener lo que se llama “Auto-Negotation”, es decir, negocia con los dispositivos que se conectan a él la velocidad de funcionamiento, 10 megabit ó 100, así como si se funcionara en modo “full-duplex” o “half-duplex”. “Full-duplex” se refiere a que el dispositivo es capaz de enviar y recibir información de forma simultánea, “half-duplex” por otro lado sólo permite enviar o recibir información, pero no a la vez.

4 - Velocidad de proceso: todo lo anterior explicado requiere que el “switch” tenga un procesador y claro, debe ser lo más rápido posible. También hay un parámetro conocido como “back-plane” o plano trasero que define el ancho de banda máximo que soporta un “switch”. El “back plane” dependerá del procesador, del número de tramas que sea capaz de procesar. Si hacemos números vemos lo siguiente: 100megabits x 2 (cada puerto puede enviar 100 megabit y enviar 100 más en modo “full-duplex”) x 8 puertos = 1,6 gigabit. Así pues, un “switch” de 8 puertos debe tener un “back-plane” de 1,6 gigabit para ir bien. Lo que sucede es que para abaratar costes esto se reduce ya que es muy improbable que se produzca la situación de tener los 8 puertos enviando a tope… Pero la probabilidad a veces no es cierta wink.gif

5 - Si un nodo puede tener varias rutas alternativas para llegar a otro un “switch” tiene problemas para aprender su dirección ya que aparecerá en dos de sus entradas. A esto se le llama “loop” y suele haber una lucecita destinada a eso delante de los “switch”. El protocolo de Spanning Tree Protocol IEEE 802.1d se encarga de solucionar este problema, aunque los “switch” domésticos no suelen tenerlo… No hagáis redondas…

Router
Un router (en español enrutador o encaminador) es un dispositivo hardware o software de interconexión de redes de computadoras que opera en la capa tres (nivel de red) del modelo OSI. Este dispositivo interconecta segmentos de red o redes enteras. Hace pasar paquetes de datos entre redes tomando como base la información de la capa de red.

El router toma decisiones lógicas con respecto a la mejor ruta para el envío de datos a través de una red interconectada y luego dirige los paquetes hacia el segmento y el puerto de salida adecuados. Sus decisiones se basan en diversos parámetros. Una de las más importantes es decidir la dirección de la red hacia la que va destinado el paquete (En el caso del protocolo IP esta sería la dirección IP). Otras decisiones son la carga de tráfico de red en las distintas interfaces de red del router y establecer la velocidad de cada uno de ellos, dependiendo del protocolo que se utilice.

En el ejemplo del diagrama, se muestran 3 redes IP interconectadas por 2 routers. La computadora con el IP 222.22.22.1 envía 2 paquetes, uno para la computadora 123.45.67.9 y otro para 111.11.11.1 A través de sus tablas de enrutamiento configurados previamente, los routers pasan los paquetes para la red o router con el rango de direcciones que corresponde al destino del paquete. Nota: el contenido de las tablas de rutas está simplificado por motivos didácticos. En realidad se utilizan máscaras de red para definir las subredes interconectadas.

Los broadcast, o difusiones, se producen cuando una fuente envía datos a todos los dipositivos de una red. En el caso del protocolo IP, una dirección de broadcast es una dirección compuesta exclusivamente por números unos (1) en el campo del host (para la dirección ip en formato binario de modo que para una máscara de red 255.255.255.0 la dirección de broadcast para la dirección 192.168.0.1 seria la 192.168.0.255 o sea xxxxxxxx.xxxxxxxx.xxxxxxxx.11111111). Los protocolos de enrutamiento son aquellos protocolos que utilizan los routers o encaminadores para comunicarse entre sí y compartir información que les permita tomar la decisión de cual es la ruta más adecuada en cada momento para enviar un paquete. Los protocolos más usados son RIP (v1 y v2), OSPF (v1, v2 y v3), y BGP (v4), que se encargan de gestionar las rutas de una forma dinámica. aunque no es estrictamente necesario que un router haga uso de estos protocolos, pudiéndosele indicar de forma estática las rutas (caminos a seguir) para las distintas subredes que estén conectadas al dispositivo. Comúnmente los routers se implementan también como puertas de acceso a Internet (por ejemplo un router ADSL), usándose normalmente en casas y oficinas pequeñas. Es correcto utilizar el término router en este caso, ya que estos dispositivos unen dos redes (una red de área local con Internet). Existe la posibilidad de no utilizar equipos dedicados, opción que puede ser la más adecuada para redes locales o redes con un tráfico limitado, y usar software que implemente los protocolos de red antes mencionados. Para dar funcionalidad de router a un PC con los sistemas operativos GNU/Linux o BSD es suficiente con añadirle al menos dos interfaces de red y activar el soporte de enrutamiento en el kernel.

Donde usar Switch?

Uno de los principales factores que determinan el exito del diseño de una red, es la
habilidad de la red para proporcionar una satisfactoria interacción entre cliente/servidor, pues los usuarios juzgan la red por la rápidez de obtener un prompt y la confiabilidad del servicio.
Hay diversos factores que involucran el incremento de ancho de banda en una LAN:
•El elevado incremento de nodos en la red.
•El continuo desarrollo de procesadores mas rápidos y poderosos en estaciones de
trabajo y servidores.
•La necesidad inmediata de un nuevo tipo de ancho de banda para aplicaciones
intensivas cliente/servidor.
•Cultivar la tendencia hacia el desarrollo de granjas centralizadas de servidores para
facilitar la administración y reducir el número total de servidores.
La regla tradicional 80/20 del diseño de redes, donde el 80% del tráfico en una LAN
permanece local, se invierte con el uso del switch.
Los switches resuelven los problemas de anchos de banda al segmentar un dominio de colisiones de una LAN, en pequeños dominios de colisiones.
En la figura la segmentación casí elimina el concurso por el medio y da a cada estación final más ancho de banda en la LAN.

Donde usar un ruteador?

Las funciones primarias de un ruteador son:
•Segmentar la red dentro de dominios individuales de brodcast.
•Suministrar un envio inteligente de paquetes. Y
•Soportar rutas redundantes en la red.
Aislar el tráfico de la red ayuda a diagnosticar problemas, puesto que cada puerto del ruteador es una subred separada, el tráfico de los brodcast no pasaran a través del ruteador.
Otros importantes beneficios del ruteador son:
•Proporcionar seguridad a través de sotisficados filtros de paquetes, en ambiente
LAN y WAN.
•Consolidar el legado de las redes de mainframe IBM, con redes basadas en PCs a
través del uso de Data Link Switching (DLSw).
•Permitir diseñar redes jerarquicas, que delegen autoridad y puedan forzar el manejo
local de regiones separadas de redes internas.
•Integrar diferentes tecnologías de enlace de datos, tales como Ethernet, Fast
Ethernet, Token Ring, FDDI y ATM.

¿ No funciona internet ?

Mas veces de las deseadas habrás notado que no puedes navegar porque tu browser no consigue encontrar ningun servidor, y eso aunque aparentemente la línea tenga buena conexión, y las luces correspondientes de tu router o modem indiquen que hay linea establecida, e incluso algo de tráfico. Igual ocurre que otros programas que usan internet sí funcionan, como por ejemplo el correo. En estos casos no es que internet no funcione, sino que el/los servidor DNS a los que se conecta tu navegador cada vez que necesita resolver a IP un nombre de dominio, no funciona.

Para comprobar si este es el caso (que además tiene fácil arreglo) basta con abrir una ventana de comandos y hacer ping a un número IP conocido. Si obtenemos respuesta, podemos repetir el ping a su nombre de dominio, y si en este caso no hay respuesta, ya sabremos que el servidor DNS de nuestro ISP esta fuera de servicio.

Por ejemplo:

ping 213.4.130.210
ping terra.es

Soluciones

Si obtenemos respuesta al ping ip y no al ip nombre_de_dominio la solución mas fácil es añadir servidores adicionales a la configuración de nuestro ordenador, ya que el sistema en caso de silencio del primer servidor pasa la consulta al segundo, y asi sucesivamente.

Para añadir direcciones IP de servidores DNS adicionales, en linux basta con editar el archivo /etc/resolv.conf y añadir debajo de los ya existentes las nuevas direcciones, con el formato nameserver numero_ip, un servidor por línea.

En sistemas windows, basta ir a “mis conexiones de red” y pulsar el botón derecho sobre el icono que quieras configurar (conexion de red inalambrica, modem, tarjeta adsl …) y seleccionar propiedades. En un recuadro aparecerá un listado disponible de protocolos. Selecciona “protocolo internet (TCP/IP)” y pulsa el botón propiedades. Tendrás una nueva ventana donde verás hasta dos servidores DNS, preferido y alternativo, que serán los que tu incluiste al configurar la conexión (salvo, claro está, que marcases la casilla de “obtener la direccion del servidor DNS automáticamente”. Pues bien, pulsando ahi el botón de opciones avanzadas tendrás una nueva ventana donde añadir servidores adicionales. Ten en cuenta que el sistema operativo intentará resolver los nombres de dominio utilizando los servidores en el orden en que aparezcan en esa lista.

Y donde encontrar servidores DNS alternativos a los que ya te haya facilitado tu ISP ? pues una opción sería llamar a tu ISP, diciendole que sus servidores DNS no funcionan y pidiendole números adicionales (cualquier ISP tiene normalmente una buena lista de servidores DNS a los que acudir). También puedes buscar en internet direcciones de servidores IP públicos y alternativos, que si son rápidos serán mejor opción ya que no dependerán de la misma empresa. Ten en cuenta, naturalmente, que no te basta el nombre del servidor DNS, precisas conocer su IP.

Si tienes el programa dig puedes comprobar la disponibilidad del nuevo servidor DNS antes de añadirlo a tu sistema, tecleando simplemente:

dig cualquier_nombre_de_dominio @numero_ip_server_DNS

La consulta DNS se hará precisamente a ese servidor.

Mas soluciones

Otra solución pasa por disponer en nuestro sistema de un servidor DNS propio. Por supuesto, la configuración de un sistema DNS integro es muy compleja, y carece de sentido para nosotros. Nos bastará un servidor DNS cache que almacene las IPs de las consultas ya realizadas (servidor de cache de nombres). Bajo windows existe un pequeño servidor DNS de configuración relativamente sencilla, llamado treewalk, gratuito para uso personal. Otro producto similar para windows podría ser AnalogX FastCache (que no he llegado a probar). Para Linux, puede instalarse BIND y configurar solamente los archivos resolv.conf para que apunten a nuestro ordenador (127.0.0.1) en lugar de al DNS server de nuestro ISP, y luego en /etc/bind/named.conf.options incluir en la sección forwarded los números IP de los servidores DNS del ISP, por si acaso.

Mientras Treewalk por defecto es un sistema de cache persistente (recuerda las IPS que ha resuelto aunque apagues/enciendas el ordenador) BIND solo almacena por defecto las consultas en cada sesión, por lo que su efectividad para resolver el problema que tratamos en esta página es mas limitada

Una posible desventaja es que con IPs almacenadas en cache, siempre cabe la posibilidad de que alguna información quede obsoleta (porque el nombre de dominio haya cambiado de IP). El problema no es muy grave, ya que normalmente la persistencia de la consulta en la cache es controlada por el servidor que nos facilitó la respuesta (mediante el valor TTL) y en segundo lugar porque si vemos que los resultados no son correctos, podemos vaciar (flush) la memoria cache y comenzar de nuevo.

Dig: consultando la configuración dns

Dig es una herramienta (linea de comandos) disponible en prácticamente cualquier distribución linux (aunque también hay alguna versión para windows) que te permite hacer consultas a un servidor dns. Dig precisa conocer la dirección IP de un servidor DNS al que consultar por defecto, dirección IP que toma del archivo resolv.conf, que en Windows puedes encontrar en c:\windows\system32\drivers\etc\resolv.conf, y en sistemas GNU/Linux en /etc/resolv.conf.

En esta página, y en diferente color, se incluyen los comandos a ejecutar desde la consola.

los 13 principales

Ejecuta en linea de comandos dig . ns y obtendrás la lista de los trece super servidores dns, que debe ser la misma que la que puedes obtener en ftp.internic.net

Si lo que quieres es conocer los servidores que manejan los dominios .com .net …, prueba: dig com. NS o “dig net. NS“… Lo mismo para paises: prueba dig es. NS o dig ca. NS etc etc

Opciones dig

dig tu_dominio.com +trace

Similar al tracert TCP/IP, pero para dns

dig tu_dominio.com. NS

Te indica los servidores dns de tu_dominio:

;; ANSWER SECTION:
ignside.net.            132119  IN      NS      ns2.nexen.net.
ignside.net.            132119  IN      NS      ns1.nexen.net.

El primer número (132119) indica el TTL (tiempo de vida en cache) de la consulta

dig tu_dominio.com. MX

Te indica los servidores de correo (Mail e[X]change) que gestionan los mails dirigidos a loquesea@tudominio.com. Por ejemplo:

;; ANSWER SECTION:
ignside.net.            3600    IN      MX      10 pouilly.nexen.net.
ignside.net.            3600    IN      MX      20 champagne.nexen.net.

Estan listados por orden de precedencia, los números mas bajos (10, 20) primero.

dig tu_dominio.com

devuelve la IP del dominio

dig midominio.com. @dns1.nrc.ca

consulta los datos dns en un servidor @especifico.

La mayoría de los servidores DNS estan configurados para, si no conocen la respuesta al query, encargarse ellos mismos de reformular la pregunta a otro servidor distinto. Esto se llama configuración recurrente o amistosa (friendly, recursive).

dig -x numero_ip

DNS inverso

Descifrando las respuestas

Una orden como dig www.ignside.net genera el siguiente resultado:

C:\WINDOWS\system32\dns\bin>dig www.ignside.net

; <<>> DiG 9.4.0-(Hawk)-8.02 <<>> www.ignside.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1580
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.ignside.net.               IN      A

;; ANSWER SECTION:
www.ignside.net.        2886    IN      CNAME   irvnet.nexenservices.com.
irvnet.nexenservices.com. 6486  IN      CNAME   sauterne.nexen.net.
sauterne.nexen.net.     486     IN      A       217.174.203.10

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 28 22:33:36 2005
;; MSG SIZE  rcvd: 116

C:\WINDOWS\system32\dns\bin>

Veamos la respuesta linea por linea, teniendo en cuenta que aquellas que comienzan con ; son comentarios introducidos por dig, no vienen del servidor dns:

En las dos primeras líneas, dig se limita a informar de la versión del programa en ejecución y del dominio objeto de consulta. La línea ;; global options: printcmd se refiere a las opciones generales usadas en la consulta. Puedes evitar estas dos lineas utilizando la sintaxis de consulta dig +nocmd nombredominio.com

La siguiente seccion Got Answer nos ofrece detalles de la consulta recibida, entre ellos, el número de respuestas recibidas, y si nos la ha dado o no una “autoridad” en dns.

Las ‘banderas’ (flags) nos dan detalles de la consulta y respuesta: QR (Query/Response) sirve para diferenciar la consulta de la respuesta. RD (Recursion Desired), es una modalidad de la consulta, que es replicada en la respuesta con la bandera RA (Recursion Allowed), y significa que pedimos al server que si no puede resolver la respuesta por si mismo, consulte recursivamente a otro server. La aceptación de la petición por el server es opcional. AA significaría que la respuesta es de un server autorizado. Otras flags son: TC (Truncated Response), que significa que la respuesta se ha fraccionado por ser de mayor tamaño del permitido, AD (Authentic Data) y CD (Checking Disabled).

La tercera sección nos da detalles de la consulta; además como es obvio del dominio consultado, nos informa que estamos consultando en los registros A. Como ya sabemos, si indicase MX en su lugar querria decir que estamos consultando una dirección de email. IN indica que la búsqueda se realiza en el ámbito de internet.

Las consultas posibles que podemos hacer, comenzando por las ya conocidas son:

• dig midominio.com NS para los servidores dns (nombre)
• dig midominio.com MX para los servidores de correo
• dig midominio.com A para la ip del servidor que aloja al dominio
• dig midominio.com ANY reune las anteriores
• dig midominio.com AAAA nos indica el numero IP en ipv6 (si es que lo tiene, claro):

  C:\WINDOWS\system32\dns\bin>dig www.ipv6.org AAAA +short
  shake.stacken.kth.se.
  2001:6b0:1:ea:202:a5ff:fecd:13a6

En el ejemplo que hemos puesto mas arriba, la respuesta tiene varias lineas. La línea www.ignside.net. 2886 IN CNAME irvnet.nexenservices.com. nos dice que el dominio por el que preguntamos es un alias (CNAME) de irvnet.nexenservices.com; La siguiente linea nos indica que irvnet.nexenservices.com es un alias de sauterne.nexen.net, y la tercera linea nos indica la IP de sauterne.nexen.net.

El porque tres respuestas ? porque www no es mas que un subdominio de ignside.net y este subdominio es un alias de irvnet.nexenservices.com (apunta a la misma IP) que a su vez es un alias del dominio del ISP (nexen), obteniendo finalmente la Ip de este.

El que ninguna de las respuestas que hemos obtenido sea AUTHORITY no dice nada sobre la fiabilidad de la respuesta, simplemente que el server que nos la ha dado no es responsable del dominio.

Finalmente podemos encontrarnos con una sección de respuestas adicionales, que típicamente nos informaría de las IPS de los nameserves devueltos en la sección AUTHORITY, si los hubiera.

La última sección nos explica el tiempo que ha tardado en resolverse la consulta, el número en bytes de la respuesta, la fecha y el servidor dns consultado.

Acotando las respuestas:

dig admite varias opciones que modalizan la cantidad de información obtenida. Todas las secciones de la respuesta pueden ser eliminadas con las opciones +nocmd, +[no]comments, +[no]question, +[no]answer, +[no]authority, +[no]additional y +[no]stats.
Existe una forma abreviada, que es la de excluir todo y indicar concretamente lo que quieres: dig midominio.com A +noall +answer.

Otra opción para limitar la información es short. Y si al contrario quieres mas detalles de los standard, prueba +multiline

TTL

La respuesta dns incluye un valor TTL expresado en segundos: por ejemplo, en esta linea, 2886 segundos: www.ignside.net. 2886 IN CNAME irvnet.nexenservices.com.

TTL, o Time To Live, es el tiempo máximo durante el cual un server almacenará en su cache una respuesta obtenida de un server con “autoridad”. Mientras dure el TTL, el server en cuestión no volverá a realizar consultas dns sobre ese dominio, respondiendo con los datos guardados. Expirado el TTL, consultará de nuevo a la autoridad en la materia …

Zonas DNS

Hemos venido hablando de respuestas autorizadas o no. El servidor DNS, al contestar las consultas, busca en primer lugar en los registros dns de su zona local (aquellos de los que el server es responsable). Si encuentra alli la respuesta, será una respuesta autorizada. Si no la encuentra, buscará en su cache de consultas anteriores. Si aquí se encuentra una coincidencia, el servidor responde con esta información. Esta respuesta ya no es autorizada. Finalmente si el servidor está configurado para la búsqueda recursiva, consultará -en nuestro nombre- a otro server dns.

Por ello el concepto de autoridad, en dns, es similar al de administración: la respuesta es autorizada si el dominio está en una zona administrada por ese server. La respuesta también es autorizada si nuestro server dns no tiene la respuesta en cache y hace una consulta recursiva. A partir de ese momento, y mientras conserve la respuesta en cache, no sera respuesta autorizada.

PTR

Pointer Record. Tambien llamado reverse record (registro inverso).

Un registro PTR asocia una dirección IP con su nombre de dominio real, debiendo apuntar a un nombre de dominio que se resuelva a esa IP. La IP se indica invirtiendo sus cuatro grupos de numeros y añadiendo IN-ADDR.ARPA.

SOA record

SOA son las iniciales de Start Of Authority. Un Registro SOA identifica la mejor fuente de información sobre un dominio dado, y solo puede haber un registro por dominio. La información que obtenemos con dig midominio.com SOA incluye:

• Hostname.Domain.Name, que es el nombre del servidor primario para este dominio (donde reside la respuesta autorizada): por ejemplo, en el caso de google.com, es ns1.google.com..
• Mailbox.Domain.Name es (teóricamente) el correo del responsable del DNS de este dominio; en el mismo ejemplo de google.com, dns-admin.google (sustituye el primer punto por @ para formar el email).
• serno se refiere el numero de serie, que identifica cuando ha habido una actualización de la base de datos: por ejemplo numeros de serie válidos serian 1, 2, 3 etc …. Típicamente se usa como serial number la fecha inversa de la ultima actualización (año-mes-dia). Por ejemplo, 2005072601
• Refresh indica al servidor secundario cada cuanto tiempo debe consultar al primario sobre actualizaciones
• Retry indica el lapso que debe respetar el servidor secundario para tratar de reconectar con el primario, en el momento de Refresh
• Expire es el numero de segundos durante los cuales el servidor secundario mantiene los datos, si no puede conectar con el primario
• TTL es el tiempo de vida que los datos deben conservarse en cache al ser solicitados.

Enlaces relacionados

Para mas opciones puedes consultar los parámetros de un registro DNS. En esta pagina encontrarás listadas todas las querys posibles, opcodes, códigos de respuesta, etc.

Otro excelente recurso lo puedes encontrar en www.networksorcery.com. Men&Mice tienen un excelente glosario, ambos links en inglés.

Men & Mice también ofrecen la posibilidad de usar dig online

Diagnosticando problemas de red TCP/IP con ping

Ping es una herramienta de diagnóstico de redes TCP/IP, que ofrece información util sobre la presencia en red de de otro ordenador, y sobre el rendimiento de la conexión; de modo similar al sonar de un submarino (de ahi su nombre) envia una señal a un ordenador en red y escucha el eco.

Aunque es una herramienta de gran utilidad, sus resultados a veces pueden resultar falseados por politicas de seguridad establecidas en el ordenador investigado, ya que en ocasiones, para hacer invisible a un ordenador en red (indetectable = inatacable) se configuran para que no contesten este tipo de peticiones. Por tanto si estas haciendo ping sin respuesta a un equipo de tu red, una de las cuestiones a tener en cuenta será la existencia de filtros a nivel de router, o firewall.

Por supuesto, es una herramienta de consola, y su uso es ping numero_ip_target o bien ping nombre_de_dominio_target

1. Ping a tu dirección local 127.0.0.1; debe responder. Si no responde, posiblemente el protocolo TCP/IP esté dañado. Habrá que reinstalar el protocolo.
2. Ping a tu IP privada, si estas en sub red (por ejemplo 192.168.1.2). Debe responder. Si no hay respuesta, o bien has escrito mal tu ip, o como en el caso anterior es un problema de la pila TCP/IP. Puedes averiguar tu IP con ipconfig
3. Ping a la IP privada del gateway. Debe responder.
4. Ping a la IP pública del gateway. Debe responder
5. Ping a la IP de un ordenador fuera de la red. Debe responder
6. Ping al nombre de dominio de un ordenador fuera de la red. Debe responder. De no responder (y si en los casos anteriores) debes revisar tus dns.

TTL

Uno de los datos que lleva cada datagrama enviado por TCP/IP es el TTL que es el número de saltos (pasos por routers) que el paquete puede dar antes de ser descartado o devuelto. Se trata de un límite impuesto por el protocolo TCP/IP para evitar que queden paquetes vagando por la red indefinidamente. El número máximo de saltos permitidos en el protocolo TCP/IP es 255, pero normalmente las aplicaciones que usan el protocolo TCP/IP fijan un valor menor (por ejemplo, 128 un host con XP, 32 en los primeros SO windows etc). El valor recomendado como normal es de 60 saltos. Típicamente, el valor TTL disminuirá una unidad por cada paso de router, hasta llegar al tope establecido. El router por el que pasen datos con TTL igual a cero, no redigirá dichos datos, sino que los descartará.

si quieres saber el valor TTL que usa tu ordenador haz ping localhost.

Teóricamente sabiendo el valor inicial del TTL podriamos saber cuantos saltos ha dado el paquete hasta alcanzar destino y volver (valor TTL de nuestra aplicacion TCP/IP menos valor TTL del ping), si bien es sumamente impráctico utilizarlo con esta finalidad, pues los host a los que hacen ping no devuelven el mismo TTL del paquete que reciben, sino su propio valor TTL. Por ejemplo, tu puedes hacer un ping con un XP (valor TTL de 128) que pasa por 10 routers, y llega a destino con valor 118. El dispositivo al que haces ping podría ser un router (suelen tener TTL de 255) con lo cual ese valor seria asignado al TTL. La respuesta del ping hacia tu ordenador podría pasar por 15 routers: recibirias un ping con TTL 240, escasamente indicativo de la ruta del paquete.

En contexto de servidores DNS, TTL es el tiempo en el que un servidor que consulta a un servidor superior debe conservar la respuesta en su cache.

ipconfig

ipconfig sin parámetros te indica el nombre del adaptador de red en uso, la ip del equipo, la máscara de subred y la ip del gateway.

ipconfig /all te da información mas completa indicando nombre del equipo, direccion MAC, configuracion WINS, dns etc.

Con ipconfig /renew cada adaptador del equipo solicita una nueva IP al servidor DHCP (si activado).

NBTSTAT

Estadísticas NetBIOS over TCP/IP. Opciones de interés:

-n

Muestra nombres NetBIOS de la red resueltos por nuestro equipo: los nombres que nuestro ordenador conoce.

-s

Muestra sesiones NetBIOS

-c

Muestra los nombres resueltos en la cache

-R

purga y recarga la cache con el contenido del archivo lmhosts

NETSTAT

Estadisticas de red

-a

Conexiones activas y puertos a la escucha.

-n

Muestra números de puertos y direcciones en formato numérico.

-b

Muestra comunicaciones y ejecutable que las ha establecido.

-bv

Muestra comunicaciones, ejecutable y módulos que las han establecido.

-s

Muestra estadísticas por protocolo (IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP y UDPv; se puede utilizar la opción -p para especificar un subconjunto: netstat -sp tcp

NET

VIEW

Lista equipos disponibles con soporte netBIOS

VIEW \\nombre_equipo

Muestra los recursos compartidos de nombre_equipo.
los que llevan $ al final son invisibles

NET STATISTICS SERVER o NET STATISTICS SERVER

Muestra estadística diversa sobre la subred: sesiones abiertas, reinicios de red, etc

NET DIAG

Ejecutado en dos ordenadores con protocolos NetBeui o IPX/SPX, nos indica si ambos equipos pueden enviar y recibir informacion con dicho protocolo.

nslookup

informacion del servidor de nombres

netsh

ver, modificar y diagnosticar la configuración de la red

Una de las posibilidades mas interesantes de netsh es la de automatizar el cambio de configuración de nuestro adaptador de red al perfil de varias redes diferentes. Esto es útil, por ejemplo, si tenemos un portatil y lo usamos en varias redes diferentes (trabajo, casa, etc).

Puedes ver como automatizar el cambio de red aqui y esta es la página de ayuda msoft sobre netsh

winipcfg

Windows 95/98 tenia una utilidad gráfica para mostrar parámetros de red: winipcfg. Para NT (y 2000 y XP) puedes obtener una copia

Si recuerdas de cuando hablabamos del protocolo NetBIOS, en este tipo de redes cada equipo tiene una dirección no lógica, es cuanto es única y solo individualiza a un equipo de la sub red, pero no dice nada de su localización.

En una red sencilla cada ordenador de la subred guarda una lista con los nombres de los demas equipos. Es una relacion de igual a igual y no hace falta servidor.

Con la utilización de NetBIOS sobre TCP/IP nacen los servidores WINS:

El Servicio de Nombres de Internet de Windows, o WINS, es simplemente un servidor de nombres NetBIOS y de su traslación a IP. Es un servidor dinámico, ya que solo mantiene la información mientras el equipo esta conectado y refresca la infoemación.

Puede existir un servidor WINS primario junto con otro secundario, que solo se utilizará en caso de fallo, sincronizando la informacion entre si.

Es cada equipo de la red quien solicita registrarse en el servidor WINS (con su nombre NetBIOS y IP), limitandose el servidor a mantener la informacion recibida, y a suministrarla al resto de equipos de la red.

En definitiva WINS es una de las formulas de resolver nombre de equipo a IP en el protocolo NetBIOS sobre TCP/IP; una de las fórmulas y no la única, por lo que en una red doméstica no es necesario. Otras vias de resolucion nombre_equipo a IP son el archivo LMHOSTS, la resolución de nombres por difusión IP, o la cache NetBIOS.

Broadcast or not broadcast

Toda máquina que usa NetBIOS registra su nombre al iniciarse. Este registro no es sino el proceso de darse a conocer al resto de máquinas de la sub red, y segun la tengamos configurada, esta auto-presentación puede ser mediante broadcasting (señal enviada a todos los equipos conectados) o dandose de alta en un servidor WINS. Alternativamente hay un tercer sistema, estatico, utilizando un archivo LMHOST.

En definitiva:

• cache de la NetBIOS: cada vez que un PC resuelve un nombre NetBios a IP, conserva en memoria cache los datos un tiempo variable (10 minutos). Si necesita de nuevo el dato, lo busca en primer lugar en esta cache (Para ver el contenido de la memoria cache, nbtstat -c )
• Si el PC no ha podido localizar la IP de la maquina que busca, hace una petición basada en el nombre NetBIOS que es radiada (broadcasting) a todos los equipos conectados, y eventualmente respondida unicamente por la máquina destino que facilita su IP. Desventajas ? abundancia de tráfico de red para cada simple petición.
• Archivo LMHosts: es un archivo de texto que describe cada nombre de equipo con la ip que le corresponde. Es el unico sistema estatico (que no se actualiza segun que equipos esten conectados en cada momento
• Servidor WINS, del que veniamos hablando