Regarding the behavior change of the BGP network feature.

[zice312963205]

Description

The current BGP network import-check feature causes BGP to subscribe to Zebra for all networks in a next-hop subscription manner. Due to a previous modification, Zebra can no longer distinguish whether this subscribed RNH (Resolved Next Hop) is used as a next hop in routes or for BGP networks. This introduces an implicit functional difference: Previously, the subscription behavior for network import-check did not attempt to match the contents of 'ip nht bgp route-map xxx'. Therefore, all network routes only checked for the existence of the route in Zebra. After the modification, the subscription behavior triggered by these networks attempts to match the contents of 'ip nht bgp route-map xxx', leading to behavioral differences in networks after upgrading FRR versions. This behavior cannot be corrected through any command.

From the perspective of the BGP network feature itself, it seems inappropriate to match the contents of 'ip nht bgp route-map xxx'. This route-map should be used solely for BGP next-hop iteration. Is this logic correct, and should we address this issue?

r1(config)# do show ip nht
VRF default:
Resolve via default: off
1.1.1.1
resolved via static, prefix 1.1.1.1/32
unreachable (blackhole), weight 1
Client list: bgp(fd 19)(filtered)
r1(config)#

config:
ip prefix-list nht seq 5 permit 2.2.2.2/32 ge 32 le 32
!
route-map nht permit 10
match ip address prefix-list nht
exit
!
route-map nht deny 20
exit
!

router bgp 65001
bgp router-id 192.0.2.1
no bgp ebgp-requires-policy
no bgp enforce-first-as
no bgp hard-administrative-reset
no bgp default ipv4-unicast
no bgp graceful-restart notification
!
address-family ipv4 unicast
network 1.1.1.1/32
exit-address-family
!
exit
!
ip nht bgp route-map nht
!

Version

FRRouting 10.3

How to reproduce

config:
ip prefix-list nht seq 5 permit 2.2.2.2/32 ge 32 le 32
!
route-map nht permit 10
match ip address prefix-list nht
exit
!
route-map nht deny 20
exit
!

router bgp 65001
bgp router-id 192.0.2.1
no bgp ebgp-requires-policy
no bgp enforce-first-as
no bgp hard-administrative-reset
no bgp default ipv4-unicast
no bgp graceful-restart notification
!
address-family ipv4 unicast
network 1.1.1.1/32
exit-address-family
!
exit
!
ip nht bgp route-map nht
!

Expected behavior

please see the description

Actual behavior

please see the description

Additional context

No response

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[zice312963205]

Revision: b821084
Author: Donald Sharp sharpd@nvidia.com
Date: 2021/9/24 22:10:31
Message:
bgpd: Make bgp ready to remove distinction between 2 nh tracking types

Allow bgp to figure out if it cares about address resolution instead
of having zebra care about it. This will allow the removal of the
zapi type for import checking and just use nexthop resolution.

Effectively we just look up the route being returned and
if it is in either table we just handle it instead of
looking for clues from the zapi message type.

Signed-off-by: Donald Sharp sharpd@nvidia.com

Modified: bgpd/bgp_nht.c

@donaldsharp Could you help check this issue?

[pguibert6WIND]

Revision: b821084 Author: Donald Sharp sharpd@nvidia.com Date: 2021/9/24 22:10:31 Message: bgpd: Make bgp ready to remove distinction between 2 nh tracking types

Allow bgp to figure out if it cares about address resolution instead of having zebra care about it. This will allow the removal of the zapi type for import checking and just use nexthop resolution.

Effectively we just look up the route being returned and if it is in either table we just handle it instead of looking for clues from the zapi message type.

Signed-off-by: Donald Sharp sharpd@nvidia.com

Modified: bgpd/bgp_nht.c

@donaldsharp Could you help check this issue?

The need to simplify ZAPI is correct. However,one could think of a passed parameter to help NHT in zebra to know if a route-map has to be applied ot not. In that way, no cli needed.

[zice312963205]

Revision: b821084 Author: Donald Sharp sharpd@nvidia.com Date: 2021/9/24 22:10:31 Message: bgpd: Make bgp ready to remove distinction between 2 nh tracking types
Allow bgp to figure out if it cares about address resolution instead of having zebra care about it. This will allow the removal of the zapi type for import checking and just use nexthop resolution.
Effectively we just look up the route being returned and if it is in either table we just handle it instead of looking for clues from the zapi message type.

Signed-off-by: Donald Sharp sharpd@nvidia.com

Modified: bgpd/bgp_nht.c
@donaldsharp Could you help check this issue?

The need to simplify ZAPI is correct. However,one could think of a passed parameter to help NHT in zebra to know if a route-map has to be applied ot not. In that way, no cli needed.

I believe this cannot be marked simply by a flag. Instead, I think it is necessary to revert to the previous approach by introducing a type identifier for RNH. This is because, for BGP, certain prefixes may require iteration based on the next hop, meaning they need the NHT route-map. On the other hand, when used as a network, the NHT route-map is not needed. Although these two RNHs have the same prefix, different type identifiers need to create distinct RNHs to ensure they notify different results.
For example, BGP receives the following routes:
1.1.1.1/24 nh:2.2.2.2
2.1.1.1/24 nh:3.3.3.3
Meanwhile, the following is configured in BGP IPv4-unicast:

router bgp 65001
address-family ipv4 unicast
network 3.3.3.3/32
exit-address-family
And the following NHT route-map is configured:

ip prefix-list nht seq 5 permit 2.2.2.2/32 ge 32 le 32
route-map nht permit 10
match ip address prefix-list nht
exit
!
route-map nht deny 20
exit

ip nht bgp route-map nht
Additionally, there's a static route on the device:

ip route 1.1.1.1/32 blackhole

Under this configuration, my expectation is that BGP should consider:
The route 1.1.1.1/24 as valid
The route 2.1.1.1/24 as invalid
3.3.3.3/32 should be able to be injected into BGP.
With the current implementation, I cannot achieve this because the RNH created for import-check conflicts with the RNH created for BGP nexthop. They cannot distinguish which need the NHT route-map and which do not.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot]

This issue will be automatically closed in the specified period unless there is further activity.

[mjstapp]

Let's keep this open - seems like something we should talk through

[frrbot]

This issue will no longer be automatically closed.