Routing Policies bring the capability of defining specific routing policies according to business objectives. This feature permits denying or allowing providers to be used for probing and reaching a specific prefix or ASN. It also provides the possibility to set a static or static exact route through a particular provider. The static route policy will only apply improvements for prefixes learned from the BGP table or external sources. The static exact route policy will announce improvements according to the exact policy details provided by the user, regardless of prefixes being present in the BGP table or external data sources (BGP split does not apply to static exact policies).
Within an Allow or Deny policy, you can choose between VIP or non-VIP (regular) probing mechanisms to be used.
Policies can be configured for networks (ASN) or aggregate prefixes. IRP works with prefixes from the global BGP routing table. Each prefix is checked against a set of policies, matching a single policy in accordance with the policy priority value, those with the highest value being checked first.
In version 3.9 IRP added support for policies by Country. Note that IRP maps individual prefixes to a country and does not use a transitive inference based on AS records. These prefix mappings allow IRP to more accurately work with large transcontinental AS.Starting with version 3.9 IRP introduces a priority attribute that defines what policy to choose in cases when different policies include the same unpacked specific prefix. The policy with the highest priority will apply for such a prefix.
Note that after upgrade all existing policies are assigned (implicitly) the lowest default priority of 0.Below you can find some typical scenarios of Routing Policies usage. For instance, there may be a specific prefix that consumes a high volume of traffic and IRP redirects it through the most expensive provider due to performance considerations. At the same time you have another two less costly available providers. In this case, you could deny the expensive provider for the specific prefix and IRP will choose the best-performing provider between the remaining two. This can be achieved by applying a Deny policy to the expensive provider or an Allow policy to the less costly providers.
The table below shows which cases a specific policy can be applied in, depending on the number of providers. #
|
No. of providers \ Policy |
Allow |
Deny |
Static |
Static Exact |
| 1 provider |
No |
Yes |
Yes |
Yes |
| 2 providers or more (maximum: total number of providers – 1) |
Yes |
Yes |
No |
No |
| All providers (VIP probing disabled) |
No |
No |
No |
No |
| All providers (VIP probing enabled) |
Yes |
No |
No |
No |
If a Static or Static Exact Route policy is applied to a prefix, VIP probing through each of the providers is unnecessary. Regular probing will suffice for detection of a provider failure that would trigger IRP to reroute the traffic to a different provider. Therefore IRP does not allow using VIP probing within a Static or Static Exact Route policy.
Routing policies are designed to control outgoing paths for destination networks that are outside your infrastructure. This feature should not be used to manipulate your infrastructure network behavior.Avoid setting up of policies that point to same prefix. When improvement by aggregate is enabled, multiple prefixes can point to the same aggregate and this can cause unpredictable behavior.
If a provider is added or removed, suspended or shutdown, the routing policies are adjusted by IRP in the following way: #
A new provider is added. #
|
Policy |
Result |
|
Allow all providers (VIP probing enabled) |
The new provider is automatically included into the configured policy and probed by the VIP probing mechanism. |
|
Allow selected providers only |
The new provider is automatically ignored by the configured policy and not probed by the probing mechanism. |
|
Deny |
The new provider is automatically included into the configured policy and probed by the selected probing mechanism. |
|
Static Route |
The new provider is automatically ignored by the configured policy. |
|
Static Exact |
The new provider is automatically ignored by the configured policy. |
The provider under the policy is removed. #
|
Policy |
Result |
|
Allow all providers (VIP probing enabled) |
The new provider is automatically removed from the configured policy and not probed by the VIP probing mechanism. If there is only one provider left, the policy is automatically deactivated. |
|
Allow selected providers only |
The provider is automatically removed from the configured policy and not probed by the probing mechanism. If there is only one provider left, the policy is automatically deactivated. |
|
Deny |
The provider is automatically removed from the configured policy and not probed by the probing mechanism. If there is no any other provider under this policy, it is automatically deactivated. |
|
Static Route |
The policy is automatically deactivated. |
|
Static Exact Route |
The policy is automatically deactivated. |
The provider under the policy is suspended. #
|
Policy |
Result |
|
Allow all providers (VIP probing enabled) |
The provider is temporarily removed from the configured policy and not probed by the VIP probing mechanism. If there is only one provider left, the policy is temporarily deactivated. |
|
Allow selected providers only |
The provider is temporarily removed from the configured policy and not probed by the probing mechanism. If there is only one provider left, the policy is temporarily deactivated. |
|
Deny |
The provider is temporarily removed from the configured policy and not probed by the probing mechanism. If there is no any other provider under this policy, it is temporarily deactivated. |
|
Static Route |
The policy is temporarily deactivated. |
|
Static Exact Route |
The policy is temporarily deactivated. |
The provider under the policy is shutdown. #
|
Policy |
Result |
|
Allow all providers (VIP probing enabled) |
The provider is temporarily removed from the configured policy and not probed by the VIP probing mechanism. If there is only one provider left, the policy is temporarily deactivated. |
|
Allow selected providers only |
The provider is temporarily removed from the configured policy and not probed by the probing mechanism. If there is only one provider left, the policy is temporarily deactivated. |
|
Deny |
The provider is temporarily removed from the configured policy and not probed by the probing mechanism. If there is no any other provider under this policy, it is temporarily deactivated. |
|
Static Route |
The policy is temporarily deactivated. |
|
Static Exact Route |
The policy is temporarily deactivated. |
Policies that target an AS can be cascaded. Cascading applies the same policy to AS that are downstream to target AS, i.e. to AS that are transited by target AS.
The use case of cascading is to apply a policy to a remote AS that transits a few other AS. Still, a cascading policy can cover a huge number of down-streams. This number is parameterized and can be set to values that best fit customer’s needs. Refer for example bgpd.policy.cascade.amount.
When multiple routing domains are configured, a policy can be set to prevent global improvements. Refer to Optimization for multiple Routing Domains for further details about routing domains.
Policies can be assigned a specific community and all policy based improvements will be marked with the designated value to allow their further manipulation on edge routers.
All Routing Policies are stored in /etc/noction/policies.conf file, which is automatically generated by the system.
Do not alter the /etc/noction/policies.conf file manually because any modifications will be overwritten by the system. Any changes can only be performed from the Configuration -> Routing Policies section in the system GMI Frontend.The rule will be ignored by the platform if the Routing Policy contains a syntax/logical error.
