Noction IRP FAQ

Noction Intelligent Routing Platform (IRP) is a product developed by Noction to help businesses optimize their multi-homed network infrastructure. The platform operates at the network edge and receives a copy of the traffic from edge routers, passively analyzes it for specific TCP anomalies, and actively probes remote destination networks for metrics like latency, packet loss, throughput, historical reliability, etc…

It computes a performance or a cost-improvement network traffic engineering policy and applies the new improved route by announcing it to the network’s edge routers via a traditional BGP session.

Noction IRP is designed to help Service Providers and Enterprises that operate a multi-homed network environment improve BGP routing performance.

Yes. You can learn how Service Providers, datacenters and enterprises improved network performance with Noction IRP by reading the success stories on our clients page.

Yes. We can deploy a test installation in your infrastructure. The system can run in a non-intrusive (read-only) BGP mode. It will provide reporting on network performance, providers issues and outages without announcing any BGP updates to the edge routers.

No. IRP deployment is a complex process that needs to be conducted and monitored by our technical support team. If you would like to test the platform in your network, please leave a Trial Request and we will get back to you to arrange a test deployment.

A detailed list of hardware and software requirements can be found in the technical requirements document.

Information about installing and configuring IRP can be found in the product documentation. Noction engineers will fully assist you during the deployment process.

It strictly depends on the complexity of the infrastructure and the feedback speed. Once all prerequisites are ready it takes up to one day.

Intelligent Routing Platform is licensed based on the network bandwidth usage, measured as monthly 95th percentile. Fill in a quote request, and we will prepare a customized quote for you.

Noction accepts credit card payments, wire transfer and PayPal. Checks are accepted only for US customers.

IRP has been successfully tested with Brocade/Foundry, Cisco, Juniper, Huawei, Alcatel, Vyatta, Mikrotik, Arista and ZTE. Generally, IRP is designed to work with any standards-compliant BGP router which supports routing policies and standard BGP attributes.

Considering the inter-datacenter link’s added latency, one IRP instance can optimize networks with multiple physical locations which are in relatively close geographical proximity. If the network’s Points of Presence are located considerably far from each other, multiple IRP instances are required. Please see this post for additional details. Noction support team analyzes the customer’s specific topology and identifies the necessary number of instances.

An IRP instance is required for each geographical location/POP in the case that latency between locations/POPs is lower than the recommended 70ms barrier. Otherwise the Multiple Routing Domains feature can be used to optimize traffic originating in multiple locations. While if you operate a single location with multiple edge routers, a single IRP instance will suffice. IRP is able to handle multiple BGP sessions with your edge routers.

Noction IRP can be delivered as a physical appliance based on a Dell server running CentOS 7 while Noction support team can also remotely deploy the system on your own server IRP cannot be provided as a virtual appliance since the system should be located within the customer’s network.

In production, a dedicated server for each IRP instance is strongly recommended. The system can also be deployed on a VM with matching specifications, provided that this is hardware- or para-virtualization (Xen, KVM, VMware). OS-level virtualization (OpenVZ/Virtuozzo or similar) is not supported.

Starting with version 4.0, IRP can perform automated loss and latency optimization of inbound traffic. This feature improves inbound traffic performance by deflecting it from the worst-performing provider. For the traffic deflection consistency, IRP uses provider traffic engineering capabilities. (the ability to influence traffic based on the announced BGP community).

Starting with IRP version 3.4, IRP supports bandwidth management capabilities for inbound traffic. IRP monitors bandwidth levels and performance characteristics of alternative routes and automatically brings your traffic to the shape you need. IRP uses well-known and proven BGP mechanisms to adjust the count of AS Path Prepends announced by your edge routers for each of your network prefixes.

Starting with version 3.7 IRP introduces Transit optimization features. Transit optimization is an enhancement of Inbound optimization. It relies on the same method of influencing Internet-wide routing – manipulating best path selection by increasing length of AS Path for a prefix carrying traffic on an undesirable interface.

Yes, IRP fully supports IPv6.

The initial configuration is performed by Noction engineers.

Yes. IRP uses two types of BGP monitors to diagnose and report the state of the BGP sessions between the edge routers and the providers as well as network reachability through a specific provider. The information provided by these monitors enables IRP to avoid announcing routing updates that would result in traffic misrouting (sending improvements to a failed provider).

Yes, IRP supports failover mode at the operating system level. As a requirement, one must install two IRP instances on two separate hardware units having the latest CentOS operating system preinstalled. Using the CentOS High Availability feature, one of the IRP instances runs in an Active mode while the second one runs in a Passive mode. Each server must have two network cards: one used for network communication and the other one used for data synchronization with the partner instance. In case of the Active instance failure, the Passive one will immediately take over.

IRP uses regular Ethernet connection for management/probing. An iBGP session between the IRP appliance and your edge router is established on top of that.

Once a better path has been detected, IRP injects the new route with an updated next-hop and a higher local-preference value, so that the optimized routes take precedence over the original ones received from the providers. The updated next-hop is the IP address of the provider that has been selected by IRP as best-performing.

IRP will announce back only the optimized prefixes/routes with the updated next-hop.

IRP uses and analyzes Netflow/sFlow data by gathering a list of relevant prefixes which have to be probed and improved. IRP does not export Netflow or any other type of flow data.

To connect IRP to your edge routers, an iBGP session needs to be established between the IRP appliance and your edge routers.

Yes. IRP supports only CentOS 7, x86_64 distribution.

The networks to be analyzed and optimized are selected from the traffic data by the system’s Collector according to the traffic destination and configurable traffic volume thresholds. IRP will select the prefixes that are exchanging most of the traffic with your network. Each selected network will be probed by the system to detect outages, packet loss, latency and other routing anomalies. If IRP detects a better alternate path to a specific destination, it will automatically reroute the traffic according to your configurations.

The minimum contract period is one year. However there is a month-to-month option available as well at a higher price. Please request a quote for exact pricing.

IRP supports NetFlow v1, v5, v9, jFlow, IPFIX, and sFlow. 

IRP probes the selected destination prefixes via: ICMP, UDP and TCP_SYN probes. The order in which these packets are used for probing can be adjusted in the configuration interface.

After an initial probing (and improvement, if required), each improved prefix is being reprobed in configurable intervals (default value – 4 hours).

In the situation when an IP address is not responding the IRP’s probes, the system will run an indirect probing process and will optimize the whole prefix based on the indirect probing results. The indirect probing algorithms identifies the closest responsive IP to the probed network that belongs to the same ASN. If such an IP is detected, the indirect probing result will serve as basis for the routing decision.

Yes. All current improvements are stored in a persistent database. In case of an extensive downtime, the improvements are temporarily invalidated by the system and submitted for reprobing to confirm their validity.

By default, 70 concurrent probing threads are set up, generating an average outgoing traffic of 1200 Kbps and 230 Kbps of incoming traffic.

The default re-probing interval was calculated considering the complexity of network topologies, number of uplinks and average time per probe to complete. It can be adjusted by administrators after running the system for at least a few days and monitoring probing performance. Beside the default re-probing period, additional prefix probing can be triggered automatically by advanced IRP algorithms or by using the VIP Improvements feature. However, probing the same destination multiple times may flag alerts for network administrators or trigger a security or rate control mechanism in those networks, which is not desirable. To avoid IRP probes resemble malicious packets, we recommend administrators to limit the number of IRP probes to a reasonable level. Without having a sensible limit on the number of probes sent, probing packets will likely start to be dropped, which will lead to inaccurate probing results. More information on IRP probing principles can be found here.

The system uses one of the following methods for probing a remote network: ICMP, UDP, and TCP_SYN. The probing is self-learning, based on the network replies, updating the algorithms accordingly.

For any technical support please contact us at support@noction.com

Any feature request or bug report can be submitted at support@noction.com

In an Intrusive BGP mode IRP actively announces route improvements to your network, while operating in a non-intrusive mode, the system performs the probing and provides reporting on potential improvements without injecting them  into your edge routers.

No, IRP does not modify the packets content at any level.

Yes, for proactive probing there are several PBR settings to configure on your edge routers. In specific complex scenarios, traffic from the IRP platform should pass multiple routers before getting to the provider. If a separate probing Vlan cannot be configured across all routers, GRE tunnels from IRP to the Edge routers should be configured (one GRE tunnel per each edge router). Also, for report generation, Commit Control decision-making and prevention of overloading a specific provider with an excessive number of improvements, a SNMP community per each provider needs to be set (a read-only community is enough).

IRP offers a rich API that gives you the ability to incorporate IRP functionality and data assets into your website applications, mobile apps, monitoring tools, etc.

IRP supports remote user authentication protocols such as LDAP, Active Directory and TACACS.

IRP does not work with MPLS since it has been designed to operate at the edge of the network using BGP.

No, IRP doesn’t affect the BGP configurations running on the edge routers.

IRP can collect and process up to 400,000 Mbps of NetFlow data, moreover there are IRP instances in production that can handle 600,000 Mbps.

Using Flow data is the recommended option since it allows to provide real-time traffic information to IRP without infrastructure changes and at a low cost.

Using Mirrored traffic will allow IRP to detect in a faster way network issues if the min_delay algorithm is enabled. This algorithm basically checks for TCP packet retransmits. In case it detects frequent retransmits, the destination prefix will be injected immediately for probing, therefore allowing IRP to react faster to these issues. Setting up Mirrored traffic can be quite expensive (10G link and NIC) according to the amount of bandwidth utilisation.

For best results, both methods can be used simultaneously.

Yes. IRP is able to intelligently reroute peering traffic across Internet Exchanges as well as across separate eBGP links with your peers.

Yes, IRP is able to announce routing updates to a route reflector, which then propagates them to the edge routers.

Yes, IRP’s front-end provides the full list of current improvements that can be re-routed or deleted at any time. 

Yes, IRP is able to optimize traffic across such providers. However, a requirement is that the network must connect to at least one transit provider that delivers a full routing table.

IRP’s Threat Mitigation feature allows for automated DDoS detection and mitigation using BGP FlowSpec and the Remote-triggered Blackholing mechanisms. It requires minimum human interaction and comes with a user-friendly interface as well as versatile alerting/notification options.

IRP can integrate with your current network monitoring systems in the following ways:

1. IRP uses SNMP traps to send alerts towards the customer’s monitoring systems to notify about events that administrators have chosen to monitor. These are fully adjustable and administrators can decide upon which events should trigger notifications and then configure them on the platform.

2. REST API which provides the ability to access all statistics provided by IRP and even initiate manual probing for specific destinations.
IRP can also send email and sms notifications for various events.

In this case the BGP session between your edge routers and the IRP appliance is disconnected and all improvements are automatically withdrawn from the routing tables. The router(s) start referring to the standard BGP routing tables that are received from your external peers, thus no downtime occurs and the traffic starts flowing through the regular non-optimized paths.