[LAC-TF] [lacnog] Redistribución de rutas BGP con IGP
Carlos M. Martinez
carlosm3011 at gmail.com
Tue Oct 28 16:39:49 BRST 2014
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 at gmail.com
> <mailto:tomas.lynch at 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 at gmail.com
> <mailto:josegutierrezsalazar at 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 at gmail.com <mailto:nantoniello at 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 at cgr.go.cr
> <mailto:erick.lobo at 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 at cgr.go.cr <mailto:erick.lobo at 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 at lacnic.net <mailto:LACTF at lacnic.net>
> >>> https://mail.lacnic.net/mailman/listinfo/lactf
> >>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> <mailto:lactf-unsubscribe at lacnic.net>
> >>
> >>
> >>
> >> _______________________________________________
> >> LACNOG mailing list
> >> LACNOG at lacnic.net <mailto:LACNOG at lacnic.net>
> >> https://mail.lacnic.net/mailman/listinfo/lacnog
> >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> >>
> >
> >
> >
> > --
> > JG
> >
> > _______________________________________________
> > LACTF mailing list
> > LACTF at lacnic.net <mailto:LACTF at lacnic.net>
> > https://mail.lacnic.net/mailman/listinfo/lactf
> > Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> <mailto:lactf-unsubscribe at lacnic.net>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net <mailto:LACTF at lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> <mailto:lactf-unsubscribe at lacnic.net>
>
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>
More information about the LACTF
mailing list