- AVC: Application Visibility and Control. Cisco Deep Packet Inspection feature embedded in routers. it enables application recognition based on signature and fields extraction.
- ART: Application Response Time. Cisco passive probe embedded in routers. It enables TCP application performance metrics such as latency per network part.
- BR: Border Router. Cisco PfR component
- CSR: Cloud Services Router
- FNF: Flexible NetFlow. Latest Netflow version.
- IP: Internet Protocol – Layer 3 Datagram Protocol.
- IPFIX: Internet Protocol Flow Information Export. Industry standard for Netflow
- LAN: Local Area Network
- MACE: Measurement, Aggregation, and Correlation Engine
- MC: Master Controller Cisco PfR component
- MMA: Cisco Metric Mediation Agent. Cisco passive probe embedded in routers. It enables TCP & UDP application performance metrics.
- NAT: Network Address Translation
- DPI: Deep Packet Inspection. Generic name for application recognition engine over telecommunication network.
- NBAR2: Network Based Application Recognition. Cisco Deep Packet Inspection Engine
- PfR: Performance Routing
- SNMP: Simple Network Management Protocol
- TCP: Transmission Control Protocol—L4 Reliable Transport Mechanism.
- UDP: User Datagram Protocol—L4 Transport Mechanism. Connectionless transport layer protocol
- VRF: Virtual Routing and Forwarding
- WAAS: Wide Area Application Services
- WAN: Wide Area Network
Cisco is a feature bundle embedded in routers, targeted at improving end-user experience when they use applications over Wide Area Network (WAN). Cisco IWAN provides the ability to report your application performance metrics, enables per-application policy for granular control of application bandwidth use (Application Visibilty and Control, AVC), monitors network performance and selects the best path for each Class of Service (Performance Routing, PfR), and optimize application traffic for faster response time and less bandwidth (Wide Area Application Services, WaaS).
Netflow version 9 and IPFIX are the protocols of choices for Cisco IWAN to export information from the routers.
eye.lo is a probe-less application-aware platform. Network information are exported by IWAN features towards eye.lo through an open export format Netflow Version 9 and IP Flow Information Export (IPFIX).
Eye.lo leverages Cisco AVC application recognition and performance metrics to:
- Provide visibility into different types of traffic,
- Quickly isolate and troubleshoot application performance issues,
- Check CoS policy consistency across the Network
eye.lo leverages Cisco PfR data to:
- Display synthetic view of hybrid infrastructure based on path change & out-of-policy event.
- Provide full visibility on traffic per path when PfR intelligently load balances traffic over all WAN paths to protect critical applications from fluctuating WAN performance.
- Understand performance issue based metrics (Jitter, latency, loss)
eye.lo installation and operation don’t need any additional 3rd party license or tool to deliver full visibility on critical application. eye.lo is a probe-less solution which leverages advanced metrics provided by Cisco Intelligent WAN features embedded in Customers Premises Equipment (CPE). No additional box is needed to provide full visibility on critical application over the network.
Cisco IWAN + eye.lo, without any additional box, enables:
- Full visibility on application traffic and optimization
- Multi-tenant massive deployment
- Sober storage strategy & best responsiveness
Highly customizable environment
Launching IWAN services is:
- Deciding service scope available for enterprise customers.
- Adapting user rights and eye.lo features accordingly,
- Reviewing the network customer topologies to define routers templates and check IWAN impact on existing CPE portfolio
- Sizing the collection link and eye.lo hosting hardware
- Adapting the provisioning system to automatically deliver the seed files to eye.lo platform every night
- Training the sales and manage services team
Based on experience, LivingObjects can deliver a full set of professional services to help deploy IWAN services in less than three months.
In the past, typical network traffic could easily be identified using well known port number. HTTP, HTTPS, POP3, or IMAP were among common traffic seen in enterprise. Today, there is increasing number of applications which is delivered over HTTP – both business and recreational applications. And many applications use dynamic ports such as Exchange, and voice and video which are delivered over RTP. This makes them impossible to be identified by looking at port number.
NBAR2 is Cisco’s Deep Packet Inspection (DPI), based on application signature, and Field Extraction (FE) technologies, to retrieve fields such as HTTP URL, SIP domain, mail server, and so on. Application information such as Sharepoint, Netflix, or Google Docs is provided by Nbar2 signature dictionary, called protocol pack. The protocol pack is updated several times a year to include new applications. Version 16.0 includes more than 1500 signatures.
PfR is part of Cisco IWAN. PfR monitors network performance and routes applications based on application performance policies and load balances traffic based upon link utilization levels to efficiently utilize all available WAN bandwidth. PfR is comprised of two major Cisco IOS components, a Master Controller (MC) and a Border Router (BR).
The Master Controller is a policy decision point at which policies are applied to various traffic classes that traverse the Border Router systems.
- The hub master controller is the master controller at the hub-site, which is either a data center or a head quarter. This is the device where all policies are configured. It also acts as master controller for that site and makes optimization decision.
- Branch Master Controller: The Branch Master Controller is the master controller at the branch-site. There is no policy configuration on this device. It receives policy from the Hub MC. This device acts as master controller for that site for making optimization decision.
Border Routers (BRs) are in the data forwarding path. Border Routers collect data from their Performance Monitor cache and smart probe results, provide a degree of aggregation of this information, and influence the packet forwarding path as directed by the Master Controller to manage user traffic.
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.
You need to configure data export on CPEs. Data will be exported using Netflow/IPFIX towards eye.lo.
- The Exporter defines the source interface (LAN/WAN) and the destination IP address of the remote collector
- The Monitor attaches records and exporters to the devices interfaces to activate the monitoring. It also configures the cache maximum size (32k recommended for small branch routers to 200k for DCs) and strategy (Synchronized 5 minutes recommended).
You may configure one of the following options (see LLD for details): static LO Performance Monitors, custom LO EZPM, EZPM ‘application-performance’ profile, FNF, TNF.
Compared to the relative simplicity of SNMP monitoring metrics, IWAN features comes at an expense on the Network device in terms of memory (need for anticipation in configuring the cache size) and CPU (for advanced processing). Cisco has introduced EZPM in latest version of IWAN to decrease CPU load. Service providers have to check if the needed additional resources on routers is compliant with their existing portfolio (ie: Which router for which contracted bandwidth).
On Top of Cisco IWAN dictionary, eye.lo can recognize traffic based on IP, port, HTTP hostname, SSL (HTTPS) server name. The workflow is the following:
- Does the flow match an embedded eye.lo customer specific application ?
- If no match, does it belong to the Nbar2 dictionary?
- If no match, does it match with a IANA service based on well-known ports?
If no match then the flow is classified as unknown