re: bird redhat repo missing rpms for 1.6.3

[Logan V.]

This is in reply to the issue mentioned in the thread from May[1]
where folks were having problems installing BIRD 1.6.3 from the repo
due to the ncurses 6 linking. I experienced the same problem recently
and ended up creating a COPR repository[2] to create BIRD 1.6.3 builds
that are installable on CentOS 6 and 7.

If you just want a working repo to install BIRD 1.6.3 on CentOS from,
you can stop reading here and go install from the linked COPR repo.
For the nuts and bolts of what is published and what was needed to
make this work, read further.

The CentOS 6 build references the BIRD 1.6.3 published src.rpm[3], and
the CentOS 7 build references the Fedora 26 src.rpm[4]. The CentOS 6
build is very straight forward, because BIRD publishes a src.rpm with
an upstart init script.. COPR sources this src.rpm directly, builds it
in their CI system, and publishes it to my repo[5].

Unfortunately the src.rpm that BIRD publishes does not produce a
usable build on CentOS 7 due to the broken init script and lack of a
systemd service unit. I have no idea if any of this has changed since
1.6.3, but as of 1.6.3, there is a line[6] which does not work using
systemd's init backwards compatibility on CentOS 7, since
"${NETWORKING}" and "${NETWORKING_IPV6}" are not set. I later found
that Fedora publishes a BIRD src.rpm along with a systemd service unit
that they use to create their builds on Fedora repos[7]. So instead of
using the BIRD src.rpm to build for CentOS 7, I used the Fedora 26
src.rpm instead which includes the necessary systemd unit file to
create a working CentOS 7 package[8].

For future BIRD releases, I will continue to maintain the COPR repo if
necessary so my ansible-bird role[9] will continue to work on EL6/7
systems. It will be a lot more convenient to maintain the COPR if I
can source EL6 and EL7 builds directly from the BIRD src.rpm, and it
looks like the only roadblock for that is BIRD will need to add a
systemd unit and integrate it to their spec file[10].

Logan

P.S. Thanks to all of the contributors for this excellent software!

[1] http://bird.network.cz/pipermail/bird-users/2017-May/011235.html
[2] https://copr.fedorainfracloud.org/coprs/logan2211/bird/
[3] http://rpm.knot-dns.cz/redhat/bird-1.6.3-1.src.rpm
[4] 
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/b/bird-1.6.3-3.fc26.src.rpm
[5] https://copr.fedorainfracloud.org/coprs/logan2211/bird/build/578086/
[6] https://gitlab.labs.nic.cz/labs/bird/blob/v1.6.3/misc/bird.init#L30
[7] http://pkgs.fedoraproject.org/cgit/rpms/bird.git/tree/bird.service
[8] https://copr.fedorainfracloud.org/coprs/logan2211/bird/build/578083/
[9] https://github.com/logan2211/ansible-bird
[10] https://gitlab.labs.nic.cz/labs/bird/blob/v1.6.3/misc/bird.spec

Re: FreeBSD, OSPF & bird 1.6.0

[Job Snijders]

Hi,

Sorry to say, but best practice is to upgrade to latest stable release and
test if the problem still exists.

Between 1.6.0 and 1.6.3 there have been a number of bug fixes and new cool
features. It makes little sense to debug an obsolete release :-)

Kind regards,

Job

Re: FreeBSD, OSPF & bird 1.6.0

[Борис Коваленко]

Hi!

Becase this is old BSDRP image and I can't upgrade it for now.

So, I also found that this routes comes from main_kernel protocol where
"import all" is used. Where FreeBSD has this route installed:
31.44.12.204   link#11UHS lo0

IMHO very strange, but BSD specific?

So the question is not to bird itself, but bird <-> freebsd
interoperability. What is the best practice? Should I use "import all" in
kernel protocol or there is no reason for this?

Regards,
Boris


ср, 12 июл. 2017 г. в 23:00, Job Snijders :

> Hi,
>
> Why are you using bird 1.6.0?
>
> The recommended version is 1.6.3.
>
> Kind regards,
>
> Job
>
-- 

С уважением,
Борис Коваленко

Re: FreeBSD, OSPF & bird 1.6.0

[Job Snijders]

Hi,

Why are you using bird 1.6.0?

The recommended version is 1.6.3.

Kind regards,

Job

FreeBSD, OSPF & bird 1.6.0

[Борис Коваленко]

Hello!

Have 2 FreeBSD hosts directly connected via VLAN.
Host 1 ip: x.x.12.203
Host 2 ip: x.x.12.204

Host 1 is FreeBSD 10.3-p12, running bird 1.6.0
Host 2 is FreeBSD 11-Stable, running bird 1.6.3

The problem is that Host1 can't resolve ARP of Host2 because of this kernel
route:
X.X.12.204   31.44.12.204   UGH1   lagg0.150

This route is installed by bird. When I filter this route in updates - I
see no problems in ARP. But where it is coming from? Imho from (show ospf
state)
  router 0.0.1.2
distance 10
network X.X.12.200/29 metric 10
stubnet 172.31.1.2/32 metric 0
>external X.X.12.200/29 metric2 20
>external X.X.12.204/32 metric2 20
external 172.31.1.2/32 metric2 20

Configs are pretty simple and shown below. So my question is - Is this
normal or something wrong with my config?

common part of configs:
protocol device main_device {
scan time 60;
}

protocol direct main_direct {
interface "*";
check link yes;
}

#
#
#

filter f_main_kernel_import
{
accept;
}

filter f_main_kernel_export
{
if(source = RTS_STATIC || source = RTS_STATIC_DEVICE) then
accept;
else if(source = RTS_INHERIT) then
accept;
else if(source = RTS_OSPF || source = RTS_OSPF_IA || source =
RTS_OSPF_EXT1 || source = RTS_OSPF_EXT2) then
accept;
else if(source = RTS_BGP) then {
if(bgp_path.len < 2) then
accept;
else {
if(defined(bgp_community) && (bgp_community ~ [(BGP_MC_LOCAL)]
|| bgp_community ~ [(BGP_MC_LOCAL_INTERNET)] || bgp_community ~
[(BGP_MC_CUSTOMER)])) then accept;
else if(defined(bgp_ext_community) && (bgp_ext_community ~
[(BGP_EMC_LOCAL)] || bgp_ext_community ~ [(BGP_EMC_LOCAL_INTERNET)] ||
bgp_ext_community ~ [(BGP_EMC_CUSTOMER)])) then accept;
else if(defined(bgp_community) && bgp_community ~
[(BGP_MC_UPSTREAM)] && fn_ipv4_default()) then accept;
else reject;
}
} else
reject "[f_main_kernel_export] reject: ", net, "/", from, "/",
source;
}

#
filter f_main_ospf_import
{
if(fn_ipv4_announced()) then {
bgp_community.add(BGP_MC_LOCAL_INTERNET);
bgp_ext_community.add(BGP_EMC_LOCAL_INTERNET);
}
else {
bgp_community.add(BGP_MC_LOCAL);
bgp_ext_community.add(BGP_EMC_LOCAL);
}

bgp_local_pref = BGP_LP_LOCAL;

if(net = 31.44.12.204/32) then
reject;

accept;
}

filter f_main_ospf_export
{
case source {
RTS_INHERIT:
ospf_metric2 = 20;
accept;
RTS_DEVICE:
ospf_metric2 = 20;
accept;
RTS_STATIC_DEVICE:
if(fn_ipv4_default()) then ospf_metric2 = 100;
else ospf_metric2 = 20;
accept;
RTS_STATIC:
ospf_metric2 = 20;
accept;
RTS_BGP:
if(fn_ipv4_default()) then {
ospf_metric2 = 100;
accept;
}
else
reject;
RTS_OSPF:
accept;
RTS_OSPF_IA:
accept;
RTS_OSPF_EXT1:
accept;
RTS_OSPF_EXT2:
accept;
else:
reject "[f_main_ospf_export] reject: ", net, "/", from, "/",
source;
}
}

Host1 OSPF:
root@br0:/usr/local/etc/bird# more ipv4_ospf.conf
#
protocol ospf main_ospf {
rfc1583compat   yes;
tick2;
router id   0.0.1.1;

export filter   f_main_ospf_export;
import filter   f_main_ospf_import;

area0.0.0.0 {

networks {
172.31.1.1/32;
X.X.12.200/29;
};

interface "lo*" {
cost10;
hello   15;
dead60;
typeptp;
};

interface "lagg0.150" {
cost10;
hello   2;
dead10;
};

};
}

Host2 OSPF:
root@br0:/usr/local/etc/bird# more ipv4_ospf.conf
#
protocol ospf main_ospf {
rfc1583compat   yes;
tick2;
router id   0.0.1.2;

export filter   f_main_ospf_export;
import filter   f_main_ospf_import;

area0.0.0.0 {

networks {
172.31.1.2/32;
X.X.12.200/29;
};

interface "lo*" {
cost10;
hello   15;
dead60;
typeptp;
};

interface "lagg0.150" {
cost10;
hello   2;