Blog de Tecnologia

El Servidor Sendmail

Etiquetas: Linux, Sendmail comentarios (0)

Introducción

En el servicio convencional de correo postal, el cliente se limita a enviar y recibir correo. Los pasos intermedios, es decir el transporte, el modo de entrega, el lugar de entrega, etc., son transparentes para el usuario. Esto nos muestra que hay tres partes importantes en este servicio:

• El envío del correo.
• El transporte del correo y
• La recepción del correo.

El correo electrónico (e-mail) tiene un comportamiento muy parecido. Sólo que este servicio es
un sistema automatizado de entrega de correo. Las aplicaciones que participan en este servicio
son de tecnología cliente/servidor. Bien, así como el sistema convencional tiene sus partes, el
correo electrónico también tiene sus componentes:

• El cliente del correo electrónico (remitente):
También referenciado como MUA (Mail User Agent, Agente usuario de correo).

• El agente de transporte del correo:
También referenciado como MTA (Mail Transport Agent, Agente de transporte de
correo).

• El agente de entrega del correo (destinatario):
También referenciado como MDA (Mail Delivery Agent, Agente de entrega de
correo).

En esta introducción se muestra un cuadro con una descripción breve de los componentes de
e-mail:

¿Cómo funciona el correo electrónico?

El remitente de un e-mail confecciona un mensaje usando un cliente de correo electrónico, y lo
dirige a un destinatario. Después que el cliente de correo electrónico ha enviado el mensaje, el
agente de transporte de correo (MTA) toma el relevo en el proceso. Por ejemplo, Linux Fedora
usa un programa llamado Sendmail como agente de transporte de correo predeterminado.
El agente de transporte acepta el correo que llega del agente de usuario y envía el correo a un
receptáculo servidor. El agente de entrega revisa este gran buzón, determina la dirección del
destinatario de un determinado correo y entrega el mensaje al agente de transporte que da servicio
de e-mail al receptor. El agente de entrega no es más que un cliente de correo electrónico o un
agente de usuario.
Sin embargo, según la configuración del correo entrante para un cliente determinado, a veces es
necesario un componente adicional. Puede conectarse directamente a la máquina que actúa como
servidor de correo electrónico y leer su correo en ese sistema, o puede leer su correo desde su
sistema de escritorio, usando IMAP (Internet Message Access Protocol, Protocolo de acceso a los
mensajes de Internet), o POP (Post Office Protocol, Protocolo de oficina postal).

Protocolos de correo electrónico

Para habilitar todo el proceso de correo electrónico se utilizan una variedad de protocolos de red
estándar que permiten que diferentes máquinas, a menudo ejecutando sistemas operativos diferentes y usando diferentes programas de correo, envíen y reciban correo electrónico. Los protocolos que se indican a continuación son los que más se utilizan para transferir correo electrónico de un sistema a otro.

Protocolos de transporte de correo

La entrega de correo desde una aplicación cliente a un servidor, y desde un servidor origen al
servidor destino es manejada por SMTP (Simple Mail Transfer Protocol, Protocolo simple de
transferencia de correo).

SMTP
El objetivo principal del Protocolo simple de transferencia de correo, SMTP, es transferir correo
entre servidores de correo. Sin embargo es crítico para los clientes de correo también. Para poder enviar correo, el cliente envía el mensaje a un servidor de correo saliente, el cual luego contacta al servidor de correo de destino para la entrega. Por esta razón, es necesario especificar un servidor
SMTP cuando se esté configurando un cliente de correo.
Bajo Linux Fedora, un usuario puede configurar un servidor SMTP en la máquina local para
manejar la entrega de correo. Sin embargo, también es posible configurar servidores remotos
SMTP para el correo saliente.
Un punto importante sobre el protocolo SMTP es que no requiere autenticación. Esto permite que cualquiera en la red Internet puede enviar correo a cualquiera otra persona o a grandes grupos de personas. Esta característica de SMTP es lo que hace posible el correo basura o spam. Los servidores SMTP modernos intentan minimizar este comportamiento permitiendo que sólo los hosts conocidos accedan al servidor SMTP. Los servidores que no ponen tales restricciones son llamados servidores open relay.
Linux Fedora utiliza Sendmail (/usr/sbin/sendmail) como su programa SMTP por defecto. Sin
embargo, también está disponible una aplicación más simple de servidor de correo llamada Postfix (/usr/sbin/postfix).

Protocolos de acceso a correo

Hay dos protocolos principales usados por las aplicaciones de correo cliente para recuperar correo
desde los servidores de correo: POP (Post Office Protocol, Protocolo de oficina postal) e lMAP
(Internet Message Access Protocol, Protocolo de acceso a mensajes de Internet).
A diferencia de SMTP, estos protocolos requieren autenticación de los clientes usando un nombre
de usuario y una contraseña. Por defecto, las contraseñas para ambos protocolos son pasadas a
través de la red de forma encriptada.

POP
El servidor por defecto POP bajo Linux Fedora es /usr/sbin/ipop3d y es proporcionado por el
paquete imap. Cuando utilice el protocolo POP, los mensajes de correo son descargados a través
de las aplicaciones de correo cliente. Por defecto, la mayoría de los clientes de correo POP son
configurados automáticamente para borrar el mensaje en el servidor de correo después que éste
ha sido transferido exitósamente, sin embargo esta configuración se puede cambiar.
POP es completamente compatible con estándares importantes de mensajería de Internet, tales como MIME (Multipurpose Internet Mail Extensions, Extensiones de Correo de Internet Multipropósito), el cual permite los anexos de correo.
POP funciona mejor para usuarios que tienen un sistema en el cual leer correo. También funciona
bien para usuarios que no tienen una conexión permanente a la Internet o a la red conteniendo
el servidor de correo. Desafortunadamente para aquellos con conexiones lentas, POP requiere
programas cliente que luego de la autenticación, descarguen el contenido completo de cada mensaje.
Esto puede tomar un buen tiempo si algún mensaje tiene anexos grandes.
La versión más reciente del protocolo estándar POP es POP3. Existen sin embargo, una variedad
de variantes del protocolo POP menos usadas:

Para añadir seguridad, es posible utilizar la encriptación SSL (Secure Socket Layer, Capa de
enchufes seguros) para la autenticación del cliente y las sesiones de transferencias de datos. Esto
se puede activar usando el servicio ipop3s o mediante el uso del programa /usr/sbin/stunnel.

IMAP

El servidor por defecto IMAP bajo Linux Fedora es /usr/sbin/imapd y es proporcionado por el
paquete imap. Cuando utilice un servidor de correo IMAP, los mensajes de correo se mantienen en el servidor donde los usuarios pueden leerlos y borrarlos. IMAP también permite a las aplicaciones cliente crear, renombrar o borrar directorios en el servidor para organizar y almacenar correo.
IMAP lo utilizan principalmente los usuarios que acceden su correo desde varias máquinas. El
protocolo es conveniente también para usuarios que se estén conectando al servidor de correo a
través de una conexión lenta, porque sólo la información de la cabecera del correo es descargada
para los mensajes, hasta que son abiertos, ahorrando de esta forma ancho de banda. El usuario
también tiene la habilidad de eliminar mensajes sin verlos o descargarlos.
Por conveniencia, las aplicaciones cliente IMAP son capaces de hacer caché de los mensajes
localmente, para que el usuario pueda hojear los mensajes previamente leídos cuando no se esté
conectado directamente al servidor IMAP.
IMAP, como POP, es completamente compatible con estándares de mensajería de Internet, tales
como MIME, que permite los anexos de correo.
Para seguridad adicional, es posible utilizar la encriptación SSL para la autenticación de clientes
y para las sesiones de transferencia de datos. Esto se puede activar usando el servicio imaps, o
mediante el uso del programa /usr/sbin/stunnel.
También están disponibles otros clientes y servidores de correo IMAP gratuítos así como también comerciales, muchos de los cuales extienden el protocolo IMAP y proporcionan funcionalidades adicionales.

Clasificaciones de los programas de correo
En general, todas las aplicaciones de e-mail caen en al menos una de tres clasificaciones. Cada
clasificación juega un papel específico en el proceso de mover y administrar los mensajes de correo.
Mientras que la mayoría de los usuarios sólo están al tanto del programa de correo específico que
usan para recibir o enviar mensajes, cada uno es importante para asegurar que el mensaje llegue
a su destino correcto.

Agente de usuario de correo
Un agente de usuario de correo (MUA) es sinónimo con una aplicación cliente de correo.
Un MUA es un programa que, al menos, permite a los usuarios leer y redactar mensajes de correo.
Muchos MUAs son capaces de recuperar mensajes a través de los protocolos POP o IMAP,
configurando los buzones de correo para almacenar mensajes y enviando los mensajes salientes
a un MTA.
Los MUAs pueden ser de interfaz gráfica, tal como Mozilla Mail, o tener una interfaz basada en
un texto muy sencillo, tal como mutt o pine.

Agente de transporte de correo

Un Agente de transporte de correo (MTA) transfiere mensajes de correo electrónico entre hosts
usando SMTP. Un mensaje puede envolver a muchos MTAs a medida que este se mueve hasta
llegar a su destino.
Aunque la entrega de mensajes entre máquinas puede parecer bien simple, el proceso completo
de decidir si un MTA particular puede o debería aceptar un mensaje para ser repartido, es más
bien complicado. Además, debido a los problemas de spam, el uso de un MTA particular está
usualmente restringido por la configuración del MTA o por la falta de acceso a la red MTA.
Muchos programas clientes de correo modernos pueden actuar como un MTA cuando estén
enviando correo. Sin embargo, esta acción no debería ser confundida con el papel de un MTA
verdadero. La única razón de que los programas de correo cliente son capaces de enviar mensajes
(como un MTA) es porque el host ejecutando la aplicación no tiene su propio MTA. Esto es
particularmente cierto para programas de cliente o para sistemas que no están basados en el
sistema operativo UNIX. Sin embargo, estos programas clientes sólo envían mensajes hacia
afuera hacia un MTA para el cual están autorizados a utilizar y no directamente al servidor de
correos recipiente.
Puesto que Linux Fedora instala dos MTAs, Sendmail y Postfix, los programas cliente de correo
no son comúnmente requeridos que actúen como un MTA. Linux Fedora también incluye un MTA de propósitos especiales llamado Fetchmail.

Agente de entrega de correos

Un Agente de entrega de correos (MDA) es invocado por un MTA para archivar correo entrante
en el buzón de correo del usuario. En muchos casos, el MDA es en realidad un Agente de entregas
local (LDA, Local Delivery Agent)), tal como mail o Procmail.
Cualquier programa que realmente maneja un mensaje para entrega al punto en que puede ser
leído por una aplicación cliente de correos se puede considerar un MDA.
Por esta razón, algunos MTAs (tales como Sendmail y Postfix) pueden tener el papel de un MDA
cuando ellos anexan nuevos mensajes de correo al archivo spool de correo del usuario. En general, los MDAs no transportan mensajes entre sistemas tampoco proporcionan una interfaz de usuario;los MDAs distribuyen y clasifican mensajes en la máquina local para que sea accedida por una aplicación cliente de correo.

Agentes de transporte de correo

Linux Fedora incluye dos tipos primarios de MTAs:

• Sendmail y
• Postfix.

Sendmail es configurado como el MTA por defecto, aún cuando es fácil cambiar el MTA
predeterminado a Postfix.

Linux Fedora también incluye un MTA de propósitos especiales llamado Fetchmail, el cual es
usado para entregar correo desde un MTA remoto a uno local.
Los propósitos de esta sección sólo se centrarán en el MTA Sendmail.

Sendmail

Muchos administradores de red eligen a Sendmail como su MTA por defecto debido a su poder
y escalabilidad. Sendmail transfiere correo de forma segura entre hosts, usando el protocolo
SMTP.

La instalación de Sendmail por defecto

El ejecutable de Sendmail es /usr/sbin/sendmail.
El archivo de configuración largo y detallado de Sendmail es /etc/mail/sendmail.cf.

Evite modificar este archivo sendmail.cf directamente.
En vez de esto, para hacer cambios enla configuración, edite el archivo /etc/mail/sendmail.mc, cree una copia de respaldo del original /etc/mail/sendmail.cf, y luego use el procesador de macros incluido m4 para crear un nueva /etc/mail/sendmail.cf.

Varios archivos de configuración de Sendmail son instalados en el directorio /etc/mail/
incluyendo:

Muchos de los archivos de configuración en /etc/mail/, tales como access, domaintable, mailertable
y virtusertable, deben en realidad almacenar su información en archivos de bases de datos antes
de que Sendmail puede usar algún cambio de configuración. Para incluir cambios hechos a estas
configuraciones en sus archivos de bases de datos, ejecute el comando:

makemap hash /etc/mail/ < /etc/mail/

Donde:
es reemplazado con el nombre del archivo de configuración a convertir.

Por ejemplo, para tener todos los correos direccionados al dominio example.com entregados a

, añada la línea siguiente al archivo virtusertable:

@example.com bob@other-example.com

Para finalizar el cambio, el archivo virtusertable.db debe ser actualizado usando el comando
siguiente como root:

makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable

Esto crea un nuevo archivo virtusertable.db conteniendo la nueva configuración.

Cambios comunes de configuración de Sendmail

Cuando se esté alterando el archivo de configuración de Sendmail, es mejor generar un archivo
completamete nuevo /etc/mail/sendmail.cf en vez de modificar el existente.

Nota:
Antes de cambiar el archivo sendmail.cf, es una muy buena idea hacer una copia de respaldo del archivo en funcionamiento.

Para añadir funcionalidad a Sendmail, modifique el archivo /etc/mail/sendmail.mc. Cuando termine, utilice el procesador de macros m4 para generar un nuevo sendmail.cf ejecutando el comando:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf.

Después de crear un nuevo archivo /etc/mail/sendmail.cf, reinicie Sendmail para que tomen efectolos cambios. La forma más fácil de hacer esto es escribiendo el comando /sbin/service sendmail restart como root.
Por defecto, el procesador de macros m4 es instalado con Sendmail pero es parte del paquete
m4.

Nota:
El archivo por defecto sendmail.cf no permite que Sendmail acepte conexiones de red desde ningún host,más que la máquina local. Para configurar Sendmail como un servidor para otros clientes, modifique /etc/mail/sendmail.mc y cambie DAEMON_OPTIONS para que también escuche en dispositivos de red o coloque en comentarios toda esta opción. Luego, vuelva a generar /etc/mail/sendmail.cf ejecutando:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Esta configuración debería de funcionar para la mayoría de los sitios sólo SMTP. No funcionará
para sitios UUCP (copia UNIX a UNIX); debe generar un nuevo sendmail.cf si se está usando
transferencias de correo UUCP.

Consulte el archivo /usr/share/sendmail-cf/README antes de modificar cualquier archivo
en los directorios bajo el directorio /usr/share/sendmail-cf, pues ellos pueden afectar la futura
configuración de los archivos /etc/mail/sendmail.cf.

Creación de máscaras

Una configuración común de Sendmail es tener una sola máquina actuando como el gateway
de correo para todas las máquinas en la red. Por ejemplo, una compañía puede querer tener una
máquina llamada mail.bigcorp.com que maneja todo su correo y asigna una dirección de retorno
consistente para todo el correo saliente.

En esta situación, el servidor Sendmail debe enmascarar los nombres de las máquinas en la red
de la compañía para que la dirección de retorno sea user@bigcorp.com en vez de user@devel.
bigcorp.com.

Para hacer esto, añada las líneas siguientes /etc/mail/sendmail.mc:

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain’)
FEATURE(`masquerade_envelope’)
FEATURE(`allmasquerade’)
MASQUERADE_AS(`bigcorp.com.’)
MASQUERADE_DOMAIN(`bigcorp.com.’)
MASQUERADE_AS(bigcorp.com)

Después de generar un nuevo sendmail.cf usando m4, esta configuración hará que todo el correo
dentro de la red aparezca como que si hubiese sido enviado desde bigcorp.com.

Detener el correo basura

El correo basura se puede definir como correo no deseado e innecesario recibido por un usuario
que nunca solicitó tal comunicación. Es un abuso costoso y molesto de las comunicaciones de
Internet estándar.
Sendmail hace relativamente fácil bloquear nuevas técnicas de difusión de correo basura. Hasta
bloquea por defecto muchos de los métodos comunes de difusión de correo basura.
Por ejemplo, el reenvío de mensajes SMTP, también conocido como relaying, ha sido desactivado
por defecto desde Sendmail versión 8.9. Antes de que se produjese este cambio, Sendmail indicaba al host (x.org) que aceptará mensajes desde un partido (y.com) y que los enviará a un partido diferente (z.net). Ahora, sin embargo, Sendmail debe ser configurado para permitir a cualquier dominio que transmita correo a través del servidor. Para configurar dominios de transmisión, modifique el archivo /etc/mail/relay-domains y reinicie Sendmail.
Sin embargo, en muchas ocasiones, los usuarios reciben bombardeos de correo basura de otros
servidores a través de Internet. En estos casos, puede utilizar las funciones de control de acceso
de Sendmail que están disponibles en el archivo /etc/mail/access para prevenir conexiones desde host indeseados. El ejemplo siguiente ilustra como este archivo puede ser usado para bloquear y también para permitir el acceso al servidor Sendmail:

badspammer.com ERROR:550 “Go away and do not spam us anymore”
tux.badspammer.com OK
10.0 RELAY

Este ejemplo indica que cualquier correo enviado desde badspammer.com es bloqueado con un
código de error 550 RFC-821, con un mensaje para el emisor. Los correos enviados desde el subdominio
tux.badspammer.com, serán aceptados. La última línea muestra que cualquier correo
enviado desde la red 10.0.*.* se puede transmitir a través del servidor de correo.
Debido a que /etc/mail/access.db es una base de datos, use makemap para activar los cambios.
Haga esto usando el comando siguiente como root:

makemap hash /etc/mail/access < /etc/mail/access

Como puede imaginarse, este ejemplo sólo analiza una mínima parte de lo que Sendmail puede
realizar en cuanto a permitir o bloquear el acceso. Consulte /usr/share/doc/sendmail/README.
cf para más información y ejemplos.
Puesto que Sendmail llama a Procmail MDA cuando está entregando correo, también es posible
usar un programa de filtrado de correo basura, tal como SpamAssassin para identificar y archivar
correo basura por los usuarios.

Agentes de usuario de correo

Hay muchos programas de correo disponibles bajo Linux Fedora. Hay programas gráficos de
clientes de correo con características completas, tales como Mozilla Mail o Ximian Evolution,
así como también programas basados en texto, tales como mutt y pine.
El resto de esta sección se enfoca en asegurar la comunicación entre el cliente y el servidor.

Comunicación segura

Los MUAs populares incluidos con Linux Fedora, tales como Mozilla Mail, mutt y pine, ofrecen
sesiones encriptadas con SSL.
Al igual que otros servicios existentes en una red no cifrada, la información de correo electrónico
importante, como nombres de usuario, contraseñas y mensajes, se puede interceptar y ver sin quetenga conocimiento el servidor o el cliente de correo. Al usar los protocolos estándar POP e IMAP,toda la información de autenticación se envía “limpiamente”, sin encriptar, por lo que es posiblepara un intruso ganar acceso a las cuentas de usuarios reuniendo los nombres de los usuarios y sus contraseñas cuando estos son transmitidos sobre la red.

Clientes de correo electrónico seguros

Afortunadamente, la mayoría de los agentes MUA de Linux están diseñados para comprobar
el correo mediante SSL. Para usar SSL al recuperar el correo, se debe activar esta opción en el
cliente y en el servidor de correo.
SSL se activa muy fácilmente en el cliente, normalmente basta con pulsar un botón en el área
de configuración del agente MUA o mediante una opción en el archivo de configuración del
MUA. Los protocolos IMAP y POP seguros tienen números de puerto conocidos (993 y 995,
respectivamente) que MUA utiliza para autenticar y descargar los mensajes.

Asegurar las comunicaciones de cliente de correo

Ofrecer cifrado SSL a los usuarios de IMAP y POP del servidor de correo es muy sencillo.
Primero, cree un certificado SSL. Esto se puede hacer de dos formas: solicitando a una Certificate
Authority (CA) por un certificado SSL o mediante la creación de un certificado auto-firmado.

Atención:
Los certificados auto-firmados solamente deberían ser usados para propósitos de prueba. Cualquier servidor usado en un ambiente de producción debería usar un certificado SSL emitido por una CA.

Para crear un certificado SSL con firma propia para IMAP, cambie al directorio /usr/share/ssl/certs/
y escriba el comando siguiente como root:

make imapd.pem

Conteste todas las preguntas para completar el proceso.
Para crear un certificado SSL con firma propia para POP, cambie al directorio /usr/share/ssl/certs/, y escriba el comando siguiente como usuario root:

make ipop3d.pem

Una vez más, conteste todas las preguntas para completar el proceso. Una vez terminado, use
el comando /sbin/service para iniciar el demonio apropiado (imaps o pop3s). Luego, configure
el servicio imaps o pop3s para que arranquen en los niveles de ejecución apropiados. Use por
ejemplo la Herramienta de configuración de servicios (system-config-services).
Alternativamente, el comando stunnel puede ser usado como una envoltura de criptación SSL
con el estándar, para los demonios no seguros, imapd o pop3d.
El programa stunnel utiliza librerías OpenSSL externas incluídas con Red Hat Linux para
proporcionar criptografía robusta y proteger las conexiones. Es mejor solicitar a una Certificate
Authority (CA) por un certificado SSL, pero es posible crear un certificado auto-firmado.
Para crear un certificado SSL auto-firmado, cámbiese al directorio: /usr/share/ssl/certs/
y escriba el comando siguiente:

make stunnel.pem

Una vez más, conteste todas las preguntas para completar el proceso.
Una vez que el certificado es generado, es posible usar el comando stunnel para iniciar el demonio
de correo imapd usando el comando siguiente:

/usr/sbin/stunnel -d 993 -l /usr/sbin/imapd imapd

Una vez que este comando es emitido, es posible abrir un cliente de correo IMAP y conectarse
al servidor de correo usando una encriptación SSL.
Para arrancar pop3d usando el comando stunnel, escriba el comando siguiente:

/usr/sbin/stunnel -d 993 -l /usr/sbin/pop3d pop3d

Para más información sobre el uso de stunnel, lea la página man stunnel o refiérase a los documentos
en el directorio /usr/share/doc/stunnel-/.

¿Que es DNS ? - Linux

Etiquetas: DNS, Fedora Core comentarios (0)

Introducción

Un usuario conectado a Internet que desea acceder a determinados sitios web, introduce una
dirección web, en el campo dirección de su “navegador” (browser). Esta dirección tiene un formato
especial basado en un estándar denominado: nombre de dominio completamente cualificado
(FQDN), el cual está asociado a un número IP.
Para un usuario es más fácil recordar un nombre de dominio que un grupo de números que
identifican la dirección IP.
Este nombre de dominio es convertido, por un servicio de Internet, en una dirección IP que es la
forma de cómo se comunican los sistemas en Internet. Este servicio se denomina Domain Name
Service (DNS) o servidor de nombres.
El DNS es el sistema empleado en Internet para asignar y usar universalmente nombres únícos
para referirse a los equipos conectados a la red. En realidad la red Internet es una red de sistemas
DNS.

Técnicamente un DNS es:

• Una base de datos distribuida jerárquicamente por toda la red Internet.

• Un sistema de tecnología cliente/servidor que aglutina nombres, protocolos y servicios.

• Convierte los nombres de computadoras en direcciones numéricas IP y viceversa.
Linux Fedora incluye un servidor DNS denominado Berkeley Internet Name Domain
(BIND).

Algo más sobre DNS y FQDN

El uso de nombres de dominio completamente cualificado permite a los administradores del
sistema, flexibilidad a la hora de cambiar las direcciones IP para máquinas individuales sin realizar
preguntas sobre el nombre en las máquinas. Por otro lado, los administradores pueden revolver
cuáles máquinas manejan consultas basadas en nombre.
DNS es normalmente implementado usando servidores centralizados que autorizan algunos
dominios y se refieren a otros servidores DNS para otros dominios.
Cuando un cliente solicita información a un servidor de nombres, usualmente se conecta al
puerto 53 de este. El nombre de servidor luego intenta resolver el FQDN basado en su librería de
resolución, la cual puede contener información de autorización sobre el host solicitado o datos
en caché de una consulta anterior.

Si el nombre del servidor no tiene la respuesta en su librería de resolución, consultará otros
nombres de servidores, llamados servidores de nombres de root, para determinar qué servidores
de nombres son fidedignos para el FQDN en cuestión.
Luego, con esa información, consulta los servidores de nombres autorizados para determinar la
dirección IP del pedido del cliente. Si se está realizando una búsqueda inversa, se usa el mismo
procedimiento, excepto que la consulta es realizada con una dirección IP desconocida en vez de
un nombre.

Componentes del DNS
El DNS utiliza tres componentes principales:

• Clientes DNS (resolvers): Los clientes DNS envían las peticiones de resolución de nombres
a un servidor DNS. Las peticiones de nombres son preguntas de la forma: ¿Qué dirección IP
le corresponde al nombre nombre.dominio?

• Servidores DNS (name servers): Los servidores DNS contestan a las peticiones de los clientes
consultando su base de datos. Si no disponen de la dirección solicitada pueden reenviar la
petición a otro servidor.

• Espacio de nombres de dominio (domain name space): Se trata de una base de datos
distribuida entre distintos servidores.

Espacio de nombres de dominio del DNS

El espacio de nombres de dominio es una estructura jerárquica que tiene la forma de un árbol.
Los distintos dominios de ese árbol están clasificados en niveles. A continuación un resumen de
esos niveles:

• Dominios de nivel raíz:

o Es la parte más alta en la jerárquia de autoridad.
o Este dominio utiliza una etiqueta nula y para referenciarla se usa un punto (.).

• Dominios del primer nivel:

o Pueden contener sub-dominios y computadoras.
o Parten del dominio raíz.
o Los dominios de primer nivel (Top-Level Domains) han sido clasificados tanto en
función de su estructura organizativa como geográficamente.

Véase a continuación:

En función de su estructura organizativa:

Geograficamente :

• Dominios del segundo nivel:
o Pueden contener sub-dominios y computadoras.
o Parten de un dominio de primer nivel.

A continuación se muestra una pequeña parte del espacio de nombres de dominio de Internet:

Un nombre de dominio es una secuencia de nombres separados por el carácter delimitador punto.

Por ejemplo:

fedora3.iciuni.edu.pe, el computador servidor Linux Fedora: fedora3, pertenece al
dominio: Instituto de Ciencias de la Información de la Universidad Nacional de Ingeniería, que
a su vez pertenece al dominio educación y éste a su vez, al dominio pe (Perú).

Zonas de autoridad:

Es una porción del espacio de nombre de dominio del cual una computadora se hace responsable.
La zona de autoridad de estos servidores abarca al menos un dominio y también pueden incluir
sub-dominios; aunque generalmente los servidores de un dominio delegan sus sub-dominios en
otros servidores.

Zonas de servidores de nombres

En Internet, la dirección de una computadora se puede analizar en diversas secciones y estas
secciones se analizan a su vez por orden jerárquico.
El siguiente ejemplo está intrínsecamente relacionado con la figura 25.1. Observe el siguiente
nombre de dominio completamente cualificado (FQDN):
ventas.nicole.ichhas.com

Lea el nombre de derecha a izquierda, con cada nivel de la jerarquía dividido por puntos. En
nuestro ejemplo, com define el dominio de primer nivel para este FQDN. El nombre ichhas es un
sub-dominio bajo com, mientras que nicole es un sub-dominio bajo ichhas. El nombre más hacia
la izquierda, ventas, identifica una máquina específica.

El nombre anterior también se puede analizar por secciones (vea esto en la figura 25.2.). Observe

que ichhas.com es una sección del espacio de nombres de dominio; a cada sección se le denomina
zona. Luego la zona es: ichhas.com
La otra sección o zona es: nicole.ichhas.com
A esta zona pertenece la máquina ventas.

Las zonas son definidas en servidores de nombres autorizados a través del uso de archivos de
zona, que describen el espacio de nombres de esa zona, los servidores de correo a ser utilizados
por un dominio particular o sub-dominio, y más.
Los archivos de zona son almancenados en servidores de nombres primarios (también llamados
servidores de nombres maestro), los cuales son verdaderamente autorizados y son ellos los que
hacen los cambios a los archivos.

Los servidores de nombres secundarios (también llamados servidores de nombres esclavos),
reciben sus archivos de zona desde los servidores de nombres primarios.
Cualquier servidor de nombres puede ser un servidor primario y secundario para zonas diferentes
al mismo tiempo, y también pueden ser considerados autoritarios para múltiples zonas. Todo
depende de cómo se configure el servidor de nombres.

Tipos de servidores de nombres

Existen cuatro tipos de configuración de servidores de nombres primarios:

Un servidor de nombres puede ser uno o más de estos tipos. Por ejemplo, un servidor de nombres puede ser un maestro para algunas zonas, un esclavo para otras y sólo ofrecer el reenvío de resoluciones para otras.

Resolución de nombres de dominio

La resolución de un nombre de dominio es la traducción del nombre a su correspondiente dirección
IP. Para este proceso de traducción los resolvers pueden formular dos tipos de preguntas (recursivas
e iterativas).

Preguntas recursivas: Si un cliente formula una pregunta recursiva a un servidor DNS, éste
debe intentar por todos los medios resolverla aunque para ello tenga que preguntar a otros
servidores.

Preguntas iterativas: Si, en cambio, el cliente formula una pregunta iterativa a un servidor DNS,este servidor devolverá o bien la dirección IP si la conoce o si no, la dirección de otro servidor que sea capaz de resolver el nombre.

Veamos un ejemplo: Estamos trabajando con Internet Explorer y escribimos en la barra de
dirección: www.fedoracore.com. En primer lugar, el navegador tiene que resolver el nombre de
dominio a una dirección IP. Después podrá comunicarse con la correspondiente dirección IP, abrir una conexión TCP con el servidor y mostrar en pantalla la página principal de fedoracore. La siguiente gráfica muestra el esquema de resolución:

1. Nuestro computadora (cliente DNS) formula una pregunta recursiva a nuestro servidor
DNS local (generalmente el proveedor de servicios de Internet).

2. El servidor local es el responsable de resolver la pregunta, aunque para ello tenga que reenviar
la pregunta a otros servidores. Suponemos que no conoce la dirección IP asociada a www.
fedoracore.com; entonces formulará una pregunta iterativa al servidor del dominio raíz.

3. El servidor del dominio raíz no conoce la dirección IP solicitada, pero devuelve la dirección
del servidor del dominio com.

4. El servidor local reenvía la pregunta iterativa al servidor del dominio com.

5. El servidor del dominio com tampoco conoce la dirección IP preguntada, aunque sí conoce
la dirección del servidor del dominio fedoracore.com, por lo que devuelve esta dirección.

6. El servidor local vuelve a reenvíar la pregunta iterativa al servidor del dominio fedoracore.
com.

7. El servidor del dominio fedoracore.com conoce la dirección IP de www.fedoracore.com y
devuelve esta dirección al servidor local.

8. El servidor local por fin ha encontrado la respuesta y se la reenvía a nuestra computadora.

Preguntas inversas:

Los clientes DNS también pueden formular preguntas inversas, esto es, conocer el nombre
de dominio dada una dirección IP. Para evitar una búsqueda exhaustiva por todo el espacio de
nombres de dominio, se ha creado un dominio especial llamado:
in-addr.arpa:

Cuando un cliente DNS desea conocer el nombre de dominio asociado a la dirección IP w.x.y.z.
formula una pregunta inversa a z.y.x.w.in-addr.arpa. La inversión de los bytes es necesaria
debido a que los nombres de dominio son más genéricos por la derecha, al contrario que ocurre
con las direcciones.

Nota:

BIND el DNS de Linux Fedora

Linux Fedora incluye un servidor DNS denominado Berkeley Internet Name Domain
(BIND).

Como se puede apreciar en el directorio /var/named/ se almacenan los archivos de zonas, cuyo
contenido está conformado por registros de recursos. En la siguiente sección se describirá algunos
de ellos.

Registros de recursos de archivos de zona

El componente principal de un archivo de zona es su registro de recursos.
Hay muchos tipos de registros de recursos de archivos de zona. A continuación le mostramos los
tipos de registros más frecuentes:

Ejemplo de archivo de zonas

Veamos, en el siguiente ejemplo básico, los registros de recursos antes mencionados integrados
en un archivo de zona.

Los servidores de nombres con autoridad se configuran como dns1.ichhas.com y dns2.ichhas.
com, cuyos registros A apuntan respectivamente a 10.0.1.2 y a 10.0.1.3. Los servidores de correo configurados con los registros MX apuntan a main y next a través de los registros CNAME.
Puesto que los nombres main y next no terminan en un punto (.), el dominio $ORIGIN es colocado
después de ellos, expandiéndolos a main.ichhas.com y a next.ichhas.com. A través de registros
de recursos relacionados A, se puede determinar sus direcciones IP. Los servicios FTP y Web,
disponibles en los nombres estándar ftp.ichhas.com y www.ichhas.com, son apuntados a los
servidores apropiados usando registros CNAME.

Archivos de zona de resolución de nombres inversa

Un archivo de zona de resolución de nombres inversa, se usa para traducir una dirección IP de
un espacio de nombres particular en un FQDN. Este archivo es muy parecido al archivo de zona
estándar, excepto que se usan registros de recursos PTR para enlazar las direcciones IP a un
nombre de dominio completamente cualificado.
En el ejemplo siguiente, las direcciones IP de la 10.0.1.20 a la 10.0.1.22 apuntan a los FQDNs
correspondientes.

Archivos creados por defecto

Conmutación de una Red Empresarial

Etiquetas: Conmutación de una Red Empresarial, redes comentarios (0)

Descripcion de la Conmutación en el nivel Empresarial

Conmutacion y segmentación de Red
Aunque en la creación de redes empresariales se utilizan tanto routers como switches, el diseño de red de la mayoría de las empresas se basa en gran parte en los switches. Los switches representan menor costo por puerto que los routers, y proporcionan envío rápido de tramas al máximo de velocidad de cable admitido.

El switch es un dispositivo muy adaptable de Capa 2. En su función más simple, reemplaza al hub como punto central de conexión de varios hosts. En una función más compleja, el switch se conecta a uno o más switches para crear, administrar y mantener enlaces redundantes y la conectividad de la red VLAN. Procesa todos los tipos de tráfico de la misma forma, sin importar su uso.

Envía tráfico basándose en las direcciones MAC. Cada switch mantiene una tabla de direcciones MAC en la memoria de alta velocidad, llamada memoria de contenido direccionable (CAM, Content Addressable Memory). El switch recrea esta tabla cada vez que se lo activa, utilizando a la vez las direcciones MAC de origen de las tramas entrantes y el número de puerto a través del cual ésta ingresó al switch.

El switch elimina las entradas de la tabla de direcciones MAC que no se utilizan dentro de determinado período de tiempo. El nombre dado a este período de tiempo es temporizador de actualización; la eliminación de una entrada se llama descarte por antigüedad.

Cuando una trama unicast ingresa a un puerto, el switch encuentra su dirección MAC de origen en la trama. Luego busca en la tabla MAC una entrada que coincida con la dirección.

Si la dirección MAC de origen no se encuentra en la tabla, el switch agrega una entrada que consta de la dirección MAC y el número de puerto, e inicia el temporizador de actualización. Si la dirección MAC de origen ya existe, el switch restablece el temporizador de actualización.

A continuación, el switch busca en la tabla la dirección MAC de destino. SI ya existe una entrada, el switch reenvía la trama al número de puerto correspondiente. Si la entrada no existe, el switch satura todos los puertos activos con la trama, con la excepción del puerto por el cual se la recibió.

En una empresa, los factores decisivos son la disponibilidad permanente, la velocidad y el rendimiento de la red. La extensión de broadcast y los dominios de colisiones afectan el flujo de tráfico. Por lo general, los dominios de colisiones y un broadcast más grande afectan estas variables críticas.

Si un switch recibe una trama de broadcast, inunda todas las interfaces activas con ésta, como sucede con una dirección MAC de destino desconocida. Todos los dispositivos que reciben este broadcast forman el dominio de broadcast. Cuantos más switches se conecten, más se incrementa el tamaño del dominio de broadcast.

Los dominios de colisiones presentan un problema similar. Cuantos más dispositivos participen en un dominio de colisión, más colisiones se producen.

Los hubs generan dominios de colisiones de gran tamaño. Los switches, por el contrario, utilizan una función llamada microsegmentación para reducir la extensión de los dominios de colisiones a un solo puerto del switch.

Cuando un host se conecta a un puerto del switch, el switch crea una conexión dedicada. Cuando dos hosts conectados se comunican entre sí, el switch analiza la tabla de conmutación y establece una conexión virtual, o microsegmento, entre los puertos.

El switch mantiene el circuito virtual hasta el final de la sesión. Al mismo tiempo hay varios circuitos virtuales activos. La microsegmentación mejora la utilización del ancho de banda al reducir las colisiones y permitir varias conexiones simultáneas.

Los switches son compatibles con la conmutación simétrica o asimétrica. Los switches cuyos puertos tienen la misma velocidad se denominan simétricos. Muchos switches, sin embargo, tienen dos o más puertos de alta velocidad. Estos puertos de alta velocidad, o puertos uplink, se conectan a las áreas que presentan mayor demanda de ancho de banda. Por lo general, estas áreas incluyen:

Conexiones a otros switches
Enlaces a servidores o granjas de servidores
Conexiones a otras redes

Las conexiones entre puertos de diferentes velocidades utilizan la conmutación asimétrica. Si es necesario, el switch almacena información en la memoria para proporcionar un búfer entre puertos de diferentes velocidades. Los switches asimétricos son comunes en entornos empresariales.

Conmutado de Multicapa

Tradicionalmente, las redes están compuestas por dispositivos separados según sean de Capa 2 o Capa 3. Cada dispositivo utiliza una técnica diferente para procesar y enviar el tráfico.

Capa 2

Los switches de Capa 2 están basados en hardware. Envían el tráfico a la velocidad de cable, mediante los circuitos internos que conectan físicamente a cada puerto entrante con todos los demás puertos. El proceso de envío utiliza la dirección MAC y la existencia de la dirección MAC de destino en la tabla de direcciones MAC. Un switch de Capa 2 limita el envío de tráfico a un único segmento o una subred dentro de la red.

Capa 3

Los routers están basados en software y utilizan microprocesadores para llevar a cabo el enrutamiento según las direcciones IP. El enrutamiento de Capa 3 permite el reenvío de tráfico entre diferentes redes y subredes. Cuando un paquete ingresa a la interfaz del router, éste utiliza software para encontrar la dirección IP de destino y seleccionar la ruta más adecuada hacia la red de destino. Luego el router conmuta el paquete a la interfaz de salida correspondiente.

La conmutación de Capa 3, o conmutación multicapa, combina la conmutación basada en hardware y el enrutamiento basado en hardware en el mismo dispositivo.

Un switch multicapa combina las funciones de un switch de Capa 2 y un router de Capa 3. La conmutación de Capa 3 se lleva a cabo en hardware especial de circuito integrado de aplicación específica (ASIC). Las funciones de envío de trama y de paquetes utilizan los mismos circuitos ASIC.

Con frecuencia, los switches multicapa guardan, o almacenan en caché, la información de enrutamiento de origen y destino del primer paquete de una conversación. Para los paquetes siguientes, no es necesario ejecutar una búsqueda de enrutamiento, ya que la información de enrutamiento se encuentra en la memoria. Esta función de almacenamiento en caché contribuye al gran rendimiento de estos dispositivos.

Tipos de Conmutacion

En los comienzos de la conmutación, un switch era compatible con uno o dos métodos importantes de envío de una trama desde un puerto hasta otro. Los dos métodos son almacenar y enviar y conmutación por método de corte. Ambos métodos tienen ventajas definidas, así como algunas desventajas.

Almacenamiento y reenvío

En este tipo de conmutación, se lee la trama completa y se la almacena en la memoria antes de enviarla al dispositivo de destino. El switch comprueba la integridad de los bits de la trama; para ello, recalcula el valor de comprobación de redundancia cíclica (CRC, Cyclic Redundancy Check). Si el valor de CRC calculado es el mismo que el valor del campo CRC de la trama, el switch envía la trama al puerto de destino. El switch no envía las tramas si los valores de CRC no coinciden. El valor de CRC está ubicado dentro del campo secuencia de verificación de trama (FCS, Frame Check Sequence) de la trama Ethernet.

Aunque este método evita que se conmuten tramas dañadas a otros segmentos de la red, provoca una mayor latencia. Debido a la latencia provocada por el método de almacenamiento y envío, por lo general, sólo se lo utiliza en entornos proclives a producir errores, como los entornos con altas probabilidades de interferencia electromagnética.

Conmutación por método de corte

El otro método importante de conmutación es la conmutación por método de corte. La conmutación por método de corte se subdivide en dos métodos adicionales: por envío rápido y libre de fragmentos. En ambos métodos, el switch envía la trama antes de que se complete la recepción. Dado que el switch no calcula o comprueba el valor de CRC, es posible que se envíen tramas dañadas.

El envío rápido es el método más veloz de conmutación. El switch envía las tramas al puerto de destino tan pronto como lee la dirección MAC de destino. Este método tiene la latencia más baja, pero también envía fragmentos de colisión y tramas dañadas. Este método de conmutación funciona mejor en una red estable con pocos errores.

En la conmutación libre de fragmentos, el switch lee los primero 64 bytes de la trama antes de comenzar a enviarla al puerto de destino. La trama Ethernet más corta que tiene validez es de 64 bytes. Por lo general, las tramas de menor tamaño son resultado de colisiones y se denominan runts. La comprobación de los primeros 64 bytes garantiza que el switch no envíe fragmentos debidos a colisiones.

El método de almacenamiento y envío tiene la latencia más alta y el envío rápido, la más baja. La latencia de método libre de fragmentos se encuentra en el medio de estos otros dos. El método de conmutación libre de fragmentos funciona mejor en un entorno donde se producen muchas colisiones. En una red de conmutación construida adecuadamente, las colisiones no representan un problema; por lo tanto, la conmutación de envío rápido sería el método más indicado.

En la actualidad, la mayor parte de los switches de la LAN de Cisco utilizan el método de conmutación de almacenamiento y envío. Esto se debe a que, gracias a la tecnología más reciente y a los plazos de procesamiento más breves, los switches pueden almacenar y procesar las tramas casi tan rápido como la conmutación por método de corte, sin el inconveniente de los errores. Asimismo, muchas de las funciones más complejas, como la conmutación multicapa, requieren el uso del método de almacenamiento y envío.

También existen algunos switches de Capa 2 y Capa 3 más avanzados que pueden adaptar su método de conmutación a las cambiantes condiciones de la red.

Estos switches comienzan enviando el tráfico mediante el método de envío rápido, a fin de proporcionar la latencia más baja posible. Aunque el switch no realiza una verificación de errores antes de enviar la trama, reconoce los errores y mantiene un contador de errores en la memoria. Compara la cantidad de errores encontrados con un valor de umbral predefinido.

Si la cantidad de errores supera el valor de umbral, el switch ha enviado una cantidad inaceptable de errores. En esta situación, el switch se modifica y pasa a la conmutación de almacenamiento y envío. Si la cantidad de errores se reduce y queda por debajo del umbral, el switch vuelve al modo de envío rápido. Esto se denomina conmutación por método de corte adaptable.

Seguridad del Switch

ndependientemente del método de conmutación que se utilice, la seguridad de la red debe ser una prioridad. La seguridad de la red a menudo se concentra en los routers y en el bloqueo de tráfico externo. Los switches forman parte de la estructura interna de la organización, y están diseñados para proporcionar conectividad simple. Por lo tanto, sólo se aplican algunas medidas de seguridad, y en ocasiones no se aplica ninguna.

Aplique las siguientes funciones básicas de seguridad a los switches para garantizar que sólo las personas autorizadas puedan tener acceso a los dispositivos:

Asegure el dispositivo físicamente
Utilice contraseñas seguras
Active el acceso a SSH
Supervise el acceso y el tráfico
Desactive el acceso http
Deshabilite los puertos no utilizados
Habilite la seguridad de puertos
Desactive Telnet

Redundancia de una Red Conmutada

En la actualidad, las empresas dependen cada vez más de sus redes para su funcionamiento. Para muchas organizaciones, la red es su herramienta vital. Los períodos de inactividad de la red tienen como consecuencia la pérdida de operaciones comerciales, ingresos y confianza por parte del cliente, lo que podría resultar desastroso para la empresa.

La falla de un único enlace de la red, un único dispositivo o un puerto crítico de un switch causa un período de inactividad de la red. La redundancia es una característica clave del diseño de la red a fin de mantener un alto grado de confiabilidad y eliminar cualquier punto de error exclusivo. La redundancia se logra mediante la instalación de enlaces de red y equipos duplicados para áreas críticas.

En ocasiones, proporcionar redundancia completa a todos los enlaces y los dispositivos de la red puede resultar muy costoso. Los ingenieros de red a menudo deben equilibrar el costo de la redundancia con la necesidad de disponibilidad de la red. Los períodos de inactividad de la red pueden tener como consecuencia la pérdida de operaciones comerciales, ingresos y confianza por parte del cliente.

La redundancia hace referencia a la existencia de dos rutas diferentes a un destino determinado. Algunos ejemplos de redundancia fuera de los entornos de red son: dos carreteras que llevan a un pueblo, dos puentes que cruzan un río o dos puertas de salida de un edificio. Si una vía está bloqueada, todavía está disponible la otra.

Para lograr redundancia, conecto los switches a varios enlaces. Los enlaces redundantes de una red conmutada reducen la congestión y mejoran la alta disponibilidad y el balance de carga.

Sin embargo, la conexión entre switches puede ocasionar problemas. Por ejemplo, la naturaleza de broadcast del tráfico de Ethernet crea bucles de conmutación. Las tramas de broadcast se transmiten en círculos en todas direcciones, lo que ocasiona una tormenta de broadcast. Las tormentas de broadcast utilizan todo el ancho de banda disponible y pueden impedir que se establezcan conexiones de red, además de ocasionar la interrupción de las conexiones ya establecidas.

Las tormentas de broadcast no son el único problema creado por los enlaces redundantes en una red conmutada. Las tramas unicast a veces ocasionan problemas, como las transmisiones de múltiples tramas y la inestabilidad de la base de datos de MAC.

Transmisiones de múltiples tramas

Si un host envía una trama unicast a un host de destino, y la dirección MAC de destino no está incluida en ninguna de las tablas de direcciones MAC del switch conectado, todos los switches inundan todos los puertos con la trama. En una red con bucles, la trama podría enviarse de vuelta al switch inicial. El proceso se repite, y así se crean varias copias de la trama en la red.

Con el tiempo, el host de destino recibe varias copias de la trama. Esto ocasiona tres problemas: desperdicio de ancho de banda, desperdicio de tiempo de la CPU y posible duplicación del tráfico de transacciones.

Inestabilidad de la base de datos de direcciones MAC

Es posible que los switches de una red redundante obtengan información incorrecta sobre la ubicación de un host. Si existe un bucle, un switch puede asociar la dirección MAC de destino con dos puertos separados. Esto ocasiona confusión y envíos subóptimos de tramas.

Protocolo de Spanning Tree (STP)

El protocolo de Spanning Tree (STP, Spanning Tree Protocol) proporciona un mecanismo de desactivación de enlaces redundantes en una red conmutada. El STP proporciona la redundancia requerida para brindar fiabilidad sin crear bucles de conmutación.

Es un protocolo de estándares abiertos, que se utiliza en un entorno de conmutación para crear una topología lógica sin bucles.

El STP es relativamente autosuficiente y requiere poca configuración. La primera vez que se encienden los switches con STP activado, buscan bucles en la red de conmutación. Los switches que detecten un posible bucle bloquean algunos de los puertos de conexión, y dejan otros activos para enviar tramas.

El STP define una estructura que abarca todos los switches de una red conmutada en estrella. Los switches verifican la red constantemente para garantizar que no haya bucles y que todos los puertos funcionen correctamente.

Para evitar los bucles de conmutación, el STP:

Obliga a ciertas interfaces a ingresar en un estado de espera o bloqueo
Deja a otras interfaces en estado de envío
Reconfigura la red activando la ruta en espera correspondiente, si la ruta de envío deja de estar disponible

En la terminología de STP, a menudo, se utiliza el término puente para referirse al switch. Por ejemplo, el puente raíz es el switch principal o punto focal de la topología de STP. El puente raíz se comunica con los demás switches mediante unidades de datos de protocolo de puente (BPDU, Bridge Protocol Data Units). Las unidades BPDU son tramas que se envían como multicast cada 2 segundos a todos los demás switches. Estas unidades contienen información como:

Identidad del switch de origen
Identidad del puerto de origen
Costo del puerto de origen
Valor de los temporizadores de actualización
Valor del temporizador de saludo

Cuando se enciende el switch, cada puerto pasa por un ciclo de cuatro estados: bloquear, escuchar, aprender y reenvío. Un quinto estado, la desactivación, indica que el administrador desconectó el puerto del switch.

A medida que el puerto pasa por estos estados, los LED del switch pasan de naranja intermitente a verde permanente. Un puerto puede demorar hasta 50 segundos en pasar por todos estos estados y quedar listo para enviar tramas.

Cuando un switch se enciende, el primer estado en el que entra es el de bloqueo, a fin de impedir la formación de un bucle. Luego cambia al modo de escucha, para recibir las unidades BPDU de los switches vecinos. Después de procesar esta información, el switch determina qué puertos pueden enviar tramas sin crear un bucle. Si el puerto puede enviar tramas, pasa a modo de aprendizaje y luego a modo de envío.

Los puertos de acceso no crean bucles en una red conmutada y siempre pasan al estado de envío si tienen un host conectado. Los puertos de enlace troncal pueden crear una red con bucles y pasan a un estado de envío o de bloqueo.

Puentes Raiz

Para que funcione STP, los switches de la red determinan un switch que funcione como punto focal de esa red. El STP utiliza este punto focal, denominado puente raíz o switch raíz, para determinar qué puertos deben bloquearse y qué puertos deben entrar en estado de envío. El puente raíz envía unidades BPDU que contienen información sobre la topología de la red a todos los demás switches. Esta información permite que la red se vuelva a configurar en caso de una falla.

Sólo hay un puente raíz en cada red, y se lo elige según el ID de puente (BID, Bridge ID). El BID se crea a partir del valor de prioridad del puente y la dirección MAC.

La prioridad del puente tiene un valor predeterminado de 32 768. Si un switch tiene una dirección MAC de AA-11-BB-22-CC-33, el BID correspondiente a ese switch sería: 32768: AA-11-BB-22-CC-33.

El puente raíz se elige de acuerdo con el valor BID más bajo. Dado que los switches con frecuencia utilizan el mismo valor de prioridad predeterminado, el switch con la dirección MAC más baja será el puente raíz.

Cuando se enciende cada switch, supone que es el puente raíz, y envía las BPDU que contienen su BID. Por ejemplo, si S2 publica un ID de raíz con un número menor al de S1, S1 detiene la publicidad de su ID de raíz y acepta el ID de raíz de S2. S2 es ahora el puente raíz.

STP designa tres tipos de puertos: puertos raíz, puertos designados y puertos bloqueados.

Puerto raíz

El puerto que proporciona la ruta de menor costo al puente raíz se convierte en el puerto raíz. Los switches calculan la ruta de menor costo a partir del costo de ancho de banda de cada enlace necesario para llegar al puente raíz.

Puerto designado

Un puerto designado es un puerto que envía el tráfico hacia el puente raíz pero no se conecta con la ruta de menor costo.

Puerto bloqueado

Un puerto boqueado es un puerto que no envía tráfico.

Antes de configurar el STP, el técnico de redes planea y evalúa la red a fin de seleccionar el mejor switch para que sea la raíz de Spanning Tree. Si el switch raíz se asigna a la dirección MAC más baja, el envío puede no ser óptimo.

Un switch con ubicación central funciona mejor como puente raíz. Un puerto bloqueado ubicado en el extremo de la red puede obligar al tráfico a tomar una ruta más larga para llegar a destino que la que tomaría si el switch tuviera una ubicación central.

Para especificar el puente raíz, la BID del switch elegido se configura con el valor de prioridad más bajo. Para configurar la prioridad del puente, se utiliza el comando de prioridad del puente. El rango de prioridad abarca de 0 a 65535, pero los valores se incrementan en 4096. El valor predeterminado es 32768.

Para establecer la prioridad:

S3(config)#bridge priority 4096

Para restablecer la prioridad al valor predeterminado:

S3(config)#no bridge priority

Spaning Tree en una red Jerarquica

Después de establecer el puente raíz, los puertos raíz, los puertos designados y los puertos bloqueados, el STP envía unidades BPDU por la red conmutada en intervalos de 2 segundos. STP continúa escuchando estas BPDU para asegurarse de que ningún enlace falle y de que no aparezcan nuevos bucles.

Si se produce una falla en un enlace, el STP lleva a cabo otro cálculo mediante tres procesos:

Cambio del estado de algunos puertos bloqueados a puertos de envío
Cambio del estado de algunos puertos de envío a puertos bloqueados
Generación de una nueva estructura jerárquica de STP a fin de mantener la integridad sin bucles de la red

El STP no lleva a cabo este proceso de forma instantánea. Cuando se desconecta un enlace, el STP detecta la falla y vuelve a calcular la mejor ruta por la red. Este cálculo y el período de transición demoran alrededor de 30 a 50 segundos en cada switch. Durante este cálculo, no se transmiten datos de usuario a través de los puertos comprometidos.

Algunas aplicaciones de los usuarios pueden presentar un error de tiempo de espera durante el período de cálculo, lo cual puede tener como resultado la pérdida de productividad e ingresos. Los cálculos frecuentes por parte de STP tienen un efecto negativo en el tiempo de actividad.

Un servidor empresarial de gran volumen está conectado al puerto de un switch. Si ese puerto realiza un cálculo debido a STP, el servidor queda inactivo durante 50 segundos. Sería difícil imaginar la cantidad de transacciones perdidas durante ese período.

En una red estable, los cálculos de STP son poco frecuentes. En una red inestable, es importante verificar la estabilidad de los switches y los cambios de configuración. Una de las causas más comunes de cálculos frecuentes de STP es una falla en el suministro o la alimentación de energía a un switch. Una falla en el suministro de energía puede ocasionar el reinicio inesperado del dispositivo.

Existen diversas mejoras de STP que minimizan el tiempo de inactividad ocasionado por los cálculos.

PortFast

STP PortFast hace que los puertos de acceso pasen de inmediato al estado de envío, y evitan los estados de escucha y aprendizaje. El uso de PortFast en los puertos de acceso que están conectados a una sola estación de trabajo o un servidor permite que estos dispositivos se conecten a la red de inmediato, en lugar de esperar la convergencia de STP.

UplinkFast

STP UplinkFast acelera la elección de un nuevo puerto raíz cuando hay fallas en un enlace o switch, o cuando STP se reconfigura. El puerto raíz pasa de inmediato al estado de envío, sin pasar por los estados de escucha y aprendizaje, como sucedería en el procedimiento normal de STP.

BackboneFast

BackboneFast proporciona una convergencia rápida después de que ocurre un cambio en la topología jerárquica de Spanning Tree. Así se restaura rápidamente la conectividad de backbone. BackboneFast se utiliza en la capa de distribución y la capa core, donde se conectan varios switches.

PortFast, UplinkFast y BackboneFast son propiedad de Cisco y, por lo tanto, no pueden utilizarse si la red incluye switches de otros fabricantes. Asimismo, todas estas funciones deben configurarse.

Existen varios comandos útiles para verificar el funcionamiento de Spanning Tree.

show spanning-tree: muestra el ID de raíz, el ID del puente y el estado de los puertos

show spanning-tree summary: muestra un resumen del estado de los puertos

show spanning-tree root: muestra el estado y la configuración del puente raíz

show spanning-tree detail: muestra información detallada sobre los puertos

show spanning-tree interface: muestra la configuración y el estado de la interfaz de STP

show spanning-tree blockedports: muestra los puertos bloqueados

Protocolo de Rapid Spanning Tree (RSTP,Rapid Spanning Tree Protocol)

Cuando IEEE desarrolló el protocolo Spanning Tree (STP) original en el estándar 802.1D, era aceptable proporcionar un tiempo de recuperación de 1 a 2 minutos. En la actualidad, la conmutación de Capa 3 y los protocolos de enrutamiento avanzado ofrecen una ruta alternativa más rápida para llegar a destino. La necesidad de transmitir tráfico sensible a las demoras, como voz y video, requiere que las redes de conmutación converjan rápidamente para seguirle el paso a las nuevas tecnologías.

Protocolo de Rapid Spanning Tree (RSTP), definido en el estándar IEEE 802.1w, acelera de forma considerable el cálculo de Spanning Tree. A diferencia de PortFast, UplinkFast y BackboneFast, el RSTP no es propiedad de empresa alguna.

El RSTP requiere una conexión full-duplex de punto a punto entre los switches para alcanzar la velocidad de reconfiguración más rápida. La reconfiguración de Spanning Tree mediante RSTP se produce en menos de 1 segundo, mientras que con STP demoraba hasta 50 segundos.

El RSTP elimina la necesidad de utilizar funciones como PortFast y UplinkFast. RSTP puede revertirse a STP para prestar servicios a equipos heredados.

Para acelerar el proceso de cálculo, RSTP reduce la cantidad de estados de puerto a tres: descarte, aprendizaje y envío. El estado de descarte es similar a tres de los estados del STP original: bloqueo, escucha y desactivación.

RSTP también presenta el concepto de topología activa. Todos los puertos que no estén en estado de descarte o bloqueo se consideran parte de la topografía activa, y pasan de inmediato al estado de envío.

LAN VIRTUAL

Los hosts y los servidores conectados a switches de Capa 2 son parte del mismo segmento de la red. Esta disposición presenta dos problemas considerables:

Los switches inundan todos los puertos con las transmisiones de broadcast, lo que consume ancho de banda innecesario. A medida que aumenta la cantidad de dispositivos conectados a un switch, se genera más tráfico de broadcast y se desperdicia más ancho de banda.
Todos los dispositivos conectados a un switch pueden enviar y recibir tramas de todos los demás dispositivos del mismo switch.

Una de las mejores prácticas de diseño de red establece que el tráfico de broadcast debe quedar restringido al área de la red en la que resulta necesario. También existen razones comerciales por las cuales ciertos hosts se comunican entre ellos, pero otros no. Por ejemplo, es posible que los miembros del departamento de contabilidad sean los únicos usuarios que necesiten acceso al servidor de contabilidad. En una red conmutada, redes de área local virtuales (VLAN) se crean de modo que contengan broadcast y agrupen a los hosts en comunidades de interés.

Una VLAN es un dominio lógico de broadcast que puede abarcar diversos segmentos de una LAN física. Esto le permite a un administrador agrupar estaciones por función lógica, por equipos de trabajo o por aplicaciones, independientemente de la ubicación física de los usuarios.

La diferencia entre una red física y una red virtual o lógica puede ilustrarse mediante el siguiente ejemplo:

Los estudiantes de una escuela se dividen en dos grupos. Los estudiantes del primer grupo se identifican con tarjetas rojas. Los del segundo grupo se identifican con tarjetas azules. El director anuncia que los estudiantes con tarjetas rojas sólo pueden hablar con los compañeros que también tengan tarjetas rojas, y que los estudiantes con tarjetas azules sólo pueden hablar con sus compañeros poseedores de tarjetas azules. Ahora los estudiantes están separados lógicamente en dos grupos virtuales, o VLAN.

Según esta agrupación lógica, un broadcast se transmite sólo al grupo con tarjetas rojas, aunque ambos grupos están ubicados físicamente en la misma escuela.

Este ejemplo también ilustra otra función de las VLAN. Los broadcasts no se envían entre distintas VLAN, están restringidos a la misma VLAN.

Cada VLAN funciona como una LAN individual. Una VLAN abarca uno o más switches, lo que permite que los dispositivos host funcionen como si estuvieran en el mismo segmento de la red.

Una VLAN tiene dos funciones principales:

Contiene broadcasts.
Agrupa dispositivos. Los dispositivos ubicados en una VLAN no son visibles para los dispositivos ubicados en otra VLAN.

Es necesario que el tráfico cuente con un dispositivo de Capa 3 para poder transmitirlo entre VLAN.

En una red conmutada, un dispositivo puede asignarse a una VLAN según su ubicación, su dirección MAC, su dirección IP o las aplicaciones que utiliza con más frecuencia. Los administradores pueden asignar la membresía a una VLAN de forma estática o dinámica.

La membresía estática a una VLAN requiere que el administrador asigne de forma manual cada puerto a una VLAN específica. Por ejemplo, el puerto fa0/3 puede asignarse a la VLAN 20. Cualquier dispositivo que se conecte al puerto fa0/3 es miembro de la VLAN 20 de forma automática.

Este tipo de membresía a una VLAN es el más fácil de configurar y también es el más difundido; sin embargo, requiere un mayor grado de apoyo administrativo en caso de adiciones, traslados y cambios. Por ejemplo, el traslado de un host de la VLAN a otra requiere reconfigurar manualmente el puerto del switch para asignarlo a la nueva VLAN o conectar el cable de la estación de trabajo a otro puerto del switch de la nueva VLAN.

La membresía a una VLAN determinada es totalmente transparente para los usuarios. Los usuarios que trabajen en un dispositivo conectado a un puerto del switch no tienen forma de saber que son miembros de una VLAN.

La membresía dinámica a VLAN requiere un servidor de política de administración de VLAN (VMPS). El VMPS contiene una base de datos que asigna direcciones MAC a la VLAN. Cuando se conecta un dispositivo a un puerto del switch, el VMPS busca en la base de datos una coincidencia con la dirección MAC, y asigna ese puerto de forma temporal a la VLAN correspondiente.

La membresía dinámica a VLAN requiere más organización y configuración, pero crea una estructura con mucha más flexibilidad que la membresía estática a una VLAN. En una VLAN dinámica, los traslados, las adiciones y los cambios están automatizados, y no requieren intervenciones por parte del administrador.

Nota: no todos los switches de Catalyst son compatibles con el uso de VMPS.

Configuración de una Lan Virtual

Independientemente de que las VLAN sean estáticas o dinámicas, la cantidad máxima de VLAN depende del tipo de switch y de IOS. De forma predeterminada, VLAN1 es la VLAN de administración.

El administrador utiliza la dirección IP de la VLAN de administración para configurar el switch de forma remota. Al tener acceso remoto al switch, el administrador de red puede configurar y mantener todas las configuraciones de VLAN.

Además, la VLAN de administración se utiliza para intercambiar información, como el tráfico del protocolo de descubrimiento de Cisco (CDP, Cisco Discovery Protocol) y el tráfico del protocolo de enlace troncal de la VLAN (VLAN Trunking Protocol, VTP) con otros dispositivos de red.

Cuando se crea una VLAN, se le asigna un número y un nombre. El número de la VLAN puede ser cualquier número del rango disponible en el switch, con la excepción de VLAN1. Algunos switches admiten aproximadamente 1000 VLAN, mientras que otros admiten más de 4000. Se considera que la asignación de nombres a las VLAN es una de las mejores prácticas de administración de redes.

Utilice los siguientes comandos para crear una VLAN según el modo de configuración global:

Switch(config)#vlan vlan_number
Switch(config-vlan)#name vlan_name
Switch(config-vlan)#exit

Asigne puertos para que sean miembros de la VLAN. De forma predeterminada, al inicio todos los puertos son miembros de VLAN1. Asigne los puertos individualmente o como rango.

Utilice los siguientes comandos para asignar puertos individuales a las VLAN:

Switch(config)#interface fa#/#
Switch(config-if)#switchport access vlan vlan_number
Switch(config-if)# exit
Utilice los siguientes comandos para asignar un rango de puertos a las VLAN:

Switch(config)#interface range fa#/start_of_range - end_of_range
Switch(config-if)#switchport access vlan vlan_number
Switch(config-if)#exit

Para verificar, realizar mantenimiento y diagnósticos de fallas en las VLAN, es importante comprender los comandos show clave que están disponibles en Cisco IOS.

Se utilizan los siguientes comandos para verificar y mantener las VLAN:

show vlan

Muestra una lista detallada de todos los números y nombres de la VLAN que están activos actualmente en el switch, así como los puertos asociados con cada uno.
Muestra las estadísticas de STP si está configurado en cada VLAN.

show vlan brief

Muestra una lista abreviada solamente de las VLAN activas y los puertos asociados con cada una.

show vlan id id_number

Muestra información sobre una VLAN específica, según el número de ID.

show vlan name vlan_name

Muestra información sobre una VLAN específica, según el nombre.

En una organización, a menudo se agregan, eliminan o trasladan empleados a diferentes departamentos o proyectos. Este cambio constante requiere tareas de mantenimiento a la VLAN, incluidas la eliminación o la reasignación a diferentes VLAN.

La eliminación de VLAN y la reasignación de puertos a distintas VLAN son dos funciones individuales. Cuando un puerto se desvincula de una VLAN específica, vuelve a VLAN1.

Para eliminar una VLAN:

Switch(config)#no vlan nombre_vlan

Para desvincular un puerto de una VLAN específica:

Switch(config)#interface fa#/#
Switch(config-if)#no switchport access vlan nombre_vlan

Identificando una VLAN

Los dispositivos conectados a una VLAN sólo se comunican con otros dispositivos de la misma VLAN, independientemente de que estén en el mismo switch o en switches diferentes.

Un switch asocia cada puerto con un número de VLAN específico. Cuando una trama ingresa a ese puerto, el switch agrega el ID de la VLAN (VID) en la trama Ethernet. La adición del número de ID de la VLAN a la trama Ethernet se denomina etiquetado de tramas. El estándar de etiquetado de tramas más frecuente es IEEE 802.1q.

El estándar 802.1Q, a veces abreviado a dot1q ("punto1q"), agrega un campo de etiquetado de 4 bytes a la trama Ethernet. Esta etiqueta se incluye entre la dirección de origen y el campo de tipo/longitud.

Las tramas Ethernet tienen un tamaño mínimo de 64 bytes y uno máximo de 1518 bytes. Sin embargo, una trama Ethernet etiquetada puede tener un tamaño de hasta 1522 bytes.

Las tramas contienen campos como:

Las direcciones MAC de origen y destino
La longitud de la trama
Los datos de carga
La secuencia de verificación de trama (FCS)

El campo de FCS proporciona una verificación de errores para garantizar la integridad de todos los bits de la trama.

Este campo de etiquetado incrementa la trama Ethernet mínima de 64 a 68 bytes. El tamaño máximo se incrementa de 1518 a 1522 bytes. El switch vuelve a calcular el FCS porque se ha modificado la cantidad de bits de la trama.

Si se conecta un puerto compatible con 802.1Q a otro puerto compatible con 802.1Q, la información de etiquetado VLAN se transmite entre ellos.

SI el puerto de conexión no es compatible con 802.1Q, se elimina la etiqueta VLAN antes de transmitir la trama a los medios.

Los dispositivos con puertos que no son compatibles con 802.1Q consideran demasiado extensa una trama Ethernet etiquetada. La trama se descarta y se registra como error, denominado gigante.

Puertos de Enlace Troncal

Una VLAN tiene tres funciones principales:

Limita el tamaño de dominios de broadcast
Mejora el rendimiento de la red
Proporciona un nivel de seguridad

A fin de aprovechar todos los beneficios de las VLAN, éstas se extienden por diversos switches.

Los puertos de switch pueden configurarse para dos funciones diferentes. Un puerto se clasifica como puerto de acceso o puerto de enlace troncal.

Puerto de acceso

Un puerto de acceso pertenece sólo a una VLAN. Por lo general, los dispositivos individuales como las PC o los servidores se conectan a este tipo de puerto. Si un hub conecta varias PC a un único puerto de acceso, todos los dispositivos conectados al hub son miembros de la misma VLAN.

Puerto de enlace troncal

Un puerto de enlace troncal es un enlace punto a punto entre el switch y otro dispositivo de red. Los enlaces troncales transmiten el tráfico de diversas VLAN mediante un único enlace, y permiten que las VLAN se extiendan por toda la red. Los puertos de enlace troncal son necesarios para transmitir el tráfico de diversas VLAN entre dispositivos al conectar dos switches entre sí, un switch a un router o un host NIC compatible con los enlaces troncales definidos en 802.1Q.

Sin los puertos de enlace troncal, cada VLAN requiere una conexión separada entre switches. Por ejemplo, una empresa con 100 VLAN requiere 100 enlaces de conexión. Este tipo de disposición no es fácil de escalar y resulta muy costosa. Los enlaces troncales ofrecen una solución a este problema al transportar tráfico de diversas VLAN a través del mismo enlace.

Cuando se transmiten diversas VLAN por el mismo enlace, éstas deben contar con identificación. Un puerto de enlace troncal es compatible con el etiquetado de tramas. El etiquetado de tramas agrega información sobre las VLAN a la trama.

IEEE 802.1Q es el método estandarizado y aprobado para llevar a cabo el etiquetado de tramas. Cisco ha desarrollado un protocolo de etiquetado de tramas patentado denominado enlace Inter-Switch (ISL, Inter-Switch Link). Los switches de mayor nivel, como la serie Catalyst 6500, aún son compatibles con ambos protocolos de etiquetado. Sin embargo, la mayor parte de los switches LAN -como el 2960- son compatibles con 802.1Q únicamente.

Los puertos de switch son puertos de acceso de forma predeterminada. Para configurar un puerto de switch como puerto de enlace troncal, utilice los siguientes comandos:

Switch(config)#interface fa(controler # / port #)

Switch(config-if)#switchport mode trunk

Switch(config-if)#switchport trunk encapsulation {dot1q | isl | negotiate}

Los switches que son compatibles tanto con 802.1Q como con ISL requieren el último fragmento de configuración. El 2960 no requiere ese fragmento, ya que sólo es compatible con 802.1Q.

El parámetro de negociación es el modo predeterminado en muchos switches de Cisco. Este parámetro detecta automáticamente el tipo de encapsulamiento del switch vecino.

Los switches más modernos tienen la capacidad de detectar el tipo de enlace configurado en el otro extremo. Según el servicio conectado, el enlace se configura como puerto de enlace troncal o como puerto de acceso.

Switch(config-if)#switchport mode dynamic {desirable | auto}

En el modo deseable, el puerto se establece como puerto de enlace troncal si el otro extremo se establece como enlace troncal, deseable o automático.

En el modo automático, el puerto se convierte en puerto de enlace troncal si el otro extremo se establece como enlace troncal o deseable.

Para volver a establecer un puerto de enlace troncal después de establecerlo como puerto de acceso, utilice cualquiera de los siguientes comandos:

Switch(config)#interface fa(controler # / port #)

Switch(config-if)#no switchport mode trunk

o bien

Switch(config-if)#switchport mode access

Extension de las VLAN en switches

Los enlaces troncales permiten a las VLAN enviar tráfico entre switches mediante un único puerto.

Un enlace troncal configurado con 802.1Q en ambos extremos permite transmitir tráfico con un campo de etiquetado de 4 bytes agregado a la trama. Esta etiqueta de la trama contiene el ID de la VLAN.

Cuando un switch recibe una trama etiquetada en un puerto de enlace troncal, elimina la etiqueta antes de enviarla a un puerto de acceso. El switch envía la trama sólo si el puerto de acceso es miembro de la misma VLAN que la trama etiquetada.

Sin embargo, es necesario que cierto tráfico se transmita a través del enlace configurado según 802.1Q sin un ID de VLAN. El tráfico sin ID de VLAN se denomina sin etiquetar. Entre los ejemplos de tráfico sin etiquetar se cuentan el protocolo de descubrimiento de Cisco (CDP), VTP y ciertos tipos de tráfico de voz. El tráfico sin etiquetar minimiza los retrasos asociados con la inspección de la etiqueta de ID de la VLAN.

Para procesar el tráfico sin etiquetar, existe una VLAN especial llamada VLAN nativa. Las tramas sin etiquetar recibidas en el puerto de enlace troncal con 802.1Q son miembros de la VLAN nativa. En los switches Catalyst de Cisco, la VLAN 1 es la VLAN nativa predeterminada.

Puede configurarse cualquier VLAN como VLAN nativa. Asegúrese de que la VLAN nativa para un enlace troncal con 802.1Q sea la misma en ambos extremos de la línea de enlace troncal. Si son diferentes, pueden ocasionarse bucles en Spanning Tree.

En un enlace troncal con 802.1Q, utilice el siguiente comando para asignar el ID de la VLAN nativa en una interfaz física:

Switch(config-if)#dot1q native vlan vlan-id

Enrutamiento en VLAN

Aunque las VLAN se extienden para abarcar diversos switches, sólo los miembros de la misma VLAN pueden comunicarse.

Un dispositivo de Capa 3 proporciona conectividad entre diferentes VLAN. Esta configuración permite que el administrador de red controle estrictamente el tipo de tráfico que se transmite de una VLAN a otra.

Un método para realizar el enrutamiento entre VLAN requiere una conexión de interfaz aparte al dispositivo de Capa 3 para cada VLAN.

Otro método para proporcionar conectividad entre distintas VLAN requiere una función llamada subinterfaces. Las subinterfaces dividen lógicamente una interfaz física en diversas rutas lógicas. Es posible configurar una ruta o una subinterfaz para cada VLAN.

La compatibilidad con la comunicación inter-VLAN mediante subinterfaces requiere configuración tanto en el switch como en el router.

Switch
Configure la interfaz del switch como un enlace troncal con 802.1Q.

Router
Seleccione una interfaz de enrutamiento con un mínimo de 100 Mbps FastEthernet.
Configure subinterfaces compatibles con el encapsulamiento de 802.1Q.
Configure una subinterfaz para cada VLAN.

Una subinterfaz permite que cada VLAN tenga su propia ruta lógica y un gateway predeterminado en el router.

El host de la VLAN de origen envía el tráfico al router mediante el gateway predeterminado. La subinterfaz de la VLAN especifica el gateway predeterminado para todos los hosts de esa VLAN. El router ubica la dirección IP de destino y lleva a cabo una búsqueda en la tabla de enrutamiento.

Si la VLAN de destino se encuentra en el mismo switch que la VLAN de origen, el router vuelve a enviar el tráfico al origen mediante los parámetros de subinterfaz del ID de la VLAN de origen. Este tipo de configuración a menudo se denomina router-on-a-stick ("router en un palo").

Si la interfaz de salida del router es compatible con 802.1Q, la trama conserva su etiqueta de VLAN de 4 bytes. Si la interfaz de salida no es compatible con 802.1Q, el router elimina la etiqueta de la trama y le devuelve su formato de Ethernet original.

Para configurar el enrutamiento entre VLAN, lleve a cabo los siguientes pasos:

1. Configure un puerto de enlace troncal en el switch.

Switch(config)#interface fa0/2

Switch(config-if)#switchport mode trunk

2. En el router, configure una interfaz de FastEthernet sin dirección IP ni máscara de red.

Router(config)#interface fa0/1

Router(config-if)#no ip address

Router(config-if)#no shutdown

3. En el router, configure una subinterfaz con una dirección IP y una máscara de red para cada VLAN. Cada subinterfaz tiene un encapsulamiento de 802.1Q.

Router(config)#interface fa0/0.10

Router(config-subif)#encapsulation dot1q 10

Router(config-subif)#ip address 192.168.10.1 255.255.255.0

4. Utilice los siguientes comandos para verificar la configuración y el funcionamiento del enrutamiento entre VLAN.

Switch#show trunk

Router#show ip interfaces

Router#show ip interfaces brief

Router#show ip route

Protocolo de Enlaces Troncales de VLAN (VTP)

A medida que las redes crecen en tamaño y complejidad, el mantenimiento centralizado de la estructura de las VLAN se vuelve crucial. El protocolo de enlaces troncales de VLAN (VTP) es un protocolo de mensajería que ofrece un método para la distribución y la administración de la base de datos de un servidor centralizado en un segmento de la red. Los routers no envían actualizaciones de VTP.

Si no existe una forma automatizada de administrar una red empresarial con cientos de VLAN, es necesario configurar manualmente cada VLAN de todos los switches. Cualquier cambio en la estructura de las VLAN requiere más configuración manual. Un número ingresado de forma incorrecta ocasiona inconsistencias en la conectividad de toda la red.

Para resolver este problema, Cisco creó VTP, a fin de automatizar muchas de las funciones de configuración de VLAN. VTP asegura el mantenimiento coherente de la configuración de las VLAN en toda la red, y reduce la tarea de la administración y el monitoreo de las VLAN.

VTP es un protocolo de mensajería de cliente/servidor que agrega, elimina y cambia los nombres de las VLAN en un dominio de VTP individual. Todos los switches bajo una única administración forman parte de un dominio. Cada dominio tiene un nombre exclusivo. Los switches de VTP sólo comparten los mensajes de VTP con los demás switches del mismo dominio.

Existen dos versiones diferentes de VTP: La versión 1 y la versión 2. La versión 1 es la predeterminada, y no es compatible con la versión 2. Todos los switches deben configurarse con la misma versión.

VTP tiene tres modos: servidor, cliente y transparente. De forma predeterminada, todos los switches son servidores. Es recomendable tener al menos dos switches de la red configurados como servidores, para proporcionar copias de respaldo y redundancia.

Con VTP, cada switch publica los mensajes en sus puertos de enlace troncal. Los mensajes incluyen el dominio de administración, el número de revisión de configuración, las VLAN conocidas y los parámetros de cada una. Estas tramas de publicación se envían a una dirección multicast de modo que todos los dispositivos vecinos puedan recibir las tramas.

Cada switch de VTP guarda una base de datos de VLAN en NVRAM que contiene un número de revisión. Si un VTP recibe un mensaje de actualización con un número de revisión posterior al que tiene almacenado en la base de datos, el switch actualiza su base de datos de VLAN con esta nueva información.

El número de revisión de configuración VTP comienza en cero. Cuando se producen cambios, el número de revisión de configuración aumenta en uno. El número de revisión continúa incrementándose hasta llegar a 2,147,483,648. En este punto, el contador vuelve a cero. Reiniciar el switch también restablece el número de revisión a cero.

Puede producirse un problema con el número de revisión si alguien conecta a la red un switch con un número de revisión mayor sin reiniciarlo antes. Dado que un switch está establecido como servidor de modo predeterminado, esto tiene como resultado que se sobrescriba la información legítima de la VLAN en todos los switches con información nueva, pero incorrecta.

Otra forma de evitar esta situación crítica es configurar una contraseña de VTP para validar el switch. Al agregar un nuevo switch a una red existente, siempre reinícielo antes de conectarlo a la red, a fin de restablecer el número de revisión. Además, cuando agregue un switch y ya haya uno que funcione como servidor, asegúrese de que el nuevo switch esté configurado en modo cliente o transparente.

Existen tres variedades de mensajes de VTP: publicaciones de resumen, publicaciones de subconjunto y solicitudes de publicación.

Publicaciones de resumen

Los switches Catalyst emiten publicaciones de resumen cada 5 minutos, o cuando se produce un cambio en la base de datos de la VLAN. Las publicaciones de resumen contienen el nombre de dominio del VTP actual y el número de revisión de la configuración.

Si se agregan, eliminan o cambian VLAN, el servidor incrementa el número de revisión de configuración y emite una publicación de resumen.

Cuando un switch recibe un paquete de publicación de resumen, compara el nombre de dominio de VTP con su propio nombre de dominio de VTP. Si el nombre de dominio es el mismo, el switch compara el número de revisión de configuración con su propio número. Si es igual o más bajo, el switch ignora el paquete. Si el número de revisión es más alto, se envía una solicitud de publicación.

Publicaciones de subconjunto
Una publicación de subconjunto se emite después de la publicación de resumen y contiene una lista de la información de la VLAN.

La publicación de subconjunto contiene la nueva información de la VLAN según la publicación de resumen. Si existen varias VLAN, es necesario contar con más de una publicación de subconjunto.

Solicitudes de publicación

Los clientes de VTP utilizan solicitudes de publicación para solicitar información sobre las VLAN. Las solicitudes de publicación son necesarias si se reinició el switch o si se cambió el nombre de dominio de VTP. El switch recibe una publicación de resumen de VTP con un número de revisión de configuración más alto que el suyo.

Configuracion de VTP

Los switches son servidores de forma predeterminada. Si un switch en modo de servidor emite una actualización con un número de revisión mayor al número actual, todos los switches modifican sus bases de datos para que coincidan con el nuevo switch.

Al agregar un nuevo switch a un dominio de VTP existente, siga estos pasos:

Paso 1: Configure el VTP sin conexión (versión 1)

Paso 2: Verifique la configuración de VTP.

Paso 3: Reinicie el switch.

Compatibilidad con VLAN para telefonía IP y tráfico inalámbrico

El propósito principal de las VLAN es separar el tráfico en grupos lógicos. El tráfico de una VLAN no afecta al tráfico de otra. Un entorno de VLAN es ideal para tráfico sensible a las demoras, como el tráfico de voz.

El tráfico de voz debe tener prioridad sobre el tráfico de datos normal, para evitar conversaciones entrecortadas. Contar con una VLAN dedicada al tráfico de voz evita que éste deba competir con los demás datos por el ancho de banda disponible.

Un teléfono por IP generalmente tiene dos puertos, uno para voz y otro para datos. Los paquetes que se transmiten entre el equipo y el teléfono por IP comparten el mismo enlace físico al switch, y el mismo puerto de éste. Para segmentar el tráfico de voz, es necesario activar una VLAN separada dedicada a este propósito en el switch.

El tráfico inalámbrico también se beneficia al contar con VLAN. El tráfico inalámbrico es, por naturaleza, muy poco seguro y susceptible a ataques por parte de piratas informáticos. Las VLAN creadas para el tráfico inalámbrico aíslan algunos de los problemas que pueden surgir. Un problema en la integridad de la VLAN inalámbrica no tiene efecto en ninguna otra VLAN de la organización.

La mayoría de las distribuciones inalámbricas ubican al usuario de una VLAN fuera del firewall, para proporcionar más seguridad. Los usuarios deben autenticar su identidad para poder ingresar a la red interna desde la red inalámbrica.

Además, muchas organizaciones ofrecen acceso a invitados a su red inalámbrica. Las cuentas para invitados le proporcionan a cualquier persona, dentro de un rango limitado, servicios inalámbricos temporales como acceso a la Web, correo electrónico, ftp y SSH. Las cuentas para invitados están incluidas en la VLAN inalámbrica o tienen una VLAN propia.

Mejores Practica para las VLAN

Cuando se las planea y diseña cuidadosamente, las VLAN proporcionan seguridad, conservan el ancho de banda y localizan el tráfico en una red empresarial. Todas estas funciones se combinan para mejorar el rendimiento de la red.

Algunas de las mejores prácticas para la configuración de VLAN en una red empresarial son:

Organizar la ubicación del servidor
Deshabilitar los puertos que no se utilizan
Configurar las VLAN de administración en un número que no sea 1
Utilizar el protocolo de enlace troncal de VLAN
Configurar dominios de VTP
Reiniciar todo nuevo switch que se conecte a una red establecida

No obstante, las VLAN no son la respuesta a todos los problemas.

Si no se implementan correctamente, pueden complicar la red y provocar una conectividad inconstante y un bajo rendimiento de la red.

Las VLAN aíslan ciertos tipos de tráfico por motivos de seguridad. La transmisión de tráfico entre las VLAN requiere un dispositivo de Capa 3, lo cual incrementa el costo de implementación e introduce un mayor nivel de latencia a la red.

Blog de Tecnologia

Datos personales

VideoBlog Dayanx

Estadisticas

Nube de Tags

Blog Archive

Seguidores

Labels

El Servidor Sendmail

¿Que es DNS ? - Linux

Conmutación de una Red Empresarial