we are installing several SX350 devices and configure them with Business Dashboard via SNMP and http(s).
We had to restart our Hypervisor to install Updates and Hardwareupgrades, after each restart of the Dashboard VM a Job, created by System, run to configure every Port as Trunk with all VLANs. How can I stop this?
And how can I update the present installation to the new release (June)?
Thanks and regards,
Using PnP for initial configuration and making VLAN changes manually afterwards will certainly prevent the problem from occurring. Basically the problem will only happen if you have a VLAN profile assigned to the device group, so if you take the profile away and manage the VLANs through other means, then CBD will not change anything.
The change of the access port to a trunk port is part of the bug. Basically CBD is adding the VLAN to all active ports, not just the ones that need it. In any case, I'll work with engineering on getting a fix and will update you when I have something that you can test.
Sounds good so far, thanks.
Maybe the "trunk-bug" is related to the Firmware of the switch. We are useing 188.8.131.52.
Stick to PNP, is there a way to delete a device directly from the DB? I have a "play" switch, but now I can't use PNP on this device anymore because (even after deleting it from Dashboard) it appears with old Name. I reset the switch to factory defaults, deleted it from Dashboard and after this I enabled PNP again.
Sorry for so much trouble and regards,
No, the problem with the ports is entirel due to CBD. Being able to see both access and trunk configuration on the port is normal. The mode of the port determines which parameters take effect, but the configuration for both modes is retained.
Regarding PnP, the device needs to be offline to be able to be deleted from CBD. By that I mean not currently visibile to a probe and not actively connected to the dashboard in a direct management configuration. But when you delete the device, all information about that device is removed. It sounds like what is happening for you is that you are adding the device as a PnP device and calling it something slike switchA, but then after the device comes up and connects to the dashboard you see it as switchB. Most likely what is happening here is that the hostname on the switch is actually switchB, and when it is first discovered, CBD will update the name as CBD knows it to match the device hostname. Does that match what is happening here?
thanks for your info about the port config on the config file. Hopefully you guys could change it someday to read it the config file better.
About the PnP Device:
Yes, it was connected to a probe. I disconnected it, delete it from Dashboard and waited for about 10min. After this period I reconnected the device and it showed up as old hostname and type "Host". At the moment it's running with a very basic config and without a configured hostname (it uses factory default). CBD shows it under PNP devices ("Enabled Devices" and for some reason not under "Unclaimed Devices"). Should I try to setup the device manual under Inventory -> Add?
Regards and have a nice weekend,
This is a bit unusual. It's not uncommon for a device to be initially detected as a host as there are several discovery methods that will really only identify the device's MAC and IP addresses. But generally it should be identified more correctly within a couple of minutes. However, it doesn't happen magically - there must be a discovery method used to identify what type of device it is. The options here include:
1. Discovery from Bonjour announcements. This will only work if the device is in the same VLAN as the probe.
2. Discovery through LLDP or CDP. The requires the device to be connected to a switch that is already managed by CBD
3. Discovery by querying the SNMP system MIB. This won't be an option here as SNMP is disabled by default on the switches and you mentioned the switch was at factory defaults.
You can check which discovery methods apply to this device by selecting it in the CDB inventory and clicking on the More... button to see the device details. The discovery methods are shown in the lower left of the screen. But from what you have described, I don't think any of these three methods is going to be the case here. Discovery is probably by either ARP table or MAC address table.
Manually adding the device probably won't change anything. If I had to guess, I'd say that when you were provisioning through PnP earlier, your configuration probably enabled SNMP, or maybe moved the management interface to a different VLAN that contained the probe. But now I'm just guessing.
At this point, it's going to be hard to say exactly what is happening without getting some more detailed information. I'm going to suggesting calling your local support number listed on https://cisco.com/go/sbsc and get an engineer to work through the problem with you live. In the end it will probably be something pretty simple, but they will need to understand the network topology and will probably ask you for some specific screenshots or diagnostics as they work through the troubleshooting process.
we use option 1, CDP doesn't work yet but worth a try. The affected device doesn't show up in Inventory, so I can't say anything about how it was discovered. I can only say that this is connected to a SX550X Stack where Probe is enabled. I tested the steps with a brand new Switch (incl. old FW), and it works as expected after I setup a very simple pnp config. After "Claim Device" and select the Firmware and Config it took some time and then it was ready configured.
However, I added the device manual and reapplied the config -> its working