In recent years, the concepts of Artificial Intelligence (AI) and Machine Learning (ML)...
4.14 Provider
4.14.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.14.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.14.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.14.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-9999999
4.14.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.14.6 peer.X.aspath_for_ix #
Modifies the way IX AS number is treated for outbound improvements towards an Internet Exchange provider for 2nd and 3rd options of bgpd.as_path. The supported options are:
0: Strip IX ASN if present
1: Preserve IX ASN if present
Refer also bgpd.as_path.
- Possible values:
0-1 - Default value:
0
4.14.7 peer.X.auto_config #
Enables or disables periodic execution of Internet Exchanges auto re-configuration process once per global.exchanges.auto_config_interval interval.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.8 peer.X.bgp_peer #
MandatoryDefines 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.14.9 peer.X.blackholing.bgp_peer #
Specifies a BGP session(s) to be used to send blackholing announcements to.
- Possible values:
One or a list of valid BGP neighbor names, as defined in BGP sessions settings.
4.14.10 peer.X.blackholing.community #
Specifies a BGP community mark to be used in order to distinguish routes that are to be sent towards the provider’s router responsible for blackhole routes.
4.14.11 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.14.12 peer.X.bmp.check_routes #
Allows using BMP to check route availability from a Provider configured as a partial routing or IX.
IRP may unexpectedly use routes received from a Provider, but filtered by an edge router, because BGP filters aren’t applied to BMP data. The parameter must be enabled before switching peer.X.bmp to “Use BMP data only” mode.- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.13 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.14.14 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.14.15 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 peer.X.precedence) and cost mode is enabled (global.improve_mode)- Possible values:
0-1000000000 - Default value:
0
4.14.16 peer.X.description #
Defines the provider’s description (full provider name)
- Possible values: text
4.14.17 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 explorer.interval.infra parameter is used in case zero value is specified in this parameter.
- Possible values:
0-50000000between 0ms and 50ms - Default value:
0
4.14.18 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-10000000between 0.01ms and 10ms - Default value:
1000000
4.14.19 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.14.20 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 collisions of communities values assigned to IRP both within its configuration and/or on customer’s network.
4.14.21 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 collisions of communities values assigned to IRP both within its configuration and/or on customer’s network.
4.14.22 peer.X.flowspec.pbr.enabled #
Enables or disables Flowspec PBR for a provider.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1
4.14.23 peer.X.flowspec.pbr.use_bgp_peer #
Specifies whether FlowSpec PBR entries should be advertised only to assigned router(s) or to all routers with FlowSpec PBR enabled.
- Possible values:
0 (All routers), 1 (Assigned routers) - Default value:
0
4.14.24 peer.X.global_group #
Includes the provider into a existing Global Group.
See also: Global Group
- Possible values:
1-100
4.14.25 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.14.26 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 (Disabled), 1 (Enabled) - Default value:
0 - Recommended value: depends on network infrastructure and policies
4.14.27 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 advertising to provider 1”.- Possible values:
valid BGP community attribute
4.14.28 peer.X.ipv4.diag_hop #
MandatoryDefines 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: List of valid IPv4 addresses or prefixes (usually equal to peer.X.ipv4.next_hop)
4.14.29 peer.X.ipv4.master_probing #
MandatoryDefines 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.
See also: Specific PBR configuration scenarios
- Possible values: valid local IPv4 address
4.14.30 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.14.31 peer.X.ipv4.next_hop #
MandatoryDefines 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.14.32 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.
See also: provider.X.rule.Y.next_hop_as
- Possible values:
0-4294967295 - Default value:
0
4.14.33 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.14.34 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.
See also: Specific PBR configuration scenarios
4.14.35 peer.X.ipv4_pbr_check #
Defines per-provider alternative IPv4 address to be used for PBR tests. This overrides explorer.ipv4_test.
See also: peer.X.ipv6_pbr_check
- Possible values:
valid IPv4 address
4.14.36 peer.X.ipv6.diag_hop #
MandatoryDefines 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: List of valid IPv6 addresses or prefixes, usually equal to peer.X.ipv6.next_hop
4.14.37 peer.X.ipv6.master_probing #
Mandatory for IPv6Defines 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.
See also: Specific PBR configuration scenarios
- Possible values:
valid local IPv6 address
4.14.38 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 recommended 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.14.39 peer.X.ipv6.next_hop #
Mandatory for IPv6Defines 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.14.40 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.
See also: provider.X.rule.Y.next_hop_as
- Possible values:
0-4294967295 - Default value:
0
4.14.41 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.14.42 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.
See also peer.X.ipv6.master_probing.
- Possible values:
valid local IPv6 address
4.14.43 peer.X.ipv6_pbr_check #
Defines per-provider alternative IPv6 address to be used for PBR tests. This overrides explorer.ipv6_test.
See also: peer.X.ipv4_pbr_check.
- Possible values: valid IPv6 address
4.14.44 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, 1-1000000-1 means unlimited - Default value:
-1 - Recommended value:
it is recommended to set it to not more than ~60-80% of the physical interface rate
See also: peer.X.snmp.interfaces
4.14.45 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
See also: peer.X.mon.snmp
4.14.46 peer.X.mon.ipv4.external.state #
Enables or disables external monitors for IPv4.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.47 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.14.48 peer.X.mon.ipv4.internal.state #
Enables or disables internal monitors for IPv4.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.49 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
See also: peer.X.mon.snmp
4.14.50 peer.X.mon.ipv6.external.state #
Enables or disables external monitors for IPv6.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.51 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.14.52 peer.X.mon.ipv6.internal.state #
Enables or disables internal monitors for IPv6.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.53 peer.X.mon.snmp #
Identifier of SNMP host to use for monitoring this provider. Refer to SNMP Host, snmp.X.name.
- Possible values:
1-1000
4.14.54 peer.X.mon.vpn_instance_id #
The Provider routing instance index.
The parameter is useful when a provider belongs to a non-default routing instance, and the Internal Monitor should be addressed to monitor a BGP session inside that specific routing instance.
Applicable only to Huawei and Arista modes of Internal Monitor.Default value depends on the mode: Huawei routers have the main routing instance ID equal to zero while Arista routers have this ID equal to 1.
Refer to peer.X.mon.ipv4.internal.mode, peer.X.mon.ipv6.internal.mode, Arista BGPv2 MIB, Huawei BGP VPN MIB.
- Possible values:
0-4294967295
4.14.55 peer.X.pbr_check #
Enables/disables PBR check for a specific provider.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
1 - Recommended value:
1
4.14.56 peer.X.precedence #
Precedence value of “0” has a special meaning. IRP excludes providers from grouping if a provider’s precedence value is set to 0.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 a single group must have the same value for the following parameters:
- peer.X.95th.bill_day
- peer.X.95th.mode
- peer.X.95th.centile
- peer.X.cc_disable
- peer.X.cost
- peer.X.global_group
- peer.X.group_loadbalance
- peer.X.improve_in_group
If two different providers have the same peer.X.precedence value (except 0), then these providers are considered to be a group, and traffic is balanced between them (refer to peer.X.group_loadbalance).
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 - Default value:
0
4.14.57 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.
- Possible values:
1-100 - Default value:
1
4.14.58 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 (Disabled), 1 (Enabled) - Default value:
1
4.14.59 peer.X.shortname #
MandatoryDefines the provider’s short, abbreviated name (3-20 characters). This parameter’s value is used for reports and graphs.
- Possible values:
text
4.14.60 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.
- Possible values:
0, 1, 2 - Default value:
0
4.14.61 peer.X.snmp.enhanced #
Enables or disables heuristically enhanced SNMP collection for provider.
- Possible values:
0 (Disabled), 1 (Enabled) - Default value:
0
4.14.62 peer.X.snmp.interfaces #
Defines a collection of interfaces used for current provider.
There have been four formats of individual values where the first number represents identifier of an SNMP host configured under SNMP Host, the delimiter depicts the type of matching algorithm, and the value after the delimiter is used to access the required interface stats:
- id-number Match interface by ifIndex
id=name Match interface by ifName
id:description Match interface by ifDescr
id|alias Match interface by ifAlias
- Possible values:
collection of SNMP Interfaces
4.14.63 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