Discovery Phase ShazzamDescription Shazzam is the first phase of discovery. Shazzam scans ports to determine what protocols are available on a target system. The result from the Shazzam probe determines what classifiers to be triggered. For common issues with the Shazzam discovery phase, see the following kb: Troubleshooting the Shazzam phase in Discovery Shazzam Flow A quick discovery or a scheduled discovery is triggered and StartDiscovery script include calls ShazzamLaunch.launch()ShazzamLaunch.launch() fires the Shazzam probe by creating an ecc_queue output with the necessary parameters, i.e ip range, scanners, etcThe MID Server runs the Shazzam probe by Running the port probes specified in the "port_probe_spec" parameter against each IP set in the "range" probe parameter The Shazzam result is returned to the instance via a ecc_queue input recordThe Shazzam input is processed by discovery_sensor ShazzamClassification probes are triggered as per the order configured in the discovery_port_probe table, and classification_priority field, for the "successful" scanners IP Service, Port Probes, and Scanners The IP Services determine what port and protocol (TCP or UDP) to use IP Services can be seen under "Discovery Definition > IP Services", table cmdb_ip_service The Port Probes set which ip services to scan, what classification to use, the order in which to trigger classifications, and determine the Scanner type Port Probes can be seen under "Discovery Definition > Port Probes", table discovery_port_probe A Scanner is a code in the MID server that uses the information from IP Services and Port Probes to scan a target port Scanners found in package com.service_now.mid.probe.shazzam.scanners Configuration The Shazzam probe will use the port probes as configured in a schedule's behavior, behaviors can be seen on table discovery_behaviorFunctionality “All” is used if the schedule does not use a behavior, or for quick discovery, functionality definitions can be seen on table discovery_function_def IP Service Affinity The IP Service Affinity allows Discovery to remember the service which successfully discovered an IP address. To turn on service affinity set system property (sys_properties) glide.discovery.ip_service_affinity = true. This property is set to false by default. Service affinities can be seen on table ip_service_affinity. Adding Ports to Shazzam Navigate to "Discovery Definition > IP Service" and create an IP ServiceNavigate to "Discovery Definition > Port Probes" and create a Port ProbeCreate new Discovery Functionality Definition on table discovery_function_defCreate new Discovery Functionality on table discovery_functionalityNavigate to "Discovery Definition > Behaviors" and create a discovery behaviorConfigure Behavior to use newly created functionality with definition and the port probe desired For discovery schedules without a behavior, or Quick Discovery: Navigate to "Discovery Definition > IP Service" and create an IP ServiceNavigate to "Discovery Definition > Port Probes" and create a Port ProbeNavigate to table discovery_function_def and open definition "All"Add newly created Port Probe to functionality Shazzam Payload Size A system property converts Shazzam payloads into JSON strings, which reduces the size and memory footprint. This setting can prevent nodes from running out of memory when a single schedule discovers large numbers of IP ranges. The glide.discovery.shazzam_ranges_json system property is set to true for new instances. This setting encodes the payload as a JSON string. The property is configurable by administrators and is available in the "Discovery Definition > Properties" module. The property label is "Use JSON for IP ranges in Shazzam" in the module. Scripts and Code Note: The code used by Shazzam is not limited to the following Build ECC Queue Ouptut ScriptIncludes StartDiscoveryShazzamLaunch MID Server Shazzam.java Process ECC Queue Input Discovery Sensor Shazzam Debugging Parameters Note: keep probe debug parameters set to false unless debugging shazzam Probe Parameters debug = truescanner_log = true MID Parameter mid.log.level = debug Debug ecc queue output creation Add breakpoints to ShazzamLaunch script where necessaryRun quick discovery or trigger scheduled discovery by running a script background like: // discovery schedule sys_idvar schedID = ""; // discovery schedule sys_trigger record sys_idvar schedTrigger = ""; var schedGR = new GlideRecord('discovery_schedule'); schedGR.get('sys_id', schedID); var schedTriggerGR = new GlideRecord('sys_trigger'); schedTriggerGR.get('sys_id', schedTrigger); var sd = new StartDiscovery(); sd.startFromSchedule(schedGR, schedTriggerGR); Example debug breakpoint Debug Shazzam probe execution on MID Set debug probe parametersSet MID Server to debugReview MID Server logsWith a network protocol analyzer review packets sent by MID to target and confirm target replied to packets sent Debug Ecc queue input processing Open discovery_sensor ShazzamAdd debug statements where necessary, gs.log()Review system logs SNMP Scanner SNMP credentials must be used in order to get a reply from a target device and determine SNMP is running on the target. Shazzam will attempt all available SNMP credentials until an SNMP credential is successfully used on a target device. A credential affinity will be created once the device replies to an SNMP credential. Once discovery knows the correct credential to use for the target IP, Shazzam probes will include the affinity and no longer need to attempt all credentials. Example Shazzam output payload with credential: Note: By default mid server parameter mid.snmp.enable_auto_public is true. This parameter specifies whether to use the SNMP public community string automatically if no other SNMP credentials were successful. Therefore even with no SNMP credentials configured discovery may still be successful for some devices being discovered via SNMP (devices which have public active). Configuration The Shazzam phase/probe can be configured via: MID Server ParametersProbe ParametersMID Server propertiesDiscovery Schedule configuration Thread Configuration Starting in Orlando, Shazzam can be multi-threaded. Shazzam will have threads run concurrently when both of the following MID Server parameters are greater than 0: mid.shazzam.threadsmid.shazzam.max_scanners_per_thread Probe Parameters BannerTCP_waitForConnectMS Sets the number of milliseconds the BannerTCP scanner waits for a connection and banner.Default: 1500 debug Enables debug logging if set to true.Default: false delay_webem Delays classification of systems with a WBEM port open until the final Shazzam sensor job. For a large schedule discovering many WBEM ports, delaying classification until the last sensor job could cause the node to run out of memory. Setting this parameter to false allows classification of these systems to occur across all Shazzam sensor jobs.Default: true DNS_alternativePort Deprecated DNS_waitForResponseMS Sets the number of milliseconds the DNS scanner waits for a response.Default: 1000 GenericTCP_waitForConnectMS Sets the number of milliseconds the GenericTCP scanner waits for a connection.Default: 1000 HTTP_waitForConnectMS Sets the number of milliseconds the HTTP scanner waits for a connection.Default: 500 HTTP_waitForResponseMS Sets the number of milliseconds the HTTP scanner waits for a response.Default: 500 NBT_alternativePort Deprecated NBT_waitForResponseMS Sets the number of milliseconds the NBT scanner waits for a response.Default: 500 report_inactive When true, reports devices that are alive but inactive. For example, a device has no ports open but refuses at least one port connection request.Default: true scanner_log Enables scanner logging if set to true. This logging information appears in the Shazzam probe response.Default: false shazzam_report_dead When true, reports devices with dead IP addresses. For example, a device that has all ports closed.Default: false SNMP_alternativePort Deprecated SNMP_tapIntervalMS Sets the number of milliseconds the SNMP scanner waits between taps.Default: 1000 SNMP_taps Sets the number of taps (requests) the SNMP scanner attempts.Default: 2 SNMP_waitForResponseMS Sets the number of milliseconds the SNMP scanner waits for a response after the last tap.Default: 1000 TLS_keepOriginalCertificate When true and Discovery is running, the certificate_file field in the cmdb_ci_certificate is populated with the original certificate. This can increase your payload size.Default: false MID properties/parameters mid.shazzam.regulator.interval_msSets the interval, in milliseconds, in which Shazzam can launch packets. This parameter works with the mid.shazzam.regulator.packets_per_interval parameter to set the number of packets allowed in this interval. By default, Shazzam launches one packet each millisecond. Type: integerDefault value: 1 mid.shazzam.regulator.packets_per_intervalSets the number of packets that Shazzam can launch in the configured time interval. This parameter works with the mid.shazzam.regulator.interval_ms parameter, which sets that interval. By default, Shazzam launches one packet each millisecond. Type: integerDefault value: 1 mid.shazzam.chunk_sizeSpecifies the maximum number of IP addresses that Shazzam scans in parallel. This parameter primarily controls outbound port consumption. Type: integerDefault value: 100 mid.shazzam.threadsSpecifies the number of concurrent threads that Shazzam uses. Setting this or the mid.shazzam.max_scanners_per_thread parameter to 0 disables Shazzam multi-thread optimization. Type: integerDefault value: 5 mid.shazzam.max_scanners_per_threadSpecifies the number of concurrent scanners processed by each Shazzam thread. Setting this or the mid.shazzam.threads parameter to 0 disables Shazzam multi-thread optimization. Type: integerDefault value: 500 Discovery Schedule Configuration Shazzam batch sizeEnter the number of IP addresses that each Shazzam probe can scan. Dividing the IP addresses into batches improves performance by allowing classification for each batch to begin after the batch completes. rather than after all IP addresses have been scanned. The probes run sequentially. For example, the value is set to 1000 and a discovery scans 10,000 IP addresses using a single MID Server. It creates 10 Shazzam probes with each probe scanning 1000 IP addresses. By default, the batch size is 1000. A UI policy enforces a minimum batch size of 256 because batch sizes below 256 IP addresses do not benefit from clustering. The policy converts any value below 256 to a value of zero. The value for this field cannot exceed the value defined in the maximum range size property for the Shazzam probe. Shazzam cluster supportSelect the check box to distribute Shazzam processing among multiple MID Servers in a cluster and improve performance. This setting works with the Shazzam batch size. For example, a schedule is created to scan 100,000 IP addresses, with 10 MID Servers assigned to do the work. Each MID Server is assigned to scan 10,000 IP addresses. If the Shazzam batch size is set to 5,000 IP addresses per probe, the schedule runs two Shazzam probes per MID Server (10,000 IP addresses/5,000 per batch). These probes are run in sequence and not concurrently.Use SNMP VersionUse this field to designate the SNMP version to use for this discovery. SNMP v3 is the most secure option. Valid options are v1/v2c, v3, or All. Example: