- Bird-users - Mailing Lists

Re: BGP up/down event logging
by Sergiy Goloborodko 26 Nov '24

26 Nov '24

Hi, I'm on BIRD 2.15.1 and trying to get my head around on BGP up/down events logging. I have seen down events in /var/log/messages e.g. Nov 21 10:48:07 system7 bird[3983]: a5_v4: Received: Administrative shutdown Is there a way to see when peer is going up without enabling TRACE? Best Regards, Sergiy

1 0

[PATCH] Babel: Allow v6 next hop on interfaces with v4 addresses
by Chris Webb 24 Nov '24

24 Nov '24

By default, the Babel protocol will advertise an IPv6 extended next hop address on interfaces which don't have an IPv4 address. This is controlled by the 'extended next hop' option. Add support for 'extended next hop force' which advertises an extended next hop even when IPv4 addresses are present. (They may be temporary, for debugging or otherwise unsuitable for including in an advertisement.) --- doc/bird.sgml | 9 ++++++--- proto/babel/babel.c | 10 +++++++--- proto/babel/babel.h | 2 +- proto/babel/config.Y | 3 ++- 4 files changed, 16 insertions(+), 8 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 0d1e6f49..cb5fa572 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2266,7 +2266,7 @@ protocol babel [<name>] { check link <switch>; next hop ipv4 <address>; next hop ipv6 <address>; - extended next hop <switch>; + extended next hop <switch>|force; rtt cost <number>; rtt min <time>; rtt max <time>; @@ -2377,10 +2377,13 @@ protocol babel [<name>] { source for Babel packets will be used. In normal operation, it should not be necessary to set this option. - <tag><label id="babel-extended-next-hop">extended next hop <m/switch/</tag> + <tag><label id="babel-extended-next-hop">extended next hop + <m/switch/|force</tag> If enabled, BIRD will accept and emit IPv4 routes with an IPv6 next hop when IPv4 addresses are absent from the interface as described in - <rfc id="9229">. Default: yes. + <rfc id="9229">. Use <cf/extended next hop force/ to emit IPv4 routes + with an IPv6 next hop even when IPv4 addresses are present on the + interface. Default: yes. <tag><label id="babel-rtt-cost">rtt cost <m/number/</tag> The RTT-based cost that will be applied to all routes from each neighbour diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4187d258..1541edc1 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1836,8 +1836,12 @@ babel_iface_update_addr4(struct babel_iface *ifa) { struct babel_proto *p = ifa->proto; - ip_addr addr4 = ifa->iface->addr4 ? ifa->iface->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ifa->cf->next_hop_ip4) ? ifa->cf->next_hop_ip4 : addr4; + if (ipa_nonzero(ifa->cf->next_hop_ip4)) + ifa->next_hop_ip4 = ifa->cf->next_hop_ip4; + else if (ifa->cf->ext_next_hop < 2 && ifa->iface->addr4) + ifa->next_hop_ip4 = ifa->iface->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ifa->cf->ext_next_hop) log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); @@ -1912,7 +1916,7 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con add_tail(&p->interfaces, NODE ifa); - ip_addr addr4 = new->addr4 ? new->addr4->ip : IPA_NONE; + ip_addr addr4 = ic->ext_next_hop < 2 && new->addr4 ? new->addr4->ip : IPA_NONE; ifa->next_hop_ip4 = ipa_nonzero(ic->next_hop_ip4) ? ic->next_hop_ip4 : addr4; ifa->next_hop_ip6 = ipa_nonzero(ic->next_hop_ip6) ? ic->next_hop_ip6 : ifa->addr; diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..f832a699 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -163,7 +163,7 @@ struct babel_iface_config { ip_addr next_hop_ip4; ip_addr next_hop_ip6; - u8 ext_next_hop; /* Enable IPv4 via IPv6 */ + u8 ext_next_hop; /* Enable IPv4 via IPv6, set >= 2 to force */ u8 auth_type; /* Authentication type (BABEL_AUTH_*) */ u8 auth_permissive; /* Don't drop packets failing auth check */ diff --git a/proto/babel/config.Y b/proto/babel/config.Y index d412a54b..734c184b 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -24,7 +24,7 @@ CF_DECLS CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, - NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, + NEXT, HOP, FORCE, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, COST, DELAY) @@ -159,6 +159,7 @@ babel_iface_item: | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4; } + | EXTENDED NEXT HOP FORCE { BABEL_IFACE->ext_next_hop = 2; } | AUTHENTICATION NONE { BABEL_IFACE->auth_type = BABEL_AUTH_NONE; } | AUTHENTICATION MAC { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 0; } | AUTHENTICATION MAC PERMISSIVE { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 1; }

2 2

bird and ipsec (strongswan) routes
by Brian C. Hill 21 Nov '24

21 Nov '24

Hello, I want to use bird to mutually propagate routes throughout several sites connected with vpn gateways, probably with ospf. e.g. site A net(s) <-> site A vpn gateway <-> vpn 'concentrator' <-> site B vpn gateway <-> hosts site B net(s), etc.. I couldn't find many posts about the best strategy to use, and the ones did find are many years old, but it seems to boil down to these options: • use a script to migrate xfrm route table (220) to a bird-readable table • use static routes inside bird • use vti instead of xfrm My questions: 1) Is it sill the case that bird cannot read directly from the xfrm table? (I tried this with a pipe config but nothing gets imported) 2) What is the strategy that most of you are using now? (as opposed to many years ago) Thanks! Brian

6 5

How to advertise two virtual IPs using BGP?
by Hans Heng 21 Nov '24

21 Nov '24

Hi all! I have a dual-home server, whose connection topology and configuration is described as below. **** Connection Topology and Configuration **** The server has two physical NICs enp4s0f0 and enp4s0f1, which are connected to two separate ports TOR_A and TOR_B on a Top of Rack (TOR) router, each representing a separate BGP session through bgp_A and bgp_B protocol. The server also has a dummy interface named em5, which has a private ip 38.145.72.193/32. Bird kernel protocol exports an ECMP routing rule to kernel as a kernel default routing, and bgp_A/bgp_B protocol export the private ip to my internet, then 38.145.72.193/32 on em5 acts as a public ip. **** My goal **** I want to add another virtual ip on em5, say 38.145.72.198/32, and let this new virtual ip act as a public ip too. Can this requirement be met? If yes, how should I modify the configuration to make BGP advertise this ip over my internet? **** Additional Information on Server **** ## bird setup an ECMP route on 2 phy nics as default route, ## which set source ip to the public ip $ ip route default proto bird src 38.145.72.193 metric 32 nexthop via 10.105.1.10 dev enp4s0f0 weight 1 nexthop via 10.105.1.12 dev enp4s0f1 weight 1 10.105.1.10/31 dev enp4s0f0 proto kernel scope link src 10.105.1.11 10.105.1.12/31 dev enp4s0f1 proto kernel scope link src 10.105.1.13 bird> show route all Table master4: 0.0.0.0/0 unicast [bgp_A 2024-11-17] * (100) [AS4212010101i] via 10.105.1.10 on enp5s0f0 Type: BGP univ BGP.origin: IGP BGP.as_path: 4259105001 4212010101 BGP.next_hop: 10.105.1.10 BGP.local_pref: 0 unicast [bgp_B 2024-11-18] (100) [AS4212010101i] via 10.105.1.12 on enp5s0f1 Type: BGP univ BGP.origin: IGP BGP.as_path: 4259205001 4212010101 BGP.next_hop: 10.105.1.12 BGP.local_pref: 0 38.145.72.193/32 unicast [direct1 2024-11-06] * (240) dev em5 Type: device univ # bird.conf router id 172.18.xxx.yyy; ipv4 table master4; define LOCAL_NET = [ 38.145.72.193/32 ]; protocol direct { ipv4; interface em5,-*; } protocol kernel { scan time 1; merge paths yes limit 4; ipv4 { import none; export filter { if proto = direct1 then reject; krt_prefsrc = 38.145.72.193; accept; }; }; } protocol device { scan time 1; } protocol bgp bgp_A { description TOR A; local 10.105.1.11 as 4290105101 ; # enp4s0f0 neighbor 10.105.1.10 as 4259105001; # TOR_A path metric 1; ipv4 { import all; export filter { if net ~ LOCAL_NET then accept; else reject; }; next hop self; }; } protocol bgp bgp_B { bfd; description TOR B; local 10.105.1.13 as 4290105101 ; # enp4s0f1 neighbor 10.105.1.12 as 4259205001; # TOR_B default bgp_med 0; default bgp_local_pref 0; path metric 1; ipv4 { import all; export filter { if net ~ LOCAL_NET then accept; else reject; }; next hop self; }; }

3 9

Low voltage server/appliance for bird.
by Mike Neo 14 Nov '24

14 Nov '24

Hello, I am looking for a 1U rack platform with 1x or 2x psu with low power consumption for a bird-based bgp router (Ubuntu). The supported traffic is expected to be ~1-2Gbps. Can anyone recommend a tested solution? Thank you in advance. Mike

4 7

How BIRD chooses best route with confederation
by Yakimus // Netassist NOC 06 Nov '24

06 Nov '24

Hello! I have an example of working BGP confederation, where, as I supose, the route is chosen not in the best way Could someone explain why the first route looks better than the second one? Both are IGP, both have equal preference, but the second one have shorter as_path BIRD 2.0.12 ready. Table master4: 194.145.125.0/24 unicast [LVI_v4 2024-11-03] * (100) [AS39063i] via xx.xxx.132.22 on eth0.776 Type: BGP univ BGP.origin: IGP BGP.as_path: (43426 211288 29390) 39063 BGP.next_hop: xx.xxx.132.22 BGP.local_pref: 100 unicast [DEAS_v4 2024-11-03] (100) [AS39063i] via xx.xxx.132.19 on eth0.776 Type: BGP univ BGP.origin: IGP BGP.as_path: (29390) 39063 BGP.next_hop: xx.xxx.132.19 BGP.local_pref: 100 -- NETassist

2 1

[BGP] Set up bgp through the internet on public servers
by Talal Gharsa 02 Nov '24

02 Nov '24

Hello, I rent physical hosts from a public cloud provider and i am trying to set up a private network between them. For that, i want to configure BGP protocol between them. I use Bird 2.15.1 on AlmaLinux 9.2. Each host has a public ip that i use as « router id » and « neighbor ». I add a private ip 10.1.1.x on lo interface used for BGP. birdc show protocol command confirm that the bgp session is established. State is « up » and Info column displays « Established ». But birdc show route command is empty; it shows only the following message « BIRD 2.15.1 ready. ». The routing tables seems to not be shared between the peers. There are no errors in the logs (either /var/log/messages nor journalctl). Do you know if this approach is technically possible? Herunder the configuration: $ cat /etc/bird/bird.conf router id <public ip>; protocol bgp bgp_static { local as 65001; neighbor <server 2 public ip> as 65001; multihop 99; ipv4 { import all; export filter { if net = 10.1.1.1/32 then accept; reject; }; }; debug all; } Many Thanks, tg

4 4

Import/Pipe default route export pattern
by Nico Schottelius 01 Nov '24

01 Nov '24

Hello, we have some hosts that are part of the same AS, but cannot receive IGP routes due to networking isolation. The are usually IPv6 only, but sometimes they have an IPv4 address assigned to the loopback interface and would like to access the IPv4 Internet via IPv6 routes. So far, nothing special, IPv4-over-IPv6 works fine in bird. My questions goes into the direction of "how do you handle this case the best way"? How we solve it at the moment is not particularly elegant: - Store the IPv4 default route in a separate table "defroute4" on regular-router1 - Have a separate table "vpnXYZ" that is dedicated for exchanging routes with the IPv6-only-separated host vpnXYZ - Export the IPv4 default route using pipe from defroute4 to vpnXYZ - Use vpnXYZ table inside the peering with the vpnXYZ host - We want the routes that we receive from vpnXYZ to go into master4/master6 tables It seems a bit too complicated and I'd have expected something like an "import table" and "export table" statement in the bird channel configuration, WHICH DOES EXIST, but seems not to be designed to have a different import and export table :-( In code this currently looks as follows: -------------------------------------------------------------------------------- ipv6 table defroute6; ipv4 table defroute4; protocol static defroute_v6 { ipv6 { table defroute6; }; route ::/0 unreachable; } protocol static defroute_v4 { ipv4 { table defroute4; }; route 0.0.0.0/0 unreachable; } ipv4 table t_vpn_14778195; protocol pipe def_to_vpn_14778195 { table defroute4; # import TO here peer table t_vpn_14778195; # export TO this import none; export filter v4default; } protocol pipe vpn_14778195_to_master { table t_vpn_14778195; # import TO here peer table master4; # export TO this import none; export filter from_vpn14778195; } protocol bgp incoming_vpn14778195 { local as myas; direct; neighbor 2a0a:e5c0:2d:10::... as 213081; ipv6 { import filter from_vpn14778195; export filter v4default; }; ipv4 { import filter from_vpn14778195; export filter v4default; extended next hop on; next hop self; table t_vpn_14778195; }; } -------------------------------------------------------------------------------- Does anyone have a better / shorter / more elegant version to solve this issue? BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch

1 0

Route-type 5 support in BGP EVPN
by Ramanathan Selvamani 30 Oct '24

30 Oct '24

Hi Team, I would like to know about the below two things in BIRD support (1) Do you have any plan to support BGP EVPN Route-Type 5 (IP Prefix Route) as defined in RFC 9136 in the BIRD EVPN branch. (2) Do you have any plan to support two level recursive lookup to resolve nexthop for BGP routes. I mean the below comment in "rt_update_hostentry" function /* Recursive route should not depend on another recursive route */ Thanks, Ramanathan

2 2

BGP Flowspec VPNv4/VPNv6
by Vincent Bernat 26 Oct '24

26 Oct '24

Hey! I would be interested in implementing BGP Flowspec for VPNv4/VPNv6. Hacking flow4/flow6 to be VPNv4/VPNv6 instead of IPv4/IPv6 instead is easy, but I am unsure of the right way to *add* VPNv4/VPNv6. Should I add flowvpn4/flowvpn6 tables or reuse flow4/flow6 and only add "vpn4/vpn6 flow" channels to the BGP protocol? The difference with the MPLS case is that there is no FIB for Flowspec, so the design could be simplified. But, maybe we prefer to follow the existing design and have distinct tables for VPN and non-VPN cases? Thanks.

3 3