The customer was in the process of configuring eBGP peering on their aggregation router (MX2020, running Junos OS version 19.4R3-S7.3) with the following peers:
As part of this setup, they defined three BGP groups:
Upon establishing neighborship with ASBR01, IPv4 and IPv6 routes were advertised immediately. However, BGP-LU route advertisements were delayed by over 15 minutes.
This delay was only observed with the first peer (ASBR01); subsequent peers (ASBR02–ASBR04) did not exhibit the same issue.
Model: mx2020
Junos: 19.4R3-S7.3
labuser@re0-labrouter> show bgp summary | match 42XX
96.XX.XX.154 42XXXXXX21 9 7 0 0 2:51 Establ
96.XXX.XX.190 42XXXXXX21 27 5692 100 0 2:47 Establ
2001:558:XXX:XXX::2 42XXXXXX21 20 2431 100 0 2:49 Establ
No BGP route advertisement to BGP LU peer
labuser@re0-labrouter> show bgp neighbor 96.XX.XX.154
Peer: 96.XX.XX.154+33619 AS 42XXXXXX21 Local: 96.XXX.XX.153+179 AS 42XXXXXX20
Description: asbr01.XXX
Group: ipv4-lu Routing-Instance: master
Forwarding routing-instance: master
Type: External State: Established Flags: <Sync RSync>
Last State: EstabSync Last Event: RsyncAck
Last Error: None
Export: [ LEGACY-TO-LU-OUT DENY-ALL ]
Options: <Preference AdvertiseInactive AuthKey LogUpDown AddressFamily PeerAS Multipath PrefixLimit LocalAS Rib-group Refresh>
Options: <MtuDiscovery BfdEnabled DropPathAttributes Protection>
Options: <GracefulShutdownRcv MultipathAllowProtection>
Authentication key is configured
Address families configured: inet-labeled-unicast
...
Table inet.0 Bit: 2000c
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 30 Sent 2 Checked 180
Input messages: Total 9 Updates 1 Refreshes 0 Octets 237
Output messages: Total 7 Updates 0 Refreshes 0 Octets 133
Output Queue[1]: 0 (inet.0, inet-labeled-unicast)
Trace options: state
Trace file: /var/log/ipv4-lu-unicast-logs size 10485760 files 10
At the same time, BGP route advertisement is happening towards IPv4 Unicast and IPv6 Unicast Peer
labuser@re0-labrouter> show bgp neighbor 96.XXX.XX.190
Peer: 96.XXX.XX.190+34875 AS 42XXXXXX21 Local: 96.XXX.XX.189+179 AS 42XXXXXX20
Group: ipv4-u Routing-Instance: master
Table inet.0 Bit: 2000d
Active prefixes: 8
Received prefixes: 70
Accepted prefixes: 70
Advertised prefixes: 24683
labuser@re0-labrouter> show bgp neighbor 2001:558:XXX:XXX::2
Peer: 2001:558:XXX:XXX::2+33451 AS 42XXXXXX21 Local: 2001:558:XXX:XXX::1+179 AS 42XXXXXX20
Group: ipv6-u Routing-Instance: master
Table inet6.0 Bit: 50007
Send state: not in sync
Received prefixes: 66
Accepted prefixes: 66
Advertised prefixes: 37335
About 20+ minutes later, We see successful advertisement to the LU Peer
May 21 05:30:00
Advertised prefixes: 1113
The delay was caused by the export policy LEGACY-TO-LU-OUT configured on the ipv4-lu BGP group. This policy evaluates all BGP routes (approximately 1 million in customer environments) and filters those with the community *:1305 before advertising them to other peers.
set protocols bgp group ipv4-lu export LEGACY-TO-LU-OUT
set protocols bgp group ipv4-lu export DENY-ALL
set policy-options policy-statement LEGACY-TO-LU-OUT term permit-lu-prefixes from protocol bgp
set policy-options policy-statement LEGACY-TO-LU-OUT term permit-lu-prefixes from community BGP-LU-COMM
set policy-options policy-statement LEGACY-TO-LU-OUT term permit-lu-prefixes then accept
set policy-options policy-statement LEGACY-TO-LU-OUT then next policy
set policy-options community BGP-LU-COMM members *:1305
set policy-options policy-statement DENY-ALL then reject
This behavior is expected. When a BGP group is activated, based on the export policy, the system must evaluate all BGP routes to determine which ones to advertise. If there are already active peers in the group and a new peer is added, the evaluation is quicker.