cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
915
Views
0
Helpful
9
Replies

discrepancy report : Duplicate Sysname with NAT devices

christianpho
Level 1
Level 1

Hi,

we are using CiscoWorks 5.0.2

Two of our devices are behind a firewall and there IP address was NAT by Firewall for CiscoWorks server. In device credentials for those device the NAT ip address was use to join thoses 2 devices.

switch : lab01 as 10.0.0.1 configure as NAT to 192.168.0.1 by Firewall CiscoWorks credentials point to 192.168.0.1 ip address

lab02 as 10.0.0.2 configure as NAT to 192.168.0.2 by Firewall CiscoWorks credentials point to 192.168.0.2 ip address.

When I run my discrepency report I always got error Duplicate Sysname for thoses 2 devices. The messages does not include any information about which device IP have the same sysname.

I think the fact the device was NAT cause that problem but I don't see where I can specify thoses 2 IP address are for the same device....

1 Accepted Solution

Accepted Solutions

This appears to be the same switch triggering the discrepancy. That could indicate some stale or bad data in the ANI database. Debugging this will require you to enable core, corex, and dcrp debugging under Campus Manager > Admin > Debugging Options > Data Collection. However, I will probably not have time this week to look at the resulting ani.log. Therefore, you might want to open a TAC service request.

View solution in original post

9 Replies 9

Joe Clarke
Cisco Employee
Cisco Employee

For IOS devices, the sysName is built using the hostname + ip domain-name. Do any of your devices have this same configuration? We typically see this when a switch or router is deployed with the default hostname (e.g. Switch.company.com). NAT shouldn't have anything to do with this.

Hi !

devices in question are a 2924MXL Cisco Switches. The IP address used by thoses devices are not used anywhere else in the network known by CiscoWorks (this is true also for ip address configured in the device and there NAT address).

The ip domaine name is all the same in everywhere in the organisation. And are configure in the configuration of thoses devices. An host entry are been created manually for those 2 devices for there NATTED ip address (192.168.0.0 network) with there reverse lookup entry.

Wy was tried to delete those device and recreate them and we got the same situation.

I was think the problem was caused by NAT because we have only 2 devices are NAT for CiscoWorks thoses to we have this problems.

I'm sure the devices was not left with there default hostname configured on them.

Excuse my English, I'm a French people !

If you have two suspect devices, query their sysName via SNMP. You can use Device Center > Tools > SNMP Walk to do this. The starting OID should be sysName. This value will not be touched by NAT at all, so if the walk from the CiscoWorks server reveals the values are identical, then the hostname will need to be fixed on at least one of the switches to ensure proper Campus Data Collection.

Hi !

I had query those 2 devices, each of theses have only one IP address (the correct one for each) and for each the sys name is what it should be for each of them.

Like I was wrote in my first post the messages log contain no more information about any other device in conflict, how can I solve this problem....

Hi !

I have some new about this today !

I was not remember in the past if it was the same thing last week I had deploy command to add domain name to all 2924 Cisco Switch in our network.

In the "Discrepancy Detail" box I see the following :

The following devices have the same SysName.

Device type and OS version of LABO02 :

Cisco Internetwork Operating System Software

IOS (tm) C2900XL Software (C2900XL-C3H2S-M), Version 12.0(5)WC17, RELEASE SOFTWARE (fc1)

Device type and OS version of LABO02:

Cisco Internetwork Operating System Software

IOS (tm) C2900XL Software (C2900XL-C3H2S-M), Version 12.0(5)WC17, RELEASE SOFTWARE (fc1)

192.168.0.2

192.168.0.2

Note: If devices,running Cisco IOS,have the same SysName then only one of the devices will be discovered by Campus Manager.Delete the discovered device and perform another discovery after configuring unique SysName on devices.

This appears to be the same switch triggering the discrepancy. That could indicate some stale or bad data in the ANI database. Debugging this will require you to enable core, corex, and dcrp debugging under Campus Manager > Admin > Debugging Options > Data Collection. However, I will probably not have time this week to look at the resulting ani.log. Therefore, you might want to open a TAC service request.

Hi !

before post any messages on this news group we was deletes thoses 2 devices and add them again to database.... we was thing that will remove any corrupt data in the database about those devices...

Hi Mr. Clarke,

like you had advise me I had open TAC resquest for this issue here there answer :

I have double-checked this information with the development team and this is the response I have received from them:

While LMS can support devices across NAT boundaries, SNMP is not a truly NATable protocol. The SNMP PDU's which contain IP addresses (like cdpCacheAddress, etc.) cannot be translated.

Therefore, Campus Manager ends up getting confused. There is no workaround for this since no one has yet designed a NAT ALG for SNMP.

However, if you check the explanation of the discrepancy you will see that this is not an impacting network issue on your server:

“Devices With Duplicate SysName

Campus Manager reports a discrepancy when it discovers two devices with the same SysName. Campus Manager stores the device details of only one of the two devices.

Impact

Campus Manager manages only one of these devices.

Fix

Assign unique SysName for all devices in the network. You cannot fix this discrepancy through Campus Manager.”

In order to avoid getting this discrepancy on the reports you can Acknowledge the discrepancy and this way it will no longer appear on the report.

I apologize for any inconveniences that this may cause you.

Please let me know if we can proceed with the closure of this SR.

I was the one that provided this answer. I had a "duh" moment before, and it was your log that solidified what was actually going on. Sorry for the confusion.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco