[lacnog] ¿Alguien esta implementando PfR de CISCO en escenarios de ISP multi-homed?

Jue Sep 20 12:00:13 BRT 2012

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>

> 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> 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
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: 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
> --
> Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 - Arequito -
> Santa Fe - Argentina
>
>
>
>
>
>
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20120920/6585ee26/attachment.html>