Ir al contenido principal

Sistema autónomo (ASN) 32 bits - LACNIC/Politicas


Cito textual. <<

ASN de 32 bits

Introducción:

Desde el 1 de enero de 2007, al igual que los demás RIRs, LACNIC está asignando a sus miembros Números de Sistemas Autónomos (ASNs) de 32 bits.

Hasta ese entonces los ASNs asignados eran de 16 bits con lo que la cantidad máxima disponible era de aproximadamente 65 mil ASNs.

Anticipando un posible agotamiento del espacio de ASNs de 16 bits, se iniciaron en 2001 los primeros estudios y propuestas para expandir el formato del ASN para 32 bits.

El trabajo concluyó en 2007 con la publicación de un documento de la IETF (Internet Engineering Task Force), llamado RFC 4893. Este documento indica el nuevo formato de ASN, su utilización en protocolos de ruteo como el BGP y también su interacción con otros sistemas y protocolos que todavía no han sido actualizados para soportar el nuevo formato.

Desde esa fecha, IANA asigna a los RIRs bloques de ASN de 32 bits para su subsecuente asignación dentro de cada región.


Política:

Ya en el año 2006 se estaba discutiendo a nivel de los RIRs propuestas de políticas para asignación de ASNs de 32 bits. En ellas se mantienen los criterios en cuanto a necesidad de que la organización sea "multihomed" o de que tuviera una política única de ruteo para justificar así la asignación. 
Esa política para asignación de ASN incluye también criterios para la transición entre la asignación de ASN 16 bits para la de 32 bits.

La política regional adoptada en LACNIC (que es similar a las de otras regiones) establece que en las solicitudes de ASNs realizadas a partir del 1 de enero de 2007 se debe indicar expresamente que se desea un ASN de 32 bits. En caso contrario la asignación por defecto será de un ASN 16 bits.

De acuerdo con esta misma política, ese criterio debe ser modificado a partir del 1 de enero de 2009. Así, a partir de esa fecha, las solicitudes realizadas considerarán por defecto la asignación de ASNs de 32 bits, mientras que ASNs de 16 bits serán asignados únicamente cuando sean explícitamente solicitados.


Situación Actual:

Es importante recordar que por más que aún existen ASNs de 16 bits disponibles, a partir de enero de 2009 solamente serán asignados a quienes explicitamente lo soliciten.



Especialmente cuando como es sabido, existen sistemas y equipos que no soportan ASNs de 32 bits, lo que puede afectar a las organizaciones que estén optando por una política de ruteo redundante, para lo que necesitarán de un ASN y, en algunos casos, de nuevos equipos de enrutamiento.

Entonces si bien no se trata de un problema urgente, pues las proyecciones actuales indican que aún existen ASNs de 16 bits para 2 o 3 años más, es un aspecto al que se le debe prestar especial atención.
Ante esta situación, creemos importante recomendar que en la planificación y proyectos de nuevas redes se considere la posible necesidad de utilizar ASNs de 32 bits, lo que puede repercutir en las decisiones de compra de nuevos equipos o sistemas de redes.

Se recomienda también a los administradores de redes ya en operación que verifiquen junto a los proveedores de sus equipos y sistemas, el soporte de ASN de 32 bits en futuras versiones de sus productos.

Si bien los mecanismos para transición son simples y permiten que sistemas más antiguos funcionen con estos nuevos ASN sin necesidad de actualización, es importante el soporte a esa nueva versión del ASN para contar con todas las herramientas a la que los administradores están habituados hasta este momento.

Por último, existe en la comunidad global un debate importante sobre el tipo de representación para los ASNs de 32 bits. Hasta el momento la representación elegida consiste en la denominada “as-dot2” donde los 32 bits se representan de la siguiente manera: <valor de 16 bits más significativo en formato decimal>.<valor de 16 bits menos significativo en formato decimal>. La utilización de esta representación ha sido cuestionada pues dificulta el trabajo con expresiones regulares ya construidas en diferentes herramientas, promoviéndose en cambio la representación “as-plain” donde se toma simplemente el valor decimal de ASN (dentro del rango decimal 0 – 4294967295).
Como forma de contribuir al debate que está ocurriendo en estos momentos, en LACNIC creemos importante recibir comentarios de parte de la comunidad de nuestra región respecto de este tema.

>>Ahora bien.

Para conocer el ASN de un ISP utilizar la siguiente línea de comando en un terminal linux:

Para el ejemplo solicitamos el ASN del ISP al cual pertenece la dirección IP 201.151.157.1

:~$ whois -h whois.cymru.com 201.151.157.1
AS      | IP               | AS Name
11172   | 201.151.157.1    | Alestra, S. de R.L. de C.V.


El comando whois es un buscador que consulta un elemento en la base del RFC 3912.
La opción -h indica que la consulta se realizara conectando con algun servidor, en este caso whois.cymru.com el cuál es un servidor especializado en hacer la conversión IP a ASN.
Finalmente se ingresa la dirección IP a la cual se requiere hacer lookup.

Comentarios

Entradas populares de este blog

Problema para conectar mi VPN a través de TELMEX

Tengo un servicio Infinitum de TELMEX el cuál no me permitia conectar a mi empresa usando el cliente VPN de Cisco (Cisco VPN client), mi modem es un Technicolor TG582n http://wiki.aa.org.uk/Category:Router_TG582N. El error es "Secure VPN Connection terminated locally by the Client. Reason 412: The remote peer is no longer responding:

OSPF + EIGRP redistribuir rutas

Vamos a ver un caso muy particular para redistribución de rutas, en este ejemplo partimos del supuesto que tenemos un Router R4 en un sitio remoto que tiene configurado OSPF, tenemos en otro extremo Routers R1, R2 y R3 con enrutamiento EIGRP configurado entre ellos, se habilitan 2 interfaces en R4 para interconectar con el AS EIGRP entre R3 y R2 por cuestiones de contar con redundancia y requerimos lo siguiente: Habilitar enrutamiento entre los Routers sin eliminar las configuraciones previas, podemos agregar y cambiar valores por defecto. Permitir que la ruta por defecto de todos los Routers sea por medio de R4 Establecer como ruta preferida para comunicar ambos sistemas mediante R3 y R4 quedando como ruta secundaria R2 y R4. El esquema de interconexión y direccionamiento utilizado es el siguiente.

Históricos Billetes - Guatemala.

Banco de Occidente, 1 Peso, Quezaltenango, Guatemala, 1880   El Banco Internacional de Guatemala, 1 Peso, 1914