(fernand0# linux)Su charla se titula:
<fernand0>Multihoming sin recursos utilizando linux
<fernand0>Horacio...
<HoraPe>Buenas tardes
<HoraPe>un momento por favor
<HoraPe>Comentare aqui un metodo de obtener una cierta redundancia de conectividad a internet
<HoraPe>a un costo mucho mas bajo que el metodo habitual.
<HoraPe>Puede verse una explicacion detallada en http://compendium.ar.uninet.edu/multihoming.pdf
<HoraPe>y un anexo de implementacion en http://compendium.ar.uninet.edu/multihoming-anx.pdf
<HoraPe>La necesidad del multihoming
<HoraPe>Cada vez mas las organizaciones dependen de su conectividad a internet para realizar sus actividades.
<HoraPe>La forma habitual de conexion a internet de una organizacion es a traves de un proveedor de internet (ISP)
<HoraPe>Cuando la conexion al ISP o la de este a internet fallan, la organizacion queda aislada de la red, y disminuye (o se anula) la capacidad de realizar sus actividades.
<HoraPe>Una forma de evitar esto (o de reducir su probabilidad) es mediante la conexion a multiples ISP, a esto se le llama multihoming.
<HoraPe>De este modo, al fallar uno de los ISPs, la conectividad se mantiene por los otros.
<HoraPe>El metodo clasico de multihoming
<HoraPe>Normalmente, para poder realizar multihoming se requiere:
<HoraPe>- Numero de sistema autonomo (asignado por un RIR)
<HoraPe>- Direcciones de internet propias (o asignadas por uno de los proveedores, lo que genera una nueva dependencia)
<HoraPe>- Uso del protocolo de ruteo BGP
<HoraPe>Esto acarrea una serie de costos, los numeros de sistema autonomo (ASN) son limitados y caros, las direcciones de internet son caras tambien, los proveedores acostumbran cobrar mas
<HoraPe>para permitir usar bgp.
<HoraPe>Ademas, el uso de este metodo genera costos no solo para el beneficiario sino para toda la infraestructura de la red.
<HoraPe>Por todo esto, el sistema clasico de multihoming no es adecuado para organizaciones pequeñas.
<HoraPe>Hemos identificado una serie de criterios que debe cumplir un metodo que sea adecuado a estas:
<HoraPe>- No debe necesitar numero autonomo ni direcciones propias.
<HoraPe>- Debe evitar la dependencia en entidades externas (deberia poder cambiarse cualquiera de los ISPs a los que estemos conectados sin grandes problemas)
<HoraPe>- Debe permitir que siempre que alguna de las conexiones funcione, nuestros servidores sean accesibles desde internet y nuestras estaciones deben poder acceder a la red.
<HoraPe>- No debe precisar cooperacion por parte de los ISPs.
<HoraPe>- Deben tener un bajo costo.
<HoraPe>El metodo
<HoraPe>Habitualmente (al menos en la Argentina) los ISPs instalan un router en nuestras oficinas, que es el router del prefijo de red que nos entregan.
<HoraPe>Esto hace que el demarc (punto de separacion de responsabilidades entre el ISP y el cliente) es la interfaz que conecta su router a nuestra red
<HoraPe>Lo primero que necesitamos es mover el demarc para que este bajo nuestro control.
<HoraPe>Para eso ponemos un router propio (corriendo bajo linux)
<HoraPe>este router nuestro queda conectado a los multiples proveedores que tengamos y a nuestra red.
<HoraPe>utilizando NAT y un sistema que le permita descubrir que ISPs estan funcionando, permite dar la ilusion de multihoming completo.
<HoraPe>Para que nuestros servers sean accesibles cuando algunas conexiones esten caidas, el DNS debe publicar una direccion por cada server e ISP que tengamos.
<HoraPe>Cada vez que un cliente quiera conectarse a uno de nuestros servers deberia probar cada una de las direcciones publicadas hasta que alguna corresponda a un ISP en funcionamiento.
<HoraPe>Por el lado de la conexion de las estaciones hacia la red, el router determina que ISP esta vivo (usando un sistema similar al de netsaint, por ejemplo) y en base a eso toma las decisiones de ruteo.
<HoraPe>Problemas del metodo
<HoraPe>- Las comunicaciones establecidas no sobreviven a caidas del ISP por el que se hayan establecido.
<HoraPe>Los detalles de implementacion pueden verse en http://compendium.ar.uninet.edu/multihoming-anx.pdf y estan algo anticuados
<HoraPe>Alguna pregunta?
<HoraPe><MJaway:#qc> queria saber si es posible tener un proveedor convencional y hacer
<HoraPe> multihoming con uno de respaldo
<HoraPe>supongo que lo que quieres decir es que tienes un ISP "normal", que te entrega un bloque de direcciones
<HoraPe>y otro "hogareño", tipo ADSL o cable, que te da solo una direccion
<HoraPe>En ese caso, funciona a medias
<HoraPe> Funciona completamente para que tus estaciones puedan seguir saliendo a la red
<HoraPe>pero en el caso de los servidores como solo tienes una direccion IP
<HoraPe>puede servir de respaldo solo a uno
<HoraPe>(en el caso tipico, de servidores de web, en el de mail puede hacer de respaldo de todos)
<HoraPe>nramos: para que puedan hacer preguntas por aca
<HoraPe>MJesus: contestada la pregunta?
<HoraPe>[01:05] <Virox:#qc> Este método solo funciona cuando uno tiene conecciòn ADSL u otro mejor???
<nramos>pero en ese caso quisiera que hablaras de balanceo trafico si todas tus conexiones a tus ISP funcionan
<HoraPe>virox, en principio esta pensado para enlaces superiores al ADSL
<HoraPe>donde tu proveedor te entrega un bloque de direcciones
<HoraPe>normalmente no pones servidores en ADSL o inferiores
<HoraPe>nramos, si funciona mas de una conexion, se hace balanceo de carga
<HoraPe>[01:05] <cygar:#qc> HoraPe: En el caso de caida de una de las direcciones, al hacer el cambio a
<HoraPe>la zona DNS a la nueva IP, te quedas un "rato" aislado para los que quieren acceder via
<HoraPe>nombre. no? Como resuelves eso?
<nramos>como?
<HoraPe> cygar, en una red respetuosa de los protocolos, si tu zona dice:
<HoraPe>SRV-A IN A srv.A.isp.A
<HoraPe>SRV-A IN A srv.A.isp.B
<HoraPe>SRV-A IN A srv.A.isp.C
<HoraPe>al tratar de conectar a SRV-A se probaran las 3 IPs
<HoraPe>pero hay muchas aplicaciones que prueban solo la primera y si no funciona no siguen
<HoraPe>para evitar ese caso, necesitas que el script que maneja las rutas altere tambien la zona de DNS para dejar solo las que funcionan
<HoraPe>haciendolo con TTLs bajos y un servidor secundario en otra red, funciona bastante bien
<HoraPe>nramos, balanceo de carga entrante: al haber mas de un registro A por server las conexiones entrantes se repartiran.
<HoraPe>balanceo de carga saliente, tienes una ruta default activa por cada ISP, lo que reparte las conexiones salientes
<HoraPe>alguna otra pregunta?
<HoraPe>[01:12] <MJaway:#qc> Horape, para que una misma maquina tenga resplado multihoming, habría que
<HoraPe>ponerle mas ip ?
<HoraPe>cada maquina debe responder a una ip por cada ISP al que estes conectada
<HoraPe>segun el caso puedes hacer que cada maquina tenga el completo juego de direcciones
<HoraPe>o que el router las reparta usando DNAT
<HoraPe>en la implementacion original (realizada hace unos 5 años) cada maquina tenia el juego completo de direcciones
<HoraPe>hoy que existe DNAT, es mucho mas facil de administrar
<HoraPe> (cada maquina tiene una sola IP y el DNAT mapea de las IPs reales a las privadas)
<HoraPe>[01:14] <cygar:#qc> Lo mejor en ese caso no es solo tener las X cantidad de direcciones de los X
<HoraPe>cantidad de ISP's solo en el router que hace de multihoming y solo DNAT'ear conexiones para
<HoraPe>adentro para no tener que tener esas X cantidad de conexiones para las maquinas de "adentro"
<HoraPe>?
<HoraPe>exacto
<HoraPe>
<HoraPe>[01:15] <MJesus:#qc> si tiene dos ip, de difernete proveedor, cuando uno caiga, servirá el otro?
<HoraPe>como automatizar eso?
<HoraPe>para entrante, se maneja solo
<HoraPe>para saliente, tienes un programa estilo netsaint que determina que ISPs estan vivos
<HoraPe>y modifica las reglas y las zonas del DNS
<MJesus>muchas gracias Horape 
<fernand0>Gracias Horacio, por esta magnífica conferencia.
<fernand0>Creo que todos hemos aprendido un poco más hoy
<fernand0>gracias a todos los presentes también por acudir.
<fernand0>en una hora, tendremos otra intessante conferencia
<MJesus>clap clap clap clap clap clap clap clap clap clap
<fernand0>plas plas plas plas plas plas plas plas plas plas plas plas