MDC Sync Setup Instructions

Author: Paddy Murphy

Performance and Configuration syncs need to be set up to populate widgets in EMS-Nova. Instruction below are for a SEO environment where snmp port forwarding is used. You will still need to verify the snmp settings are correct where port forwarding is not used. Syncs are set up at the controller level. Before you start you will need a connection to the rdf database.

RDF database server is defined in ansible env_configuration under [rdf-db] group in the hosts.ini file.

The majority of syncs use snmp, verify you can do a snmp walk before proceeding. See example snmp walk commands for common technologies below. Remove SNMP port if it is not required.

snmpwalk -c public -v1 152.44.175.18:1616 .1.3.6.1.4.1.331

snmpwalk -v1 -c admins 50.229.75.130:1616 .1.3.6.1.4.1.6626.6000

snmpwalk -c public -v1 166.144.210.28:8002 .1.3.6.1.4.1.35043

An entry is required in the discovery_profile table with the correct port number and read/write community for device.

select * from discovery_profile;

This entry needs to be referenced in network_element table. Also verify that the snmp_port value is correct.

select id, name, ip_address , port , technology, discovery_profile_id, snmp_port  from network_element ne where id = <network element id>:

In EMS navigate to the relevant controller and go to System → Edit System → General Information Info to verify that the SNMP Community & SNMP Write Community values are correct for the device. This step is required because these values are hashed in the network_element table.

Check if element has been synced over from network_element table.

select * from orchestrator.element where entry_point_id  = <network element id>;

If element is missing it can be added by making a simple edit to the element in EMS System → Edit System → General Information. Adding a space to the “Additional Info” field will not affect any critical controller information. When the update is saved the element should appear in the orchestrator.element table.

The element ID in orchestrator.element is used to set up the syncs.

Check is any syncs already exist for device.

select * from orchestrator.schedule_config where element_id  = <element ID>;

Find an existing entry to duplicate, you may need to run this on a different environment if there are no entries.

select * from orchestrator.schedule_config where schedule_type  = 'PERFORMANCE' and schedule_id  != 5;

The schedule_config ID does not auto increment. Run the following and increment by one for new entries.

select max(id) from orchestrator.schedule_config;

Ensue that the following values in the new schedule_config are correct:

• schedule_type - PERFORMANCE or CONFIGURATION
• scheduled_by - ORCHESTRATOR
• technology - match value in orchestrator.element
• timeout_seconds – 300
• version_from - match technology_verson of orchestrator.element
• version_to - match technology_verson of orchestrator.element
• agent_id - reference correct agent in orchestrator.agent
• customer_id - reference correct customer in orchestrator.customer
• customer_site_id – reference correct customer site in orchestrator.customer_site
• element_id - reference id of orchestrator.element
• schedule_id – reference id in orchestrator.schedule an hourly schedule would be suitable for Performance or Configuration syncs, the NEVER schedule can be used to stop the schedule,

Once a sync has been enabled you can check the results with the following queries. If everything is set up correctly the sync should appear in the active_task and move to the completed_task. A five minute sync is useful for testing purposes.

failed task

select * from orchestrator.failed_task ft where original_request like '%<entry point id>%';

completed task

select * from orchestrator.completed_task ct where original_request like '%<entry point id>%';

task queue

select * from orchestrator.active_task at2 where original_request like '%<entry point id>%';

Sync has been set up and should have run but there are no entries in the task tables. Supported versions can be checked in the following folder of the relevant branch of rdf_agent

src/main/java/com/errigal/rdf/processing/technology/

This information is usually in the …ParamaterPocessor.java file Check the isCompatible method in this file it may allow a sync to work if software_version contains mdc i.e “1.2mdc”

Sync entries are appearing in the failed_task due to Max tries exceeded… Check the orginal_request JSON data in the orchestrator.failed_task table and verify the values are correct. See example of a successful request below:

{"tags":{"entryPointId":"23755"},"httpCredentials":{"useHttps":false,"internalPort":8000,"externalPort":8000},"snmpCredentials":{"snmpVersion":"2","readCommunity":"public","writeCommunity":"private","internalPort":8001,"externalPort":8001},"sshCredentials":{"internalPort":8000,"externalPort":8000},"host":"166.144.206.175","port":8000,"technology":"ANDREWS_IONE","technologyVersion":"mdc2.8.3.13","requester":"SCO_Customer","requesterSite":"sco_site","discoveryType":"CONFIGURATION","timeout":300000,"payload":[],"priority":5}

Syncs are running but Ping Latency widget is blank.

The network_element.discovered_name of the Controller needs to match the name in widget. In the example above the discovered_name should be “solid_controller”