IRP Installation and Configuration Guide

IRP Installation and Configuration Guide



3 Using IRP

3.1 Getting started

The Frontend is a web interface with a comprehensive set of reports, graphs and diagnostic information, which can reflect the current and historical network state, as well as the benefits of IRP network optimization.

3.1.1 Accessing the system

The system frontend is accessible over HTTPS. IRP’s Frontend can be accessed using any major browser, via the main IRP server IP address, or FQDN. E.g: http://irp-system.noction.com/. When opening the Frontend’s URL, a login form will pop up:
figure screenshots/frontend-login-form.png
Figure 3.1.1 Frontend login form

The username and password provided by the system administrator must be used. The “Remember me” check-box can be used as well.

3.1.2 System dashboard

After a successful login, the default Dashboard will become available. It contains a standard set of gadgets - elements, which can contain a reduced version of a report or a graph.
figure screenshots/frontend-default-dashboard.png
Figure 3.1.2 Default Dashboard


3.2 Frontend structure

The Frontend has several components that operate together and allow a regular user or administrator to access various reports, graphs, or configuration pages.
  1. The menu bar (see Figure 3.3↓) allows quick access to any part of the system via its menu items.
    figure screenshots/frontend-menu-bar.png
    Figure 3.2.1 Menu bar

  2. The sidebar (See section 3.2.1↓) is present on the Dashboard or on any graph or report. Its contents depend on the current page, and can include filters, export functions, etc., as explained in the next section.
  3. The status bar (see Figure 3.4↓), allows one to access the global search function (Section 3.2.3↓), as well as system events and notifications (See the Events↓ section).
    figure screenshots/frontend-status-bar.png
    Figure 3.2.2 Status bar

3.2.1 Sidebar

All dashboards, reports, graphs and events have a sidebar, located at the left side of the screen. Depending on the current page, the sidebar has a different set of controls, allowing users to manage the dashboard components or to filter the report and graph results.
Every sidebar contains Export, Email and Print buttons. Reports can be exported in .xls, .csv, .pdf formats, while the graphs and dashboard - only as .pdf .
figure screenshots/sidebar-edit-export.png
Figure 3.2.3 Common sidebar buttons

The “Email” button allows scheduling email delivery of several reports or graphs, or even an entire dashboard (Figure 3.6↓). Multiple destination email addresses can be used. Most elements in this form have informative tool-tips, that can be seen when hovering over a specific control. Note that Email Reports can be removed from <Username> → Emailing from the top panel.
figure screenshots/sidebar-emailing-setup.png
Figure 3.2.4 Email schedule configuration

In the case of a report, custom filters can be applied, so that only specific information will be displayed in the report.
figure screenshots/sidebar-filters.png
Figure 3.2.5 Report filters

On graphs, reports and dashboard, the time period which the information is being provided for, can be selected by using the “Timestamp” button. An intuitive control will open, and the desired time period can be selected.
figure screenshots/sidebar-timestamp-selector.png
Figure 3.2.6 Time period selection

The number of results can be adjusted on a report page, using the “Results per page” slider.
figure screenshots/sidebar-slider.png
Figure 3.2.7 Adjusting the number of results per page

Dashboards have a different sidebar layout.
The Delete button cannot be found in the default dashboard. The default dashboard cannot be deleted.
System dashboard represents the overall system information which includes:
  • Configured maximum number of improvements (Max IPv6 Improvements will be shown if IPv6 is enabled)
  • Number of Routing Policies improvements
  • Number of improvements performed today
  • The amount of traffic improved today
  • Percentage of prefixes improved today
  • Number of operating iBGP sessions
  • Number of announcements to the edge router
  • Announcements to each from configured routers
  • Number of BGP sessions with the providers
  • Number of operating BGP sessions with the providers
figure screenshots/sidebar-dashboard-buttons.png
Figure 3.2.8 Dashboard buttons

3.2.2 Failover status

When failover is configured and operational the status of the components is highlighted below system dashboard for each master and slave nodes.
A valid failover license is required
figure screenshots/FailoverStatus-Master.png
Figure 3.2.9 Failover status of master node

Slave node status shall be considered together with component status in the dashboard. During normal operation components Core, Explorer and Irppushd are stopped.
figure screenshots/FailoverStatus-Slave.png
Figure 3.2.10 Failover status of slave node

3.2.3 Global search

The Frontend allows to search for historical information on optimized prefixes, AS Numbers and AS Names. The search function can be accessed using the Search box in the status bar.
figure screenshots/statusbar-search-box.png
Figure 3.2.11 Search box

Enter the needed prefix, AS number or AS name in the search box, then press Enter or click on the magnifying glass button.
While entering the search terms, results are dynamically loaded in a modal window (Figure 3.14↓).
figure screenshots/statusbar-dynamical-search-results.png
Figure 3.2.12 Dynamical global search results

When displaying the complete results, specific prefixes can be manually removed, or scheduled for re-probing, by using the buttons next to each result (Figure 3.15↓).
figure screenshots/global-search-results.png
Figure 3.2.13 Global search results

The Show all X results in Y category buttons can also be used, to display all matching results from the selected category (Improvements or AS Path problems)

3.2.4 Warning bars

The warning bars are shown in case the attention should be drawn to operational/performance issues, some specific IRP configuration settings or license/payment issues.
figure screenshots/warning-precedence.png
Figure 3.2.14 Precedence and improve in a group warning

figure screenshots/warning-internal-monitor.png
Figure 3.2.15 Internal Monitor warning

figure screenshots/warning-explorer-performance.png
Figure 3.2.16 Explorer performance warning
figure screenshots/warning-license-expiration.png
Figure 3.2.17 License expiration warning

3.3 Customizing the dashboard

The Default dashboard is the first screen that can be seen after a successful login to the system. It contains a default set of gadgets, that can be customized by adding additional gadgets, removing unnecessary gadgets, or modifying specific gadget’s settings.

3.3.1 Custom dashboard gadgets

3.3.1.1 Platform status

figure screenshots/widget-platform-status.png
Figure 3.3.1 Platform status

3.3.1.2 Interfaces status

figure screenshots/widget-interfaces-status.png
Figure 3.3.2 Interfaces status

3.3.1.3 List of improved prefixes

figure screenshots/widget-list-of-improved-prefixes.png
Figure 3.3.3 List of improved prefixes

3.3.1.4 AS-Path problems

figure screenshots/widget-as-path-problems.png
Figure 3.3.4 AS-Path problems


3.4 Reports

The IRP Frontend comes with a comprehensive set of reports, reflecting the current state of the network as well as overall statistics on the system performance. As explained in the Sidebar↑ section, the results can be filtered by specific criteria for each report, and the time period of the reported data can also be selected.
figure screenshots/frontend-reports-menu.png
Figure 3.4.1 Reports menu

3.4.1 Platform overview

The “Platform Overview” report provides information on the overall rate of improvements based upon latency, loss and cost. This report can be used for a quick overview of the overall system performance and improvements.
One can see here that almost all the improved routes had a loss drop of 20% or more. For more than 80% of the improved routes the loss was fully eliminated. There are also 7% of the improved routes, which were redirected from a complete blackout. The report also provides the amount of the accomplished route improvements made, based upon latency, and cost (if the Cost optimization is enabled, see Cost optimization↑).
figure screenshots/report-1-platform-overview.png
Figure 3.4.2 Platform overview

3.4.2 Platform performance

The “Platform Performance” report offers overall statistics on improvements made, based upon performance reasons, commit control and cost reasons on a daily, weekly and monthly basis.
figure screenshots/report-2-platform-performance.png
Figure 3.4.3 Platform performance

3.4.3 Loss Improvements

The Loss Improvements report highlights how much of the "Packet loss problem" IRP detected and was able to solve during a specific timeperiod.
Loss relative rates - highlights the percentual magnitude of the improvement in loss rates for groups of destinations before and after IRP assessed and re-routed the traffic. The groups represent:
  • All destinations that cover good and problematic destinations that registered traffic flowing to during the timeperiod;
  • Problem destinations that includes only routes with packet loss and improved by IRP;
  • Loss eliminated represents those problem destinations that IRP was able to improve to a better route with zero loss;
  • Loss reduced represents those problem destinations that IRP improved but was not able to reduce loss altogether.
figure screenshots/report-13-loss-improvements-relative-rates.png
Figure 3.4.4 Loss relative rates

Loss absolute rates - highlights the actual loss rate values before and after improvement for the same groups of destinations as above. While the previous part of the report shows big numbers one needs to know how big the packet loss problem actually is. The Loss absolute rates part of this report shows just that. It displays an actual 10% or 5% or 3% or 1% value depending on how well-behaved the network is. Values of 5-7% are usual. Values exceeding 10% are a bit worrisome. While it allows IRP to boast a bigger impact for your network it also means that the routing information you receive is not very accurate and that your providers might not be making the very best effort to service your traffic.
figure screenshots/report-13-loss-improvements-absolute-rates.png
Figure 3.4.5 Loss absolute rates

Problem destinations - highlights destination counts of affected routes in the groups as above. The charts present the rate of problem destinations identified by IRP and subsequently highlights how well IRP was able to improve on them. The counts allow you to infer whether there are 20 customers suffering minor packet loss (say, 5% each) or 2 customers suffering severe packet loss (for example 50% each). If for the top and middle graphs above IRP was able to reduce packet loss by 80% these pie charts allow you to infer that there were 20 or 2 customers affected and that for some of them IRP solved the problem completely and how many others are still suffering.
figure screenshots/report-13-loss-improvements-lossy-destinations.png
Figure 3.4.6 Loss-improved destinations

3.4.4 Latency Improvements

The Latency Improvements report presents an overview for average latency values before and after IRP optimization during a specific timeperiod and depicts them across the following populations:
  • Sample destinations that cover good and problematic destinations that IRP probed during selected timeperiod;
  • Problematic destinations cover those routes/prefixes that IRP assessed to have excessive latency rates and identified a better route via a different upstream provider;
  • 20% or more cover those destinations where IRP was able to identify a route with latency improvements of 20% or more;
  • 50% or more cover those destinations where IRP was able to identify a route with latency improvements of 50% or more.
figure screenshots/report-14-latency-improvements-values-ms.png
Figure 3.4.7 Latency values (ms)

Latency values (ms) - highlights the actual latency values before and after improvement for the same groups of destinations as above.
figure screenshots/report-14-latency-improvements-values-percent.png
Figure 3.4.8 Latency values (%)

Latency destinations - highlights destination counts in the groups as above.
figure screenshots/report-14-latency-improvements-destinations.png
Figure 3.4.9 Latency destinations

3.4.5 Probe conversion rates

Probe conversion rates - highlights the counts of networks/prefixes probed by IRP and their conversion rate into any of the possible improvements:
  • Commit
  • Performance
  • Cost
figure screenshots/report-15-probe-to-improvement-conversion-rates.png
Figure 3.4.10 Probe conversion rates

3.4.6 Current improvements

The "Current Improvements" report provides a list of the currently active improvements as per network. A drill-down capability to a specific ASN or prefix is also provided. The report shows the improved prefix and the providers from and to which the traffic was redirected. It also provides the reason, which the improvement was based upon, along with the performance values before and after the traffic was rerouted.
If necessary, specific improvements can be manually deleted by clicking the checkbox next to the needed prefix, afterward using the “Remove selected” button.
figure screenshots/report-3-current-improvements.png
Figure 3.4.11 Current improvements
In some specific cases, the “From” and “To” fields will contain the same provider. This is not a platform issue and is related to the Outage detection algorithm specifics. For more details see the Outage detection↑ and VIP Improvements↑ sections.
 
The “ASN” field can be empty in case there is no information about the AS number (a prefix belongs to) in the IRP ASN dictionary. As soon as the ASN information is available in the dictionary, the field will be filled accordingly.
Of note is that Current Improvements report also has a map view.
figure screenshots/report-3-current-improvements-map.png
Figure 3.4.12 Current improvements map view
The map view besides offering the usual zooming and panning capabilities also offers clustering and highlighting of improvements by either provider or improvement type.

3.4.7 VIP Improvements

The “VIP Improvements” report contains a list of VIP Prefixes/VIP ASNs that have been introduced by user and have also been translated by IRP. The list can be collapsed or expanded. Furthermore a single prefix or the whole ASN may be reprobed from this report by clicking the “Reprobe” link. The VIP Prefixes/ASN entries can be removed if necessary.
figure screenshots/report-3_1-vip-improvements.png
Figure 3.4.13 VIP Improvements
New VIP Prefixes/ASNs may be added to the system directly from this report using “Add VIP Prefix” or “Add VIP ASN” buttons.
figure screenshots/report-3_2-vip-improvements-add-vip-prefix.png
Figure 3.4.14 Add VIP Prefix/ASN

3.4.8 Improvements to Exchanges

The “Improvements to Exchanges” report contains a complete list of current improvements where the new provider is an Internet Exchange. The report includes data about improved prefixes and their relative traffic by means of last minute and average bandwidth usage. Average bandwidth is estimated based on current hour statistics.
figure screenshots/report-17-Improvements-to-Exchanges.png
Figure 3.4.15 Improvements to Exchanges

3.4.9 Historical records

The “Historical records” report contains a complete list of active and inactive improvements that were made by the system. The report can be sorted using any of the columns by simply clicking on the column header.
figure screenshots/report-4-historical-records.png
Figure 3.4.16 Historical records
In some specific cases, the “From” and “To” fields will contain the same provider. This is not a platform issue, and is related to the Outage detection algorithm specifics. Please see the Outage detection↑ section for more details

3.4.10 Providers overall

The "Providers Overall" report provides the number of prefixes that were rerouted from and to each of the providers. In the example below, the traffic exchange between the providers is balanced. However, if the difference between the outgoing and incoming traffic is significant, then the quality of that provider’s network should be questioned. The report also shows the number of improved prefixes, based upon performance and cost, for each of the providers.
figure screenshots/report-5-peers-overall.png
Figure 3.4.17 Providers overall

3.4.11 Provider performance

During the day IRP makes many probes to determine performance characteristics of alternatives routes.
Provider performance report presents an aggregated view of this measurements for providers. The data on the report highlights Packet loss and Average latency per provider putting the provider with best packet loss data at the top.
figure screenshots/report-16-provider-performance.png
Figure 3.4.18 Provider performance
Provider performance report has been extended and now also offers a daily performance view. The extended Provider daily performance report adds the following capabilities:
  • a Best (hypothetical) provider that estimates what might be possible to achieve on your network in terms of loss and average latency,
  • classification of destinations by distance from your network with the option to review a category of interest,
  • filtering by date range allowing review of past data or average performance over longer time intervals,
  • a table view with exact details of the data in the report.
Figure 3.4.19 Provider daily performance
Note that while some providers seem better performing (for example, NLIX or AMS-IX in the provided screen capture) the fact that they display a much smaller number of probes clearly indicates they are Internet Exchanges with only a few peers interchanging data with our network.

3.4.12 Cost overview

This report is available only if the system is running in Cost optimization mode (see Cost optimization↑).
The “Cost Overview” report provides details regarding the cost savings, resulted from running IRP for each provider. It displays the costs that would be normally paid to the providers and the costs incurred after IRP has optimized the routing. The system calculates the total transit cost while running in Cost improvement mode and compares it with the total transit cost that would be incurred without running IRP. This difference is shown on the right side of the table as Cost Savings. The total cost savings include the ones made by the Commit Control as well. If the provider’s billing periods differ, then it is possible to choose a billing period for each provider separately.
figure screenshots/report-6-cost-overview.png
Figure 3.4.20 Cost overview

3.4.13 Congestion and outages

This report is available only if Outage detection↑ is enabled.
The “Congestion and outages” report contains all the as-patterns defined as problematic by the system. The problem state is shown in the “Status” column, as follows:
  • - A problem on the specified AS-Pattern is suspected
  • - The problem was not confirmed by additional re-probing
  • - The problem was confirmed, and all related prefixes were rerouted
  • - The problem was confirmed, but no better-performing route has been found
figure screenshots/report-7-as-path-pattern-problems.png
Figure 3.4.21 AS-pattern problems

3.4.14 Top volume prefixes

The “Top volume prefixes” displays a list of prefixes sorted by the total volume transferred to these remote networks.
figure screenshots/report-8-top-volume-prefixes.png
Figure 3.4.22 Top volume prefixes

3.4.15 Top volume AS

The “Top Volume AS” reports show the Autonomous Systems with the highest volume of traffic coming from the monitored network. It can help you understand your traffic flow directions. If according to this report a specific AS has significantly more traffic than the others, then the network operator may consider getting a direct connection to this AS, to reduce traffic costs.
figure screenshots/report-10-top-volume-as.png
Figure 3.4.23 Top volume AS

3.4.16 Top problem AS

The "Top Problem AS" report reveals the most problematic Autonomous Systems that the monitored networks are sending traffic to. It does that by showing how many times the traffic going to that AS was rerouted by the IRP.
figure screenshots/report-11-top-problem-as.png
Figure 3.4.24 Top problem AS

3.4.17 Prefix statistics

This report lists specific prefixes with relevant monthly values such as traffic volume and number of improvements or current unique and top hosts values. To see top hosts expand the + button to expand to latest individual hosts and their corresponding traffic volume. Note that the upper limit for the number of top hosts is constrained by collector.export.top_volume_ips↓.
figure screenshots/report-9-prefix-statistics.png
Figure 3.4.25 Prefix statistics
Note that Prefix statistics report introduced a map view highlighting with heat-maps those regions of the world where either most traffic or highest number of improvements are made.
figure screenshots/report-9-prefix-statistics-map.png
Figure 3.4.26 Prefix statistics map view

3.4.18 AS statistics

The “AS statistics” report aggregates by Autonomous System the total number of improvements, the volume of traffic and the 95th for a selected past month. Note that the choice of month for the 95th and the time period of the report are independent and they can set non-overlapping ranges.
figure screenshots/report-12-as-statistics.png
Figure 3.4.27 AS statistics

3.4.19 Country statistics

The “Country statistics” report distributes traffic volume and number of improvements by country. It helps see to what regions most of a network’s traffic is addressed and also the relative number of suboptimal routes towards them that IRP identified and addressed by injecting improvements.
figure screenshots/report-country-statistics.png
Figure 3.4.28 Country statistics
Country statistics report also displays a map view highlighting countries with most/least number of improvements.
figure screenshots/report-country-statistics-map.png
Figure 3.4.29 Country statistics map view

3.4.20 Bandwidth by peer

The "Bandwidth by Peer" report lists statistics regarding communications with peers on Internet Exchanges. Filters and sorting help identify the required details.
figure screenshots/report-ix-peer-bandwidth.png
Figure 3.4.30 Bandwidth by peer

3.4.21 Current inbound improvements

The “Current inbound improvements” report provides a list of the currently active improvements. A drill-down capability to a specific ASN or prefix is also provided. The report shows the improved prefix and the providers from and to which the traffic was redirected. It also provides the reason, which the improvement was based upon, along with the performance values before and after the traffic was rerouted.
If necessary, specific improvements can be manually deleted by clicking the check-box next to the needed prefix, afterward using the “Remove selected” button.
figure screenshots/report-18-Inbound-CurrentImprovements.png
Figure 3.4.31 Current inbound improvements
Refer Inbound optimization↑ for details.

3.4.22 Inbound Improvements history

The "Inbound Improvements history" report provides a detailed list of past inbound improvement actions. Filtering for example by specific prefix or improvement type is provided. The report shows the improved prefix and the new prepends count towards a provider.
figure screenshots/report-inbound-hisotry.png
Figure 3.4.32 Inbound Improvements history
Refer Inbound optimization↑ for details.

3.4.23 Probes today

The "Probes Today" report provides probing details, including probes that did not warrant an improvement or failed completely. The report shows probed prefixes and actual selected probing IPs in that prefix with details about probe state and actual measurements across all providers. Missing details for some providers, for example for partial providers or Internet exchanges indicate that either the provider was stopped, the prefix is not serviced by the provider or entirely a probing IP was not identified and the probe has failed complete.
Icons and coloring are used in the report to highlight data for example if an improvement exists for the prefix, or what was the current provider during probing or whether there’s a 100% loss. Filtering and sorting can be used to highlight and group the data into different specific categories.
figure screenshots/report-probes-today.png
Figure 3.4.33 Probes today

3.4.24 Monitors status

The "Monitors Status" report highlights the current status of IRP monitors per provider. For Internet Exchanges the report highlights all the peers with a tooltip with details.
figure screenshots/report-monitors-status.png
Figure 3.4.34 Monitors status
The "Historical monitors" report supplements Monitors status by highlighting the time, monitor details and the new state facilitating the tracing of various issues on the network and in IRP configuration.
figure screenshots/report-monitors-history.png
Figure 3.4.35 Historical monitors


3.5 Graphs

The IRP graphs are visual representations of data found in the reports. They provide an opportunity to quickly identify problems in the network, as well as forecast periodic changes in the traffic patterns and network behavior. For each graph you can adjust the time period which you want to get the results for, and export them as PDF (see the Sidebar↑ section).
Unless otherwise noted, all graphs are plotted using 5 minute intervals.
figure screenshots/frontend-graphs-menu.png
Figure 3.5.1 Graphs menu

3.5.1 Improvements by type

The “Improvements by type” graph shows the improvements made by IRP based upon: performance, cost, commit, and outage detection. Various problem patterns can be detected in compliance with the IRP activity shown in this graph. The graph provides information on the types of improvements that are more frequent for the network in the current state. Different patterns can be noticed depending on the improvement mode that is currently running.
figure screenshots/graph-1-improvements-by-cause.png
Figure 3.5.2 Improvements by type

3.5.2 Performance improvements

The “Performance improvements” graph displays the prefixes improved based upon a performance reason. By following this graph, the solved loss and latency issues, occurring in the network, can be monitored. The graph also provides the average, maximum and minimum number of improvements for each of the improvement reasons during the selected time frame. The maximum peaks are indicators of a loss or latency problem in the network.
figure screenshots/graph-3-performance-improvements.png
Figure 3.5.3 Performance improvements

3.5.3 Probed prefixes and Improvements

The "Probed prefixes and Improvements " graph shows the number of improvements (Loss/Latency) per time unit as reported to the total probed prefixes.
figure screenshots/graph-4-improved-prefixes-within-probed.png
Figure 3.5.4 Probed prefixes and Improvements

3.5.4 New and retry improvements

After a particular improvement was made, IRP analyzes the path periodically. If the improvement is still valid it leaves it as it is. The “New and retry improvements” graph provides the number of improvements made for the first time as related to those, which were simply confirmed after re-probing.
figure screenshots/graph-5-new-and-retry-improvements.png
Figure 3.5.5 New and retry improvements

3.5.5 Improvements by probing source

The current graph displays the percentage of improvements that are differentiated by the probing source including Commit Control, Outage Detection, VIP Probing, Regular and Retry Probing.
figure screenshots/graph-16-improvements-by-probing-source.png
Figure 3.5.6 Improvements by probing source

3.5.6 Prefixes rerouted from provider

The current graph displays the number of prefixes that were rerouted from a specific provider in order to resolve performance or cost issues.
figure screenshots/graph-6-prefixes-rerouted-from-peer.png
Figure 3.5.7 Prefixes rerouted from provider

3.5.7 Prefixes rerouted to provider

The graph displays the number of prefixes that were rerouted to a specific provider in order to resolve performance or cost issues.
figure screenshots/graph-7-prefixes-rerouted-to-peer.png
Figure 3.5.8 Prefixes rerouted to provider

3.5.8 Improvements by provider

The “Improvements by provider” graph shows all the improvements made by IRP for each of the providers. You can monitor the issues occurring in the network, which triggered IRP to reroute the traffic. You can compare the providers based on how they perform in the context of performance and cost. It also provides the average, maximum and minimum number of improvements per provider for each of the improvement reasons.
Improvements by provider graph categorizes improvements by performance and cost. If cost mode is disabled this graph shows the same data as Prefixes rerouted to provider graph.
figure screenshots/graph-8-improvements-by-peer.png
Figure 3.5.9 Improvements by provider

3.5.9 Performance improvements by provider

Similar to the previous graph, the “Performance improvements by provider” displays a graphical representation of historical values for all latency and loss-based improvements for each provider. The charts are displayed next to each other for easier comparison and identification of regularities. Keep in mind that specific provider lines can be removed from the graph. This way we are able to focus only on the interesting data.
figure screenshots/graph-9-latency-improvements-by-peer.png
Figure 3.5.10 Performance improvements by provider

3.5.10 Commit improvements by provider

If the Commit Control algorithm is enabled (see Commit Control↑), this graph will display an overview of all the commit improvements that were enforced by IRP for a specific time period.
figure screenshots/graph-11-commit-improvements-by-peer.png
Figure 3.5.11 Commit improvements by provider

3.5.11 Total and Improved traffic

The Total and Improved Traffic graph allows you to see the positive impact of IRP on the network. It provides the amount of improved traffic, shown in blue color, as related to the total traffic, shown in green. Thus, you can monitor how much of the traffic is affected by IRP.
figure screenshots/graph-12-total-and-improved-traffic.png
Figure 3.5.12 Total and improved traffic

3.5.12 Bandwidth usage by provider

The Bandwidth Usage graph shows the total usage for each of the providers. It allows you to compare the current traffic volume to the current 95th percentile and the commit 95th. The graph provides average, maximum and minimum traffic usage values for each of the providers during the selected time period.
figure screenshots/graph-13-peers-bandwidth-usage.png
Figure 3.5.13 Bandwidth usage by provider

3.5.13 Providers bandwidth usage

The Providers bandwidth usage graph combines all usage lines in a single chart. It allows cross-comparison between providers themselves. The chart includes options to hide/show providers of interest during selected time period. The top and bottom charts display outbound and inbound traffic accordingly.
figure screenshots/graph-all-providers-bandwidth-usage.png
Figure 3.5.14 Providers bandwidth usage

3.5.14 Bandwidth usage and improvements

Bandwidth usage and improvements chart superimposes two charts for easy analysis and comparison of how improvement counts correlate with bandwidth.
figure screenshots/graph-14-bandwidth-usage-and-improvements.png
Figure 3.5.15 Bandwidth usage and improvements

3.5.15 Total bandwidth usage

figure screenshots/graph-15-total-bandwidth-usage.png
Figure 3.5.16 Total bandwidth usage

3.5.16 Inbound traffic distribution

The graph highlights distribution of inbound traffic across inbound prefixes and providers.
figure screenshots/graph-17-Inbound-Traffic-Distribution.png
Figure 3.5.17 Inbound traffic distribution
Inbound traffic distribution report includes a feature to cross-compare current values with a saved inbound traffic distribution from recent past. To cross-compare saved inbound traffic distribution with freshly retrieved statistics, save and compare traffic shape changes and if they conform to expectations.
Refer Inbound optimization↑ for details.

3.6 Routing Policies

To see the full list of routing policies configured in the system, select the Routing Policies option from the main menu and click on the Routing Policies option in the submenu. The list displays all the enabled and disabled routing policies configured in IRP.
figure screenshots/routing-policies.png
Figure 3.6.1 Routing Policies
As shown in the screenshot above, the list provides the following details:
  • Priority of a policy.
Priority specifies what policy to use in case of overlapping prefixes as might be the case of a large aggregate prefix policy extending over an ASN policy
  • The prefix/ASN to which the policy was applied.
  • A note to describe the policy.
  • The ASN of the prefix to which the policy was applied.
  • The status of the VIP reprobing (enabled/disabled).
  • The type of the policy ( allow/deny/static).
  • Providers which are affected by the policy.
  • Time passed after the last probe was performed towards this prefix.
  • The time left before the next scheduled probe towards this prefix.
  • From and To details of an existing improvement relating to this policy.
  • The available actions for the policy. These include:
    • On-demand probing
    • Editing the routing policy
    • Enabling the routing policy
    • Disabling the routing policy
You can collapse all the policies by clicking the "Collapse All" button and then expand them back by clicking the "Expand all" button. You can use the "Remove all " button to delete all the policies. You can also select a set of policies and use the "Remove selected" button to delete them.
A new routing policy can be added by pressing the "Add routing policy" button. The following window will open up:
figure screenshots/routing-policy-window.png
Figure 3.6.2 Routing policy window
The following parameters should be configured to add a routing policy:
  • Prefix/ASN: The prefix/ASN to which the policy is applied
  • Note: A note to describe the policy
  • Policy Type: The type of the policy (allow/deny/static)
  • A community to mark improvements
  • A flag to set if policy is VIP
  • The policy status (enabled/disabled)
  • A flag to indicate if an ASN policy should propagate to downstream ASN.
  • A flag indicating if a global improvement allowed.
  • Priority slider or text-box will set a policy’s priority.
  • The Providers for which the policy should be respected
  • Cascade flag for ASN policies that indicate if the policy should be enforced only for this AS or also for downstream AS. If cascading is enabled it ensures that the policy is enforced for all traffic that will eventually be routed through this AS.
Refer policy configuration parameters Routing Policies settings↓ for details.
To see a list of Static Route policies, select Static Routes in the Routing Policies submenu. Alternatively the filter on the left side-bar can be used. A list like the one below will be displayed.
figure screenshots/routing-policies-static-routes.png
Figure 3.6.3 Static Routes
The list structure and the actions available are similar to those found in the Routing Policies list. Here you can also add a new Static Route by using the "Add static route" button.
You can select the VIP option in the Routing Policies submenu to access a list of all the policies with VIP reprobing enabled.
figure screenshots/vip-policies.png
Figure 3.6.4 VIP policies
Here you can also enable VIP reprobing for a new prefix/ASN by using the "Add VIP" button.

3.7 Flowspec policies

To review Flowspec policies, select the Routing Policies option from the main menu and click on the Flowspec Policies option in the submenu.
Flowspec must be enabled for BGPd to announce them.
The list displays all the enabled and disabled Flowspec policies configured in IRP.
figure screenshots/flowspec-policies.png
Figure 3.7.1 Flowspec policies
As shown in the screenshot above, the list highlights:
  • A note to describe the policy.
  • A source ASN/prefix and port(s) for matching packets.
  • A destination prefix and port(s) for matching packets.
  • DSCP traffic classification value.
  • The policy action (Throttle, Drop, Redirect or Redirect IP).
  • Redirect IP or Provider for redirect policies.
  • Protocols of matching packets, for example TCP, UDP or ICMP.
  • Rate limits in Mbps for Throttle policies.
Flowspec policies like routing policies can be edited, enabled, disabled or deleted altogether.
A Flowspec policy is added by clicking on the designated button and specifying the following:
figure screenshots/flowspec-policy-window.png
Figure 3.7.2 Flowspec policy popup
The following parameters should be configured to add a routing policy:
  • Notes to describe the policy
  • Status to set if policy is Enabled or Disabled
  • Source ASN/Prefix/Port(s): The source ASN/prefix andport(s) of the IP packets that match. A prefix in CIDR notation or a single IP address should be provided. Multiple valid TCP/UDP ports can be provided as well as port ranges.
One Flowspec rule is created for each of the prefixes in the designated AS. ASN Flowspec policies can be setup only on the source of IP packets.
Ensure that routers are capable of processing a large number of Flowspec rules before setting policies for an AS consisting of a very large number of network segments (prefixes).
  • Destination Prefix/Port: The destination prefix/port attribute of the IP packets that match. Same rules as for Source Prefix/Port(s) apply.
Prefixes MUST not equal or include probing IP addresses. Refer to for example global.master_probing_interface↓, peer.X.ipv4.master_probing↓peer.X.ipv6.master_probing↓.
  • Protocols: Packet protocols that match the policy. Can be any combination of TCP, UDP and ICMP.
  • Policy Type: The type of the policy (Throttle, Drop or Redirect)
  • Provider specifies one of the provider identifiers where traffic will be redirected. The provider is set only for Redirect policies.
In order for Redirect policies to be implemented on routers a community value must be assigned to them and VRF must be configured on the router itself. Consult Noction support for details.
  • Rate limits the allowed bandwidth usage for matching traffic. The value is set only for Throttling policies. The rate specifies a number in the range 1-4200 Mbps.
In case the provided Flowspec policy attributes are incomplete or invalid on attempting to submit it a warning will be raised similarly as depicted in the popup.

3.8 Throttling excessive bandwidth use with Flowspec

Throttling excessive bandwidth use with Flowspec↑ policies use the same Flowspec policies reports. Select the Routing Policies option from the main menu and click on the Flowspec Policies option in the submenu.
Flowspec must be enabled for BGPd to announce them.
The list displays besides all the other Flowspec policies the automatic throttling rules marked with Throttle at. These rules cannot be edited.
figure screenshots/flowspec-policies-Autothrottling.png
Figure 3.8.1 Throttling excessive bandwidth use with Flowspec policies
Each of the rules sets a specific destination prefix to control outbound bandwidth use and sets an Mbps rate based on past average bandwidth use.
Refer Core configuration↓ for configuration details.

3.9 Maintenance windows

To review Maintenance windows, navigate to Policies option in main menu and click on Maintenance Window option. The list displays all the current and future maintenance windows configured in IRP. Refer Maintenance windows↑ for details about maintenance windows.
figure screenshots/maintenance-windows.png
Figure 3.9.1 Maintenance windows
As shown in the screen-shot above, the list highlights:
  • Current color-coded status of the maintenance window where Red and Orange depict unloading and actual maintenance phases while Blue and Green depict future planned windows and past finished windows correspondingly.
  • Begin and End date-times of maintenance windows.
  • Provider or router under maintenance.
  • Withdraw Improvement option enables or disables withdrawal of existing Outbound Improvements to that provider.
  • Seconds to Unload defines time interval in seconds prior to beginning of the maintenance window when IRP starts to unload outbound traffic from provider.
If Seconds to Unload/Seconds to Prepend time intervals set to zero IRP does not perform corresponding action.
When seconds to unload is specified it should be at least 5 minutes (300 seconds) long with larger time intervals allowing IRP more time to assess and reroute traffic flowing through provider with scheduled maintenance window. Very short time intervals might not have the desired effect since usually an IRP optimization cycle takes 2-3 minutes to finish.
  • Seconds to Prepend defines time interval in seconds prior to beginning of the maintenance window when IRP announces all inbound prefixes with maximum prepends to provider in order to deflect inbound traffic towards other providers.
Maintenance windows can be added, edited or deleted using the designated action buttons.
A maintenance window is added by specifying the following:
figure screenshots/maintenance-window-popup.png
Figure 3.9.2 Maintenance window popup
The parameters mentioned above including the option to choose a single provider or all providers on a router are provided for Maintenance window configuration.
Maintenance windows are also highlighted on IRP Frontend sidebar with the title of the sidebar box highlighting the status of the next maintenance window so that it is visible even if the contents of the sidebar is collapsed.
figure screenshots/maintenance-window-sidebar.png
Figure 3.9.3 Maintenance window sidebar

3.10 Events

The system events are diagnostic messages that were sent by the IRP Components (See also: IRP Components↑), as well as notifications caused by the BGP monitoring algorithm (See also: BGP Monitoring↑). The events are displayed in the status bar located at the bottom of the system frontend (See Frontend structure↑). Several or all the events can be marked as “Read”, so they will no longer be displayed in the status bar.
figure screenshots/system-events.png
Figure 3.10.1 System events


3.11 Troubleshooting

The IRP Frontend provides several troubleshooting tools, that can offer you quick information on the specific remote networks.

3.11.1 Traceroute

A traceroute to a specific IP address or hostname can be run from the Frontend. Results will be displayed in the graphical and detailed formats, as in the examples below. The “Allow automatic improvement” checkbox can also be used for automatic improvement of the provided IP address.
figure screenshots/troubleshooting-traceroute.png
Figure 3.11.1 Traceroute
figure screenshots/traceroute-graphical.png
Figure 3.11.2 Traceroute results
figure screenshots/traceroute-details.png
Figure 3.11.3 Traceroute exploring details results

3.11.2 Looking glass

A ping, traceroute or MTR can be run from the Frontend via the default route or via a specific provider.
figure screenshots/troubleshooting-looking-glass.png
Figure 3.11.4 Looking glass

3.11.3 Whois

The “Whois” tool can query IP addresses, hostnames, network prefixes, or AS Numbers.
The following valid values can be entered in the search box:
  • Hostname: fully qualified domain name, e.g: “domain.com”
  • IP: valid IP address, e.g: “10.20.30.40”
  • IP Block: any valid prefix, in CIDR format, e.g: “10.20.30.40/24”
  • ASN: valid ASN, using the following format: “AS1234”
figure screenshots/troubleshooting-whois.png
Figure 3.11.5 Whois

3.11.4 Prefix probing

IRP features a manual prefix probing function. One can manually submit a specific IP address for probing and optimization by the system. Valid hostnames and IP addresses can be entered. The probing results will be displayed on the same page. Please note that IRP probes the exact entered IP address. In case the IP address doesn’t respond, IRP runs the indirect probing process and optimizes the whole prefix based on the indirect probing results.
Prefix probing allows to automatically or manually choose the best path for a particular IP address or prefix.
In order to check what are the possible paths for a particular prefix, enter the IP address or prefix into the field. If you prefer the prefix to be improved automatically, tick the check box “Improve automatically” and press the “Submit for probing” button. Otherwise, just press the “Submit for probing” button and wait until the system returns the probing results.
figure screenshots/troubleshooting-prefix-probing-input.png
Figure 3.11.6 Prefix Probing
The system returns the probing results by displaying the loss, latency and cost values for each of the providers.
figure screenshots/troubleshooting-prefix-probing.png
Figure 3.11.7 Prefix probing results
After the probing results are received, choose the path you consider the best one. Note, that IRP highlights the current and the best path. Use the “Reroute” button to redirect the traffic through the selected provider. You can also set the selected provider as static for the probed prefix by pressing the “Add static route” button or apply a specific routing policy to the probed prefix by clicking the “Add a custom policy” button.


3.12 Configuration editor

Starting with IRP version 1.7, all system parameters can be modified from the Frontend, using the “Configuration” menu.
Depending on the parameter type, several control types are available:
  • Text boxes, which can hold IP addresses, provider names and numerical values
    figure screenshots/configuration-editor/controls/text-box.png
  • Auto-complete boxes, used for parameters that can take a limited set of values
    figure screenshots/configuration-editor/controls/autocomplete-box.png
  • Auto-complete list boxes, usually containing a list of IPs / prefixes (in CIDR format) / ASNs
    figure screenshots/configuration-editor/controls/autocomplete-listbox.png
  • Buttons
    figure screenshots/configuration-editor/controls/buttons.png
  • Sliders, used to select a value from a predefined range
    figure screenshots/configuration-editor/controls/slider.png
  • Drop-down lists
    figure screenshots/configuration-editor/controls/drop-down-box.png
  • Toggle buttons (used for specific algorithms and BGP peers)
  • Provider control buttons, can be used to suspend, resume, stop, or remove a provider


3.12.1 Global configuration

Global settings can be adjusted from the Frontend, by using the “Configuration” menu.
Please refer to Global and Core Configuration↑ for a detailed parameters description.
Several global parameters can be configured by selecting their desired values and clicking on the “Submit” button.
Available parameters:
figure screenshots/configuration-editor/global-settings.png
Figure 3.12.1 Configuration editor: Global settings
The list of ignored networks can be modified on the same page. The options allow listing as appropriate:
Setting prefixes and ASNs is possibleeither manually, or by importing a text file containing one IP/network in CIDR format or ASN per line.
figure screenshots/configuration-editor/global-settings-ignored-nets.png
Figure 3.12.2 Configuration editor: Ignored prefixes
Failover functionality is switched on or off (global.failover↓) as part of Global configuration too.
Failover license is required for Failover tab to be available.
Failover configuration covers the following parameters:
  • Failover timer - time period in seconds during which master is considered alive and before slave becomes active if there are no announcements from master (global.failover_timer_fail↓).
  • Failback timer - time period before slave node will release control back to master (global.failover_timer_failback↓). This is to protect from failover flapping between master and slave in case of master instability.
  • Slave IPv4 address - indicates to master what is the slave node (global.failover_slave.ip↓). Master uses this address to setup SSH connections and sync its own configuration files.
  • Slave SSH port - indicates the TCP port number for SSH on the slave node (global.failover_slave.port↓). Master uses this port to setup SSH connections and sync its own configuration files.
figure screenshots/configuration-editor/global-settings-failover.png
Figure 3.12.3 Configuration editor: Global failover


3.12.2 BGP and Routers configuration

BGP daemon-related parameters can be configured in the “Configuration → BGP” section.
figure screenshots/configuration-editor/bgp-settings.png
Figure 3.12.4 Configuration editor: BGP settings
BGP routers can be added, removed or modified on the same page.
A new BGP neighbor can be added using the “Add Router” button. Several parameters must be configured:
figure screenshots/configuration-editor/bgp-add-peer-general.png
Figure 3.12.5 Configuration editor: New Router, general settings
figure screenshots/configuration-editor/bgp-add-peer-advanced.png
Figure 3.12.6 Configuration editor: New Router, advanced settings
figure screenshots/configuration-editor/bgp-settings-failover.png
Figure 3.12.7 Configuration editor: New Router, advanced settings

3.12.3 Collector configuration

Global collector parameters, as well as Span and Flow-specific settings can be adjusted by using the “Configuration → Collector” menu item.
figure screenshots/configuration-editor/collector-settings.png
Figure 3.12.8 Configuration editor: Collector settings
The list of prefixes announced by the monitored network can be edited in the same form. Its contents can be also imported from a text file.


3.12.4 Core configuration

All Core parameters affecting the decision-making algorithms can be modified on the next page (“Configuration → Core”).
The following configuration parameters can be adjusted:
figure screenshots/configuration-editor/core-settings.png
Figure 3.12.9 Configuration editor: Core configuration
Outage detection↑ algorithm can be enabled and configured on the same page. Outage detection algorithm can be enabled or disabled using the toggle On/Off buttons at the top of each form.
figure screenshots/configuration-editor/core-settings-outage.png
Figure 3.12.10 Configuration editor: Outage detection
Throttling excessive bandwidth use with Flowspec↑ can be enabled and configured on the same page. The feature can be enabled or disabled using the toggle On/Off buttons at the top of each form.
figure screenshots/configuration-editor/core-settings-overusage.png
Figure 3.12.11 Configuration editor: Overusage
The following configuration parameters can be adjusted:
Prefix relevant BW and Overusage threshold multiplier parameters control the number of Flowspec rules that will be generated automatically. Adjust these values to control the number of Throttling Flowspec policies.
Circuit issues detection ↑ parameters are listed and can be adjusted:
figure screenshots/configuration-editor/core-settings-circuit-issues.png
Figure 3.12.12 Configuration editor: Circuit issues detection
The following configuration parameters can be adjusted:
  • Delta loss to shutdown (core.circuit.high_loss_diff↓) sets threshold to initiate shutting down a provider with circuit issues as a difference between examined provider’s average loss and overall average loss during the given time horizon. Shutdown is attempted only for providers marked accordingly.
  • Delta loss to warn (core.circuit.warn_loss_diff↓) sets threshold to raise a warning regarding issues with a provider as difference between examined provider’s average loss and overall average loss during the given time horizon. Usually this threshold is significantly lower than the shutdown threshold.
  • Delta loss to restore (core.circuit.recover_loss_diff↓) sets low loss level threshold when IRP will restore full functionality over provider that had circuit issues.
  • Issues time horizon (core.circuit.hist_interval↓) sets how many minutes in the past IRP looks for probes with loss over both analyzed provider and all the other providers on the network.
  • Withdraw improvements on warn (core.circuit.withdraw_on_warn↓) instructs IRP to withdraw outbound improvements over provider with circuit issues when warning threshold is reached. By default improvements are withdrawn only when shutdown threshold is exceeded.
  • Restore after (core.circuit.recover_hold_time↓) sets the interval in seconds after which IRP should re-evaluate a provider’s circuit loss and attempt restoring it to normal function. This will be performed only for providers that are configured to attempt to restore after shutdown.
  • Restore interval (core.circuit.recover_monitored_intervals↓) sets the interval in minutes during which IRP will periodically re-evaluate a provider’s circuit loss and attempt restoring it to normal function. This will be performed only for providers that are configured to attempt to restore after shutdown.
The configuration parameters above are applied for all providers even though for individual providers different level of control can be set starting from disabling and ending with attempting both to automatically shutdown and later restore connectivity with it. See also Providers configuration↓


3.12.5 Commit Control configuration

Commit Control↑ algorithm can be enabled and configured on the Commit Control group of pages. It can be enabled or disabled using the toggle On/Off buttons at the top of the form.
If NetFlow is used to collect statistics Routers MUST be configured to export statistics every minute (or as often as possible). Some router models have default export intervals for either inactive or active flows of up to 1800 seconds. Big delays cause IRP to react very slowly to increased load and reduce the effectiveness of Commit Control feature.
If NetFlow is used to collect statistics Routers MUST be configured to export statistics every minute (or as often as possible). Some router models have default export intervals for either inactive or active flows of up to 1800 seconds. Big delays cause IRP to react very slowly to increased load and reduce the effectiveness of Commit Control feature.
The most important parameters for Commit Control are, as follows:
figure screenshots/configuration-editor/core-settings-cc.png
Figure 3.12.13 Configuration editor: Commit Control
Providers Overall block displays Commit Control configuration for all providers including their precedence. See details in the figure below.
Individual provider parameters can be adjusted as well as detail regarding current Commit Control changes applied by IRP can be accessed by following the provided links.
figure screenshots/configuration-editor/cc-providers-overall.png
Figure 3.12.14 Providers Overall


3.12.6 Explorer configuration

To adjust the Explorer-related parameters, the “Configuration → Explorer” menu item must be accessed. The Explorer Configuration↑ and Explorer settings↓ sections should be consulted for detailed Explorer configuration and parameters description.
Explorer parameters:
figure screenshots/configuration-editor/explorer-configuration.png
Figure 3.12.15 Configuration editor: Explorer settings


3.12.7 Providers and Peers configuration

Providers can be added and modified via the “Configuration → Providers and Peers” menu.
figure screenshots/configuration-editor/peer-settings.png
Figure 3.12.16 Configuration editor: Providers configuration
Using the provider control buttons, a specific provider can be temporarily suspended (e.g for a short maintenance in the monitored network), stopped (for long maintenance), or completely deleted. See also: peer.X.shutdown↓. Commit Control can also be disabled or enabled for each provider specifically. (peer.X.cc_disable↓).
The sections below describe the most common groups of provider configuration parameters. Some parameters are repeated on more than one of these groups for convenience.

3.12.7.1 Providers configuration

To add a new provider, the “Add provider” button must be used. Several parameters should be configured for the new provider:
figure screenshots/configuration-editor/add-peer-general.png
Figure 3.12.17 Configuration editor: Adding a new provider, General settings
figure screenshots/configuration-editor/add-peer-cc.png
Figure 3.12.18 Configuration editor: Adding a new provider, Commit Control
  • SNMP-related settings:
Provider specific SNMP parameters are deprecated in IRP 3.7 and later. Refer SNMP hosts configuration↓ and SNMP Hosts settings↓ for SNMP configuration parameters used in IRP 3.7 and newer.
figure screenshots/configuration-editor/add-peer-snmp.png
Figure 3.12.19 Configuration editor: Adding a new provider, SNMP settings
figure screenshots/configuration-editor/add-peer-monitoring.png
Figure 3.12.20 Configuration editor: Adding a new provider, External Monitor
figure screenshots/configuration-editor/add-peer-monitoring-internal.png
Figure 3.12.21 Configuration editor: Adding a new provider, Monitoring
  • SNMP v3 uses additional parameters depending on security services used for monitoring:
Provider specific SNMP parameters are deprecated in IRP 3.7 and later. Refer SNMP hosts configuration↓ and SNMP Hosts settings↓ for SNMP configuration parameters used in IRP 3.7 and newer.
figure screenshots/configuration-editor/add-peer-ipv4.png
Figure 3.12.22 Configuration editor: Adding a new provider, Commit Control
The same parameters can be adjusted for the already configured providers.

3.12.7.2 Internet Exchanges configuration

An Exchange is configured as a special type of provider. The important things to consider when setting up an Exchange are listed below.
It is recommended that Noction systems engineers guide you through Exchange configuration process.
IRP needs one ACL and one PBR rule for each Peering Partner on an Exchange. Internet Exchanges can have hundreds of Peering Partners. Ensure that the number of Access Lists, Access List entries and PBR entries will not exceed router hardware limitations.
  • Once the Exchange is setup IRP will retrieve the routing table on the router in order to setup Exchange peering partners. IRP will require access to the router in order to do so.
When configuring an Exchange its Diag Hop parameter must be provided. Diag Hop for an Exchange represents the list of direct-connected networks configured on the router’s interface towards the Exchange network. This parameter is labeled "IPv4 diagnostic hop" on IRP Frontend.
  • Probing IPs for Exchanges no longer require one IP address per peering partner since this number might be impractically big. Instead a combination of probing IP and DSCP value is used to configure the PBRs. A single probing IP in conjunction with DSCP can cover up to 64 peering partners. A sufficient number of probing IPs will be required in order to cover all peering partners on your exchange.
As a rule of thumb it is better to list the PBR rules for transit providers before the (large number of) rules for Internet Exchange peers. If the many PBR rules assigned to peers on a large Internet Exchange are placed at the beginning of the PBR list some routers evaluate all of them before finding the terms for transit providers and this consumes valuable router CPU resources.
figure screenshots/configuration-editor/ix-settings.png
Figure 3.12.23 An Internet Exchange is similar to a provider and it requires configuration of the Router, the Probing IPs and the other usual attributes
  • Once the Exchange is configured, IRP will need to reset its BGP session towards the router interconnecting with the Exchange in order to retrieve the required routing table information about all peering partners. Once the BGP session is restarted IRP will start fetching Exchange routing tables.
Give IRP sufficient time (~10 minutes) to fetch Exchange routing tables before continuing configuration.
  • IRP offers peering partner autoconfiguration. It retrieves the list of Next Hops (peering partners) on the Exchange with the corresponding list of prefixes individual peers accept.
figure screenshots/configuration-editor/ix-peering-partners-settings.png
Figure 3.12.24 The list of peering partners for the Exchange shows details about each of them and offers access to IRP Autoconfiguration feature and PBR ruleset generator for the router
  • Use the Autoconfiguration feature to create an initial configuration for IRP. Review Exchange peering partners before starting the Exchange. Consider enabling periodic auto re-configurations for selected IX in order to update periodically the value of BGP session monitoring IPv4 address from the Exchange and to add new peering partners. Refer global.exchanges.auto_config_interval↓ and peer.X.auto_config↓.