[LAC-TF] [lacnog] Redistribución de rutas BGP con IGP
Tomas Lynch
tomas.lynch at gmail.com
Tue Oct 28 17:46:52 BRST 2014
Si es eBGP en general terminas haciendo la sesión con la dirección
física ya que tienes dos routers conectados back-to-back, iBGP con
loopback. Si, existe ebgp multihop pero también por default BGP puede
balancear entre 6 enlaces distintos.
2014-10-28 14:39 GMT-04:00 Carlos M. Martinez <carlosm3011 at gmail.com>:
> 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
>>
> _______________________________________________
> 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