Vous êtes sur la page 1sur 118

DIPLOMADO SUPERIOR EN

PLATAFORMAS OPERATIVAS
PARA INTERNETWORKING
EXAMEN COMPLEXIVO

ABRIL 2015

TEMTICA

Protocolos para correo electrnico (SMTP, POP3, IMAP)


y su Configuracin en Linux.

Arquitectura 10-Gigabit Ethernet, Funcionalidad y


Caractersticas de Capa Fsica (PHY) y Subcapa MAC.

Protocolo IPv4. Direccionamiento con clase y sin clase.

Protocolos DHCP, DNS y su Configuracin en Linux.

Protocolos de Enrutamiento RIP versin 2 y OSPF.


Funcionalidad y Caractersticas.

Protocolos para Correo


Electrnico

El Correo Electrnico o e-mail como se lo conoce


mas comnmente, es la solucin para transferir
informacin de forma rpida y menos costosa que
el correo convencional(correo en papel).

A inicios de la dcada de los 90 su uso pas de ser


meramente acadmico al mtodo de transferencia
de informacin de crecimiento exponencial.

Dentro del Modelo de Referencia OSI ste servicio


se ubica en la capa mas alta (7:Aplicacin)

Correo Electrnico
e-mail

El modelo de transferencia de informacin va email esta basado en un concepto bastante


sencillo el cual contempla dos sub-sistemas:

Los Agentes de Usuario, y

Los Agentes de Transferencia del Mensaje.

Correo Electrnico
e-mail

ESPECIFICACIONES IETF (INTERNET ENGINEERING TASK FORCE):

RFC 822 : RFC 2822 : RFC 5322 (Formato del Mensaje de Internet)

Correo Electrnico
e-mail
Es posible hacer una diferenciacin entre los Protocolos de
Transporte de Correo Electrnico (ej.: SMTP) y los Protocolos
de Acceso de Correo Electrnico (ej.: POP3 e IMAP) dado que:

Los Mail Transfer Protocols cubren la entrega de correos


electrnicos desde una aplicacin de correo hasta el
servidor, y desde un servidor de origen hasta un servidor de
destino.

Mientras que los Mail Agent Protocols se enfocan en las


aplicaciones de cliente de e-mail para recuperar mensajes
desde los servidores de correo electrnico.

SMTP

El Protocolo de Transferencia de Correo Simple se


concentra especificamente en como el sistema
subyacente de entrega de correo pasa los mensajes
a travs del internet desde un computador a otro.

Sus especificaciones estn establecidas en los RFC


821 : RFC 2821 : RFC 5321 del IETF.

El mensaje se entrega mediante la conexin TCP al


puerto 25 establecida entre el computador remitente
y el computador receptor.

SMTP

El servicio acepta pre definidamente conexiones


sin necesidad de autenticarse lo cual debe
tenerse muy en cuenta; si el mensaje no puede
ser entregado se genera un reporte con la
cabecera del mensaje para ser devuelto al
remitente.

La comunicacin se realiza mediante comandos


SMTP mismos que contemplan el uso de palabras
reservadas y parmetros al igual que la mayora
de lenguajes informticos.

SMTP
Los comandos que hacen posible las operaciones bsicas en el envo de correos
son:
HELO: (Hello) El cliente enva este comando al servidor SMTP para auto
identificarse e iniciar la "conversacin" SMTP, regularmente este comando es
acompaado por el nombre de dominio o direccin IP del cliente SMTP (ej.: HELO
cesarmac.grizzly-cave.com. Si el argumento usado es un nombre de dominio
entonces este debe ser un nombre de dominio completamente identificado (fully
qualified domain name) o FQDN.
MAIL FROM: Especifica la direccin del remitente. Este comando tambin le dice al
servidor SMTP que una nueva transaccin de correo esta empezando y hace que el
servidor inicialice todas sus tablas de estado y buffers, etc. Usualmente este el
primer comando luego del proceso de identificacin y de login. Si la direccin del
remitente es aceptada, el servidor contestara con un cdigo de respuesta 250 OK.
Ej.:
C: MAIL FROM:<cesitar@grizzly-cave.com>
S: 250 OK

SMTP
RCPT TO (Recipient To): Especifica la direccin del
destinatario. Este comando puede ser repetido mltiples
veces para un mensaje dado con el fin de entregar un
mismo mensaje a mltiples destinatarios. Ej.:
C:
S:
C:
S:
C:
S:

MAIL FROM:<cesitar@grizzly-cave.com>
250 OK
RCPT TO:<steve@apple.com>
250 OK
RCPT TO:<bill@microsoft>
250 OK

SMTP
DATA: Este comando inicia la transferencia del contenido del mensaje (texto del cuerpo
del mensaje, adjuntos, etc.) Al concluir el envo del comando al servidor, este responde
con un cdigo 354. Luego, los contenidos del mensaje pueden ser transferidos al servidor.
Cuando todos los contenidos del mensaje han sido enviados, un sencillo punto (".") debe
ser enviado en un linea independiente. Si el mensaje es aceptado para entrega, el cdigo
250 OK ser enviado por el servidor. Ej.:
C:
S:
C:
C:
C:
C:
C:
C:
C:
C:
C:
S:

DATA
354 Send message content; end with <CRLF>.<CRLF>
Date: Wed, 29 Apr 2015 12:50:29 -0500
From: Cesar Mena <cesitar@grizzly-cave.com>
Subject: Resultado del Examen Complexivo
To: steve@apple.com
Hola Steve,
El resultado del examen lo sabremos en un momento mas.
/Cesar.
.
250 OK

SMTP
RSET: (Reset) Si el comando RSET es enviado al servidor de e-mail, la
transaccin actual de correo seria abortada. La conexin no se
cerraria(de eso se encarga el comando QUIT) pero toda la informacin
sobre el remitente, destinatario(s) y datos serian eliminados y los buffers
y tablas de estados serian limpiados.
VRFY: (Verify) Este comando le pide al servidor que confirme que un
nombre de usuario especificado o un buzn es valido (existe). Si se
pregunta el nombre de usuario, el nombre completo del usuario y el
buzn completamente especificado se devuelve. Dado que VRFY
puede constituirse en una amenaza de seguridad en algunos servidores
es ignorado. El comando puede ser usado para averiguar nombres de
usuario en los servidores. Los servidores que ignoran el comando,
contestaran la peticin pero sin devolver la informacin solicitada.

SMTP
NOOP: (No operation) El comando NOOP hace
que el receptor envie una respuesta OK. El
proposito principal es verificar que el servidor esta
aun conectado y es capaz de comunicarse con el
cliente.
QUIT: Le solicita al servidor cerrar la conexin. Si
la conexin puede ser cerrada el servidor contesta
con un cdigo numrico 221 y entonces la sesin
es cerrada.

SMTP
Adicionalmente SMTP brinda un conjunto de comandos Extendidos o servicios
extendidos de SMTP. Estos servicios extendidos pueden ser distintos en cada
servidor, cada vez que se inicia una transaccin con el comando EHLO en
lugar de HELO el servidor generalmente entrega al cliente un listado de sus
comandos/servicios extendidos.
EHLO: (Extended Hello) Al igual que HELO inicia la conexin pero especifica
que se quiere usar el protocolo ESMPT. EHLO puede ser usado aun cuando no
se use ningn comando ESMTP; los servidores que no ofrezcan ningn
comando ESMTP adicional al menos reconocen el comando EHLO y
contestaran de forma adecuada.
AUTH: (Authentication) Este comando es usado para autenticar el cliente con
el servidor. El comando enva el usuario y clave del cliente al servidor. AUTH
puede ser combinado con otras palabras claves como PLAIN, LOGIN y CRAMMD5 para usar diferentes mtodos de login y diferentes niveles de seguridad.

SMTP
STARTTLS: (Start Transport Layer Security) Tanto clientes como servidores que
usan SMTP normalmente se comunican usando texto plano sobre el internet. La
comunicacin a menudo va a travs de uno o mas ruteadores que no son
controlados o fiables por el servidor y el cliente. Esta comunicacin puede ser
monitoreada y es posible alterar los mensajes que son enviados va esos
ruteadores.
Para mejorar la seguridad, puede ser usada una conexin TLS (Transport Layer
Security) encriptada cuando se comunican entre el servidor y el cliente. TLS es
mas til cuando un usuario y clave (enviados por el comando AUTH) necesitan
ser encriptados. TLS puede ser usado para encriptar el mensaje completo, pero
el comando no garantiza que todo el mensaje se mantenga encriptado durante
toda la ruta al receptor; algunos servidores de e-mail pueden decidir enviar el
mensaje sin encriptacion. Pero al menos el usuario y la clave usados con el
comando AUTH se mantendrn encriptados. Usando el comando STARTTLS
junto con el comando AUTH es posible autenticar usuarios de una manera muy
segura.

SMTP
SIZE: Este comando tiene dos propsitos. El servidor SMTP puede informar al
cliente cual es el tamao mximo del mensaje y el cliente le puede informar al
servidor el tamao (estimado) del mensaje de correo que ser enviado. El
cliente debera enviar un mensaje de tamao igual o menor al tamao
reportado por el servidor, pero generalmente no constituye un problema si el
mensaje es un tanto mas grande. Ej.:
S: 250 SIZE 1000000
C: MAIL FROM:<cesitar@grizzly-cave.com> SIZE=500000
El cliente enva el comando SIZE y la informacin del tamao junto con el
comando MAIL FROM. El servidor enva el comando SIZE y la informacin
solos. El tamao esta siempre especificado en bytes.
HELP: Este comando hace que el servidor le enva al cliente informacin til;
por ejemplo, una lista de los comandos soportados por ese servidor SMTP.

SMTP

En el sistema operativo Linux la instalacin y


puesta en marcha del servicio ha evolucionado
desde las primeras versiones hasta el punto
actual en el cual es una tarea relativamente
sencilla.

Tomando como referencia a la distribucin de


f e d o r a p ro c e d e m o s a l a i n s t a l a c i n y
configuracin de SMTP:

SMTP
Es posible configurar dos programas para SMTP: Postfix y Sendmail. La
versiones mas recientes no incluyen Postfix sin embargo Sendmail si esta
disponible.
Para verificar que servicio tenemos instalados recurrimos al comando:
[root@primary-ns ~]# alternatives --config mta
There is 1 program that provides 'mta'.
Selection

Command

----------------------------------------------*+ 1

/usr/sbin/sendmail.ssmtp

Enter to keep the current selection[+], or type selection number:


[root@primary-ns ~]#

La respuesta del servidor indica que nicamente disponemos de sendmail.

SMTP
De requerirlo, la instalacin de Postfix se la realiza
de la siguiente manera:
[root@primary-ns ~]# yum -y install postfix

Luego de resolver las dependencias de paquetes


para esta aplicacin la instalacin concluye
exitosamente:
Installed:
postfix.x86_64 2:2.11.3-1.fc21
Dependency Installed:
mariadb-common.x86_64 1:10.0.17-1.fc21 mariadb-config.x86_64 1:10.0.17-1.fc21
mariadb-libs.x86_64 1:10.0.17-1.fc21
Complete!

SMTP
Es posible verificar la instalacin al invocar al menu de servidores SMTP instalados en
el sistema nuevamente:
[root@primary-ns ~]# alternatives --config mta
There are 2 programs which provide 'mta'.
Selection

Command

----------------------------------------------*+ 1
2

/usr/sbin/sendmail.ssmtp
/usr/sbin/sendmail.postfix

Enter to keep the current selection[+], or type selection number:


2
Ahora ya es posible usar Postfix como servidor de SMTP.

SMTP
Con la verificacin del servicio activo es posible avanzar hacia la
configuracin de los parmetros adicionales dado que predeterminadamente
Postfix no permite conexiones de red diferentes a las de local host:
Editar el archivo /etc/postfix/main.cf.
Quite el comentario de la linea mydomain removiendo simbolo hash (#), y reemplace
domain.tld con el dominio del servidor de mail que esta siriviendo, such as grizzlycave.com.
Quite el comentario de la linea myorigin = $mydomain.
Quite el comentario de la linea myhostname, y reemplace host.domain.tld con el
hostname para el equipo.
Quite el comentario de la linea mydestination = $myhostname, localhost.$mydomain.
Quite el comentario de la linea mynetworks, y reemplace 168.100.189.0/28 con un
parmetro de red valido para los hosts que pueden conectarse al servidor.
Quite el comentario de la linea inet_interfaces = all.
Comente la linea inet_interfaces = localhost.
Reinicie el servicio de postfix.

POP3

El Protocolo de Oficina Postal versin 3 por sus


siglas en ingles describe la implementacin
simple de trasferencia de mensajes entre el
servidor de correo y el cliente de correo (agente
de usuario).

Aunque existe la versin segura de sta


implementacin (POP3S) el protocolo simple
realiza el proceso de autenticacin del cliente
contra el servidor mediante el envo de los datos
de usuario y contrasea.

POP3

Desde la perspectiva del servidor la gestin es


bastante mas puntual que desde el lado del
cliente puesto que los mensajes son
descargados y ledos en el cliente sin mantener
copias en el servidor.

Este enfoque en la gestin de recepcin de


mensajes hace que no sea posible la lectura de
los mensajes desde diferentes agente de
usuario.

POP3

Las conexiones TCP al servidor desde el agente


de usuario se las realiza al puerto 110
generalmente y la implementacin segura
POP3S en el puerto 995.

Las especificaciones IETF del protocolo POP3


estn contenidas en el RFC 1939.

IMAP

El Protocolo de Acceso a los Mensajes de Internet


(versin 4) en contraste a POP3 permite la visualizacin
y manipulacin de los mensajes directamente en el
servidor aun cuando el agente de usuario permita
gestionar los mensajes desde el computador local.

Existe la implementacin segura de IMAPS aunque lo


mas relevante de IMAP4 es la inclusin de nuevos
elementos mas verstiles como el de buzn de correo,
carpeta y otras funcionalidades de bsqueda que
permiten que la gestin de mensajes sea mas efectiva.

IMAP

El Protocolo de Acceso a los Mensajes de Internet


esta implementado con un conjunto de comandos
que hacen posible que la gestin de los mensajes
brinde nuevas alternativas.

Generalmente los agentes de usuario mantienen


embebidos dichos comandos de manera que stos
sean transparentes al usuario final; sin embargo,
basta conocer la sintaxis de los mismos para
interactuar con el servidor desde una conexin en
modo consola desde el equipo cliente.

IMAP

Las conexiones TCP al servidor desde el agente


de usuario se las realiza al puerto 143
generalmente; la implementacin segura IMAPS
est en el puerto 993.

Las especificaciones IETF del protocolo IMAP4


estn contenidas en el RFC 3501.

CONFIGURACION EN LINUX
DE POP3 E IMAP
Tanto POP3 como IMAP4 son Protocolos de Acceso a
Mail que en la distribucin Fedora de Linux estn
soportados pre determinadamente en el paquete
dovecot. Su instalacin procede de la siguiente manera:
[root@primary-ns ~]# yum -y install dovecot
Installed:
dovecot.x86_64 1:2.2.15-3.fc21
Dependency Installed:
clucene-core.x86_64 0:2.3.3.4-13.fc21
Complete!

Existen implementaciones que en busca de una mejora


en la fase de autenticacin han generado
modificaciones como: APOP, KPOP y RPOP.

CONFIGURACION EN LINUX
DE POP3 E IMAP
Los procesos imap-login y pop3-login los cuales implementan los protocolos IMAP y
POP3 son liberados por el demonio maestro de dovecot incluido en su paquete. El
uso de IMAP y POP3 es configurado a travs del archivo de configuracin /etc/
dovecot/dovecot.conf predeterminadamente dovecot ejecuta IMAP y POP3 junto con
sus versiones seguras usando SSL.
Para configurar los protocolos que se desea servir, es necesario quitar el comentario
de la linea protocols borrando el smbolo hash(#) y verificar que se encuentra el/los
nombre(s) de el/loss protocolo(s) deseado(s):
protocols imap imaps pop3 pop3s

Luego de grabar los cambios en el archivo editado, es mandatorio reiniciar el servicio


para que los cambios sean aplicados de manera inmediata:
[root@primary-ns ~]# systemctl restart dovecot.service

Excepto si se espera que el cambio surta efecto en el siguiente reinicio del sistema:
[root@primary-ns ~]# systemctl enable dovecot.service

TEMATICA

Arquitectura 10-Gigabit
Ethernet
10-Gigabit Ethernet es bsicamente la versin de
Ethernet de mayor velocidad. Soporta tasas de
datos de 10Gb/s. Ofrece beneficios similares a
aquellos del estndar de Ethernet precedente.
De todas maneras, sta no soportar el modo de
operacin half-duplex.

Arquitectura 10-Gigabit
Ethernet
Las potenciales aplicaciones y mercados para 10Gigabit Ethernet son enormes. Existen amplios
grupos de usuarios quienes demandan 10-Gigabit
Ethernet, por ejemplo, usuarios empresariales,
universidades, portadoras de telecomunicaciones
y proveedores del servicio de Internet.
Cada mercado tpicamente tiene diferentes
requerimientos para cobertura del enlace y costo.

Arquitectura 10-Gigabit
Ethernet
FUNCIONALIDAD

Bajo el modelo OSI, Ethernet es fundamentalmente un protocolo de


capa 1 y 2. 10-Gigabit Ethernet retiene la arquitectura clave de Ethernet,
el formato de la trama, y el tamao mximo y mnimo de la trama.

Justo como en Gigabit Ethernet, tanto 1000BASE-X y 1000BASE-T


siguen el estndar del modelo Ethernet, 10-Gigabit Ethernet continua la
evolucin de Ethernet en velocidad y distancia, mientras retiene la
misma arquitectura usada en otras especificaciones Ethernet, excepto
por un ingrediente clave.

Dado que 10-Gigabit Ethernet es una tecnologa full-duplex nicamente,


no necesita del protocolo (CSMA/CD) Deteccin de Portadora de
Acceso Mltiples/Deteccin de Colisiones usado en otras tecnologas
Ethernet. En cualquier otro aspecto, 10-Gigabit Ethernet concuerda con
el modelo original de Ethernet.

Arquitectura 10-Gigabit
Ethernet

Arquitectura 10-Gigabit
Ethernet
CARACTERISICAS DE CAPA FISICA (PHY)

En la capa fsica (capa 1), un dispositivo de Ethernet de


capa fsica (PHY) conecta el medio ptico o de cobre a
la capa MAC a travs de una tecnologa de conectividad.

La arquitectura de Ethernet divide mas all la capa fsica


en tres subcapas: Medio Fsico Dependiente (PMD),
Medio Fsico Adjunto (PMA), y Subcapa de Codificacin
Fsica(PCS). PMDs proveen la conexin fsica y
sealizacin al medio; los transceivers pticos, por
ejemplo son PMDs. La PCS consiste de codificacin (ej.:
64B/66B) y un serializador o multiplexor.

Arquitectura 10-Gigabit
Ethernet
CARACTERISICAS DE CAPA FISICA (PHY)

El estndar 802.3ae define dos tipos de PHY:

LAN PHY y

WAN PHY.

Estos proveen la misma funcionalidad, excepto que


PHY WAN tiene un conjunto de caractersticas
extendido en la PCS que habilita la conectividad con
redes SONET STS-192c/SHD VC-4-64c.

Arquitectura 10-Gigabit
Ethernet

Arquitectura 10-Gigabit
Ethernet
CARACTERISITICAS DE SUBCAPA MAC
La capa de Control de Acceso al Medio mantiene
las definiciones previas de Ethernet excepto por el
uso del protocolo CSMA/CD puesto que en 10Gigabit Ethernet solo se brindar soporte para fullduplex.
Esto a pesar de que la simplicidad de CSMA/CD
aport en gran medida al xito de Ethernet.

Arquitectura 10-Gigabit
Ethernet
CARACTERISITICAS DE SUBCAPA MAC
El formato de la trama MAC mantiene la
especificacin del estndar predecesor de
manera que la integracin con las redes
existentes sea lo mas uniforme, evitando adems
la fragmentacin y reensamblaje de las tramas .

Arquitectura 10-Gigabit
Ethernet
CARACTERISITICAS DE SUBCAPA MAC
El formato de la trama MAC mantiene el tamao de 64 octetos y
consta de los siguientes campos:

Prembulo: El prembulo de 7 octetos contiene un patrn de


0's y 1's alternados que son usados para permitir al receptor
la sincronizacin del tiempo para alcanzar un estado estable.

Delimitador de Inicio de la trama: El campo SFD es la


secuencia 10101011 usada para indicar el inicio de la trama.

Campos de Direccin: Cada trama MAC contiene las


direcciones de origen y destino. Cada direccin tiene un
tamao de 48 bits. El primero de los cuales es usado para
identificar la direccin como una direccin individual (0) o un
grupo de direcciones (1). El segundo es usado para indicar si
la direccin es definida localmente (1) o globalmente (0).

Arquitectura 10-Gigabit
Ethernet
CARACTERISITICAS DE SUBCAPA MAC

Longitud/Tipo: Si el nmero es menor que el tamao


mximo de trama vlida, indica la longitud de los datos
del cliente MAC. Si el numero es mayor o igual al
decimal 1536, representa el tipo de protocolo del cliente
MAC.

Datos y relleno: El relleno es opcional. Es necesario


nicamente cuando el paquete de datos es mas
pequeo que 38 octetos para asegurar el tamao de
trama mnimo de 64 octetos como est especificado en
el estndar existente.

Secuencia de chequeo de trama: El campo FCS


contiene un cdigo de redundancia cclica de 32-bits.
TEMATICA

Protocolo IPv4.

Es uno de los dos protocolos mas utilizados


dentro la Arquitectura TCP/IP.

Es el encargado de la gestin de la entrega de


paquetes entre los puntos finales.

Pertenece a la suite de paquetes de la capa de


Internet del modelo TCP/IP.

Protocolo IPv4.

Es un protocolo no orientado a conexin, no


confiable.

Las capas superiores en la arquitectura TCP/IP


entregan los datos a IP y ste, los empaqueta
dentro de un datagrama IP.

Las especificaciones IETF del protocolo IPv4


estn contenidas en el RFC 971.

Protocolo IPv4.
DATAGRAMA IP
32 BITS
4 BITS
VERSION

8 BITS

16 BITS

HLEN TIPO DE SERVICIO


IDENTIFICACION

TTL

LONGITUD TOTAL
FLAGS

PROTOCOLO

HEADER CHECKSUM

DIRECCION DE ORIGEN
DIRECCION DE DESTINO
OPCIONES
DATOS

FRAGMENT OFFSET

Protocolo IPv4.
DIRECCION IP

Una direccin IP es una direccin usada para identificar


de forma nica a un dispositivo en una red IP.

Est formada por cuatro octetos (8 bits) para dar como


resultado una direccin de 32 bits separada por puntos
y expresada en formato decimal.

Una porcin variable de la direccin identifica la red a


la que se encuentra adherida y la otra porcin tambin
variable indica el host que la identifica.

Protocolo IPv4.
MASCARA DE SUBRED

Al igual que las direcciones IP esta formada por


cuatro octetos y expresada en formato decimal.

La mascara de subred permite describir que


porcin de una direccin se refiere a la subred y
que parte al host.

Protocolo IPv4.
DIRECCIONAMIENTO CON CLASE

Referido en ocaciones como "direccionamiento jerrquico", es


el mecanismo inicial de direccionamiento IP, en la actualidad su
uso es muy poco frecuente.

Este esquema se dice que es auto identificable, dado que


permite identificar el limite entre prefijo y sufijo de la direccin
IP; esto, a partir de los tres bits de orden mayor de la direccin.

El acelerado crecimiento del uso de las redes oblig a buscar


nuevos esquemas de direccionamiento que superen las
limitaciones que suponen usar este esquema.

DIRECCIONAMIENTO CON CLASE

Protocolo IPv4.
DIRECCIONAMIENTO CON CLASE
Este esquema jerrquico supone dos debilidades
importantes:

Dependencia de la ubicacin de la direccin IP


en la red.

Tendencia al uso poco eficiente de la asignacin


de direcciones IP y su consecuente desperdicio.

Protocolo IPv4.
IPv4 SUBNET ADDRESSING
Es el direccionamiento de IPv4 mediante division de redes o
"subnetting":

Si bien IPv6 plantea alternativas de solucin para la ya


saturada demanda de direcciones IP, deber transcurrir un
tiempo hasta que sta versin este ampliamente instalada.

Entre tanto IPv6 sea adoptado como el protocolo standard


para Internet, existe una alternativa que brinda un
mecanismo eficiente en el uso de direcciones IP
denominado subnetting.

Protocolo IPv4.
IPv4 SUBNET ADDRESSING

Las subredes (subnetting) brindan flexibilidad al


mecanismo de direccionamiento IP. En ste
proceso, la porcin local es subdividida en el
campo de subred y el campo de host.

La asignacin la hace de forma discrecional el


administrador de red, en tanto y en cuanto, se
respeten las restricciones del estndar formal
para subredes.

Protocolo IPv4.
IPv4 SUBNET ADDRESSING

Para el procedimiento de subnetting es


necesario tomar bits de la porcin host.
Dependiendo de la clase de direccin existe un
lmite de bits que pueden ser "prestados".

Clase A

Tamao del campo


de host
24

Mximo # de bits
prestados
22

Clase B
Clase C

16
8

14
6

Protocolo IPv4.
IPv4 SUBNET ADDRESSING

Para que los paquetes sean entregados efectivamente, el


ruteador realizar la operacin lgica AND entre la
direccin IP de destino y su mscara de subred, el
resultado es la direccin de red/subred a la que el destino
pertenece.

Se debe tomar en cuenta que al subdividir una red,


implcitamente se generan una direccin de subred y
broadcast por cada nueva divisin. Estas direcciones de
red/subred y broadcast no deben ser asignadas a host
alguno ni a sus interfaces.

Protocolo IPv4.
DIRECCIONAMIENTO SIN CLASE

El mecanismo de divisin de redes para superar la


limitacin del nmero de direcciones IP, aun no
brindaba la flexibilidad de asignacin de la cantidad
de redes y/o hosts por red que en la prctica se
requera.

La respuesta a sta necesidad dio origen a la tcnica


de subnetting aplicando Mascaras de Subred de
Longitud Variable [Variable Lenght Subnet Masks
(VLSM)] dentro un segmento de red dado.

Protocolo IPv4.
DIRECCIONAMIENTO SIN CLASE

Como se mencion anteriormente, la versin 6 del


protocolo IP supera sta restriccin; sin embargo, aun
a la presente fecha, su implementacin aun no es
masiva ni es el estndar oficial en Internet.

La divisin de redes bajo el mecanismo VLSM permite


la coexistencia de redes grandes y pequeas
(indistintamente del numero de hosts) alcanzando un
uso amplio y mas efectivo del espacio de direcciones
IP.

Protocolo IPv4.
DIRECCIONAMIENTO SIN CLASE

No obstante a la flexibilidad brindada por VLSM, su


administracin demanda de un mayor esfuerzo y precisin;
puesto que de otro modo, podra presentarse el caso en el que
una direccin es interpretada de forma diferente en dos redes
fsicas, ste escenarios es conocido como ambigedad de
direcciones.

Con el uso adecuado de VLSM se logra flexibilidad en la


divisin de redes; esta divisin por otro lado, incrementa la
cantidad de subredes y las correspondientes rutas que
permitan a los ruteadores hacer una entrega eficientemente de
los datagramas IP.

Protocolo IPv4.
DIRECCIONAMIENTO SIN CLASE

El crecimiento de las tablas de ruteo en trminos del


volumen de paquetes a entregar y del procesamiento que
demandan esas operaciones, se tornan en factores crticos
para la estabilidad y confiabilidad del proceso de ruteo.

Nuevamente, la introduccin de una nueva tcnica dentro


del estndar se enfoca en resolver esta problemtica. La
tcnica se denomina Ruteo Inter-Dominio Sin Clase
[Classless Inter-Domain Routing (CIDR)] y consiste en
combinar multiples prefijos pequeos de red en un solo
prefijo mas grande.

Protocolo IPv4.
DIRECCIONAMIENTO SIN CLASE

La combinacin de rutas se conoce como


Agregacin de Rutas, el resultante prefijo mas
grande se lo llama tambin supernet. Este concepto
"supernetting" contrasta con el de subnetting que es
la divisin de bloques de direcciones.

Las especificaciones IETF para la estrategia de


direccionamiento CIDR estn contenidas en el RFC
4632 (1518, 1519).
TEMATICA

Protocolo DHCP

El Protocolo de Configuracin Dinmica de Host


DHCP permite la configuracin automtica de los
parmetros de red en los hosts.

Este procedimiento disminuye la probabilidad de


error al realizar esta tarea de forma manual.

El servicio DHCP instalado previamente en un


host servidor, contiene los rangos de direcciones
IP a ser entregados, as como tambin los plazos
de "arrendamiento".

Protocolo DHCP

Tanto los hosts, como el servicio DHCP, deben


estar conectados dentro del mismo segmento de
red, puesto que el requerimiento se lo hace a
travs del envo broadcast de un paquete de
descubrimiento DHCP solicitando al servicio una
direccin IP.

El servicio luego de identificar una direccin libre,


responder a sta peticin mediante un paquete
de ofrecimiento con los datos de la direccin IP
asignada.

Protocolo DHCP

El host arrendatario deber solicitar una nueva


direccin antes de que el plazo de
arrendamiento haya vencido.

Es importante verificar que todas las direcciones


arrendadas hayan sido devueltas para evitar
que stas se pierdan.

Protocolo DHCP

Comnmente ademas de la direccin IP,


informacin sobre la mascara de subred, IP de
la puerta de enlace predeterminada, servidor de
DNS son enviados por el servicio de DHCP al
host.

Las definiciones del protocolo DHCP estn


contenidas en la RFC 2131 y 2132.

Protocolo DHCP
CONFIGURACION EN LINUX
El procedimiento de instalacin es el siguiente:
[root@primary-ns ~]# yum -y install dhcp
Installed:
dhcp.x86_64 12:4.3.1-12.fc21
Dependency Updated:
dhclient.x86_64 12:4.3.1-12.fc21
12:4.3.1-12.fc21
dhcp-libs.x86_64 12:4.3.1-12.fc21
Complete!

dhcp-common.x86_64

Protocolo DHCP
CONFIGURACION EN LINUX
La instalacin de dhcp crea el archivo de configuracin /
etc/dhcp/dhcpd.conf, mismo que inicialmente esta vaco.
No obstante, el archivo de ejemplo /usr/share/doc/
dhcp-version/dhcpd.conf.sample puede ser utilizado
como base para configurar el servicio recin instalado:
D H C P t a m b i n u s a e l a r c h i v o /var/lib/dhcpd/
dhcpd.leases para almacenar la base de datos de
arrendamiento a los clientes.

Protocolo DHCP
CONFIGURACION EN LINUX
El primer paso al configurar un servidor DHCP es crear el archivo de configuracin que almacena la
informacin de red para los clientes. En este archivo se puede declarar opciones independientes y globales
los sistemas clientes.
El archivo de configuracin puede contener tabulaciones adicionales para mejor legibilidad. Las palabras
claves son case sensitive y las lneas que empiezan con el smbolo (#) son consideradas comentarios.
Hay dos tipos de declaraciones en un archivo de configuracin:

Parmetros - Declaran como realizar una tarea, ya sea para realizarla, o que opciones de configuracin de
red enviar al cliente.

Declaraciones - Describen la topologa de la red, los clientes, provee el direccionamiento para los clientes,
o aplica un grupo de parmetros a un grupo de declaraciones.

Los parmetros que inician con la palabra clave opcin son referidos como opciones. Estas opciones
controlan opciones de DHCP as como configura valores de parmetros que no son opcionales o controla
como se comporta el servidor DHCP.
Los parmetros (incluyendo opciones) declaradas antes de una seccin encerrada entre parntesis son
consideradas parmetros globales. Los parmetros globales aplican a todas las secciones bajo stos.

Protocolo DHCP
CONFIGURACION EN LINUX
En el siguiente ejemplo, las opciones routers, subnet-mask, domain-search,
domain-name-servers, y time-offset son usadas para cualquier sentencia
host declarada bajo sta.
Adicionalmente, una subred puede ser declarada, su declaracin debe estar incluida
para cada subred en la red. Caso contrario, falla el inicio del servidor DHCP.
Hay opciones globales para cada cliente DHCP en la subred y un rango declarado. A
los clientes les es asignada una direccin ip dentro del rango.
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers
192.168.1.254;
option subnet-mask
255.255.255.0;
option domain-search
grizzly-cave.com";
option domain-name-servers
192.168.1.1;
option time-offset
-18000;
# Eastern Standard Time
range 192.168.1.10 192.168.1.100;
}

Protocolo DHCP
CONFIGURACION EN LINUX
Para configurar un servidor DHCP que rente una direccin IP
dinmica a un sistema dentro de una subred, se requiere declarar un
tiempo predeterminado de renta, tiempo mximo de renta, y valores
de configuracin de la red para los clientes.
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-search "grizzly-cave.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
}

Protocolo DHCP
CONFIGURACION EN LINUX
En el caso de requerir la asignacin de una direccin IP basa en
la direccin MAC de la tarjeta de red, se debe usar el parmetro
hardware ethernet dentro de la declaracin host. Ej.: la
declaracin host gamebox especifica que la tarjeta de red con la
direccin 00:0c:29:49:01:29 siempre recibe la direccin IP
192.168.1.4: el parmetro opcional host-name tambin puede
ser usado para asignar un nombre al cliente.
host gamebox {
option host-name gamebox.grizzly-cave.com";
hardware ethernet 00:0c:29:49:01:29;
fixed-address 192.168.1.4;
}

Protocolo DHCP
CONFIGURACION EN LINUX
Todas las subredes que comparten la misma red fsica deberan ser declarar dentro de
la declaracin shared-network. Los parmetros dentro de shared-network, pero fuera
de las declaraciones subnet, son consideradas como parmetros globales. El nombre
de shared-network debe ser un titulo descriptivo para la red.
shared-network name {
option domain-search
test.grizzly-cave.com";
option domain-name-servers
ns1.grizzly-cave.com, ns2.grizzly-cave.com;
option routers
192.168.0.254;
more parameters for GRIZZLY-CAVE shared-network
subnet 192.168.1.0 netmask 255.255.252.0 {
parameters for subnet
range 192.168.1.1 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.252.0 {
parameters for subnet
range 192.168.2.1 192.168.2.254;
}
}

Protocolo DHCP
CONFIGURACION EN LINUX
Las declaraciones grupales group son usadas para aplicar parmetro globales a un
grupo de declaraciones. Ej.: shared network, subnet y hosts pueden ser agrupadas.
group {
option routers
192.168.1.254;
option subnet-mask
255.255.255.0;
option domain-search
"grizzly-cave.com";
option domain-name-servers
192.168.1.1;
option time-offset
-18000;
# Eastern Standard Time
host gamebox {
option host-name gamebox.grizzly-cave.com";
hardware ethernet 00:0c:29:49:01:29;
fixed-address 192.168.1.4;
}
host steve {
option host-name steve.grizzly-cave.com";
hardware ethernet 00:A1:C3:F2:DD:74;
fixed-address 192.168.1.7;
}
}

Protocolo DNS
Conocido tambin como servidor de nombres, es un sistema de red
que asocia nombres de equipos con su respectiva direccin IP.

Para los usuarios, esto tiene la ventaja de que pueden referirse a


maquinas en la red por sus nombres que usualmente son mas
fciles de recordar que direcciones IP numricas.

Para los administradores de sistemas, el uso de nombres de


servidores les permite cambiar direcciones IP para un host sin
afectar de ninguna manera a las consultas basadas en nombre, o a
decidir que maquinas manejan estas consultas.

La clave de ste servicio radica en la conveniencia que le supone al


ser humano por ejemplo, recordar el nombre de una pagina web
versus los cuatro octetos de la direccin IP del servidor que la aloja.

Protocolo DNS

DNS usualmente se implementa usando uno o mas servidores


centralizados que son autorizados para ciertos dominios.

Cuando un host cliente solicita informacin de un nameserver, ste


usualmente se conecta al puerto 53. El NS entonces intenta
resolver el nombre consultado.

Si ste no tiene la respuesta autorizada, o no tiene aun la respuesta


en cache por consultas previas, realiza la consulta a otros NS,
llamados root nameservers o NS raz, para determinar que NS esta
autorizado para los nombres consultados, luego los consulta para
obtener el nombre requerido.

Las definiciones del protocolo DNS estn contenidas en la RFC


1034, 1035 y 2181.

Protocolo DNS
Zonas de Nameservers
En un servidor de DNS (ej.: BIND - Berkley Internet Name Domain), toda la informacin
es almacenada en elementos de datos bsicos llamados registros de datos(resource
records) RR. El registro de recurso generalmente es un nombre de dominio
completamente calificado(fully qualified domain name) FQDN de un host, y este se
descompone en multiples secciones organizadas dentro de una jerarqua tipo rbol.
Esta jerarqua consiste de un tronco principal (main trunk), ramas primarias (primary
branches), ramas secundarias (secondary branches), y as sucesivamente. Ej.:
cesar.research.grizzly-cave.com
Cada nivel de la jerarqua esta dividido por un punto (.) En el ejemplo, com define el
dominio de nivel mas alto, grizzly-cave su subdominio, y research el subdominio de
grizzly-cave. En ste caso, cesar identifica el registro de recurso RR que es parte del
dominio research.grizzly-cave.com. Con excepcin de la parte mas distante hacia la
izquierda (esto es, cesar) cada una de estas secciones es llamada una zona y define
un espacio de nombres (namespace) especfico.

Protocolo DNS
Zonas de Nameservers
Cada nivel de la jerarqua esta dividido por un punto (.) En el ejemplo, com define
el dominio de nivel mas alto, grizzly-cave su subdominio, y research el
subdominio de grizzly-cave. En ste caso, cesar identifica el registro de recurso
RR que es parte del dominio research.grizzly-cave.com. Con excepcin de la parte
mas distante hacia la izquierda (esto es, cesar) cada una de estas secciones es
llamada una zona y define un espacio de nombres (namespace) especfico.
Se han definido 2 tipos de namespaces de alto nivel: Genricos y Paises.
Conceptualmente existen 250 dominio de alto nivel. La administracin de
nombrado de nivel mas alto es administrado por la ICAAN Corporacion de Internet
para la Asignacin de Nombre y Nmeros (Internet Corporation for Assigned
Names and Numbers quienes absorbieron a IANA en 1998). Las asignaciones de
segundo nivel las realizan los registradores (registrars) acreditados por la ICAAN

Protocolo DNS
Zonas de Nameservers
Genericas
aero

com

cisco
robot

biz

Pases
info

gov

washington

net

org us au cn ec jp es

ieee pmi
www
FQDN

edu

Protocolo DNS
Zonas de Nameservers
Las zonas estn definidas en NS autorizados a travs del uso de
archivos de zonas, los cuales contienen definiciones de los registros
de recursos RR en cada zona.
Los archivos de las Zonas estn almacenados en los NS primarios
(llamados tambin Master NS), donde se hacen los cambios a los
archivos, y los NS secundarios (llamados tambin Slave NS), los
cuales reciben las definiciones de las zonas de los NS primarios.
Tanto los unos como los otros estn autorizados para la zona y lucen
iguales para los clientes. Dependiendo de la configuracin, cualquier
NS puede tambin servir como servidor primario o secundario para
mltiples zonas al mismo tiempo.

Protocolo DNS
Tipos de Servidores de Nombres
Existen dos tipos de configuraciones de NS:

Autorizado (authoritative) Los servidores autorizados responden


a registros de recursos que son parte de sus zonas nicamente.
Esta categora incluye tanto NS primarios como secundarios.

Recursivo (recursive) Los servidores recursivos ofrecen


servicios de resolucin, pero no estn autorizados para ninguna
zona. Las respuestas para todas las resoluciones son
almacenadas en cache en una memoria por un periodo fijo, el
cual esta especificado por el registro de recurso obtenido.

Protocolo DNS
Tipos de Servidores de Nombres
Aun cuando un nameserver puede ser tanto autorizado como recursivo a la
vez, se recomienda no combinar los tipos de configuracin. Para poder
realizar su trabajo, los servidores autorizados deberan estar disponibles
para los clientes todo el tiempo.
Por otro lado, dado que una consulta recursiva tarda mucho mas que las
respuestas autorizadas, los servidores recursivos deberan estar disponibles
para un numero restringido de clientes nicamente, de otro modo son
susceptibles a los ataques de denegacin de servicio distribuidos
(Distributed Denial of Service DDoS).
BIND consiste de un conjunto de programas relacionados al servicio DNS.
Contiene un servidor de nombres monoltico llamado named, una utilidad de
administracin llamada rndc, y una herramienta de depuracin llamada dig.

Protocolo DNS
CONFIGURACION EN LINUX
La instalacin procede de la siguiente manera:
[root@primary-ns ~]# yum -y install bind
Installed:
bind.x86_64 32:9.9.6-8.P1.fc21
Dependency Updated:
bind-libs.x86_64 32:9.9.6-8.P1.fc21
bind-libs-lite.x86_64 32:9.9.6-8.P1.fc21
bind-license.noarch 32:9.9.6-8.P1.fc21
bind-utils.x86_64 32:9.9.6-8.P1.fc21
Complete!

Protocolo DNS
CONFIGURACION EN LINUX
Concluida la instalacin es necesario modificar el archivo /etc/named.conf que contiene la
configuracin principal del servicio. Adicionalmente en el directorio auxiliar /etc/named/ tambin se
registran archivos usados por el archivo principal de configuracin.
El archivo de configuracin consiste de una coleccin de sentencias con opciones anidadas y
rodeadas por llaves. Como en la mayora de archivos de configuracin, es necesario cuidar la
sintaxis, puesto que errores de este tipo derivan en imposibilidad de iniciar el servicio named.
statement-1 ["statement-1-name"] [statement-1-class] {
option-1;
option-2;
option-N;
};
statement-2 ["statement-2-name"] [statement-2-class] {
option-1;
option-2;
option-N;
};
statement-N ["statement-N-name"] [statement-N-class] {
option-1;
option-2;
option-N;
};

Protocolo DNS
CONFIGURACION EN LINUX
Los tipos de sentencias mas comunes en el archivo de
configuracin de BIND son:
acl: Permite definir listas de control de acceso sobre grupos
de hosts.
include: Permite invocar archivos externos de manera que
se limite el acceso y organizacin a informacin privilegiada.
options: Permite declarar opciones de configuracin
globales as como predefinidas.
zones: Define las caractersticas de una zona.

Protocolo DNS
CONFIGURACION EN LINUX
El nombre de la sentencia acl_name hace referencia a la lista de control de acceso, y la opcin
elemento concordante (match element) es usualmente una direccin IP individual 192.168.1.1 o
una notacin CIDR 192.168.1.0/24. Ej.:
acl acl-name {
match-element;
...
};

ACL puede ser usado en combinacin con otras sentencias, especialmente con options.
acl black-hats {
10.0.2.0/24;
192.168.0.0/24;
1234:5678::9abc/24;
};
acl red-hats {
10.0.1.0/24;
};
options {
blackhole { black-hats; };
allow-query { red-hats; };
allow-query-cache { red-hats; };
};

Protocolo DNS
CONFIGURACION EN LINUX
La sentencia include permite incluir archivos en el /etc/named.conf,
de manera que los datos potencialmente sensibles puedan ser ubicados
en un archivo separado con acceso restringido. El archivo invocado deber
ser siempre referido con su ruta absoluta. Ej.:
include "/etc/named.rfc1912.zones";

La sentencia options permite definir opciones globales de configuracin


del servidor as como parmetros predeterminados para otras sentencias.
Por ejemplo puede usarse para especificar la ubicacin del directorio de
trabajo para named, el tipo de consultas permitidas, etc.
options {
option;
...
};

Protocolo DNS
CONFIGURACION EN LINUX
La sentencia zone permite definir las caractersticas de una zona, as como la ubicacin de sus archivos de
configuracin y opciones de zona especificas; puede ser usado para sobrecargar las sentencias de opciones
globales. Ej.:
options {
allow-query
listen-on port
listen-on-v6 port
max-cache-size
directory
statistics-file

{ localhost; };
53 { 127.0.0.1; };
53 { ::1; };
256M;
"/var/named";
"/var/named/data/named_stats.txt";

recursion
yes;
dnssec-enable
yes;
dnssec-validation yes;
};
zone grizzly-cave.com" IN {
type master;
file "grizzly-cave.com.zone";
allow-transfer { 192.168.0.2; };
};
zone "grizzly-cave.com" {
type slave;
file "slaves/grizzly-cave.com.zone";
masters { 192.168.0.1; };
};

Protocolo DNS
CONFIGURACION EN LINUX
Los archivos de zonas contienen informacin acerca de un namespace.
Estos estn almacenados predeterminadamente en el directorio de trabajo
de named ubicado en /var/named/, y cada archivo de zona es nombrado
acorde con la opcin del archivo en la sentencia zona, usualmente de
manera que es relacione al dominio en cuestin e identifique el archivo
como contenedor de los datos de la zona.
Un archivo de zona consiste de directivas y registros e recursos. Las
directivas le indican al NS que ejecute las tareas o que aplique parmetros
especiales a la zona, los registros de recursos definen los parmetros de la
zona y asignan identidades a los hosts individuales. Mientras las directivas
son opcionales, los registros de recursos son requeridos con el fin de
proveer el servicio de nombre a una zona. Todas las directivas y registros
de recursos deben ser ingresados en lineas individuales.

Protocolo DNS
CONFIGURACION EN LINUX
Las Directivas Comunes son:
$INCLUDE: Esta directiva permite incluir otro archivo en el lugar en el que aparece, de
manera que los parmetros de otro zona puedan ser almacenados en un archivo de zona
separado. Ej.:
$INCLUDE /var/named/penguin.grizzly-cave.com
$ORIGIN: La directiva de origen permite agregar el nombre del dominio a registros no
calificados, como aquellos que tienen nicamente nombre de host. Se debe tener en cuenta
que el uso de esta directiva no es necesario si la zona esta especificada en /etc/
named.conf, dado que el nombre de la zona es usada predeterminadamente. Ej.:
$ORIGIN grizzly-cave.com.
$TTL: Para definir el Tiempo de Vida predeterminado para la zona se usa la directiva Time to
Live (TTL) $TTL, esto es, por cuanto tiempo es valido el registro de una zona. Cada registro
de recurso puede contener su propio valor TTL, la cual sobreescribe esta directiva. Ej.:
$TTL 1D

Protocolo DNS
CONFIGURACION EN LINUX
Los Registros de Recursos Comunes usados en las zonas son:
A: El registro de direccin Address especifica la direccin IP a ser asignada al nombre.
A
The Address record specifies an IP address to be assigned to a name. It takes the following form:
hostname IN A IP-address

If the hostname value is omitted, the record will point to the last specified hostname.
In Example11.9, Using the A resource record, the requests for server1.example.com are pointed to 10.0.1.3 or 10.0.1.5.
Example11.9.Using the A resource record
server1

IN
IN

A
A

10.0.1.3
10.0.1.5

CNAME
The Canonical Name record maps one name to another. Because of this, this type of record is sometimes referred to as an alias record. It takes the following form:
alias-name IN CNAME real-name

CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers. However, there are multiple restrictions for their usage:

CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops.

CNAME records should not contain other resource record types (such as A, NS, MX, etc.). The only exception are DNSSEC related records (that is, RRSIG, NSEC, etc.) when the zone is signed.

Other resource record that point to the fully qualified domain name (FQDN) of a host (that is, NS, MX, PTR) should not point to a CNAME record.
In Example11.10, Using the CNAME resource record, the A record binds a hostname to an IP address, while the CNAME record points the commonly used www hostname to it.
Example11.10.Using the CNAME resource record
server1
www

IN
IN

A
CNAME

10.0.1.5
server1

MX
The Mail Exchange record specifies where the mail sent to a particular namespace controlled by this zone should go. It takes the following form:
IN MX preference-value email-server-name

The email-server-name is a fully qualified domain name (FQDN). The preference-value allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The MX resource record with the lowest preference-value is preferred over the others. However, multiple email servers can possess the same value to
distribute email traffic evenly among them.
In Example11.11, Using the MX resource record, the first mail.example.com email server is preferred to the mail2.example.com email server when receiving email destined for the example.com domain.
Example11.11.Using the MX resource record
example.com.

IN
IN

MX
MX

10
20

mail.example.com.
mail2.example.com.

NS
The Nameserver record announces authoritative nameservers for a particular zone. It takes the following form:
IN NS nameserver-name

The nameserver-name should be a fully qualified domain name (FQDN). Note that when two nameservers are listed as authoritative for the domain, it is not important whether these nameservers are secondary nameservers, or if one of them is a primary server. They are both still considered authoritative.
Example11.12.Using the NS resource record
IN
IN

NS
NS

dns1.example.com.
dns2.example.com.

PTR
The Pointer record points to another part of the namespace. It takes the following form:
last-IP-digit IN PTR FQDN-of-system

The last-IP-digit directive is the last number in an IP address, and the FQDN-of-system is a fully qualified domain name (FQDN).
PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to Section11.2.2.4.2, A Reverse Name Resolution Zone File for more examples of PTR records in use.
SOA
The Start of Authority record announces important authoritative information about a namespace to the nameserver. Located after the directives, it is the first resource record in a zone file. It takes the following form:
@

IN

SOA primary-name-server hostmaster-email (


serial-number
time-to-refresh
time-to-retry
time-to-expire
minimum-TTL )

The directives

are as follows:
The @ symbol places the $ORIGIN directive (or the zone's name if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record.
The primary-name-server directive is the hostname of the primary nameserver that is authoritative for this domain.
The hostmaster-email directive is the email of the person to contact about the namespace.
The serial-number directive is a numerical value incremented every time the zone file is altered to indicate it is time for the named service to reload the zone.
The time-to-refresh directive is the numerical value secondary nameservers use to determine how long to wait before asking the primary nameserver if any changes have been made to the zone.
The time-to-retry directive is a numerical value used by secondary nameservers to determine the length of time to wait before issuing a refresh request in the event that the primary nameserver is not answering. If the primary server has not replied to a refresh request before the amount of time specified in the time-to-expire directive elapses, the
secondary servers stop responding as an authority for requests concerning that namespace.

In BIND 4 and 8, the minimum-TTL directive is the amount of time other nameservers cache the zone's information. In BIND 9, it defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (that is, 3H).
When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (M), hours (H), days (D), and weeks (W). Table11.6, Seconds compared to other time units shows an amount of time in seconds and the equivalent time in another format.
The Address record specifies an IP address to be assigned to a name. It takes the following form:
hostname IN A IP-address

If the hostname value is omitted, the record will point to the last specified hostname.

CNAME

TEMATICA

Protocolo DNS
CONFIGURACION EN LINUX
Los Registros de Recursos Comunes usados en las zonas
son:
A: El registro de direccin Address especifica la direccin
IP a ser asignada al nombre.
hostname IN A IP-address

Si el valor de hostname es omitido, el registro apuntar al


ltimo hostname especificado.
server1

IN

10.0.1.3

IN

10.0.1.5
TEMATICA

Protocolos de Enrutamiento
ENRUTAMIENTO

El enrutamiento es la funcin de entregar paquetes


entre los extremos de la comunicacin identificando la
mejor ruta. Esta funcin corresponde a varios
protocolos de la capa de Red (3) del modelo de
referencia OSI.

En esta capa, los equipos son activos y autnomos en


la medida en la que puede "decidir", que ruta tomar
para la entrega de paquetes basados en diferentes
mtricas de referencia.

Protocolos de Enrutamiento
ENRUTAMIENTO

El equipo toma la denominacin de ruteador (router) y


estar en capacidad de entregar paquetes a las redes
a las cuales esta conectado por una interfaz (puerto)
con su respectiva direccin IP asignada.

La entrega de paquetes depende de la direccin IP de


destino y la red a la que pertenece, ste calculo resulta
de la operacin lgica AND entre la direccin IP de
destino y su respectiva mascara de subred; finalmente,
se quita la porcin de host y obtenemos la red.

Protocolos de Enrutamiento
ENRUTAMIENTO

Los protocolos ruteables (Routed) son datos


siendo transportados a lo largo de la red. Ej. IP,
IPX, AppleTalk, DECnet.

Los protocolos no ruteables (Non Routable) no


soportan ser ruteados y asumen que todos los
hosts que se comunicarn estn en el mismo
segmento de red. Ej.: NetBEUI, DLC, LAC, DRP.

Protocolos de Enrutamiento
ENRUTAMIENTO

Los protocolos de enrutamiento (Routing)


distribuyen (anuncian) dinmicamente
informacin de enrutamiento a lo largo de todos
los ruteadores en la red y "aprenden" nuevas
rutas hacia los otros ruteadores conectados a la
red, en base a lo cual cada ruteador puede
determinar el mejor camino a usar para entregar
el trfico. Ej.: d OSPF, RIP, EIGRP or BGP.

Protocolos de Enrutamiento
ENRUTAMIENTO
Estos protocolos de enrutamiento son responsables de:

Enviar actualizaciones.

Con el conocimiento adecuado.

En el momento correcto y

Acorde a la ubicacin que mantienen sobre los


destinatarios de las actualizaciones.

Protocolos de Enrutamiento
ENRUTAMIENTO

Los algoritmos de ruteo, mientras tanto, son esa


parte del software de la capa de red,
responsable de decidir por cual de las lneas de
salida deber ser transmitido un paquete
entrante.

Protocolos de Enrutamiento
ENRUTAMIENTO

Los protocolos de enrutamiento actan ruteando


infor macin tanto dentro, como entre, sistemas
autnomos*, lo que da lugar a su divisin en:

Protocolos de Enrutamiento Interior (IGP). Ej: RIP, RIPv2,


IGRP, EIGRP, OSPF.

Protocolos de Enrutamiento Exterior (EGP). Ej. EGP, BGP:

* Un grupo de redes y ruteadores controlados por una sola


autoridad administrativa se denomina Sistema Autnomo.

Protocolos de Enrutamiento
ENRUTAMIENTO

En el caso de que sea necesario establecer


comunicacin entre dos hosts que comparten el
mismo segmento de red, no se requiere la
intervencin de un ruteador, ste es el caso del Ruteo
Directo.

En contraste, si los hosts a comunicarse estn


conectados a redes diferentes, la participacin del
ruteador es inevitable y en ese caso el Ruteo es
Indirecto.

Protocolos de Enrutamiento
ENRUTAMIENTO
Los protocolos referidos anteriormente fundamentan su accionar
en algoritmos de enrutamiento.

Si el mantenimiento de las tablas de rutas se lo realiza


manualmente se trata de Enrutamiento Esttico, ste algoritmo
presenta debilidades en la gestin actualizaciones y respuesta a
cambios de topologa convirtindose en una debilidad.

Cuando el proceso de actualizacin es automtico y responde


de igual forma ante cambios de topologa enviando
actualizaciones de enrutamiento hacia otros routers, entonces el
Enrutamiento es Dinmico.

Protocolos de Enrutamiento
ENRUTAMIENTO
Los algoritmos dinmicos de enrutamiento estn clasificados.

Si el mantenimiento de las tablas de rutas se lo realiza


manualmente se trata de Enrutamiento Esttico, ste algoritmo
presenta debilidades en la gestin actualizaciones y respuesta a
cambios de topologa convirtindose en una debilidad.

Cuando el proceso de actualizacin es automtico y responde


de igual forma ante cambios de topologa enviando
actualizaciones de enrutamiento hacia otros routers, entonces el
Enrutamiento es Dinmico.

Protocolos de Enrutamiento
ENRUTAMIENTO
Existe otra clasificacin para los algoritmos dinmicos de
enrutamiento.

Algoritmo Vector-Distancia*: Cada ruteador mantiene una lista


de todos los destinos conocidos en su FIB**. Cuando el ruteador
arranca, se inicializa la FIB para que contenga una entrada para
cada red conectada directamente. Cada entrada en la FIB
identifica una red destino, un ruteador de un salto para alcanzar
el destino, y la "distancia" a la red (de acuerdo a algunas
medidas de distancia).

*Tambin conocido como algoritmo de Bellman-Ford en honor a los investigadores que lo desarrollaron.
**FIB (Forwarding Information Base): Base de Informacin de Retransmisin.

Protocolos de Enrutamiento
ENRUTAMIENTO

Algoritmo Estado del Enlace*: Puede ser entendido


como el mapa que tiene cada ruteador, y que muestra
todos los otros ruteadores y las redes a las cuales se
conectan. En trminos abstractos, los ruteadores
corresponden a nodos en un grfico, y las redes que
conectan ruteadores corresponden a los lmites. Hay
un lmite (enlace) entre dos nodos en el grfico de la
topologa si y solo si el ruteador correspondiente
puede comunicarse directamente.

* Tambin conocido como algoritmo de Dijkstra

Protocolos de Enrutamiento
RIP version 2
RIPv2 fue descrito primero en la RFC 1388 y RFC 1723; la RFC
actual es 2453, escrita en Noviembre de 1998. Aunque los
entornos actuales usan protocolos de enrolamiento avanzados
como OSPF y EIGRP, aun hay redes que utilizan RIP. La necesidad
de usar VLSMs y otros requerimientos indujo la definicin de
RIPv2.
Las mejoras de RIPv2 sobre RIPv1 en la habilidad de usar VLSM,
con soporte para autenticacin de rutas, y con multicasting de
actualizaciones de ruta. RIPv2 soporta CIDR. Aun enva
actualizaciones cada 30 segundos y retiene el lmite de 15 saltos;
tambin usa actualizaciones disparadas. RIPv2 aun usa el puerto
UDP 520; el proceso RIP es responsable de verificar el nmero de
versin.

Protocolos de Enrutamiento
RIP version 2
Retiene las estrategias de prevencin de lazos de
veneno reverso y conteo al infinito. La distancias
administrativa de 120 de RIPv1 se mantiene. Finalmente,
RIPv2 usa la direccin IP 224.0.0.9 cuando se actualiza
la ruta multicast a otro ruteador RIP. Al igual que en
RIPv1, RIPv2 resume las redes IP en los lmites de las
redes. Es posible deshabitar auto-resumen si se requiere.
Se puede usar RIPv2 en redes pequeas donde se
requiere VLSM. Tambin trabaja al lmite de redes mas
grandes.

Protocolos de Enrutamiento
RIP version 2
Autenticacin
La autenticacin puede prevenir comunicaciones con cualquier
ruteador RIP que no estn planificados para que forme parte de la red,
como una estacin UNIX que este ejecutando routed. Unicamente las
actualizaciones RIP con la clave de autenticacin son aceptadas. La
RFC 1723 define la autenticacin simple de texto plano para RIPv2.
Autenticacin MD5
Adicionalmente a las claves de texto plano, existen implementaciones
propietarias que proveen la habilidad para usar autenticacin Message
Digest 5 (MD5), la cual esta definida en la RFC 1321. Su algoritmo
toma como entrada un mensaje de longitud arbitraria y produce una
salida de huella digital de 128-bits o mensaje asimilado de la entrada,
hacindolo mucho mas seguro que las claves de texto plano.

Protocolos de Enrutamiento
RIP version 2
Base de Informacin de Retransmisin (FIB) RIPv2
RIPv2 mantiene una base de datos de tablas de ruteo como en la Versin
1. La diferencia es que ste tambin mantiene informacin de la mscara
de subred. La siguiente lista repite la informacin de la tabla de RIPv1:

Direccin IP: Direcciones IP del host de destino o red, con mscara


de subred.

Gateway: La primera puerta de enlace a lo largo del camino al destino.

Interface: La red fsica que debe ser usada para alcanzar el destino.

Mtrica: Un nmero indicando el nmero de saltos hasta el destino.

Temporizador: La cantidad de tiempo desde que la entrada de la ruta


fue actualizada por ltima vez.

Protocolos de Enrutamiento
RIP version 2
Formato del Mensaje RIPv2
El formato del mensaje RIPv2 aprovecha la ventaja de los campos
no usados en el formato del mensaje RIPv1 al agregar mascaras
de subred y otra informacin.
La siguientes es una descripcin de cada campo:

Comando: Indica si el paquete es un mensaje de peticin o una


respuesta. El mensaje de peticin pide que un ruteador enve
toda o parte de su tabla de ruteo. Los mensajes de respuesta
contiene entradas de la ruta. El ruteador enva la respuesta
peridicamente o como una contestacin a una peticin.

Versin: Especifica la version de RIP usada. Se lo pone a 2


para RIPv2 y a 1 para RIPv1.

Protocolos de Enrutamiento
RIP version 2
Formato del Mensaje RIPv2

AFI: Especifica la familia de direccin usada. RIP esta


diseado para transportar informacin de ruteo para
diferentes protocolos. Cada entrada tiene un AFI para
indicar el tipo de direccin especificada. El AFI para IP es
2. El AFI se pone a 0xFFFF para la primera entrada para
indicar que el resto de la entrada contiene informacin de
autenticacin.

Tag de Ruta: Provee un metodo pra distinguir entre rutas


internas (aprendidas via RIP) y rutas externas (aprendidas
por otros protocolos). Se puede agregar este atributo
opcional durante la redistribucin de protocolos de ruteo.

Protocolos de Enrutamiento
RIP version 2
Formato del Mensaje RIPv2

Direccin IP: Especifica la direccin IP(red) del destino.

Mscara de subred: Contiene la mscara de subred


para el destino. SI ste campo es 0, no se ha
especificado mascara de subred para la entrada.

Siguiente salto: Indica la direccin IP del siguiente salto


donde los paquetes son enviado para alcanzar su
destino.

Mtrica: Indica cuantos saltos de ruteador para alcanzar


el destino. La Mtrica esta entre 1 y 15 para una ruta
vlida o 16 para una inalcanzable o ruta infinita.

Protocolos de Enrutamiento
RIP version 2
Formato del Mensaje RIPv2
Nuevamente, como en la Versin 1, el ruteador permite hasta 25
ocurrencias de las ltimas cinco palabras de 32-bits (20 bytes) para
hasta 25 rutas por mensaje RIP. Si el AFI especifica un mensaje
autenticado, el ruteador puede especificar nicamente 24 entradas
para la tabla de ruteo. Las actualizaciones son enviadas a la
direccin multicast 224.0.0.9.
Temporizadores RIPv2
Los temporizadores RIPv2 son los mismos que en la Versin 1. Se
envan actualizaciones peridicas cada 30 segundos. El
temporizador predeterminado invlido es 180 segundos, el
temporizador holddown es 180 segundos, y el temporizador flush es
240 segundos. Se puede escribir esta lista como 30/180/180/240
representando a los temporizadores U/I/H/F.

Protocolo de Enrutamiento
OSPF
Uno de los protocolos de puerta de enlace interna mas
comnmente usados en enlaces IP. OSPFv2 es un protocolo de
estndar abierto que provee enrutamiento para IPv4. OSPFv3
ofrece algunas mejoras para IPv6. OSPF es un protocolo
complejo que esta hecho de varios handshakes de protocolo,
anuncios de base de datos y tipos de paquetes.
OSPF es un protocolo de enrutamiento de puerta de enlace
que usa estado de enlace en lugar distancia vector para la
seleccin de la ruta. OSPF propaga anuncios del estado del
enlace (LSA) en lugar de actualizaciones a las tablas de ruteo.
Dado que lo nico que se intercambia son LSAs en lugar de
entradas de tablas de ruteo, las redes OSPF convergen de una
manera oportuna.

Protocolo de Enrutamiento
OSPF
OSPF usa un algoritmo estado del enlace para
construir y calcular el camino mas corto para
todos los destinos conocidos. Cada ruteador en
un rea OSPF contiene una base de datos de
estado del enlace idntica, la cual es una lista de
cada uno de las interfaces utilizables del ruteador
y de vecinos alcanzables.

Protocolo de Enrutamiento
OSPF
Estableciendo Relaciones OSPF con los Vecinos
OSPF es un protocolo de estado del enlace basado en un
estndar abierto. A un nivel alto, la operacin consiste de tres
elementos principales: descubrimiento de los vecinos, intercambio
de informacin dl estado del enlace, y clculo del mejor camino.
Para calcular el mejor camino, OSPF usa primero el camino mas
corto (SPF) o algoritmo de Dijkstra. La informacin de entrada
para clculo del SPF es la informacin de estado del enlace, la
cual es intercambiada entre ruteadores usando diferente tipos de
mensajes OSPF. Estos tipos de empajes ayudan a mejorar la
convergencia y escalabilidad en implementaciones OSPF
multitarea.

Protocolo de Enrutamiento
OSPF
Estableciendo Relaciones OSPF con los
Vecinos
OSPF soporta varios tipos de red diferentes. Las
cuales permiten configurar OSPF sobre una
variedad diferente de tecnologas de red
primarias.

Protocolo de Enrutamiento
OSPF
Caractersticas de OSPF
OSPF fue desarrollado por Equipo de Trabajo de Ingeniera
de Internet (IETF) para resolver las limitaciones de los
protocolos de enrutamiento distancia vector. Una de las
principales razones porque OSPF es ampliamente
implementado en las redes empresariales de hoy en da es
el hecho de que ste es un estndar abierto; OSPF no es
propietario. La Versin 1 del protocolo esta descrito la RFC
1131. La versin actual usada para IPv4, Versin 2, esta
especificada en la RFC 1247 y 2328. OSPF Versin 3, la
cual es usada en redes IPv6, esta especificada en la RFC
5340.

Protocolo de Enrutamiento
OSPF
Caractersticas de OSPF
OSPF ofrece un gran nivel de escalabilidad y
convergencia rpida. A pesar de que sta es de
configuracin relativamente simple en redes de
tamao pequeo y mediano, la implementacin
OSPF y la resolucin de problemas en redes de
gran escala puede en ocasiones ser desafiante.

Protocolo de Enrutamiento
OSPF
Caractersticas de OSPF
Las caractersticas claves del protocolo OSPF son las siguientes:

Transporte independiente: OSPF trabaja en la parte mas alta de IP y usa


el protocolo nmero 89. No depende de funciones de los protocolos TCP o
UDP de la capa de tranporte.

Uso eficiente de las actualizaciones: Cuando un ruteador OSPF


descubre primero un nuevo vecino, ste enva una actualizacin completa
con toda la informacin del estado del enlace. Todos los ruteadores dentro
de un rea OSPF deben tener informacin del estado del enlace idntica y
sincronizada en sus bases de datos de estado del enlace OSPF. Cuando
una red OSPF est en estado convergente y viene un nuevo enlace o un
enlace se vuelve no disponible, el ruteador OSPF enva nicamente una
actualizacin parcial a todos sus vecinos. Esta actualizacin ser
inundada a todos los ruteadores OSPF dentro de un rea.

Protocolo de Enrutamiento
OSPF

Mtrica: OSPF usa una mtrica que est basada en los costos
acumulados de todas las interfaces de origen a destino. Los costos
de la interface son inversamente proporcionales al ancho de banda
de la interface y pueden tambien ser definidos explicitamente.

Actualizacin de la direccin de destino: OSPF usa multicast y


unicast, en lugar de broadcast, para envo de mensajes. Las
direcciones multicast IPv4 usadas por OSPF son 224.0.0.5 para
enviar informacin a todos los ruteadores OSPF y 224.0.0.6 para
enviar informacin a ruteadores DR/BDR. Las direcciones multicast
IPv6 son FF02::5 para todos los ruteadores OSPFv3 y FF02::6 para
todos los ruteadores DR/BDR. Si las redes primarias no tienes
capacidades de broadcast, se deben establecer relaciones OSPF
con los vecinos usando una direccin unicast. Para IPv6, sta
direccin ser una direccin IPv6 de enlace local.

Protocolo de Enrutamiento
OSPF

Soporte para VLSM: OSPF es un protocolo de ruteo sin


clase. Soporta enmascaramiento de red de longitud
variable (VLSM) y redes marginales. Este porta
informacin de la mscara de subred las actualizaciones
de las rutas.

Resumen de rutas manual: Es posible resumir


manualmente rutas OSPF inter-rea en el Area de Frontera
del Ruteador (ABR), y es posible resumir rutas OSPF
externas en el Lmite del Sistema Autnomo del Ruteador
(ASBR). OSPF no sabe el concepto de auto resumen.

Autenticacin: OSPF soporta autenticacin de textoclaro, MD5 y SHA.

Bibliografa

Funcionalidad

Caractersticas

Vous aimerez peut-être aussi