OSPF, missing external network prefix

[Eugene M. Zheganin]

Hi.

I have a bunch of bird routers. Recently I discovered that at least one
prefix from LSADB isn't installed in FIB:

(first here's what bird thinks about it)
# birdc
BIRD 1.4.4 ready.
bird> show ospf lsadb lsid 192.168.114.192

Global

 Type   LS ID   Router   Age  Sequence  Checksum
 0005  192.168.114.192 192.168.0.15  498  8385d906
bird> show route for 192.168.114.193
0.0.0.0/0  via 178.161.152.73 on vlan600 [bgpv4sat 2015-12-04] *
(100) [AS16285i]
bird> show route for 192.168.114.192/26
0.0.0.0/0  via 178.161.152.73 on vlan600 [bgpv4sat 2015-12-04] *
(100) [AS16285i]

(and the actual FIB)
# route -n get 192.168.114.193
   route to: 192.168.114.193
destination: 0.0.0.0
   mask: 0.0.0.0
gateway: 178.161.152.73
fib: 0
  interface: vlan600
  flags: 
 recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
   0 0 0 0  1500 1 0
[root@crystal-alpha:local/etc]# route -n get 192.168.114.192/26
route: writing to routing socket: No such process

I really want to inverstigate why. So far I have import ACL in bird, but
this prefix doesn't seem to match:

protocol ospf ospfv4 {
rfc1583compat yes;

export filter exportospfv4;
import filter importospfv4;

area 0.0.0.44 {
interface "vlan1";
interface "gre0";
interface "gre1" {
cost 15111;
};
};
}

filter importospfv4 {
if net ~ [ 172.16.0.0/31, 172.16.1.80/31, 172.16.1.81/32,
172.16.1.80/32, 172.16.0.0/32, 172.16.0.1/32 ] then {
print "ospfv4 import: net rejected: ", net;
reject;
}
if net = 0.0.0.0/0 then {
print "ospfv4 import: net rejected: ", net;
reject;
} else {
print "ospfv4 import: net accepted: ", net;
accept;
}
}

Anyway, there's no signs of this missing prefix in logs.
I've also noticed one more thing, may be important: this prefix is
originating from a branch office. It's present and installed on all othe
area 0 routers, no matter what vendor they're from, but is missing on
the routers which aren't from area 0, but only if they're bird. It's
present on Cisco ones (may be a coincident though, since I doesn't have
any Cisco device connected with area 0 via bird).

Thanks.
Eugene.

Re: OSPF, missing external network prefix

[Eugene M. Zheganin]

Hi/

On 08.12.2015 14:53, Ondrej Zajicek wrote:
> On Tue, Dec 08, 2015 at 11:28:00AM +0500, Eugene M. Zheganin wrote:
>> Hi.
>>
>> I have a bunch of bird routers. Recently I discovered that at least one
>> prefix from LSADB isn't installed in FIB:
> Hi
>
> Could you send me output of 'show ospf state'?
>
Sure. Since it's 80 kilobytes long (it's an enterprise VPN, big enough),
I thought it would be more comfortable to provide a link on a text file,
here it is:

http://tech.hq.norma.perm.ru/files/ospf-state.txt

At the time it was taken the situation didn't resolve, I checked.

You may also notice that bird there is 1.4.4. I also have 1.5.0 bird
with same situation on a different server, and I can provide 'show ospf
state' from it, you you need one.

Thanks.
Eugene.

Re: OSPF, missing external network prefix

[Eugene M. Zheganin]

Hi,

On 08.12.2015 14:53, Ondrej Zajicek wrote:
> On Tue, Dec 08, 2015 at 11:28:00AM +0500, Eugene M. Zheganin wrote:
>> Hi.
>>
>> I have a bunch of bird routers. Recently I discovered that at least one
>> prefix from LSADB isn't installed in FIB:
> Hi
>
> Could you send me output of 'show ospf state'?
>
One more thing I discovered when investigation this (and I'm really
sorry, I should have mentioned this in the first letter) - the missing
prefix is from an NSSA area.

Eugene.

Re: OSPF, missing external network prefix

[Eugene M. Zheganin]

Hi.

On 08.12.2015 18:23, Ondrej Zajicek wrote:
> On Tue, Dec 08, 2015 at 06:10:20PM +0500, Eugene M. Zheganin wrote:
>> I've also noticed that this prefix is missing from 'show ospf state'
>> output files, but present in 'show ospf state all' output files, but
>> along with a IP address of 172.16.5.159. This is an IP address of a
>> router this prefix is originating from (it's an address of it's tunnel
>> most close to the area 0), and it's not directly reachable from the
>> routers which FIB is missing it, so I suppose this may be the reason.
> Yes, that is expected behavior. Don't know why these routes are available
> on other Cisco routes.
They are (for example this output is from Cisco router and it's not in
area 0):

kosm114#sh ip route 192.168.114.192
Routing entry for 192.168.114.192/26
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward
metric 3
  Last update from 172.16.1.50 on Tunnel0, 4d00h ago
  Routing Descriptor Blocks:
  * 172.16.1.50, from 192.168.0.15, 4d00h ago, via Tunnel0
  Route metric is 20, traffic share count is 1

kosm114#sh ip ospf inter
kosm114#sh ip ospf interface
Tunnel1 is up, line protocol is up
  Internet Address 172.16.1.67/31, Area 19
  Process ID 10, Router ID 192.168.141.193, Network Type POINT_TO_POINT,
Cost: 15111
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:07
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 8, maximum is 50
  Last flood scan time is 0 msec, maximum is 112 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.0.15
  Suppress hello for 0 neighbor(s)
Tunnel0 is up, line protocol is up
  Internet Address 172.16.1.51/31, Area 19
  Process ID 10, Router ID 192.168.141.193, Network Type POINT_TO_POINT,
Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:05
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 3, maximum is 50
  Last flood scan time is 0 msec, maximum is 104 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.0.15
  Suppress hello for 0 neighbor(s)
> Not sure if 172.16.5.159 should or should not be propagated, perhaps it
> is just missing. If you have BIRD on originating router, you could
> remove explicit next hop by setting 'gw = 0.0.0.0;' in the OSPF export
> filter (on the originating router).
>
Unfortunately, these NSSA prefixes are originating from Cisco devices.
Is there some workaround to make these prefixes available in other
areas, except of reverting NSSA areas to ordinary ones ? After all the
external routes from NSSAs should be visible in other areas, since they
are converted from type 7 to type 7 by the ABR, right ?

Thanks.
Eugene.

Re: OSPF, missing external network prefix

[Eugene M. Zheganin]

Hi.

On 08.12.2015 18:23, Ondrej Zajicek wrote:
> On Tue, Dec 08, 2015 at 06:10:20PM +0500, Eugene M. Zheganin wrote:
>> I've also noticed that this prefix is missing from 'show ospf state'
>> output files, but present in 'show ospf state all' output files, but
>> along with a IP address of 172.16.5.159. This is an IP address of a
>> router this prefix is originating from (it's an address of it's tunnel
>> most close to the area 0), and it's not directly reachable from the
>> routers which FIB is missing it, so I suppose this may be the reason.
> Yes, that is expected behavior. Don't know why these routes are available
> on other Cisco routes.
>
So, to summarize, is it bird working not as intended with OSPF NSSA, or,
is it Cisco/Juniper equipment that installs wrong prefixes in their FIB ?

Thanks.
Eugene.

OSPF LSA id collision

[Eugene M. Zheganin]

Hi.

I have lots of messages in one of my bird's logfile:

Dec 10 18:20:50 wizard bird: ospfv4: LSA ID collision for 172.16.1.194/31

They are about different LSA id.
What do they mean exactly ? Does it mean some of my routers have
identical networks configured ?

Thanks.
Eugene.

OSPF: Cannot find next hop for LSA type

[Eugene M. Zheganin]

Hi,

Recenly I occasionally found that one can define the OSPF area twice, like

area 0.0.0.1 {
interface "eth0";
}
area 0.0.0.1 {
interface "eth1";
}

And this obviously erroneous configuration passes the bird configuration 
check, and starts causing unpredictable and wierd problems, including 
the one mentioned in subject. Since bird doesn't seem to have a bug 
tracker, this list seems to be an appropriate place to report this.


Thanks.
Eugene.

reorder BGP plink preference

[Eugene M. Zheganin]

Hello,

I have a bird router serving multiple BGP sessions with my AS uplinks, 
and now I need to create a more complicated thing, - I have several FIBs 
and I need to reorder the BGP link preference for a given FIB. Say, I 
have 3 uplinks, A/B/C, A is the most preferable one for default FIB, but 
I need B to be the most preferable one for FIB 1. I have some basic 
experience with multiple routing tables in bird, I'm successfully using 
two at the moment, but I just have no idea on how to do this. I mean I 
know how to make the B upstream the only channel for FIB 1 (without 
redundancy), but I have no idea on how to reorder the preference in 
order to keep the redundancy. Is there such a way ?



Thanks.

Eugene.

Re: reorder BGP plink preference

[Eugene M. Zheganin]

Hello,


Well, I sat down to write the configuration and got immediately stuck: 
here's the thing: I have a pipe exporting from kernel tp given FIB, but 
in kernel I already have a default route from most preferable uplink - 
A, and I need a default route from B, which just isn't in the kernel. 
How do I deal with that ?


Thanks.

21.12.2018 13:21, Łukasz Jarosz пишет:

Hi,
Just use import filters in pipes exporting to your FIBs. To 
distinguish uplinks, while applying priorities, use if condition on 
source protocol's value or last ASN.


Best regards,
Lukasz

pt., 21 gru 2018, 09:16: Eugene M. Zheganin <mailto:e...@norma.perm.ru>> napisał(a):


Hello,

I have a bird router serving multiple BGP sessions with my AS
uplinks,
and now I need to create a more complicated thing, - I have
several FIBs
and I need to reorder the BGP link preference for a given FIB. Say, I
have 3 uplinks, A/B/C, A is the most preferable one for default
FIB, but
I need B to be the most preferable one for FIB 1. I have some basic
experience with multiple routing tables in bird, I'm successfully
using
two at the moment, but I just have no idea on how to do this. I
mean I
know how to make the B upstream the only channel for FIB 1 (without
redundancy), but I have no idea on how to reorder the preference in
order to keep the redundancy. Is there such a way ?


Thanks.

Eugene.

show route output explained

[Eugene M. Zheganin]

Hello,

Since the documentation doesn't specify the exact output format, could 
anyone please explain it to me ?



0.0.0.0/0  via 192.168.57.60 on re0 [ospfv4 11:17:31] ! E2 
(150/10/1) [192.168.100.254]

   via 90.150.180.20 on ng0 [kernel1 11:12:08] (10)


I understand most of it, but not in detail.

1) What, for example, the exclamation mark means ? Bird mimics Juniper 
notation, but Juniper doesn't have exclamation mark in it, only +/-/*. 
(Since bird mimics the Juniper notation it would be cool if it would 
also print the mark meanings, like JunOS or Cisco IOS does)


2) What is the triplet (150/10/1) ? I understand these are probably 
metric/cost/preference, but which is what ? Juniper here uses single metric.


3) When it comes to internal OSPF area, this field output changes to 
double-field one:



192.168.57.0/24    dev re0 [direct1 11:12:08] * (240)
   dev re0 [ospfv4 11:17:31] I (150/10) [192.168.100.254]


again, which field in (150/10) is what ?


Thanks.

all protocol state debug

[Eugene M. Zheganin]

Hello,


I want to log all protocols state changes, and I have a question:

debug all { states }

is valid in birdc, but why

debug all {
    states
};


is invalid in bird.conf ?


Thanks.

Eugene.

Re: all protocol state debug

[Eugene M. Zheganin]

Hello,

11.03.2019 21:02, Ondrej Zajicek пишет:

On Mon, Mar 11, 2019 at 08:41:19PM +0500, Eugene M. Zheganin wrote:

Hello,


I want to log all protocols state changes, and I have a question:

debug all { states }

is valid in birdc, but why

debug all {
     states
};


is invalid in bird.conf ?

Hello

I cannot say *why* it is that, but you can use:

   debug protocols all { states };

in bird.conf file to do that.



Well, in theory - yeah, but practically I get this:

===Cut===

[root@gw0:local/etc]# head /usr/local/etc/bird.conf
router id 192.168.0.248;

debug protocols all { states };


log syslog {
    debug, trace, info, remote, warning, error, auth, fatal, bug
};

filter importibgpv4 {
[root@gw0:local/etc]# birdc
BIRD 1.6.3 ready.
bird> conf
Reading configuration from /usr/local/etc/bird.conf
/usr/local/etc/bird.conf, line 3: syntax error
[root@gw0:local/etc]#

===Cut===


and I don't understand why. Is my 1.6.3 too old for this ?


Thanks.

Eugene.

protocol pipe and bgp

[Eugene M. Zheganin]

Hello,

If I have pipe between two kernel routing tables, which, in turn, are 
filled with two different BGP protocols, when these routes are exported 
from kernel FIB via pipe, do they retain their BGP attributes like BGP 
preference ? Or, if this question is more clear, does the following 
statement for an pipe filter look sane ?



filter exportfib0tofib2 {
    if source = RTS_BGP then {
            print "fib0 to fib2 export: net accepted: ", net;
            bgp_local_pref = 25;
            accept;
    } else {
            print "fib0 to fib2 export: net rejected: ", net;
            reject;
    }
}

or should I operate generifc protocol preference instead ?

I'm asking because I created BGP/PIPE configuration when the last 
established BGP session seems to get the maximum preference when 
exported via pipe, if you know what I mean.



Thanks.

Eugene.

stupid question about OSPF cost and route preference

[Eugene M. Zheganin]

Hello.

I have a bunch of birder routers, and the troublesome router is 
connected to some of them via LAN and to some of them via WAN tunnels.


For some reason it always chooses a WAN route, regardless of it's metric:


===Cut===

bird> show route for 10.50.3.0/24
10.50.3.0/24   via 172.16.0.45 on gif1 [ospfv4 18:25:39] * E2 
(150/10222/1) [192.168.57.254]

[root@gw /usr/local/etc]# ifconfig gif1 down
[root@gw /usr/local/etc]# birdc
BIRD 1.6.6 ready.
bird> show route for 10.50.3.0/24
10.50.3.0/24   via 192.168.57.254 on vlan57 [ospfv4 18:33:37] * E2 
(150/11/1) [192.168.57.254]

[root@gw /usr/local/etc]# ifconfig gif1 up
[root@gw /usr/local/etc]# birdc
BIRD 1.6.6 ready.
bird> show route for 10.50.3.0/24
10.50.3.0/24   via 172.16.0.45 on gif1 [ospfv4 18:34:01] * E2 
(150/10222/1) [192.168.57.254]

bird>

===Cut===


And I totally don't understand why (OSPF cost is several times higher !).

Config is  as follows:


=== Cut===

filter importospfv4 {
    if net ~ [ 10.8.1.0/24 ] then {
   reject;
    } else {
   accept;
    }
}

filter exportospfv4 {
    if net ~ [ 192.168.55.254/32, 192.168.57.2/32 ] then {
  reject;
    } else {
  accept;
    }
}

protocol ospf ospfv4 {
    export filter exportospfv4;
    import filter importospfv4;
    area 0.0.0.0 {
    interface "vlan55" {
             cost 11;
    };
    interface "vlan57" {
             cost 11;
    };
    };
    area 0.0.0.1 {
    interface "gif0"{
              cost 5111;
    };
    interface "gif1" {
              cost 5111;
    };
    };
}

===Cut===


Thanks.

Eugene.

Re: stupid question about OSPF cost and route preference

[Eugene M. Zheganin]

On 07.04.2020 19:06, Ondrej Zajicek wrote:

On Tue, Apr 07, 2020 at 06:41:37PM +0500, Eugene M. Zheganin wrote:

Hello.

I have a bunch of birder routers, and the troublesome router is connected to
some of them via LAN and to some of them via WAN tunnels.

For some reason it always chooses a WAN route, regardless of it's metric:

Hello

gif1 and vlan57 are in different areas, that is something that is likely
relevant. What you get from 'show ospf state'?


Here it is:

===Cut===

bird> show ospf state

area 0.0.0.0

    router 192.168.55.254
    distance 0
    network 192.168.57.0/24 metric 11
    stubnet 192.168.55.0/24 metric 11
    xnetwork 172.16.0.36/30 metric 5111
    xnetwork 172.16.0.44/30 metric 5111
    external 0.0.0.0/0 metric2 1
    external 10.8.1.0/24 metric2 1
    external 10.8.1.1/32 metric2 1
    external 10.8.1.2/32 metric2 1
    external 10.9.0.0/24 metric2 1 via 172.16.0.37
    external 10.95.255.126/32 metric2 1
    external 172.16.0.36/30 metric2 1
    external 172.16.0.38/32 metric2 1
    external 172.16.0.44/30 metric2 1
    external 172.16.0.46/32 metric2 1
    external 192.168.55.0/24 metric2 1
    external 192.168.57.0/24 metric2 1

    router 192.168.57.23
    distance 11
    network 192.168.57.0/24 metric 10

    router 192.168.57.24
    distance 11
    network 192.168.57.0/24 metric 10
    external 0.0.0.0/0 metric2 1
    external 192.168.57.0/24 metric2 1
    external 192.168.60.1/32 metric2 1
    external 192.168.60.2/32 metric2 1
    external 192.168.60.3/32 metric2 1

    router 192.168.57.254
    distance 11
    network 192.168.57.0/24 metric 10
    xnetwork 172.16.0.44/30 metric 5121
    xnetwork 172.16.0.56/30 metric 5121
    xnetwork 172.16.0.64/30 metric 5121
    xrouter 192.168.53.1 metric 10
    external 0.0.0.0/0 metric2 1
    external 10.3.51.0/24 metric2 1
    external 10.3.60.0/24 metric2 1
    external 10.4.0.41/32 metric2 1
    external 10.4.0.42/32 metric2 1
    external 10.4.1.41/32 metric2 1
    external 10.4.1.42/32 metric2 1
    external 10.8.0.1/32 metric2 1
    external 10.8.0.2/32 metric2 1
    external 10.8.0.0/24 metric2 1
    external 10.46.0.0/24 metric2 1
    external 10.50.0.0/24 metric2 1
    external 10.50.3.0/24 metric2 1
    external 10.58.0.0/24 metric2 1
    external 10.60.0.0/24 metric2 1
    external 10.61.0.0/24 metric2 1
    external 10.62.0.0/24 metric2 1
    external 10.200.116.0/24 metric2 1
    external 10.201.255.1/32 metric2 1
    external 10.201.255.237/32 metric2 1
    external 10.201.255.238/32 metric2 1
    external 90.150.180.21/32 metric2 1
    external 172.16.0.5/32 metric2 1
    external 172.16.0.6/32 metric2 1
    external 172.16.0.57/32 metric2 1
    external 172.16.0.58/32 metric2 1
    external 172.16.0.67/32 metric2 1
    external 172.16.0.68/32 metric2 1
    external 172.16.1.1/32 metric2 1
    external 185.71.78.61/32 metric2 1
    external 185.71.78.62/32 metric2 1
    external 192.168.57.0/24 metric2 1
    external 192.168.58.1/32 metric2 1
    external 192.168.58.3/32 metric2 1
    external 192.168.59.0/24 metric2 1 via 192.168.57.60
    external 192.168.100.0/24 metric2 1 via 192.168.57.60

    router 192.168.100.23
    distance 21
    network 192.168.100.0/24 metric 10
    external 192.168.100.0/24 metric2 1
    external 192.168.122.0/24 metric2 1

    router 192.168.100.254
    distance 11
    network 192.168.57.0/24 metric 10
    network 192.168.100.0/24 metric 10
    external 0.0.0.0/0 metric2 1
    external 10.101.0.0/16 metric2 1
    external 10.101.6.61/32 metric2 1
    external 10.101.6.62/32 metric2 1
    external 10.101.6.63/32 metric2 1
    external 10.101.21.0/24 metric2 1
    external 10.115.0.0/16 metric2 1
    external 10.121.10.0/24 metric2 10

redistributing static routes into OSPF, need to change next-hop

[Eugene M. Zheganin]

Hello,

How do I redistribute static routes into OSPF ? Suppose I have this:


protocol static {

    route 10.101.6.61/32 via 172.16.0.70;

}


If the export filter will allow this route into OSPF, the neighbor will 
receive it with this very next-hop, and in the absense of direct 
connectivity to 172.16.0.70 (which is the case) it will complain 
"Received route 10.101.6.61/32 with strange next-hop 172.16.0.70" and 
refuse to install it into FIB. How do I change next-hop to the address 
of the originating router ? The BGP proto has the option "next hop 
self", which OSPF does not.



Thanks.

Eugene.

ospf3 and bird interface in non-default FIB

[Eugene M. Zheganin]

Hello,

I'm running Bird 2.0.11 on FreeBSD 13.2, I also have a number of bird 
2.0.x in local network. For a number of reasons I need the interface the 
OSPF is bound to to be in non-default FIB.


As soon as I put it there, I'm starting to get the periodic errors like


===Cut===

ospfv4: Socket error on igb0: Network is unreachable


===Cut===

(v4 here stands for IPv4) and the bird is also unable to establish the 
neighborship with 2 of 7 it's neighbors:



===Cut===
# birdc
BIRD 2.0.11 ready.
bird> show ospf neighbors
ospfv4:
Router ID   Pri  State  DTime   Interface  Router IP
192.168.57.35 1 Full/BDR    36.075  igb0   192.168.57.35
192.168.57.37 1 Full/DR 31.771  igb0   192.168.57.147
192.168.57.23 1 2-Way/Other 31.771  igb0   192.168.57.23
192.168.57.13 1 2-Way/Other 31.894  igb0   192.168.57.13
192.168.100.254   1 Full/PtP    37.138  gre1   172.16.0.7
178.161.174.72  128 Full/PtP    39.563  gre4   172.16.0.24
192.9.200.5   1 Full/PtP    33.227  ipsec0 172.16.0.13
192.168.55.254    1 Full/PtP    36.256  ipsec1 172.16.0.80
178.161.174.72  128 Full/PtP    34.665  ipsec2 172.16.0.22
89.108.123.58 1 Full/PtP    33.138  ipsec3 172.16.0.28
192.168.52.1  1 Full/PtP    32.505  ipsec4 172.16.0.30
===Cut===

For instance, 192.168.57.35 and 192.168.57.37 are stuck in ExtStart. Why ?


My config looks like this:


===Cut===


protocol ospf ospfv4 {
   ipv4 {
   table master4;
   export filter exportospfv4;
   import filter importospfv4;
   };
   #debug all;
   area 0.0.0.0 {
   interface "igb0" {
   cost 111;
   };
   interface "tun0" {
   cost 111;
   };
   };
   area 0.0.0.1 {
   interface "gif1" {
   cost 4111;
   };
   interface "ipsec0" {
   cost 7111;
   };
   };
   area 0.0.0.2 {
   interface "gre1" {
   cost 1211;
   };
   interface "gre2" {
   cost ;
   };
   interface "gre6";
   };
   area 0.0.0.3 {
   interface "gif5";
   interface "ipsec1";
   };
   area 0.0.0.4 {
   interface "ipsec2";
   interface "gre4";
   interface "gre5";
   };
   area 0.0.0.5 {
   interface "ipsec3";
   };
   area 0.0.0.6 {
   interface "ipsec4";
   };
}

===Cut===


I've also tried to put ospfv4 protocol in the same FIB the interface is 
in (adding the "table fib1" statement), but got the same error about 
network unreachability. Restarting bird does not clear this state also. 
Running ospf with full debug gives this:



===Cut===
Aug 21 11:23:12 ronin bird[59670]: ospfv4: DBDES packet received from 
nbr 192.168.57.35 on igb0

Aug 21 11:23:12 ronin bird[59670]: ospfv4: length   32
Aug 21 11:23:12 ronin bird[59670]: ospfv4: router   192.168.57.35
Aug 21 11:23:12 ronin bird[59670]: ospfv4: mtu  1500
Aug 21 11:23:12 ronin bird[59670]: ospfv4: imms I M MS
Aug 21 11:23:12 ronin bird[59670]: ospfv4: ddseq    1977563332
Aug 21 11:23:12 ronin bird[59670]: ospfv4: HELLO packet received from 
nbr 192.168.100.254 on gre1
Aug 21 11:23:15 ronin bird[59670]: ospfv4: HELLO packet received from 
nbr 178.161.174.72 on gre4
Aug 21 11:23:16 ronin bird[59670]: ospfv4: DBDES packet sent to nbr 
192.168.57.35 on igb0

Aug 21 11:23:16 ronin bird[59670]: ospfv4: length   32
Aug 21 11:23:16 ronin bird[59670]: ospfv4: router   192.168.57.254
Aug 21 11:23:16 ronin bird[59670]: ospfv4: mtu  1500
Aug 21 11:23:16 ronin bird[59670]: ospfv4: imms I M MS
Aug 21 11:23:16 ronin bird[59670]: ospfv4: ddseq    3625460956
Aug 21 11:23:16 ronin bird[59670]: ospfv4: Socket error on igb0: Network 
is unreachable



===Cut===


Right now I have no idea how to fix this.

Thanks.


Eugene.

routes, "strange next-hop" and p2p interfaces

[Eugene M. Zheganin]

Hello,


I have a peculiar VPN client that I want to redistributes the routes 
from. Technically it creates a tun0 interface and
attaches all the routes it's connected to as it's own on-interface 
routes pointing to it's own IP (yeah, I know it's la
me, but seems like it's written by Windows 98 addicts, so it's still 
pretty normal for them). This confuses bird and it

's complaining with usual


===Cut===

Jun  7 15:10:43 vipnet bird[28752]: KRT: Received route 1.2.3.4/26 with 
strange next-hop 5.6.7.8



===Cut===


However:


===Cut===

[root@host ~]# ip addr show tun0
4: tun0:  mtu 1500 qdisc 
fq_codel state UNKNOWN group default qlen 500

link/none
    inet 5.6.7.8/32 scope global tun0
   valid_lft forever preferred_lft forever
    inet6 fe80::6d6d:315d:3deb:6ae0/64 scope link stable-privacy
   valid_lft forever preferred_lft forever

===Cut===


So far I'm reexporting these routes as static, but is there any way to 
do thsi automatically ?


Thanks.

bird and on-interface p2p routes

[Eugene M. Zheganin]

Hello,

youm this question was asked like a gazillion times, but so far I faled 
to google the answer. So, I have a network softrouter on Linux which was 
clearly written by some ignorant folks; it operates the p2p tunX 
interface that doesn't have the remote IP set, only a local one. So bird 
does complain about "strange next-hop" when walking through the kernel 
routing table and seeing the local/self address as a gateway. Still, 
this is partially valid setup, because the hosts this softrouter injects 
into the kernel RT are reachable via p2p interface directly. I can 
declare these as a static routes reachable via tunX, but this setup 
lacks the automation (I will had to refresh thhe routes manually).


So, my though is like this: is it possible to convert these from 
"strange next-hop" routes to this


===Cut===

10.24.123.0/21    unicast [direct1 2023-12-07] * (200)
    dev tun0

===Cut===

via the export filter ? I tried the following approach but it seems like 
I'm missing something:


===Cut===

filter exportkernelv4 {
    if ifname = "tun0" then {
    print "attempting to change route attributes: ifname ", 
ifname, ", gw: ", gw, ", dest: ", dest;

    onlink = true;
    #unset(gw);
    }
    accept;
};

protocol kernel {
    learn;
    persist;
    scan time 20;
    ipv4 {
    import all;
    export filter exportkernelv4;
    };
}

===Cut===


What am I missing ? Seems like for some reason I just cannot merey 
unsert the gw attribute.



Thanks.

Eugene.

Re: bird and on-interface p2p routes

[Eugene M. Zheganin]

Hello,

On 11.01.2024 03:44, Alexander Zubkov wrote:

As far as I remember, if you set the interface in a filter, than the gw is
undefined automatically.

Yep, checked the documentation, and here it is:

https://bird.network.cz/?get_doc=20=bird-5.html#ss5.5

  string ifname

 Name of the outgoing interface. Sink routes (like blackhole,
unreachable or prohibit) and multipath routes have no interface associated
with them, so ifname returns an empty string for such routes. **Setting it
would also change route to a direct one (remove gateway).**


Thanks, that did it; but unfortunately, further debugging revealed that 
bird seems to completely ignore such routes and they don't make it to 
the export filters, being discarded earlier.


Still the only option is to redeclare these as static.


Eugene.

Re: bird and on-interface p2p routes

[Eugene M. Zheganin]

Hello,

On 11.01.2024 13:29, Alexander Zubkov wrote:

You mean exporting to the kernel? You can alter the routes in input
filters. Or pipe routes to another table, altering them in the pipe export
filter, and then export to the kernel from that other table.

Nope, I need quite the opposite - I need to redistribute these into the 
OSPF; they are already present in the KRT. As far as I can see, bird 
just totally ignores these.


Eugene.