Mostrando entradas con la etiqueta 2 ISPs diferentes. Mostrar todas las entradas
Mostrando entradas con la etiqueta 2 ISPs diferentes. Mostrar todas las entradas

lunes, 26 de enero de 2015

Tecno-cuento: La triste historia de un ISP sin IPv6

Erase una vez.....
  Erase una vez, en un tiempo no muy lejano, un ISP muy grande que
dominaba las telecomunicaciones de un país, se sentía poderoso y sin
competencia. Cuando alguien necesitaba conectarse a Internet siempre
recurrian a ellos. Tenían una penetración en el mercado envidiable
para todos.

  Sin embargo, este ISP tan grande no había querido implementar nunca
IPv6, pensaba que tenía suficientes direcciones IP para abastecerse, no
percibían indicador alguno que dijera: tengo que tener el nuevo protocolo.

  Durante esos años, otro pequeño ISP si implementó IPv6,
comenzaron a crecer lentamente, se dieron cuenta que el protocolo si
marcaba una diferencia en sus clientes, ganaban usuarios gracias a tener
soporte de dicho protocolo. Su penetración en el mercado crecía,
ganaban más dinero y más respeto. Siendo más grandes le era más
fácil conseguir mejores precios de equipos, de tráfico, de
interconexión. Todo funcionaba muy bien. El ISP pequeño sencillamente
no lo podía creer, algo tan sencillo de implementar como IPv6 le
rendía frutos inimaginables. Sus clientes le decian que tenian crear
VPNs y conferencias contra otras partes del mundo, que sus subsidiarias, clientes y
aliados de negocio en Europa y Asia si tenían IPv6, por ello IPv4 no les
era importante.

 El ISP grande, a pesar de ser tan poderoso comenzó a tener
problemas internos, no eran problemas de facturación o dinero. Eran
quejas del personal de ventas que no podían cerrar las mismas porque
los clientes empezaron a pedir IPv6 y ellos siendo tan grandes e
importantes sencillamente no tenían!!. Clientes corporativos pedían
IPv6, usuarios residenciales solicitaban lo mismo, incluso grandes
licitaciones del estado. Cuando eso empezó a ocurrir el Gerente de
Ventas tuvo quejas hacia los departamentos de Producto, Ingeniería y
Operaciones. Estos últimos se quedaron sin palabras y algunos empleados
fueron removidos por los dueños de las empresas. Al final, a Ventas no
les importaba donde estaba la culpa, sencillamente no podían obtener
nuevos clientes.

 Posteriormente algunos vendedores al percatarse que estaban
perdiendo clientes fueron contratados por el ISP pequeño que estaba
buscando personal, total ahora sí podían pagar a importantes vendedores
porque en realidad ya no eran tan chicos. Lo mismo ocurrió con el jefe
de redes del ISP grande que sabía mucho de IPv6 pero la burocracia no
le había permitido llevar a producción el novedoso protocolo. Luego el
jefe de redes lógicamente trajo a su administrador de servidores de
confianza y su persona de seguridad. El ISP grande no podía creer lo
que estaba pasando.

 Los vendedores contratados por el ISP chico (provenientes del ISP
grande) venían con su enorme cartera de clientes, todos potenciales para
ser instalados. Se avecinaba una estampida de clientes del ISP grande.
Pasaban los meses y el ISP chico ya no solo ofrecía Internet, su Data
Center era mucho más grande, importantes empresas trajeron servidores
nuevos, de cache y mucho más. Ahora ofrecían co-location, hosting,
virtual hosting, voz, video y más.

 Cuando el proveedor grande quiso implementar IPv6, tuvo que hacer las
cosas muy rápidas, les salian mal, varios errores, además
consultores y empresas se aprovecharon de sus problemas y cobraban mucho
más para hacer las tareas con la premura que solicitaban. Aumentó el
downtime de red, las llamadas al call center y la prestigiosa reputación se venía
abajo.

 Como es de esperar, al final de la historia todos en el cuento:
clientes y proveedores terminaron implementando IPv6, unos más felices que otros
pero todos con IPv6 en sus redes

  Espero lo hayan disfrutado, y Colorín Colorado este cuento se ha acabado

Abrazos a todos,

Alejandro,


Get ready for Black Friday deals in South Africa with bidorbuy. We at bidorbuy are as excited as you are! We are hard at work to find the best deals at the best price to bring you a whole week of awesome Black Friday deals!

viernes, 12 de junio de 2009

NAT en Cisco. 2 ISPs diferentes

Necesidad: 
  Tener un enlace primario y un enlace secundario en un mismo router con dos proveedores a Internet diferentes. 

Escenario(abajo la configuración detallada y explicada): 
 Router Cisco 1760 donde: 
Interfaz Fastethernet0/0 LAN (IP 172.20.0.1) 
Internaz Serial1/0.1 ISP Primario (IP 10.0.0.58) 
Internaz Serial0/0.1 ISP Secundario (IP 10.1.1.58) 


  Diagrama:
Procedimiento: 
Primero es necesario configurar unas rutinas en el router que se van a encargar de monitorear las interfaces WAN. 

ip sla monitor 1 (deseo monitorar el next-hop del enlace del ISP primario) 
type echo protocol ipIcmpEcho 10.0.0.57 source-interface Serial1/0.1 timeout 1000 threshold 400 frequency 3 ip sla monitor schedule 1 life forever start-time now (esta linea es para activar realmente el monitoreo) 

ip sla monitor 2 (deseo monitorar el next-hop del enlace del ISP secundario) type echo protocol ipIcmpEcho 10.1.1.57 source-interface Serial0/1.1 timeout 2000 threshold 1000 frequency 3 ip sla monitor schedule 2 life forever start-time now (esta linea es para activar realmente el monitoreo) ! 

Con las lineas arribas indicadas lo que se hace es monitorear si el next hop en el enlace WAN esta levantado. 

Por ejemplo en el primer caso se hace ping (ipIcmpEcho) al IP 10.0.0.57, con un timeout de 2000 ms, un umbral de 1000 ms cada 3 segundos. Posteriormente es necesario habilitar los comandos track en Cisco. Estos son muy utiles para conocer luego el estado de los SLA previamente configurados. Los comandos son: track 123 rtr 1 reachability delay down 15 up 10 ! track 345 rtr 2 reachability delay down 15 up 10 ! El truco se encuentra en el NAT (tanto asi que lo anterior se puede hacer con rutas flotantes, sin embargo de la manera implementada es la mejor practica). 
El NAT debe ser realizado en base a route-maps (no lo intentes de otra manera). Las lineas que personalmente utilice fueron: 

ip nat pool POOL-MINAT 200.30.30.30 200.30.30.30 prefix-length 29 
ip nat inside source route-map ISP-1 pool POOL-MINAT overload 
ip nat inside source route-map ISP-2 interface Serial0/1.1 overload 
access-list 150 remark PARA-NAT 
access-list 150 permit ip 172.20.0.0 0.0.0.255 any 
route-map ISP-1 permit 5 
 match ip address 150 
  match interface Serial1/0.1 
route-map ISP-2 permit 5 
  match ip address 150
  match interface Serial0/1.1 

En el ejemplo anterior vemos que el NAT es en base a los route-maps ISP-1 e ISP-2, el ACL a utilizar es el 150 extendido donde estamos nateando toda la red 172.20.0.0/24 Cuando los paquetes salgan por el ISP-1 saldran nateados con el IP 200.30.30.30 y cuando salgan con el ISP-2 saldran con el IP de la interfaz WAN. Logicamente puedes ajustar esto a tu necesidad. 
 Ahora bien, la ruta de los paquetes de salida son definidas con la siguiente configuracion: 

ip route 0.0.0.0 0.0.0.0 Serial1/0.1 track 123 
ip route 0.0.0.0 0.0.0.0 Serial0/1.1 track 345 

 La ruta por default es la interfaz s1/0.1 cuando el IP 10.0.0.57 se encuentre UP, en caso de que se caiga la interfaz y/o el ping al IP 10.0.0.57 NO sea satisfactorio se utilizara la ruta por la interfaz S0/1.1 (enlace secundario) 


Verificacion: 

1760-WAN#sh track 123 
Track 123 Response Time Reporter 1 reachability Reachability is Up 33 changes, last change 08:27:17 Delay up 10 secs, down 15 secs Latest operation return code: OK Latest RTT (millisecs) 11 

1760-WAN#sh track 345 
Track 345 Response Time Reporter 2 reachability Reachability is Up 36 changes, last change 3d01h Delay up 10 secs, down 15 secs Latest operation return code: OK Latest RTT (millisecs) 8 1760-WAN


#sh ip nat t [OUTPUT SUPRESSED] 


 Espero haya sido de tu ayuda, Suerte!,


pdf to word

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...