question Re: Discovery of Brocade SAN Switches in ServiceNow AI Platform forum

Discovery of Brocade SAN Switches

Peter Nowak — Thu, 17 Sep 2020 14:54:32 GMT

Hi,

we want to discover Brocade SAN Switch DCX8510-8 (IBM System Storage SAN768B-2 Backbone
(2499-816).
We want to use the SSH connection, but Shazzam identified the switch as a UNIX System and therefore the discovery run failed.

Then we tried SNMP. But snmpv1 and also snmpv3 failed. Every time the Shazzam identified the switch as UNIX and no further data came out of the switch.

We don't want to use CIM, as CIM use the BNA, and BNA will not be used in future. Other CIM server isn't available.

So, how it is possible to discover a Brocade Switch.

Thx for any answer.

BR, Peter

Re: Discovery of Brocade SAN Switches

Vivektietsood — Fri, 18 Sep 2020 00:15:50 GMT

Please try running discovery with SNMP as priority 1 or order 1 credentials and Unix order 2 (or even take out Unix credentials if possible)

Reason for your error:

Credentials can be assigned an order value in the Credentials Form, which forces the application to try all the credentials at their disposal in a certain sequence. If you do not specify an order value, the application tries the credentials in the Credentials [discovery_credential] table randomly, until it finds one that works.

Once the discovery is successful, susequent runs should be easier, because:

After identifying the credentials for a device, Discovery and Orchestration create an affinity between the credentials and the device using the Credential Affinity [dscy_credentials_affinity] table. All subsequent discoveries or Orchestration activities attempt to match the credentials in this table with a device for which an affinity exists. If credentials for a device change, Discovery and Orchestration try all available credentials again until they create a new affinity.

Other Info on Credential Order

Order (sequence) in which Discovery tries this credential as it attempts to log on to devices. The smaller the number, the higher in the list this credential appears. Establish credential order when using large numbers of credentials or when security locks out users after three failed login attempts. If all the credentials have the same order number (or none), the instance tries the credentials in a random order.

Please like or accept solution so that it helps others too.

Re: Discovery of Brocade SAN Switches

Peter Nowak — Fri, 18 Sep 2020 11:01:22 GMT

Thx for answer.

We'll try this. I'll get in touch.

BR, Peter

Re: Discovery of Brocade SAN Switches

Peter Nowak — Fri, 18 Sep 2020 14:58:20 GMT

Hi,

we implemented the tip. Unfortunately this did not lead to the desired success. As before, no data can be extracted from the switch.

Also the behavior of the discovery run itself has also remained the same ...

Any other tip ?

BR, Peter

Re: Discovery of Brocade SAN Switches

Alikutty A — Fri, 18 Sep 2020 15:14:56 GMT

Hi Peter,

You will need to use a behavior and scan the device in a separate schedule using the SNMP protocol only.

Steps to follow:

1. Create a new behavior with SNMP only port

2. Create a new schedule and add your device IP in it, Select the mid server selection method as Use Behavior and add yours in it.

3. Run the discovery

When you scan the device, Shazzam will only use the SNMP port and if you have valid credential/firewall access (161) then the device should get discovered. You can do this approach for all SNMP devices which have the SSH ports opened in it.

Note: Do not change the classification priority as it is global change.

Reference: https://docs.servicenow.com/bundle/paris-it-operations-management/page/product/discovery/task/create-disco-behavior.html

Re: Discovery of Brocade SAN Switches

Peter Nowak — Mon, 21 Sep 2020 12:32:41 GMT

Hi Alikutty,

thank you very much first. We did your suggestion. The discovery ran much more faster. However, the result is no different from the previous one. I think it is because of the snmp configuration of the switch.

Maybe you or anyone else has some tips.

BR, Peter

Re: Discovery of Brocade SAN Switches

Alikutty A — Mon, 21 Sep 2020 14:10:14 GMT

What is the current error in your discovery log? Where does it stops in the ECC queue?

If it is failing during Shazzam then Port 161 should be opened.

If it is failing during Classification, then your SNMP credentials are not working.

If it is failing during Identification, then your SNMP OID entry is missing in the instance.

Please clarify?

Re: Discovery of Brocade SAN Switches

Peter Nowak — Mon, 21 Sep 2020 14:25:57 GMT

It's not failing, but discovered as a "linux server" device without any details in the tabs.

Port 161 is open

SNMP credentials working SNMPv1 and also SNMPv3, we tried both.

Peter

Re: Discovery of Brocade SAN Switches

Alikutty A — Mon, 21 Sep 2020 14:42:16 GMT

So it is scanning on port 22. This should not happen if you setup the behavior correctly. Did you setup SNMP behavior and update it on your discocery schedule? Behavior may not work in quick discovery.

Please show a screenshot of your ECC queue and discovery schedule configuration.

Sample

Re: Discovery of Brocade SAN Switches

Joachim Fink — Mon, 21 Sep 2020 16:31:12 GMT

Hi Alikutty,

many thanks for your help so far - we really appreciate it 😉

I will provide you with detailed information regarding the discovery set up by choosing the just freshly established "SNMP only Discovery" behavior:

That's what is in the ECC queue:

Finally this SAN switch was classified as "linux server":

Any helpful suggestions are highly welcome!

Thank you in advance.

Sincerely,

Joachim

Re: Discovery of Brocade SAN Switches

Vivektietsood — Mon, 21 Sep 2020 17:04:40 GMT

this has me confused too :). Can you check IRE (Identification and Reconciliation Rules) for switches and Linux servers ? And paste the screenshots here.

Re: Discovery of Brocade SAN Switches

Alikutty A — Mon, 21 Sep 2020 17:05:08 GMT

Hi Joachim,

From the ECC queue, the Identification phase is going into the credentialess discovery pattern which is not expected. Can you disable credententialess discovery inside your mid server and try this again?

Ideally it should call the Network switch pattern for the right device discovery.

Thanks!

Re: Discovery of Brocade SAN Switches

Joachim Fink — Mon, 21 Sep 2020 17:26:32 GMT

Hi Alikutty,

I disabled credententialess discovery inside our mid server - now the device doesn't get classified at all - discovery ends after SNMP classify which found 348 OIDs :

"SNMP - Classify: 348 OIDs"

Thank you once again!

Re: Discovery of Brocade SAN Switches

Vivektietsood — Mon, 21 Sep 2020 17:51:09 GMT

okay, another thought - are you able to discover any SNMP device like printers or any other switch / router if not then this may indicate a problem with the pattern, maybe pattern needs to be installed again. If yes then sometimes network engineers create custom ports, it may be possible that the switch in question is not configured to listen on port 161, and is using some other custom port.

Re: Discovery of Brocade SAN Switches

Vivektietsood — Mon, 21 Sep 2020 18:26:22 GMT

This might be useful too, taken from the following thread:

https://community.servicenow.com/community?id=community_question&sys_id=b12d89b2db0af3804abd5583ca9619a0&anchor=answer_31692e43db0afb806c1c02d5ca961958&view_source=searchResult

The Linux SNMP classifier, by default, is inactive and typically wouldn't be used. Enabling the classifier tends to collect a lot more things as Linux Servers then you'd actually want it to. It's likely your device has a lot of routing capabilities, which is why Discovery is classifying it as such.

If the device is running a Linux OS and you can use SSH, I'd recommend trying that route first. However, most appliances are running a hardened version that you might not be able to query everything by default.

In the end, you may have to come up with your own Discovery SNMP pattern to create your CI properly in the table you want and with the right attributes that are specific to the manufacturer/model. I'd recommend watching Doug's video on creating SNMP patterns to help you out.

https://community.servicenow.com/community?id=community_article&sys_id=dfd86535db172300f21f5583ca9619dc

Re: Discovery of Brocade SAN Switches

Joachim Fink — Tue, 22 Sep 2020 08:48:46 GMT

Hi Vivektietsood,

thank you for your suggestions.

Port 161 and 162 were opened at the firewall (TCP & UDP) for connections from the MID Server to fulfill SNMP discovery requests of network devices.

Other SNMP devices can be correctly discovered and CI's are created.
What we see in the ECC for those devices queue looks ok for us
(order in the screenshot is upside down):

Any hint is valuable for us.

Many thanks for your support!

Sincerely,
Joachim

Re: Discovery of Brocade SAN Switches

Joachim Fink — Tue, 22 Sep 2020 09:57:39 GMT

Btw - we've already tried SSH before - credentials were successful, but we had issues with it - like
< command not found : "uname -a" .... >

Re: Discovery of Brocade SAN Switches

Inactive_Us1148 — Mon, 22 Feb 2021 17:23:43 GMT

Do you have the OID to classify this device in your SNMP OID Table?

If not, you might want to add it.

Based on what I'm seeing the OID for this device is 1.3.6.1.4.1.1588.2.1.1.120
ServiceNow should have an OID Classifier with 1.3.6.1.4.1.1588.2.1.1.121 that should work for this device with a little tweaking. I would create a copy of this SNMP OID Classification record and change the *Oid to 1.3.6.1.4.1.1588.2.1.1.120 and when its all said and done it should look like the attached. With the OID matching it should kick off the Classifier and you should be in business.

Stick with what the others said above, use a Behavior for SNMP when discovering these devices.

Try that at let us know if that works.

Re: Discovery of Brocade SAN Switches

Mohammad14 — Thu, 21 Oct 2021 20:59:15 GMT

Make an entry in Snmp system oid and define classifier , table/class to populate , Manufacture , model.

keep credential less disabled.

try it. should work just fine. in case you miss some ci attributes not fetching .. load MIBs file and restart MID server .. to sync with MIBs.

hope this helps.

Thank you