[LACNIC/Napla] Favor informacion sobre configuracion enlaces BackupNAP.

[Roque Gagliano]

Hola
> 
> (1) MISMO SITIO/NUEVO SWITH ALTERNO/MISMO ROUTER
>  
> Conexion de un solo router a los dos switches, peering a los mismo
> vecinos. Un enlace sera primario y otro secundario.
>  
> Se puede configurar rutas paralelas de loopback a loopback entre cada
> peer con "multihop", pero lo sugiero si el enlace primario esta
> saturado. Sino, no veo la necesidad, ni la complejidad adicional.

(Roque) No nos olvidemos que muchas veces los NAP piden que la IP de
origen de las sesiones BGP sean siempre la LAN del NAP. Si ese es el
caso, yo configuraría dos sesiones a las dos LANES y luego dejar a BGP
balancear según Route-id o usando Loc Pref si queremos que un switch en
particular  sea secundario de todo el mundo.

>  
> (2) MISMO SITIO/NUEVO SWITCH/NUEVO ROUTER
>  
> Esto ofrece la alternativa de que falla el router o switch y sigue
> funcionando. Se balancea en forma silimar al caso (1)

(Roque) En realidad hay alguna diferencia en este caso y tiene que ver a
cómo se ven las rutas anunciadas por los dos nuevo routers que están
dentro del NAP dentro de la red de cada ISP. Supongamos que los dos
router tienen igual costo IGP al resto de la red del ISP, entonces (si
no hay loc pref) el router de salida se va a escoger por router-id del
equipo de borde, no por el rotuer-id de la otra punta como era en el
caso anterior. También hay que analizar si hay route-reflectors dentro
del ISP. 

Conclusión, si no tocas la loc-pref se debe estudiar el IGP de cada ISP
para saber realmente cómo se va a distribuir el tráfico, pero si hay BW
suficiente no vale la pena complicarse. A mí particularmente me gusta
esta topología, te da mucha redundancia y posibilidad de dar
mantenimiento a un equipo y a un switch sin problema de afectar el
tráfico.

Roque

>  
> (3) Ideal: SITIO ALTERNO/NUEVO SWITCH/NUEVO ROUTER
>  
> Idealmente tener otro sitio provee mayor redundancia en caso
> catastrofico, pero puede elevar los costos de operacion. Si se hace si
> mucho costo adicional, ofrece mayor seguridad de redundancia.
> Adicionalmente si el edificio del primer sitio no permite albergar
> hosting, la seleccion de una nueva puede permitir a que cada ISP tenga
> pisos o espacios adyacentes para uso de web hosting para clientes
> cercandos al IXP. Esto permite a que cada uno que lo desee reduce sus
> costos para llevar el trafico a otros ISPs y su propia red. En otros
> sitios a veces es factible convencer el que renta el edificio a que
> regale el sitio del IXP y va a ganar renta de espacios para el web
> hosting de cada ISP.
>  
> En el caso (3), si los enlaces tienen los mismos costos, BGP usa la
> salida mas cercana mediante el costo del IGP. Asi no es necesario usar
> local preference.
>  
> Si un IXP es mas peque~o, entonces el uso de local preference puede
> ser la opcion. 
>  
> Mike
> 
> 
> ______________________________________________________________________
> From: napla-bounces at lacnic.net [mailto:napla-bounces at lacnic.net] On
> Behalf Of Fernando Motta B.
> Sent: Wednesday, July 25, 2007 2:55 PM
> To: napla at lacnic.net
> Subject: [LACNIC/Napla] Favor informacion sobre configuracion enlaces
> BackupNAP.
> 
> 
> 
> Buenas Tardes Señores NAPLA: Actualmente estamos interesados en NAP
> Colombia en implementar esquemas de alta disponibilidad , de esta
> forma algunos miembros del NAP tienen conexion a un Switch Principal y
> a uno de backup.  Mi interrogante es que en base a la experiencia de
> Uds nos rescomendaran Políticas de Enrutamiento BGP que deben
> aplicarse en el anuncio de las rutas de Backup que tienen algunos ISPs
> Miembros del NAP COLOMBIA. El objeto es que se tengan configuradas las
> rutas de respaldo de la forma más homogénea posible, para facilitar el
> manejo de contingencias.  Por ejemplo anunciar rutas  BGP utilizando
> local preference que otros metodos me podrian recomendar?.
> 
> Gracias por su colaboracion:
> 
> 
> 
> 
> Fernando Motta B.
> Int. & A.T. NapColombia. 
>  
> 
> 
> 
> 
>  
> 
> 
> 
> 
> ______________________________________________________________________
> MSN Amor Busca tu ½ naranja 
> _______________________________________________
> Napla mailing list
> Napla at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/napla
-- 

------------------------------------------------------------- 
Roque Gagliano ANTEL - URUGUAY 
rgaglian at antel.net.uy 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/napla/attachments/20070726/17ade56f/attachment.sig>