eye.lo is a multi-tenant software platform dedicated to Service Provider. Its distributed architecture, based on redundant nodes, insures smooth scalability, optimal level of use of resources, fault tolerance and low latency response for the concurrent requests and big data.
LivingObjects recommends a centralized collection to ease implementation of new customers. However, eye.lo can also be deployed in isolated environment.
eye.lo is deployed in Service Providers’ DCs on a single server or a distributed infrastructure. Above 3000 routers, LivingObjects recommends a distributed architecture which enables smooth scalability across time. I/O are optimized for random data access. Data storage needs to be implemented on physical machine with SSD. The other components can be virtualized, but need dedicated VM infrastructure not to compete with other software for I/O.
LivingObjects recommends Linux Debian distribution with Kernel version greater than 3.16. For other distribution contact LivingObjects at email@example.com. To access eye.lo, end-customers can use any recent web browsers.
NetFlow provides the ability to collect IP network information as it enters or exits an interface. A Flow Record consists of keyed fields and non-keyed fields. Keyed fields are all field(s) which need to be unique in order for a new Flow Record cache entry to be created in the CPE memory. Non-keyed fields provide information such as metrics (byte count, packet count, latency or jitter). For every record, a cache table is created to track and store flow entry. A new cache entry is created when the keyed field(s) of the packet does not match existing cache entry. Otherwise, only the non-keyed fields are updated, e.g. byte count is incremented.
The key difference resides in the information access: SNMP requires collectors to request the information. Netflow collectors passively receive and process flows from all devices. For first case (polling), devices need to store the data available on request. With Netflow, devices send data once processed. Thus, if devices embed the right processing engines (Deep Packet Inspection, passive probe, …), one could have much more detail on traffic and performance using Netflow.
1. Netflow 5: (IPV4-specific,) NFV5 is the most commonly deployed version. The flows exported by the equipment provides 5-tuple keyed fields, Source IP/port, Destination IP/port and protocol, to describe the identities of the systems involved in the conversation and the amount of data transferred.
2. Flexible NetFlow FNF V9: (IPv4&6 compatible) Version v9 has brought FNF capability, which makes Netflow a highly versatile protocol. Its flexibility makes it particularly more relevant for complex reporting and heterogeneous data.
- Flexible key field aggregation
- variable number of data fields.
- unidirectional or bidirectional
- sampled or not
- multi-vendor (430 standardized fields, thousands vendor-specific fields)
- aggregated, synchronized or not for exports
3. IPFIX: (“IP Flow Information eXport”) also referred to as NFv10, IPFIX is the industry standardized version of Netflow. It builds on NFv9 for most of the features, and brings additional flexibility (variable-length fields, sub -application extracted fileds, options-data…)
Note: Netflow version 9 and IPFIX are the export protocols of choices for AVC, because they can accommodate flexible record format and multiple records required by Flexible Netflow infrastructure. IPFix is recommended.
5 minutes is the default recommended granularity for all counters.
eye.lo architecture divides in layers: Proxy, collection node, storage cluster and services. Each component embeds his scalability strategy for a light-touch implementation. The non-blocking technology and distributed architecture used to collect data let eye.lo to achieve a high response rate for hundreds of thousands of multi-vendor devices.
The extreme flexibility and scalability yields a very short lead-time from the order to the delivery, resulting in value from day one.
See Low Level design Guide for more detail.
The provisioning process is highly parallel: Using snmp protocol, all tasks requests are asynchronously sent on the network and smoothed over time. For large seed files, processed equipment responses are batched onto groups of 1000, and returned to the administration UI for the user to track the provisioning progress.
If service providers choose a centralized collection, they have to size the collection link properly. Link sizing recommendation depends on :
- IWAN features enabled: More features = more data to export.
- Bandwidth per site repartition: headquarter with 500 employees will have more variety (=more export) than a small office with 20 employees)
- The time traffic distribution: the CPEs don’t have their max traffic at the same time.
A typical 10 000 CPE enterprise SP IWAN Network requires an 200 Mbps bandwidth
Collection link Max speed = Average flow size x Predicted Max aggregated traffic x Flow count at this max traffic
Please contact LivingObjects for customized sizing.
eye.lo processes and aggregates raw flows coming from the routers to store what is needed for a customer/service profile. Storage size varies depending on:
- Customer profiles: For example, an internet connectivity customer will access only application traffic metrics and a VPN connectivity customer will access traffic and performance metrics.
- The data retention: For example, an internet connectivity customer will access 5 minutes metrics for 1 week, and a VPN connectivity customer will access traffic and performance metrics for 3 weeks.
Storage sizing = Client profile X Data retention rule X Predicted Average aggregated traffic
A typical 10000 CPE, scalable infrastructure is
- Proxy: 1 x 4 CPU, 4 GO RAM, 1 SAS 20 GB (scalable)
- Collect: 2 x 8 CPU, 16 GO RAM, SAS 1 TB (scalable)
- Services : 4 x 8 CPU, 8 GO RAM, 1 SAS 200 GB
Physical environment for DB:
- 2 x (20 CPU/64GB RAM/ 2*1TB SSD disk (RAID1)) (Scalable)
Please contact LivingObjects for customized sizing.