[LAC-TF] [lacnog] Redistribución de rutas BGP con IGP
Erick Lobo Marín
erick.lobo at cgr.go.cr
Tue Oct 28 15:25:25 BRST 2014
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>
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>:
> > 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>
> > 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>:
> >>>
> >>> 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>
> >>> 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
> >>> https://mail.lacnic.net/mailman/listinfo/lactf
> >>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> >>
> >>
> >>
> >> _______________________________________________
> >> LACNOG mailing list
> >> 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
> > https://mail.lacnic.net/mailman/listinfo/lactf
> > Cancelar suscripcion: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20141028/d3146cda/attachment.html>
More information about the LACTF
mailing list