We have this feature but with wrong logic.
https://github.com/vyos/vyatta-cfg-quagga/blob/current/scripts/bgp/vyatta-bgp.pl#L723

Be default frr don't check this param.
So to enable this checks we need set and delete it again. It don't have any sense.

set protocols bgp 65001 parameters disable-network-import-check
commit
del protocols bgp 65001 parameters disable-network-import-check

vyos@zab01# commit
vyos@zab01# vtysh -c "show run"
Building configuration...

Current configuration:
!
router bgp 65001
 bgp network import-check
 neighbor 10.0.0.2 remote-as 65002

How about replace

parameters disable-network-import-check

to

parameters enable-network-import-check

PR https://github.com/vyos/vyatta-cfg-quagga/pull/44

@jestabro I fixed commit to

protocols bgp var parameters network-import-check

https://github.com/vyos/vyatta-cfg-quagga/pull/44/commits/2605e1fd84e5a8ef2e196ca07363936052a84893#diff-b4b2c4c113e14c75f6cbe8abeea91d3cR723

Thanks, @Viacheslav. We will need to add a migration script for the previous setting; that is simple in this case, since, as you observed, it was a no-op, and can just be dropped. If you are busy, I can add it.

@jestabro Create it please.

While you are working on this I'd suggest the default behavior to be to check if IGP routes exist by default. The reason most implementations check IGP is described in my initial bug submission along with diagrams. Since advertising unconditionally breaks dynamic routing it may make sense to make this a default.

Ben Russell
Chief Technology Officer
Stratus Networks
(309)370-3174
CCIE R&S #35267
MEF CECP #25743X2
CCDP

[logo]

This e-mail, and any files transmitted with it are the property of Stratus Networks, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 309-370-3174 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited

We don't can do it as default behavior.
Frr documentation, frr has profiles

datacenter - reflects a single administrative domain with intradomain links using aggressive timers.

http://docs.frrouting.org/en/latest/basic.html#profiles

With this profile default import check is "on"

#define DFLT_BGP_IMPORT_CHECK			1

https://github.com/rtrlib/frr-1/blob/master/defaults.h#L28

But it has some aggressive timers.
The profile must be the same across all daemons. Mismatches may result in undefined behavior.
I don't think it safe for production (changing profiles).

protocols bgp var parameters network-import-check

I would leave this as an option.

DFLT_BGP_IMPORT_CHECK can only be set by changing the profile? It can't be set directly? We don't need to change the default timers, just this parameter.

Ben Russell
Chief Technology Officer
Stratus Networks
(309)370-3174
CCIE R&S #35267
MEF CECP #25743X2
CCDP

[logo]

This e-mail, and any files transmitted with it are the property of Stratus Networks, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 309-370-3174 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited

Why we can't enable this feature by default.
A lot of customers don't use it, and announce their BGP prefix with "network x.x.x.x"
Imagine if you don't have configuration "redistribute connected" or "redistribute static".
If this feature enabled by default in the new release - you update the VyOS, reboot it and lose access to the router.
Because there are no routes /24 as directly connected. Also, you can use more-spec prefixes (/28 /29 /25), not /24.
Prefixes will disappear from the announcements ISPs.
It's impossible to figure out quickly what happened.

As far as I remember, originally in our Quagga days, it was the case: nothing was advertised if it wasn't present in the RIB. So if you wanted to advertise e.g. 192.0.2.0/24 but had it split into /25's, you'd need both set protocols bgp ... network 192.0.2.0/24 and set protocols static route 192.0.2.0/24 blackhole.

So I'm, with @brussell here: let's make it the default again.
I also agree that we should make a highly visible advisory to the release notes though.

@dmbaturin to enable it by default we need rewrite BGP to new python/XML format and use template, where this feature will be by default because FRR by default doesn't check routes in the RIB.

It would be interesting to hear the reason the FRR chose this behavior as default for one of their profiles. It causes major reconvergence issues for BGP networks and I don't see an obvious benefit.

FRR 7.4 has been released, and the default behaviour has been changed, commit 62282e8379. @Viacheslav, when we update to this version, I can work with you to update the migration script.

Sounds good thanks.

Ben Russell
Chief Technology Officer
Stratus Networks
(309)370-3174
CCIE R&S #35267
MEF CECP #25743X2
CCDP | VCNE

[logo]

This e-mail, and any files transmitted with it are the property of Stratus Networks, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 309-370-3174 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited

Behavior in FRR version 7.4

R1 - FRR 7.4 | directly connected 10.1.1.0/24 | not connected 203.0.113.0/24
R2 - FRR 7.3.1
R3 - FRR 7.3.1

R1 and R2 - eBGP
R1 and R3 - iBGP

1. R1 initial bgp configuration:

[email protected]:~$ show conf com | match "dum|bgp"
set interfaces dummy dum1 address '10.1.1.1/24'
set protocols bgp 65001 address-family ipv4-unicast network 10.1.1.0/24
set protocols bgp 65001 address-family ipv4-unicast network 203.0.113.0/24
set protocols bgp 65001 neighbor 100.64.0.2 remote-as '65002'
set protocols bgp 65001 neighbor 100.64.2.2 remote-as '65001'

Default for eBGP peer import/export not allow anything
Default for iBGP peer import/export allow

Check bgp status:

[email protected]:~$ show ip bgp sum

IPv4 Unicast Summary:
BGP router identifier 192.168.122.15, local AS number 65001 vrf-id 0
BGP table version 4
RIB entries 3, using 576 bytes of memory
Peers 2, using 43 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
100.64.0.2      4      65002        57        61        0    0    0 00:16:46     (Policy) (Policy)
100.64.2.2      4      65001        19        19        0    0    0 00:15:43            1        1

Total number of neighbors 2

Routes adverised to eBGP neighbor (no prefixes)

[email protected]:~$ show ip bgp neighbors 100.64.0.2 advertised-routes 
[email protected]:~$

Routes adevtised to iBGP neighbor

[email protected]:~$ show ip bgp neighbors 100.64.2.2 advertised-routes 

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0    100  32768 i

Total number of prefixes 1

Thus, by default, we do not export prefixes that are not in the RIB to the iBGP peer, and we do not export/import anything from/to the eBGP peer.

Ok it fixed issue when prefixes will be advertised only if it present in the routing table, but caused a different issue.
Default policy for eBGP peers is not export and receive prefixes.
If we want by default export and import routes for eBGP peers we have 2 options:

1. Use route-maps for import/export with policy "accept"
2. Use FRR option "ebgp-requires-policy" - Require in and out policy for eBGP peers (RFC8212)

By default it enabled (bgp ebgp-requires-policy), so to disable that behavior in vtysh:

r1-f7.4# conf t
r1-f7.4(config)# router bgp
r1-f7.4(config-router)# no bgp ebgp-requires-policy 
r1-f7.4(config-router)#

And reset peers.

[email protected]:~$ show ip bgp sum

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
100.64.0.2      4      65002       107       115        0    0    0 00:06:09            1        3
100.64.2.2      4      65001        66        77        0    0    0 00:06:09            1        2

2. Routes adverised to eBGP neighbor (with option "no bgp ebgp-requires-policy")

[email protected]:~$ show ip bgp neighbors 100.64.0.2  advertised-routes 

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*> 10.2.2.0/24      0.0.0.0                                0 65002 i
*> 10.3.3.0/24      0.0.0.0                       100      0 i

Routes adverised to iBGP neighbor (with option "no bgp ebgp-requires-policy")

[email protected]:~$ show ip bgp neighbors 100.64.2.2  advertised-routes 

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0    100  32768 i
*> 10.2.2.0/24      100.64.0.2               0    100      0 65002 i

3. Enable again default value for 7.4 "bgp ebgp-requires-policy"

r1-f7.4# show ip bgp sum

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
100.64.0.2      4      65002       119       127        0    0    0 00:18:09     (Policy) (Policy)
100.64.2.2      4      65001        78        89        0    0    0 00:18:09            1        2

And enable route-map action permit for "import/export" for eBGP peer

set policy route-map RMAP rule 10 action permit
set protocols bgp 65001 neighbor 100.64.0.2 address-family ipv4-unicast route-map import RMAP
set protocols bgp 65001 neighbor 100.64.0.2 address-family ipv4-unicast route-map export RMAP

Show bgp

[email protected]:~$ show ip bgp sum
BGP router identifier 192.168.122.15, local AS number 65001 vrf-id 0


Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
100.64.0.2      4      65002       124       134        0    0    0 00:21:46            1        3
100.64.2.2      4      65001        81        92        0    0    0 00:21:46            1        2

Routes adverised to eBGP neighbor (route-map permit all)

[email protected]:~$ show ip bgp neighbors 100.64.0.2 advertised-routes 

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*> 10.2.2.0/24      0.0.0.0                                0 65002 i
*> 10.3.3.0/24      0.0.0.0                       100      0 i

Conclusion.
We can use for FRR template option "no bgp ebgp-requires-policy" by default and it give us desired behaviour.
It's needs more test with other type of redistribution.

In T2100#72560, @jestabro wrote:

FRR 7.4 has been released, and the default behaviour has been changed, commit 62282e8379. @Viacheslav, when we update to this version, I can work with you to update the migration script.

That time is now. 1.4 has moved from FRR 7.3 to 7.5 and systems using set protocols bgp <asn> address-family <ipv4-unicast|ipv6-unicast> network <prefix> no longer have their prefixes announced to peers if they don't exist in the RIB.

From http://docs.frrouting.org/en/latest/bgp.html#clicmd-[no]bgpnetworkimport-check :

For versions 7.3 and before frr defaults for datacenter were the network must exist, traditional did not check for existence. For versions 7.4 and beyond both traditional and datacenter the network must exist.

@plett VyOS 1.4 now does an automatic fallback to the 1.3 behavior which used FRR 7.3 until we decide how to handle this, w.g. by adding a new CLI option which is added by a migration script to keep older systems running "as is" when upgrading.

Put in a PR for this, https://github.com/vyos/vyos-1x/pull/744