CBD Access to swtiches located in another VLAN

[Ciscorudy]

Hello,

I'm asking you because I can see all my switches located in the same VLAN as the one where CBD is installed. But I can't see the switches located in another VLAN.

However in the configuration I added the subnetwork associated with the switches of the other VLAN in the discovery option of CBD.

Namely VLAN of the CBD with the switches seen 172.20.1.0/27.
VLAN other switches 172.20.20.0/27

But it does not work.
I join you a picture of the network addresses seen by CBD. I do not understand why it sees 198.168.200.2/24 when I have not configured this range.

How can I add in the networks section OVERVIEW - Subnet my VLAN networks for the other Switches.

For information section VLAN :

VLAN2 = Network of process switches + CBD (works well 21 switches of overdraft)
VLAN10 = Network of other switches (Not functional CBD does not see the switches of this VLAN).

I have the impression that the discovery of equipment located in another VLAN than the CBD one does not work properly.

Thanks in advance

[balaji.bandi]

Looks like the tools you using to discover not able to reach other VLAN, so you need to add some where main lication to reach other VLAN to route the traffic so tool can recognise other subnet device.

most case this will done where the core switches VLAN Interface configured .

[David Harper]

Are there any direct connections between the switches on vlan 10 and and any of the switches that CBD has discovered?  To discover across VLANs, CBD will typically find the devices in the other VLANs by looking at things like CDP, LLDP and ARP tables in the devices it does discover.  Once it knows those devices exist and it has an IP address for them, it can connect to them directly to manage them.  But if those devices are not visible in the neighbour tables of the devices CBD has already discovered, then CBD has not way to find out that they exist.

It would probably be a good idea to call the support team using the local phone numbers published at https://cisco.com/go/sbsc and talk this through with an engineer.  Depending on what the network topology looks like, there may be a couple of different ways to get CBD discovering those devices.

Cheers,

Dave.

[Ciscorudy]

Hello,

No, they are physically separated VLANs via a firewall.

For example:

An ethernet interface of the firewall (Eth1) for the process network with a dedicated VLAN switch and the CBD installed in this VLAN.

An ethernet interface of the firewall (eth2) for the DMZ network with a dedicated VLAN switches.

The firewall rules are well implemented to allow the process VLAN sw to see the DMZ VLAN.

So no physical link between the process VLAN switches and the DMZ VLAN switches except the firewall.

Can't we directly modify the DEBIAN configuration to create static routes for example or define the different vlan.

Thank you for your help on this complex subject.

Concerning the help I'm not sure if it is supported.

[David Harper]

It's not a routing problem.  CBD deliberately does not actively scan IP ranges to discover devices as that can cause problems in some networks.  I think that, given the network you describe, the solution is to enable the probe on one of the switches on the eth2 side of the firewall.  You will need to modify the firewall rules to allow that switch's IP address to establish a TCP connection to port 443 on the dashboard, but hopefully that is doable.  Once you have a probe running on that network, then the rest of the switches will be discoverable and manageable.

To do this, the switch will need to be a CBS250 or CBS350 model (there are some older Small Business series devices that also do this if you are not using the Cisco Business models).  Also, you will need to have no more than 15 managed devices on that network.  If either of these is a problem, then we will need to look at a different solution.

Cheers,

Dave.

[Ciscorudy]

Hello Thank you for your help,

That's what I tried to do, activate the probe in one of the switches of the VLAN apart see picture below.

The firewall allows the connection between the 2 VLANs. Possibility to ping on the CBD via the switch in the VLAN DMZ.

But without success I have no return on the CBD side. I even tried to create a new network in CBD with the certificates etc but without success.

[David Harper]

This sort of problem is frequently due to a problem with the way the dashboard certificate is constructed.  Could you go to the System > Certificate page in the dashboard and use the download button there to get a copy of the certificate chain in use.  Then pm that to me and I can pretty easily check if that is causing the problem.

Cheers,

Dave.

[Ciscorudy]

Hello,

here is the file certificate

Thank you

[David Harper]

Ok.  That certificate looks like the one that would have been auto-generated when the system was first installed.  It does not have the necessary information in it for it to be accepted by the switch as a valid server - in particular, the IP address configured for the dashboard on the switch web page is not present in the Subject Alternative Name field in the certificate.  To fix this, navigate back to the System > Certificate page on the dashboard, select the Update Certificate  tab and Renew Self-Signed Certificate radio button, then fill out the form with whatever data is appropriate for your environment and click Save.  This will generate a new certificate and ensure that the current IP address is included in the SAN field.

The other thing that will be needed is to install the certificate in the switch.  Because the certificate is self-signed, it is not automatically trusted by the switch.  To allow it to be trusted, you will need to do the following steps:
1.  In the switch UI, select the Advanced option in the Display Mode dropdown at the top right of the GUI
2. Navigate to Security > Certificate Settings > CA Certificate Settings and then click the Import button on that page.
3. You can use any name for the certificate, and then copy/paste the encoded certificate - including the BEGINE CERTIFICATE and END CERTIFICATE markers - into the space provided.  You can get the encoded version of the certificate using the Download button on the System > Certificate > Current Certificate page in the dashboard.

Once you have done these two things, the connection between the switch and the dashboard should come straight up.

Cheers,

Dave. 

[Ciscorudy]

Hello,

Thank you for this answer.
Unfortunately I had already done all this but without success in the switch it remains disconnected!

However I followed all the steps.

Recovery of the certificate.
insertion in the switch.
Installation of the user
...

Many thanks

[David Harper]

Ok, this looks like it is set up correctly now.  I assume the firewall rules will allow the switch to create a connection to the dashboard on TCP port 443?  One other thought is to make sure the switch firmware is version 3.1 or higher, as the probe version in the original 3.0 software is a bit old to interoperate with recent versions of the dashboard.

But if connectivity is good and the switch firmware is recent, then we will need to dig a bit deeper.  Can you change the log settings on the switch on the CBD page so that the log level is set to debug and the only log modules enabled are Call Home Logging and System Logging.  After changing the settings, wait a couple of minutes and then collect a copy of the dashboard info file.  To get this, first plug a USB key into the switch, then go to the Administration > File Management > File Operations page on the switch, select the Backup File and Dashboard Info File radio buttons, and enter a filename in the text box provided.  Then click Apply.  It will take a couple of minutes to collect the data and save it to the USB key, but once this is complete, pm the file to me and we can have a look and see what is wrong.

Thanks,

Dave.

[Ciscorudy]

Hello,

I had at first an error of not validated certificate but solved by activating the time server on my SW.

Now I have the following error: Disconnected (access key-error - HTTP unauthorized)

Thanks for your help

[David Harper]

Check to make sure the access key is still valid.  The default lifetime when you create the key is seven days and so it could easily have expired.  If you go to your user detail page where you generated the key and look for it in the table of keys, you will see if it is still valid or not.  If it is still valid, then we will need to dig a bit further, but that is the first thing to check.

Cheers,

Dave.

[Ciscorudy]

Hi,

Indeed there was a problem in the validation of the KEY.
Now it works my networks are online.

But I have again problem that I want to access to the Topology networks of the others I have an error. It works only for one network the other errors.

Many Thanks for your support,

[David Harper]

This happens when the probe version at the site is old compared to the dashboard.  I assume the probe is running embedded on a switch at this site?  If so, upgrading the switch firmware to the latest should fix the problem.

Cheers,

Dave.