Cuando el balanceo es simple como dice Tomas, podemos confiar en BGP y no habrá cambios abruptos.<div>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.</div>
<div><br></div><div>Christian<br><br>On Wednesday, September 19, 2012, Tomas Lynch  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">La pregunta me parece que está dirigida a cuánto mejor es balancear<br>

sin poner esto vs. poniendo esto. Mi experiencia es que BGP de por sí<br>
es bastante robusto y balancea muy bien si ambos peers están bien<br>
configurados sin necesidad de técnicas extra para que funcione. Debe<br>
ser por ello que no encuentras documentación más allá de la teoría a<br>
la que nos tienen acostumbrados el CCIE.<br>
<br>
Tomás<br>
<br>
ps: es la primera vez que veo la palabra inteligencia cerca de EIGRP,<br>
pero ese es mi punto de vista solamente.<br>
<br>
2012/9/18 Ivan Chapero <<a href="javascript:;" onclick="_e(event, 'cvml', 'info@ivanchapero.com.ar')">info@ivanchapero.com.ar</a>>:<br>
> Christian, también sirve para el inbound traffic (lo que siempre altera al<br>
> ISP):<br>
><br>
> <a href="http://www.cisco.com/en/US/docs/ios-xml/ios/pfr/configuration/15-2mt/pfr-bgp-inbound.html" target="_blank">http://www.cisco.com/en/US/docs/ios-xml/ios/pfr/configuration/15-2mt/pfr-bgp-inbound.html</a><br>
><br>
> PfR Entrance Link Selection Control Techniques<br>
><br>
> The PfR BGP inbound optimization feature introduced the ability to influence<br>
> inbound traffic. A network advertises reachability of its inside prefixes to<br>
> the Internet using eBGP advertisements to its ISPs. If the same prefix is<br>
> advertised to more than one ISP, then the network is multihoming. PfR BGP<br>
> inbound optimization works best with multihomed networks, but it can also be<br>
> used with a network that has multiple connections to the same ISP. To<br>
> implement BGP inbound optimization, PfR manipulates eBGP advertisements to<br>
> influence the best entrance selection for traffic bound for inside prefixes.<br>
> The benefit of implementing the best entrance selection is limited to a<br>
> network that has more than one ISP connection.<br>
><br>
><br>
> <a href="http://docwiki.cisco.com/wiki/PfR:Solutions:InternetInboundLoadBalancing#Internet_Presence_and_Inbound_Load_Balancing" target="_blank">http://docwiki.cisco.com/wiki/PfR:Solutions:InternetInboundLoadBalancing#Internet_Presence_and_Inbound_Load_Balancing</a><br>

><br>
> Dicho muy burdamente, se podría tener una inteligencia (asistida) similar a<br>
> EIGRP en cuanto a métricas de carga del enlace pero sobre el protocolo BGP.<br>
><br>
> Saludos.<br>
><br>
> El 18 de septiembre de 2012 18:53, Christian O'Flaherty<br>
> <<a>christian.oflaherty@gmail.com</a>> escribió:<br>
><br>
>> No conocía esa funcionalidad, pero al mirar la documentación vi que solo<br>
>> sirve para el tráfico saliente:<br>
>><br>
>> BGP Control Techniques<br>
>><br>
>> PfR uses two BGP techniques to enforce the best exit path; injecting a BGP<br>
>> route, or modifying the BGP local preference attribute.<br>
>><br>
>> Tal vez puede ser útil para los que manejan contenido, pero esos suelen<br>
>> tener uplinks bien grandes que no requieren balanceos complejos.<br>
>><br>
>> En qué otro caso puede ser útil?<br>
>><br>
>> Christian<br>
>><br>
>> 2012/9/15 Ivan Chapero <<a>info@ivanchapero.com.ar</a>><br>
>>><br>
>>> Buen fin de semana gente,<br>
>>> hace un tiempo le estoy dedicando lectura a la documentación de CISCO<br>
>>> sobre PfR[1][2]. Dado que BGP (a mi entender) un protocolo bastante<br>
>>> indiferente a el estado real de los enlaces y rendimiento de la WAN,  me<br>
>>> pareció extremadamente interesante la "inteligencia" y dinámica que aporta<br>
>>> al balanceo de carga y la performance del routing en general.<br>
>>><br>
>>> Lo que me lleva a consultar en esta lista es que lamentablemente vi sólo<br>
>>> un par de blogs que exponen ejemplos y en su mayoría son mayormente para<br>
>>> escenarios teóricos de CCIE. Dicho de otra manera, no encontré antecedentes<br>
>>> y how-to's para escenarios reales en entornos de ISP. Por esto les consulto:<br>
>>> ¿alguien experimentó/desplegó PfR en su borde?, ¿consideraciones a tener en<br>
>>> cuenta para escenarios de ISP?, ¿best-practices?.<br>
>>><br>
>>> Quedo a la espera de sus observaciones.<br>
>>><br>
>>> Saludos.<br>
>>> --<br>
>>> Ivan Chapero<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> LACNOG mailing list<br>
>>> <a>LACNOG@lacnic.net</a><br>
>>> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
>>> Cancelar suscripcion: <a>lacnog-unsubscribe@lacnic.net</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LACNOG mailing list<br>
>> <a>LACNOG@lacnic.net</a><br>
>> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">htt</a></blockquote></div>