In recent years, the concepts of Artificial Intelligence (AI) and Machine Learning (ML)...
4.8 Core settings
4.8.1 core.circuit.high_loss_diff #
Defines the upper threshold of consistent packet loss over a provider when compared to other providers on the network. A provider exceeding this threshold is marked for shutdown. An event of this type will be raised and available to subscribers to act upon. Threshold loss difference is determined over a configured past time horizon and compared with all other providers on the network over the same interval.
While the provider is marked for shutdown IRP cannot do this itself. Instead network engineers and/or other network capabilities are expected to be triggered in order to divert as much traffic as possible away from provider with circuit issues.- Possible values:
2-50 - Default value:
15
4.8.2 core.circuit.hist_interval #
Defines time interval in minutes used to determine average packet loss over a provider when compared to other providers on the network for circuit issues detection algorithm.
Keep in mind that shorter time intervals might cause false positives where the averages are high simply because a few large and random packet loss probes are able to push the numbers above thresholds. At the same time longer time intervals will take longer to spot issues and thus will extend the time period where a circuit with issues is being used while alternatives were available.- Possible values:
1-240 - Default value:
5
4.8.3 core.circuit.inbound #
Defines if and when IRP announces Max prepends for inbound prefixes through provider with circuit issues. The options are as follows:
→ No changes – any prepends through provider are not changed
→ Prepend on warn – IRP announces Max Prepends once Warning level for circuit issues is reached
→ Prepend on shutdown – IRP announces Max Prepends only when shutdown level for circuit issues is exceeded.
Refer also core.circuit.transit.
- Possible values:
0 (No changes), 1 (Prepend on warn), 2 (Prepend on shutdown) - Default value:
0
4.8.4 core.circuit.recover_hold_time #
Defines the time interval in seconds before IRP attempts to restore a circuit with issues.
- Possible values:
60-3600 - Default value:
600
4.8.5 core.circuit.recover_loss_diff #
Defines the normal threshold of packet loss when a provider with circuit issues can be considered to be ok. At this stage IRP will restore the provider to its full capacity status and will retract all other measures taken in the past in order for the network traffic to avoid the circuit with issues.
This parameter is only used if the ways to react to a circuit issue include restoring it and this only can happen within the given time interval. Otherwise the circuit should be restored by manual intervention of network engineers after they have verified the issue is no longer a problem.
Note that this parameter should be both smaller than core.circuit.high_loss_diff and core.circuit.warn_loss_diff- Possible values:
0-48 - Default value:
5
4.8.6 core.circuit.recover_monitored_intervals #
Defines the time interval in minutes during which IRP will continuously evaluate average loss for provider(s) with circuit issues in order to determine if it is back to normal.
This parameter is only used if the ways to react to a circuit issue include restoring it and this only can happen within the given time interval. Otherwise the circuit should be restored by manual intervention of network engineers after the circuit issue is no longer a problem.- Possible values:
1-30 - Default value:
5
4.8.7 core.circuit.transit #
Defines if and when IRP announces Max prepends for transit prefixes through provider with circuit issues. The options are as follows:
→ No changes – any prepends through provider are not changed
→ Prepend on warn – IRP announces Max Prepends once Warning level for circuit issues is reached
→ Prepend on shutdown – IRP announces Max Prepends only when shutdown level for circuit issues is exceeded.
Refer also core.circuit.inbound.
- Possible values:
0 (No changes), 1 (Prepend on warn), 2 (Prepend on shutdown) - Default value:
0
4.8.8 core.circuit.warn_loss_diff #
Defines the lower threshold of packet loss when a provider seems to be having circuit issues. At this stage IRP will start raising alerts that network engineers and/or network management systems can subscribe in order to act on them. At this level IRP starts taking other preventive measures such as re-probing outbound improvements made to provider with circuit issues.
Note that this parameter should be both smaller than core.circuit.high_loss_diff and larger than core.circuit.recover_loss_diff.- Possible values:
1-49 - Default value:
10
4.8.9 core.circuit.withdraw_on_warn #
Enables or disables withdrawing outbound improvements to a provider with circuit issues at or above warning level.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.8.10 core.commit_control #
Enables or disables Commit Control (see the Commit Control section)
The following parameters must be set in the configuration file to ensure proper functionality of the Commit Control feature:- SNMP parameters must be set for each provider:
→ SNMP Host
→ peer.X.snmp.interfaces
- Each provider needs to have peer.X.95th set to the desired Commit level
- peer.X.precedence must be set for each provider
When Commit Control is disabled, all existing Commit Control improvements are removed from current improvements. The improvements are preserved temporarily until core.commit_control.probe_ttl after Core service restart. If Commit Control is re-enabled before expiration these improvements will be restored into current improvements.
See also:
Commit Control
core.commit_control.rate.group
core.commit_control.rate.high
core.commit_control.rate.low
Commit Control
core.commit_control.rate.group
core.commit_control.rate.high
core.commit_control.rate.low
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.8.11 core.commit_control.agg_bw_min #
Defines the minimum bandwidth for a single prefix. Prefixes, whose bandwidth is less than the specified value, are ignored by Commit Control and are not being used in the Commit Control algorithm.
It is not recommended to set high values for this parameter since it limits the number of prefixes that can be rerouted by the Commit Control mechanism.This parameter is considered only during initial improvement. During retry probing of existing Commit Control improvements IRP might detect that the current bandwidth usage for some prefixes is below this limit. IRP will preserve these improvements as relevant if there are no other reasons to withdraw them.Its recommended to decrease value if summary throughput is lower than 200-500 Mbps.
- Possible values:
0.1-5000 - Default value:
1 - Recommended value:
1
4.8.12 core.commit_control.del_irrelevant #
If enabled, Commit Control algorithm deletes improvements that have traffic volume less than value in the core.commit_control.agg_bw_min parameter.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1 - Recommended value:
1
4.8.13 core.commit_control.group_balance.check_monitor #
Defines how monitors affect group load balancing.
Group load balance will include providers in a group only when a provider has no failed monitors.
- 0 Ignores monitors
- 1 Excludes providers with failed IPv4 monitor
- 2 Excludes providers with any failed monitor
- Possible values:
0-2 - Default value:
0
4.8.14 core.commit_control.inbound.enabled #
Enables or disables Inbound bandwidth control.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.8.15 core.commit_control.inbound.improvement.delay #
The parameter specifies minimal time delay before next Inbound/Transit optimization cycle.
Time delay should be sufficient to cover route propagation time and time required to collect and process changes in bandwidth distribution.
- Possible values:
60-1800 - Default value:
300
4.8.16 core.commit_control.inbound.moderated #
Enables or disables review and moderate feature of inbound bandwidth control.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.8.17 core.commit_control.inbound.rate.high #
Defines provider’s high load rate limit (%). Refer core.commit_control.rate.high for details.
This limit is used when inbound and outbound commit control operate independently. Otherwise core.commit_control.rate.high value overrides this. Refer also peer.X.95th.mode.
- Possible values:
50-99 - Default value:
90
4.8.18 core.commit_control.inbound.rate.low #
Defines provider’s low load rate limit (%). Refer core.commit_control.rate.low for details.
This limit is used when inbound and outbound commit control operate independently. Otherwise core.commit_control.rate.low value overrides this. Refer also peer.X.95th.mode.
- Possible values:
30-99 - Default value:
70
4.8.19 core.commit_control.inbound.sync_groups #
Synchronous Inbound Provider Groups allows for the Inbound Commit Control decisions to be applied simultaneously to all the providers within the group. The number of applied prepends for a single
provider would propagate to all the providers in the group.
Typical use case: When providers are in the same autonomous system, prepending prefixes via a single provider leads to a complete traffic shift to another one, potentially overloading the link. Arrange all the providers within a given ASN into a group to apply the same amount of prepends for each provider.
A group consists of provider IDs separated by double colons. Groups in the parameter should be separated by spaces.
provider would propagate to all the providers in the group.
Typical use case: When providers are in the same autonomous system, prepending prefixes via a single provider leads to a complete traffic shift to another one, potentially overloading the link. Arrange all the providers within a given ASN into a group to apply the same amount of prepends for each provider.
A group consists of provider IDs separated by double colons. Groups in the parameter should be separated by spaces.
It is not recommended to set high values for this parameter since it limits the number of prefixes that can be rerouted by the Commit Control mechanism.
4.8.20 core.commit_control.inbound.volume_estimation #
Defines method of estimating inbound bandwidth. The available options are:
0: Last minute data
1: Largest of last minute and current hour average
2: Largest of last minute and daily average
- Possible values:
0-2 - Default value:
1
4.8.21 core.commit_control.loss_override #
Defines when IRP allows Commit Control improvements to adjust a provider’s bandwidth considering current and new provider’s loss measurements. The available options are to allow Commit Control improvements when there is:
0: Better or equal loss
1: Better or irrelevant loss difference
2: Any loss difference
Refer core.performance.loss_pct for details.
- Possible values:
0-2 - Default value:
0
4.8.22 core.commit_control.probe_ttl #
Defines the TTL (time-to-live) for a specific probe. If the probe results are older than the value specified here, the system will disregard it and the Commit Control algorithm will schedule it for expedited re-probing.
- Possible values:
600-86400 - Default value:
7200 - Recommended value:
7200
4.8.23 core.commit_control.probing_queue_size #
Defines the number of slots in the probing queue that can be used by the Commit Control algorithm. This sets the upper limit on the number of prefixes that can be scheduled for probing by Commit Control. Note that this queue has higher priority than ordinary and retry probing. At the same time Commit Control relies heavily on existing probing results and most of the time this queue will be empty.
- Possible values:
1-500 - Default value:
100 - Recommended value:
10-100
4.8.24 core.commit_control.rate.group #
If using provider load balancing in group, this parameter defines allowed deviation of a provider’s current bandwidth(in %) compared with other providers in the same group.
Example 1. There are three grouped providers with 95th set to 1 Gbps, 2 Gbps and 3 Gbps with a total current bandwidth of 600 Mbps. In this case, load balancing expects that each provider’s bandwidth usage will be 100 Mbps, 200 Mbps and 300 Mbps accordingly. These values are proportional to individual provider’s 95th settings in the group. Let’s assume core.commit_control.rate.group is set to 5%. If a provider’s bandwidth exceeds by more than the 5% limit the expected value (105 Mbps, 210 Mbps and 315 Mbps accordingly and the total for the group did not change), IRP will start active rerouting of excessive bandwidth from that provider to providers within or outside this group.
Load balancing in a provider group is performed even when the 95th is not exceeded.- Possible values:
1-30 - Default value:
5 - Recommended value:
5
See also: Provider load balancing
4.8.25 core.commit_control.rate.high #
Defines provider’s high load rate limit (%).
IRP will stop Latency/Cost improvement if provider bandwidth is over core.commit_control.rate.high % of load (percents of 95th). The improvements will start happening again after provider’s bandwidth drops below core.commit_control.rate.low % of load.
IRP will stop Latency/Cost improvement if provider bandwidth is over core.commit_control.rate.high % of load (percents of 95th). The improvements will start happening again after provider’s bandwidth drops below core.commit_control.rate.low % of load.
These parameters are used for passive 95th overload prevention as well as an additional method for Commit Control to be less aggressive.
Provider’s Latency/Cost improvement ability does not change when current bandwidth rate varies between core.commit_control.rate.low and core.commit_control.rate.high.Example 2. if provider’s current load is 1100 Mbps, 95th is set to 1000 Mbps. Commit Control will try to unload 200Mbps (to reduce current load to 90% of the 95th level) in order to prevent 95th overload as well as allow provider’s bandwidth natural growth during peak hours.
See also: Provider load balancing
- Possible values:
50-99, but larger or equal to core.commit_control.rate.low - Default value:
90 - Recommended value:
90
4.8.26 core.commit_control.rate.low #
Defines provider’s low load rate limit (%).
IRP will start Latency/Cost improvements again after provider’s bandwidth drops below core.commit_control.rate.low % of load. Latency/Cost improvements will be stopped if provider bandwidth is over core.commit_control.rate.high % of load (percents of 95th).
IRP will start Latency/Cost improvements again after provider’s bandwidth drops below core.commit_control.rate.low % of load. Latency/Cost improvements will be stopped if provider bandwidth is over core.commit_control.rate.high % of load (percents of 95th).
These parameters are used for passive 95th overload prevention as well as an additional method for Commit Control to be less aggressive.
Provider’s Latency/Cost improvement ability does not change when current bandwidth rate varies between core.commit_control.rate.low and core.commit_control.rate.high.See also: Provider load balancing
- Possible values:
30-99, but lower or equal to core.commit_control.rate.high - Default value:
80 - Recommended value:
80
4.8.27 core.commit_control.react_on_collector #
Defines if Commit Control algorithm should react immediately on collector overload values.
Enabling this feature represents a tradeoff. Take into consideration the benefits of a faster react time vs reliance on older probes and statistics when making Commit Control improvements.- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1 - Recommended value:
1
4.8.28 core.commit_control.worst_loss #
Defines amount of loss worsening allowed when IRP performs Commit Control improvements and core.commit_control.loss_override is set to “Any loss difference”.
Refer core.performance.loss_pct for details.
- Possible values:
1-99 - Default value:
2
4.8.29 core.cost.worst_ms #
Latency worsening.
Defines the allowed latency worsening for an improved prefix while running in Cost optimization mode (see global.improve_mode) and the Commit Control feature is enabled. While operating in these modes IRP will consider as alternatives candidates with latency degradation not exceeding this limit. Of course, the candidate with least latency degradation or even with better latency will be chosen as an improvement.
When IRP detects that an existing Commit Control improvement has alternatives with latencies better than specified value it will replace it with a new performance (latency) improvement. Over-usage of the alternative route will be avoided.
This parameter is applicable for local improvements within a Routing Domain. Global improvements will also take into account core.global.worst_ms values.- Possible values:
1-1000000 - Default value:
10 - Recommended value:
10
4.8.30 core.eventqueuelimit #
Defines the exploring events queue size for IPv4 prefixes.
Lower values may result in IRP missing some important network issues.
- Possible values:
1-10000 - Default value:
1000 - Recommended value:
500-2000
4.8.31 core.eventqueuelimit.retry_probe_pct #
Defines a percentage of the total exploring queue length (see core.eventqueuelimit) to be used for retry probing.
- Possible values:
1-100 - Default value:
40 - Recommended value:
20-60
4.8.32 core.eventqueuelimit_ipv6 #
Defines the exploring events queue size for IPv6 prefixes.
Lower values may result in IRP missing some important network issues.
- Possible values:
1-10000 - Default value:
1000 - Recommended value:
500-2000
4.8.33 core.flowspec.max #
Defines the maximum number of IPv4 Flowspec rules that IRP is allowed to advertise.
Routers have a low limit of FlowSpec entries. If the limit is exceeded, the router behavior may be unpredictable.- Possible values:
1-20000 - Default value:
100
4.8.34 core.flowspec.max_ipv6 #
Defines the maximum number of IPv6 Flowspec rules that IRP is allowed to advertise.
Routers have a low limit of FlowSpec entries. If the limit is exceeded, the router behavior may be unpredictable.- Possible values:
1-20000 - Default value:
100
4.8.35 core.global.allow_commit #
Enables or disables global commit control Improvements in a multiple routing domain configuration. By default these Improvements are enabled.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1
4.8.36 core.global.allow_latency_cost #
Enables or disables latency and cost global Improvements in a multiple routing domain configuration. By default these Improvements are enabled.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1
4.8.37 core.global.worst_ms #
Defines acceptable latency worsening for cost and commit for global improvements.
Refer core.cost.worst_ms
- Possible values:
1-1000000 - Default value:
30 - Recommended value:
10
4.8.38 core.improvements.clearslots #
Specifies the number of outdated improvements that will be discarded when slots are needed for new improvements. Outdated are improvements as defined by core.improvements.clearslots.days_max. In case there are no outdated improvements usual improvement replacement mechanisms are employed relying on Improvements weight.
- Possible values:
0-100 - Default value:
10 - Recommended value:
10
4.8.39 core.improvements.clearslots.days_max #
Sets the number of days after which an improvement is considered outdated. Outdated improvements have not been re-confirmed for a long time. The oldest of them will be discarded by the slot clearing process for outdated improvements when new slots are needed for new improvements. Refer core.improvements.clearslots.
- Possible values:
1-60 - Default value:
7 - Recommended value:
7
4.8.40 core.improvements.inbound_transit.max #
Specifies the maximum number of transit improvements. Refer Optimization of transiting traffic, Optimization of transiting traffic.
Increasing this limit should be done with care. Each transit improvement is continuously monitored if alternative routes from providers are still present on the router(s) and this consumes router CPU resources.- Possible values:
1-1000 - Default value:
100
4.8.41 core.improvements.inbound_transit.ttl.clean #
Specifies how IRP should treat old transit improvements.
Old transit improvements are those that exceed core.improvements.inbound_transit.ttl.max.
The options are to either
- gradually decrease the number of prepends and withdraw the transit improvement when no prepends are left or
- withdraw the inbound transit improvement immediately when it exceeds core.improvements.inbound_transit.ttl.max.
Transit improvements cleanup performed once a day at configured off-peak hour (global.offpeak_hour).- Possible values:
0 (Decrease prepends), 1 (Remove immediately) - Default value:
0
4.8.42 core.improvements.inbound_transit.ttl.max #
Specifies the maximum period of time to preserve a transit improvement. If IRP does not have any other reasons to adjust a transit improvement after this limitation is exceeded its prepends will be decreased or the improvement will be withdrawn. Refer core.improvements.inbound_transit.ttl.clean, Optimization of transiting traffic, Optimization of transiting traffic.
- Possible values:
901-345600 - Default value:
86400
4.8.43 core.improvements.inbound_transit.ttl.min #
Specifies the minimal period of time to preserve a transit improvement. In order to give sufficient time to the entire Internet to adjust to a transit improvement and to avoid route instability IRP blocks making changes to a transit improvement for this duration of time. IRP can still offer route changes to the same transit prefixes routed through other providers. Refer Optimization of transiting traffic, Optimization of transiting traffic.
- Possible values:
600-86400 - Default value:
14400
4.8.44 core.improvements.max #
Defines the maximum number of active IPv4 improvements.
The number of announced prefixes can be twice this value if bgpd.updates.split is enabled.- Possible values:
1-100000 - Default value:
10000 - Recommended value:
10000
4.8.45 core.improvements.max_ipv6 #
Defines the maximum number of active IPv6 improvements.
- Possible values:
0-100000 - Default value:
2000 - Recommended value:
2000
4.8.46 core.improvements.safe_removal #
Specifies when IRP removes/withdraws outbound improvements. Outbound improvements become irrelevant if old provider performance metrics are no longer worse than the improved provider metrics. Still, original routes for some improvements change and providers that will service those prefixes once IRP improvements are withdrawn might have worse performance metrics. Safe improvement removal accounts for this possibility and removes improvements only when ALL providers have performance metrics that are not worse than the (fresh) improvement provider metrics.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.8.47 core.improvements.ttl.retry_probe #
Defines the retry probing interval (in seconds). Once an improvement is older than this value, it will be sent for re-probing.
- Possible values:
600-86400 - Default value:
14400 - Recommended value:
7200-14400
4.8.48 core.log #
Defines the file-system path to the core log file.
- Default value:
/var/log/irp/core.log
4.8.49 core.log.level #
Defines the logging level for the core service.
- Possible values:
emerg, fatal, alert, crit, error, warn, notice, info, debug, trace - Default value:
info - Recommended value:
info
4.8.50 core.outage_detection #
Enables the Outage Detection algorithm.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0 - Recommended value:
1
4.8.51 core.outage_detection.limit_pct #
Defines the problem prefixes threshold (in percent) over which the system confirms an outage (if core.outage_detection is enabled).
See also: Outage detection
- Possible values:
0-100 - Default value:
60
4.8.52 core.outage_detection.volume_top_n #
Top-N relevant volume prefixes
The outage detection mechanism considers only those prefixes in the “Top N by volume.” Separately for IPv4 and IPv6.
- Possible values:
1-20000 - Default value:
5000
4.8.53 core.overusage.check_interval #
Defines the interval to check overusage for Flowspec policies prefixes in order to apply automatic throttling Flowspec policies.
- Possible values:
60-600 - Default value:
60 - Recommended value:
60
4.8.54 core.overusage.hold_timer #
Defines the retention time for throttling rules after prefix average bandwidth returns to normal for automatic throttling Flowspec policies.
- Possible values:
60-600 - Default value:
60 - Recommended value:
300
4.8.55 core.overusage.out.average.period #
Defines the duration of the time interval in hours used to determine average prefix usage for automatic throttling Flowspec policies.
- Possible values:
1-24 - Default value:
1 - Recommended value:
1
4.8.56 core.overusage.out.average.relevant_min #
Defines minimum prefix bandwidth average (in Mbps) that is relevant for automatic throttling Flowspec policies.
- Possible values:
1-100000 - Default value:
50 - Recommended value:
50
4.8.57 core.overusage.out.threshold.throttle #
Defines the multiplier of prefix average bandwidth applied on outbound traffic for automatic throttling Flowspec policies.
- Possible values:
2-10000 - Default value:
2 - Recommended value:
2
4.8.58 core.overusage.out.threshold.trigger #
Defines the multiplier of prefix average bandwidth that sets the overusage threshold of a prefix. An automatic throttling Flowspec policy is created when current prefix bandwidth exceeds the average multipled by this multiplier.
- Possible values:
2-10000 - Default value:
10 - Recommended value:
10
4.8.59 core.performance.loss_pct #
Defines the relevant packet loss difference (in percent) after which a loss improvement is made.
For current route loss > 50%: Do not perform rerouting, if packet loss difference between routes is less than 15%.
For current route loss <= 50%: Do not perform rerouting, if packet loss difference between routes is less than core.performance.loss_pct.
- Possible values:
1-15 - Default value:
3 - Recommended value:
3-5
4.8.60 core.performance.rtt.diff_ms #
Defines the relevant RTT difference (ms) after which a latency improvement is made. If the RTT difference between the current route and another provider is less than core.performance.rtt.diff_ms, then the system ignores this prefix as an improvement candidate or removes the current improvement as irrelevant during the improvement reconfirmation process.
core.performance.rtt.diff_ms and core.performance.rtt.diff_pct are grouped together at decision making, using a logical AND condition.- Possible values:
1-1000000 - Default value:
10 - Recommended value:
2-20
4.8.61 core.performance.rtt.diff_pct #
Defines the relevant RTT difference (in percent) after which a latency improvement is made. If the RTT difference between the current route and another provider is less than core.performance.rtt.diff_pct, then the system ignores this prefix as an improvement candidate or removes the current improvement as irrelevant during the improvement reconfirmation process.
core.performance.rtt.diff_ms and core.performance.rtt.diff_pct are grouped together at decision making, using a logical AND condition.- Possible values:
1-100 - Default value:
10 - Recommended value:
5-20
4.8.62 core.performance.rtt.ix_diff_ms #
Defines the relevant RTT difference (ms) to make latency improvements across Internet Exchanges and transit providers. A latency improvement from an IX to a transit provider is allowed only when the latency is improved by at least this threshold. Inversely, a latency improvement from a transit provider to an IX is allowed even if latency degradation is less thanthis threshold.
A default value of zero for this parameter disables this feature. A value smaller than or equal to core.performance.rtt.diff_ms isn’t allowed. When the feature is disabled then the core.performance.rtt.diff_ms and core.performance.rtt.diff_pct parameters are considered to determine relevancy of latency improvements.core.performance.rtt.ix_diff_ms and core.performance.rtt.ix_diff_pct are grouped together at decision making, using a logical AND condition.- Possible values:
0-1000000 - Default value:
0 - Recommended value:
20-50
4.8.63 core.performance.rtt.ix_diff_pct #
Defines the relevant RTT difference (in percent) to make latency improvements across Internet Exchanges and transit providers. Refer core.performance.rtt.ix_diff_ms for details.
core.performance.rtt.ix_diff_ms and core.performance.rtt.ix_diff_pct are grouped together at decision making, using a logical AND condition.- Possible values:
1-100 - Default value:
10 - Recommended value:
5-20
4.8.64 core.probes.ttl.failed #
Defines the failed probe lifetime (in seconds).
Regular and Retry probing will not be performed until the age of the failed probe is less than core.probes.ttl.failed
- Possible values:
120-14400 - Default value:
300 - Recommended value:
300
4.8.65 core.probes.ttl.max #
Defines the probe lifetime (in seconds).
Probed prefixes data is kept in the IRP database for the specified amount of time. Automatic cleanup of outdated data is performed periodically by Dbcron.
See also: Administrative Components
High values will lead to database size growth.
- Possible values:
86400-604800 - Default value:
86400 - Recommended value:
86400
4.8.66 core.probes.ttl.min #
Defines the relevant probe lifetime (in seconds)
Ordinary probing will not be performed for a specific prefix if its probe age is less than core.probes.ttl.min.
- Possible values:
300-43200 - Default value:
7200 - Recommended value:
1800-14400
4.8.67 core.problem.outage_timeout #
Outage detection timeout (in seconds).
The IRP will disregard a possible outage, if it was not confirmed during last core.problem.outage_timeout.
- Possible values:
60-3600 - Default value:
600
See also: core.outage_detection
4.8.68 core.problem.rtt.diff_pct #
Defines the RTT difference (in percent) between the current route and the new route, for Outage detection algorithm. IRP will choose a new route for problematic prefixes only if the RTT difference (in percent) is greater than this parameter.
- Possible values:
1-100 - Default value:
50 - Recommended value:
30-60
4.8.69 core.vip.interval.probe #
Defines the VIP prefixes probing interval, in seconds.
All networks and ASNs specified in
/etc/noction/policies.conf and will be queued for priority probing every core.vip.interval.probe seconds.For probing intervals lower than 5 minutes (300 seconds) IRP uses fast probing algorithms avoiding for example long lasting tracing.See also: VIP Improvements
- Possible values:
60-14400 - Default value:
3600