[lacnog] ¿Por qué BGP elige esta ruta en particular?

Mar Sep 6 12:03:03 BRT 2016

Justamente ese paso 10 es el que nos hace dudar. Ese paso solamente aplica
a rutas externas y no internas como en este caso.

Sobre el caso de commitconfirmed.net, que utilice la más nueva tampoco me
deja tranquilo. Justamente lo que afirman tanto Iván como Alejandro sería
lo más normal: utilizar la ruta más antigua.

Pero, insisto, eso sirve solamente para rutas externas. ¿O será que no está
documentado y también es el tie-breaker para rutas internas?

2016-09-02 23:06 GMT-04:00 Ivan Chapero <info en ivanchapero.com.ar>:

> Idem,
> inclusive para rutas eBGP es un step del algoritmo:
>
> 10. When both paths are external, prefer the path that was received first
> (the oldest one).
>
> This step minimizes route-flap because a newer path does not displace an
> older one, even if the newer path would be the preferred route based on the
> next decision criteria (Steps 11, 12, and 13).
> Pero el lab del blog parece convincente, la última ruta re-anunciada
> producto del VRF que modifica el RD termina siendo la "best". Habría que
> recrearlo, pero es muy sábado :D
>
> Abrazo.
>
> El 2 de septiembre de 2016, 23:06, Alejandro Acosta <
> alejandroacostaalamo en gmail.com> escribió:
>
>> Hola,
>>
>> El 9/2/2016 a las 7:25 PM, Ivan Chapero escribió:
>>
>> Lindo ejercicio mental, esto puede dar luz:
>>
>> http://www.commitconfirmed.net/2015/09/09/bgp-best-path-sele
>> ction-in-mplsip-bgp-vpns/
>>
>>
>> Conclusion
>>
>> In a scenario where neighbor address is the same and all previous steps
>> in BGP best path algorithm didn’t break the tie, best path is chosen on the
>> age of the route – the one which has been learned last is chosen as best.
>>
>>
>> ¿Seguro de esto?  Toda mi vida (bueno.., desde hace muchos) he pensado
>> que es la más ruta que tiene más tiempo aprendida..., es una manera de
>> asumir que es la ruta más estable.
>>
>>
>> This doesn’t seem to be platform dependent. I did similar test on Junos
>> based platform (MX series) and result was the same.
>>
>>
>> Sl2!
>>
>> El viernes, 2 de septiembre de 2016, Tomas Lynch <
>> <tomas.lynch en gmail.com>tomas.lynch en gmail.com> escribió:
>>
>>> Estimados,
>>>
>>> Tenemos el siguiente caso en uno de nuestros equipos. Esta es la salida
>>> en el PE donde se encuentra la VRF indicada:
>>>
>>> ROUTER1#show ip bgp vpnv4 vrf VPN_CUSTOMER 10.199.16.0/20
>>>
>>> BGP routing table entry for 65100:16021:10.199.16.0/20, version 69022324
>>>
>>> Paths: (2 available, best #2, table VPN_CUSTOMER)
>>>   Advertised to update-groups:
>>>      36
>>>
>>>   65000 65001 65002 65002 65002, imported path from 65000:22149:
>>> 10.199.16.0/20
>>>     10.10.66.173 (metric 11501) from 10.15.1.2 (10.15.1.2)
>>>       Origin IGP, metric 150, localpref 100, valid, internal
>>>       Community: 65000:1281
>>>       Extended Community: RT:65000:51109 RT:65000:81108
>>>       Originator: 10.10.66.173, Cluster list: 10.15.1.2
>>>       mpls labels in/out nolabel/37244
>>>
>>>   65000 65001 65002 65002 65002, imported path from 65000:22146:
>>> 10.199.16.0/20
>>>     10.10.66.173 (metric 11501) from 10.15.1.2 (10.15.1.2)
>>>       Origin IGP, metric 150, localpref 100, valid, internal, best
>>>       Community: 65000:1281
>>>       Extended Community: RT:65000:51109 RT:65000:81108
>>>       Originator: 10.10.66.173, Cluster list: 10.15.1.2
>>>       mpls labels in/out nolabel/67523
>>>
>>> La pregunta es ¿por qué elige la segunda entrada si todos los parámetros
>>> son iguales con excepción del RD?
>>>
>>> Primero pensamos que el NLRI es menor (22149 > 22146) pero no lo
>>> encontramos en ningún proceso de selección de rutas (
>>> <http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html>
>>> http://www.cisco.com/c/en/us/support/docs/ip/border-gateway
>>> -protocol-bgp/13753-25.html)
>>>
>>> La persona que me pasó este problema se pregunta si no hay algo
>>> escondido en la información que BGP se pasa. Algún tipo de hash para
>>> comparar.
>>>
>>> Para mi es un tema del algoritmo de selección, incluso si existiera un
>>> parámetro oculto: si comparo absolutamente todo y las rutas son iguales,
>>> entonces elijo al azar una de ellas y la envío a la RIB. Es decir que la
>>> persona que escribió el código tenía como finalidad elegir una ruta y puso
>>> un fail-safe al final de los IF de selección de rutas para que instale al
>>> menos una de las rutas. Sin esto no instalaría ninguna.
>>>
>>> ¿Alguno tiene alguna indicación de lo que sucede cuando agoto todas las
>>> opciones de la selección de rutas de BGP?
>>>
>>> Gracias,
>>>
>>> Tomás
>>>
>>>
>>>
>>
>> --
>>
>> *Ivan Chapero Área Técnica y Soporte*
>> Fijo: 03464-470280 (interno 535) | Móvil:  03464-155-20282  | Skype ID:
>> ivanchapero
>> --
>> GoDATA Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 -
>> Arequito - Santa Fe - Argentina
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LACNOG mailing listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>>
>
>
> --
>
> *Ivan ChaperoÁrea Técnica y Soporte*
> Fijo: 03464-470280 (interno 535) | Móvil:  03464-155-20282  | Skype ID:
> ivanchapero
> --
> GoDATA 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: https://mail.lacnic.net/mailman/options/lacnog
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20160906/3b9135a0/attachment.html>