Mostrando las entradas con la etiqueta NAT. Mostrar todas las entradas
Mostrando las entradas con la etiqueta NAT. Mostrar todas las entradas

8 de diciembre de 2018

Elementos a considerar en la elección de un dispositivo

Al momento de generar un proyecto o elaborar una propuesta de comunicaciones o redes se supone que ante todo tenemos criterios técnicos. Pero en la realidad no es tan así.
Muchas veces nuestro punto de partida es presupuestario (cuánto está dispuesta a "gastar" la empresa en el proyecto) o de afinidad (qué tecnologías y productos conocemos).

Ciertamente deberíamos tener un punto de partida técnico.
Qué protocolos, herramientas o prestaciones son necesarias para poder responder a los objetivos que motivan el proyecto. Un inicio de tipo técnico no supone la elección de productos comerciales sino de recursos técnicos para luego ver qué productos comerciales son los que pueden dar respuesta ea estos requerimientos.
Inevitablemente el tema presupuestario es importante. Pero si nosotros mismos lo tomamos como punto de partida para la toma de decisiones se hará difícil desarrollar en la empresa una cultura de "inversión" en tecnología que desplace el concepto de "gasto" que sobrevuela muchas veces.

Más allá de estas consideraciones hay un criterio comercial que nosotros mismos como técnicos deberíamos respetar y tener presente para justificar nuestras elecciones y asesorar adecuadamente a quiénes deben tomar las decisiones de inversión.

  • La adopción de tecnología debe estar en primer lugar en función de los objetivos de negocios y los requerimientos de funcionamiento de la organización.
    No es la tecnología por la tecnología misma.
  • La implementación de tecnología en la empresa debe, por lo tanto, responder también a los requerimientos de seguridad, estabilidad y disponibilidad de tipo corporativo que se requieren en todos los aspectos de la empresa.
En consecuencia, al momento de seleccionar tecnologías y productos debemos tener presentes algunos criterios que no son puramente técnicos:

  • Las buenas prácticas habituales del sector al cual pertenece la organización (sector financiero, comercial, minería, logística, etc.)
  • La legislación y otras regulaciones locales, nacionales, regionales e internacionales que impactan directamente o indirectamente en la selección e implementación de tecnologías de comunicaciones. 
  • La disponibilidad de servicios de implementación, post-venta, reposición de partes, soporte, etc., con respaldo del fabricante.
  • La disponibilidad de recursos humanos capacitados y entrenamiento oficial para la adecuada gestión de la tecnología en función de los objetivos corporativos.
  • La innovación tecnológica.
    En implementaciones corporativas buscamos flexibilidad, escalabilidad e innovación. Por ejemplo, una implementación WLAN que en la actualidad requiera la instalación de nuevos dispositivos debería estar considerando access points 802.11ac u 802.11ax que son los últimos estándares disponibles en el mercado, una implementación 802.11n limita las posibilidades de implementación de tecnología por parte de la empresa para sostener su operación en los próximos años.
  • Que se trate de productos de tipo corporativo, no hogareño.
    Los productos corporativos tienen un mayor costo porque cubren una serie de aspectos que no pueden ser cubiertos con productos hogareños: garantía, soporte de hardware y software, servicios complementarios, documentación, etc.
En el caso de productos de networking para redes corporativas los fabricantes no deciden (la mayor parte de las veces) discontinuar o reemplazar un producto abruptamente de un día al siguiente. En términos generales, como parte de la dinámica comercial del fabricante, hay un roadmap que además del lanzamiento al mercado considera también las instancias de reemplazo futuro de ese producto.
Al considerar la necesidad de disponer de servicios brindados por el fabricante (garantía, soporte, actualizaciones, etc.) hay que evaluar esa información, que los fabricantes suelen proporcionar y documentar en sus sitios web. Si no está disponible hay que solicitarla.

Me refiero a las fechas previstas en las que un determinado producto ya no será soportado por el fabricante.


Cisco Systems suele ofrecer para cada producto esta información:

  • FCS (First Customer Shipment)
    Fecha del primer despacho de una orden de compra de un cliente.
  • Anuncio de EoL (End of Life)
    Fecha del documento que anuncia las fechas de retiro de un producto.
  • EoS (End-of-Sale)
    Fecha límite para ingresar órdenes de compra en los mecanismos formales de Cisco. El producto no se vende más a partir de esta fecha.
  • ENSA (End of New Service Attachment)
    Fecha límite para suscribir un contrato de servicio y soporte para el producto.
  • LDS (Last Date of Support)
    Fecha límite para ingresar solicitudes de soporte o servicios. Después de esta fecha no hay soporte disponible y el producto es considerado obsoleto.

Consecuencia.
Desde mi perspectiva y salvo cuando hay una limitación de tipo presupuestaria, si se va a adquirir nuevo equipamiento de Cisco, además de las consideraciones técnicas y financieras, se deberían tener en consideración estos puntos:

  • Priorizar dispositivos de última generación alineados con las nuevas arquitecturas: seguridad, SDN, BYOD, IoT, etc.
  • Preferir equipamiento IOS XE a dispositivos IOS tradicionales.
  • Considerar en la elección las prestaciones de seguridad, performance, gestión y calidad de servicio requeridas en la actualidad y en el futuro próximo.
  • No descuidar la integración de la red cableada con la red inalámbrica.
  • Evitar equipamiento cuya fecha de EoS esté próxima o que su fecha de ENSA esté a menos de 3 años.

Enlaces de consulta en Cisco Systems

Podés participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


2 de julio de 2017

Terminología NAT - Gráfica

Al implementar y analizar NAT es necesario considerar la terminología que es propia de esta implementación.  El punto de referencia es primariamente el mismo NAT server o NAT box.
  • Red inside.
    Red que se encuentra del lado “interno” del dispositivo NAT.
    Habitualmente coincide con la red LAN.
  • Red outside.
    Red del lado “externo” del dispositivo NAT.
    Habitualmente coincide con la red WAN o Internet.


Se deben considerar también las diferentes direcciones IPv4 en juego en este proceso:
  • Inside Local Address
    Dirección asignada a los dispositivos que se encuentran conectados a la red Inside y que utilizan para sus comunicaciones locales.
  • Inside Global Address.
    Dirección admitida en la red Outside que han de utilizar los dispositivos de la red Inside para establecer comunicaciones a través de la red Outside.
    Es la que representa a una terminal de la red Inside en la red Outside.
  • Outside Local Address.
    Dirección configurada en los dispositivos que se encuentran conectados a la misma rede local, pero en la red Outside.
  • Outside Global Address.
    Dirección que representa a un dispositivo de la red Outside en la red Global.


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


19 de junio de 2017

NAT / PAT - Gráfica

Cuando se trata de traducir direcciones IPv4 como mecanismo de ahorro de direcciones o para solucionar conflictos de direccionamiento, contamos con 3 variantes de configuración de esta traducción:
  • NAT estático.
    Traducción de direcciones locales a globales una a una realizada de modo manual a través de la configuración.
  • NAT dinámico.
    Traducción de direcciones locales a globales una a una pero realizada de modo dinámico utilizando direcciones globales tomadas de modo dinámico a partir de un pool de direcciones globales.
  • PAT o NAT overhead.
    Traducción de direcciones y puertos locales a direcciones y puertos globales realizada de modo estático o dinámico a partir de un pool de direcciones globales.
Una forma de representación gráfica de estos procesos puede ser la siguiente:

NAT - traducción de direcciones

PAT - traducción de direcciones y puertos



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


4 de enero de 2015

Traducción de direcciones IPv6 a IPv4

La comunicación entre nodos conectados a redes IPv6 con nodos conectados a redes IPv4 es posible implementando un proceso de traducción mejor conocido como AFT (Address Family Translation).
Esta es considerada una estrategia de corto plazo pero que permite la coexistencia de ambas redes para facilitar una transición hacia la red IPv6. Aplicaciones que utilizan protocolos que incluyen información IP en la porción de datos (como FTP o SIP) requieren la implementación de gateways de capa de aplicación para soportar la traducción.
Hay 2 tecnologías disponibles para realizar estas traducciones:
  • NAT-PT
    Network Address Translation – Protocol Translation
  • NAT64
    Network Address Translation IPv6 to IPv4
El uso de NAT-PT no es recomendado por la IETF merced a su débil interacción con DNS y sus limitaciones para la traducción. Estos problemas están documentados en el RFC 4966.
La sugerencia es trabajar con NAT 64.

La traducción de IPv6 a IPv4 o viceversa es mucho más compleja que el NAT de IPv4 que todos conocemos ya que requiere la conversión de 3 elementos en cada paquete:
  • El encabezado IPv6 debe ser reemplazado por un encabezado IPv4 o a la inversa.
  • La dirección IPv6 de origen debe ser traducida a una dirección IPv4 de origen o a la inversa.
  • La dirección IPv6 de destino debe ser traducida a una dirección IPv4 de destino o a la inversa.
Cuando la sesión se inicia desde un host IPv6, el destino será un nodo IPv4, para representar la dirección de destino IPv4 en formato IPv6 se genera un ID compuesto por el prefijo 64:FF9B::/96 que se completa con los 32 bits de la dirección IPv4 de destino.
Del mismo modo, cuando la sesión se inicia en un host IPv4, la dirección IPv4 de origen será traducida por una dirección IPv6 compuesta por el prefijo 64::BB9F::/96 y los 32 bits de la dirección IPv4 del host.
Para la traducción de las direcciones de host IPv6 se utiliza un rango de direcciones IPv4 destinado por el Administrador para este propósito.
Veamos algunos elementos de NAT64.

NAT  64
Es una solución apta tanto para entornos corporativos como de service provider.
  • Implementa funciones de NAT64 a la vez que DNS64, lo que es la base de su superioridad respecto de NAT-PT.
  • Soporta múltiples y muy variados escenarios de traducción.
  • Se puede implementar en 2 maneras:
    - Stateless NAT64.
    - Stateful NAT64.
Stateless NAT64
  • Definido en el RFC 6145.
  • No realiza ningún control o seguimiento de las sesiones.
  • La traducción puede iniciarse tanto del lado IPv6 como del IPv4.
  • Realiza traducciones 1 a 1.
  • No permite ahorrar direcciones IPv4.
  • Posibilita y facilita el seguimiento end-to-end de las sesiones.
  • Requiere que los hosts IPv6 obtengan su dirección por configuración manual o por asignación utilizando DHCPv6.
Stateful NAT64
  • Definido en el RFC 6146.
  • Realiza un seguimiento stateful de las sesiones.
  • La traducción puede iniciarse tanto del lado IPv6 como del IPv4.
  • Soporta mapeo manual de la traducción.
  • Realiza traducciones 1:N ya que implementa overloading de direcciones.
  • Permite reducir el número de direcciones IPv4 necesarias.
  • No es posible hacer un seguimiento transparente de las sesiones end-to-end.
  • Opera independientemente del modo de asignación de las direcciones IPv6, con lo que soporta asignación estática, stateless o por DHCPv6.

Bibliografía recomendada: