Best practice for route preference

[Olivier Benghozi]

Hi,

Speaking about general routing (not specially Bird), I would say that what
you want would be perfectly managed by the «advertise best external»
feature, which makes a router advertise in iBGP its best external paths,
even if they are not the overall best path.

This way, in conjunction with solution 1, router 2 uses the routes from
router 1, BUT all the routes are known on both routers.

Features in Cisco/Juniper:

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/advertise-external-edit-protocols-bgp.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/bgp-best-external.html

Unfortunately this doesn't exist in Bird :P
But could be nice to implement...


Here, we use a solution «0» :D
- we don't use advertise-external
- we don't prefer a specific transit provider, so the routes with similarly
sized AS paths are known from every routers :)


But, for selective iBGP session, we use solution 2:
- between countries (we would not really like to see a transit in London be
used from routers in Paris by example, even if AS path is shorter)
- incoming routes from all transit/peering are tagged with two communities,
one for the transit (or peering, not the same), one for the site (showing
the country and the POP, one digit for each)
-at iBGP ingress policy, received iBGP routes tagged with communities
[Transit/Peering + any foreign country] see their locapref slightly
decreased.


About solution 3: sux, forget it (to my mind) :)


regards,
Olivier


Le mar. 6 août 2024 à 13:28, Nico Schottelius via Bird-users <
bird-users at network.cz> a écrit :

>
> Good morning,
>
> you might remember my confusion about non-exported routes some threads
> away [0] and while not completely bird specific, I think it might be a
> good topic to discuss for most bird users as well:
>
>      How to deal with route preference when one has multiple sources?
>
> Problem statement:
>
> - Your ASN receives the same route multiple times from different upstreams
> - What is the best way of handling multiple routes in regards to
>   a) best practice ("the next engineer understands the solution")
>   b) efficiency ("how fast to failover")
>   c) robustness ("simplicity" and "default behaviour")
>
> The setup will for almost anybody look something like that:
>
>  --------
> |Your ASN |
>  --------
>
> router1----------------- ASN A: sends route X
>   |
>  iBGP+IGP (babel, OSPF, etc.) - other-routers-of-the-asn
>   |
> router2
>   |--------------------- ASN B: sends route X
>
> And let's assume that by default ASN A is the preferred path for route
> X.
>
> Solution 1: lower bgp_local pref on import from ASN B
> -----------------------------------------------
> - Advantage:
>   - very easy to configure
>   - has the state local: "this upstream is not so interesting"
> - Disadvantage
>   - router2 does not export route X into the ASN
>   - Only if the ASN A route vanishes, it is being redistributed
>
> From a setup perspective, this looks very logical and coherent, besides
> the lack of knowledge of all other routers of the routes.
>
> Solution 2: lower bgp_local pref on import from router2
> -------------------------------------------------
> - Advantage:
>   - route X will be propagated into the ASN
>   - Should have almost zero failover time, only kernel needs to be
>     updated on each router
> - Disadvantage
>   - All routes from router2 will have a lower preference, if router2
>     handles other routes that should be treated normally, configuration
>     can get complex
>
> From a setup perspective this looks more messy and complicated, but
> should achieve faster failover times and seems more transparent.
>
> Solution 3: Elongate the bgp_path
> -------------------------------------------------
> router2 could prepend ASN B some times on import or export to iBGP.
>
> - Advantage:
>   - route would be propagated (actually unclear, as it is not the best
> route)
> - Disadvantage
>   - path is modified in an "incorrect" way
>
>
> Solution 4: other solutions
> -------------------------------------------------
> Maybe something else is actually much smarter?
> If you solve the problem differently, I'm looking for feedback on that
> topic.
>
> Best regards,
>
> Nico
>
>
> [0] https://bird.network.cz/pipermail/bird-users/2024-July/017743.html
>

-- 
*Ce message et toutes les pièces jointes (ci-après le "message") sont 
établis à l’intention exclusive des destinataires désignés. Il contient des 
informations confidentielles et pouvant être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de détruire le message. Toute utilisation de 
ce message non conforme à sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
de l'émetteur*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20240806/004bc386/attachment.htm>