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

Jue Sep 20 14:03:27 BRT 2012

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20120920/9ccab94a/attachment.html>