Está en la página 1de 21

VLSM

INTRODUCION
El crecimiento exponencial de internet desde finales de los aos 80 llevo hacia la
merma y agotamiento progresivo de las direcciones IPv4 ofrecidas por
la IANA (Autoridad de nmeros asignados en internet). Para el 3 de febrero de
2011 la IANA asigno los ltimos bloques libres de direcciones IPv4.
El agotamiento de direcciones IP se convirti en el factor que impulso la creacin y
adopcin de diversas tecnologas que atenuaran el rpido agotamiento de estas.
Algunas de las tecnologas ms importantes son:

NAT (Traduccin de direcciones de red)


Redes privadas
DHCP (Protocolo para la configuracin dinmica del terminal)
Subredes
CIDR (Enrutamiento entre dominios sin clase)
VLSM (Mascara de subred de tamao variable)

Desde el 2007, IPv6 se ve como la solucin definitiva a largo plazo para el


agotamiento de las direcciones IPv4 aunque su implementacin se est realizando
a paso lento.

VLSM - Mascara de Longitud Variable


A diferencia del subneteo (subnetting) que genera una mscara comn (fija) y
cantidad de hosts iguales a todas las subredes, el proceso de VLSM toma una
direccin de red o subred y la divide en subredes ms pequeas adaptando las
mscaras segn las necesidades de hosts de cada subred, generando una
mscara diferente para las distintas subredes de una red. Esto permite no
desaprovechar un gran nmero de direcciones, sobre todo en los enlaces seriales.
Hay varios factores a tener en cuenta a la hora de subnetear y trabajar con VLSM:

El uso de VLSM solo es aplicable con los protocolos de enrutamiento sin


clase (classless) RIPv2, OSPF, EIGRP, BGP4 e IS-IS.

Al igual que en el subneteo, la cantidad de subredes y hosts est


supeditada a la direccin IP de red o subred que nos otorguen.

Es imposible que comprendan el proceso de obtencin de VLSM si no manejan


fluidamente el proceso de subneteo comn, por ello se brindara informacin bsica

necesaria con el fin de configurar el router para el enrutamiento IP, por ejemplo,
cmo las direcciones se descomponen y cmo funciona la divisin en subredes.

DIRECCIONES IP
Una direccin IP es una direccin usada con el fin de identificar de forma exclusiva
un dispositivo en una red IP. La direccin se compone de 32 bits binarios, que
pueden ser divisible en una porcin de red y porcin host con la ayuda de una
mscara de subred. Los 32 bits binarios se dividen en cuatro octetos (1 octeto = 8
bits). Cada octeto se convierte a decimal y separados por un punto (punto).
Ejemplo:
10. 1. 23. 19 (decimal)
00001010.00000001.00010111.00010011 (binario)
Estos octetos se descomponen para proporcionar un esquema de
direccionamiento que puede acomodar a las redes grandes y pequeas. Hay cinco
clases diferentes de redes, de A a E.

Mscaras de red
Una mscara de red le ayuda a saber qu parte de la direccin identifica la red y
qu parte de la direccin identifica el nodo. Clase A, redes B, y C tienen mscaras
por defecto, tambin conocidas como mascarillas naturales, como se muestra
aqu:
Clase A: 255.0.0.0
Clase B: 255.255.0.0
Clase C: 255.255.255.0
Subredes
Cada dato para interconectar a la red debe tener un identificador de red nico, con
cada nodo en ese enlace de ser miembro de la misma red. Si se rompe una
importante red (Clase A, B, o C) en subredes ms pequeas, que le permite crear
una red de subredes interconectadas. Cada enlace de datos en esta red tendra
entonces un ID de red / subred nica.
Para crear una subred de una red, se extiende la mascara natural con algunos de
los bits de la parte del ID host de la direccin con el fin de crear un ID de subred.
Ejemplo 1
Dada una red de clase C de 204.17.5.0 que tiene una mscara natural de
255.255.255.0, puede crear subredes de esta manera:
204.17.5.0

- 11001100.00010001.00000101.00000000

255.255.255.224 - 11111111.11111111.11111111.11100000
-------------------------- |sub| ---Al extender la mascarilla para 255.255.255.224, que ha tomado tres bits (indicados
por "sub") de la porcin de host original de la direccin y los utiliz para hacer
subredes. Con estos tres bits, es posible crear ocho subredes. Con los cinco bits
de ID de host restantes, cada subred puede tener hasta 32 direcciones de host, 30
de los cuales en realidad se pueden asignar a un dispositivo.
rango de direcciones de host 204.17.5.0

255.255.255.224

1 al 30

rango de direcciones de host 204.17.5.32

255.255.255.224

33-62

rango de direcciones de host 204.17.5.64

255.255.255.224

65-94

rango de direcciones de host 204.17.5.96

255.255.255.224

97-126

rango de direcciones de host 204.17.5.128

255.255.255.224

129-158

rango de direcciones de host 204.17.5.160

255.255.255.224

161-190

rango de direcciones de host 204.17.5.192

255.255.255.224

193-222

rango de direcciones de host 204.17.5.224

255.255.255.224

225-254

Ejemplo 2:

*Acepta 8 subdredes
*Cada uno de los routers est unido a cuatro subredes, (una subred es comn a
los dos routers.)
*Cada router tiene una direccin IP para cada subred a la que est unido.
*Cada subred potencialmente podra soportar hasta 30 direcciones de host.

Sin embargo para crear subredes debemos de tomar mas bits de los cuales
reduce un poco los host disponibles. Por ejemplo
1.- Clase C de 204.17.5.0 y una mscara de 255.255.255.224 (/ 27) le permite
tener ocho subredes, cada una con 32 direcciones de host (30 de los cuales
podran ser asignados a los dispositivos).
Si utiliza una mscara de 255.255.255.240 (/ 28):
204.17.5.0

- 11001100.00010001.00000101.00000000

255.255.255.240

- 11111111.11111111.11111111.11110000
--------------------------|Sub|---

*4 Bits para hacer subredes con bits de la izquierda (16 subredes,)


*4 Bits de la derecha cada una de las cuales pueden tener hasta 16 direcciones de
host (14 de los cuales se pueden asignar a los dispositivos).

2.- Clase B. de 172.16.0.0, con mascara natural de 255.255.0.0 o


172.16.0.0/16. La extensin de la mscara no va ms all de 255.255.0.0. por ello
se tiene la capacidad de crear muchos ms subredes que con la red de Clase
C. Si utiliza una mscara de 255.255.248.0 (/ 21), el nmero de subredes y hosts
por subred tiene esto permite?
172.16.0.0

- 10101100.00010000.00000000.00000000

255.255.248.0

- 11111111.11111111.11111000.00000000
----------------- | sub | -----------

Utiliza cinco bits de los bits de host para las subredes originales. Esto le permite
tener 32 subredes (2 5 ). Despus de usar los cinco bits para subredes, que se
quedan con 11 bits de direcciones de host. Esto permite que cada subred para
2048 tiene direcciones de host (2 11 ), 2.046 de los cuales podran ser asignados a
los dispositivos.

NOTA: Cmo determinar a que subred pertenece?

Ahora para determinar la subred a la que pertenecen una vez ya modificados se


realiza una la operacin lgica AND de tal modo que solamente en la
multiplicacin de 1*1=1 y en caso diferente dara cero por ejemplo:
DeviceA: 172.16.17.30/20
DeviceB: 172.16.28.15/20
Determinar la subred para DeviceA:
172.16.17.30

- 10101100.00010000.00010001.00011110

255.255.240.0

- 11111111.11111111.11110000.00000000
----------------- |sub| ------------

172.16.16.0 = =

10101100.00010000.00010000.00000000 (subred)

Determinar la subred para DeviceB:


172.16.28.15

- 10101100.00010000.00011100.00001111

255.255.240.0

- 11111111.11111111.11110000.00000000
----------------- |sub| ------------

172.16.16.0 = =

10101100.00010000.00010000.00000000 (subred)

Por lo tanto, DeviceA y DeviceB tienen direcciones que forman parte de la misma
subred.

Ejemplo3:

*C de 204.15.5.0/24
*Crear cinco subredes.

Ya que se necesita tres bits de subred, se queda con cinco bits para la parte de
host de la direccin.2 5 = 32 (30 utilizable).

Neta: 204.15.5.0/27 anfitrin rango de direcciones del 1 al 30


NETB: 204.15.5.32/27 anfitrin rango de direcciones 33-62
Netc: 204.15.5.64/27 anfitrin rango de direcciones 65-94

NetD: 204.15.5.96/27 anfitrin rango de direcciones 97-126


Nete: 204.15.5.128/27 anfitrin rango de direcciones 129-158
Aplicando VLSM a los ejemplos
En todos los ejemplos anteriores de subredes,
La misma mscara de subred se aplica para todas las subredes = cada
subred tiene el mismo nmero de direcciones de host disponibles.

Puede necesitar esto en algunos casos, pero, en la mayora de los casos, tienen la
misma mscara de subred para todas las subredes termina por perder el espacio
de direcciones. Por ejemplo, en el ejemplo 3, una red de clase C se dividi en
ocho subredes de igual tamao; Sin embargo, cada subred no utiliz todas las
direcciones de host disponibles, lo que resulta en prdida de espacio de
direcciones.

Tienen una gran cantidad de espacio de


direcciones de host sin usar
*Desperdicia espacio de direcciones
debido al hecho de que la misma
mscara de subred se utiliza para todas
las subredes.

Las mscaras de subred de longitud


variables (VLSM) le permite usar
diferentes mscaras para cada subred,
utilizando para ello el espacio de
direcciones de manera eficiente.

Neta: debe ser compatible con 14 hosts


NETB: debe ser compatible con 28 hosts
Netc: debe ser compatible con 2
anfitriones
NetD: debe ser compatible con 7
anfitriones
Nete: debe soportar 28 de acogida

Determinar qu mscara permite que el nmero requerido de los ejrcitos.


Neta: requiere una mscara / 28 (255.255.255.240) para apoyar a 14 hosts
NETB: requiere una mscara / 27 (255.255.255.224) para apoyar a 28 hosts
Netc: requiere una mscara / 30 (255.255.255.252) para apoyar 2 hosts
NetD *: requiere una mscara / 28 (255.255.255.240) para apoyar a 7 anfitriones
Nete: requiere una mscara / 27 (255.255.255.224) para apoyar a 28 hosts
* A / 29 (255.255.255.248) que slo permiten 6 direcciones de host utilizables
Por lo tanto, NetD requiere una mscara / 28.
La forma ms fcil para asignar las subredes es asignar el descendiente. Por
ejemplo, se puede asignar de esta forma:

NETB: 204.15.5.0/27 anfitrin rango de direcciones del 1 al 30


Nete: 204.15.5.32/27 anfitrin rango de direcciones 33-62
Neta: 204.15.5.64/28 anfitrin rango de direcciones 65 a 78
NetD: 204.15.5.80/28 anfitrin rango de direcciones 81-94
Netc: 204.15.5.96/30 anfitrin rango de direcciones 97 a 98

Ejemplo 4
Dada la red 192.168.0.0/24, desarrolle un esquema de direccionamiento que
cumpla con los siguientes requerimientos. Use VLSM.
1 Una subred de 20 hosts para ser asignada a la VLAN de Profesores
2 Una subred de 80 hosts para ser asignada a la VLAN de Estudiantes

3 Una subred de 20 hosts para ser asignada a la VLAN de Invitados


4 Tres subredes de 2 hosts para ser asignada a los enlaces entre enrutadores.
Solucin
Ordeno las subredes en orden decreciente: 80, 20, 20, 2, 2, 2.
La direccin que nos dan es 192.168.0.0/24 que es una clase C, por lo que por
definicin, el octeto disponible de hosts es el ltimo y los 3 primeros octetos son
las porciones de red.

Para 80 hosts necesito 7 bits (2^7=128, menos red y broadcas 126 hosts
mx.)
El prefijo de subred del primer bloque sera /25 (8-7=1; 24+1=25)
Tomando la subred cero, la primera direccin de subred sera
192.168.0.0/25, broadcast 192.168.0.127, por lo tanto el rango asignable
sera .1 hasta .126.

Para 20 hosts necesito 5 bits (2^5=32, es decir 30 hosts mx.).


Prefijo: /27 (8-5=3, 24+3=27);
Dir. de red: 192.168.0.128/27
Broadcast 192.168.0.159.
Rango asignable .129-.158.

La siguiente subred es del mismo tamao y el prefijo es el mismo.


Dir. de red: 192.168.0.160/27
Broadcast 192.168.0.191
Rango .161-.190.

Slo necesitan 2 bits (2^2=4, es decir 2 hosts mx)


Prefijo debe ser /30 (8-2=6, 24+6=30).
Dir. de enlace 1: 192.168.0.192,
dir. de broadcast en enlace 1: 192.168.0.195, rango .193-.194.
Dir. enlace 2: 192.168.0.196/30
broadcast en enlace 2: 192.168.0.199,
Rango .197-.198.
Dir. enlace 3: 192.168.0.200/30,
Broadcast enlace 3: 192.168.0.203
Rango: .201-.202.

El esquema resultado es:

Protocolo CIDR
Introduccin
Classless Interdomain Routing (CIDR) se present para mejorar tanto la utilizacin
del espacio de direcciones como la escalabilidad de ruteo en Internet. Era
necesario debido al rpido crecimiento de Internet y al crecimiento de las tablas de
ruteo IP contenidas en los routers de Internet.
Desarrollo
Se plane desde 1992 y se introdujo en septiembre de 1993 por IETF en el RFC
1517 y representa la ltima mejora en el modo de interpretar las direcciones IP. Su
introduccin permiti una mayor flexibilidad al dividir rangos de direcciones IP en
redes separadas.
A medida que Internet ha evolucionado y crecido en los ltimos aos, es claro que
pronto se enfrentarn varios problemas graves de escala:
- El agotamiento de direcciones de la clase B. Una causa fundamental de este
problema es la falta de una clase de direcciones de un rango apropiado para una
organizacin de mediano tamao. La clase C, con un mximo de 254 direcciones
de host, es demasiado pequeo, mientras que la clase B, que permite a un
mximo de 65534 direcciones de host, es demasiado grande para estar
densamente ocupada. El resultado es una ineficiente utilizacin de las direcciones
red de clase B.
-La sobrecarga de informacin de enrutamiento. El tamao y la tasa de
crecimiento de las tablas de enrutamiento de los routers de Internet estn ms all
de la capacidad de software actual para gestionar con eficacia.
[ 1]
-El eventual agotamiento de direcciones IP

Estos son los problemas que nos menciona el RFC 1517 y por los cuales se tuvo
la iniciativa de implementar CIDR que seguido de esto nos menciona sobre cmo
y sobre que parmetros se puede aplicar CIDR.
Si Internet planea apoyar una administracin de direcciones descentralizada,
entonces debe buscarse un equilibrio entre los requisitos de las direcciones IP
para un enrutamiento eficiente y la necesidad de una administracin de
direcciones descentralizada.
Arquitectura de CIDR

La arquitectura CIDR es aplicable a cualquier grupo de dominios conectados que


soporte IP versin 4. CIDR no requiere de todos los dominios en Internet para ser
convertidos para usar CIDR. Se supone que algunos de los dominios existentes en
Internet nunca se podrn convertir. A pesar de ello, CIDR seguir proporcionando
conectividad a dichos lugares, aunque la optimizacin de las rutas a estos lugares
puede verse afectada.
CIDR reemplaza la sintaxis previa para nombrar direcciones IP. En vez de asignar
bloques de direcciones en los lmites de los octetos, que implicaban las mscaras
por default de 8, 16 y 24 bits, CIDR usa la tcnica VLSM o mscaras de longitud
variable, para hacer posible la asignacin de prefijos de longitud arbitraria.
Concepto bsico y notacin de prefijo
En el sentido ms simple, el cambio de los prefijos de red de clase A, B y C a
prefijos sin clases es hacer explcito qu bits en una direccin IPv4 de 32 bits se
interpretan como el prefijo asociado a un sitio y que son los utilizados para
numerar los sistemas finales individuales dentro del sitio. En la notacin CIDR, un
prefijo se muestra como una cantidad de 4 octetos, al igual que una direccin IPv4
tradicional, seguido por el carcter "/", seguido por un valor decimal entre 0 y 32
que describe el nmero de Bits significativos.
El uso de prefijos sin clases con longitudes de prefijo explcitas permite una
adaptacin mucho ms flexible de los bloques de espacio de direcciones de
acuerdo con la necesidad real. Cuando anteriormente slo haba tres tamaos de
red disponibles, los prefijos se pueden definir para describir cualquier potencia de
bloque de dos tamaos de entre una y 2 ^ 32 direcciones de sistema finales. Los
Registros Regionales de Internet (RIRs), a su vez, asignan o asignan bloques de
direcciones ms pequeos a los Registros de Internet Locales (LIRs) o
Proveedores de Servicios de Internet (ISPs).
La siguiente tabla proporciona un atajo conveniente para todos los tamaos de
prefijo CIDR, mostrando el nmero de direcciones posibles en cada prefijo y el
nmero de prefijos de ese tamao que pueden estar numerados en el espacio de
direcciones IPv4 de 32 bits:
notation
-------n.n.n.n/32
n.n.n.x/31
n.n.n.x/30
n.n.n.x/29
n.n.n.x/28
n.n.n.x/27
n.n.n.x/26

addrs/block
----------1
2
4
8
16
32
64

# blocks
---------4294967296
2147483648
1073741824
536870912
268435456
134217728
67108864

"host route"
"p2p link"

n.n.n.x/25
n.n.n.0/24
n.n.x.0/23
n.n.x.0/22
n.n.x.0/21
n.n.x.0/20
n.n.x.0/19
n.n.x.0/18
n.n.x.0/17
n.n.0.0/16
n.x.0.0/15
n.x.0.0/14
n.x.0.0/13
n.x.0.0/12
n.x.0.0/11
n.x.0.0/10
n.x.0.0/9
n.0.0.0/8
x.0.0.0/7
x.0.0.0/6
x.0.0.0/5
x.0.0.0/4
x.0.0.0/3
x.0.0.0/2
x.0.0.0/1
0.0.0.0/0

128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728
268435456
536870912
1073741824
2147483648
4294967296

33554432
16777216
8388608
4194304
2097152
1048576
524288
262144
131072
65536
32768
16384
8192
4096
2048
1024
512
256
128
64
32
16
8
4
2
1

legacy "Class C"

legacy "Class B"

legacy "Class A"

"default route"

-n es un valor de octeto decimal de 8 bits.


-X es un valor de 1 a 7 bits, basado en la longitud del prefijo.
Para que CIDR tuviera xito en la reduccin del tamao y la tasa de crecimiento
del sistema de enrutamiento global, era necesario cambiar el proceso de
asignacin de direcciones IPv4 para hacer posible la agregacin de informacin de
enrutamiento a lo largo de lneas topolgicas. Dado que, en general, la topologa
de la red est determinada por los proveedores de servicios que la han construido,
las asignaciones de direcciones topolgicamente significativas son
necesariamente orientadas al proveedor de servicios.
Consideraciones de implementacin de enrutamiento
Con el cambio de redes con clase a prefijos sin clases, no es posible inferir la
mscara de red del patrn de bits inicial de una direccin IPv4. Esto tiene
implicaciones sobre cmo se almacena y se propaga la informacin de
enrutamiento. Las mscaras de red o las longitudes de prefijo deben estar
explcitamente incluidas en los protocolos de enrutamiento. Los protocolos de
enrutamiento interior, tales como OSPF, IS-IS, RIPv2, EIGRP, y el protocolo de

enrutamiento exterior BGP versin 4, soportan esta funcionalidad, habiendo sido


desarrollados o modificados como parte del despliegue del enrutamiento entre
dominios sin clases durante los aos noventa.
Los protocolos de enrutamiento interior ms antiguos, como RIP, HELLO, el
Protocolo de enrutamiento de Cisco Gateway Interior (IGRP) y los protocolos de
enrutamiento externos ms antiguos, como el Protocolo de puerta exterior EGP, no
admiten el transporte explcito de longitud de mscara de prefijo y por lo tanto, no
se pueden utilizar eficazmente en internet. Aunque su uso puede ser apropiado en
configuraciones sencillas de sitios finales heredados, se consideran obsoletos y no
deben usarse en redes de trnsito conectadas al Internet global.
De forma similar, las tablas de enrutamiento y reenvo en el equipo de red de capa
3 deben organizarse para almacenar la longitud del prefijo o la mscara. No se
puede esperar que el equipo que organiza su informacin de enrutamiento y
reenvo de acuerdo con las convenciones de red y subred de clase A, B y C
existentes no funcione correctamente en las redes conectadas a internet; No se
recomienda el uso de dicho equipo. Afortunadamente, muy poco de este tipo de
equipo est en uso hoy en da.
Reglas para el anuncio de la ruta
1.- El reenvo en Internet se realiza sobre una base de coincidencia ms larga.
Esto implica que los destinos que son multi-homed, relativos a un dominio de
enrutamiento, siempre deben ser anunciados explcitamente en ese dominio de
enrutamiento, es decir, no se pueden resumir. Si una red es multi-homed, todos
sus caminos en un dominio de enrutamiento que es "superior" en la jerarqua de
las redes debe ser conocido por la red "superior.
2.- Un router que genera una ruta agregada para rutas mltiples, las rutas ms
especficas deben descartar paquetes que coincidan con la ruta agregada, pero no
con ninguna de las rutas ms especficas. En otras palabras, el "salto siguiente"
para la ruta agregada debe ser el destino nulo. Esto es necesario para evitar los
bucles de reenvo cuando algunas direcciones cubiertas por el agregado no son
accesibles.
Tenga en cuenta que durante los fallos, el enrutamiento parcial del trfico a un sitio
que toma su espacio de direcciones de un proveedor de servicios pero que es
realmente alcanzable slo a travs de otro puede ocurrir porque dicho trfico se
reenva a lo largo de la ruta anunciada por la ruta agregada. La regla 2 evitar la
mala distribucin de paquetes, haciendo que el anunciante de la ruta agregada
descarte dicho trfico, pero la salida de un "traceroute" y otras herramientas
similares que existe un problema dentro de esa red en lugar de en la red que ya

no est publicitando el prefijo ms especfico. Esto puede ser confuso para


aquellos que tratan de diagnosticar problemas de conectividad.
Tambin debe generalizarse una implementacin siguiendo estas reglas, de
manera que se acepte un nmero de red y una mscara arbitraria para todos los
destinos de enrutamiento. Tenga en cuenta que la ruta degenerada al prefijo
0.0.0.0/0 se utiliza como ruta por defecto y debe ser aceptada por todas las
implementaciones. Adems, para protegerse contra los anuncios accidentales de
esta ruta, esta slo debera publicarse en otro dominio de enrutamiento cuando un
router est explcitamente configurado para hacerlo, nunca como una opcin
"predeterminada" no configurada.
La regla 1 garantiza que el algoritmo de reenvo utilizado es coherente entre
protocolos de enrutamiento e implementaciones. Las redes multihomed siempre
son anunciadas explcitamente por cada proveedor de servicios a travs del cual
se enrutan, aunque sean un subconjunto especfico del agregado de un proveedor
de servicios. Puede parecer que el proveedor de servicios principal podra
anunciar implcitamente el sitio multihomed como parte de su agregado, pero el
reenvo de coincidencias ms largas hace que esto no funcione.
La regla 2 garantiza que no se forman bucles de enrutamiento debido a la
agregacin. Tenga en cuenta que el manejo de la ruta "default" (0.0.0.0/0) es un
caso especial de esta regla; una red no debe seguir los destinos predeterminados
que forman parte de uno de sus anuncios agregados.
Los sistemas que procesan anuncios de rutas deben ser capaces de verificar que
la informacin que reciben es aceptable de acuerdo con las reglas de la poltica.
Las implementaciones que filtran anuncios de ruta deben permitir mscaras o
longitudes de prefijo en elementos de filtro. Por lo tanto, los elementos de filtro que
anteriormente se especificaron como:
accept 172.16.0.0
accept 172.25.120.0.0
accept 172.31.0.0
deny 10.2.0.0
accept 10.0.0.0

Ahora lucen como lo siguiente:


accept 172.16.0.0/16
accept 172.25.0.0/16
accept 172.31.0.0/16
deny 10.2.0.0/16
accept 10.0.0.0/8

Esto es simplemente hacer explcita la mscara de red que estaba implicada por
las clases A, B y C. Tambin es til mejorar la capacidad de filtrado para permitir la
coincidencia de un prefijo y ms especfico todos los prefijos con el mismo patrn
de bits. Afortunadamente, esta funcionalidad ha sido implementada por la mayora
de los vendedores de equipos utilizados en internet.
La generacin de una ruta agregada se especifica generalmente estticamente o
en respuesta al aprendizaje de una ruta dinmica activa para un prefijo contenido
dentro de la ruta agregada. Si se realiza este anuncio dinmico de ruta agregada,
se debe tener cuidado de que las rutas no se agreguen ni se retiren
excesivamente. En general, se aade un anuncio de ruta de agregado dinmico
cuando al menos un componente del agregado llega a ser alcanzable y se retira
slo cuando todos los componentes se vuelven inaccesibles. Las rutas agregadas
y configuradas correctamente son ms estables que las rutas no agregadas y, por
lo tanto, mejoran la estabilidad global del enrutamiento.
Consideraciones de ruta de propagacin y protocolo de ruteo.
Antes del despliegue original de CIDR, la prctica comn era propagar rutas
aprendidas a travs de protocolos de enrutamiento externos, como EGP o BGP, a
travs del protocolo de enrutamiento interior, normalmente OSPF, IS-IS o RIP. Esto
se hizo para asegurar que se eligieran puntos de salida consistentes y correctos
para que el trfico se enviara a un destino aprendido a travs de dichos
protocolos. Cuatro efectos evolutivos 1) El advenimiento de CIDR 2) El crecimiento
explosivo del estado de enrutamiento global 3) La adopcin generalizada de BGP4
y 4) El requisito de propagar la informacin de ruta completa, se han combinado
para desaprobar esa prctica. Para garantizar la propagacin correcta del camino
y evitar la incoherencia del enrutamiento entre sistemas autnomos, las redes de
trnsito deben usar BGP interno para transportar rutas aprendidas de otros
proveedores tanto dentro como a travs de sus redes.
Consideraciones sobre DNS
Un aspecto de los servicios de Internet que se vio notablemente afectado por el
traslado al CIDR fue el mecanismo utilizado para la traduccin de direccin a
nombre: la zona IN-ADDR.ARPA del sistema de dominios. Debido a que esta zona
est delegada slo en los lmites de octetos, el paso a un plan de asignacin de
direcciones que utiliza direccionamiento orientado a bits causo un cierto aumento
de trabajo para aquellos que mantienen partes de la zona IN-ADDR.ARPA.

Transicin a una solucin de largo plazo


CIDR fue diseado para ser una solucin a corto plazo a los problemas de
enrutamiento de estado y el agotamiento de direcciones en Internet IPv4. No
cambia las arquitecturas fundamentales de enrutamiento o direccionamiento de
Internet. No se espera que afecte a los planes de transicin hacia una solucin
ms a largo plazo, excepto, quiz, al retrasar la urgencia de desarrollar una
solucin de este tipo.
Anlisis del efecto de CIDR en el enrutamiento global
Cuando CIDR fue propuesto por primera vez a principios de la dcada de 1990,
los autores originales hicieron algunas observaciones sobre la tasa de crecimiento
del estado de enrutamiento global y ofrecieron proyecciones sobre cmo el
despliegue del CIDR podra reducir lo que pareca ser un crecimiento exponencial
a una tasa ms sostenible. Desde ese despliegue, un esfuerzo continuo, llamado
"El Informe CIDR" [CRPT], ha intentado cuantificar y rastrear esa tasa de
crecimiento. A continuacin se presenta un breve resumen del informe del CIDR
de marzo de 2005, con un intento de explicar los diversos patrones y cambios en
la tasa de crecimiento que se han producido desde que las mediciones del tamao
del estado de enrutamiento global comenzaron en 1988.
En 1992, cuando CIDR se desarroll por primera vez, hubo serios problemas con
el crecimiento continuo de Internet. El crecimiento en la complejidad del estado de
enrutamiento y el rpido aumento en el consumo de espacio de direcciones
hicieron que parezca que uno o ambos problemas impediran el crecimiento
continuo de Internet en pocos aos.
La arquitectura del sistema de enrutamiento IPv4 lleva informacin de topologa
basada en anuncios de direcciones agregadas y una coleccin de anuncios ms
especficos que estn asociados con ingeniera de trfico, multi-homing y
configuracin local.
Una pregunta obvia es si el CIDR puede seguir siendo un enfoque viable para
mantener el crecimiento global del estado de enrutamiento y tratar el agotamiento
del espacio a tasas sostenibles. Las mediciones recientes indican que el
crecimiento exponencial se ha reanudado, pero un anlisis posterior sugiere que
esta tendencia puede ser mitigada por un esfuerzo ms activo para educar a los
proveedores de servicios en cuanto a estrategias de agregacin eficientes y la
configuracin adecuada del equipo.
Mirando hacia adelante, existe una clara necesidad de una mejor tecnologa de
multi-homing que no requiere el estado de enrutamiento global para cada sitio y

para los mtodos de realizar el equilibrio de carga de trfico que no requieren


agregar an ms estado. Sin tales desarrollos y en ausencia de grandes cambios
arquitectnicos, la agregacin es la nica herramienta disponible para hacer
escala de enrutamiento en el Internet global.
Explicacin de sumarizacin de rutas.
El protocolo CIDR trabaja con sumarizacin de rutas para minimizar el trabajo de
los routers y optimizar memoria de las tablas de enrutamiento en cada dispositivo.
De esta forma evitamos una sobre carga de rutas.
El procedimiento para realizar la sumarizacin de rutas es muy simple, se trata de
unificar un rango de direcciones IPv4 y tiene una mejor demostracin cuando
configuramos un router para rutas estticas y se hace como lo indican los
siguientes pasos:
1.- Convertir las direcciones a formato binario, y ordenarlas de mayo a menor.
2.- Revisar los bits que ms coincidan de lado izquierdo, para determinar la
mscara de la ruta sumarizada.
3.- Por ltimo los bits que no coinciden se convierten en ceros, los que coinciden
se quedan igual y es nuestra nueva direccin de red con nuestra nueva mascara.

GLOSARIO

Direccin - El identificador de nmero nico asignado a un host o interfaz


de una red.

Subred - Una parte de una red que comparte una direccin de subred
particular.

Mscara de subred - Una combinacin de 32 bits que se utiliza para


describir qu parte de una direccin se refiere a la subred y qu parte se refiere
a la acogida.

Interfaz - Una conexin de red.

Si ya ha recibido su direccin legtima (es) desde el Centro de Informacin de Red


de Internet (InterNIC), est listo para comenzar. Si no va a conectar a Internet,
Cisco sugiere encarecidamente que utilice direcciones reservadas de RFC 1918
Bibliografa:
[1] RFC 1517: Applicability Statement for the Implementation of Classless InterDomain Routing (CIDR).
[2] RFC 4632: Classless Inter-Domain Routing (CIDR): The Internet Address
Assignment and Aggregation Plan.
[3] http://giret.ufps.edu.co/cisco/descargas/Presentaciones/Modulo2_capitulo6.pdf
[4] https://tele3comuts.jimdo.com/teoria/vlsm/introducci%C3%B3n-al-vlsm/
[5] http://mikrotikxperts.com/index.php/informacion/conocimientos-basicos/16tutorial-vlsm
[6] http://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocolrip/13788-3.html#anc11
[7] http://www.ciscopress.com/articles/article.asp?p=2169292&seqNum=2
[8] http://mikrotikxperts.com/index.php/informacion/conocimientos-basicos/16tutorial-vlsm
[9]http://www.pearsonitcertification.com/articles/article.aspx?
p=2168927&seqNum=6