Avaya Diagnostic Server 2.0
SLA Mon™ Best Practices Guide
Avaya Client Services
October 2014
Abstract
This document provides best practices guidelines for the
Avaya Diagnostic Server 2.0 SLA Mon™ Server. It
provides guidance on product administration and usage.
While not covered directly in this document, references are
provided for product installation, registration, and licensing.
This document is intended to supplement, not replace, the
product deployment and administration guides.
© 2014 Avaya Inc. All rights reserved.
2
Disclaimer
All information in this document is subject to change without notice.
Though reasonable measures have been taken to provide accurate
information, it is provided without guarantee of complete accuracy and
without warranty of any kind. It is the user’s responsibility to verify and
test all information in this document. Avaya shall not be liable for any
adverse outcomes resulting from the application of this document; the
user accepts full responsibility.
© 2014 Avaya Inc. All Rights Reserved.
Avaya and the Avaya Logo are trademarks of Avaya Inc. or Avaya ECS
Ltd., a wholly owned subsidiary of Avaya Inc. and may be registered in
the US and other jurisdictions. All trademarks identified by ® and ™
are registered trademarks or trademarks, respectively, of Avaya Inc. All
other registered trademarks or trademarks are property of their
respective owners.
© 2014 Avaya Inc. All rights reserved.
3
Contents
 Avaya Diagnostic Server Overview
 SLA Mon™ Certificate Overview
 SLA Mon™ Administration
 SLA Mon™ Usage
 SLA Mon™ Alarms
© 2014 Avaya Inc. All rights reserved.
4
Avaya Diagnostic Server Overview
© 2013 Avaya Inc. All rights reserved.
5
Avaya Diagnostic Server with SLA Mon™ Technology
Level Set on Components & Terminology
Avaya Diagnostic Server
with SLA Mon™ Technology
SLA Mon™ Server
SAL Gateway
Endpoint
Diagnostics
Network
Monitoring
 Advanced diagnostic capabilities differentiate the Avaya solution and Avaya maintenance
 SAL gateway – available to all Avaya maintenance customers
– Secure connection between Avaya and the enterprise
– Gateway for Avaya services delivery
 SLA Mon™ server – available to Support Advantage Preferred and Avaya Networking GE
maintenance customers
– Endpoint Diagnostics
– Network Monitoring
Avaya Diagnostic Server and its components are subject to license terms under the respective End User License Agreements for SAL
Gateway and SLA Mon.
© 2014 Avaya Inc. All rights reserved.
6
How SLA MonTM Technology Works
Intelligent agents embedded in Avaya products and controlled
by the SLA Mon™ server to provide advanced capabilities
© 2014 Avaya Inc. All rights reserved.
7
Training Videos and Product Documentation
Avaya Diagnostic Server on YouTube/AvayaMentor
 Wide variety of training videos available.
 Specific videos related to installation:
– How to Install the Avaya Diagnostic Server 2.0 using the Attended Mode
– How to Install the Avaya Diagnostic Server 2.0 using the Unattended Mode
– How to Edit and Validate the ADS 2.0 unattended install ADS_Response.properties file
– How to perform an unattended upgrade or migration to Avaya Diagnostic Server 2.0
– How to Install the Avaya Diagnostic Server 2.0 Virtual Appliance
– How to perform a SAL VE 1.0 Migration to Avaya Diagnostic Server 2.0
 SLA Mon Server must be licensed after installation.
– Licensing your SLA Mon for Avaya Diagnostic Server 2.0
Documents can be found on the Support portal: https://support.avaya.com/ads
 Deploying Avaya Diagnostic Server 2.0
 Administering Avaya Diagnostic Server 2.0 with SLA Mon
© 2014 Avaya Inc. All rights reserved.
8
SLA Mon™ Certificate Overview
© 2013 Avaya Inc. All rights reserved.
9
Digital Certificates Provide Secure Communication
SLA Mon
Server
server identity
certificate
registration
certificate-based
authentication
Agent
certificate authority
(CA) certificate
 The SLA Mon agent registers with the SLA Mon server.
– Using a matching pair of digital certificates, the agent authenticates
the server to ensure it is receiving instructions from a trusted server.
– The agent obtains from the server an encryption key.
 All subsequent communication between the server and the agent is
encrypted using the encryption key.
 Nothing works if the SLA Mon server and agent do not have a
matching pair of certificates.
© 2014 Avaya Inc. All rights reserved.
10
Demo Certificates – Avaya Diagnostic Server 1.0
SLA Mon
Server
Agent
demo CA cert
demo server
identity cert
 With Avaya Diagnostic Server 1.0 we shipped all components – SLA
Mon server, IP phone agents – with demo certificates.
 The demo certificates are meant for lab use, product demonstration
use, etc.
 Customers have the option to install their own custom certificates for
production use, and this is the best practice recommendation.
 Some customers continue using the demo certificates in production,
for various reasons.
© 2014 Avaya Inc. All rights reserved.
11
Demo Certificates – Avaya Diagnostic Server 2.0
SLA Mon
Server
No demo cert by
default; customers
may install the demo
cert if they wish.
demo CA cert
Agent
demo CA cert
demo CA cert
 With Avaya Diagnostic Server 2.0 we removed the demo certificate from the SLA Mon
server.
– Purpose is to encourage customers to make a conscious decision regarding the certificates
they will use.
– A root-level command (‘installdemocert’) allows customers to install the demo certificate if that
is what they want to do.
 See product document:
– “Administering Avaya Diagnostic Server 2.0 with SLA Mon,” Chapter 6: Managing Certificates.
 In future product releases, the demo certificate will also be removed from all the agents,
but that is not the case today.
© 2014 Avaya Inc. All rights reserved.
12
Three Certificate Options
 Avaya demo certificates.
– Intended for lab use and product demonstration use.
– Not intended for production use, but ultimately up to the customer and many are doing it.
– All customers who choose to use the Avaya demo certificates are using the same certificates. In
other words, an SLA Mon server at CompanyX could control the agents at CompanyY because they
are all using the same certificates.
– Customers have no control over these certificates.
 Custom certificates – externally or internally signed.
– Many customers have custom certificates that they use, and processes for generating their own
certificates.
– These certificates can be externally signed by a 3rd party certificate authority (CA) like Verisign.
– These certificates can be internally signed by a CA in the enterprise security group.
– These certificates are unique to the customer and controlled by the customer and vendor.
Important: Currently the SLA Mon agents only accept certificates signed by a root authority.
Certificates signed by an intermediate authority are currently not supported.
 Custom certificates generated by SLA Mon Server.
– The SLA Mon server has a utility that allows customers to generate and sign certificates.
Certificates created in this manner are often called self-signed certificates.
– These certificates are equally secure from a functional standpoint. But since the CA is the server
itself and whoever controls the server, the key used to sign the certificate is not nearly as controlled
as a key owned by the enterprise security group or an external vendor like Verisign.
– See product document: “Administering Avaya Diagnostic Server 2.0 with SLA Mon,” Chapter 6:
Managing Certificates.
© 2014 Avaya Inc. All rights reserved.
13
Certificate Capabilities
ADS 2.0
SLA Mon
Server
•
•
•
•
Ships with no certificate.
Customer may install Avaya demo certificate.
Customer may install custom certificate.
The same and only one certificate is used to communicate with all the agents on the
system – 9600 series IP phones, G430/450 media gateways, ERS/VSP data switches.
• Ships today with Avaya demo certificate embedded; will remove in future.
• Has capability to install custom certificate using the TRUSTCERTS parameter in the
46xxsettings file.
Important: See the interaction with the telephony certificate on the next slide.
The SLA Mon certificate must be first in the TRUSTCERTS list.
Agent
Note: Best practice is to populate this parameter even if using the embedded
demo certificate, as in a future upgrade of the phone’s firmware that
embedded certificate will be gone.
• See product document – “Administering Avaya Diagnostic Server 2.0 with SLA Mon,”
Chapter 3: Administering the SLA Mon agent.
• Prior to R6.3.6/FW 36.8.0 …
• ships with Avaya demo certificate embedded.
• cannot install custom certificate; must use demo certificate.
• As of R6.3.6/FW 36.8.0 …
• does not ship with demo certificate embedded.
• does have the capability to install a certificate, demo or custom.
• Ships today with Avaya demo certificate embedded.
• Cannot install custom certificate; must use demo certificate.
• Future releases TBD …
• may or may not ship with demo certificate embedded.
• will have the capability to install a certificate, demo or custom.
• See ERS/VSP product documentation for latest information.
© 2014 Avaya Inc. All rights reserved.
14
SIP Phone
SLA Mon
Server
Sequence
1.
2.
3.
4.
5.
6.
7.
Phone boots up.
Loads boot code.
Loads application
code, which includes
SLA Mon agent.
Acquires IP address.
Downloads settings
file from HTTP
server.
Settings file should
contain the
TRUSTCERTS
parameter with
name(s) of cert(s) to
download.
Cert(s) must be
placed in the same
server and directory
as the settings file
and phone binaries.
Session
Manager
SIP Phone
IP phone
boot code
SLA Mon
agent code
IP phone application code
embedded demo
cert for SLA Mon
Embedded demo
cert for telephony
Linux OS
Once any cert is downloaded to the trust store, neither
of the embedded demo CA certs is used. Both the SLA
Mon cert and the telephony cert must be loaded to the
trust store. In case either of the demo CA certs is
needed, we include the respective demo CA cert in the
SLA Mon server public directory and in the IP phone
software package. When there are multiple certs, the
SLA Mon cert must be listed first.
Important: An IP phone differentiates files for download by filename only. If you want the phone to download a new file,
such as a new phone binary or new certificate, the filename must be different than the file that’s already installed on the
phone. Otherwise the phone will not download the new file because to the phone the file is already loaded.
© 2014 Avaya Inc. All rights reserved.
15
H.323 Phone
SLA Mon
Server
Comm.
Manager
H.323 Phone
SLA Mon
agent code
Sequence
IP phone
boot code
IP phone application code
embedded demo
cert for SLA Mon
Today the CM telephony application
does not use certificates, but this
will change in the future.
Same sequence as the
SIP phone.
Linux OS
We anticipate that when H.323 phones and
Communication Manager start using digital certificates,
the operation of the H.323 phone and trust store will be
the same as the SIP phone.
Important: An IP phone differentiates files for download by filename only. If you want the phone to download a new file,
such as a new phone binary or new certificate, the filename must be different than the file that’s already installed on the
phone. Otherwise the phone will not download the new file because to the phone the file is already loaded.
© 2014 Avaya Inc. All rights reserved.
16
9600 SNMP MIBs
 The latest 96x0/96x1 H.323 MIBs and latest 96x1 SIP MIB contain the
following object:
endptTRUSTCERTS
 96x0/96x1 H.323 MIB description:
“Trusted Certificates list. This variable returns the current trusted certificates to be
downloaded; 0-255 ASCII characters, 0 or more filenames or URLs separated by
commas.”
 96x1 SIP MIB description:
“Trusted Certificate URLs. This variable returns the URLs of certificate files that are
considered as trusted certificates and requested to download into the endpoint at
boot-time.”
© 2014 Avaya Inc. All rights reserved.
17
SLA Mon™ Administration
© 2013 Avaya Inc. All rights reserved.
18
SLA Mon™ Administration
User Interfaces
© 2013 Avaya Inc. All rights reserved.
19
Login to SLA Mon GUI
© 2014 Avaya Inc. All rights reserved.
20
Access the SLA Mon CLI
Enter CLI mode.
 CLI does not have all the
functionality of the GUI,
though most Endpoint
Diagnostics functions can
be performed over CLI.
 See product document:
“Administering Avaya
Diagnostic Server 2.0 with
SLA Mon.”
 Note: Avaya Diagnostic
Server 2.0 contains SAL
Gateway 2.3 and SLA
Mon 2.3.
© 2014 Avaya Inc. All rights reserved.
21
SLA Mon™ Administration
Agent Enablement
© 2013 Avaya Inc. All rights reserved.
22
SLA Mon Agents Explained
 Intelligent agents (SLA Mon agents) are embedded in…
– 9600 Series Deskphones
– G430/G450 Media Gateways
– ERS and VSP Ethernet switches
 The agents are controlled by the SLA Mon server to perform…
– Network Monitoring (all agents)
– Endpoint Diagnostics (IP phone agents)
 The agent must be enabled in each host product.
 In the case of IP phones, specific agent functions must be enabled
individually.
 The SLA Mon server must discover each agent, and each agent
must register with the server.
– Registration includes authentication using digital certificates, and a
key exchange for encryption.
– Once an agent is registered, the communication between the server
and the agent is encrypted.
© 2014 Avaya Inc. All rights reserved.
23
Supported Products w/ SLA Mon Agents
Type
IP Deskphone
Gateway
Networking
Switch
Model
Model / Firmware Number
96X0 H.323
9610 – FW 3.1.5 (packet capture only; no remote control)
9620, 9630, 9640, 9650, 9670 – FW 3.2, 3.2.1, 3.2.2
96X0 SIP
Not Supported
96X1 H.323
9608, 9611, 9621, 9641 – FW 6.4
96X1 SIP
9608, 9611, 9621, 9641 – FW 6.2.2, 6.3.1, 6.4
9601 – FW 6.3.1, 6.4
430
FW 32.24, 32.26, 33.13, 34.5, 36.8
450
FW 32.24, 32.26, 33.13, 34.5, 36.8
ERS 3500
FW 5.1.2
ERS 4000
FW 5.7.1
ERS 5000
Not Supported
ERS 8800 / 8600
FW 7.2.10
VSP 4000
Not Supported
VSP 7000
VSP 7024 – FW 10.3.1
VSP 9000
FW 3.4
For the latest information please go to https://downloads.avaya.com/css/P8/documents/100180195
© 2014 Avaya Inc. All rights reserved.
24
Enable the Agent in IP Phones
46xxsettings file parameters
SLMSTAT 1
Enable the agent. This also enables the network monitoring function.
SLMSRVR <a.b.c.d>
Set IP address of the SLA Mon server. Agent will only talk to this server (for
security and control).
SLMCTRL 1, 2
Enable agent function – IP phone remote control (Agent Remote GUI).
1 = enable
2 = see below for 96x1 H.323 R6.4 local control function
SLMPERF 1
Enable agent function – IP phone events monitoring (Agent Remote GUI).
SLMCAP 2
Enable agent function – IP phone remote packet capture.
1 = feature not yet available: packet capture without RTP payload
2 = packet capture with RTP payload (see below for 96x1 H.323 R6.4)
Craft DEBUG Menu for 96x1 H.323 R6.4

If SLMCTRL=2
– then SLA Mon remote control can be enabled/disabled locally (disabled by default).

If SLMCAP=2
– then SLA Mon packet capture with RTP payload can be enabled/disabled locally (disabled by default)

Values for both local parameters are: “Disabled,” “Enabled,” and “Active.”

DEBUG menu configuration requires PROCPSWD to be configured to non default value (27238).
© 2014 Avaya Inc. All rights reserved.
25
User Prompts – 96x1 H.323 R6.4
 If IP phone remote control or packet capture is activated, the
phone will display the
&
icons respectively, alerting
the user that someone is controlling the phone.
 If these occur during a call, there will be “beeps” on the call
every few seconds.
 Note that
also appears when tcpdump is running using
SSH connection.
© 2014 Avaya Inc. All rights reserved.
26
96x1 SNMP MIBs
 The latest 96x1 H.323 and SIP MIBs contain the following object:
endptSLMSTAT
 96x1 H.323 MIB description:
“SLA Monitor permission flag. This variable returns 1 if the Avaya Service Level
Agreement (SLA)_Monitor is enabled, else 0.”
 96x1 SIP MIB description:
“Indicates whether the SLA monitor agent is enabled or disabled. This variable
returns a 0 if the monitor is disabled (default) and 1 if the monitor is enabled.”
© 2014 Avaya Inc. All rights reserved.
27
Enable the Agent in Media Gateways
G450-001(super)# set sla-monitor enable
<enable the SLA Mon agent>
G450-001(super)# show sla-monitor
SLA Monitor:
Enabled <agent status>
Server Address: 10.13.7.124 <currently registered to this SLA Mon server>
Server Port:
50011
Capture Mode:
All <disregard; unrelated feature>
Version:
1.3.4 <agent version>
 Certificate management commands are added to the 36.8 firmware.
 Currently the media gateway cannot specify the SLA Mon server IP address
via configuration. This means any SLA Mon server (if there are multiple in
the enterprise) can take control of the agent in the media gateway. This
necessitates a future enhancement in the media gateway.
 Media gateway firmware loads prior to 36.8 incorrectly report the default
gateway address as 0.0.0.0 instead of the router address. Because the
SLA Mon server uses the reported default gateway address to identify the
subnet, this requires a workaround for media gateways, to be covered later.
© 2014 Avaya Inc. All rights reserved.
28
Enable the Agent in ERS and VSP Switches
 Enable the agent and assign an IP address.
– By default the agent uses the switch/stack IP address if a specific agent
address is not configured.
 Note: Commands are common across ERS 3500, 4000, and 5000
families.
 To view current configuration:
enable <enter privileged exec mode>
show application slamon agent
 To configure SLA Mon agent:
enable
configure terminal
application
slamon agent ip address {A.B.C.D}
slamon oper-mode enable <enable the agent>
slamon server ip address {A.B.C.D}
 See this deck’s appendix and networking product documentation for
full listing of SLA Mon-related commands.
© 2014 Avaya Inc. All rights reserved.
29
SLA Mon™ Administration
Agent Discovery
© 2013 Avaya Inc. All rights reserved.
30
Obtain Network Topology
The ultimate objective is to create a logical
topology within SLA Mon that matches the
physical network topology. This requires
knowing the network topology and where
the agents are located in that topology.
© 2014 Avaya Inc. All rights reserved.
31
Discover the Agents
1. Populate location.
2. Add an IP address range
to scan for agents. Add a
zone designation (optional).
3. Select one or more
ranges previously entered,
and run discovery.
SLA Mon polls all the IP
addresses in the range to
discover agents. This is
surprisingly quick.
© 2014 Avaya Inc. All rights reserved.
32
Discover the Agents (zoom in)
/21 is the smallest mask (largest IP address range) permitted. This particular entry scans 10.1.0.1 thru 10.1.7.255 to
discover agents. This is nothing more than an IP address range. It implies nothing about how this range is subnetted in
the network. The individual subnet information (subnet mask and default gateway) is received from the agents.
Warning: Zone assignments made here overwrite the
zone assignments on the Zone Management page.
Santa Clara’s IP address range is large
enough that it requires 4 discovery entries.
The other cities only require a single entry.
© 2014 Avaya Inc. All rights reserved.
Creating zones for the cities puts the
individual IP subnets into a display
grouping, explained in coming slides.
33
See Discovered Agents
Prune the list by location or
zone, and/or search for a
specific agent.
All discovered agents
are listed.
- Blank means
discovered.
- Icon means
manually disabled.
Important: Today we
do not track real-time
agent status. An
agent entry simply
means that at one
time it was
discovered. In a
future release we will
add a heartbeat
mechanism and
indicate the real-time
status
of each agent.
© 2014 Avaya Inc. All rights reserved.
Note: SLA Mon identifies IP subnets by the default
gateway reported by the agent, instead of the familiar
network/mask designation. This may change in the future,
but for now this is how IP subnets are identified.
34
G430/G450 Media Gateway Workaround
Important: In releases prior to firmware 36.8 the G430/G450 media
gateway incorrectly reports its default gateway address as 0.0.0.0
instead of the router address. To work around this, SLA Mon assigns
a router address of a.b.c.0 with a.b.c being the first three octets of
the media gateway’s own IP address. This workaround applies to
any agent that reports 0.0.0.0.
© 2014 Avaya Inc. All rights reserved.
35
SLA Mon™ Administration
Zone Management (optional)
© 2013 Avaya Inc. All rights reserved.
36
Zones Explained
 A zone is a way to group IP subnets for display purposes, to more easily see
inter-zone test results and intra-zone test results.
 We can create a zone of one city. The IP subnets in the Santa Clara office can
be grouped into a zone called “SantaClara_Zone.”
 We can also create a zone of multiple cities.
– We can create a California zone and a Texas zone and put select cities into each zone.
– Or we can create a USA zone and an Australia zone and put select cities into each
zone.
 We can create zones within the same city.
– Within a college campus in one city, we can create an “Engineering” zone and a “Fine
Arts” zone and a “Sociology” zone.
– Within a corporate campus we can create a “Bldg A” zone and “Bldg B” zone.
– Within a large building we can create a “Floor 1” zone and a “Floor 2” zone.
 An administrator can create zones to suit the purposes of the enterprise, to
make the network performance displays more manageable.
– We want to see at a high level the tests between the zones.
– We want to see separately the tests between subnets within a zone; to do this we drill
down into that zone.
 This grouping is only for display purposes. All tests are between IP subnets, not
between zones.
© 2014 Avaya Inc. All rights reserved.
37
Zone Management
If agents were discovered on the Discovery tab w/o a zone designation,
they can be assigned to a zone after discovery. Likewise, a zone assigned
at discovery time can be changed after discovery.
2. Select zone to add subnets to.
3. Assign all IP subnets in the
city of Sacramento to zone
“Sacramento.”
1. Add new zone name.
5. The selected IP subnets
will appear in the
Sacramento zone and be
grouped for display.
4. Or add individual IP subnets
in the city of Sacramento to
zone “Sacramento.”
Note: SLA Mon identifies IP subnets by the default
gateway reported by the agent, instead of the familiar
network/mask designation. This may change in the future,
but for now this is how IP subnets are identified.
© 2014 Avaya Inc. All rights reserved.
Warning: Any zone changes made here do not transfer
to the Discovery tab. If agents are re-discovered on the
Discovery tab using the previous discovery entries, they
will overwrite the zone assignments on this page.
38
Summary View of Locations and Zones
5x5 summary matrix of a
network that contains 5
locations, 2 of which are
zones:
- Europe zone
- North America zone
- Bangalore subnet
Click on blue cell
to drill into zone.
- London subnet
- Sydney subnet
Important: This shows a full mesh of network tests, from every
location to every location. This is NOT the best practice and will be
explained in more detail later.
© 2014 Avaya Inc. All rights reserved.
39
Drill into the Zones
When we drill into the North America
zone we see that there are two
subnets – Montreal and Sacramento.
When we drill into the Europe zone
we see that there are two subnets –
Munchen and Salzburg.
© 2014 Avaya Inc. All rights reserved.
40
Zone Limitations
 The zone hierarchy is limited to one level.
– We cannot create a zone consisting of multiple zones.
– Right now we don’t anticipate a need for this.
 Only one test can be created between a zone pair.
– This is an intentional limitation.
– Suppose we try to create these two tests:
– 10.1.1.1 (SantaClara_Zone) to 10.10.1.1 (Toronto_Zone)
– 10.1.2.1 (SantaClara_Zone) to 10.10.2.1 (Toronto_Zone)
– The second test will be blocked by SLA Mon.
– Because we segregated the display into zones, we cannot show
multiple test results for the same zone pair.
– If there were no zones, these tests would be permitted as
individual subnet tests.
– The zones need to be created such that only one test is required
for any zone pair.
© 2014 Avaya Inc. All rights reserved.
41
SLA Mon™ Administration
Network Test Administration
© 2013 Avaya Inc. All rights reserved.
42
Tests Explained
 Working in pairs, SLA Mon agents send synthetic test traffic
between one another to measure the network response.
– By synthetic we mean the tests are designed to look like live
traffic but they are not live traffic – not live audio calls or video
sessions or data sessions.
– By network response we mean packet loss, jitter, and delay.
 In addition…
– A mean opinion score (MOS) is calculated using the network
response data, per an ITU-T recommendation.
– There are periodic tests to monitor DSCP markings hop by hop.
– SLA Mon checks to see if packets are re-ordered during
transmission – ie, transmitted order: 1 2 3 4 5; received order: 1 3
2 4 5.
– SLA Mon checks to see if packets are duplicated during
transmission – ie, transmitted packets: 1 2 3 4 5; received
packets: 1 1 2 3 4 4 5.
© 2014 Avaya Inc. All rights reserved.
43
Set DSCP Values
Set the values used in the
enterprise.
Check if enterprise uses video;
uncheck otherwise.
© 2014 Avaya Inc. All rights reserved.
44
Set Alarm Thresholds
180ms is the commonly accepted value for one-way delay.
These are commonly accepted
values for jitter and loss, though
perhaps a bit low in practicality.
Set based on the enterprise’s
tolerance levels.
An alarm is triggered if the
threshold is breached this
many times in an hour span.
4.0 - 4.5 is considered PSTN toll quality.
Down to 3.6 is considered business quality.
e-MOS is estimated mean opinion
score, calculated using the ITU-T
G.107 recommendation.
© 2014 Avaya Inc. All rights reserved.
45
Create a Test Pattern
1. Add new pattern name.
2. Select test pattern
for editing.
Test runs for 1sec, data is compiled and sent to SLA
Mon server, and test runs again. This cycle repeats
every 5-10secs, depending on how many total tests
the SLA Mon server is managing, how many network
links each agent is monitoring, the processing
capacity of the server, latency in the network, and
other factors.
3. Maximize these unless you’re concerned
about too much test traffic on the network.
For each test pair, the G.729 pattern puts roughly one G.729
call’s worth of traffic (<30kbps) onto the network. Likewise the
G.711 pattern puts <100kbps onto the network.
4. Select G.729 or G.711 (G.729 recommended for most cases).
© 2014 Avaya Inc. All rights reserved.
46
Add Tests Manually to the Pattern
Select subnet1 and subnet2 and add test pair.
Repeat as necessary. Save pattern.
All 3 traffic types are added.
Important: One entry represents both directions.
© 2014 Avaya Inc. All rights reserved.
47
Add Tests Using Bulk Tool – option 1
1. Select the default pattern, which is a full-mesh pattern.
2. Export the full-mesh pattern to a
spreadsheet.
3. Manually prune the spreadsheet.
4. Import the pruned spreadsheet test pattern
into a new pattern and save the pattern.
The default test pattern is 1) all zones to all zones (full mesh of zones); 2) full
mesh of subnets within a zone; 3) full mesh of subnets not assigned to a zone;
4) full mesh of unassigned subnets to zones (subnet to zone tests).
© 2014 Avaya Inc. All rights reserved.
48
Add Tests Using Bulk Tool – option 2
1. Start with an empty test pattern and generate all subnet
combinations (full mesh pattern). Save the pattern.
2. Export the full-mesh pattern to a
spreadsheet.
3. Manually prune the spreadsheet.
4. Remove all test pairs from the test
pattern. Save the pattern.
5. Import the pruned spreadsheet test
pattern. Save the pattern.
Important: This method generates the same full-mesh pattern as the default pattern. However, a side-by-side
comparison of the two exports will not necessarily look identical. Because a single test pair represents both
directions, one export might show test pair A-to-B while the other export might show test pair B-to-A. Once the
enterprise test pattern is built on a spreadsheet, continue to add to or subtract from that spreadsheet, because
the next default-pattern or all-subnet-combinations export may not look exactly the same.
© 2014 Avaya Inc. All rights reserved.
49
Why Not to Use the Full-Mesh Pattern
Again, the ultimate objective
is to create a logical topology
within SLA Mon that matches
the physical network
topology. A full-mesh pattern
would create test pairs
between Toronto and Boston,
and between all the remote
offices. But there is no WAN
link between these offices; all
WAN links go to Santa Clara.
A reported network
disturbance between Toronto
and Boston could not be
isolated to a specific link – is
the disturbance on the
Toronto to Santa Clara link or
on the Santa Clara to Boston
link? For this reason the tests
must be logically built like the
network is physically built.
Important: For best network performance monitoring there must
be a dedicated pair of agents for each monitored network link. In
this case Santa Clara must have at least four agents to pair with
the agents at the four remote offices. If one agent at Santa Clara
pairs with all four remote offices, the network performance tests
will not be as frequent for each network link and therefore not
provide the same monitoring coverage.
© 2014 Avaya Inc. All rights reserved.
50
Test Pattern Best Practices
 As stated previously, build the test pattern to match the network topology. Do
not use the full-mesh pattern unless the network is built as a full-mesh.
 For a hub-and-spoke topology, the following methods can be used to build the
test pattern.
– Many-to-many: Multiple subnets at the hub paired with the various remote subnets.
This is the preferred method if possible.
–
–
–
–
hub_subnet_1  remote_subnet_A
hub_subnet_2  remote_subnet_B
hub_subnet_3  remote_subnet_C
Each subnet – hub and remote – has at least one agent (preferably more).
– One-to-many: A single subnet at the hub paired with all the remote subnets.
–
–
–
–
–
–
hub_subnet_1  remote_subnet_A
hub_subnet_1  remote_subnet_B
hub_subnet_1  remote_subnet_C
hub_subnet_1 has at least as many agents as there are remote subnets.
Each remote subnet has at least one agent.
SLA Mon automatically selects a different agent at the hub subnet to pair with each remote
agent.
– A combination of the two:
– hub_subnet_1  remote_subnet_A, B, C, D
– hub_subnet_2  remote_subnet_E, F, G, H
– hub_subnet_3  remote_subnet_J, K, L, M
© 2014 Avaya Inc. All rights reserved.
51
Test Pattern Max Capacity
 A maximum of 250 network links (500 agents forming 250 agent
pairs) is supported.
 The recommended processor (quad-core) and RAM (8GB)
requirements are given to support 250 network links.
 The minimum processor (dual-core) and RAM (4GB) requirements
will not support 250 network links.
 The recommended (180GB) and minimum (40GB) disk storage
requirements are estimates for larger and smaller enterprises
respectively, based on lab testing.
–
–
–
–
It is not feasible to be precise in the storage requirements.
Each implementation will vary in server performance.
Each network will vary due to the uniqueness of each network.
The disk capacity may need to be increased to get the full 60 days’
worth of network performance history for all monitored links.
 There is no limitation in the SLA Mon code preventing more than
250 network links from being monitored. However, 250 is the
maximum that Avaya supports.
© 2014 Avaya Inc. All rights reserved.
52
Execute Test Pattern
Stop the current test pattern,
select a new pattern, and start.
© 2014 Avaya Inc. All rights reserved.
View test pairs for selected
test pattern.
“Failed” in this context means the SLA Mon server attempted to
initiate a set of tests from one agent to another, and that set of tests
failed to execute. This could be caused by:
• Agent malfunction / agent down / no agent available.
• Agent overloaded – not enough agents in a subnet.
• Communication path disrupted between SLA Mon server and
agents (same as no agent available).
In all cases the SLA Mon server attempts to find another agent on the
subnet to execute the tests.
53
SLA Mon™ Usage
© 2013 Avaya Inc. All rights reserved.
54
SLA Mon™ Usage
Network Performance Monitoring
© 2013 Avaya Inc. All rights reserved.
55
Summary Matrix for Multiple Test Pairs
Rows and columns are numbered, but only the
rows are labeled with the subnet or zone.
Select traffic type and
measured traffic parameter.
Color Code:
Prune the matrix by
selecting locations/zones
to view.
Click on a cell to see the
details of that test pair.
© 2014 Avaya Inc. All rights reserved.
• Green: all tests in past hour
were below threshold.
• Amber: at least one test in
past hour exceeded threshold,
but not the latest test
executed.
• Red: latest test executed
exceeded threshold.
• Grey: no test administered.
• Black: unable to execute
administered test; agent or
network down, or agent in
distress.
• Blue: zone, click to see intrazone test results.
• White: location to same
location test not applicable.
56
Detailed Matrix for a Specific Test Pair
For the past hour, all of the traffic type and traffic parameter
combinations from the summary matrix are shown here for this
specific test pair. Color codes are the same as the summary matrix.
© 2014 Avaya Inc. All rights reserved.
57
Detailed Graphs
Select time period to view, up to 5 days
and down to 10 mins (default last hour).
both directions graphed
Select traffic parameter and
traffic type.
administered
thresholds
To zoom in on a specific time window within the graph, use a
mouse click-drag-release motion. Double-click to return to full
graph view for the selected date/time period.
Mouse over a spot on the graph (cross hairs will
appear) to see specific data on that point.
network performance plot
© 2014 Avaya Inc. All rights reserved.
58
Hop-by-Hop QoS Monitoring
Audio traffic left marked as DSCP 46.
Changed to 0 by first hop. No more QoS
treatment from that point on.
Temporarily changed to match the
service provider’s class of service
markings while in the MPLS cloud.
This is a common practice.
At egress, MPLS network puts
DSCP back to what it was at
ingress.
both directions charted
© 2014 Avaya Inc. All rights reserved.
Traceroute is the underlying utility
used to monitor hop-by-hop QoS,
and it is possible for the router or
destination endpoint to not
respond to the traceroute.
59
SLA Mon™ Usage
IP Phone Remote Control
© 2013 Avaya Inc. All rights reserved.
60
Control IP Phone via GUI
Search and select agents,
up to 6 at once.
Manipulate the phone using the
phone’s physical buttons
represented on these rows.
Scrolling list of phone events,
including user button presses,
shows what is happening on the
phone.
LED status indicators show which
LEDs are on (green) and which
ones are off (red).
For touch screen phones, manipulate the phone
also by clicking on the GUI screen, which
equates to touching the actual screen.
© 2014 Avaya Inc. All rights reserved.
61
Instructions
 “How to Remotely Control a Phone Using the Avaya Diagnostic Server”
– http://www.youtube.com/watch?v=44Iqwpsdw4A
– 4:17
 See “Administering Avaya Diagnostic Server 2.0 with SLA Mon.”
 Test call use case:
– No need to have someone on site to make a test call.
– Execute the test call remotely.
 Support use case – comparable to remote desktop support, but for IP phones:
– Remote support technician can control the phone to assist the user with phone settings
and usage.
– Remote support technician can view what’s happening on the phone and what the user
is doing on the phone to assist with error conditions.
– Much more effective than simply having the user explain what he/she is doing and how
the phone is responding.
© 2014 Avaya Inc. All rights reserved.
62
SLA Mon™ Usage
IP Phone Bulk Call Generation
© 2013 Avaya Inc. All rights reserved.
63
Instructions
 “How to Complete a Bulk Call on the Avaya Diagnostic Server”
– http://www.youtube.com/watch?v=o9HaCTA6WYQ
– 5:44
 See “Administering Avaya Diagnostic Server 2.0 with SLA Mon.”
– A bulk call is administered and executed via the CLI only.
– Maximum 50 simultaneous calls.
 Provisioning use case – just turned up a branch office with 50 IP phones:
– Have all 50 IP phones call another 50 IP phones at another location – HQ or another
branch office.
– As long as all 100 IP phones have the SLA Mon agent and are controlled by the same
SLA Mon server, all 50 calls are sent and answered automatically.
– Call destinations not controlled by the SLA Mon server follow the normal call path.
– While the 50 calls are up, the Network Monitoring feature of SLA Mon can be used to
measure network performance between the branch office and the destination, to
confirm that the network is properly handling the calls.
© 2014 Avaya Inc. All rights reserved.
64
SLA Mon™ Usage
IP Phone Packet Capture
© 2013 Avaya Inc. All rights reserved.
65
Capture Packets on Phone’s Ethernet Interface
1. Search for agents to
add to the working set.
3. Select capture file and download
to your machine. View with
Wireshark or other analyzer.
2. Select up to 5
phones and start
capture.
Capture files are stored for 90 days (15 days
on SVM), up to 5 files per phone.
The packet capture feature is meant to diagnose discrete, repeatable events, such as an IP phone not able to register, not able
to send an outgoing call, or not able to receive an incoming call. A capture can be started on the phone, and the event
executed to see if the proper messages are being exchanged across the network. This feature is not meant to diagnose
intermittent audio quality issues or other intermittent and obscure issues. Capture stops automatically after 60secs.
© 2014 Avaya Inc. All rights reserved.
66
Instructions
 See “Administering Avaya Diagnostic Server 2.0 with SLA Mon.”
 Diagnostic use case – discrete, repeatable error events:
– Capture all traffic to/from phone, including ARPs.
– Troubleshoot why call setup is not occurring.
– Troubleshoot why a phone cannot register.
 Limitations:
– The phone does not have the flash space and capability to store the capture
file.
– Packets entering and exiting the phone’s Ethernet interface are duplicated
and transferred to the SLA Mon server and stored as a file.
– The capture stops automatically after 60secs.
© 2014 Avaya Inc. All rights reserved.
67
SLA Mon™ Alarms
© 2013 Avaya Inc. All rights reserved.
68
Overview
 SLA Mon can send SNMP alarms to the enterprise network
management station (NMS).
 The key questions are:
– What does the enterprise view as significant events that need to
be logged in the SLA Mon server?
– What does the enterprise view as significant events that need to
be proactively alerted to the NMS?
 The key configuration steps are:
– Set the network thresholds and conditions that should trigger a
log entry or alarm to the NMS.
– Configure the NMS parameters.
– From a menu of possible events, select the ones that should
trigger a log entry or alarm to the NMS.
 Watch video: Configuring SLA Mon SNMP Trap Details for
Avaya Diagnostic Server 2.0
© 2014 Avaya Inc. All rights reserved.
69
Set Alarm Thresholds
180ms is the commonly accepted value for one-way delay.
These are commonly accepted
values for jitter and loss, though
perhaps a bit low in practicality.
Set based on the enterprise’s
tolerance levels.
An alarm is triggered if the
threshold is breached this
many times in an hour span.
4.0 - 4.5 is considered PSTN toll quality.
Down to 3.6 is considered business quality.
e-MOS is estimated mean opinion
score, calculated using the ITU-T
G.107 recommendation.
© 2014 Avaya Inc. All rights reserved.
70
Add a New NMS
Specify the IP address of the NMS,
and click “Add New.”
© 2014 Avaya Inc. All rights reserved.
71
Configure SNMP Parameters for the NMS
Ranging from warning and above to critical, specify which
severity level(s) should be proactively alarmed to the NMS.
As dictated by the NMS.
A Trap does not require an acknowledgment from the NMS
(suited for TCP). An Inform requires an acknowledgment
from the NMS (suited for UDP).
162 unless configured otherwise in the NMS.
As dictated by the NMS.
© 2014 Avaya Inc. All rights reserved.
72
Select Events and Severity Levels
1. Select the events that the enterprise wants
logged in the SLA Mon server. These events are
explained in the next slide.
2. Assign the severity level of each event – what severity
does the enterprise consider this event to be?
An alarm is sent (or not sent) to the NMS using this criterion.
3. Save changes.
© 2014 Avaya Inc. All rights reserved.
73
Events Explained
 License Alarms
– avSLAMonLicenseTrap (.1.3.6.1.4.1.6889.2.62.1.2.0.4.0.15)
– triggered once a day when there is no valid license file
– avSLAMonLicenseServerNotReachableTrap (.1.3.6.1.4.1.6889.2.62.1.2.0.4.0.16)
– triggered once a day when the WebLM server is not reachable
 QoS Alarms – triggered according to the administered thresholds and strike
rates
–
–
–
–
avSLAMonTrapQoSJitter (.1.3.6.1.4.1.6889.2.62.1.2.0.2.0.7)
avSLAMonTrapQoSDelay (.1.3.6.1.4.1.6889.2.62.1.2.0.2.0.8)
avSLAMonTrapQoSPacketLoss (.1.3.6.1.4.1.6889.2.62.1.2.0.2.0.9)
avSLAMonTrapQoSEMOS (.1.3.6.1.4.1.6889.2.62.1.2.0.2.0.10)
 Start or Stop Alarms
– avSLAMonServiceColdStart (.1.3.6.1.4.1.6889.2.62.1.2.0.1.0.2)
– triggered when the slamon service is started on Linux
– avSLAMonServiceStopped (.1.3.6.1.4.1.6889.2.62.1.2.0.1.0.3)
– triggered when the slamon service is stopped on Linux
 DSCP Change Alarms
– avSLAMonTrapDSCPChange (.1.3.6.1.4.1.6889.2.62.1.2.0.2.0.11)
– triggered when DSCP start and end values do not match; repeated once an hour as long as
the condition exists
© 2014 Avaya Inc. All rights reserved.
74
Events Explained (cont.)
 Test Failure Alarms
– avSLAMonTrapTestFailure (.1.3.6.1.4.1.6889.2.62.1.2.0.2.0.12)
– triggered per IP subnet when there is greater than a 10% failure rate in an hour for SLA Mon
agent tests
 Agent Registration Alarms
– avSLAMonTrapAgentRegistrantion (.1.3.6.1.4.1.6889.2.62.1.2.0.3.0.13)
– triggered when an SLA Mon agent successfully registers
 Config Change Alarms
– avSLAMonTrapConfigChange (.1.3.6.1.4.1.6889.2.62.1.2.0.1.0.5)
– triggered when there is a configuration change on the Alarm Thresholds page on the SLA Mon
server
 Agent Discovery Alarms
– avSLAMonTrapAgentDiscovery (.1.3.6.1.4.1.6889.2.62.1.2.0.3.0.14)
– deprecated; do not select this event box
 Selecting the event causes it to be logged in the SLA Mon server.
 Assigning a severity level to the event determines whether or not a trap is sent
to the NMS.
© 2014 Avaya Inc. All rights reserved.
75
Appendix: ERS Commands
© 2013 Avaya Inc. All rights reserved.
76
Configuring switch-based SLA Mon™ agent via
ACLI
 Note- commands are common across ERS3500, 4000,
5000 families.
© 2014 Avaya Inc. All rights reserved.
77
Configuring SLA Mon via ACLI cont.
© 2014 Avaya Inc. All rights reserved.
78
Configuring SLA Mon via ACLI cont.
© 2014 Avaya Inc. All rights reserved.
79
Configuring SLA Mon via ACLI cont.
© 2014 Avaya Inc. All rights reserved.
80
Configuring SLA Mon via ACLI cont.
Note- Bypass mode is used to run tests
between two switches without an SLA Mon
Server. This operation is not covered in the
ADS R2 KTK. Refer to ERS3500 5.1.1 or
ERS5600 6.6 Troubleshooting Technical
Transfer for guidance to running Bypass
mode
© 2014 Avaya Inc. All rights reserved.
81
Configuring SLA Mon via ACLI cont.
© 2014 Avaya Inc. All rights reserved.
82
Configuring SLA Mon via ACLI cont.
© 2014 Avaya Inc. All rights reserved.
83
Summary of SLA Mon Agent commands via CLI
© 2014 Avaya Inc. All rights reserved.
84