Hola Ivan,<br><br>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.<br>
<br>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 :) ).<br>
<br>Saludos,<br>Nicolas<br><br><br><br><div class="gmail_quote">2012/9/20 Ivan Chapero <span dir="ltr"><<a href="mailto:info@ivanchapero.com.ar" target="_blank">info@ivanchapero.com.ar</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#000000"><font><font face="tahoma,sans-serif">Christian, </font></font></font><div><font color="#000000"><font><font face="tahoma,sans-serif">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).</font></font></font></div>
<div><br></div><div><font face="tahoma, sans-serif">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.</font></div>
<div><font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif">Con PfR podría tener un monitoreo de SLA que me resuelva de manera automática esas diferencias sobre mis upstreams.</font></div><div>
<font face="tahoma, sans-serif"><br></font></div><div>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.</div>
<div><br></div><div>Tal vez en NANOG se pueda captar algunos enlaces de entornos empresariales que lo apliquen. No pertenezco a dicha lista.</div><div><br></div><div>Saludos.</div><div><br></div><div><div class="gmail_quote">
El 20 de septiembre de 2012 12:00, Christian O'Flaherty <span dir="ltr"><<a href="mailto:christian.oflaherty@gmail.com" target="_blank">christian.oflaherty@gmail.com</a>></span> escribió:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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... <div>
<br></div><div>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? </div>
<span><font color="#888888">
<div><br></div></font></span><div><span><font color="#888888">Christian</font></span><div><div><br><div><br><div class="gmail_quote">2012/9/19 Ivan Chapero <span dir="ltr"><<a href="mailto:info@ivanchapero.com.ar" target="_blank">info@ivanchapero.com.ar</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#000000"><font><font face="tahoma,sans-serif">Tal vez no aclaré bien el entorno donde me parece interesante esta nueva feature. </font></font></font><div><font color="#000000"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div><div><font color="#000000"><font><font face="tahoma,sans-serif">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.</font></font></font><div>
<font face="tahoma, sans-serif"><br></font></div><div><font face="tahoma, sans-serif">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. </font></div>
<div><span style="font-family:tahoma,sans-serif"><br></span></div><div><span style="font-family:tahoma,sans-serif">Desde el contexto de un ISP de acceso a Internet multi-homed en zonas del interior del </span><span style="font-family:tahoma,sans-serif">país</span><span style="font-family:tahoma,sans-serif"> muchas veces no se facilitan </span><span style="font-family:tahoma,sans-serif">políticas</span><span style="font-family:tahoma,sans-serif"> de peering por parte del upstream provider que se contrata y en muchos casos sólo es posible aprender la default-gw de ellos.</span></div>
<div><span style="font-family:tahoma,sans-serif"><br></span></div><div>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). </div>
<div><br></div><div>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.</div>
<div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div> </div><div>Les dejo dos links que encontré ayer y creo que dan unos primeros pasos en la idea planteada:</div><div><a href="http://blog.initialdraft.com/archives/3330/" target="_blank">http://blog.initialdraft.com/archives/3330/</a></div>
<div><a href="http://blog.initialdraft.com/archives/3817/" target="_blank">http://blog.initialdraft.com/archives/3817/</a>
</div><div><br></div><div><br></div><div>Saludos!</div><div><div><div><br><div class="gmail_quote">El 19 de septiembre de 2012 18:04, Christian O'Flaherty <span dir="ltr"><<a href="mailto:christian.oflaherty@gmail.com" target="_blank">christian.oflaherty@gmail.com</a>></span> escribió:<div>
<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<span><font color="#888888">
<div><br></div></font></span><div><span><font color="#888888">Christian</font></span><div><div><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>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></div></div>
<br>_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">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 href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank">lacnog-unsubscribe@lacnic.net</a><br>
<br></blockquote></div></div></div><br><br clear="all"><div><div><br></div>-- <br><b>Ivan Chapero<br><span style="color:rgb(102,102,102)">Área Técnica y Soporte</span></b><span style="color:rgb(102,102,102)"> </span><br style="color:rgb(102,102,102)">
<span style="color:rgb(102,102,102)">Fijo: 03464-470280 (interno 535)</span> | <span style="color:rgb(102,102,102)">Móvil: 03464-155-20282</span> <div><span style="color:rgb(102,102,102)">MSN: </span><a href="mailto:ivanchapero@hotmail.com" target="_blank">ivanchapero@hotmail.com</a> <br>
<span style="color:rgb(102,102,102)">--</span><br style="color:rgb(102,102,102)"><div style="text-align:center"><span style="color:rgb(102,102,102)">Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 - Arequito - Santa Fe - Argentina</span></div>
<br><br><br><br><br><br><br></div><br>
</div></div></div></div></div>
<br>_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">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 href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank">lacnog-unsubscribe@lacnic.net</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">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 href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank">lacnog-unsubscribe@lacnic.net</a><br>
<br></blockquote></div></div></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br><b>Ivan Chapero<br><span style="color:rgb(102,102,102)">Área Técnica y Soporte</span></b><span style="color:rgb(102,102,102)"> </span><br style="color:rgb(102,102,102)">
<span style="color:rgb(102,102,102)">Fijo: 03464-470280 (interno 535)</span> | <span style="color:rgb(102,102,102)">Móvil: 03464-155-20282</span> <div><span style="color:rgb(102,102,102)">MSN: </span><a href="mailto:ivanchapero@hotmail.com" target="_blank">ivanchapero@hotmail.com</a> <br>
<span style="color:rgb(102,102,102)">--</span><br style="color:rgb(102,102,102)"><div style="text-align:center"><span style="color:rgb(102,102,102)">Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 - Arequito - Santa Fe - Argentina</span></div>
<br><br><br><br><br><br><br></div><br>
</div></div></div>
<br>_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net">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 href="mailto:lacnog-unsubscribe@lacnic.net">lacnog-unsubscribe@lacnic.net</a><br>
<br></blockquote></div><br>