Skip to content

Basic Planning Guide

This page details some of the best practices to get started with Assure1’s infrastructure management.

Business Requirements

Define Business Goals

To ensure Assure1 provides the value for which it has been purchased it is extremely important to define the business goals extensively and communicate/measure against them throughout the duration of the implementation. Examples of business goals are defined below:

  • Automation for Operations

  • Automation for Administration

  • Increased Visibility via Dashboards and Diagrams

  • Replacement of previous tool sets

  • Cost Reduction/Avoidance/ROI

Operations

Operations, in the context of Assure1, are the usage or interaction of the various user communities with the Assure1 Software Solution. This may include executives, engineers, end-users, and NOC operators.

User Authentication

Assure1 supports both internal and external authentication mapped one-to-one to the user defined, but no fail-over capability between the types. Below are the three types of external authentication, make sure you determine these configurations prior to implementation:

  • Active Directory - primary/secondary hosts and domain suffix as well as secure connection.

  • LDAP - primary/secondary hosts and distinguished name as well as secure connection.

  • RADIUS - primary/secondary hosts as well as RADIUS port/secret.

Multi-tenancy

Assure1 supports the capability to provide multiple securely segmented read-only access groups used for multi-tenancy. This is usually for client-side portaling or segmented departments within a single organization. All these configurations are defined within the User Groups, Device Groups, Dashboard Groups, Diagram Groups, and Event Filter Groups all need to be defined prior to its creation. Any multi-tenancy configuration needs to be designed prior to implementation to prevent rework.

Defined Roles

To leverage any secure application, certain roles need to be defined and each role needs to be assigned privileges. By default, five roles come pre-defined by Assure1: Administrator, Anonymous, API, Operator, and Publisher. Additional roles may be required within your environment, so this needs to be determined at the earliest stage of implementation.

Users Group Creation

User groups, like roles, need to be determined prior to implementation. User Groups use roles to control access into Assure1 and have a group of defined user names associated to the group.

Process Management

Federos recommends that all major processes (defined or yet undefined) be listed and use cased if interaction with the Assure1 software solution is required or wanted. This ensures that any process interaction will be successful and accomplished with ease.

Assure1 Architecture

Assure1’s architecture consists of a typical 3-tier implementation, where the presentation layer leverages an Apache web server, the data layer consists of MariaDB, Elastic, Influx and Orient database instances, and the application layer runs Assure1 compiled binaries.

Components Required

Before determining your architecture, you must first determine all the Assure1 components you will need to achieve the features/functionality you require. This list is vital in the planning and design phases and any architecture created without this component list completely identified may run into scaling issues.

System Requirements

Federos recommends the following:

  • Dedicated partition for Assure1 installation. (By default, this is the /opt partition)

  • RAID 10 for any database or bulk loading uses.

  • NTP configured and synchronized across all servers.

  • All Assure1 servers monitored for CPU, Disk, Memory, and IO at least every 5 minutes.

Hardware Requirements

Estimates are broken out into four categories and are baseline hardware recommendation for Assure1.

  • Minimum

  • Medium

  • Large

All Historical Storage estimates given are based on default configuration and retention policies. Storage requirements depend on data retention policies, number of raw events received, and number of metrics collected. Contact your Sales Representative for a personalized estimate.

Minimum

Minimum installs are less than 1000 devices.

Supported implementations:

  • 1 Server: All-in-One Install

  • 2 Servers: Presentation and Database Server with separate Collection Server

  • 4+ Servers: Separate Presentation, Database, Elasticsearch Database and Collection Servers

Requires:

  • Linux Server Support

  • Intel/AMD x86_64

  • RHEL/CentOS 7.X (64-bit x86) ("Base" OS Install)

  • 4 Core Xeon E5 2GHz or better Processors (4 Cores)

  • 16GB RAM

  • 60GB Drive Space for application and logs

  • 100GB Historical Storage (Database Server Only)

Medium

Medium installs are between 1,000-10,000 devices.

Supported implementations:

  • 4+ Servers: Separate Presentation, Database, Elasticsearch Database and Collection Servers

Requires:

  • Linux Presentation/Collection Server Support

  • Intel/AMD x86_64

  • RHEL/CentOS 7.X (64-bit x86) ("Base" OS Install)

  • 2 * 4 Core Xeon E5 2GHz or better Processors (8 Cores)

  • 16GB RAM per server

    Note

    As applications are split amongst the different servers, especially the databases, the per server requirements may be reduced to 8GB.

  • 80GB Drive Space for application and logs

  • 500GB Historical Storage (Database Server Only)

Large

Large installs are typically between 10,000-50,000 devices.

Supported implementations:

  • 4+ Servers: Separate Presentation, Database, Elasticsearch Database and Collection Servers

Requires:

  • Linux Presentation/Collection Server Support

  • Intel/AMD x86_64

  • RHEL/CentOS 7.X (64-bit x86) ("Base" OS Install)

  • 2 * 8 Core Xeon E5 2GHz or better Processors (16 Cores)

  • 32GB RAM per server

    Note

    As applications are split amongst the different servers, especially the databases, the per server requirements may be reduced to 16GB.

  • 100GB Drive Space for application and logs

  • 1TB Historical Storage (Database Server Only)

...and Beyond

For larger installations or more specific requirements, please contact your Sales Representative.

Software Map

Determining the software map is a matter of applying the components list to the hardware list. Components can be installed on any server, but there are some best practices rules detailed below:

  • Pollers of any type should not be on the same server where the web server resides - this may cause user interface interference.

  • Components that poll an internal historical storage database (threshold engine, historical event rotation, etc), should reside on the same server as the historical storage database runs on.

  • Metric Pollers and Threshold Engines are highly memory dependent.

  • Metric Pollers are scaled by average response time to device polled, % of devices down, timeout settings, threads defined, historical database insert speed, CPU speed/availability, and memory availability.

  • Database instances (Metrics, Real-Time Events, Elasticsearch and Graph) can be put on a separate servers due to high disk requirements.

  • Metric Pollers and Discovery agents to be used are installed on the same server. This prevents discovery/polling mismatch failures.

Redundancy/Fail-over & Fail-back

Assure1 supports fully globalized fail-over and fail-back capabilities. We recommend you read the redundancy brief provided by Federos and document your fail-over requirements for production implementation prior to start of implementation.

Backup/Restore Strategy

As with all software, standard backup/restore requirements should apply. By default, the Assure1 configuration database is backed up every Saturday at 1 AM. The other databases need to be included into a backup plan. All backup requirements need to be defined prior to implementation.

Assure1 Component Network Requirements

Assure1 uses few network ports for inter-component communications. These need to be opened bi-bidirectionally via the local operating system firewall and/or network ACLs or firewalls. We recommend that this is done prior to installation.

  • Assure1 Message Bus TCP/5671 (Presentation)

  • Assure1 MariaDB Database TCP/3306 (Presentation/Events Database)

  • Assure1 Web Server TCP/80,443 (Presentation)

  • Assure1 File Synchronization TCP/8873 (Presentation)

  • Assure1 Redundancy Wizard TCP/8055,8056 (Database)

  • See the Prerequisites for CentOS7 or RHEL7 documentation for a detailed list of ports that are used.

Assure1 Typical Collection Network Requirements

As Assure1 is typically used for polling devices across the network, the following ports need to be opened from at least the collection servers to the remote network devices (Federos recommends a management subnet be created to make maintenance of this easier).

  • ICMP Ping or Generic Up/Down Polling requires ICMP connectivity from Server to Devices

  • SNMP Polling requires network connectivity (UDP/161) from Server to Devices

  • WMI/NT Event log Polling requires network connectivity (TCP/135) from Server to Devices

  • Management Servers and monitored devices need to contact the NTP server (UDP/123)

  • Syslog collection requires network connectivity (UDP/514) from Devices to Server

  • SNMP Trap requires network connectivity (UDP/162) from Devices to Server

  • MTU Packet Size should allow for 1475 or higher

Scale & Capacity Planning

Assure1 scales based upon two major areas: database inserts/second and database retention requirements. These can be calculated using the Assure1 scalability brief and storage calculation spreadsheet. A detailed discovery & planning session is required to determine your polling requirements and storage retention levels for the initial implementation as well as considering future capacity required or expected.

DNS Caching

DNS caching on Linux is disabled by default, which can cause performance issues (increased load on DNS servers, increased response latency, etc) in large scale implementations. For optimal performance, it is recommended that a DNS caching agent be configured on all Assure1 servers.

Recommended DNS Caching agents:

Device Management Process

The device management process is one of the most common key administration processes that will need to be defined. This process includes what needs to be done in Assure1 to facilitate adding new devices to be monitored as well as how devices are decommissioned and handling the various changes a device may experience. Below is a basic list of areas that need to be addressed by the process:

  • Auto Discovery - Devices being entered into Assure1’s Core Device Catalog

    • Auto discovery Scheduled Job (Ping Scans, Seed Lists, CDP, LDAP)

    • Collection Discovery via collector rules

    • Manual Entry via Web UI

  • Device Typing - Setup of Device communication and device type/category (SNMP or WMI)

    • SNMP Discovery agent - v1, v2, v3 community strings (v1 polling not generally recommended)

    • WMI Discovery agent - Windows only

  • Instance Discovery - Discovery of sub-devices (Interfaces, IPSLA probe tags, Disk Partitions)

    • Automated via Metric Manager Discovery agents

    • Manually via Web UI

  • Metric Discovery - Setup of polling metric instances

    • Automated via Polling Policy Discovery agent

    • Manually via Web UI

  • Network Inventory Collection - Interface, ARP, IPRoutes, CDP, etc

  • Topology Stitching - Standard Agents for IPRoutes, ARP, and CDP, otherwise customization is needed

As part of this process there may be additional enrichment or security required rules that may need to be written. The following are commonly required:

  • Device Group placements (auto.rules, snmp.rules)

  • MetaTags created (auto.rules, snmp.rules)

Most of the discovery engines are designed for discovery of new devices. The following device changes may need to be handled in some way by this process:

  • Device DNS Name changes (Auto discovery agent automatically updates)

  • Device IP Address changes (Manual or customization)

  • Device Security changes (Community Strings) - SNMPDiscovery or manual

  • Device Type/Category changes - Manual or customization

  • Device Group changes - customization

  • Device Polling requirements - Automated with pollers, customization for collectors

  • Sub-device changes (New, changes, decommissions, etc)

    • IP SLA Probe Tags - Manual or customization

    • Interfaces - Manual or customization

    • Partitions - Manual or customization

    • Topology - Manual or customization

    • Inventory - Automated with -Flush option

When devices are decommissioned the following areas will need to be addressed:

  • Device Catalog Deletion - Bulk Load or via SQL

  • Retention of Metric Data - Static Devices

  • Retention of Topology

It is also important to understand how discovery and/or re-discovery processes will be initiated. Typically, most customers run discovery on-demand, but you may wish it to be fully automated and scheduled jobs can be enabled to run at set time of day, week, and month.

Dashboards

Custom Dashboards

  • List of Dashboards that need to be created with the following information

    • Audience (who is it designed for)

      • Customers, Executives, NOC Operators

    • Security restriction (who can access it, etc)

      • Customers, Executives, NOC Operators

    • Contents

      • Background, Metrics, Filters, Images, etc

    • Layout requirements (where does what go?)

    • Maintenance requirements (who is going to keep it up to date)

      • Admin, NOC Operators

Plug-ins

  • Who should have access to the Topology/SLM Plug ins?

Metrics (Polling, Collection, Display)

Metric Manager is used for collection, processing, reporting, and displaying of availability, performance, or capacity-based data. The individual component types need to be properly scoped so that the correct configuration can be deployed. Below are commonly discussed requirements that need to be discussed/determined before moving into implementation.

Base Configuration

  • TopN Overviews - Type/Scope/Direction

  • Custom Collection Definitions (Name, How, Maximums, Factor, Scales/Abbr)

  • Retention (Raw, Hourly, Daily) - reference scale brief/calculator

    • Raw - default 14 days

    • Hourly (1hr consolidation) - default 3 months

    • Daily (24hr consolidation) - default 2 years

Pollers

  • What polling intervals are required?

    • Every minute?

    • Every 5 minutes?

  • Clustering/Location

    • How many devices need to be polled?

    • What is the average latency/packet loss for the devices to be polled by location?

    • Is load balancing required? How many poller instances are required?

  • Database Scalability

    • What are the expected inserts/sec for each poller and each database instance?

    • What polling delay is expected/required?

    • Which storage engines will be used by pollers? Direct or Bulk Insert?

  • Custom SNMP Polling

    • What MIBs and Objects are required for polling (Gauges, Indexed tables, and Counter)?

Collectors

  • What custom collection feeds are required?

    • Format for rules parsing (Are formulas required?)

    • Feed Type/Protocol

  • How many interfaces, of what capacity, need to be collection targets?

Synthetic Transactions

  • How many types of transactions need to be run? How many concurrently? How many POVs?

  • Are the transactions run via command-line or WinTask policy?

  • How many instances of the same transaction type need to be run?

  • Do the transactions need to be setup to run automatically?

  • Do you have code examples and test-beds available and documented?

Thresholding

  • Do you need threshold notifications or just event integration?

  • Approximately how many thresholds will need to be defined?

  • Do you have defined service levels that threshold differently?

  • Do you need to threshold metric trends across daily, weekly, monthly, or yearly change?

  • Do you need dynamic thresholding for metrics via cyclical deviation?

  • What are your static threshold levels that need to be defined, i.e.

    • CPU - > 75% Warning, > 90% Critical

    • Bandwidth - > 75% Warning, > 90% Critical

Dynamic Device Overviews

Besides the following, are there any custom metric overviews required?

  • Device Health (Ping Availability, CPU, Disk, Memory)

  • Network Traffic (Latency, Packet Loss, Interface Stats)

  • IPSLA by Probe Tag/Type (Availability, Latency, Jitter, Packet Loss)

  • Response Times (Synthetic Transaction Latency)

Custom Reporting

  • What scheduled static reporting templates are required?

  • Are they Graphical Reports?

    • Trend Report

    • Time-Series

  • Are they List Reports?

  • What schedules or distribution lists are assigned to each graph template?

Service Level Management

  • What services need to be monitored? Quantity?

    • VOIP

    • DNS

    • WEB

  • Are they documented?

  • Who will have access to the SLM data?

  • How often are they changed?

  • Is automated creation/maintenance required?

Events

Event Collection

  • What are the event feeds that need to be collected?

    • Format

    • Feed/Protocol/Method

  • Which aggregators will be needed?

    • Standard Trap/Syslog (forwarding?)

    • API-based - NNM, etc

    • TL1 - Gateway/NE list - Chat In/Out Login, Poll, Logout scripts

    • Generic (Database, Socket, Flat File, Command, Email, etc)

  • What are the different collection locations and how are they split up?

Scalability

  • What is the estimated events/sec per aggregator?

  • How many total events/sec are required for the historical event repository?

  • How many days of historical event data do you want to keep?

Escalation/Notification

  • What simple notification profiles are required? (Uni-directional without time delay)

  • Do you have operational performance monitoring requirements that you want to use iE&N (Intelligent Escalation and Notification Engine) for? (one-to-one mapping of event to responsible group)

    • What are your escalation tree requirements by type?

    • Do you want to use the rotating on-call engine?

      • Who is going to maintain the on-call list?

      • What are the Users/Groups/Shifts/Schedules?

  • What custom notification requirements are needed? (SMS, Voice, IM, other, etc)

  • What text email formats is required?

  • What SMTP servers do you intend to use?

  • Do you intend to use the email acknowledgment engine? What POP3 server, port, user, password?

Event Display

  • What default Filters are required?

    • Device filter

    • Specific Alarm Types

    • Time frames

    • Public/Private to Groups?

  • What Filter Group configurations need to be created?

    • Which Filters belong in which groups?

    • Which Filters can specific groups use?

  • What default Displays need to be required?

    • Public/Private to Groups?

    • What Fields, Names, and Order

  • What custom right-click tools need to be created? Who uses them?

    • SQL queries

    • CGI scripts

  • Each non-read-only user group uses its own menu defined. Are there additional menus you want created? List them out fully.

Enrichment

  • What Internal Event Enrichment is required?

    • Device Catalog (Priority, Meta Tags, etc)

    • Topology (Next Hop, etc)

    • Inventory (Interface Name, etc)

  • What External Event Enrichment is required?

    • Format/Mappings

    • Feed/Method (Flat File, Database, Socket, Command-line)

  • What Method for each enrichment policy makes the most sense?

    • Rules-based (quick/easy/real-time but keeping up to date may be a problem)

    • Agent/Connector (not real-time, but fewer look ups, less maintenance required)

Correlation

  • What correlation requirements beyond the basic generic Clear and Expire do you require?

    • Heart beating

    • Stacking or Disparate Events - This + This = That (Same Source/Different Source)

    • XinY - Event Thresholding to new summation event?

    • Parent/Child or RCA - Topology-based? Data Source?

    • Downstream Suppression - If this is downstream from that, and that is in alarm, suppress this (What is suppressed?)

    • Custom Policy/Automatic Remediation?

    • Service Impact Analysis

  • Correlation Methods

    • Rules (Correlation by De-duplication, Direct Query, etc)

    • Mechanizations (Database Stored Procedures)

    • Connector/Agents (Custom Single Policy, Time-of-Day Correlations)

    • CAPE (Multiple Policy Engine, Auto-Remediation)

    • PRCA Connector (Network-based Topology Correlation, Down-stream Suppression)

    • SLM Connector (Real-time Service Impact Analysis)

Northbound Integrations

(Custom, Ticketing, Historical)

  • What Ticketing Integration is required?

    • When/How do you want to ticket? (Methods)

    • How to integrate with the ticketing system? (API, Socket, Database, Flat File, Command-line, SOAP, etc)

    • What scheduled synchronization requirements do you have?

      • Work Log + Alarm Journal

      • Ticket Status + Event Severity/Acknowledgement

      • Other?

  • What other northbound integrations are required? (Historical/Other)

Historical Reporting

  • What table-based historical event reports are required?

    • Query (Where Clause)

    • Format (Columns)

    • Schedule to run?

  • What other custom reporting is required?

Topology

Network Inventory Collection

  • Do you want to use CDP-based data? Is it enabled on all routers/switches/servers?

  • How often do you want to collect inventory (Discovery vs. Re-Discovery)?

  • Do you need to split up your inventory collection to collect from a certain location, time of day, etc? Do you want to limit the collection and exclude certain data?

Topology Stitching

(ARP, CDP, IPRoutes, Config Agent, Custom CRM/Provisioning, Billing)

  • Do you wish to still keep the following default inventory data?

    • ARP

    • CDP

    • IPRoutes

  • What custom Config Agent stitching do you need to collect?

  • What custom 3rd party stitching data do you need to collect?

    • Format/Mapping

    • Feed/Method (Database, Flat File, Socket, Subversion, SOAP)

Configuration Agent

  • What Devices are targets? How are they grouped?

  • How often do you want them to be collected?

  • What differential notifications do you want? Where do you want the notifications sent?

  • What Chat In/Chat Out scripts need to be developed and tested?

    • Commands/Responses

    • User/Passwords

Appendix A - DNS/IPSLA Naming Standards Guide/Examples

A standard IP addressing scheme for distributing IP networks between access, distribution, core, WAN networks, and data centers should be devised. Networks should be allocated in CIDR blocks to help routing protocols summarize the networks as well as provide ease of identification.

All host and network devices should be configured to use Domain Name Service (DNS) servers for name resolution. For Assure1 components, configuring both forward and reverse resolution is recommended.

At least 2 DNS servers should be setup to provide authoritative DNS lookups to devices and hosts. Zones should be setup to provide forward lookups for all domains and sub-domains (example.com), as well as provide reverse lookups for all IP networks (X.X.X.in-addr.arpa). If one device is accessible from multiple interfaces/IP addresses (from an ICMP and/or SNMP perspective), you should add reverse DNS to the management addressed host name.

A standard naming scheme should be used to provide consistency. The standard can include description by location, device type, purpose, etc. Names cannot include spaces, nor should they contain underscores (_) due to standards-based DNS restrictions.

Example 1

(Device Use)(Device Type)(Floor)(Device Number)(BuildingName)(Riser)
ASW-1-2-RDP-A1 = Access Switch 1st Floor Device Number 2 Galter Riser A1
DSW-1-2-RDP-PACS = Distribution Switch 1st Floor Device Number 2 Feinberg Building Riser PACS
CSW-5-1-259 = Core Switch 5th Floor Device Number 1 259 Building Riser N/A

Example 2

(Building)(Floor/Closet)(Device Type)(Device Number)
1st 3 characters designate building
4th thru the 7th characters designate the area, floor and closet
8th thru the 10th characters designate the device use & function
11th and 12th characters designate the device number

The above example would result in a device name like "str-x201-wap-01", and could translate to meaning "the 1st wireless access point at stratford, area x, 2nd floor, 1st closet".

Cisco

Example IOS Configuration

ip domain-name <DNSDomain>
ip name-server <DNSSrv1>
ip name-server <DNSSrv2>

Example CatOS Configuration

set ip dns domain <DNSDomain>
set ip dns server <DNSSrv1> primary
set ip dns server <DNSSrv2>
set ip dns enable

Appendix B - Basic Device Configuration Guides

Common Server Configurations

SNMP Polling Options

Federos recommends leveraging the Net-SNMP (http://www.net-snmp.org/) agent for Unix, Linux, and windows-based platforms. If you wish to use Windows SNMP Agent, we highly recommend downloading SNMP Informant Patch for Windows. The stability, popularity, conformity of the agent, various platforms supported, and large default MIB support are the reasons for this recommendation. Federos provides a net-snmp SNMP rules file that provides many of the common metric data requirements customers are seeking. For all other agents, custom SNMP rules may need to be created so you may want to consult with your Federos sales representative before implementation. Be aware that only SNMP v2 and v3 are supported by default by the pollers.

Unix/Linux Syslog Forwarding

Syslog forwarding is documented by the syslog daemon being used on your server. Below is a list of documentation URLs we found that may help you set this up within your environment. You should also be able to do "man syslogd.conf"

NTP

Federos recommends all devices being monitored are synchronized to a single common clock source. Consult with your operating system documentation to determine the best NTP strategy for your organization.

Common Network Device Configurations

SNMP Polling Setup

Most network devices monitored by Assure1 leverage SNMP for communication. Consult your vendor documentation on how to setup SNMP connectivity and test the process before implementation. Below is a running list of different vendors and the recommended configuration required:

Cisco

Example IOS Configuration

no snmp-server community public RO
no snmp-server community private RW
snmp-server community <enter_read_only_password_here> RO
snmp-server community <enter_read_write_password_here> RW

Example CatOS Configuration

set snmp community read-only <enter_read_only_password_here>
set snmp community read-write <enter_read_write_password_here>
set snmp community read-write-all

Cisco devices can provide serial numbers through SNMP, although they are only configured by default on fixed chassis devices. All other modular devices should have the serial number configured manually to provide ease of contract and warranty management.

Example IOS Configuration

snmp-server chassis-id <enter_device_serial_number_here>

Example CatOS Configuration

set logging level snmp 7 default

Interface Descriptions

To assist with troubleshooting issues and to provide additional information to an enterprise management system, all interfaces should have a description defined for them. This description can either be a generic description about the interface type, or can include specific information like customer name, circuit ID, etc.

Example IOS Configuration

interface Serial0/1
 description T1 connection to Internet provider (circuit id: XXXX/0000001)

Example CatOS Configuration

set port name 4/1 Trunk to distribution switch

SNMP Interface Index Renumbering

One of the big challenges associated with many SNMP performance management tools is the tool's ability to handle interface index re-numbering. It is true that some tools handle this better than others; however, there are steps that your organization can take to minimize the problems you'll likely encounter when this occurs. One of the relatively easy and straight forward approaches to take is to configure all IOS routers with the command 'snmp-server ifindex persist'.

The tools also need to be smart enough to know when ifIndexes change for other devices. Usually vendors say they key off of the ifDescr, but they should allow this to be configurable by device type. For example, ifDescr is always the same on CatOS Ethernet ports, but portName will be unique.

Syslog/Trap Forwarding

Most network devices monitored by Assure1 forward event information either by Syslog or by Trap. Some devices can send equal quality of data in either format, and where this is the case Federos recommends using syslog because it is easier to parse. Consult your vendor documentation on how to setup syslog or trap forwarding and test the process before implementation. Below is a running list of different vendors and the recommended configuration required:

Cisco Syslog

Example IOS Configuration

logging trap notifications
logging source-interface <DevMgmtIntf>
logging <MgmtSrvIPAddr>

Example CatOS Configuration

set logging server severity 5
set logging server enable
set logging server <MgmtSrvIPAddr>
set logging timestamp enable

NTP

Federos recommends all devices on monitoring be synchronized with a single common clock source. Consult with your vendor documentation to determine the best NTP strategy for your organization. Below is a running list of different vendors and the recommended configuration required:

Cisco

Example IOS Configuration

service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
clock timezone CST -6
clock summer-time CDT recurring
ntp authenticate
ntp authentication-key 1 md5 <enter_auth_key_here>
ntp trusted-key 1
ntp source <DevMgmtIntf>
ntp server <NTPSrv1> key 1
ntp server <NTPSrv2> key 1

Example CatOS Configuration

set timezone CST -6
set summertime enable CDT
set summertime recurring
set ntp broadcastclient disable
set ntp client enable
set ntp authentication enable
set ntp key <enter_auth_key_here>
set ntp server <NTPSrv1>
set ntp server <NTPSrv2>

Copyrights and Trademarks

  • MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

  • Apache™ is a trademark of The Apache Software Foundation.

  • Cisco®, and IOS® are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

  • Sun®, and Solaris® are trademarks of Sun Microsystems, Inc. or its subsidiaries in the United States and other countries.

  • IBM®, and AIX® are registered trademarks of the International Business Machines Corporation in the United States, other countries, or both.

  • HP®, and HP-UX® are registered trademarks of the Hewlett-Packard Company.

  • Red Hat® is a registered trademark of Red Hat, Inc. in the United States and other countries.

  • Linux® is a registered trademark of Linus Torvalds.

  • Windows® is a registered trademark of Microsoft Corporation in the United States and other countries.