If the front-end BGP peer and the back-end BGP peer learn the same prefix, a fib alarm will appear.

[ShawnLeung87]

If the front-end BGP peer and the back-end BGP peer learn the same prefix, a fib alarm will appear. This situation exists in BGP networks where routing prefixes are advertised across multiple ISPs The 1.1.1.0/24 prefix of the route learned from the ISP operator is the same as the 1.1.1.0 prefix of the back GW, which will cause an abnormal fib alarm GATEKEEPER GK: process_fib_back(): A FIB entry has the unexpected action 0 There are too many such alarms, causing the back-end GW to be unreachable.

[ShawnLeung87]

This problem is more serious, for example,

1. On my client side, as number 139282, it is connected to our company's as 10358, and also connected to ISP NTT,
2. Usually prefix 1.1.1.0/24, announce as 10358 to reach ISP NTT, the AS number of ISP NTT establishes a BGP session with gatekeeper GK, 1.1.1.0/24 action GK_FWD_GRANTOR,
3. If the client as number 139282, stop advertising prefixes 1.1.10/24 to as 10358, and advertise the prefix 1.1.1.0/24 from its own directly connected ISP NTT. AS10358 will learn the route prefix 1.1.1.0/24 from the front-end interfere, which will trigger the problem "GATEKEEPER GK: process_fib_back(): A FIB entry has the unexpected action 0", resulting in unreachable GW router and unreachable destination prefixes.
4. I deleted the 1.1.1.0/24 action GK_FWD_GRANTOR, the network is restored

[ShawnLeung87]

At present, I have thought of a way. In the BGP configuration of bird, the configuration does not import the IP prefix of our company from the ISP peer.

[AltraMayor]

Although Gatekeeper servers get information from BGP, Gatekeeper servers are not routers. Gatekeeper servers get information from BGP to support the routers to which they are connected. Gatekeeper servers expect all traffic from front-to-back interfaces to be from external networks to the protected network and vice versa. So when a Gatekeeper server receives routes for the same prefix on both interfaces, it gets confused with what's going on. This confusion can happen with routes of any type. From a Gatekeeper server's perspective, the confusion in your case is because the server is instructed to protect a prefix being announced as external; that is why the action is reported as "unexpected."

Your solution to filter prefixes you are responsible for from external announcements is a good approach to solving the problem. Later on, you may find other solutions that are more convenient to the way you manage your network, but all of the solutions will be at the BGP level.