[lacnog] ¿Alguien esta implementando PfR de CISCO en escenarios de ISP multi-homed?
Carlos M. martinez
carlosm3011 en gmail.com
Jue Sep 20 12:09:34 BRT 2012
No deja de ser interesante, y me encantaria a mi tambien escuchar
opiniones de gente que lo haya implementado, quizas experiencias de
otras regiones (podriamos repetir la pregunta en NANOG quizás)
Ahora, estas cosas 'medio automaticas' no dejan de darme un poco de
miedo, capaz que soy muy conservador, pero me gusta saber que el router
hace lo que le pido y no 'mas'.
El 'miedo' viene porque mientras todo anda bien, es genial. El tema es
cuando empiezan a haber problemas.
~Carlos
On 9/20/12 12:00 PM, Christian O'Flaherty wrote:
> Ahora está mas claro, pero me sigue preocupando que los anuncios BGP
> sean modificados en forma automática. Si algún upstream tiene puesto
> dampening sin que lo sepas, empezarás a tener problemas raros sin muchas
> herramientas para diagnóstico. En esta lista hubo algún email sobre una
> vuelta al dampening...
>
> Son muy comunes esos escenarios donde deben cambiarse los anuncios BGP
> para cumplir con SLA? No es mas simple negociar burstable con el
> upstream o pedir al proveedor un SLA al equivalente al que se compromete
> el ISP con sus cliente?
>
> Christian
>
> 2012/9/19 Ivan Chapero <info en ivanchapero.com.ar
> <mailto:info en ivanchapero.com.ar>>
>
> Tal vez no aclaré bien el entorno donde me parece interesante esta
> nueva feature.
>
> Para situarlos en el escenario correcto piensen en ISPs que son ASNs
> de acceso a Internet para usuarios , no como ASNs de tránsito
> tratando de mantener en orden la carga entre sus peers.
>
> Las políticas de peering complejas y bien documentadas en cuanto a
> efectos que pueden "mapearse/propagarse" por comunidades
> son típicas entre proveedores de tránsito o grandes carriers.
>
> Desde el contexto de un ISP de acceso a Internet multi-homed en
> zonas del interior del país muchas veces no se
> facilitan políticas de peering por parte del upstream provider que
> se contrata y en muchos casos sólo es posible aprender la default-gw
> de ellos.
>
> Por operar prefijos que son destinados a usuarios a veces no es
> suficiente planear un load-balance (ya sea por prepends / MEDs /etc)
> y controlar que los diferentes enlaces no saturen; nos suelen exigir
> verificar que el camino sea el ideal en cuanto a parámetros de SLA
> para ciertos servicios populares o clientes importantes (un
> poco utópico pero el interés en lograrlo existe).
>
> Todas las herramientas de ingeniería de tráfico propias de BGP a mi
> alcance son estáticas y requieren seteos manuales del operador,
> agradezco me corrijan si hay métodos dinámicos para modificar
> comportamientos en los anuncios.
> PfR anexa a BGP la capacidad de modificar dinamicamente las rutas en
> base a parámetros de SLA muy granulares, que en definitiva, de fondo
> se utilizan los mismos conceptos manuales pero basados en
> mediciones dinámicas del módulo SLA y aplicados en blackground por
> el equipo.
>
> Creo que este hilado fino no es típico de un ASN de tránsito y su
> load-balance mayormente será diagramado para cumplir con las tasas
> de transferencia contratadas y punto, un ajustado a mano de las
> palancas es lo más estable y coherente.
>
> Cuando debemos traficar desde/hacia usuarios residenciales, que
> lleguen con 30ms en vez de 250ms a cierto /24 de un CDN importante
> suele provocar una alegría en ellos y hace una diferencia en el
> servicio. En estos intentos de búsqueda y monitoreo de rutas óptimas
> de extremo a extremo me parece que aportaría mucho PfR.
>
> Les dejo dos links que encontré ayer y creo que dan unos primeros
> pasos en la idea planteada:
> http://blog.initialdraft.com/archives/3330/
> http://blog.initialdraft.com/archives/3817/
>
>
> Saludos!
>
> El 19 de septiembre de 2012 18:04, Christian O'Flaherty
> <christian.oflaherty en gmail.com
> <mailto:christian.oflaherty en gmail.com>> escribió:
>
> Cuando el balanceo es simple como dice Tomas, podemos confiar en
> BGP y no habrá cambios abruptos.
> Cuando el balanceo se empieza a complicar, y no sirven los med
> ni los prepend, y los proveedores modifican los local-pref, y
> debemos empezar a usar comunidades para cambiar los local-pref
> default para algunos prefijos en las redes del proveedor,
> etc.... ahí no me gustaría que esas decisiones las tome un
> algoritmo. Tal vez soy un poco antiguo... pero prefiero mover
> las llaves manualmente.
>
> Christian
>
>
> On Wednesday, September 19, 2012, Tomas Lynch wrote:
>
> La pregunta me parece que está dirigida a cuánto mejor es
> balancear
> sin poner esto vs. poniendo esto. Mi experiencia es que BGP
> de por sí
> es bastante robusto y balancea muy bien si ambos peers están
> bien
> configurados sin necesidad de técnicas extra para que
> funcione. Debe
> ser por ello que no encuentras documentación más allá de la
> teoría a
> la que nos tienen acostumbrados el CCIE.
>
> Tomás
>
> ps: es la primera vez que veo la palabra inteligencia cerca
> de EIGRP,
> pero ese es mi punto de vista solamente.
>
> 2012/9/18 Ivan Chapero <info en ivanchapero.com.ar>:
> > Christian, también sirve para el inbound traffic (lo que
> siempre altera al
> > ISP):
> >
> >
> http://www.cisco.com/en/US/docs/ios-xml/ios/pfr/configuration/15-2mt/pfr-bgp-inbound.html
> >
> > PfR Entrance Link Selection Control Techniques
> >
> > The PfR BGP inbound optimization feature introduced the
> ability to influence
> > inbound traffic. A network advertises reachability of its
> inside prefixes to
> > the Internet using eBGP advertisements to its ISPs. If the
> same prefix is
> > advertised to more than one ISP, then the network is
> multihoming. PfR BGP
> > inbound optimization works best with multihomed networks,
> but it can also be
> > used with a network that has multiple connections to the
> same ISP. To
> > implement BGP inbound optimization, PfR manipulates eBGP
> advertisements to
> > influence the best entrance selection for traffic bound
> for inside prefixes.
> > The benefit of implementing the best entrance selection is
> limited to a
> > network that has more than one ISP connection.
> >
> >
> >
> http://docwiki.cisco.com/wiki/PfR:Solutions:InternetInboundLoadBalancing#Internet_Presence_and_Inbound_Load_Balancing
> >
> > Dicho muy burdamente, se podría tener una inteligencia
> (asistida) similar a
> > EIGRP en cuanto a métricas de carga del enlace pero sobre
> el protocolo BGP.
> >
> > Saludos.
> >
> > El 18 de septiembre de 2012 18:53, Christian O'Flaherty
> > <christian.oflaherty en gmail.com> escribió:
> >
> >> No conocía esa funcionalidad, pero al mirar la
> documentación vi que solo
> >> sirve para el tráfico saliente:
> >>
> >> BGP Control Techniques
> >>
> >> PfR uses two BGP techniques to enforce the best exit
> path; injecting a BGP
> >> route, or modifying the BGP local preference attribute.
> >>
> >> Tal vez puede ser útil para los que manejan contenido,
> pero esos suelen
> >> tener uplinks bien grandes que no requieren balanceos
> complejos.
> >>
> >> En qué otro caso puede ser útil?
> >>
> >> Christian
> >>
> >> 2012/9/15 Ivan Chapero <info en ivanchapero.com.ar>
> >>>
> >>> Buen fin de semana gente,
> >>> hace un tiempo le estoy dedicando lectura a la
> documentación de CISCO
> >>> sobre PfR[1][2]. Dado que BGP (a mi entender) un
> protocolo bastante
> >>> indiferente a el estado real de los enlaces y
> rendimiento de la WAN, me
> >>> pareció extremadamente interesante la "inteligencia" y
> dinámica que aporta
> >>> al balanceo de carga y la performance del routing en
> general.
> >>>
> >>> Lo que me lleva a consultar en esta lista es que
> lamentablemente vi sólo
> >>> un par de blogs que exponen ejemplos y en su mayoría son
> mayormente para
> >>> escenarios teóricos de CCIE. Dicho de otra manera, no
> encontré antecedentes
> >>> y how-to's para escenarios reales en entornos de ISP.
> Por esto les consulto:
> >>> ¿alguien experimentó/desplegó PfR en su borde?,
> ¿consideraciones a tener en
> >>> cuenta para escenarios de ISP?, ¿best-practices?.
> >>>
> >>> Quedo a la espera de sus observaciones.
> >>>
> >>> Saludos.
> >>> --
> >>> Ivan Chapero
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> LACNOG mailing list
> >>> LACNOG en lacnic.net
> >>> https://mail.lacnic.net/mailman/listinfo/lacnog
> >>> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
> >>>
> >>
> >>
> >> _______________________________________________
> >> LACNOG mailing list
> >> LACNOG en lacnic.net
> >> htt <https://mail.lacnic.net/mailman/listinfo/lacnog>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
> <mailto:lacnog-unsubscribe en lacnic.net>
>
>
>
>
> --
> *Ivan Chapero
> Área Técnica y Soporte*
> Fijo: 03464-470280 (interno 535) | Móvil: 03464-155-20282
> MSN: ivanchapero en hotmail.com <mailto:ivanchapero en hotmail.com>
> --
> Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 -
> Arequito - Santa Fe - Argentina
>
>
>
>
>
>
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
> <mailto:lacnog-unsubscribe en lacnic.net>
>
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>
Más información sobre la lista de distribución LACNOG