Best practice for route preference
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 -- Sustainable and modern Infrastructures by ungleich.ch
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/top... https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/... 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@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*
On Tue, Aug 06, 2024 at 12:58:53PM +0200, Nico Schottelius via Bird-users wrote:
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.
Hi I think that the solution 1 (lower bgp_local_pref in EBGP import) is generally safer and simpler way, while the solution 2 can have nicer failover if done properly. First, note that for solution 2 the ASBRs should not participate in internal routing (i.e. should be end-node in IGP topology), that allows them to be configured in strict EBGP-before-IBGP way, so they would use EBGP routes both for forwarding and announce them to IBGP, regardless of other IBGP routes. The end-node condition is that you should avoid this setup: router1----------------- ASN A: sends route X | router2----------------- ASN B: sends route X | router3 (in which router3 receives both route to through ASN A and ASN B, prefer to use ASN A through router1, but because there is router2 on the path from router3 to router1, the traffic ends in ASN B anyway.) The second issue is that communication with router2 itself and outer world would use ASN B even if link to ASN A is available, unless you do some tricks with VRFs / multiple tables. I think the configuration for solution 2 can be done easily, you can just set high local_pref on import from EBGP and then decrease it by fixed amount when exported to IBGP. E.g. if you local pref values are (0, 1000), you can use (1000, 2000) on EBGP import, then decrease by 1000 when export to IBGP, so EBGP is always higher than any IBGP. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Nico Schottelius -
Olivier Benghozi -
Ondrej Zajicek