[lacnog] [LAC-TF] Redistribución de rutas BGP con IGP
Nicolas Antoniello
nantoniello en gmail.com
Mie Oct 29 01:12:34 BRST 2014
Hola Erick,
Este es un tema que tienes que analizar según TU realidad.
En términos generales y basado en mi experiencia, si solo tienes ese enlace
con ese ISP o si solo tendrás un único camino para la sesión BGP, mi
recomendación es que la levantes con la IP de la interfaz.
Sobre todo, porque cuando caiga el enlace con ese ISP VAS a querer que
también caiga (lo antes posible) esa sesión BGP... ya sea para quedar
aislado o para recibir rutas alternativas que estés aprendiendo (y también
publicando) por otro lado.
Adicionalmente si tienes un camino alternativo y quieres tener BGP entre
loopbacks, no olvides que tienes que setear el multihop de BGP a el valor
adecuado (muchos routers por defecto toman 1 como valor a menos que le
indiques lo contrario)... si no, nunca te va a levantar la sesión BGP entre
loopbacks o bien, si lo pones en 2 por ejemplo, puede que levante pero que
no se mantenga arriba al cambiar el camino a uno con más de 2 saltos...
nuevamente, probablemente en la mayoría de los casos sea más "sano"
levantarla entre interfaces directamente.
Saludos,
Nicolas
2014-10-29 2:25 GMT+09:00 Erick Lobo Marín <erick.lobo en cgr.go.cr>:
> 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>
> 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
>> >:
>> > 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>
>> > 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>:
>> >>>
>> >>> 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>
>> >>> 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
>> >>> 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
>> >>
>> >
>> >
>> >
>> > --
>> > JG
>> >
>> > _______________________________________________
>> > LACTF mailing list
>> > LACTF en lacnic.net
>> > https://mail.lacnic.net/mailman/listinfo/lactf
>> > Cancelar suscripcion: 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
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20141029/13b3759f/attachment.html>
Más información sobre la lista de distribución LACNOG