[lacnog] [LAC-TF] Redistribución de rutas BGP con IGP

Jorge Frater B. jfrater en fratec.com
Mar Oct 28 17:44:10 BRST 2014


Pero administrativamente también es recomendable por si en un futuro se
establecen más conexiones o si hay que cambiar IPs a nivel de enlace por
alguna razón. En todo caso la IP del loopback nunca se cae, por lo que es
más sano "anclar" el BGP a ella, en cambio si la interface con la IP está
down su IP posiblemente también estará down y el BGP queda huérfano.

Saludos,

Jorge Frater B.
Sistemas Fratec S.A.

-----Mensaje original-----
De: LACNOG [mailto:lacnog-bounces en lacnic.net] En nombre de Carlos M.
Martinez
Enviado el: martes 28 de octubre de 2014 12:40 p.m.
Para: lactf en lac.ipv6tf.org
CC: Latin America and Caribbean Region Network Operators Group
Asunto: Re: [lacnog] [LAC-TF] Redistribución de rutas BGP con IGP

las loopbacks tienen sentindo para situaciones donde hay caminos
alternativos para el tráfico, no en otras situaciones.



On 28/10/2014 14:25, Erick Lobo Marín wrote:
> 4- Las loopbacks son tus amigas, úsalas
> 
> Hola, consultar si la práctica recomendada en  las sessiones BGP con 
> el ISP, utilizan "loopback" o las direcciones físicas del enlace?
> 
> 
> Atentamente,
> Costa Rica
> Erick Lobo
> 
> lgD
> 
> El 28 de octubre de 2014, 7:06, Tomas Lynch <tomas.lynch en gmail.com 
> <mailto:tomas.lynch en gmail.com>> escribió:
> 
>     Mis mandamientos del ruteo en Internet son:
> 
>     1- Usarás ISIS sobre todas las cosas
>     2- No tomarás el nombre de BGP en vano
>     3- No redistribuirás BGP en ningún IGP a pesar de las
>     certificaciones que tengas
>     4- Las loopbacks son tus amigas, úsalas
>     5- No medirás pérdida de paquetes con comando traceroute
>     6- Un ping sin indicar el origen es un amigo que no vuelve más
>     7- "Desde el router" y "desde acá" no son direcciones de origen
>     8- El problema nunca es el Backbone
>     9- Los Viernes serán de read-only
>     10- Los hackers son los padres
> 
>     Por ahora me va bien, sobre todo con el noveno.
> 
>     2014-10-28 0:04 GMT-04:00 José Gutiérrez
>     <josegutierrezsalazar en gmail.com
>     <mailto:josegutierrezsalazar en gmail.com>>:
>     > Hola Erick,
>     >
>     > Ningún IGP debería se utilizado para llevar prefijos de Internet o
>     prefijos
>     > de cliente. A lo interno de la red, iBGP se debería encargar de
esto.
>     >
>     > Lo que mencionaste en el correo que nunca debería de hacerse es
>     así, ya que
>     > esas prácticas están totalmente vinculadas a un tema de
>     escalabilidad. En un
>     > inicio no tendrías mayor problema con las redistribuciones, pero
>     conforme la
>     > red vaya creciendo la complejidad aumentará y el mínimo error
>     podría dar al
>     > traste con el funcionamiento de toda la red, sin dejar de lado el
>     consumo de
>     > recursos, etc.
>     >
>     > Definir políticas en un IGP normalmente es complicado y esto es
>     así porque
>     > no es la naturaleza de su funcionamiento, para eso a lo interno
>     está iBGP
>     > donde existe muchas alternativas.
>     >
>     > Saludos
>     >
>     > José Gutiérrez
>     >
>     > El 27 de octubre de 2014, 21:26, Nicolas Antoniello
>     <nantoniello en gmail.com <mailto:nantoniello en gmail.com>>
>     > escribió:
>     >>
>     >> Hola Erick,
>     >>
>     >> En aras de la simplicidad (y esto puede ser discutible por
>     supuesto), en
>     >> lo personal la redistribución entre protocolos es algo que solo
>     haría en
>     >> caso de extrema necesidad.
>     >> Creo que lo más recomendable es que el transporte interno de rutas
>     >> aprendidas por eBGP lo hagas utilizando iBGP.
>     >>
>     >> Por otro lado, en caso que si o si requieras redistribución, por
>     supuesto
>     >> que tienes que tomar todas las medidas posibles para evitar
>     errores (sobre
>     >> todo los humanos)... eso incluye route maps, verificaciones y
>     filtros para
>     >> no publicar cosas como rutas por defecto, prefijos de otros, etc...
>     >>
>     >> Saludos,
>     >> Nicolas
>     >>
>     >>
>     >> 2014-10-28 6:22 GMT+09:00 Erick Lobo Marín <erick.lobo en cgr.go.cr
>     <mailto:erick.lobo en cgr.go.cr>>:
>     >>>
>     >>> Notas:
>     >>> -Seguido el link:
>     >>>
>
https://nsrc.org/workshops/2011/walc/routing/raw-attachment/wiki/Agenda/BGP_
BCP.pdf
>     >>> -Al referirme a dos protocolos me refiero a una implementación
>     dual stack
>     >>> IPv6-IPv4.
>     >>>
>     >>> Atentamente,
>     >>> Erick Lobo
>     >>>
>     >>> lgD
>     >>>
>     >>> El 27 de octubre de 2014, 15:19, Erick Lobo Marín
>     <erick.lobo en cgr.go.cr <mailto:erick.lobo en cgr.go.cr>>
>     >>> escribió:
>     >>>
>     >>>> Señores, avanzando en la implementación en una "enterprise" en
>     la que me
>     >>>> encuentro, dentro de algunas prácticas recomendadas de BGP, se
>     indica que
>     >>>> "nunca":
>     >>>> - Distribuya prefijos BGP dentro de un IGP
>     >>>> - Distribuya prefijos de un IGP dentro de BGP
>     >>>> - Utilice un IGP para transportar prefijos de clientes
>     >>>>
>     >>>> Por otro lado, por el contrario otros indican la redistribución
>     (entre
>     >>>> protocolos) con route-map con la mejor opción.
>     >>>>
>     >>>> En lo personal, me preocupa la complejidad (tal como:
>     configuración y
>     >>>> mantenimiento) , el rendimiento (tal como: overhead asociado a
dos
>     >>>> protocoles corriendo y el incremento descontrolado en las tablas
de
>     >>>> enrutamiento) y la seguridad asociada a cada opción.
>     >>>>
>     >>>> ¿Qué opinan?
>     >>>>
>     >>>> Atentamente,
>     >>>> Erick Lobo
>     >>>>
>     >>>> lgD
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> LACTF mailing list
>     >>> LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>     >>> https://mail.lacnic.net/mailman/listinfo/lactf
>     >>> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>     <mailto:lactf-unsubscribe en lacnic.net>
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> LACNOG mailing list
>     >> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>     >> https://mail.lacnic.net/mailman/listinfo/lacnog
>     >> Cancelar suscripcion:
https://mail.lacnic.net/mailman/options/lacnog
>     >>
>     >
>     >
>     >
>     > --
>     > JG
>     >
>     > _______________________________________________
>     > LACTF mailing list
>     > LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>     > https://mail.lacnic.net/mailman/listinfo/lactf
>     > Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>     <mailto:lactf-unsubscribe en lacnic.net>
>     _______________________________________________
>     LACTF mailing list
>     LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>     https://mail.lacnic.net/mailman/listinfo/lactf
>     Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>     <mailto:lactf-unsubscribe en lacnic.net>
> 
> 
> 
> 
> _______________________________________________
> LACTF mailing list
> LACTF en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
> 
_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog




Más información sobre la lista de distribución LACNOG