IRP Installation and Configuration Guide

IRP Installation and Configuration Guide

4 Configuration parameters reference

4.1 Complete parameters list

4.1.1 Common database credentials

db.port - TCP port number used for my MySQL database.
db.host - Database host. MySQL server host name or IPv4/IPv6 address.
db.ourhost - IRP host. IRP box host name or IPv4/IPv6 address.
db.username - Database login. Credentials for IRP database.
db.password - Password for database access.
db.dbname - Name of database that holds the IRP tables.


4.1.2 Global parameters

4.1.2.1 global.aggregate

If this parameter is ON IRP analyzes entire aggregates. When one can be improved the aggregate will be announced by BGPd (refer to bgpd.updates.split↓, bgpd.peer.X.updates.limit.max↓). Largest possible prefixes are used when aggregates exceed global.agg_ipv4_max↓ & global.agg_ipv6_max↓ parameters for IPv4 and IPv6 accordingly. An aggregate dictionary is maintained by IRP in order to support this capability. The aggregate dictionary is periodically populated by refresh_asn or BGPd (if BGPd has sufficient information, by means of at least one full-view BGP peering session).
Disabling this parameter instructs IRP to operate with the smallest possible disaggregated prefixes (/24 for IPv4 and /48 IPv6).
Switching this parameter ON/OFF might leave a large number of small prefixes in the aggregate dictionary with undesirable side effects. The contents of the dictionary should be reviewed and refreshed in case it lists undesirable prefixes. To prevent issues IRP improvements should be cleared before applying this change. Clearing improvements ensures that disaggregated prefixes announced by IRP are not present on the network.
Possible values: 0 (OFF), 1 (ON)
Default value: 1

4.1.2.2 global.bw_overusage

Enables or disables automatic Flowspec throttling policies for prefixes with excessive bandwidth spikes.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.2.3 global.agg_ipv4_max

Defines the maximum IPv4 aggregate mask for the improved prefixes advertised by BGPd. If global.aggregate↑ is enabled, IRP will not announce any prefix with the mask that’s less than the mask defined in global.agg_ipv4_max↑.
Possible values: 8-24
Default value: 16

4.1.2.4 global.agg_ipv6_max

Defines the maximum IPv6 aggregate mask for the improved prefixes advertised by BGPd. If global.aggregate↑ is enabled, IRP will not announce any prefix with the mask that’s less than the mask defined in global.agg_ipv6_max↑.
Possible values: 32-48
Default value: 32

4.1.2.5 global.exchanges

Defines the path to the Exchanges configuration file.
Default value: /etc/noction/exchanges.conf
Recommended value: /etc/noction/exchanges.conf

4.1.2.6 global.exchanges.auto_config_interval

Defines the Internet Exchanges auto re-configuration interval in seconds. Auto re-configuration is applied to providers of type Internet Exchange with enabled auto re-configuration. Refer peer.X.auto_config↓.
Possible values: 3600-2678400
Default value: 86400

4.1.2.7 global.failover

Enables and disables failover feature.
Enabling failover requires extensive preparatory activities. Refer IRP Failover↑, Failover configuration↑, Setup Failover wizard ↑ for details.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.2.8 global.failover.log

Path to failover log file.
Default value: /var/log/irp/failover.log

4.1.2.9 global.failover_identity_file

Defines the path to failover master identity file. Set this parameter only when a SSH key file other than ~/.ssh/id_rsa is used. Refer global.failover↑.
Possible values: Path to identity file

4.1.2.10 global.failover_role

Defines the role of the IRP instance in a failover configuration. Known roles are Master and Slave. Used only when failover is enabled. Refer global.failover↑.
Possible values: 0 (Master), 1 (Slave)
Default value: 0

4.1.2.11 global.failover_slave.ip

Defines the IPv4 address of the slave IRP instance used for configuration sync in a failover configuration. Used only when failover is enabled. Refer global.failover↑.
Possible values: Valid IPv4 address
Example value: 10.10.0.2

4.1.2.12 global.failover_slave.ipv6

Defines the IPv6 address of the slave IRP instance used for configuration sync in a failover configuration. Used only when failover is enabled. Refer global.failover↑.
Possible values: Valid IPv6 address
Example value: 2001:db8::ff00:42:8329

4.1.2.13 global.failover_slave.port

Defines the SSH port of the slave node in a failover configuration. Used only when failover is enabled.
See also global.failover↑.
Possible values: 1-65535 (Valid port number)
Default value: 22

4.1.2.14 global.failover_timer_fail

Defines the period of time in seconds during which master is considered alive before the slave becomes active in a failover configuration. Used only when failover is enabled.
See also global.failover↑.
Possible values: 30-3600
Default value: 300

4.1.2.15 global.failover_timer_failback

Defines the period of time in seconds for slave to switch back to standby after it detects master became alive in a failover configuration. Used only when failover is enabled.
See also global.failover↑.
Possible values: 30-3600
Default value: 300

4.1.2.16 global.flowspec

Enables/disables Flowspec capability globally.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.2.17 global.flowspec.pbr

Enables/disables use of Flowspec policies instead of Policy Based Routing. This is available only when Flowspec is enabled. Refer global.flowspec↑.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.2.18 global.frontend_acl

Defines whether access to the IRP Frontend must be restricted and controlled by an ACL. See also global.frontend_acl_ips↓.
Possible values: 0 (OFF), 1 (ON)
Default value: 0

4.1.2.19 global.frontend_acl_ips

Defines the IPs or networks that should be allowed to access the IRP Frontend.
Possible values: Valid IPv4, IPv6 address or subnet definition in CIDR format
Default value: 0/0 ::/0

4.1.2.20 global.ifstats

Defines whether interface statistics should be collected by Irpstatd or IRP collectors.
Starting with IRP 3.8 IRP collector(s) can retrieve interface aggregated statistics. This is designed to simplify IRP by reducing its number of components (Irpstatd is being considered for deprecation) and to address measurement discrepancies issues caused by collecting detailed and aggregated data by means of separate processes (Collector(s) and Irpstatd). To preserve backwards compatibility old behavior is preserved by default. This will change in future releases.
Possible values: 0 (Irpstatd), 1 (Collector)
Default value: 0

4.1.2.21 global.ignored.asn

Defines the list of ASNs to be ignored by IRP.
Format:
  1. Space-separated list of AS numbers that must be ignored by IRP.
  2. Absolute path to a newline-separated file containing a list of AS numbers that must be ignored by IRP.
This parameter should list all AS numbers that must be ignored by Irpspand, Irpflowd, Explorer and the Core. No improvements will be performed by the Core for prefixes that are announced by ASNs listed within this parameter. No data will be gathered by Irpspand/Irpflowd for any source or destination IPv4/IPv6 address that are announced by ASNs that are listed within this parameter. No probes will be sent by Explorer to any destination IPv4/IPv6 address that are announced by ASNs listed within this parameter.
Possible values: 1 - 4294967295.

4.1.2.22 global.ignored_communities

Defines the list of BGP Community attributes the network uses to mark prefixes that IRP must ignore. IRP monitors routes marked with at least one of these BGP Community attributes and dynamically updates a list of prefixes to ignore. The decision what prefixes to mark with one of these attributes is applied on the network and network operators do not need to be explicitly set in IRP too.
This (dynamic) list of prefixes will be ignored by Irpspand, Irpflowd, Explorer and the Core. No improvements will be performed by the Core for such prefixes. No data will be gathered by Irpspand/Irpflowd for any source or destination IPv4/IPv6 address within such prefixes. No probes will be sent by Explorer to any destination IPv4/IPv6 address within such prefixes.
Possible values: valid BGP community attribute list.

4.1.2.23 global.ignorednets

Defines the list of networks to be ignored by IRP.
Format:
  1. Space-separated list of local IPv4/IPv6 prefixes that should be ignored by IRP.
  2. Absolute path to a newline-separated file containing a list of IPv4/IPv6 prefixes that should be ignored by IRP.
If netmask is not clearly specified, the system assumes /32 for IPv4 addresses, and /128 for IPv6 addresses.
224.0.0.0/3 is always ignored.
- IPv6 probing is performed only to 2000::/3 address range (see: IPV6 Address Space)
- All IPv4/IPv6 addresses assigned to IRP server are automatically added to ignored networks
This parameter lists all IPv4/IPv6 addresses that should be ignored by Irpspand, Irpflowd, Explorer and the Core. No improvements will be performed by the Core for /24 subnets listed within this parameter as /24 or a less specific network. No data will be gathered by Irpspand/Irpflowd for any source or destination IPv4/IPv6 address listed within this parameter. No probes will be sent by the Explorer to any destination IPv4/IPv6 address listed within this parameter.
Possible values: See above.
Default value: 127.0.0.0/8 10.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.168.0.0/16 100.64.0.0/10 203.0.113.0/24 198.18.0.0/15 192.0.0.0/24 192.0.2.0/24 2001:db8::/32
Recommended value: See default value.
Recommended networks to ignore are:
- networks from: Section 3 of RFC5735, as listed in the default value above
- networks from: Section 2 of RFC3849

4.1.2.24 global.improve_mode

Defines the IRP operating mode (see IRP Optimization modes↑).
This parameter adjusts the priorities and rules for prefix improvements. Prefixes can be improved in three different ways:
  1. Performance optimization↑: Decrease loss, then decrease latency;
  2. Cost optimization↑: Decrease loss, then decrease cost while keeping the latency within the preconfigured level;
Loss, cost and latency are improved in strict order, depending on the selected operating mode.
Possible values: 1, 2 (see above).
Default value: 1

4.1.2.25 global.inbound_conf

Defines path to file with configured inbound prefixes.
Possible values: path to file
Default value: /etc/noction/inbound.conf
Recommended value: /etc/noction/inbound.conf

4.1.2.26 global.inbound_transit

Enables or disables inbound optimization of transiting traffic. Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
Possible values: 0 (Disable), 1 (Enable)
Default value: 0

4.1.2.27 global.ipv6_enabled

Defines whether IPv6 is enabled in the system. Currently used for the Frontend only. Even if IPv6 is enabled via this parameter, other components configuration must be adjusted for IPv6 as well.
IRP prior to 3.3-2 allows configuration of both IPv4 and IPv6 sessions on a single router, while IRP 3.3-2 requires definition of two separate BGP sessions. It is recommended to split BGP sessions in the form of two different routers before upgrading to 3.3-2, otherwise IRP configuration will not be valid. Make sure the newly added router is linked to corresponding providers to ensure IPv6 optimization works properly. InternalMon for IPv6 session monitoring requires correct configuration of BGP MIB (IPv6) mode (see peer.X.mon.ipv6.internal.mode↓ parameter). Currently support for Brocade, Cisco and Juniper MIBs is available.
Possible values: 0, 1
Default value: 0

4.1.2.28 global.master_management_interface

Defines the management network interface. In most cases it is the same as the probing interface. When failover is enabled (global.failover↑) slave’s management interface (global.slave_management_interface↓) must be configured too.
Possible values: any valid system network interface name
Default value: eth0

4.1.2.29 global.slave_management_interface

Defines the management network interface for slave node in a failover configuration. In most cases it is the same as the probing interface. When failover is disabled (global.failover↑) the parameter is not used.
Possible values: any valid system network interface name
Default value: eth0

4.1.2.30 global.nonintrusive_bgp

Instructs the system to run in a non-intrusive BGP mode (see IRP Operating modes↑).
All improvements made in a non-intrusive mode, will not be automatically injected into the routers.
Possible values: 0 (OFF), 1 (ON)
Default value: 1
Recommended value: 1 at first start, 0 after manual tests are performed and the system is ready to go into intrusive mode

4.1.2.31 global.offpeak_hour

Defines customer’s network usual off-peak hour of the day.
Possible values: 0 - 23
Default value: 3

4.1.2.32 global.outbound

Enables or disables outbound optimization.
Outbound optimization is disabled only for standalone Inbound optimization is used.
Possible values: 0 (OFF), 1 (ON)
Default value: 1
Recommended value: 1

4.1.2.33 global.png.datadir

Defines the file-system directory path for storing image files (Graphs).
Default value: /usr/share/irp/web/RRD
Recommended value: /usr/share/irp/web/RRD

4.1.2.34 global.policies

Defines the path to the Routing Policies (1.2.9↑) configuration file.
Default value: /etc/noction/policies.conf
Recommended value: /etc/noction/policies.conf

4.1.2.35 global.master_probing_interface

Defines the probing network interface. In most cases it is the same as the management interface. When failover is enabled (global.failover↑) slave’s probing interface (global.slave_probing_interface↓) must be configured too.
This parameter is used only for displaying operating system interface(s) status in Frontend. It does not actually configure Explorer behavior, which depends on Providers settings↓.
Possible values: any valid system network interface name
Default value: eth0

4.1.2.36 global.slave_probing_interface

Defines the probing network interface for the slave node in a failover configuration. In most cases it is the same as the management interface. When failover is disabled (global.failover↑) the parameter is not used.
Possible values: any valid system network interface name
Default value: eth0

4.1.2.37 global.rd_rtt

Defines the latency distances between routing domains in the format rda:rdb:rtt where rda is the id assigned to one routing domain, rdb is the id assigned to the second routing domain and rtt represents the round trip time in miliseconds between them. rda and rdb must be different and assigned to providers. IRP assumes that distance from rda to rdb is equal to distance from rdb to rda.
The parameter takes a collection of such triplets that will define all the available inter-datacenter links between routing domains.
It is important that the RTT value between routing domains is accurate. In case the value differs significantly from the correct value IRP will make improvement decision based on incorrect information and it will make unnecessary global improvements that will reroute more traffic via inter-datacenter links.

4.1.2.38 global.master_rd

Specifies the Routing Domain that hosts the master node of IRP in a failover configuration. By default RD=1 hosts IRP nodes.
It is recommended that master node of IRP is hosted in RD=1 at all times.
Possible values: 1-100
Default value: 1
Recommended value: 1

4.1.2.39 global.slave_rd

Specifies the Routing Domain that hosts the slave node of IRP in a failover configuration. By default RD=1 hosts IRP nodes.
Possible values: 1-100
Default value: 1
Recommended value: 1

4.1.2.40 global.rrd.age_max

Defines the maximum trusted interface load data age (seconds)
Data older than this interval will not be trusted by IRP. If interface rate for each provider link has not been updated for a specified amount of time, then IRP behavior will be changed as follows:
  • If provider’s limit_load is set, no further Cost/Performance improvements will be performed to that provider
  • Commit Control will not perform further in/out improvements for this provider
Possible values: 120-240
Default value: 120
Recommended value: 120. Should be increased only if frequent SNMP timeouts occur.

4.1.2.41 global.rrd.datadir

Defines the file system directory path for storing RRD database files.
Possible values: valid directory
Default value: /var/spool/irp
Recommended value: /var/spool/irp

4.1.2.42 global.user_directories_conf

Defines the path to the User Directories configuration file.
Default value: /etc/noction/user_directories.conf
Recommended value: /etc/noction/user_directories.conf

4.1.3 API daemon settings

4.1.3.1 apid.log

Defines the file-system path to the iprapid log file.
Default value: /var/log/irp/irpapid.log

4.1.3.2 apid.log.level

Defines the logging level for the irpapid service.
Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug
Default value: info
Recommended value: info

4.1.3.3 apid.listen.master_ip

Defines the IPv4/IPv6 address of the API. Allows IRP API calls to target another node on the network. If no value provided then localhost is used. When failover is enabled (global.failover↑) slave’s listen IP (apid.listen.slave_ip↓) must be configured too.
Possible values: IPv4/IPv6 address
Default value: 127.0.0.1 ::1

4.1.3.4 apid.listen.slave_ip

Defines the IPv4/IPv6 address of the API of the slave node in a failover configuration. Allows IRP API calls to target another node on the network. If no value provided then localhost is used. When failover is disabled (global.failover↑) slave’s listen IP is not used.
Possible values: IPv4/IPv6 address
Default value: 127.0.0.1 ::1

4.1.3.5 apid.listen.port

Defines the TCP port on which the irpapid is listening. If no value provided port 10443 is used.
Possible values: 1-65535
Default value: 10443

4.1.3.6 apid.maxthreads

Defines the number of threads that irpapid is allowed to run. If no value provided 50 threads are used.
Possible values: 1-300
Default value: 50

4.1.3.7 apid.path.mtr

System path to MTR utility.
Possible values: /valid/path
Default value: /usr/sbin/mtr

4.1.3.8 apid.path.ping

System path to ping utility.
Possible values: /valid/path
Default value: /bin/ping

4.1.3.9 apid.path.ping6

System path to ping for IPv6 utility.
Possible values: /valid/path
Default value: /bin/ping6

4.1.3.10 apid.path.traceroute

System path to traceroute utility.
Possible values: /valid/path
Default value: /bin/traceroute

4.1.4 BGPd settings

4.1.4.1 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.1.4.2 bgpd.log.level

Defines the logging level for the BGPd service.
Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug
Default value: info
Recommended value: info

4.1.4.3 bgpd.as_path

Defines the way BGPd handles the AS-PATH attribute in the outgoing announcements.
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.
This only works when your provider is sending aggregate prefixes, which contain corresponding AS-PATH attributes, otherwise the method will not succeed and an empty AS-Path will be produced.
Furthermore, during a BGP session initialization, no aggregates are received from peering routers, and AS-Path remains empty until consequent information is received.
The reconstructed AS-path does not always correspond to the actual BGP AS-path.
Note that the Internet Exchange router’s AS number will not be prepended to AS Path (refer to peer.X.ipv4.next_hop_as↓, peer.X.ipv6.next_hop_as↓).
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\begin_inset Separator latexpar\end_inset
    • 0 - Allow empty AS-PATH
    • 2 - Use non-empty reconstructed AS-PATH (Announce AS-path reconstructed from route trace or empty path, if no information is available)
    • 3 - Reconstruct AS path with provider ASN and prefix origin ASN
    • 4 - Use AS-Path from BMP
Third algorithm should be enabled in bgpd.as_path when explorer.trace.all↓ is disabled
Default value: 2 3

4.1.4.4 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.1.4.5 bgpd.full_control

Sets default behavior of IRP in regards to inbound prefixes control and specifically:
  • only announce improvements 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↓.
Refer to Inbound prefixes full control↑ for details.
Possible values: 0 (Improvements), 1 (Full)
Default value: 0

4.1.4.6 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
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 - 1000 sec
Default value: 60
Recommended values: 30 - 120

4.1.4.7 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 (OFF), 1 (ON)
Default value: 0
Recommended value: 0

4.1.4.8 bgpd.improvements.remove.withdrawn

Instructs BGPd to remove prefix from improvements when aggregate is being withdrawn from the router.
Possible values: 0 (OFF), 1 (ON)
Default value: 1
Recommended value: 1

4.1.4.9 bgpd.improvements.strip_non_irp_communities

Instructs BGPd to exclude from Updates of IRP improvemnts other communities except those configured in IRP.
Possible values: 0 (OFF), 1 (ON)
Default value: 0

4.1.4.10 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↓.
Possible values: 10-600
Default value: 60
Recommended value: 60

4.1.4.11 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.1.4.12 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.1.4.13 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.1.4.14 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.1.4.15 bgpd.policy.cascade.amount

Defines the maximum number of downstream AS for cascading policies. If IRP identifies more downstream AS from the designated AS the policy for those AS will not be enforced.
Possible values: 1-1000000
Default value: 1000
Recommended value: 1000

4.1.4.16 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-10
Default value: 10

4.1.4.17 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.1.4.18 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.1.4.19 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.1.4.20 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↓.
Possible values: X:Y
Default value: 65535:1

4.1.4.21 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.
Possible values: 0 - 2
Default value: 0

4.1.4.22 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.
Possible values: 0 - 2
Default value: 0

4.1.4.23 bgpd.snmp.concurrent_requests

Specifies the number of allowed concurrent (in-flight) SNMP requests sent to a router.
Possible values: 1-2000
Default value: 10

4.1.4.24 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(4.1.4.8↑) and for aggregate next-hop equal to improvements next-hop(4.1.4.7↑) 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-100
Default value: 20
Recommended value: 60

4.1.4.25 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.1.4.26 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.1.4.27 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-2000
Default value: 1000

4.1.4.28 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.1.4.29 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.1.4.30 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. Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
Possible values: 1-60
Default value: 15

4.1.4.31 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 (OFF), 1 (ON)
Default value: 1
Recommended value: 1

4.1.5 BGP sessions settings

4.1.5.1 bgpd.peer.X.as

Mandatory for each iBGP session definition.
Parameter changes cause reset of BGP session.
Defines the Autonomous System Number for the iBGP session.
Possible values: 1-4294967295

4.1.5.2 bgpd.peer.X.cap_4byte_as

Parameter changes cause reset of BGP session.
Defines usage of 16 or 32-bit autonomous system numbers. Capability can be negotiated during session setup or forced to either 16 or 32 bits.
  • 1 - Negotiated on OPEN
  • 2 - Always 16-bit AS path
  • 3 - Always 32-bit AS path
When the router is operating in legacy mode and does not negotiate capabilities but still sends 32-bit AS Path then BGPd considers this a malformed AS_PATH attribute and disconnects the session. To avoid this the parameter must be set to force use of 32bit AS numbers.
For example: A BGP session with IRP with “disable-capability-negotiation” option configured on Vyatta router.
As a result, the BGP session is established and then teared down with log messages:
Jan 29 10:20:40.777965 WARN: BGP session RTR/IPv4 (10.0.0.1 AS 65530) Incoming UPDATE error: Invalid elements ignored. Malformed AS_PATH
Jan 29 10:20:40.778021 ERROR: BGP session RTR/IPv4 (10.0.0.1 AS 65530) Incoming UPDATE error: malformed AS_PATH xxxxxxx
Error log
The solution is to set bgpd.peer.RTR.cap_4byte_as = 3, then the BGP session succeeds.
Possible values: 1 (negotiate), 2 (force 16bit), 3 (force 32bit)
Default value: 1

4.1.5.3 bgpd.peer.X.flowspec

Enables/disables FlowSpec capability for BGP session.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.5.4 bgpd.peer.X.master_communities

Defines the BGP Community that will be appended by BGPd to all advertised prefixes. The format is: “X:Y”.
Avoid colisions of communities values assigned to IRP both within its configuration and/or on customer’s network.
When failover is enabled (global.failover↑) slave’s BGP Community (bgpd.peer.X.slave_communities↓) must be configured too.
In case BGPd receives the full or partial RIB (Routing Information Base), values for: MED, Origin, LocalPref and Communities are taken from a less-specific Aggregate route. If values for MED, Origin, LocalPref are set in config, it will override any value from Aggregate route. If value for Communities is set in config, it will be appended to communities from Aggregate route.

4.1.5.5 bgpd.peer.X.slave_communities

Defines the BGP Community that will be appended by BGPd on the slave node of a failover configuration to all advertised prefixes. The format is: “X:Y”.

4.1.5.6 bgpd.peer.X.inbound.ipv4.next_hop

Defines IPv4 address which will be used as next_hop in BGP UPDATE for inbound improvements/announcements towards this router.
The next-hop address should be known by the router (refer Routers configuration for Inbound↑).
An inbound rule can be configured with a rule-specific next-hop. Refer to inbound.rule.X.next_hop↓.
Possible values: IPv4 address

4.1.5.7 bgpd.peer.X.inbound.ipv6.next_hop

Defines IPv6 address which will be used as next_hop in BGP UPDATE for inbound improvements/announcements towards this router.
The next-hop address should be known by the router (refer Routers configuration for Inbound↑).
An inbound rule can be configured with a rule-specific next-hop. Refer to inbound.rule.X.next_hop↓.
Possible values: IPv6 address

4.1.5.8 bgpd.peer.X.inbound.localpref

Defines localpref value used by IRP for inbound improvements for this router.
Assigned localpref value should allow Inbound Improvement to become best route.
Avoid colisions of localpref values assigned to IRP both within its configuration and/or on customer’s network.
Possible values: 0 - 4294967295

4.1.5.9 bgpd.peer.X.keepalive

Defines the session keepalive time (sec). See RFC1771 for details. Hold time is calculated as keepalive * 3.
Possible values: 1-100
Default value: 60
Recommended value: 1/3 holdtime

4.1.5.10 bgpd.peer.X.listen

Instructs the BGP daemon to listen for incoming sessions. It must be set to 1 to be RFC1771 compliant. It can be set to 0 to resolve specific issues.
Possible values: 0 (OFF), 1 (ON)
Default value: 1
Recommended value: 1

4.1.5.11 bgpd.peer.X.master_localpref

Defines the local-preference value for prefixes announced by BGPd.
Avoid colisions of localpref values assigned to IRP both within its configuration and/or on customer’s network.
When failover is enabled (global.failover↑) slave’s BGP LocalPref (bgpd.peer.X.slave_localpref↓) must be configured too.
If failover is enabled, master’s LocalPref value must be greater than slave’s LocalPref value.
In case BGPd received the full or partial RIB (Routing Information Base), values for MED, Origin, LocalPref and Communities will be taken from less-specific Aggregate route. If values for MED, Origin, LocalPref are set in config, it will override any value from Aggregate route. If value for Communities is set in config, it will be appended to communities from Aggregate route.
Possible values: 0 - 4294967295
Default value:

4.1.5.12 bgpd.peer.X.slave_localpref

Defines the local-preference value for prefixes announced by BGPd.
Possible values: 0 - 4294967295
Default value:

4.1.5.13 bgpd.peer.X.med

Defines the Multi-Exit Discriminator (MED) value for prefixes announced by BGPd.
In case BGPd received the full or partial RIB (Routing Information Base), values for MED, Origin, LocalPref and Communities will be taken from less-specific Aggregate route. If values for MED, Origin, LocalPref are set in config, it will override any value from Aggregate route. If value for Communities is set in config, it will be appended to communities from Aggregate route.
Possible values: 0 - 4294967295

4.1.5.14 bgpd.peer.X.origin

Defines the Origin value for prefixes announced by BGPd.
Possible values: 0 (IGP), 1 (EGP), 2 (INCOMPLETE)

4.1.5.15 bgpd.peer.X.master_our_ip

Mandatory for IPv4 BGP session.
Parameter changes cause reset of BGP session.
Defines IPv4 address of IRP server end of this iBGP session. When failover is enabled (bgpd.peer.X.slave_our_ip↓) slave’s IP address (bgpd.peer.X.slave_localpref↑) must be configured too.
Possible values: IPv4 address

4.1.5.16 bgpd.peer.X.slave_our_ip

Mandatory for IPv4 BGP session.
Parameter changes cause reset of BGP session. Affects only BGP session of slave node in a failover configuration.
Defines IPv4 address of IRP server end of this iBGP session of slave node in a failover configuration.
Possible values: IPv4 address

4.1.5.17 bgpd.peer.X.master_our_ipv6

Mandatory for IPv6 BGP session.
Parameter changes cause reset of BGP session.
Defines IPv6 address of IRP server end of this iBGP session. When failover is enabled (bgpd.peer.X.slave_our_ip↑) slave’s IPv6 address (bgpd.peer.X.slave_our_ipv6↓) must be configured too.
Possible values: IPv6 address

4.1.5.18 bgpd.peer.X.slave_our_ipv6

Mandatory for IPv6 BGP session in failover configuration.
Parameter changes cause reset of BGP session. Affects only BGP session of slave node in a failover configuration.
Defines IPv6 address of IRP server end of this iBGP session of slave node in a failover configuration.
Possible values: IPv6 address

4.1.5.19 bgpd.peer.X.peer_ip

Mandatory for IPv4 BGP session.
Parameter changes cause reset of BGP session.
Defines iBGP session’s router’s IPv4 address.
Possible values: IPv4 address

4.1.5.20 bgpd.peer.X.peer_ipv6

Mandatory for IPv6 BGP session.
Parameter changes cause reset of BGP session.
Defines iBGP session’s router’s IPv6 address.
Possible values: IPv6 address

4.1.5.21 bgpd.peer.X.master_router_id bgpd.peer.X.slave_router_id↓

Mandatory for IPv6 BGP session either as standalone master or when failover is enabled and the value should be different from bgpd.peer.X.slave_router_id↓.
Parameter changes cause reset of BGP session.
Defines IRP server’s router ID. The BGP router ID is used in the BGP algorithm for determining the best path to a destination where the preference is given to the BGP router with the lowest router ID.
Possible values: 4-byte value in the IPv4 address format. Any valid IPv4 address can be used.

4.1.5.22 bgpd.peer.X.slave_router_id

Mandatory for IPv6 BGP session either as standalone slave or when failover is enabled and the value should be different from bgpd.peer.X.master_router_id↑.
Parameter changes cause reset of BGP session. Affects only BGP session of slave node in a failover configuration.
Defines IRP server’s router ID. The BGP router ID is used in the BGP algorithm for determining the best path to a destination where the preference is given to the BGP router with the lowest router ID.
Possible values: 4-byte value in the IPv4 address format. Any valid IPv4 address can be used.

4.1.5.23 bgpd.peer.X.shutdown

Parameter changes cause reset of BGP session.
Defines whether the corresponding iBGP session is active or shutdown.
Possible values: 0 (Active), 1 (Shutdown)
Default value: 0

4.1.5.24 bgpd.peer.X.transit.mib

Parameter changes cause reset of BGP session.
Defines the MIB used by transit improvements monitors. Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
  • 0 - Generic (BGP4-MIB)
Default value: 0

4.1.5.25 bgpd.peer.X.transit.snmp

Parameter changes cause reset of BGP session.
Points to the SNMP host (and its parameters) used for transit improvements monitor on this session. Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
Possible values: valid SNMP host identifier

4.1.5.26 bgpd.peer.X.transit.status

Parameter changes cause reset of BGP session.
Enables or disables transit improvements through this BGP session (router). Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
Possible values: 0 (Disable), 1 (Enable)
Default value: 0

4.1.5.27 bgpd.peer.X.updates.limit.max

Represents a maximum number of prefixes that can be announced simultaneously in one session.
If bgpd.updates.split↑ is ON, the number of announced prefixes is twice the number of the improvements. If the BGP neighbor (typically - the edge router) has any hardware/software limitation for the number of routes in active routing table, then BGPd can be instructed not to announce more than a specified amount of prefixes. Value 0 means no limit for current iBGP session.
Values less than maximum allowed improvements, can cause not all the improved prefixes to be injected into such peer.
Higher values can be incompatible with the router (please consult the router’s vendor regarding the maximum amount of entries in routing table as well as the BGP table).
Possible values: 0-100000
Default value: 0
Recommended value: 0

4.1.5.28 bgpd.peer.X.updates.limit.ps

Defines the maximum number of updates per second that will be sent to the current BGP neighbor. Low values will slow down the improvements injection. High values can cause router to drop the improvement without installing it into the routing database.
Possible values: 1-1000000
Default value: 500
Recommended values: 100-1000

4.1.5.29 bgpd.peer.X.master_password

Defines iBGP session’s password. When failover is enabled (bgpd.peer.X.slave_our_ip↑) slave’s local IPv6 address (bgpd.peer.X.slave_password↓) must be configured too.
Possible values: up to 80 alphanumeric characters

4.1.5.30 bgpd.peer.X.slave_password

Defines iBGP session’s password for slave node in a failover configuration.
Possible values: up to 80 alphanumeric characters


4.1.6 BMP monitoring station settings

4.1.6.1 irpbmpd.log

Defines the file-system path to the BMP monitoring station (irpbmpd) log file.
Default value: /var/log/irp/irpbmpd.log

4.1.6.2 irpbmpd.log.level

Defines the logging level for the BMP monitoring station (irpbmpd) service.
Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug
Default value: info
Recommended value: info

4.1.6.3 irpbmpd.port

Defines the TCP port where BMP monitoring station (irpbmpd) listens for monitoring routers to establish BMP sessions.
When BMP information is available for all providers also consider setting BMP as a source of AS_PATH information under bgpd.as_path↑.
Default value: 7854
Recommended value: 1-65535

4.1.7 Collector settings

4.1.7.1 collector.detect.explorer_ips

Instructs the collector to ignore the Explorer-generated traffic, which can initiate false IRP reaction to the network events (Excessive loss, blackout).
This feature is used only by the SPAN collector, instructing it to ignore the IPv4 traffic when the network address translation is used to masquerade IP addresses.
Possible values: 0 (OFF), 1 (ON)
Default value: 0
Recommended value: 0

4.1.7.2 collector.export.interval

Defines the time interval (in seconds) between data exports in Collectors (flow and span). Lower values result in more accurate traffic data, but higher storage usage. High values cause slow statistics accumulation and less accurate calculation of prefix data.
Possible values: 10-3600
Default value: 60
Recommended value: 60-300

4.1.7.3 collector.export.top_volume_ips

Defines the maximum number of top hosts per prefix for which usage values are stored. Collector persists up to this number of IP address, usage tuples together with other prefix statistics being collected. When the value of the parameter is zero no such statistics will be collected.
Possible values: 0-10
Default value: 5

4.1.7.4 collector.export.ttl

Defines the collector-gathered data lifetime (in seconds). Larger values lead to excessive database size. Aggregated data is kept for one year, disregarding this parameter.
Possible values: 1-’unlimited’
Default value: 86400
Recommended value: 1-30days

4.1.7.5 collector.export.volume.high.top_n

Defines the number of top volume prefixes.
Top N prefixes will be marked for priority probing in descending order of volume. Lower values lead to small number of events for priority probing of high volume prefixes. Higher values lead to overflow of probing queue with jobs for unimportant prefixes.
Possible values: 0-’unlimited’
Default value: 50
Recommended value: 10-50

4.1.7.6 collector.export.volume.min

Defines the minimum collected prefix volume (bytes). The prefix will not be exported into the IRP database if its traffic volume is less than the value of the current parameter (collector.export.volume.min↑) and the percentage of the traffic volume less the collector.export.volume.min_pct↓ parameter.
Lower values will lead to a higher number of prefixes exported into the IRP database.
Possible values: 1-2000000000
Default value: 100000
Recommended value: 10000-1000000

4.1.7.7 collector.export.volume.min_pct

Defines the minimum prefix volume (%) for a prefix to be exported into the IRP database. The prefix will not be exported into the IRP database if its percentage of the traffic volume is less than the value of the current parameter (collector.export.volume.min_pct↑) and the traffic volume less than collector.export.volume.min↑. The percentage of the traffic volume is calculated according to the export interval (collector.export.interval↑). Lower values will lead to a higher number of prefixes exported into the IRP database.
Possible values: 0.0001-100
Default value: 0.01
Recommended value: 0.01-0.1

4.1.7.8 collector.flow.buffer.size

Defines the buffer size (in packets) for the Flow collector (irpflowd). Higher values lead to extra memory used by the collector. Slightly increase this value if the network has traffic spikes that cause buffer overflows and packet drop in the collector.
Possible values: 10000-1000000
Default value: 50000
Recommended value: 50000-500000

4.1.7.9 collector.flow.enabled

Enables the Flow collector. If the parameter is enabled, Flow Collector will be used to gather network prefix data, but it is still possible to use SPAN Collector to acquire network events.
Possible values: 0 (OFF), 1 (ON)
Default value: 0
Recommended value: 0 - for SPAN collector (see collector.span.enabled↓), 1 - for Flow collector.

4.1.7.10 collector.flow.export.inbound_transit.topn

Specifies the number of largest volume transit prefixes that are exported each collector cycle for inbound optimization of transiting traffic. Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
Possible values: 1-10000
Default value: 100

4.1.7.11 collector.flow.listen.nf

Defines the UDP port the Flow collector will listen to, for NetFlow traffic.
Possible values: 1-65535
Default value: 2055
Recommended value: 2055

4.1.7.12 collector.flow.listen.sf

Defines the UDP port the Flow collector will listen to, for sFlow traffic.
Possible values: 1-65535
Default value: 6343
Recommended value: 6343

4.1.7.13 collector.flow.log

Defines the file-system path to the irpflowd log file.
Default value: /var/log/irp/irpflowd.log

4.1.7.14 collector.flow.log.level

Defines the logging level for the irpflowd service.
Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug
Default value: info
Recommended value: info

4.1.7.15 collector.flow.process_transit_in_outbound

Enables or disables matching of prefix traffic at network egress for inbound optimization of transiting traffic. Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.
This should be enabled only in complex network topologies where ingress prefix statistics can be incomplete.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.7.16 collector.flow.sources

Defines the valid NetFlow/sFlow/jFlow exporters IP addresses. Flow data coming in from other IP addresses that are not listed in this parameter will be ignored.
It is recommended to specify only trusted Flow exporters IP addresses.
Possible values: list of valid IPv4/IPv6 addresses
Default value: 0/0 ::/0
Recommended value: Trusted IPv4/IPv6 flow exporter addresses

4.1.7.17 collector.ournets

Mandatory parameter
Defines the list of networks to be analyzed. Typically this is the list of prefixes advertised by your AS.
Format:
  1. Space-separated list of local IPv4/IPv6 prefixes that should be analyzed and optimized by the IRP.
  2. Absolute path to a newline-separated file containing a list of local IPv4/IPv6 prefixes that should be analyzed and optimized by the IRP.
IPv4 prefixes are treated as /24 subnets and IPv6 prefixes as /48 subnets, if netmask is not clearly specified.
The downstream clients’ networks can be indicated as well.
Possible values: See above.

4.1.7.18 collector.sessions.max

Defines the maximum number of TCP sessions inside the collector process. It can be used to minimize memory usage.
Both Flow and Span collectors use this parameter.
Estimated memory usage can be calculated as follows: usage = 80MB + (collector.sessions.max↑*1464)
Possible values: 10000-10000000
Default value: 2000000
Recommended value: Depends on available server memory and the maximum number of simultaneous sessions during peak hours.

4.1.7.19 collector.span.buffer.size

Defines the buffer size (in packets) for the Span collector (irpspand). Higher values lead to extra memory used by the collector. Slightly increase this value if the network has traffic spikes that cause buffer overflows and packet drop in the collector.
Possible values: 10000-5000000
Default value: 100000
Recommended value: 100000-5000000

4.1.7.20 collector.span.enabled

Enables the Span collector. Span collector will be used to gather network prefix data, if the parameter is enabled.
Possible values: 0 (OFF), 1 (ON)
Default value: 0
Recommended value: 0 - if no traffic analysis should be performed by the Span collector, 1 - if the Span collector should analyze mirrored traffic for network events and/or prefix statistics.

4.1.7.21 collector.span.interfaces

Mandatory parameter
Defines a space-separated network interfaces list for passive packet analysis by the Span collector.
Example:
collector.span.interfaces   = eth0 eth1 eth2

4.1.7.22 collector.span.log

Defines the file-system path to the irpspand log file.
Default value: /var/log/irp/irpspand.log

4.1.7.23 collector.span.log.level

Defines the logging level for the irpspand service.
Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug
Default value: info
Recommended value: info

4.1.7.24 collector.span.min_delay

Enables fast probing tasks queuing for prefixes with one of the following issues:
  • Blackouts
  • Congestion
  • Excessive packet delays.
Possible values: 0 (OFF), 1 (ON)
Default value: 0
Recommended value: 0

4.1.7.25 collector.span.min_delay.probing_queue_size

Defines the number of slots in the probing queue that can be used by the min_delay algorithm
(see: collector.span.min_delay↑)
Possible values: 1-200
Default value: 50
Recommended value: 30-200

4.1.7.26 collector.span.size_from_ip_header

When parameter is enabled packet size is determined from header of the IPv4/IPv6 packet. Otherwise, packet size is determined from link layer information (original packet size from PCAP/SNF).
Enable this when source packets are stripped before entering Noction IRP’s appliance SPAN interface.
Possible values: 0 (OFF), 1 (ON)
Default value: 0

4.1.7.27 collector.span.threshold.blackout

Defines the percentage of retransmitted packets in regards to the total packets number. If retransmit is higher than this value, this prefix is considered to have a blackout.
Possible values: 1-100
Default value: 70
Recommended value: 70-90

4.1.7.28 collector.span.threshold.congestion

Defines the percentage of retransmitted packets in regards to the total packets number. If retransmit is higher than this value, this prefix is considered to have a congestion.
Possible values: 1-100
Default value: 50
Recommended value: 30-70

4.1.7.29 collector.span.threshold.delay

Percentage of excessive delayed packets by the total packets number (see collector.span.threshold.excessive↓). If this percentage is higher than this value, we consider this prefix to have a delay.
Possible values: 1-100
Default value: 20
Recommended value: 10-30

4.1.7.30 collector.span.threshold.excessive

Defines the excessive RTT (%). The value is compared to the average round trip time. If RTT is higher by collector.span.threshold.excessive↑ in % than the average RTT, then the counter of excessive delay packets is incremented.
Possible values: > 0
Default value: 200
Recommended value: 100-500

4.1.7.31 collector.speaking_ips

Defines the number of speaking IPs to be stored in the database.
Possible values: 0-1000
Default value: 100
Recommended value: 100


4.1.8 Core settings

4.1.8.1 core.log

Defines the file-system path to the core log file.
Default value: /var/log/irp/core.log

4.1.8.2 core.log.level

Defines the logging level for the core service.
Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug
Default value: info
Recommended value: info

4.1.8.3 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.1.8.4 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.1.8.5 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.
Possible values: 0 (No changes), 1 (Prepend on warn), 2 (Prepend on shutdown)
Default value: 0

4.1.8.6 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.1.8.7 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.1.8.8 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.1.8.9 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.
Possible values: 0 (No changes), 1 (Prepend on warn), 2 (Prepend on shutdown)
Default value: 0

4.1.8.10 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.1.8.11 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.1.8.12 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:
  1. SNMP parameters must be set for each provider:\begin_inset Separator latexpar\end_inset
    1. peer.X.snmp.ip↓ or peer.X.snmp.ipv6↓
    2. peer.X.snmp.interface↓
    3. peer.X.snmp.community↓
    4. irpstatd needs to be started (see Section 2.8↑)
  2. Each provider needs to have peer.X.95th↓ set to the desired Commit level
  3. 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.
Possible values: 0 (OFF), 1 (ON)
Default value: 0

4.1.8.13 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.
Possible values: 0.1-5000
Default value: 1
Recommended value: 0.1 - if summary throughput is lower than 200-500Mbps,
1 - if summary throughput is higher than 500Mbps.

4.1.8.14 core.commit_control.del_irrelevant

If enabled, Commit Control algorithm deletes improvements that have traffic volume less than value in the4.1.8.13↑ parameter.
Possible values: 0 (OFF), 1 (ON)
Default value: 1
Recommended value: 1

4.1.8.15 core.commit_control.inbound.enabled

Enables or disables Inbound bandwidth control.
Possible values: 0 (Disabled), 1 (Enabled)
Default value: 0

4.1.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.1.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.1.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.1.8.19 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.1.8.20 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.1.8.21 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.1.8.22 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.1.8.23 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.
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