Recent disruptions to two undersea internet cables in the Baltic Sea have yet again...
4.4 Bgpd settings
4.4.1 bgpd.as_path #
Defines the way Bgpd handles the AS-PATH attribute in the outgoing announcements. The selected options are evaluated in the configured order and the first valid AS-PATH will be used.
Note that IRP will refuse to announce improvements when all configured options fail to produce a valid AS-PATH. Option 0 allows announcements with empty AS-PATH but this is undesirable for other reasons noted below.Keeping a correct AS-PATH can be a requirement for some NetFlow/sFlow processing since the provider AS or the destination AS for the corresponding flow record is taken from the BGP routing table.
Some installations use outgoing filters that allow empty AS-Path while redistributing iBGP routes to upstreams. In such cases, Bgpd must be configured not to advertise the improvements with an empty AS-PATH to prevent further redistribution of the improvements to upstream routers.
The reconstructed AS-path does not always correspond to the actual BGP AS-path.”Use AS-Path from BMP” option is tied to the bgpd.improvements.remove.bmp_exact_aggregate parameter. Must be enabled and placed first in the list of AS path restore priority options for the improvements to be removed when an exact size prefix gets withdrawn from BMP.
Refer also to peer.X.ipv4.next_hop_as, peer.X.ipv6.next_hop_as, peer.X.aspath_for_ix, bgpd.as_path_borrowing, bgpd.improvements.remove.bmp_exact_aggregate.
Examples:
bgpd.as_path=2 3 – this will instruct Bgpd to take first path from the database (reconstructed AS-Path). If that path is empty, then an AS-path with the provider’s AS number and the prefix AS number should be composed.bgpd.as_path=3 0 – this will instruct Bgpd to compose an AS-path with the provider’s AS number and the prefix AS number. If AS-Path remains empty, the improvements with an empty AS-Path are announced.- Possible values:
Space separated list of options in the order of preference- 0 – Allow empty AS-PATH
- 2 – Use non-empty reconstructed AS-PATH (Announce AS-path reconstructed from traceroute)
- 3 – Reconstruct AS path with provider ASN and prefix origin ASN
- 4 – Use AS-Path from BMP
- 5 – Use AS-Path from BGP Alternative paths (RFC 7911)
Second algorithm produces meaningful AS-PATH only when explorer.trace.all is enabled- Default value:
5 4 2 3
4.4.2 bgpd.as_path_borrowing #
Allows BMP to borrow AS path from other Provider with the same autonomous system number.
The parameter modifies only 4th algo of bgpd.as_path parameter.- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.4.3 bgpd.db.timeout.withdraw #
Defines the time period (in seconds) before prefixes are withdrawn from the routing tables, after a database failure. This allows BGP daemon to function independently for a period of time after the IRP database becomes inaccessible due to a failure or manual intervention.
- Possible values:
600-21600(6 hours) - Default value:
14400 - Recommended values:
3600-14400
4.4.4 bgpd.full_control #
Sets default behavior of IRP in regards to inbound prefixes control and specifically:
- only announce improvements or
- only announce improvements and include all allowed providers or
- fully control inbound prefixes by always announcing to allowed providers.
This system wide default behavior can be overridden at inbound prefix level by specifying desired parameter value for inbound.rule.X.full_control.- Possible values:
0 (Improvements), 1 (If improved), 2 (All) - Default value:
0
4.4.5 bgpd.grpc.port #
Specifies the TCP port on which the Bgpd is listening for interprocess communication.
- Possible values:
1-65535 - Default value:
7605
4.4.6 bgpd.improvements.remove.bmp_exact_aggregate #
Removes an improvement when the exact prefix for such improvement is no longer seen in BMP and the AS-Path from BMP is in use.
See also bgpd.improvements.remove.withdrawn, bgpd.as_path.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.4.7 bgpd.improvements.remove.hold_time #
Defines the time interval (in seconds) for deleting (from the IRP database) the improvements affected by “Remove on next-hop eq” or “Remove on aggregate withdraw” conditions (see bgpd.improvements.remove.next_hop_eq and bgpd.improvements.remove.withdrawn).
This reduces the effects of route flapping to improvement cleanup.
Verification is performed on each BGP Scan, so that the values that are lower than the value of the bgpd.scaninterval parameter are not taken into account. The higher the values – the longer the time interval needed for improvements, which are still valid after aggregate route is withdrawn or on equal next-hop.
Bgpd does improvements check against the routers received and sent via iBGP in periodic time intervals. The process is referred to as the BGP Scan process.
Time interval between BGP Scannings can be configured in bgpd.scaninterval.
- Possible values:
1-1000seconds - Default value:
60 - Recommended values:
30-120
4.4.8 bgpd.improvements.remove.next_hop_eq #
Instructs Bgpd to remove a prefix from improvements when aggregate route’s next hop has changed and points to the same next hop as the improvement.
This parameter shouldn’t be enabled when bgpd.updates.split is disabled in a multi-routing domain configuration.- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0 - Recommended value:
0
4.4.9 bgpd.improvements.remove.withdrawn #
Instructs Bgpd to remove prefix from improvements when aggregate is being withdrawn from the router.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1 - Recommended value:
1
4.4.10 bgpd.improvements.strip_non_irp_communities #
Instructs Bgpd to exclude from Updates of IRP improvements other communities except those configured in IRP.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.4.11 bgpd.log #
Defines the complete path to the Bgpd log file
- Possible values:
full path to log file - Default value:
/var/log/irp/bgpd.log
4.4.12 bgpd.log.level #
Defines the logging level for the Bgpd service.
- Possible values:
emerg, fatal, alert, crit, error, warn, notice, info, debug, trace - Default value:
info - Recommended value:
info
4.4.13 bgpd.mon.guardtime #
Defines the Bgpd Monitoring guard time. All the controlled IP addresses must respond within the specified amount of time, for the provider to be restored from the FAIL state. In FAIL state, all improvements are withdrawn from that provider.
It is recommended that bgpd.mon.guardtime is set as a double value of the bgpd.mon.holdtime.
It is recommended that bgpd.mon.guardtime is set as a double value of the bgpd.mon.holdtime.
- Possible values:
10-600 - Default value:
60 - Recommended value:
60
4.4.14 bgpd.mon.holdtime #
Defines the Bgpd Monitoring holdtime.
If any controlled IP address does not respond to all the requests during the holdtime, then corresponding provider enters the FAIL state. In FAIL state, all the improvements are withdrawn from that provider.
- Possible values:
10-60 - Default value:
30 - Recommended value:
30
4.4.15 bgpd.mon.internal.flap_guardtime #
Defines time interval to protect from BGP session flapping.
Internal monitor will keep FAIL state until BGP session stays established within the configured period of time.
- Possible values:
0-86400 - Default value:
0 - Recommended value:
600
4.4.16 bgpd.mon.keepalive #
Defines the Bgpd Monitoring keepalive interval (in seconds) between consequent ICMP Echo Requests to single controlled IP address.
- Possible values:
1-10 - Default value:
10 - Recommended value:
5
4.4.17 bgpd.mon.longholdtime #
Defines the Bgpd Monitoring long holdtime.
If any controlled IP address does not respond to all the requests during the long holdtime, then corresponding provider enters the FAIL state. In FAIL state, all the improvements are withdrawn from that provider.
- Possible values:
60-3600 - Default value:
1800 - Recommended value:
1800
4.4.18 bgpd.monitor.type #
Defines how IRP monitors Improvements to Internet Exchanges:
- by using coarse-grained internal monitors that merely validate an IX peer is live or
- by using fine-grained prefix monitors for each IX improvement that validate that the IX peer still advertises the improved prefix.
Prefix monitors might consume significant router CPU resources when relying on SNMP to determine if an IX peer advertises the improved prefix and the number of IX improvements is large.Refer to bgpd.prefix.monitor.interval for details.
- Possible values:
0 (Use internal monitor), 1 (Use prefix monitor) - Default value:
0
4.4.19 bgpd.no_export #
Controls how Bgpd appends NO_EXPORT or NO_ADVERTIZE communities to outbound improvements.
A router is responsible (as defined in RFC 1997) for preventing the utter route redistribution (NO_ADVERTISE) or the route advertisement outside of an autonomous system (NO_EXPORT).
Its strictly recommended to have this option turned on as an additional measure in preventing Outbound Improvement leakage outside of an optimized network.
One may consider disabling the feature in the following conditions:
- Different autonomous system numbers are used inside of an optimized network.
The feature may prevent redistribution of a Global improvement in MRD configuration. - Downstream BGP peering.
The feature may prevent redistribution of routes to downstream, making the improved routes not visible to it.
Disable with caution- Possible values:
- 0 Disabled
- 1 Append NO_EXPORT community to outbound imrovements
- 2 Append NO_ADVERTISE community to outbound imrovements
- Default value:
1
4.4.20 bgpd.policy.cascade.amount #
Defines the maximum number of downstream AS for cascading policies. If IRP identifies more downstream elements in AS-PATH from the designated AS the policy for those AS will not be enforced.
- Possible values:
1-1000000 - Default value:
1000 - Recommended value:
1000
4.4.21 bgpd.prefix.monitor.interval #
Prefix monitor tracks at given interval in seconds if a peering partner on an Exchange is still announcing the prefix that IRP improved through it.
This is intended to avoid cases when after IRP makes an Improvement through a peer on an IX the peer stops announcing/servicing the route.- Possible values:
1-60 - Default value:
10
4.4.22 bgpd.prefix.monitor.search_interval #
Defines the interval between retries of prefix monitor failed initialization attempts in case a prefix isn’t advertized by an IX peering partner or if a SNMP error occurs.
During this time IRP will not be able to make improvements through the affected IX peers.- Possible values:
300-3600 - Default value:
300
4.4.23 bgpd.prefixlist.asn #
Specifies a collection of AS numbers that are analyzed for inbound optimization of transiting traffic. Refer Optimization of transiting traffic, Optimization of transiting traffic.
IRP ignores prefixes /25 and shorter for IPv4 and /65 and shorter for IPv6 being present in network’s routing table. This means that traffic belonging to these small prefixes are accounted under the immediately larger prefix that fits the above criteria.- Possible values:
list of valid AS numbers
4.4.24 bgpd.prefixlist.prefixes #
Specifies a collection of IPv4 or/and IPv6 prefixes in CIDR notation that are analyzed for inbound optimization of transiting traffic. Refer Optimization of transiting traffic, Optimization of transiting traffic.
- Possible values:
list of valid CIDR prefixes
4.4.25 bgpd.rd_local_mark #
Specifies a marker to distinguish local improvements from global improvements in the case of multiple routing domains optimization. Parameter represents a valid value for BGP community attribute of the form X:Y. Value in bgpd.rd_local_mark is APPENDED to communities attribute. Refer global.rd_rtt, peer.X.rd, peer.X.flow_agents, rd.X.community.local.
- Possible values:
X:Y - Default value:
65535:1
4.4.26 bgpd.retry_probing.new.bmp_path_change #
Defines on what new provider AS Path changes to re-probe an already improved prefix. The possible options are:
- 0: Disabled
- 1: On major AS-Path change
- 2: On any AS-Path change
Major AS Path changes are those traversing a different set of Autonomous Systems. AS Path changes such as prepended ASN are ignored when only major AS Path changes are monitored.Refer also to bgpd.retry_probing.new.bmp_path_change, peer.X.bmp.
- Possible values:
0-2 - Default value:
0
4.4.27 bgpd.retry_probing.old.bmp_path_change #
Defines on what old provider AS Path changes to re-probe an already improved prefix. The possible options are:
- 0: Disabled
- 1: On major AS-Path change
- 2: On any AS-Path change
Major AS Path changes are those traversing a different set of Autonomous Systems. AS Path changes such as prepended ASN are ignored when only major AS Path changes are monitored.Refer also to bgpd.retry_probing.new.bmp_path_change, peer.X.bmp.
- Possible values:
0-2 - Default value:
0
4.4.28 bgpd.scaninterval #
The interval in seconds between the execution of the BGP Scan process.
BGP scan is used for:
- checking the improvements belonging to aggregated routes
- checking the improvements for aggregate withdrawn (bgpd.improvements.remove.withdrawn) and for aggregate next-hop equal to improvements next-hop (bgpd.improvements.remove.next_hop_eq) conditions
- checking the improvements for changed BGP attributes
- checking for changes for the improvements to be announced to/withdrawn from iBGP neighbors
- Possible values:
10-600its not recommended to set value higher than 60 seconds - Default value:
20
4.4.29 bgpd.snmp.packets_interval #
Time interval in miliseconds between transit improvement’s monitor SNMP packets. Refer Optimization of transiting traffic, Optimization of transiting traffic.
- Possible values:
1-100 - Default value:
10
4.4.30 bgpd.snmp.simultaneous #
The number of the simultaneous PDUs that will be contained in a SNMP request.
- Possible values:
1-300 - Default value:
10 - Recommended value:
10
4.4.31 bgpd.transit.monitor.election_interval #
Transit monitor election interval as a factor of reconfirm intervals. Refer bgpd.transit.monitor.fast_reconfirm_interval.
- Possible values:
1-10 - Default value:
4
4.4.32 bgpd.transit.monitor.fast_reconfirm_interval #
Transit monitor fast reconfirm interval in seconds. The reconfirm interval sets the periodicity by which transit monitors verify presence of alternative routes from other providers for transit improvements.
- Possible values:
1-60 - Default value:
15
4.4.33 bgpd.transit.monitor.retries #
Number of SNMP retries before a timeout of transit improvement’s monitor. Refer Optimization of transiting traffic, Optimization of transiting traffic.
- Possible values:
1-2000 - Default value:
3
4.4.34 bgpd.transit.monitor.timeout #
Timeout in miliseconds of individual SNMP requests used to monitor transit improvements. Refer Optimization of transiting traffic, Optimization of transiting traffic.
- Possible values:
1-10000 - Default value:
1000
4.4.35 bgpd.updates.split #
Instructs Bgpd to split advertised prefixes in two equal parts (e.g /24 is split into two /25 prefixes).
This parameter should be enabled in order to preserve the original BGP UPDATE attributes received from the corresponding aggregates.
If this option is enabled, the number of announced prefixes will be twice the core.improvements.max.If the bgpd.peer.X.updates.limit.max parameter value is established, then the limitation is set on the total amount of announced prefixes, AFTER split. For example, if the value of core.improvements.max is set to 10000 and bgpd.peer.X.updates.limit.max is set to 5000, then the amount of the improvements towards this particular provider is no more than 2500, split onto 5000.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1