BGPd settings

4 Configuration parameters reference

4.1 Complete parameters list

4.1.1 Database credentials

4.1.1.1 db.clickhouse.dbname

Name of the ClickHouse database that contains the IRP tables.
Default value: irp

4.1.1.2 db.clickhouse.host

Database host. ClickHouse server host name or IPv4/IPv6 address.
Default value: localhost

4.1.1.3 db.clickhouse.password

The password used to connect to a ClickHouse server.

4.1.1.4 db.clickhouse.port

TCP port number used to connect to a ClickHouse server.
Default value: 9000

4.1.1.5 db.clickhouse.username

User name used to connect to a ClickHouse server.
Default value: irp

4.1.1.6 db.dbname

Name of a MySQL database that holds the IRP tables.
Default value: irp

4.1.1.7 db.host

Database host. MySQL server host name or IPv4/IPv6 address.
Default value: localhost

4.1.1.8 db.ourhost

IRP host. IRP box host name or IPv4/IPv6 address.
Default value: localhost

4.1.1.9 db.password

The password used to connect to a MySQL server.

4.1.1.10 db.port

TCP port number to use for the connection to a MySQL database.
Default value: 3306

4.1.1.11 db.username

User name used to connect to a MySQL server.
Default value: irp

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.

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.

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.

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:

Space-separated list of AS numbers that must be ignored by IRP.
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.

Refer also global.ignored_communities↓, global.ignorednets↓.

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.

Refer also global.ignored.asn↑, global.ignorednets↓.

Possible values: valid BGP community attribute list.

4.1.2.23 global.ignorednets

Defines the list of networks to be ignored by IRP.

Format:

Space-separated list of local IPv4/IPv6 prefixes that should be ignored by IRP.
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.

Refer also global.ignored.asn↑, global.ignored_communities↑.

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:

Performance optimization↑: Decrease loss, then decrease latency;
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.

Refer peer.X.rd↓, peer.X.flow_agents↓, bgpd.rd_local_mark↓

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.

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

(see bgpd.improvements.remove.next_hop_eq↓ and bgpd.improvements.remove.withdrawn↓).

This reduces the effects of route flapping to improvement cleanup.

Verification is performed on each BGP Scan, so that the values that are lower than the value of the bgpd.scaninterval parameter are not taken into account. The higher the values - the longer the time interval needed for improvements, which are still valid after aggregate route is withdrawn or on equal next-hop.

BGPd does improvements check against the routers received and sent via iBGP in periodic time intervals. The process is referred to as the BGP Scan process.

Time interval between BGP Scannings can be configured in bgpd.scaninterval↓.

Possible values: 1 - 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.

Refer also to bgpd.retry_probing.old.bmp_path_change↓, peer.X.bmp↓.

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.

Refer also to bgpd.retry_probing.new.bmp_path_change↑, peer.X.bmp↓.

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.

Refer to global.aggregate↑, global.agg_ipv4_max↑, global.agg_ipv6_max↑ parameters.

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.

See also bgpd.peer.X.master_localpref↑.

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.

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.

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.

See also bgpd.peer.X.master_our_ipv6↑.

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.

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.

See also bgpd.peer.X.master_password↑.

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:

Space-separated list of local IPv4/IPv6 prefixes that should be analyzed and optimized by the IRP.
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.

Refer also core.circuit.transit↓.

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.

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.

Refer also core.circuit.inbound↑.

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:

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↑)
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.

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

4.1.8.24 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.

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↑.

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.

Possible values: 50-99, but larger or equal to core.commit_control.rate.low↓

Default value: 90

Recommended value: 90

4.1.8.25 core.commit_control.rate.low

Defines provider’s high 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).

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↑.

Possible values: 30-99, but lower or equal to core.commit_control.rate.high↑

Default value: 80

Recommended value: 80

4.1.8.26 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 (OFF), 1 (ON)

Default value: 1

Recommended value: 1

4.1.8.27 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.1.8.28 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-unlimited

Default value: 10

Recommended value: 10

4.1.8.29 core.eventqueuelimit

Defines the exploring events queue size. Lower values may result in IRP missing some important network issues.

Possible values: 1-10000

Default value: 1000

Recommended value: 100-1000

4.1.8.30 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.1.8.31 core.global.worst_ms

Defines acceptable latency worsening for cost and commit for global improvements. Refer core.cost.worst_ms↑

Possible values: 1-unlimited

Default value: 30

Recommended value: 10

4.1.8.32 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.1.8.33 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.1.8.34 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.1.8.35 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.1.8.36 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.1.8.37 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.1.8.38 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↑).

Refer Optimization of transiting traffic ↑, Optimization of transiting traffic↑.

Possible values: 0 (Decrease prepends), 1 (Remove immediately)

Default value: 0

4.1.8.39 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. Refercore.improvements.inbound_transit.ttl.clean↑, Optimization of transiting traffic ↑, Optimization of transiting traffic↑.

Possible values: 901 - 345600

Default value: 86400

4.1.8.40 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.1.8.41 core.flowspec.max

Defines the maximum number of IPv4 Flowspec rules that IRP is allowed to advertise.

Possible values: 1-10000

Default value: 100

4.1.8.42 core.improvements.max_ipv6

Defines the maximum number of active IPv6 improvements.

Possible values: 1-100000

Default value: 2000

Recommended value: 2000

4.1.8.43 core.flowspec.max_ipv6

Defines the maximum number of IPv6 Flowspec rules that IRP is allowed to advertise.

Possible values: 1-10000

Default value: 100

4.1.8.44 core.improvements.retry_probe.volume_top_n

Traffic volume top-N prefixes

The improvements are checked for relevance when they are improved the first time, with the relevancy flag set accordingly. All prefixes (starting from current month’s first day) are sorted by traffic volume. The top-N prefixes from this list are treated as "relevant" prefixes.

In case an empty slot is required for a new improvement, the old irrelevant prefix(es) will be deleted first to free-up a slot.

Volume-relevant prefixes will be queued for retry probing before non-relevant prefixes.

Possible values: 1-20000

Default value: 5000

Recommended value: chosen for each network individually

4.1.8.45 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.1.8.46 core.outage_detection

Enables the Outage Detection algorithm.

Possible values: 0 (OFF), 1 (ON)

Default value: 0

Recommended value: 1

4.1.8.47 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).

4.1.8.48 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.1.8.49 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.1.8.50 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.1.8.51 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.1.8.52 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.1.8.53 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.1.8.54 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.1.8.55 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.

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-’unlimited’

Default value: 10

Recommended value: 2-20

4.1.8.56 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.

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.1.8.57 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 zerofor 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: 1-1000000

Default value: 0

Recommended value: 20-50

4.1.8.58 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.1.8.59 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.1.8.60 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.

4.1.8.61 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.1.8.62 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: 0-3600

Default value: 600

Recommended value: 600

4.1.8.63 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.1.8.64 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.

4.1.9 Explorer settings

4.1.9.1 explorer.log

Defines the file-system path to the explorer log file.

Default value: /var/log/irp/explorer.log

4.1.9.2 explorer.log.level

Defines the logging level for the explorer service.

Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug

Default value: info

Recommended value: info

4.1.9.3 explorer.aipi

If enabled, AIPI (Adaptive Inter-Packet Interval) algorithm is executed using inter-packet intervals configured for each provider.

Possible values: 0 (OFF), 1(ON)

Default value: 0

Recommended value: 0

4.1.9.4 explorer.high_vol_precedence

High volume tasks have priority over the tasks with variable cardinality.

The parameter establishes the balance between the tasks allocated for processing high volume prefixes (high priority for the Customer network) and the network events tasks (such as blackout, congestion, etc).

Possible values: 10-90

Default value: 50

4.1.9.5 explorer.infra_ips

Mandatory parameter

Defines the IPv4/IPv6 addressees, used in internal infrastructure to determine the current route for a specific prefix. If netmask is not specified, then /32 is assumed for IPv4 address and /128 for IPv6 address (host addresses).

Format:

Space-separated list of infrastructure IPv4/IPv6 addresses.
Absolute path to a newline-separated file containing a list of local IPv4/IPv6 prefixes that should be analyzed and optimized by the IRP.

Possible values: See above.

Recommended value: all IPv4/IPv6 addresses used in the internal infrastructure.

4.1.9.6 explorer.interval.infra

Defines the time interval (in milliseconds) between the packets sent to infrastructure hops (4.1.9.5↑). By decreasing this value the Explorer performance enhances.

Possible values: 1-200

Default value: 5

Recommended value: 5

4.1.9.7 explorer.interval.other

Defines the time interval (in milliseconds) between the packets sent to destination hops (4.1.9.5↑).

Possible values: 1-1000

Default value: 200

Recommended value: 200

4.1.9.8 explorer.interval.other.trace

Defines the time interval (in milliseconds) between traceroute packets sent to non-infrastructure hops.

Possible values: 1-1000

Default value: 20

Recommended value: 20

4.1.9.9 explorer.ipv4_test

Defines public IPv4 address that will be used for ensuring that PBR is operational.

Possible values: IPv4 address

Default value: 8.8.8.8

Recommended value: 8.8.8.8

4.1.9.10 explorer.ipv6_test

Defines public IPv6 address that will be used to verify that PBR is operational.

Possible values: IPv6 address

Default value: 2620:0:ccc::2

Recommended value: 2620:0:ccc::2

4.1.9.11 explorer.maxthreads

Defines the number of simultaneously processed exploring tasks.

If this value is excessively large Explorer tasks can take very long to finish. Hardware/router diagnostic packet rate limitations kick in causing all threads to wait for exploring tasks to finish.

Possible values: 10-2000

Default value: 200

Recommended value: 200-300

4.1.9.12 explorer.max_collector_ips

Process max collected IPs. Maximum number of IPs to probe for a specific prefix.

Possible values: 1-255

Default value: 10

Recommended value: 10

4.1.9.13 explorer.algorithms

Enables or disables the use of new scanning, probing and tracing Explorer algorithms.

Possible values: 0 (Disabled), 1(Enabled)

Default value: 0

4.1.9.14 explorer.probe.algorithm

Defines the probing algorithm(s) used by explorer, in the preferred order.

The following algorithms can be used:

UDP - udp requests (destination port: 33434)
ICMP - regular ICMP ping sweep
TCP_SYN - tcp syn scan (destination port: 33434)

Possible values: ICMP UDP TCP_SYN

Default value: ICMP UDP TCP_SYN

Recommended value: ICMP UDP TCP_SYN

4.1.9.15 explorer.probe.indirect_priority

Defines the execution priority between direct and indirect probing algorithms. Parameter value of 1 means that indirect probing will be executed prior to direct probing algorithm. Parameter value of 2 disables indirect probing.

This parameter conflicts with explorer.trace.all↓ configuration option.

Possible values: 0 (Direct then Indirect), 1 (Indirect then Direct), 2 (Direct only)

Default value: 0

Recommended value: 0

4.1.9.16 explorer.probing.sendpkts.min

Defines the default ping packets count for each probe. If any loss is detected, additional packets (up to explorer.probing.sendpkts.adaptive_max↓) are sent, for a more accurate packet loss detection.

Possible values: positive Integer value

Default value: 5

Recommended value: 5

4.1.9.17 explorer.probing.sendpkts.adaptive_max

Defines the maximum number of ping packets for adaptive prefix probing.

Possible values: positive Integer value, higher or equal to explorer.probing.sendpkts.min↑

Default value: 100

Recommended value: 100

4.1.9.18 explorer.probing.simultaneous

Defines the number of scanned IP addresses.

Possible values: 1-100

Default value: 50

Recommended value: 50

4.1.9.19 explorer.scanning.confirm_ips

Defines the number of scanned speaking IP addresses for a provider with loss.

Possible values: 1-10

Default value: 5

Recommended value: 5

4.1.9.20 explorer.scanning.replypkts.min

Defines the number of response packets from a scanned speaking IP address to qualify as a candidate.

Possible values: 1-10

Default value: 5

Recommended value: 5

4.1.9.21 explorer.scanning.rtt.dispersion_ms

Defines RTT maximum dispersion in miliseconds to qualify a speaking IP as candidate.

Possible values: 1-1000

Default value: 50

Recommended value: 50

4.1.9.22 explorer.scanning.sendpkts.factor

Defines the number of attempts to send packets to all selected speaking IPs.

Possible values: 1-10

Default value: 5

Recommended value: 5

4.1.9.23 explorer.timeout

Defines the probes ICMP timeout (in ms)

Default value: 2000

Recommended value: 2000

4.1.9.24 explorer.timeout.infra

Defines the waiting time (in milliseconds) for infrastructure hops’ (4.1.9.5↑) responses expected during trace execution.

Possible values: 50-20000

Default value: 10000

Recommended value: 10000

4.1.9.25 explorer.trace.algorithms

Defines the traceroute algorithm(s) to be used, arranged by priority. See explorer.probe.algorithm↑ for algorithms description.

Possible values: UDP ICMP TCP_SYN

Default value: UDP ICMP

Recommended value: UDP ICMP

4.1.9.26 explorer.trace.all

Defines tracing behaviour. If traces are forced, each probed prefix unconditionally runs traces through all configured providers. Regular tracing is needed for Outage Detection and for AS Path reconstruction. Traces can be disabled altogether by setting explorer.trace.all↑ to 2.

Third algorithm should be enabled in bgpd.as_path↑ when traces are fully disabled.

Forcing ALL traces (explorer.trace.all↑ = 1) can significantly slow down probing for networks. Review probing times before and after changing this parameter and if probing times become unacceptable revert to previous setting.

When all traces are disablled (explorer.trace.all↑ = 2) IRP is missing essential trace data and is not able to take action on some types of problems. This effectively cuts off those features.

Possible values: 0 (Regular), 1 (Force all), 2 (Disable all)

Default value: 0

Recommended value: 0

4.1.9.27 explorer.traceroute.retrypkts

Defines the number of additional traceroute packets to be sent to the intermediate hop in case it has not replied and might be an infrastructure boundary hop.

Possible values: 0-50

Default value: 10

Recommended value: 10

4.1.9.28 explorer.traceroute.sendpkts

Defines the number of traceroute packets per hop to be sent for each probe.

Possible values: 3-5

Default value: 3

Recommended value: 3

4.1.9.29 explorer.traceroute.simultaneous

Defines the number of simultaneously probed hops during trace execution initiated from the hop defined by (4.1.9.31↓).

Possible values: 1-30

Default value: 5

Recommended value: 5

4.1.9.30 explorer.traceroute.simultaneous.infra

Defines the number of simultaneously probed infrastructure hops during trace execution.

Possible values: 1-30

Default value: 3

Recommended value: 3

4.1.9.31 explorer.traceroute.ttl.min

Defines the minimum traceroute TTL. Basically this defines the first hop after which explorer analyzes the trace.

Possible values: 1-255

Default value: 2

Recommended value: 2-5

4.1.9.32 explorer.traceroute.ttl.max

Defines the maximum traceroute TTL. Essentially this defines the last hop at which explorer stops the trace.

Possible values: 1-255

Default value: 30

Recommended value: 30

4.1.10 Notification and events parameters

4.1.10.1 pushd.log

Defines the complete path to the irppushd log file

Possible values: full path to log file

Default value: /var/log/irp/irppushd.log

4.1.10.2 pushd.log.level

Defines the logging level for the irppushd service.

Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug

Default value: info

Recommended value: info

4.1.10.3 pushd.listen.port

Defines the TCP listen port of irppushd service.

Possible values: 1-65535

Default value: 10499

4.1.10.4 pushd.email.from

Defines the From email address used for sending email notifications.

Possible values: valid email address

Default value: root@localhost

4.1.10.5 pushd.email.host

Defines the IPv4, IPv6 address or email server host name used to send emails.

Possible values: Hostname or IPv4/IPv6 address

Default value: 127.0.0.1

4.1.10.6 pushd.email.port

Defines the TCP port used for sending emails.

Possible values: 1 - 65535

Default value: 25

Recommended value: 25

4.1.10.7 pushd.sms.account_sid

Defines the public account identifier issued to user by the SMS gateway. Usually this is a random string.

Possible values: random string

4.1.10.8 pushd.sms.auth_token

Defines the secret authentication token issued by the SMS gateway to the account holder. Usually this is a longer random string.

Possible values: random string

4.1.10.9 pushd.sms.gateway

Defines the SMS gateway preferred by the user. A valid account with this SMS gateway is required to send SMS.

Possible values: twilio, plivo

Default value: none

4.1.10.10 pushd.sms.message_size

Defines the maximum size of SMS texts. Texts that are longer than this limit will be trimmed and a ... will be added. The SMS gateway will split the SMS text into multiple messages if the request includes a longer than supported SMS message.

The SMS gateway enforces its own text size limits. In case the notification exceeds SMS gateway limits the SMS message can be either trimmed or rejected.

Possible values: 150-6000

Default value: 150

4.1.10.11 pushd.sms.phone_number

Defines the From phone number used for sending SMS notifications.

SMS gateways might have policies regarding the valid phone numbers that they will accept. Check with your SMS gateways if there are any restrictions and if yes what phone numbers can be provided in this configuration parameter.

Possible values: valid phone number

4.1.10.12 pushd.sms.uri.twilio

Defines the URL of the Twilio SMS API.

Do not change this parameter unless Twilio SMS API URL has changed.

Possible values: valid URL

Default value: https://api.twilio.com/2010-04-01/Accounts/%1%/Messages.json

Recommended value: https://api.twilio.com/2010-04-01/Accounts/%1%/Messages.json

4.1.10.13 pushd.sms.uri.plivo

Defines the URL of the Plivo SMS API.

Do not change this parameter unless Plivo SMS API URL has changed.

Possible values: valid URL

Default value: https://api.plivo.com/v1/Account/%1%/Message/

Recommended value: https://api.plivo.com/v1/Account/%1%/Message/

4.1.10.14 pushd.templates.datadir

Defines the directory for notification templates used by irppushd service to format email and sms messages.

Possible values: full path to notification templates

Default value: /etc/noction/templates

4.1.10.15 pushd.webhook.avatar_emoji

Defines an emoji to be used as the IRP bot’s avatar image. The emoji is expected to be in the “:robot-face:” notation.

The avatar emoji is used if an avatar icon in pushd.webhook.avatar_url↓is not specified.

Possible values: valid emoji in :colon: notation

Default value: :robot-face:

4.1.10.16 pushd.webhook.avatar_url

Defines the URL of the IRP bot’s avatar image. URL should be a publicly accessible PNG or JPEG image that the webhook provider is able to retrieve and use.

This is the default avatar image. The avatar icon will be used instead of an emoji if both are specified. Refer to pushd.webhook.avatar_emoji↑.

Possible values: valid URL

Default value: https://www.noction.com/round-logo.png

Recommended value: https://www.noction.com/round-logo.png

4.1.10.17 pushd.webhook.botname

Defines the name assigned to IRP bot.

Possible values: text

Default value: IRP

Recommended value: IRP

4.1.10.18 pushd.webhook.url

Defines the URL assigned to Web Hooks user/team. Web Hooks work by POST-ing JSON content to this designated URL for example

POST https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

This parameter is required in order for any subscription to web hooks channels to work. Currently only the Slack.com web hooks API has been tested and confirmed to work.

Possible values: valid URL

4.1.10.19 trap.destination.auth_password

SNMP user’s password for IRP generated traps. Applicable only when SNMP v3 with authentication is used. Refer to trap.destination.version↓, trap.destination.seclevel↓, trap.destination.auth_username↓.

Possible values: text

4.1.10.20 trap.destination.auth_protocol

SNMP authentication protocol for IRP generated traps. Applicable only when SNMP v3 with authentication is used. Refer to trap.destination.version↓, trap.destination.seclevel↓.

0 - MD5
1 - SHA

Possible values: 0, 1

4.1.10.21 trap.destination.auth_username

SNMP user name for IRP generated traps. Applicable only when SNMP v3 with authentication is used. Refer to trap.destination.version↓, trap.destination.seclevel↓.

Possible values: text

4.1.10.22 trap.destination.community

Defines the SNMP community used for sending SNMP traps.

Possible values: textual community name

4.1.10.23 trap.destination.port

Defines the UDP port used for sending SNMP traps.

Possible values: 1 - 65535

Default value: 162

Recommended value: 162

4.1.10.24 trap.destination.priv_password

SNMP password for IRP generated traps. Applicable only when SNMP v3 with privacy is used. Refer to trap.destination.version↓, trap.destination.seclevel↓.

Possible values: text

4.1.10.25 trap.destination.priv_protocol

SNMP encryption protocol for IRP generated traps. Applicable only when SNMP v3 with privacy is used. Refer to trap.destination.version↓, trap.destination.seclevel↓.

0 - DES
1 - AES

Possible values: 0, 1

4.1.10.26 trap.destination.seclevel

SNMP security services for IRP generated traps. IRP supports either No security, Authentication only or both Authentication and Privacy. Applicable only when SNMP v3 is used (trap.destination.version↓). Depending on security services used further parameters should be configured, for example: trap.destination.auth_username↑, trap.destination.auth_password↑, trap.destination.auth_protocol↑, trap.destination.priv_password↑, trap.destination.priv_protocol↑.

0 - Neither Authentication nor Privacy
1 - Authentication only
2 - Authentication and Privacy

Possible values: 0, 1, 2

Default value: 0

4.1.10.27 trap.destination.version

SNMP version for IRP generated traps.

2 - SNMP v2c
3 - SNMP v3

Possible values: 2, 3

Default value: 2

4.1.10.28 trap.bgpd_announced_rate_low.limit_pct

Defines the announcements rate limit percentage.

Possible values: 1 - 100

Default value: 60

Recommended value: 60

4.1.10.29 trap.core_cc_improvements_spike.diff_pct

Defines the size (in percent) of the spike in the number of improvement compared to preceeding period average defined in trap.core_cc_improvements_spike.period_sec↓.

Possible values: 1 - 100

Default value: 50

4.1.10.30 trap.core_cc_improvements_spike.period_sec

Defines the time interval preceeding a spike. The number of improvements is averaged over this time and a spike event is triggered when the subsequent measurement exceeds the size (in percent) defined by trap.core_cc_improvements_spike.diff_pct↑.

Possible values: 30 - 86400

Default value: 300

4.1.10.31 trap.core_cc_overload.limit_mbps

Defines the overall overload limit in Mbps for the Commit Control overload by X Mbps event. The event is raised if the overall outbound traffic of the network exceeds the configured value (sum of peer.X.95th↓ for all providers) by this limit.

Possible values: 1 - 10000

Default value: 100

Recommended value: 100

4.1.10.32 trap.core_cc_overload.limit_pct

Defines the overall overload limit in percent for the Commit Control overload by X% event. The event is raised if the overall outbound traffic of the network exceeds the configured value (sum of peer.X.95th↓ for all providers) by this limit.

Possible values: 1 - 1000

Default value: 10

Recommended value: 10

4.1.10.33 trap.core_cc_provider_overload.limit_mbps

Defines the per provider overload limit in Mbps for the Commit Control provider X overloaded by Y Mbps event. The event is raised if the outbound traffic for a provider exceeds the configured value (refer peer.X.95th↓) by more than this limit.

Possible values: 1 - 10000

Default value: 100

Recommended value: 100

4.1.10.34 trap.core_cc_provider_overload.limit_pct

Defines the per provider overload limit in percent for the Commit Control provider X overloaded by Y% event. The event is raised if the outbound traffic for a provider exceeds the configured value (refer peer.X.95th↓) by more than this limit.

Possible values: 1 - 1000

Default value: 10

Recommended value: 10

4.1.10.35 trap.core_improvement_latency.limit_ms

Defines the packet latency limit in milliseconds.

Possible values: 1 - 10000

Default value: 300

Recommended value: 300

4.1.10.36 trap.core_improvement_loss.limit_pct

Defines the packet loss percentage limit.

Possible values: 1 - 100

Default value: 50

Recommended value: 50

4.1.11 Administrative settings

4.1.11.1 dbcron.api.log

Defines file-system path to the dbcron API log file.

Default value: /var/log/irp/api.mlog

4.1.11.2 dbcron.api.socket

Defines dbcron API listen socket.

Default value: /var/spool/irp/api

4.1.11.3 dbcron.log

Defines the file-system path to the dbcron log file.

Default value: /var/log/irp/dbcron.log

4.1.11.4 dbcron.log.level

Defines the logging level for the dbcron service.

Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug

Default value: info

Recommended value: info

4.1.11.5 irpstatd.log

Defines the file-system path to the irpstatd log file.

Default value: /var/log/irp/irpstatd.log

4.1.11.6 irpstatd.log.level

Defines the logging level for the irpstatd service.

Possible values: emerg, fatal, alert, crit, error, warn, notice, info, debug

Default value: info

Recommended value: info

4.1.11.7 irpstatd.snmp.enhanced.sec

Defines during what second of a minute the SNMP enhanced algorithm should run.

Possible values: 30-58

Default value: 45

Recommended value: 45

4.1.12 Providers settings

4.1.12.1 peer.X.95th

Mandatory if core.commit_control↑ is enabled.

Defines current provider’s desired 95th value (also known as Committed Interface Rate).

The value of peer.X.limit_load↓(if set to positive value) must be greater or equal to value of peer.X.95th↑.

Please refer to core.commit_control↑ and Commit Control↑ for Commit Control description.

Depending on the peer.X.95th.bill_day↓ parameter value, the behavior of the 95th level calculation has two different states.

If peer.X.95th.bill_day↓ is set to -1, then this parameter is treated as "committed interface rate limit" and actual 95th calculation is not performed. In this case, IRP will actively reroute traffic from an overloaded provider to keep it below the peer.X.95th↑ level.

If peer.X.95th.bill_day↓ is set to a positive value, then the system calculates the actual 95th value based on the historical traffic information from peer.X.95th.bill_day↓ to the current date of this month. Then, the result is compared to the peer.X.95th↑ value, and the maximum of these two is chosen as the target 95th. Thus, if the 95th for the current month has already exceeded the peer.X.95th↑ value, IRP will keep the traffic usage from increasing above current 95th.

Possible values: 1-9999999

4.1.12.2 peer.X.95th.bill_day

Defines the first billing period day. If current month has less days than the specified value, then last day of the month will be taken as the start of the new billing period. The parameter is used for 95th percentile calculation.

If -1 is specified, then peer.X.95th↑ is treated as "Committed Interface Rate".

Possible values: -1, 1-31

Default value: 1

Recommended value: First day of the billing period.

4.1.12.3 peer.X.95th.centile

Defines the actual percentage for the 95th percentile, as some providers may have non-standard traffic billing policies.

Possible values: 1-99

Default value: 95

Recommended value: please consult your agreements with this specific provider

4.1.12.4 peer.X.95th.in

Defines the 95th level (in Mbps) for inbound when inbound and outbound commit control operate independently. Refer peer.X.95th↑, peer.X.95th.mode↓.

Possible values: 1-1000000

4.1.12.5 peer.X.95th.mode

Defines the way how 95th value is determined. The following modes are supported:

0: Separate 95th for in/out
2: 95th from greater of in or out
3: Largest of the two 95th for in/out

Only mode with separate 95th for each inbound and outbound traffic keeps inbound and outbound commit control independent of each other.

Refer also peer.X.95th↑, peer.X.95th.in↑.

Possible values: 0-3

Default value: 2

4.1.12.6 peer.X.auto_config

Enables or disables periodic execution of Internet Exchanges auto re-configuration process once per 4.1.2.6↑ interval.

Explorer will be restarted after the process is completed.

Possible values: 0 (Disabled), 1 (Enabled)

Default value: 0

4.1.12.7 peer.X.bgp_peer

Mandatory

Defines the iBGP session(s) over which an improvement made for this provider is advertised. This parameter should be set to a valid BGP neighbor name as defined in BGP sessions settings↑. Typically, this is the session with the Edge router, which this provider is connected to. Multiple sessions should be set only if there are some additional (backup) links to this provider on multiple Edge routers.

Possible values: One or a list of valid BGP neighbor names, as defined in BGP sessions settings↑.

4.1.12.8 peer.X.bmp

Defines BMP data usage for this provider.

0: Do not use BMP data
1: Use BMP data if available
2: Use BMP data only

Possible values: 0 - 2

Default value: 0

4.1.12.9 peer.X.cc_disable

Instructs IRP to exclude this provider from the Commit Control algorithm.

Has effect only if core.commit_control↑ is enabled.

Possible values: 0, 1

Default value: 0

4.1.12.10 peer.X.circuit.control

Defines whether provider will be monitored for excessive loss issues and how to react to them. The possible values are:

0: Disabled
1: Warn only
2: Warn and disconnect
3: Disconnect and restore

IRP tries to induce a disconnect of BGP session via FlowSpec rules that drop any further packets on the BGP session with provider’s router. It is thus recommended that the keepalive timer is set to 20 seconds for BGP sessions with providers that are expected to be disconnected if circuit issues are detected on them. This will minimize the time a circuit with excessive loss is kept operational and causes harm.

Possible values: 0-3

Default value: 0

4.1.12.11 peer.X.cost

Defines the cost per Mbps for the current provider. All peer.X.cost↑ parameters should be specified in the same currency.

Parameter’s value should be the same for each provider in a provider’s group (refer to 4.1.12.57↓) and cost mode is enabled (4.1.2.24↑)

Possible values: 1-’unlimited’

Default value: 0

4.1.12.12 peer.X.description

Defines the provider’s description (full provider name)

Possible values: text

4.1.12.13 peer.X.diag_hop.interval_max

Defines maximum value for Adaptive Inter-Packet Interval. Adaptive Inter-Packet Interval is used while sending packets to a specific Provider’s router (packets with a specific TTL). Inter-packet interval is raised up to the maximum value when the router does not respond to the packets and is decreased to the minimum one in case the router responds. The Adaptive Inter-Packet Interval is changed gradually to obtain better performance.

A value of the 4.1.9.6↑ parameter is used in case zero value is specified in this parameter.

Possible values: 0 - 50000000 (50 ms)

Default value: 0

4.1.12.14 peer.X.diag_hop.interval_min

Defines minimum value for Adaptive Inter-Packet Interval. Adaptive Inter-Packet Interval is used while sending packets to a specific Provider’s router (packets with a specific TTL). Inter-packet interval is raised up to the maximum value when the router does not respond to the packets and is decreased to the minimum one in case the router responds. The Adaptive Inter-Packet Interval is changed gradually to obtain better performance.

Possible values: 10000 (0.01 ms) - 10000000 (10 ms)

Default value: 1000000

4.1.12.15 peer.X.disable_pbr_confirmation

Set to disable periodic transit/partial routing provider’s PBR confirmation check.

Possible values: 0 (Disabled), 1 (Enabled)

Default value: 0

Recommended value: 0

4.1.12.16 peer.X.flowspec.ipv4.redirect_community

Defines the BGP Community that will be appended by BGPd to advertised Flowspec redirect policies for IPv4 sessions. The format is: “X:Y”.

Avoid colisions of communities values assigned to IRP both within its configuration and/or on customer’s network.

4.1.12.17 peer.X.flowspec.ipv6.redirect_community

Defines the BGP Community that will be appended by BGPd to advertised Flowspec redirect policies for IPv6 sessions. The format is: “X:Y”.

Avoid colisions of communities values assigned to IRP both within its configuration and/or on customer’s network.

4.1.12.18 peer.X.flow_agents

Specifies a collection of Flow agents in the form IPv4/interfaceIdentifier. Flow agents are used to assign specific Flow statistics to a designated provider. Refer Flow agents↑, Optimization for multiple Routing Domains↑ for details.

Possible values: forward slash separated IP address and numeric identifier in 1..2147483647 range

4.1.12.19 peer.X.group_loadbalance

Defines whether commit control algorithm load balances the group of providers or optimizes it on aggregated bandwidth usage. For details refer Provider load balancing↑ and Commit control of aggregated groups↑.

Possible values: 0 (Disabled), 1 (Enabled)

Default value: 1

4.1.12.20 peer.X.improve_in_group

Enables or disables improvements within a provider group. This parameter must be equal for all providers in a provider group.

If disabled, IRP will not make any Cost or Performance improvements inside the group.

Possible values: 0 (OFF), 1 (ON)

Default value: 0

Recommended value: depends on network infrastructure and policies

4.1.12.21 peer.X.inbound.community_base

Defines the base community of consecutive range of eight community values which IRP uses to announce inbound improvements for this provider over BGP. Base community instructs an announcement of a route without any additional prepend via a particular provider. Next communities in the range instructs for additional prepends from one up to seven.

For example: when peer.1.inbound.community_base is set to 65530:50100, the value 65530:50102 represents “prepend 2 times while advertizing to provider 1”.

Possible values: valid BGP community attribute

4.1.12.22 peer.X.ipv4.diag_hop

Mandatory

Defines the diagnostic hop or subnet in CIDR format for the current provider. Usually, it is the IP address of the first hop of the specific provider. The parameter is used to make sure that a route actually passes through this provider.

It is also used for Internet Exchanges autoconfiguration process. The Peering Partners next-hops will be gathered based on the provided subnet(s) in CIDR format.

Any parameter changes (via Frontend) will caused the BGPd component restart if the provider type (peer.X.type↓) is Internet Exchanges

Possible values: valid IPv4 address (usually equal to peer.X.ipv4.next_hop↓) or subnet definition in CIDR format

4.1.12.23 peer.X.ipv4.master_probing

Mandatory

Defines the local IPv4 address, assigned for probing via the current provider. When failover is enabled (global.failover↑) slave’s probing IP (peer.X.ipv4.slave_probing↓) must be configured too.

Possible values: valid local IPv4 address

4.1.12.24 peer.X.ipv4.mon

Defines the List of IPv4 addresses to be monitored by BGPd to ensure that the immediate upstream path through this provider is operational. Each specified IP address is probed every bgpd.mon.keepalive↑ seconds to verify accessibility from BGPd (ICMP/UDP pings are used). Highly available IP addresses that reliably answer to ICMP/UDP pings should be used. It is remommended to setup at least two IP addresses belonging to different networks.

If all monitored IP addresses do not respond for bgpd.mon.holdtime↑ seconds, then any improvements designated for this provider will be withdrawn from edge router(s). Improvements will be re-announced after all IP addresses respond within bgpd.mon.guardtime↑ seconds.

Possible values: space-separated list of valid IPv4 addresses

Default value: 208.67.222.222 8.8.8.8

4.1.12.25 peer.X.ipv4.next_hop

Mandatory

Defines the next-hop IPv4 address for BGP route injection. Usually, it is the IPv4 address of the BGP partner from the provider.

Possible values: valid IPv4 address

4.1.12.26 peer.X.ipv4.next_hop_as

Defines the provider autonomous system number for IPv4. This parameter must be set in order for the 3rd algorithm of BGPd AS-PATH to work properly (refer to bgpd.as_path↑).

If this parameter is set, then it’s value will be used as part of AS-PATH for outgoing improvements if the 3rd algorithm is enabled in bgpd.as_path↑.

In case of Internet Exchanges, the AS-Path begins with peering partner’s AS number, instead of AS number of route server.

The first AS number will be stripped from AS-Path when advertising improvement towards Exchange in case the first AS number is equal to value set in this parameter.

Possible values: 0-4294967295

Default value: 0

4.1.12.27 peer.X.ipv4_pbr_check

Defines per-provider alternative IPv4 address to be used for PBR tests. This overrides explorer.ipv4_test↑.

4.1.12.28 peer.X.ipv4.route_server

Defines the Internet Exchange Route Server(s) IP address(es) used to properly auto-configure provider.X.rule.Y.bgp_peer↓ parameter.

Possible values: valid IPv4 address(es)

4.1.12.29 peer.X.ipv4.slave_probing

Defines the local IPv4 address, assigned for probing via the current provider for the slave node in a failover configuration.

4.1.12.30 peer.X.ipv6.diag_hop

Mandatory

Defines the IPv6 diagnostic hop for the current provider. Usually, it is the IP address of the first hop of the specific provider. The parameter is used to verify that a route actually passes through this provider.

Possible values: valid IPv6 address, usually equals to peer.X.ipv6.next_hop↓

4.1.12.31 peer.X.ipv6.master_probing

Mandatory for IPv6

Defines the local IPv6 address assigned for probing via the current provider. When failover is enabled (global.failover↑) slave’s probing IPv6 address (peer.X.ipv4.slave_probing↑) must be configured too.

Possible values: valid local IPv6 address

4.1.12.32 peer.X.ipv6.mon

Defines the List of IPv6 addresses to be monitored by BGPd to ensure that the immediate upstream path through this provider is operational. Each specified IP address is probed every bgpd.mon.keepalive↑ seconds to verify accessibility from BGPd (ICMP/UDP pings are used). Highly available IP addresses that reliably answer to ICMP/UDP pings should be used. It is remommended to setup at least two IP addresses belonging to different networks.

If all IP addresses do not respond for bgpd.mon.holdtime↑ seconds, then any improvements designated for this provider will be withdrawn from the edge router(s). Improvements will be announced again after all IP addresses respond within bgpd.mon.guardtime↑ seconds.

Possible values: space-separated list of valid IPv6 addresses

Default value: 2620:0:ccc::2 2001:4860:4860::8888

4.1.12.33 peer.X.ipv6.next_hop

Mandatory for IPv6

Defines the next-hop IPv6 address for BGP route injection. Usually, it is the IPv6 address of the BGP partner from the provider.

Possible values: valid IPv6 address

4.1.12.34 peer.X.ipv6.next_hop_as

Defines the provider autonomous system number for IPv6. This parameter must be set in order for the 3rd algorithm of BGPd AS-PATH to work properly (refer to bgpd.as_path↑).

If this parameter is set, then it’s value will be used as part of an AS-PATH for outgoing improvements if the 3rd algorithm is enabled in bgpd.as_path↑.

Possible values: 0-4294967295

Default value: 0

4.1.12.35 peer.X.ipv6.route_server

Defines the Internet Exchange Route Server(s) IP address(es) used to properly auto-configure provider.X.rule.Y.bgp_peer↓ parameter.

Possible values: valid IPv6 address(es)

4.1.12.36 peer.X.ipv6.slave_probing

Defines the local IPv6 address assigned for probing via the current provider for the slave node in a failover configuration.

4.1.12.37 peer.X.ipv6_pbr_check

Defines per-provider alternative IPv6 address to be used for PBR tests. This overrides explorer.ipv6_test↑.

4.1.12.38 peer.X.limit_load

Defines the load limit for current provider. IRP will improve routes to this provider as long as its load is less than the specified value in megabits per second. SNMP must be properly configured in order for this feature to work properly. If this limit is configured, but it is impossible to retrieve interface data, no new improvements will take place.

The value of peer.X.limit_load↑(if set to positive value) must be greater or equal to value of peer.X.95th↑.

Possible values: -1(unlimited), 1-1000000

Default value: -1

Recommended value: it is recommended to set it to not more than ~60-80% of the physical interface rate

4.1.12.39 peer.X.mon.enabled

Defines the BGP Monitoring behavior for this provider. Several values are possible:

0 - BGP Monitoring is disabled for this provider
1 - ICMP BGP monitoring is enabled
2 - SNMP BGP monitoring is enabled
3 - Both SNMP and ICMP BGP monitoring is enabled

4.1.12.40 peer.X.mon.ipv4.bgp_peer

Defines the current provider’s IPv4 address that must be monitored by BGPd, usually equal to

peer.X.ipv4.next_hop↑

Possible values: valid IPv4 address

4.1.12.41 peer.X.mon.ipv4.internal.mode

Specifies router supported BGP MIB to monitor this provider IPv4 BGP sessions.

0 - Generic (BGP4-MIB)
1 - Cisco (CISCO-BGP4-MIB)
2 - Juniper (BGP4-V2-MIB-JUNIPER)
3 - Brocade (draft-ietf-idr-bgp4-mibv2-12)

Possible values: 0, 1, 2, 3

Default value: 0

4.1.12.42 peer.X.mon.ipv6.bgp_peer

Defines the current provider’s IPv6 address that must be monitored by BGPd, usually equal to

peer.X.ipv6.next_hop↑

Possible values: valid IPv6 address

4.1.12.43 peer.X.mon.ipv6.external.enabled

Enables or disables external monitors for IPv6.

Possible values: 0 (Disabled), 1 (Enabled)

Default value: 0

4.1.12.44 peer.X.mon.ipv6.internal.enabled

Enables or disables internal monitors for IPv6.

Possible values: 0 (Disabled), 1 (Enabled)

Default value: 0

4.1.12.45 peer.X.mon.ipv6.internal.mode

Specifies router supported BGP MIB to monitor this provider IPv6 BGP sessions.

1 - Cisco (CISCO-BGP4-MIB)
2 - Juniper (BGP4-V2-MIB-JUNIPER)
3 - Brocade (draft-ietf-idr-bgp4-mibv2-12)

Possible values: 1, 2, 3

4.1.12.46 peer.X.mon.snmp

Identifier of SNMP host to use for monitoring this provider. Refer to SNMP Hosts settings↓, snmp.X.name↓.

Possible values: text

4.1.12.47 peer.X.mon.snmp.auth_password

Kept for backwards compatibility with IRP 3.6 and earlier. Parameter is deprecated in IRP 3.7 and will be removed in future versions. Refer SNMP hosts configuration↑ and SNMP Hosts settings↓ for new SNMP configuration.

SNMP user’s password for monitoring provider. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↓, peer.X.mon.snmp.seclevel↓, peer.X.mon.snmp.auth_username↓.

Possible values: text

4.1.12.48 peer.X.mon.snmp.auth_protocol

SNMP authentication protocol for monitoring provider. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↓, peer.X.mon.snmp.seclevel↓.

0 - MD5
1 - SHA

Possible values: 0, 1

4.1.12.49 peer.X.mon.snmp.auth_username

SNMP user name for monitoring provider. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↓, peer.X.mon.snmp.seclevel↓.

Possible values: text

4.1.12.50 peer.X.mon.snmp.community

Defines the SNMP community for retrieving monitoring statistics.

Possible values: textual community name

4.1.12.51 peer.X.mon.snmp.ip

Defines the IPv4 address for retrieving SNMP monitoring statistics (use either peer.X.mon.snmp.ip↑ or peer.X.mon.snmp.ipv6↓)

Possible values: IPv4 address

4.1.12.52 peer.X.mon.snmp.ipv6

Defines the IPv6 address for retrieving SNMP monitoring statistics (use either peer.X.mon.snmp.ip↑ or peer.X.mon.snmp.ipv6↑)

Possible values: IPv6 address

4.1.12.53 peer.X.mon.snmp.priv_password

SNMP password for monitoring provider. Applicable only when SNMP v3 with privacy is used. Refer to peer.X.mon.snmp.version↓, peer.X.mon.snmp.seclevel↓.

Possible values: text

4.1.12.54 peer.X.mon.snmp.priv_protocol

SNMP encryption protocol for monitoring provider. Applicable only when SNMP v3 with privacy is used. Refer to peer.X.mon.snmp.version↓, peer.X.mon.snmp.seclevel↓.

0 - DES
1 - AES

Possible values: 0, 1

4.1.12.55 peer.X.mon.snmp.seclevel

SNMP security services for monitoring provider. IRP supports either No security, Authentication only or both Authentication and Privacy. Applicable only when SNMP v3 is used (peer.X.mon.snmp.version↓). Depending on security services used further parameters should be configured, for example: peer.X.mon.snmp.auth_username↑, peer.X.mon.snmp.auth_password↑, peer.X.mon.snmp.auth_protocol↑, peer.X.mon.snmp.priv_password↑, peer.X.mon.snmp.priv_protocol↑.

0 - Neither Authentication nor Privacy
1 - Authentication only
2 - Authentication and Privacy

Possible values: 0, 1, 2

Default value: 0

4.1.12.56 peer.X.mon.snmp.version

SNMP version for monitoring provider.

2 - SNMP v2c
3 - SNMP v3

Possible values: 2, 3

Default value: 2

4.1.12.57 peer.X.precedence

Mandatory if core.commit_control↑ is enabled.

Defines this provider’s precedence, used for provider grouping and defining commit priorities.

See core.commit_control↑ and Commit Control↑ for Commit Control functionality.

All providers belonging to one group must have equal cost (peer.X.cost↑)

If two different providers have the same peer.X.precedence↑ value, then these providers are considered to be a group, and traffic is balanced between them.

The provider or a group with the lowest precedence value are also used by Commit Control as last resort destination (if all the providers are exceeding their 95th, then traffic is rerouted to the upstream with the smallest precedence - usually this upstream has either the highest throughput, or the lowest cost).

For example:

peer.1.precedence	= 20
peer.2.precedence	= 10
peer.3.precedence	= 30

If the peer.X.95th↑ is exceeded for all configured providers, then the excessive traffic from providers 1 and 3 will be rerouted to the 2nd provider.

If provider groups are used:

peer.1.precedence	= 50
peer.2.precedence	= 40
peer.3.precedence	= 40
peer.4.precedence	= 40
peer.5.precedence	= 30

Traffic between providers 2, 3 and 4 is evenly distributed. If all providers are already overloaded, then the excessive traffic will be rerouted to the 5th provider (since it has the lowest precedence value).

Possible values: 0-100

4.1.12.58 peer.X.rd

Assigns a routing domain identifier to the provider. Providers in the same routing domains should be assigned the same identifier.

Providers with identifier 1 (one) are assumed to be in the same routing domain that hosts IRP instance.

Refer global.rd_rtt↑, peer.X.flow_agents↑, bgpd.rd_local_mark↑.

Possible values: 1-100

Default value: 1

4.1.12.59 peer.X.routes_config

Defines whether Internet Exchanges auto configuration is enabled or not. In case it is enabled, IRP BGPd gathers Peering Partners (next-hops) with their announced routes and stores the data in IRP database. Otherwise, manual configuration is required.

Possible values: 0(OFF), 1(ON)

Default value: 1

Recommended value: 1

4.1.12.60 peer.X.shortname

Mandatory

Defines the provider’s short, abbreviated name (3-20 characters). This parameter’s value is used for reports and graphs.

Possible values: text

4.1.12.61 peer.X.shutdown

Defines whether provider is Active (0), Suspended (1) or Shutdown (2).

After the provider suspend action, all the improvements will be stored for short period of time (1h). In case of short maintenance windows, use provider suspend.

After the provider shutdown action, all the improvements will be removed. In case of long maintenance windows, use provider shutdown.

After the provider reactivation (after a previous suspend), all the improvements will be sent to retry probing.

The provider state can be updated in Frontend or using the irpPeerSuspendShutdown.pl script.

In order to get the provider suspended, shutdown or reactivated, use the irpPeerSuspendShutdown.pl helper script.

Usage: /usr/bin/irpPeerSuspendShutdown.pl [-a] [-p] [-h]

-a|--action        - Perform an action under a peer.
                     Possible values:
                         0 or ’activate’
                         1 or ’suspend’
                         2 or ’shutdown’
-p|--peerId        - An ID of the peer that should be Activated, Shutdown or Suspended
-h|--help          - Print this help

Possible values: 0, 1, 2

Default value: 0

4.1.12.62 peer.X.snmp.auth_password

SNMP user’s password for collecting statistics for provider. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↑, peer.X.mon.snmp.seclevel↑, peer.X.snmp.auth_username↓.

Possible values: text

4.1.12.63 peer.X.snmp.auth_protocol

SNMP authentication protocol for collecting statistics for provider. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↑, peer.X.mon.snmp.seclevel↑.

0 - MD5
1 - SHA

Possible values: 0, 1

4.1.12.64 peer.X.snmp.auth_username

SNMP user name for collecting statistics for provider. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↑, peer.X.mon.snmp.seclevel↑.

Possible values: text

4.1.12.65 peer.X.snmp.community

Defines the SNMP community for retrieving interface counters.

Possible values: textual community name

4.1.12.66 peer.X.snmp.enhanced

Enables or disables heuristically enhanced SNMP collection for provider.

Possible values: 0 (Disabled), 1 (Enabled)

Default value: 0

4.1.12.67 peer.X.snmp.interface

Defines the interface used for the interconnection to the current provider. It can be either an integer value specifying the interface ifIndex, or a textual interface description.

Possible values: Integer value, or textual interface description

Recommended value: textual interface description

4.1.12.68 peer.X.snmp.interfaces

Defines a collection of interfaces used for current provider. Individual values are in the form SNMPHostID:Interface where

SNMPHostID is the identifier of an SNMP host configured under 4.1.17↓
Interface could be specified either by SNMP index (ifIndex) or by name (ifDescr).

Possible values: collection of SNMPHostID:Interface pairs

4.1.12.69 peer.X.snmp.ip

Defines the IPv4 address that should be polled for SNMP interface counters.

peer.X.snmp.ip↑ and peer.X.snmp.ipv6↓ are mutually exclusive.

Possible values: valid IPv4 address

4.1.12.70 peer.X.snmp.ipv6

Defines the IPv6 address that should be polled for SNMP interface counters.

peer.X.snmp.ip↑ and peer.X.snmp.ipv6↑ are mutually exclusive.

Possible values: valid IPv6 address

4.1.12.71 peer.X.snmp.priv_password

SNMP password for collecting statistics for provider. Applicable only when SNMP v3 with privacy is used. Refer to peer.X.snmp.version↓, peer.X.snmp.seclevel↓.

Possible values: text

4.1.12.72 peer.X.snmp.priv_protocol

SNMP encryption protocol for collecting statistics for provider. Applicable only when SNMP v3 with privacy is used. Refer to peer.X.snmp.version↓, peer.X.snmp.seclevel↓.

0 - DES
1 - AES

Possible values: 0, 1

4.1.12.73 peer.X.snmp.seclevel

SNMP security services for collecting statistics for provider. IRP supports either No security, Authentication only or both Authentication and Privacy. Applicable only when SNMP v3 is used (peer.X.snmp.version↓). Depending on security services used further parameters should be configured, for example: peer.X.snmp.auth_username↑, peer.X.snmp.auth_password↑, peer.X.snmp.auth_protocol↑, peer.X.snmp.priv_password↑, peer.X.snmp.priv_protocol↑.

0 - None - neither Authentication nor Privacy is used
1 - Authentication only
2 - Authentication and Privacy

Possible values: 0, 1, 2

Default value: 0

4.1.12.74 peer.X.snmp.version

SNMP version for collecting statistics for provider.

2 - SNMP v2c
3 - SNMP v3

Possible values: 2, 3

Default value: 2

4.1.12.75 peer.X.type

Defines the type of a provider. The following types are available:

0 - Transit provider
1 - Partial routes provider
2 - Exchanges provider

Possible values: 0, 1, 2

Default value: 0

4.1.13 Inbound parameters

4.1.13.1 inbound.rule.X.bgp_peer

Defines the router(s) where IRP announces improvements of this inbound prefix.

Possible values: a router identifier(s) separated by space

4.1.13.2 priority

Defines what policy to prioritize in case of overlapping prefixes as might be the case of a large aggregate prefix policy extending over an ASN policy. The same specific prefixes might be covered by both and priority sets which one to actually enforce in favor of the others. Policies with higher priority are prioritized.

Possible values: 0-50

Default value: 0

4.1.13.3 inbound.rule.X.enabled

Enables or disables Inbound Optimization for this prefix.

Possible values: 0 (Disabled), 1(Enabled)

Default value: 1

4.1.13.4 inbound.rule.X.full_control

Specifies individual inbound prefix control level by IRP. Default behavior can be set at system level under bgpd.full_control↑. The settings specify whether default behavior is inherited from the system level or set individually for this prefix to announce either Improvements only or fully announce the prefix to allowed providers.

Refer to Inbound prefixes full control↑ for details.

Possible values: -1 (Use default), 0 (Improvement), 1(Full)

Default value: -1

4.1.13.5 inbound.rule.X.next_hop

Defines a next_hop specific for the inbound rule. When the next_hop is unset, then a value from bgpd.peer.X.inbound.ipv4.next_hop↑/bgpd.peer.X.inbound.ipv6.next_hop↑ is taken.

Next-hop should point to a router that routes/terminates traffic. Otherwise null route should be configured for the Next-Hop.

next_hop value should be of the same IP address family as the inbound prefix it is assigned to. Refer inbound.rule.X.prefix↓.

Possible values: IP address

4.1.13.6 inbound.rule.X.prefix

Defines an inbound prefix. Inbound prefixes should belong to your network.

Inbound Optimization of transit networks will be supported in future releases.

Each inbound prefix logically extends the list of ournets when it is processed by IRP Collector. Refer collector.ournets↑.

Possible values: prefix in CIDR format

4.1.13.7 inbound.rule.X.providers

Defines the list of providers where this inbound prefix can be advertised. In case this parameter value is empty then it is treated as prefix will be advertised to ALL providers.

Possible values: providerIDs collection

4.1.14 Routing Policies settings

4.1.14.1 asn/prefix

Defines the ASN or the prefix to which the routing policy is applied.

Possible values: 1-65535 for an ASN or a valid IPv4/IPv6 prefix.

4.1.14.2 cascade

Defines the ASN policies that cascade to downstream AS from designated AS. The parameter applies to ASN policies (and not to prefixes).

Possible values: 0(Disable), 1(Enable)

Default value: 0

4.1.14.3 community

A community to mark improvements belonging to a policy.

Possible values: X:Y

4.1.14.4 enabled

Defines whether the policy is enabled or not

Possible values: 0(OFF), 1(ON)

Default value: 1

4.1.14.5 forcelocal

A flag indicating if a global improvement disallowed.

Possible values: 0(OFF), 1(ON)

Default value: 0

4.1.14.6 notes

Defines a description of the routing policy

Possible values: text

Routing Policy working example:

asn=1122
vip=0
policy=deny
providers=1 3 5
enabled=1
notes=AN1122 deny via Level3, Cogent and nLayer

4.1.14.7 policy

Defines the type of policy

Possible values: allow, deny, static

Default value: allow

4.1.14.8 providers

Defines the list of providers (IDs) affected by the policy. If the ’providers’ property is not specified, then all the providers will be included in the policy by default.

Possible values: 1-unlimited

4.1.14.9 vip

Defines whether the VIP probing is enabled for the specified ASN/prefix

Possible values: 0(OFF), 1(ON)

Default value: 0

4.1.15 Exchanges settings

4.1.15.1 provider.X.rule.Y.bgp_peer

Defines the BGP Router-ID used for BGP session state monitoring, which is performed by the Internal BGP Monitor (BGP Monitoring↑).

Depending on whether a Route Server or Peering sessions are used, the parameter value should be set to Route Server Router-ID or Peering Partner Router-ID accordingly.

Possible values: IPv4 address

4.1.15.2 provider.X.rule.Y.enabled

Defines whether the rule is enabled or not.

Possible values: 0(OFF), 1(ON)

Default value: 1

4.1.15.3 provider.X.rule.Y.next_hop

Defines the Peering Partner’s IPv4/IPv6 next-hop address.

Possible values: IPv4/IPv6 address

4.1.15.4 provider.X.rule.Y.probing_dscp

Defines the DSCP (Differentiated services code point) used with provider.X.rule.Y.probing_ip↓ for a specific Peering Partner.

Possible values: 0-63

4.1.15.5 provider.X.rule.Y.probing_ip

Defines the probing IPv4/IPv6 address used for a specific Peering Partner.

Possible values: IPv4/IPv6 address

4.1.15.6 provider.X.rule.Y.shortname

Defines a short name for a configured Peering Partner.

Possible values: text

4.1.15.7 provider.X.rule.Y.pbr_check

Defines if PBR check for a configured Peering Partner is enabled or not.

Possible values: 0(OFF), 1(ON)

Default value: 1

4.1.16 User Directory settings

4.1.16.1 directory.X.admin_role_groups

Defines the specific objects/groups that list IRP users with Admin privileges. Also refer directory.X.user_role_attr↓.

Possible values: text

4.1.16.2 directory.X.base_dn

Defines the base DN (distinguished name) of users in the directory. Base DN is used in conjunction with directory.X.username↓ and directory.X.user_dn↓ to uniquily identify and query the directory during authentication.

Possible values: text

4.1.16.3 directory.X.email

Defines the directory attribute that stores user’s email address.

Possible values: text

4.1.16.4 directory.X.fullname

Defines the directory attribute that stores user’s full name.

Possible values: text

4.1.16.5 directory.X.hostname

Defines the hostname or the IP address of the User Directory.

Possible values: domain name or IP address

4.1.16.6 directory.X.initial_bind_dn

Defines User DN assigned to IRP to bind to directory. This user’s password is configured in directory.X.initial_bind_password↓.

Possible values: text

4.1.16.7 directory.X.initial_bind_password

Defines the password assigned to IRP to bind to directory. Refer directory.X.initial_bind_dn↑.

Possible values: text

4.1.16.8 directory.X.name

Assigns a name to user directory within IRP.

Possible values: text

4.1.16.9 directory.X.order

Defines the sequence this user directory is queried when multiple user directories are configured. Smaller values take precedence.

The value must be unique across configured user directories.

Possible values: 0-255

Default value: 255

4.1.16.10 directory.X.port

Defines the port used by the directory, for example 389 for LDAP.

Possible values: 0-65535

4.1.16.11 directory.X.secret

Defines the shared secret for TACACS+ host and IRP to secure communications.

Possible values: text

4.1.16.12 directory.X.state

Enables or disables use of this directory within IRP.

Possible values: 0(Disabled), 1(Enabled)

Default value: 1

4.1.16.13 directory.X.timeout

Defines the timeout (in seconds) after which IRP stops trying to communicate with the directory.

Possible values: 0-300

Default value: 60

4.1.16.14 directory.X.tls

Enables or disables use of TLS for this directory.

Possible values: 0(Disabled), 1(Enabled)

Default value: 0

4.1.16.15 directory.X.tls_cacertfile

Defines the path to a CA certificate file used when server certificate validation is enabled and CA certificate cannot be included in trusted server certificates store, for example a single purpose self-signed CA certificate is used. Refer directory.X.verify_cert↓.

Possible values: text (path)

4.1.16.16 directory.X.type

Defines user directory type for example LDAP, Active Directory, Internal etc.

Possible values: internal, ldap_posix, active_directory...

Default value: internal

4.1.16.17 directory.X.user_dn

Defines the DN of users. User DN is used in conjunction with directory.X.username↓ and directory.X.base_dn↑ to uniquely identify and query the directory during authentication. Only users matching directory.X.user_filter↓ are granted access to the system.

Possible values: text

4.1.16.18 directory.X.user_filter

Defines a filter used to match users that will be granted access. The filter uses standard LDAP filter syntax with the exception of outermost paranthesis that are expected to be dropped from configuration.

Possible values: text

4.1.16.19 directory.X.user_role_attr

Defines the attribute that stores the list of users in a role/group. Refer directory.X.admin_role_groups↑.

Possible values: text

4.1.16.20 directory.X.username

Defines the directory attribute that represents the username of users in the directory. This attribute together with directory.X.user_dn↑ and directory.X.base_dn↑ are used to uniquely identify and query the directory during authentication.

Possible values: text

4.1.16.21 directory.X.verify_cert

Enables or disables verification of directory server certificate when TLS is enabled. When verification is enabled a path to CA certificate file must be provided too. Refer directory.X.tls↑, directory.X.tls_cacertfile↑.

Possible values: 0(Disabled), 1(Enabled)

Default value: 0

4.1.17 SNMP Hosts settings

4.1.17.1 snmp.X.auth_password

User’s password used to authenticate SNMP communications. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↑, peer.X.mon.snmp.seclevel↑, snmp.X.auth_username↓.

Possible values: text

4.1.17.2 snmp.X.auth_protocol

SNMP authentication protocol. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↑, peer.X.mon.snmp.seclevel↑.

0 - MD5
1 - SHA

Possible values: 0, 1

4.1.17.3 snmp.X.auth_username

SNMP user name. Applicable only when SNMP v3 with authentication is used. Refer to peer.X.mon.snmp.version↑, peer.X.mon.snmp.seclevel↑.

Possible values: text

4.1.17.4 snmp.X.community

Mandatory parameter

Defines the SNMP community for retrieving interface counters.

Possible values: textual community name

4.1.17.5 snmp.X.ip

Defines IPv4/IPv6 address of the SNMP host.

Hostnames are not supported.

Possible values: valid IPv4 or IPv6 address

4.1.17.6 snmp.X.priv_password

Password used to encrypt SNMP communications. Applicable only when SNMP v3 with privacy is used. Refer to snmp.X.version↓, snmp.X.seclevel↓.

Possible values: text

4.1.17.7 snmp.X.priv_protocol

SNMP encryption protocol. Applicable only when SNMP v3 with privacy is used. Refer to snmp.X.version↓, snmp.X.seclevel↓.

0 - DES
1 - AES

Possible values: 0, 1

4.1.17.8 snmp.X.seclevel

SNMP security services. IRP supports either No security, Authentication only or both Authentication and Privacy. Applicable only when SNMP v3 is used (snmp.X.version↓). Depending on security services used further parameters should be configured, for example: snmp.X.auth_username↑, snmp.X.auth_password↑, snmp.X.auth_protocol↑, snmp.X.priv_password↑, snmp.X.priv_protocol↑.

0 - None - neither Authentication nor Privacy is used
1 - Authentication only
2 - Authentication and Privacy

Possible values: 0, 1, 2

Default value: 0

4.1.17.9 snmp.X.name

Sets a shortname for SNMP host.

Possible values: text

4.1.17.10 snmp.X.version

SNMP version used by host.

2 - SNMP v2c
3 - SNMP v3

Possible values: 2, 3

Default value: 2

4.1.18 Routing domains settings

4.1.18.1 rd.X.community_worsening

A BGP community value. The routing domain designated community value is added to announced global outbound improvement if it degraded performance within allowd worsening thresholds.

Possible values: valid BGP community attribute

4.1.18.2 rd.X.shortname

A shortname assigned to each routing domain for human readability.

Possible values: text

< Previous | Next >

Company News

Blog

About Us

Press Releases

Careers

Support

When Critical Infrastructure is Vulnerable: Rethinking Network Resilience

Noction IRP Quote

NFA Pricing

IRP Resources

White Papers

Case Studies

Videos

Manuals

Tier 1 Reports

IRP FAQ

NFA Resources

NFA Documentation

Tips and Tricks

NFA FAQ

Guides & eBooks

NOC as a Service

IP Transit Providers Assessment

Tier 1s Performance Dashboard

Tier 1 Carriers Report - October 2024

Noction IRP

Noction IRP Lite

Noction Flow Analyzer

IRP Installation and Configuration Guide

4 Configuration parameters reference

4.1 Complete parameters list

4.1.1 Database credentials

4.1.1.1 db.clickhouse.dbname

4.1.1.2 db.clickhouse.host

4.1.1.3 db.clickhouse.password

4.1.1.4 db.clickhouse.port

4.1.1.5 db.clickhouse.username

4.1.1.6 db.dbname

4.1.1.7 db.host

4.1.1.8 db.ourhost

4.1.1.9 db.password

4.1.1.10 db.port

4.1.1.11 db.username

4.1.2 Global parameters

4.1.2.1 global.aggregate

4.1.2.2 global.bw_overusage

4.1.2.3 global.agg_ipv4_max

4.1.2.4 global.agg_ipv6_max

4.1.2.5 global.exchanges

4.1.2.6 global.exchanges.auto_config_interval

4.1.2.7 global.failover

4.1.2.8 global.failover.log

4.1.2.9 global.failover_identity_file

4.1.2.10 global.failover_role

4.1.2.11 global.failover_slave.ip

4.1.2.12 global.failover_slave.ipv6

4.1.2.13 global.failover_slave.port

4.1.2.14 global.failover_timer_fail

4.1.2.15 global.failover_timer_failback

4.1.2.16 global.flowspec

4.1.2.17 global.flowspec.pbr

4.1.2.18 global.frontend_acl

4.1.2.19 global.frontend_acl_ips

4.1.2.20 global.ifstats

4.1.2.21 global.ignored.asn

4.1.2.22 global.ignored_communities

4.1.2.23 global.ignorednets

4.1.2.24 global.improve_mode

4.1.2.25 global.inbound_conf

4.1.2.26 global.inbound_transit

4.1.2.27 global.ipv6_enabled

4.1.2.28 global.master_management_interface

4.1.2.29 global.slave_management_interface

4.1.2.30 global.nonintrusive_bgp

4.1.2.31 global.offpeak_hour

4.1.2.32 global.outbound

4.1.2.33 global.png.datadir

4.1.2.34 global.policies

4.1.2.35 global.master_probing_interface

4.1.2.36 global.slave_probing_interface