Unified Assurance Cards Flashcards
A1 competiton list
- IBM Netcool
- BMC Smarts (Vmware)
- HP OpenView
- CA Spectrum
and more
A1 out of scope
Common ask is around
- Configuration management – A1 does not play in this space at all.
- Real time – what does this mean? Its not literal real time – its based upon orchestration or network elements notifying A1 of ‘things’ and A1 then able to take appropriate actions (discovery etc)
A1 Highlights
- DEAL WITH CHANGE MORE QUICKLY
- Fix customer problems quicker (and in a proactive manner)
- Automate & standardise Processes (regardless of technology type)
- Bring in new services and technologies faster than was possible before.
- Unified view of your network (<> siloed approach)
- Multi-tenant
- Single User Interface
- Collects Data from any digital source
- Vendor and Technology Agnostic
- Web Native – all HTML 5 and modern browser independent
- Cloud Native
- Single Scalable Database Layer
- Single Rules Configuration Language
- Open REST API at the Core of the Platform
Exposing all user and admin tasks not just a subset - Delivering Lower Cost of Ownership through Simplified Administration
- Extendable Analytics – applying useful analytics techniques to drive useful business outcomes
Collections Methods and Protocols
- Telemetry (coming soon)
- Rest / JSON API – modern apps require this integration
- Syslog & Flat File (CSV & XML) - common
- SOAP/WebServices -
- TCP Socket
- SNMP
- Syslog
- API
- Database (with DBI which is a perl DB Interface)
- TL1 (Transaction language 1) created by Bellcore
SNMP Overview
SNMP is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behaviour. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, firewalls and more..
SNMP exposes management data in the form of variables on the managed systems organized in a management information base (MIB) which describe the system status and configuration. MIB has a hierarchical structure (to find the OID such as 1.2.4.65.778)
An SNMP-managed network consists of three key components:
• Managed devices
• Agent – software which runs on managed devices
• Network management station (NMS) – software which runs on the manager
Some commands are get and set based on a OID (device ID)
SNMP is a pull mechanism, but Trap (alerts) can be set to push information to the NMS
3 versions:
- SNMPv1 = poor security; sends passwords in clear-text over the network
- SNMPv2c = adding bulk requests…., security with community, password hashing with MD5
- SNMPv3 = adding cryptographic security
To connect to a device we define a community = password
TL1 Overview
Transaction Language1 (TL1) is an ASCII-based management protocol mainly used for managing telecommunication networks (like SNMP). It is a man-machine readable language
Invented by Bellcore in 1980; before protocols were proprietary mainly
Used on SONET (Synchronous Optical Network) used in the US and Canada (<> SDH = Synchronous Digital Hierarchy) in the rest of the world)
TL1 serves as a primary interface between the network element and the manager application, and is used to operate, administer, and maintain the network. The TL1 agent on the managed device serves to provide access to data stored on the managed device. The TL1 manager uses this access to monitor and control the managed device. The data (TL1 messages) are sent and received in the form of byte stream.
The TL1 implementation on the device side and also on the management application allows the user to perform the following functions. • Alarm and Network monitoring • Performance monitoring • Network security and administration • Retrieving inventory data
Unlike SNMP, TL1 is a human-machine interface that contains human-readable strings. Also, unlike SNMP, TL1 includes no concept of a MIB. TL1 was originally specified by Bellcore in 1986 and is now maintained by Ericsson
Performance Thresholding engines
- Standard thresholding engine – this checks for violations based on greater than 75% or less than 10% etc
- Trend threshold engine – this does daily, weely, monthly checks for change – for example: 10% over the last day
- Inside of trend engine – we also have a
predictive trend – where we can notify if
something will breach in X weeks given the
current and past metric data. (maybe
bandwidth has been increasing of the past 4
days is going to hit 100% utilization for a
customer circuit in the next few weeks) - Lastly, we have the Abnormal threshold engine –the idea is to create a confidence band around the data and warn of anomalies
What are the 3 types of RCA provided ?
- Topology based – Use network topology data to find root causes.
- Alerts are show on the graph
- Supervised Event Correlation – Supervised control to improve Event Reduction
- Human control over root cause analysis
- ”No-Code” drag & drop creation of RCA policies
- Capture the knowledge of your most experienced NOC staff; puts to use that industry knowledge within your organization. By using this historical knowledge we can create policies around typical suppression use cases and create automatic workflows to do the needed based on the actual root cause
- Automate previously manual correlations and event suppression
- Unsupervised Anomaly Detection – Real-time ML analysis to detect anomalies
- Will ‘learn’ from your live event stream
- Drive automated response and resolution
Benefits are:
- Eliminate noise and focus on the relevant incidents impacting service
- Achieve upwards of 90% event to ticket
- Transform data into predictive, actionable
- Reduce time to identify issues with high-definition granularity
3 Ways to show collected network data ?
Visual, topology, console dashboard:
- Dashboards allow the user to generate any custom layout or visualization using pre-existing components of the user interface
- Diagrams allow the user to generate completely custom visualization using widgets that map to collected fault and/or performance data.
- Vision allows customers to visualize non-Assure1 data (as well as Assure1 data) overlaid on top of, normally, geographic maps of the world. Common use cases are showing weather/storms, displaying locations of vehicles/trucks, displaying cell towers (and potentially coverage maps). All this data combined with collected Assure1 data allows our customers to make decisions based on solid, actionable data.
What are the 3 layers of the architecture ?
- Collection & Processing
- K8s microservice collection mechanism (based on Go, Python, NodeJs)
- Perl broker
- Telegraf for metric ingestion
- Database
- MariaDB for management and events
- Neo4j for graph DB (topology) <> OrientDB was NoSQL
- Elasticsearch (Elastic is a separate license and cost to the customer (only exception) all rest is included
- InfluxDB for metrics (is an open-source time series database (TSDB))
- Presentation
- Kibana
- Grafana
- Apache Web Server (PHP, Ext JS)
- RabbitMQ message bus
- Solution can be hosted in private or public cloud (AWS, OCI…)
- 3 layers model that can scale horizontally
- A single UI for administrator, customer….based on a Apache Web Server
- Aggregators, collectors are part of the bottom layer. Data are normalized to be further processed
What is a Graph DB and how does it work ?
- Neo4j is a native graph DB <> OrientDB which is noSQL
o Connections are already there build in the DB <> where an index needs to be searched to get the r relationships
o Graph DB can be 1000x faster then RDBMS - A Graph DB is based on nodes with links between them and it is not based on tables like a RDBMS (based on primary, secondary keys joining data and indexes that need to be rebuilt…)
o Graph DB uses memory pointers to find other nodes from the starting node <> indexes -> very efficient and powerful
o Graph DB uses a different query language than SQL, it uses Cypher which is query for Graph (based on pattern matching, more networking style…)
- Nodes are in parenthesis (company:company)
- Relationships are in brackets with Arrow
- In the example we are looking for a company that produces a games but also a company that publishes a game
Customer repartition by SA function (fault, performance, topology) ?
- All of customers use fault management feature of Assure1
- half to 2/3 use performance management
- 1 third uses Topology management
From a customer perspective we have multiple service providers (by far our biggest market) with a number of enterprise customers in varying verticals across healthcare, utilities and finance.
We also have partners both for a consultancy perspective as well as product (ServiceNow – integration w/ Ticketing example)
Fault Management events description ?
- Events can be filtered, tags can be added to them
- Search can be done by device…
- We can link events together (parent and children = symptom events) -> reduce noise
- By default an event has 21 fields but the model can be extended and additional fields added
- A CAPE (Custom Action Policy Engine) rule can be created to search for events (CPU > 95% and bandwidth < x)
- That rule can execute a script such as connect to the device, retrieve the CPU usage and create a SR and put that information into it (written in perl)
Topology characteristics ?
- Physical but also virtual networks
- Topology covers layer 2 and 3
- Topology for layer 1 can be obtained though integration with third party systems
- The main protocol to discover devices is SNMP, but other means can be used such as getting elements from EMS (Element Management Systems) though REST API for instance or data warehouses (direct DB connection)
But also JSON device information can be put into a Kafka topic and retrieved by Assure1 to build the topology
Device Discovery process and states ?
Discovery process
- Devices are added using the discovery jobs: auto discovery job ect…
- Those jobs have rules (include, exclude rules….) defined in perl
- Once the Device auto Discovery has run, the device is in verified state. Next we need to run the Device SNMP Discovery
- SNMP Access configuration in Device Discovery menu need to be defined -> SNMP strings configuration to allow the SNMP discovery
- Exclusion profiles can be defined to exclude devices from the SNMP discovery process (REGEX IP Range with wildcards…) and Including profiles as well
- Manual discovery process; We select the server we want to run the discovery on (providing an IP address for instance)
- Gather Netwok Inventory based on vlans, interfaces
- Once the discovery process is done, we can go to graph from the dashboard
- Tuck away = keep
- Non discoverable; added manually, marked as non automatically discoverable
- Verified; The automatic discovery process has added the device and a ping response confirm that the device can be reached
- Discovered; Discovered by the SNMP discovery process
