Hello! On Fri, May 31, 2024 at 11:29:12PM +0000, LIU Chris via Bird-users wrote:

I configured BGP with peer, which is Fortinet device. Both of sides show BGP status established, however, there is no route exchanged. Start bird daemon with -D log_file, but only see some keepalive, no other debug message come out.

1. Is it possible to increase debug level, see more logs to figure out the root cause ? 2. Generally how to debug this kind of BGP issue, any suggestion is appreciated ?

``` protocol bgp BGP_INSTANCE { debug all; } ```

You may want also `ipv6 { … debug { routes }; };` Also you have to set up your filters on both sides. If you share your `show proto all` CLI command output and/or your full config file, we may help you better. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Hello Chris, � According to the documentation, https://bird.network.cz/?get_doc <https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.17> &v=20&f=bird-6.html#ss6.17 � A route requires at least one next hop. “route 192.168.0.0/16;” should not pass the configuration check. � Valid routes can be: route 192.168.0.0/16 blackhole; # drop packets to the destination route 192.168.0.0/16 reject; # reject packets to the destination route 192.168.0.0/16 via eth0; route 192.168.0.0/16 via 192.168.1.1; # 192.168.1.1 is directly reachable route 192.168.0.0/16 recursive 192.168.1.1; # use next hop by resolving the route to 192.168.1.1 � When you announcing the prefix to your neighbor, the neighbor finds next hop with bgp_next_hop, it only knows that 192.168.0.0/16 is reachable via your router, and doesn’t know that prefix is blackholed on your router. � Static routes are the reachability information defined statically on your router, which should be told to the kernel to be effective. If you are not exporting the routes to your kernel (this is actually what you did in the configuration you provided), the blackhole here will not affect your IP packet forwarding. � Regards, Soha � From: Bird-users <bird-users-bounces@network.cz> On Behalf Of LIU Chris via Bird-users Sent: Tuesday, June 4, 2024 11:24 PM To: BIRD Users <bird-users@network.cz> Subject: bird BGP not advertise local routing, unless make it blackhole � Classified as: Hitachi Rail – Public � I am new for bird/BGP. My configuration as below. Basically it is working as expected except one thing. This static routing, I want to advertise this route to BGP peers. If I just configured as : � route 192.168.0.0/16, �Bird doesn’t advertise this route unless add it as blackhole blackhole is sink or just drop, why ? protocol static static_bgp { ipv4; check link; route 192.168.0.0/16 blackhole; } � � ------------------------------------------ router id 1.1.1.1; filter Filter_Export_Kernel { if net ~ [ 10.1.0.0/16 ] then { accept; } else reject; } protocol kernel { scan time 10; ipv4 { export filter Filter_Export_Kernel; }; } protocol device { scan time 10; } protocol static static_bgp { ipv4; check link; route 192.168.0.0/16 blackhole; } protocol bgp BGP_INSTANCE_1 { local xx.xx.xx.xx as 10001; neighbor yy.yy.yy.yy as 10002; ipv4 { import all; export where proto ="static_bgp"; preference 200; }; hold time 3; bfd on; } protocol bfd BFD_INSTANCE_1 { interface "eth1" { min rx interval 1 s; min tx interval 1 s; idle tx interval 3000 ms; multiplier 3; }; neighbor yy.yy.yy.yy local xx.xx.xx.xx; } --------------------------------- � Hitachi Rail – Public

Classified as: {Hitachi Rail – Public} My setup : Linux running bird， Peer: Fortinet Firewall In bird, configure bfd as below: protocol bfd BFD_SD_01 { interface "*" { min rx interval 1000000 us; min tx interval 1000000 us; idle tx interval 1000000 ums; multiplier 3; }; neighbor 192.168.0.1 local 192.168.0.2; } Fortinet side, biasally same, also set rx intrva: 1000 ms, tx interval: 1000ms, multiplier: 3 However, both side show bfd DOWN。 Catpure tcpdump in Fortinet side, Fortinet IP: 192.168.0.1 Time source destination protocol info 1 0.000000 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00 6 0.756375 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00 11 1.519796 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00 14 2.351177 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00 19 3.225686 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00 24 3.852938 192.168.0.1 192.168.0.2 BFD Control Diag: Control Detection Time Expired, State: Down, Flags: 0x00 25 3.981126 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00 from Fortinet neighbour information, it seems cannot receive control message from Peer, why? I don't have any block port. Why get detection time: 1500ms after neighboation Below is fortinet bfd neighbor information OurAddress NeighAddress State Interface LDesc/RDesc 192.168.0.1 192.168.0.2 DOWN STN2-SD-A 1/0/M Local Diag: 1, Demand mode: no, Poll bit: unset MinTxInt: 1000, MinRxInt: 1000, Multiplier: 3 Received: MinRxInt: 0 (ms), MinTxInt: 0 (ms), Multiplier: 3 Transmit Interval: 6500 (ms), Detection Time: 1500 (ms) Rx Count: 0, Rx Interval; (ms) min/max/avg 0/0/0 Tx Count: 10287, Tx Interval (ms) min/max/avg 5000/5030/5000, last: 2350 (ms) ago Registered protocols: Static BGP Is this bird issue or fortinet? I suspect 80% caused by Fortiet, but I just want to get some suggestion/proposal from bird expert. With Best Regards, Chris LIU Hitachi Rail – Public {Hitachi Rail – Public}

Hi, Could it be issue with a source port? It is described in the documentation, btw: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.3 On Sat, Jun 8, 2024, 03:51 Maria Matejka via Bird-users < bird-users@network.cz> wrote:

Hello!

On first sight this looks like Fortinet ignoring the packets. Maybe (wild guess) you have a firewall rule in place dropping them in the Fortinet?

Maria

On 7 June 2024 21:51:28 CEST, LIU Chris via Bird-users < bird-users@network.cz> wrote:

...

Classified as: {Hitachi Rail – Public}

My setup :

Linux running bird， Peer: Fortinet Firewall

In bird, configure bfd as below:

protocol bfd BFD_SD_01 {

interface "*" {

min rx interval 1000000 us;

min tx interval 1000000 us;

idle tx interval 1000000 ums;

multiplier 3;

};

neighbor 192.168.0.1 local 192.168.0.2;

}

Fortinet side, biasally same, also set rx intrva: 1000 ms, tx interval: 1000ms, multiplier: 3

However, both side show bfd DOWN。

Catpure tcpdump in Fortinet side, Fortinet IP: 192.168.0.1

Time source destination protocol info

1 0.000000 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00

6 0.756375 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00

11 1.519796 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00

14 2.351177 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00

19 3.225686 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00

24 3.852938 192.168.0.1 192.168.0.2 BFD Control Diag: Control Detection Time Expired, State: Down, Flags: 0x00

25 3.981126 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: Down, Flags: 0x00

from Fortinet neighbour information, it seems cannot receive control message from Peer, why? I don't have any block port. Why get detection time: 1500ms after neighboation

Below is fortinet bfd neighbor information

OurAddress NeighAddress State Interface LDesc/RDesc

192.168.0.1 192.168.0.2 DOWN STN2-SD-A 1/0/M

Local Diag: 1, Demand mode: no, Poll bit: unset

MinTxInt: 1000, MinRxInt: 1000, Multiplier: 3

Received: MinRxInt: 0 (ms), MinTxInt: 0 (ms), Multiplier: 3

Transmit Interval: 6500 (ms), Detection Time: 1500 (ms)

Rx Count: 0, Rx Interval; (ms) min/max/avg 0/0/0

Tx Count: 10287, Tx Interval (ms) min/max/avg 5000/5030/5000, last: 2350 (ms) ago

Registered protocols: Static BGP

Is this bird issue or fortinet? I suspect 80% caused by Fortiet, but I just want to get some suggestion/proposal from bird expert.

With Best Regards,

Chris LIU

Hitachi Rail – Public

{Hitachi Rail – Public}

-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Hi Maria, Thanks for the reply 23.172.216.0/24 unicast [I_ZJ1 10:32:48.661 from 2a13:aac7:13:7::2] * (100) [AS398741i] via 10.0.29.2 on CN-ZJ1 Type: BGP univ BGP.origin: IGP BGP.as_path: 398741 60539 60539 (65000) 60539 398741 BGP.next_hop: 10.0.29.2 BGP.med: 101 BGP.local_pref: 400 BGP.large_community: (60539, 2, 1) (60539, 6, 65000) (60539, 6, 52000) After I enabled is_bogon() function, this route from our downstream would be filtered. function is_bogon() { if is_bogon_asn() then return true; if is_bogon_prefix() then return true; if net_len_too_long() then return true; return false; } function bgp_export() { # my_opt_prefix(); if is_bogon() then return false; #关闭以防止过滤bgp conf的内部ASN if bgp_large_community ~ [(LOCAL_ASN, 4, NODE_ID)] then return false; if is_local_prefix() then return true; # if proto = "BGP_Prefix_play" then return true; if source != RTS_BGP then return false; if bgp_large_community !~ [(LOCAL_ASN, 2, 1)] then return false; return true; } I always remember that in BIRD, BGP Confederation internal ASNs cannot be counted in bgp_path.len. But BGP Confederation internal ASNs can be treated as 'normal' ASNs for filtering? Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Sat, 1 Jun 2024 at 22:36, Maria Matejka <maria.matejka@nic.cz> wrote:

Hello Brandon,

On Thu, May 30, 2024 at 09:52:53PM +0800, Brandon Zhi wrote:

I am writing to inquire about the capabilities of the new version of BIRD regarding BGP Confederation internal ASNs. Specifically, I would like to know:

1. Can the new BIRD version filter BGP Confederation internal ASNs? 2. Does it support calculating the total AS path length, including internal ASNs within a BGP Confederation?

You are probably looking for something like bgp_path.filter() or bgp_path.len, or maybe for int p in bgp_path do { … }

Additionally, I have encountered an issue while using the is_bogon() function. It currently filters a route with the AS path (65000) 398741. I suspect this is because (65000) is being treated as a BOGON ASN.

Below is the define BOGON_ASNS I am using:

define BOGON_ASNS = [ 0, # RFC 7607 23456, # RFC 4893 AS_TRANS 64496..64511, # RFC 5398 and documentation/example ASNs 64512..65534, # RFC 6996 Private ASNs 65535, # RFC 7300 Last 16 bit ASN 65536..65551, # RFC 5398 and documentation/example ASNs 65552..131071, # RFC IANA reserved ASNs 4200000000..4294967294, # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN ];

Yes, this includes 65500. I can’t see your is_bogon() function definition though so I can’t help you more.

Hoping that this helps.

Maria

– Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.