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

Mie Sep 19 23:27:27 BRT 2012

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