delay-route-advertisements
Syntax
delay-route-advertisements {
minimum-delay {
routing-uptime routing-uptime;
inbound-convergence inbound-convergence;
}
maximum-delay {
route-age routing-age;
routing-uptime routing-uptime;
}
always-wait-for-krt-drain;
}
Hierarchy Level
[edit logical-systems name protocols bgp family name], [edit logical-systems name protocols bgp group name family name], [edit logical-systems name protocols bgp group name neighbor ip-address family name], [edit logical-systems name routing-instances name protocols bgp family name], [edit logical-systems name routing-instances name protocols bgp group name family name], [edit logical-systems name routing-instances name protocols bgp group name neighbor ip-address family name], [edit protocols bgp familyname], [edit protocols bgp group name family name], [edit protocols bgp group name neighbor ip-address familyname], [edit routing-instances name protocols bgp family name], [edit routing-instances name protocols bgp group name family name], [edit routing-instances name protocols bgp neighbor ip-address family name]
Description
Configure this option to delay route updates for a specified family until the forwarding table is synchronized. When a device starts up, BGP establishes peering sessions with its neighbors and receives route updates. These route updates are then readvertised as more specific BGP routes or less specific aggregates. Advertising routes prematurely, that is, before all the available routes are installed in the forwarding table, might result in traffic loss.
In multihomed networks, this behavior might cause unnecessary loss of service when a BGP session at the primary provider edge comes up. This problem is more pronounced when the primary provider edge device advertises route aggregates, because few aggregate prefixes can be announced more quickly to the network peers than a full routing table with thousands of more specific prefixes to the forwarding table. In order to avoid this problem, the device must delay a BGP route advertisement until the associated forwarding state is installed into the forwarding table. This feature allows a Junos OS device to do so, and allows you to configure the minimum and maximum delay periods.
Options
| minimum-delay | (Optional) Specify a minimum delay, in seconds, in advertising the routes. |
| inbound-convergence inbound-convergence | (Optional) Specify a minimum delay in route advertisement after the source peer has sent all route updates. The device waits at least for the configured duration after inbound convergence has completed at the source of the route. For BGP routes, the source peer sends the initial route updates, for example after end-of-rib is received.
|
| routing-uptime routing-uptime | (Optional) Specify the minimum delay, in seconds, before sending a route advertisement after the routing protocol process (rpd) starts. The device waits for at least the configured duration before sending out route advertisements to its peers.
|
| maximum-delay | (Optional) Specify a maximum delay, in seconds, before advertising routes to peers. |
| route-age routing-age | (Optional) Specify a maximum delay in sending a route advertisement after route aggregates have been created, that is, the route age. The device suspends waiting for the routes to be downloaded to the forwarding table at the configured route age and starts sending route advertisements to its peers.
|
| routing-uptime routing-uptime | (Optional) Specify the maximum delay in seconds before sending a route advertisement after the routing protocol process (rpd) starts. The device does not wait more than the configured duration before sending out route advertisements to its peers.
|
| always-wait-for-krt-drain | Delay route advertisement until KRT queue is drained. |
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 15.1F6.