Servicios de red: DHCP, DNS y más

DHCP, el protocolo de configuración dinámica de hosts, proporciona una dirección IPv4 y ajustes durante un tiempo limitado llamado concesión. El servidor escucha en UDP 67; el cliente utiliza UDP 68. Los portátiles, las impresoras, los teléfonos y las interfaces de los enrutadores pueden ser clientes. En Cisco IOS, ip address dhcp hace que una interfaz solicite sus ajustes.

Obtén la primera concesión

Un cliente nuevo utiliza cuatro mensajes, que se recuerdan con la sigla DORA:

1. Descubrimiento: sin una dirección utilizable ni un servidor conocido, el cliente envía una difusión desde 0.0.0.0 a 255.255.255.255.
2. Oferta: un servidor propone una dirección, una duración de concesión y unos ajustes.
3. Solicitud: el cliente solicita la oferta elegida. Esta solicitud suele enviarse por difusión, para que los demás servidores que hicieron ofertas sepan que no fueron seleccionados.
4. Confirmación: el servidor elegido confirma la concesión. El cliente ya puede utilizarla.

Por ejemplo, un portátil recibe 192.168.10.57/24, la puerta de enlace 192.168.10.1, el servidor DNS 192.168.10.5 y una concesión de 8 horas. Muchos clientes comprueban la dirección mediante ARP antes de utilizarla. Si otro host responde por esa dirección, el cliente envía DHCPDECLINE y vuelve a empezar.

Los ajustes llegan como opciones numeradas. La opción 1 proporciona la máscara de subred, la 3 el enrutador, la 6 los servidores DNS, la 15 el nombre de dominio y la 51 la duración de la concesión. Opciones como la 43 o la 150 ayudan a los teléfonos y puntos de acceso a encontrar un controlador o servidor de configuración. Por tanto, una dirección correcta con un servidor DNS incorrecto sigue siendo un problema de configuración de DHCP.

Renueva antes de que termine la concesión

La concesión tiene dos momentos de renovación predeterminados, medidos desde su inicio:

Una confirmación durante la renovación reinicia la concesión, normalmente para la misma dirección. Los usuarios siguen trabajando durante la renovación normal en segundo plano; una concesión corta no los desconecta periódicamente.

En Windows, ipconfig /all muestra el servidor y los tiempos de la concesión. ipconfig /release devuelve la dirección e ipconfig /renew solicita una concesión. Un dispositivo que se marcha sin liberarla sigue ocupando su concesión hasta que vence. Si DHCP falla, Windows puede asignarse una dirección de enlace local APIPA, como 169.254.37.112. Esto permite comunicarse con otros hosts de enlace local de ese segmento, pero no proporciona acceso enrutado a internet.

Compara la configuración de direcciones IPv6

Con SLAAC, un host construye una dirección IPv6 utilizando un prefijo /64 anunciado por un enrutador. Los indicadores de los anuncios de enrutador orientan a los hosts hacia DHCPv6: M solicita una configuración de dirección gestionada; O solicita otros ajustes, como DNS. DHCPv6 con estado proporciona una dirección; DHCPv6 sin estado proporciona ajustes adicionales mientras SLAAC proporciona la dirección. DHCPv6 utiliza UDP 546 para los clientes y 547 para los servidores. La puerta de enlace predeterminada procede de los anuncios de enrutador o de una configuración manual, no de DHCPv6.

Un ámbito, llamado conjunto de direcciones en dispositivos Cisco, combina las direcciones que pueden concederse en una subred con los ajustes que necesitan allí los clientes. Planifica las direcciones antes de introducir comandos para que el servidor DHCP y los dispositivos configurados manualmente nunca utilicen la misma dirección.

Elige el rango disponible

Empieza por la red, el prefijo y el rango de direcciones de host utilizables. Enumera la puerta de enlace, los servidores y los demás dispositivos fijos, y después excluye sus direcciones. En 192.168.10.0/24, el rango utilizable va de .1 a .254. Al excluir de .1 a .20, quedan de .21 a .254:

Ese conjunto admite 234 concesiones. No caben los 260 clientes previstos; utiliza una subred mayor, como una /23 con 510 direcciones utilizables, u otra subred. Al planificar el crecimiento, cuenta el espacio excluido y reservado, además de los usuarios activos.

Una exclusión indica al servidor que nunca conceda una dirección. Una reserva vincula una dirección a una dirección MAC o un identificador de cliente concretos, mientras el dispositivo sigue utilizando DHCP. Una impresora con reserva recibe los ajustes DNS actualizados al renovar. Una impresora con una configuración estática introducida manualmente debe actualizarse en el propio dispositivo.

Configura un conjunto en Cisco IOS

Introduce la exclusión en la configuración global. Los demás ajustes pertenecen al conjunto:

ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool OFFICE
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 192.168.10.5
 domain-name example.com
 lease 0 8

lease 0 8 significa 0 días y 8 horas. Sin un comando de concesión, el valor predeterminado de IOS es 1 día. La puerta de enlace debe corresponder a esta subred; copiar el default-router de otro conjunto puede dejar a los clientes con acceso a los hosts locales, pero sin poder salir de su red.

Comprueba el resultado con show ip dhcp pool para la capacidad del conjunto, show ip dhcp binding para los clientes y los vencimientos, y show ip dhcp conflict para las direcciones retiradas tras un conflicto. Windows Server utiliza los mismos conceptos de ámbito, exclusión, reserva y opción; las opciones del ámbito pueden prevalecer sobre las opciones generales del servidor.

Adapta la duración de la concesión y la redundancia a la demanda

El Wi-Fi de invitados se beneficia de concesiones de unas 1–4 horas porque los dispositivos que se han marchado liberan antes su espacio al vencer la concesión. Los equipos de escritorio estables pueden utilizar concesiones de varios días; el valor predeterminado de Windows Server es 8 días. Un conjunto de 200 direcciones con 60 dispositivos nuevos de invitados cada día puede llenarse en unos 3,3 días si esas concesiones siguen ocupadas. Acortar la duración configurada ayuda a medida que se aplican nuevas concesiones y renovaciones; no borra de inmediato las concesiones existentes.

Dos servidores pueden repartirse el rango sin solapamiento, por ejemplo, con una distribución 80/20, o utilizar una función de conmutación por error compatible que comparta el estado de las concesiones. Dos servidores independientes no deben asignar libremente las mismas direcciones: de lo contrario, cada uno podría dar una dirección a un cliente distinto.

Un cliente envía su mensaje de descubrimiento por difusión en su segmento local. Un enrutador convencional no reenvía esa difusión, por lo que un servidor DHCP de otra subred necesita un agente de retransmisión para recibirla. El agente suele ejecutarse en la interfaz del enrutador o conmutador de capa 3 que actúa como puerta de enlace de la subred del cliente.

Retransmite la solicitud e identifica la subred

El agente recibe la difusión y envía una solicitud por unidifusión al servidor. Inserta la dirección de su interfaz orientada a los clientes en giaddr, el campo de dirección IP de la puerta de enlace. El servidor utiliza esta dirección para seleccionar el ámbito del cliente y devuelve su respuesta a través del agente.

Para la VLAN 20, supón que la puerta de enlace es 192.168.20.1 en GigabitEthernet0/1 y el servidor es 10.0.0.10. Configura:

interface GigabitEthernet0/1
 ip helper-address 10.0.0.10

El comando debe estar en la interfaz orientada a los clientes. Una dirección de retransmisión en la interfaz orientada al servidor no recibe la difusión del cliente. El servidor también necesita un ámbito para 192.168.20.0/24 y una ruta de retorno a 192.168.20.1. Una segunda línea de retransmisión puede indicar un servidor de respaldo. En IOS, las direcciones de retransmisión reenvían de forma predeterminada varios servicios de difusión UDP, incluidos DNS y TFTP, por lo que debes revisar ese comportamiento al diseñar la red.

Avanza desde el cliente hacia el exterior

Utiliza el síntoma para elegir la siguiente comprobación:

Después examina la ruta. Confirma la VLAN del puerto del conmutador, la dirección de servidor configurada para la retransmisión, el enrutamiento en ambos sentidos y las reglas de ACL o cortafuegos para DHCP. Los clientes utilizan UDP 68 y los servidores UDP 67; el tráfico del agente al servidor utiliza el puerto del servidor. Que DNS funcione no demuestra que se permita el tráfico DHCP.

Por ejemplo, la VLAN 10 funciona, pero una VLAN 30 nueva solo recibe direcciones APIPA. Si el servidor es remoto y la VLAN 30 no tiene retransmisión configurada, su mensaje de descubrimiento nunca llega al servidor. Añade el agente de retransmisión en la puerta de enlace de esa VLAN y verifica que el servidor tenga un ámbito correspondiente antes de volver a probar la renovación.

Corrige la causa antes de borrar el estado

Un conjunto agotado no tiene direcciones libres que ofrecer. En show ip dhcp pool, compara las direcciones concedidas con el total menos las excluidas y después comprueba la lista de conflictos para detectar más espacio no disponible. Repetir solicitudes ipconfig /renew no puede crear capacidad. Revisa las exclusiones y reservas obsoletas, ajusta la duración de las concesiones a la rotación de dispositivos o amplía el espacio de direcciones.

Un dispositivo estático dentro del conjunto dinámico puede provocar advertencias de direcciones duplicadas. Localiza y corrige ese solapamiento y, después, borra las entradas de conflictos resueltos con clear ip dhcp conflict * cuando corresponda. Borrar la lista mientras sigue existiendo el duplicado favorece que se repita el mismo fallo.

Un servidor DHCP no autorizado, a menudo un enrutador doméstico conectado a la red, puede proporcionar una puerta de enlace incorrecta. Identifícalo a partir de la configuración del cliente y retíralo. La inspección DHCP impide que los puertos del conmutador que no son de confianza envíen respuestas de servidor, protegiendo a los clientes posteriores del mismo error.

La gestión de direcciones IP (IPAM) une la planificación con el mantenimiento de registros y el descubrimiento. Responde a preguntas prácticas: ¿qué subred pertenece a esta VLAN? ¿Quién es responsable de esta dirección? ¿Es estática, reservada o concedida? ¿Qué rango aún tiene espacio? Una hoja de cálculo puede contener un plan pequeño; una herramienta específica también puede comparar ese plan con los dispositivos activos. Los productos que combinan DNS, DHCP e IPAM se llaman DDI.

Registra lo necesario para realizar el siguiente cambio con seguridad

Para cada subred, registra su dirección de red y prefijo, identificador de VLAN, puerta de enlace, finalidad, ubicación, rango DHCP y exclusiones. Para cada asignación estática, registra el nombre de host, la dirección MAC, el tipo de dispositivo, el responsable y la fecha de asignación. Estos campos permiten distinguir una dirección que simplemente no muestra actividad de otra disponible para reutilizarse.

Una sede que utiliza 10.20.0.0/16 podría asignar:

En cada subred, .1 puede ser la puerta de enlace, .2–.20 el rango fijo y .21–.254 el rango DHCP. Documentar este patrón ayuda a un técnico a reconocer la función de un dispositivo y evita que dos equipos asignen espacios solapados. El plan sigue necesitando un registro individual cuando se asigna una dirección fija.

Mide el margen disponible

El porcentaje de uso de direcciones compara las direcciones utilizadas con las utilizables:

Una /22 tiene 1022 direcciones IPv4 utilizables. Si 870 están en uso, el porcentaje es de aproximadamente el 85,1 %. Un umbral de alerta del 80 % ya habría activado la planificación de más espacio. Mantén esta medida de la subred separada de la disponibilidad del conjunto DHCP: las exclusiones y reservas pueden llenar un conjunto dinámico aunque la subred aún tenga direcciones sin asignar.

Contrasta el plan con las pruebas disponibles

El descubrimiento de IPAM puede leer las concesiones DHCP, los registros DNS y las tablas ARP de los enrutadores, y explorar subredes. Compara estas fuentes: una dirección descubierta sin responsable puede corresponder a un dispositivo sin documentar; un servidor registrado sin indicios actuales puede haber sido retirado. Investiga la diferencia antes de cambiar la asignación.

Antes de asignar una dirección estática, comprueba el registro IPAM, las concesiones DHCP y DNS. Un ping fallido es una prueba insuficiente: el dispositivo que la utiliza puede estar apagado o bloquear el ping. Tras asignar la dirección, registra el dispositivo y protege la asignación frente a DHCP. Cuando lo retires, recupera la dirección y elimina los registros DNS obsoletos para que un usuario futuro no herede el nombre antiguo.

DHCP puede actualizar DNS dinámicamente y mantener los registros A y PTR de un cliente de acuerdo con su concesión. IPAM reúne estos registros en una sola vista, pero el descubrimiento automático sigue necesitando un plan preciso e información sobre los responsables para explicar qué debería estar haciendo un dispositivo.

IPv6 elimina la presión de contar todas las posibles direcciones de host de una /64. No elimina la necesidad de planificar. Registra qué prefijo /64 pertenece a cada sede y VLAN, junto con las puertas de enlace y las asignaciones fijas importantes. Controla la estructura y los responsables del espacio de direcciones incluso cuando las direcciones individuales de los hosts cambien con frecuencia.

DNS, el sistema de nombres de dominio, almacena información bajo nombres organizados en un árbol. Lee www.example.com. de derecha a izquierda: la raíz es el punto final, com es el dominio de nivel superior, y example y www identifican niveles inferiores. Un nombre de dominio completo (FQDN) indica la ruta completa hasta la raíz.

Identifica quién es responsable de la respuesta

Una zona es una parte gestionada de ese árbol, almacenada en servidores de nombres autoritativos. El primario contiene la copia editable; los secundarios contienen copias de solo lectura obtenidas mediante transferencia de zona por TCP 53. El número de serie del SOA permite a los secundarios detectar una versión más reciente. Varios servidores autoritativos mantienen las respuestas disponibles cuando falla un servidor.

Lee el tipo de registro antes que su valor

Por ejemplo, "www.example.com. 3600 IN A 203.0.113.10" relaciona un nombre con una dirección IPv4. "www.example.com. 3600 IN AAAA 2001:db8::10" proporciona IPv6. En estos registros, 3600 es el tiempo de permanencia en caché en segundos e IN es la clase internet.

Un alias como "shop.example.com. 3600 IN CNAME www.example.com." apunta al nombre, no directamente a su dirección. Una consulta sigue ese destino para obtener una respuesta A o AAAA. Un CNAME no puede compartir su nombre con datos ordinarios como registros A, MX, SOA o NS. Los metadatos de DNSSEC son una excepción especial. El ápice de la zona necesita registros SOA y NS, por lo que no puede colocarse allí un CNAME estándar; las funciones de alias o aplanamiento de los proveedores son funciones diferentes de gestión de registros.

Las preferencias MX funcionan al contrario que una puntuación donde «cuanto más alto, mejor». Con preferencia 10 para mail1.example.com. y 20 para mail2.example.com., los emisores prueban primero mail1. Los valores MX deben ser nombres de host con registros A o AAAA directos. Los destinos MX y NS no deben ser alias CNAME.

Invierte la dirección y controla la caché

Las consultas directas comienzan con un nombre; las inversas, con una dirección. Para la dirección IPv4 203.0.113.25, el nombre propietario del PTR es 25.113.0.203.in-addr.arpa.. La consulta inversa IPv6 utiliza dígitos hexadecimales en orden inverso bajo ip6.arpa. Añadir un registro A no crea un PTR, salvo que una función de actualización lo haga.

El tiempo de vida (TTL) es el tiempo máximo normal de permanencia en caché en segundos: 300 son 5 minutos, 3600 una hora y 86 400 un día. Antes de cambiar una dirección, reduce el TTL de 86 400 a 300 y espera al menos el TTL diario anterior. Después cambia la dirección para que las cachés habituales se actualicen en un máximo de 5 minutos y vuelve a aumentar el TTL tras el traslado.

En un archivo de zona, un nombre sin punto final es relativo a la zona actual. Escribir mail.example.com en la zona example.com produce mail.example.com.example.com. Utiliza mail.example.com. para el nombre completo o el nombre relativo mail.

Una computadora no suele contactar por sí misma con todos los servidores DNS. Su resolutor auxiliar pide a un resolutor recursivo que obtenga la respuesta. Este dispone de una respuesta válida en caché o contacta con los servidores autoritativos de las distintas partes del nombre.

Empieza por el cliente

Las fuentes locales incluyen el archivo hosts y la caché DNS del cliente. Una entrada del archivo hosts puede prevalecer sobre DNS en esa computadora. La ruta de Windows es C:\Windows\System32\drivers\etc\hosts; Linux y macOS utilizan /etc/hosts. Una entrada de prueba olvidada puede explicar por qué una computadora accede a un servidor antiguo mientras todas las demás funcionan.

El cliente obtiene la dirección de su resolutor mediante la opción DHCP 6 o una configuración manual. Su solicitud es recursiva: pide al resolutor la respuesta final. El cliente delega la búsqueda, no solicita indicaciones para llegar al siguiente servidor DNS.

Avanza desde la raíz hacia el nombre

Para una consulta de www.example.com con las cachés vacías:

1. El cliente consulta a su resolutor recursivo.
2. El resolutor consulta a un servidor raíz, que lo remite a los servidores de com.
3. Un servidor de com lo remite a los servidores autoritativos de example.com.
4. Un servidor del dominio devuelve "A 203.0.113.10", con TTL 3600.
5. El resolutor almacena esa respuesta en caché y la devuelve al cliente.

Las solicitudes del resolutor a lo largo de la jerarquía son iterativas: cada servidor proporciona su mejor respuesta o referencia. La raíz no contiene la dirección de todos los sitios. Existen 13 identidades de servidores raíz, nombradas de la a a la m, cada una atendida por muchos sistemas físicos que utilizan direcciones de difusión a cualquier miembro.

El siguiente cliente puede recibir la respuesta en caché sin repetir esta búsqueda. Una herramienta puede etiquetarla como "Non-authoritative answer"; esto identifica el origen de la respuesta, no un error. Las referencias y las respuestas negativas también se almacenan en caché. Por tanto, un resultado NXDOMAIN puede seguir apareciendo después de añadir un nombre que faltaba, hasta que termine su tiempo de permanencia en la caché negativa.

Utiliza el reenvío cuando deba buscar otro resolutor

Un resolutor puede enviar las solicitudes que no puede responder a un reenviador, que realiza la búsqueda. Un reenviador condicional envía las solicitudes de un dominio concreto a servidores designados. Por ejemplo, una empresa puede dirigir el dominio interno de una empresa colaboradora al resolutor de esta y enviar los nombres públicos habituales a otro destino.

Distingue privacidad de autenticidad

El DNS convencional utiliza el puerto UDP o TCP 53. La mayoría de las consultas pequeñas utilizan UDP; las transferencias de zona y muchas respuestas grandes utilizan TCP. DNS sobre TLS (DoT) cifra la conexión entre cliente y resolutor por TCP 853. DNS sobre HTTPS (DoH) transporta las consultas mediante HTTPS por el puerto 443 y puede eludir el filtrado que solo supervisa el DNS convencional.

DNSSEC, en cambio, permite a un resolutor validador comprobar firmas y detectar datos DNS alterados o falsificados. No cifra las consultas ni las respuestas. El cifrado protege la ruta de transporte; los datos firmados permiten verificar la autenticidad.

Tras modificar una dirección, los servidores autoritativos publican los datos nuevos, pero no los insertan en todas las cachés de los resolutores. Los usuarios pueden recibir temporalmente respuestas diferentes porque a sus copias en caché les quedan distintos TTL. Ese tiempo de permanencia en caché explica el retardo habitual descrito como «propagación DNS».

Empieza por el fallo exacto. «No se pudo encontrar el host» significa que falló una consulta de nombre. «Conexión rechazada» tras una consulta correcta apunta a otro problema. Probar una dirección conocida y después su nombre ayuda a separar la resolución de nombres del acceso al destino.

Si ping 203.0.113.10 funciona, pero ping www.example.com informa de que no encuentra el host, investiga la resolución. Si ambos fallan, comprueba el direccionamiento y el enrutamiento, pero recuerda que el ping también puede filtrarse. Un ping fallido por sí solo no demuestra que DNS falle ni que el servicio sea inaccesible.

Consulta directamente al servidor adecuado

Identifica los servidores DNS configurados mediante ipconfig /all, resolvectl status o /etc/resolv.conf, según corresponda. Después compara las consultas:

nslookup www.example.com
nslookup www.example.com 192.0.2.53
nslookup -type=MX example.com
dig @192.0.2.53 example.com MX
dig -x 203.0.113.25
dig +trace www.example.com
Resolve-DnsName www.example.com -Type AAAA

La primera consulta prueba el resolutor seleccionado por el cliente; una dirección explícita de servidor prueba un resolutor o servidor autoritativo elegido. dig +trace sigue las referencias. Una consulta directa correcta junto con una consulta fallida desde una aplicación apunta a los ajustes locales, la caché o el archivo hosts.

Interpreta la respuesta

SERVFAIL puede deberse a un servidor autoritativo inaccesible o a una validación DNSSEC fallida. REFUSED es distinto: un servidor accesible puede permitir la recursión solo a clientes internos. En dig, el indicador aa identifica una respuesta autoritativa.

Compara los datos antiguos y nuevos

Supón que un servidor pasó de 203.0.113.10 a 203.0.113.80. El servidor autoritativo devuelve .80, mientras que el resolutor de la oficina devuelve .10 y aún queda tiempo de un TTL anterior de 86 400 segundos. La modificación está publicada; la caché de la oficina está obsoleta. Espera al vencimiento o borra las cachés del resolutor y de los clientes afectados. ipconfig /flushdns borra la caché del cliente Windows, no todas las cachés de los resolutores anteriores. Reducir el TTL con antelación evita una espera larga durante un traslado planificado.

Cuando solo difiere una computadora, examina su archivo hosts y su caché local. Cuando los servidores autoritativos discrepan, compara los números de serie del SOA: una zona primaria modificada con un número de serie sin cambios puede no transferirse a los secundarios.

Relaciona el servicio que falla con sus registros

Un registro A incorrecto afecta a IPv4. Un registro AAAA incorrecto o inutilizable puede provocar retardos en las conexiones IPv6 aunque IPv4 funcione; un servidor que solo utiliza IPv4 no necesita un registro AAAA. Para el correo, verifica los nombres MX y sus registros A o AAAA directos. Sin MX, los emisores pueden probar los registros de dirección del propio dominio. La ausencia de un PTR puede afectar a la aceptación del correo y dificultar la lectura de los registros de eventos.

Por último, permite tanto UDP como TCP 53 donde el DNS convencional los necesite. Un cortafuegos que solo permita UDP puede dejar pasar respuestas pequeñas, pero impedir las grandes y las transferencias de zona.

Una hora común permite comparar eventos. Si un conmutador registra un fallo de puerto y un enrutador registra la pérdida de un vecino, unas marcas de tiempo precisas ayudan a establecer su orden. La hora también afecta a la validez de los certificados y a la autenticación: la configuración predeterminada de Kerberos en Active Directory solo permite 5 minutos de diferencia entre relojes.

Comprende la jerarquía de relojes

NTP, el protocolo de tiempo de red, intercambia paquetes con marcas de tiempo por UDP 123. Cuatro marcas de tiempo permiten al cliente estimar el desfase de su reloj y el retardo de red. Realiza sondeos repetidos, normalmente a intervalos de 64–1024 segundos. Las correcciones pequeñas suelen hacerse mediante un ajuste gradual del reloj para evitar saltos repentinos hacia atrás.

Un estrato describe la distancia respecto a un reloj de referencia:

Los estratos de red utilizables van del 1 al 15. El estrato no es una puntuación de precisión: un servidor cercano de estrato 2 puede dar mejores resultados que una fuente distante de estrato 1 a la que se accede por una ruta con retardo variable.

Utiliza varias fuentes externas, idealmente al menos cuatro, para los servidores horarios internos. Esto permite a NTP comparar fuentes y rechazar una incorrecta. Los demás dispositivos de red pueden sincronizarse con esos servidores internos, lo que limita el tráfico externo y mantiene una cronología local coherente.

Configura y verifica un cliente

En Cisco IOS, ntp server 192.0.2.123 selecciona un servidor de referencia; añadir prefer marca una fuente preferida. Un dispositivo sincronizado puede responder después a solicitudes de hora de otros dispositivos. En cambio, ntp master 4 anuncia el propio reloj del enrutador como una fuente de estrato 4. Su valor predeterminado es el estrato 8 si se omite el número. Utiliza una referencia local de este tipo solo cuando no exista una fuente mejor, como en un laboratorio aislado.

Consulta show ntp status para comprobar la sincronización y el estrato local. Si la fuente es de estrato 2, el cliente sincronizado pasa a ser de estrato 3. En show ntp associations, un asterisco marca la fuente seleccionada. Deja pasar varios minutos para que una nueva asociación se estabilice antes de considerar el estado inicial sin sincronizar como un fallo persistente.

NTP distribuye UTC. La configuración de zona horaria y horario de verano del dispositivo controla la hora local mostrada. Por ejemplo, clock timezone CET 1 establece en IOS un desfase estándar de una hora. Un error de un número exacto de horas apunta a los ajustes de visualización. Muchas organizaciones registran los eventos en UTC para evitar conversiones entre sedes durante un incidente.

Protege la hora y elige la precisión necesaria

La autenticación con clave simétrica limita las fuentes horarias aceptadas a las que comparten la clave configurada. La seguridad del tiempo de red (NTS) utiliza un intercambio de claves basado en TLS por TCP 4460 y después autentica los paquetes NTP, que siguen viajando por UDP 123. Restringe también qué hosts pueden consultar o controlar los servicios horarios.

El protocolo de tiempo de precisión (PTP, IEEE 1588) sigue un reloj maestro principal y utiliza marcas de tiempo de hardware en tarjetas de red y conmutadores para alcanzar una precisión inferior al microsegundo en redes locales adecuadas. Atiende necesidades como las de las redes móviles y el control industrial, donde la precisión del NTP convencional, del orden de milisegundos, es insuficiente. PTP puede funcionar sobre Ethernet o IP; el transporte IP utiliza UDP 319 para mensajes de eventos y UDP 320 para mensajes generales. SNTP es una implementación más sencilla de NTP para clientes con necesidades horarias menos exigentes.

SNMP, el protocolo simple de gestión de red, permite que un gestor de supervisión lea datos de un agente en un dispositivo. Los datos se describen mediante una base de información de gestión (MIB). Cada objeto tiene un identificador de objeto (OID), una ruta de números separados por puntos en un árbol. Por ejemplo, 1.3.6.1.2.1.1.5.0 identifica sysName; 1.3.6.1.2.1.1.3.0 identifica sysUpTime. Los objetos de los fabricantes están bajo la rama de empresas, 1.3.6.1.4.1.

Combina el sondeo programado con alertas

El agente escucha solicitudes en UDP 161. El gestor recibe notificaciones sin y con confirmación en UDP 162.

Un gestor puede sondear el tráfico, la CPU y la memoria cada 5 minutos para generar gráficos. Una notificación sin confirmación puede informar de inmediato sobre un enlace fallido. Utiliza ambos métodos: las notificaciones pueden perderse por UDP y un dispositivo fallido puede ser incapaz de enviar ninguna. Las notificaciones con confirmación se reintentan según los ajustes de tiempo de espera y reintentos, pero aún pueden fallar cuando se agotan los reintentos.

Elige una versión segura

SNMPv1 y v2c envían una cadena de comunidad en texto sin cifrar. El acceso de solo lectura (RO) permite lecturas; el de lectura y escritura (RW) también permite los cambios admitidos. La versión 2c añade GetBulk, notificaciones con confirmación y contadores de alta capacidad. SNMPv3 utiliza cuentas con los niveles de seguridad noAuthNoPriv, authNoPriv y authPriv. Da preferencia a authPriv, que autentica y cifra los mensajes, cuando sea compatible.

Una configuración v2c de IOS puede utilizar snmp-server community N3tM0n-RO RO 10 para restringir las lecturas mediante la ACL 10. snmp-server host 192.0.2.50 version 2c N3tM0n-RO selecciona el receptor de notificaciones y snmp-server enable traps activa las notificaciones sin confirmación. Un ejemplo de v3 es:

snmp-server group NMS v3 priv
snmp-server user monitor NMS v3 auth sha <auth-password> priv aes 128 <priv-password>

Evita comunidades predeterminadas como "public" y "private", limita el acceso a los hosts de gestión y concede acceso de escritura solo cuando sea necesario. SNMP ofrece acceso a objetos MIB; no es un intérprete de comandos remoto.

Convierte el cambio de un contador en un porcentaje de utilización

Los contadores miden bytes acumulados, también llamados octetos. Supón que ifHCInOctets aumenta de 18 250 000 000 a 19 750 000 000 en 300 segundos:

1. Resta las lecturas: llegaron 1 500 000 000 bytes.
2. Multiplica por 8: llegaron 12 000 000 000 bits.
3. Divide entre 300 segundos: 40 000 000 bit/s, o 40 Mbit/s.
4. Divide entre la tasa del enlace de 100 Mbit/s: el porcentaje medio de utilización entrante fue del 40 %.

Es una media del intervalo, por lo que los picos breves pueden ser mayores. Olvidar el factor de conversión de bytes a bits da una tasa ocho veces menor.

Un contador de 32 bits llega a 4 294 967 295 y vuelve a cero. A 1 Gbit/s da la vuelta en unos 34 segundos, por lo que un intervalo de sondeo de 5 minutos puede pasar por alto varias vueltas. Utiliza ifHCInOctets e ifHCOutOctets de 64 bits, compatibles con v2c y v3, para los enlaces rápidos. Comprueba la continuidad del contador antes de interpretar una diferencia negativa como tráfico negativo.

Syslog envía mensajes de eventos a un recopilador central. La recopilación central conserva las pruebas tras los reinicios de los dispositivos y permite a un técnico buscar en varios dispositivos a la vez. Un sistema de gestión de información y eventos de seguridad (SIEM) puede utilizar esos registros para correlacionar eventos.

El syslog tradicional utiliza UDP 514. El transporte TCP proporciona acuses de recibo en la capa de transporte; TLS por TCP 6514 también protege la conexión. Incluso un transporte fiable necesita que funcionen la recopilación y el almacenamiento, por lo que debes verificar que los mensajes lleguen realmente.

Interpreta correctamente el umbral de gravedad

Los niveles de syslog van del 0 al 7; los números menores indican mayor gravedad:

Un umbral configurado incluye ese nivel y todos los de mayor gravedad. logging trap warnings envía los niveles 0–4, no solo el nivel 4. El valor predeterminado del registro remoto en IOS es informativo, niveles 0–6. Activar la depuración envía todos los niveles y puede generar mucho tráfico y trabajo de procesamiento.

Distingue la categoría de origen de la gravedad

La categoría de origen de syslog identifica una categoría de fuente. Algunos ejemplos son kern (0), user (1), mail (2) y auth (4). De local0 a local7, códigos 16–23, están disponibles para uso local; los dispositivos Cisco utilizan local7 de forma predeterminada. Un recopilador puede clasificar los mensajes de dispositivos de red mediante ese código.

La prioridad de un mensaje combina ambos campos:

Local7 con gravedad 3 produce 187, escrito como "<187>". El número es una pareja codificada, no una escala de gravedad independiente.

El patrón visible de los mensajes Cisco es "%FACILITY-SEVERITY-MNEMONIC: description". En "%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down", LINEPROTO identifica la función de IOS, 5 significa aviso y UPDOWN identifica el evento. Este nombre de función es distinto de la categoría de origen local7 del transporte. "%SYS-5-CONFIG_I: Configured from console by admin on vty0" registra un cambio de configuración.

Elige destinos y alinea las marcas de tiempo

Los destinos tienen ajustes independientes. logging buffered 16384 informational mantiene un búfer en memoria, que se consulta con show logging. logging host 192.0.2.50 selecciona un recopilador. logging trap warnings establece su umbral. En una sesión de terminal remoto, terminal monitor muestra los mensajes supervisados. La salida de depuración a la consola puede sobrecargar la CPU de un dispositivo ocupado.

Utiliza service timestamps log datetime msec para añadir fecha y marcas de tiempo con milisegundos, y NTP para sincronizar los relojes. La caída de un puerto a las 10:42:13.208, la pérdida de un vecino de un enrutador a las 10:42:13.350 y la recuperación del puerto a las 10:42:17.511 forman una secuencia útil. Sugieren un problema de enlace relacionado que conviene investigar; por sí solos no identifican un cable defectuoso. Sin una hora común, el orden aparente puede reflejar simplemente un error de los relojes.

Una llamada de voz y una transferencia de archivos reaccionan de forma distinta a la congestión. Un archivo puede esperar mientras TCP retransmite los datos que faltan. Una conversación se ve afectada cuando los paquetes llegan tarde, de forma irregular o desaparecen. La calidad de servicio (QoS) permite a la red tratar de forma distinta diferentes tipos de tráfico.

Identifica la necesidad del servicio

Importan cuatro propiedades: ancho de banda, la cantidad enviada por segundo; retardo, el tiempo de viaje de extremo a extremo; variación del retardo, la variación de ese tiempo; y pérdida, la proporción de paquetes descartados. Los objetivos de diseño habituales para voz son un máximo de 150 ms de retardo unidireccional, 30 ms de variación del retardo y 1 % de pérdida. Son objetivos de planificación para una voz interactiva utilizable, no capacidad adicional creada por una política.

QoS es un comportamiento por salto (PHB). Cada enrutador o conmutador aplica su propia política. Un paquete marcado con prioridad sigue necesitando que cada salto congestionado reconozca y atienda esa clase. Las prioridades de las colas cambian el orden de atención cuando el tráfico compite; la clasificación, el marcado y los límites de tasa pueden actuar incluso en un enlace sin congestión.

Clasifica primero y después marca

La clasificación del tráfico lo identifica mediante direcciones y puertos, una interfaz de entrada, una marca existente o el reconocimiento de aplicaciones, como Cisco NBAR. El marcado del tráfico escribe un valor en una trama o paquete para que los dispositivos posteriores puedan identificar su clase con poco procesamiento.

DSCP ocupa seis bits del byte ToS de IPv4 o de la clase de tráfico de IPv6. Los dos bits restantes son ECN, notificación explícita de congestión. CoS no puede aparecer en una trama enviada sin la etiqueta VLAN.

Descifra los valores DSCP habituales

Mejor esfuerzo es 0. El reenvío acelerado (EF) es 46, 101110 en binario, y suele utilizarse para el tráfico de voz. El reenvío asegurado (AFxy) identifica la clase x, de 1–4, y la precedencia de descarte y, de 1–3:

Así, AF11, AF21, AF31 y AF41 son 10, 18, 26 y 34. Para AF32, calcula 8 por 3 más 2 por 2 para obtener 28. Dentro de la clase 4, AF43 (38) tiene mayor precedencia de descarte que AF42 (36), que a su vez la tiene mayor que AF41 (34). Una precedencia de descarte mayor significa mayor preferencia de descarte durante la congestión, no mejor protección. La política configurada determina los recursos entre distintas clases AF.

Los selectores de clase utilizan 8 por su número: CS3 es 24 y suele utilizarse para señalización de llamadas; CS6 es 48 y suele utilizarse para tráfico de enrutamiento.

Decide en las marcas de quién confiar

En un límite de confianza, la red decide qué marcas entrantes respetará. Un conmutador de acceso puede confiar en un teléfono IP y volver a marcar el tráfico de la computadora conectada como mejor esfuerzo. De lo contrario, un usuario podría marcar una descarga grande como EF y competir con las llamadas. Los servicios habituales de los proveedores de internet generalmente no conservan de extremo a extremo el tratamiento QoS de un cliente.

Para dimensionar la capacidad de voz, incluye las cabeceras. Una llamada G.711 que envía 50 paquetes por segundo, cada uno con 160 bytes de voz más 40 bytes de cabeceras, utiliza 200 bytes por paquete. Multiplicar por 8 y después por 50 da 80 000 bit/s, u 80 kbit/s por sentido. Veinte llamadas utilizan 1,6 Mbit/s en cada sentido en la capa IP, antes de la sobrecarga de la capa 2.

La congestión comienza cuando los paquetes llegan más rápido de lo que una interfaz puede enviarlos. Una LAN de 1 Gbit/s que alimenta una WAN de 100 Mbit/s puede crear este cuello de botella aunque la propia LAN tenga poca carga. Los paquetes en espera entran en una cola de salida; el tiempo que pasan en ella añade retardo.

Selecciona el siguiente paquete que se enviará

FIFO, primero en entrar, primero en salir, envía los paquetes en orden de llegada. El encolamiento justo ponderado basado en clases (CBWFQ) proporciona a las clases de tráfico proporciones mínimas de ancho de banda durante la congestión. El encolamiento de baja latencia (LLQ) añade una cola de prioridad estricta para el tráfico sensible al retardo, con un límite configurado para proteger a las demás clases.

En una WAN de 100 Mbit/s, una política podría asignar una clase prioritaria de 10 Mbit/s a la voz, garantizar el 30 % a las aplicaciones empresariales y dejar el resto al tráfico predeterminado. Una garantía de ancho de banda es una proporción mínima cuando hay competencia, no necesariamente un máximo cuando las otras clases están inactivas. El límite de prioridad evita que el tráfico de voz consuma todo el enlace congestionado.

Descarta antes de que todas las colas se llenen a la vez

El descarte al final de la cola elimina los paquetes nuevos cuando una cola está llena. Si muchos flujos TCP sufren esa pérdida juntos, todos pueden reducir la velocidad y volver a acelerarse al mismo tiempo. Esta sincronización global desperdicia capacidad.

La detección temprana aleatoria ponderada (WRED) comienza a descartar paquetes seleccionados antes de que se llene la cola. Así, los flujos reducen su ritmo en momentos distintos. Una política que tenga en cuenta DSCP puede descartar AF13 con mayor facilidad que AF11 porque ambos pertenecen a la clase 1, pero AF13 tiene mayor precedencia de descarte. La voz UDP no reduce su tasa de envío como respuesta a esa pérdida, por lo que WRED no es el tratamiento habitual de la cola de prioridad de voz.

Distingue la limitación de la conformación

Un proveedor puede limitar a la tasa de información comprometida (CIR). Las ráfagas que superen lo contratado pueden descartarse aunque el puerto físico sea más rápido. TCP puede mostrar un patrón de dientes de sierra al recuperarse y volver a reducir su ritmo.

Un conformador almacena localmente las ráfagas en un búfer y libera el tráfico a la tasa configurada. Su cantidad de ráfaga permitida por intervalo es:

Para 200 Mbit/s y un intervalo de 10 ms, convierte 10 ms a 0,010 s. La multiplicación da 2 000 000 bits por intervalo; la división entre 8 da 250 000 bytes.

Supón que la sede tiene una conexión de 1 Gbit/s, pero el proveedor limita a 200 Mbit/s. Conforma el tráfico saliente de la sede a 200 Mbit/s y aplica la cola de voz dentro de ese conformador. Así, la espera se produce donde la sede controla la prioridad, antes de que el proveedor descarte los paquetes sobrantes.

Aplica e inspecciona la política

En IOS, un class-map identifica el tráfico, un policy-map define las acciones y service-policy asocia la política a una interfaz y un sentido. Una política de colas solo cambia la competencia durante la congestión. La limitación y la conformación siguen imponiendo su tasa configurada en un enlace que, por lo demás, está desocupado. Las colas sobredimensionadas pueden empeorar el retardo de voz al aumentar el tiempo de espera.

Un proxy recibe una solicitud y realiza otra independiente hacia su destino. El cliente se conecta al proxy y el proxy se conecta al destino. Esta función en el nivel de aplicación le permite filtrar, almacenar en caché o dirigir solicitudes. En cambio, NAT reescribe las direcciones de los paquetes sin actuar como el servidor que gestiona las solicitudes de la aplicación.

Pregúntate a quién representa el proxy

Un proxy directo puede proporcionar una única salida controlada a internet para los usuarios de una organización. Un proxy inverso puede publicar www.example.com en 203.0.113.10 y reenviar las solicitudes a servidores internos como 10.1.1.21 y 10.1.1.22. A quién representa es la diferencia que los define.

Configura o intercepta el tráfico del cliente

Un proxy explícito es conocido por el cliente. Su dirección y puerto, como 10.0.0.8 en 3128 u 8080, pueden introducirse manualmente, distribuirse mediante software de gestión o seleccionarse mediante un archivo PAC, de configuración automática de proxy. WPAD ayuda a descubrir automáticamente la configuración del proxy. Estos números de puerto son opciones habituales, no requisitos universales para todos los proxies.

Un proxy transparente recibe tráfico redirigido por la red sin ajustes de proxy en el cliente. Puede seguir siendo un proxy directo porque actúa en nombre de los clientes. El conocimiento del cliente y a quién representa el proxy son dos comparaciones distintas.

Comprende qué ocurre con HTTPS

Con un proxy explícito, un cliente puede enviar una solicitud CONNECT. El proxy establece un túnel por el que pasa el tráfico cifrado. El proxy puede ver el destino solicitado, pero el túnel por sí solo no revela el contenido HTTP protegido.

Para inspeccionar ese contenido, el proxy debe realizar una interceptación TLS. Crea conexiones protegidas independientes y presenta certificados firmados por la autoridad de certificación de la organización. Los clientes deben confiar en esa autoridad. Las aplicaciones con fijación de certificados pueden rechazar este certificado sustituto, por lo que algunos destinos necesitan quedar exentos de inspección. La interceptación también cambia quién puede leer el tráfico, lo que incorpora la privacidad a la decisión de diseño.

Un proxy de caché solo puede reutilizar respuestas cuando las reglas de caché HTTP lo permiten. Las descargas repetidas de software o los recursos estáticos pueden ahorrar ancho de banda WAN. Los datos personales o que cambian con frecuencia a menudo no pueden compartirse desde una caché. Los túneles cifrados convencionales no dan al proxy acceso al contenido necesario para esa inspección y almacenamiento en caché.

Diagnostica un fallo específico del proxy

Si la navegación falla mientras otras aplicaciones funcionan, examina la dirección, el puerto y la accesibilidad del proxy. Si falla la configuración automática, prueba el acceso al archivo PAC. Si los sitios internos solo fallan al pasar por el proxy, comprueba las reglas de exclusión: un patrón como *.corp.example.com puede mantener esas solicitudes en la ruta interna.

Para los servicios web entrantes, un proxy inverso puede enviar /api a un servidor de aplicaciones y /images a un servidor de contenido estático. Si reparte las solicitudes aptas entre varios servidores de destino, también realiza balanceo de carga. La terminación centralizada de TLS simplifica la gestión de certificados, y las conexiones internas pueden volver a cifrarse cuando sea necesario.

Un balanceador de carga presenta una dirección IP virtual (VIP) a los clientes y envía el tráfico a un conjunto de servidores de destino. El cliente utiliza un único nombre de servicio mientras el conjunto aporta capacidad y tolera fallos de servidores individuales. Para el mantenimiento, el drenaje de conexiones detiene las conexiones nuevas a un servidor y deja terminar el trabajo existente antes de retirarlo.

Comprueba el servicio antes de enviarle trabajo

Una comprobación de estado debe corresponder al servicio que necesitan los clientes. El ping comprueba si un host responde, una comprobación TCP verifica si un puerto acepta conexiones y una comprobación HTTP puede probar una página como /health para obtener el código de estado 200. Un host puede responder al ping incluso después de que se bloquee su proceso web.

Para shop.example.com, supón que la VIP es 203.0.113.20 en el puerto 443 y el conjunto es 10.1.2.11–10.1.2.13 en el puerto 8080. Las comprobaciones se ejecutan cada 5 segundos y marcan un servidor como no disponible tras tres fallos consecutivos. La detección tarda aproximadamente tres intervalos de comprobación, unos 15 segundos, aunque el tiempo real depende de la programación de las comprobaciones y los tiempos de espera. Una vez que .13 deja de estar disponible, las conexiones nuevas van a .11 y .12. Esos servidores restantes necesitan suficiente capacidad libre para la carga adicional.

Elige cómo distribuir el trabajo

Los pesos 3:2:1 reparten 600 conexiones nuevas en 300, 200 y 100. Con cantidades activas de 12, 7 y 9, el algoritmo de menor número de conexiones elige el segundo servidor. Estos algoritmos eligen entre los servidores disponibles que superan las comprobaciones, no entre los ya retirados por las comprobaciones de estado.

Mantén disponible el estado de la sesión

La persistencia de sesión, o sesiones persistentes, devuelve a un usuario al mismo servidor cuando este almacena su sesión, como un carrito de compras. Una cookie o la dirección de origen pueden identificar al usuario. La persistencia puede hacer que la carga sea menos uniforme; si ese servidor falla, su sesión local puede perderse. Una base de datos o caché compartida permite a otros servidores recuperar la sesión y reduce la dependencia de un único servidor de destino.

Un balanceador de capa 4 utiliza direcciones y puertos para distribuir tráfico TCP o UDP sin leer el contenido de aplicación. Un balanceador de capa 7 lee información como nombres de host HTTP, rutas y cookies. Para inspeccionar contenido HTTPS termina TLS, lo que se llama descarga de TLS, y puede establecer una conexión cifrada nueva hacia el servidor de destino.

Protege también el punto de entrada

Un único balanceador de carga también puede fallar. Una pareja activo-pasivo tiene un dispositivo de reserva listo para asumir la VIP; un diseño activo-activo permite que ambos gestionen tráfico.

La asignación por turnos mediante DNS básica publica varios registros A para un nombre y rota su orden. Ofrece una distribución sencilla, pero no tiene comprobaciones integradas del estado del servicio ni elimina de inmediato las direcciones almacenadas en caché. Los clientes pueden seguir utilizando una dirección fallida hasta que se cambien los registros y venzan las cachés. El balanceo global de carga de servidores añade decisiones de estado y ubicación a las respuestas DNS, pero los tiempos de permanencia en caché siguen importando.