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

Jue Sep 20 14:11:31 BRT 2012

Hola Ivan,

Sobre el mecanismo propuesto, rtambién me resulta interesante el explorar
si alguien lo esta utilizando o si lo descartó por algo en particular.
Agrego a la discusión que el tema de las "oscilaciones" en BGP (como en
cualquier protocolo de ruteo) no son nada buenas... no se que tanta
"histéresis" tiene el mecanismo y que tanta oscilación produce.

Sobre el tema que mencionas de "neutralidad de la red" creo que debemos
afinar bastante la terminología y la definición de "neutralidad"... en lo
personal creo que los peering (decalrados o no) y los cache-regionales, no
rompen el principio de neutralidad de la red... pero es un tema muy
polémico ya que en genral veo que hay más de 5 definiciones distintas de
que se entiende por neutralidad (y en lo personal no comparto más de una o
dos de esas :) ).

Saludos,
Nicolas

2012/9/20 Ivan Chapero <info en ivanchapero.com.ar>

> Christian,
> lamentablemente si es común en esta región. Uno como operador del router
> de borde del ISP a clientes debe andar "descubriendo" mejores caminos entre
> los upstreams que dispone y muchas veces hay grandes diferencias dado que
> de a poco se esta rompiendo la neutralidad de red (peerings directos no
> declarados / cache-regionales).
>
> Por ponerte un ejemplo, para llegar a un CDN de Akamai asignado a VIMEO
> por el carrier-A tengo 17ms y por el carrier-B 170ms. Si me quedo con las
> herramientas propias de BGP sólo puedo balancear en cuanto a carga tráfico
> y en base a cantidad de prefijos, el protocolo nunca se entera de la
> diferencia de latencia al optar por una ruta u otra.
>
> Con PfR podría tener un monitoreo de SLA que me resuelva de
> manera automática esas diferencias sobre mis upstreams.
>
> Con respecto a reclamar el SLA al proveedor, sólo te aseguran valores de
> hilado fino dentro de su ASN por lo que comparar una latencia de extremo a
> extremo sobre otro proveedor no lo ven válido.
>
> Tal vez en NANOG se pueda captar algunos enlaces de entornos empresariales
> que lo apliquen. No pertenezco a dicha lista.
>
> Saludos.
>
> El 20 de septiembre de 2012 12:00, Christian O'Flaherty <
> christian.oflaherty en gmail.com> escribió:
>
>  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
>>>
>>>
>>
>> _______________________________________________
>> 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/ce97f6fc/attachment.html>