Alexander, thank you for your feedback. Here is a diagram: [ ISP1 ] [ ISP2 ] [ ISP3 ] [ ISP4 ] | | | | | | | | [ Router 1 ] [ Router 2 ] | | | | [ Layer 2 Switch ] | | [ Bird Route Server ] Router 1 and 2 do not peer directly. There is OSPF running, so all nodes learn a route to other nodes connected interfaces. Both routers peer to route-server and are route reflection clients. There is a route x.y.z.0/24 coming from from each ISP. Router 1 chooses ISP2 (because of as-path), what path Router 2 is choosing doesn't matter. I need to force traffic to x.y.z.0/24 via ISP1. In order to do that, I'm matching the route x.y.z.0/24 in the import filter on the route-server (maching a route itself and also ISP1 ASN in the path) and setting the local preference to 150. Then this route is re-advertised to Router 2, which will select it as best, because of iBGP and high local-preference. The route is not announced back to Router 1, because it came from there. An alternative way, to do that is to mach a route on Router 1, increase a local-pref there and that route will be leared by router 2 through the route-server. But I'd like to do that on route-server to use a centralized place for these kinds of things. Here is a show route output from a route server: bird> show route for x.y.z.0/24 all x.y.z.0/24 via 10.1.1.65 on em2 [edge_r1 18:25:09] * (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 111 888 333 999 BGP.next_hop: 1.1.1.1 BGP.med: 0 BGP.local_pref: 150 via 10.1.1.65 on em2 [edge_r1 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 222 777 999 BGP.next_hop: 2.2.2.2 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.66 on em2 [edge_r2 2019-01-16] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 333 666 999 BGP.next_hop: 3.3.3.3 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.67 on em2 [edge_r2 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 444 555 999 BGP.next_hop: 4.4.4.4 BGP.med: 0 BGP.local_pref: 100 bird> On Fri, Jan 18, 2019 at 2:17 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve.
On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the
router it was received from.
I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!