Hi, You need to show a full routing table on the receiver. Probably you do not have your direct route for 1.1.1.0/24 (or what you have) in the bird's table, so it considers gateway 1.1.1.5 to be unreachable. I usually add those routes with protocol direct. Pay attention also that your gateway will be tried to be calculated recursively because it is a default for an iBGP session. So if you had 0.0.0.0 via 2.2.2.2 in your table, you would receive gw = 2.2.2.2 with bgp_next_hop = 1.1.1.5. Heh, I just talked about that at the RIPE meeting several days ago: https://ripe81.ripe.net/archives/video/479/ (direct/recursive stuff begins at 10:25). :) On Wed, Nov 4, 2020 at 2:15 PM ico <ico@petrzalka.net> wrote:

Hi,

Thank you for reply. Unfortunately that seems not to solve my problem. Config of my bird instance is in previous email. The "receiving peer" I set in test lab running bird is configured as follows:

######## router id 1.1.1.1;

protocol bgp { local 1.1.1.1 as 65000; neighbor 1.1.1.2 as 65000; strict bind; ipv4 { import filter { print "import bgp ", net, " gw ", gw, " bnh ", bgp_next_hop; #gw = 1.1.1.5; accept; }; export none; }; } ########

This should simply receive a route 2.2.2.0/24 with whatever gw attribute and with bgp_next_hop set to 1.1.1.5. This is of course received, but the gw is not set to 1.1.1.5 on receiver. The print statement produces this:

<INFO> import bgp 2.2.2.0/24 gw :: bnh 1.1.1.5

Receiver's console:

bird> show route all Table master4: 2.2.2.0/24 unreachable [bgp1 13:54:09.354 from 1.1.1.2] * (100) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 1.1.1.5 BGP.local_pref: 100

As you can see the next hop is 1.1.1.5 but still it is unreachable. I can set it on receiver side (with commented out "gw = 1.1.1.5;"), but that will require a change on receiver, which I am unable to do in my situation. Is there a workaround for this?

Thanks

ico

On 2. 11. 2020 19:26, Alexander Zubkov wrote:

...

Hi,

There is no reason to set gw attribute in the export filter, because this attribute is not exported over bgp. bgp_next_hop is what you want. You should also consider the "next hop self" option.

On Mon, Nov 2, 2020 at 5:53 PM ico <ico@petrzalka.net> wrote:

...

Hello,

I'm trying to to export some routes from our internal OSPF to BGP , both running in the same bird instance. I am able to filter those routes via BGP just fine (some tables connected via pipe). The problem is that all exported routes have private gw addresses (10.x.x.x). I am unable to configure bird to change gw of routes before then get sent to neighbors. Neighbors see original gateways from 10.0.0.0/8 range which is invalid/unreachable from outside of course.

Here is also some simplyfied example, not showing OSPF setup etc. In this example I also don't show the pipes between tables. All of those doesn't seem to be important in this case.

######## router id 1.1.1.2;

protocol kernel krnl4 { ipv4 { export all; import all; # route 2.2.2.0/24 gets into bird here }; learn; } protocol device { }

protocol bgp { local 1.1.1.2 as 65000; neighbor 1.1.1.1 as 65000; strict bind; ipv4 { import none; export filter { # here I want to export routes with changed gateways bgp_next_hop = 1.1.1.5; # sets next hop but not gw gw = 1.1.1.5; # <ERR> filters, line XY: Invalid gw address print "export bgp ", net, " gw ", gw, " bnh ", bgp_next_hop; # <INFO> export bgp 2.2.2.0/24 gw 1.1.1.5 bnh 1.1.1.5 accept; }; }; } ########

With similar setup in a lab I was able to change those gw attributes on RECEIVING side in import filter to any arbitrary value I wanted. In real life I don't manage those BGP routers so I need to make sure to send correct routes.

The example config prints changed gw but BGP peer sees the original gw. In some tests I got error "Invalid gw address" but now I don't have that config. Here it just ignores changed gw.

Is there a configuration to achieve this?

Thanks

ico