CM 5.0.3 Discrepancy Reports: false Vlans Trunk mismatch for CIGESM

[Martin Ermel]

at a customer site I found false 'Vlans Trunk Mismatch' for CIGESM connected to a Cat6500. A SNMPwalk on 'vlanTrunkPortsVlanEnabled.<ifindex> against the trunk port on both sites of the trunk does not show any difference, so I assume it is a bug in CM and not in the SNMPagent on the device. Another possibility is that 'vlanTrunkPortVlansEnabled' is the wrong OID and the discrepancy report algorithm uses some other OIDs...

Does anybody else see these false positives?

Attached is the output of snmpwalk on several OID along with the discrepancy report.

[Martin Ermel]

the files you provided were copied to the server as adviced and they are doing their job quite well. From around 450 discrepanycies only 11 are left...(which are truth config failures)

Thanks for your support!

[Joe Clarke]

What you were given was a gross mistake on your engineer's part, and is actually doing nothing to help fix the problem. I recommend you delete the files sent to you.

The true fix will come in Campus 5.0.4 which is slated for an October release. This is later than I expected (but was pushed back to accommodate LMS 3.1).

[Martin Ermel]

The files solved the issue with the 'Discrepancy Reports'- that was fine for the customer. But do you think there is a *high* risk that there will be new issues? - I assume they cannot resolve the whole impact- or currently it cannot be guaranteed that they will - but the information for this switch type was inaccurate and unreliable (for VLANs > 1024) before. The customer does not use 'Vlan Port assignment' and the 'Discrepancy Report' do whight more for him; So I am not sure if I can persuade him to roll back but I will advice him to do so.

Will changeing 'devices.xml' be a workaround until the patch will be released?

[Joe Clarke]

What I meant was that the files do absolutely nothing. Honestly, they are Cisco confidential source code files that should have never been given out. In order for the patch to work, you would have needed compiled .class files and a new devices.xml file.

The only way this could be working now is if you retained your previous devices.xml file with the hack, and/or you did not delete and re-add the CIGESM in Campus.

Yes, the hack in devices.xml is a viable workaround for the CIGESM (not other 2950s) until the CM 5.0.4 comes out.