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.
Solved! Go to Solution.
The problem is these switches do not properly support 4K vlan instrumentation. Therefore, VLANs greater than 1000 are not polled. the only switches which support this (and for which Campus has support) are the 6500s, 4000s, 3750s, and 3550s. The CIGESM is considered a 2950-like switch by Campus.
If I understand the documentation correctly, you are right if the switch is running in VTP server or VTP client mode. But when the switch is in VTP Transparent it supports the extended Vlans.
Beside the fact that the switch works without any problems, as the extended vlans gets reflected correctly in the mib, I assume it fully supports this configuration.
Configuring Extended-Range VLANs
When the switch is in VTP transparent mode (VTP disabled), you can create extended-range VLANs (in
the range 1006 to 4094).
So I see a few things here:
1) currently, CM polls only the standard vlans (vlanTrunkPortsVlanEnabled.
2) there could be a new discrepancy type which is much more meaningful, like 'No Support For Extended VLANs On Trunk'
3) if CM really polls only vlanTrunkPortsVlanEnabled.
i.e. for cat2950 CM has a set of info with 1 item (vlanTrunkPortsVlanEnabled)
for the cat6500 CM has a set of info with 4 items (vlanTrunkPortsVlanEnabled, ..2k, ..3k, ..4k)
which I feel is not a valid comparison..
3) CM should either try to poll each OID of vlanTrunkPortsVlanEnabled, ..2k, ...3k,...4k and then just compares this with the other end of the trunk
CM should first determine the VTP mode and then decide which OID to poll
anyway a new discrepany type should be introduced for this type of failure, where extended vlans are not supported on one end of a trunk.
Not supporting extended VLANs and not fully supporting extended VLAN instrumentation are two different things. If the devices do properly support all of the MIB objects (looks like they might, but since I don't have a CIGESM, I have to rely on what development did), then you can edit NMSROOT/campus/etc/cwsi/devices.xml, and move the CIGESM entries under the C2970 section. Then, restart ANIServer, and run a new Data Collection. That should clear up the discrepancy.
If so, then some code could be added to the C2950 module to detect 4K VLAN support.
I hope I got it: extended VLAN instrumentation means support for extended VLANs through management 'techniques' like snmp; and 'fully supporting vlan instrumentation' means not only displaying extended VLAN information but also giving the possibility for e.g. creating and deleting extVLANs with these techniques.
I will try to do the test with devices.xml as soon as possible but I will not be on site with the customer before thursday next week.
I did get the devices.xml from the customer, changed it according to your advice and let the customer replace the file with the original one. Restart of all processes and a 'Data Collection' still shows the CIGESM (.660 - oscigesm) in the 'Vlans Trunk Mismatch' discrepancy report.
CM even founds a new one (actual timestamp);
Could it be that there is cached information on the server and I should delete the files and directories under 'NMSROOT/MDC/tomcat/work/Standalone/localhost' ?
If a discrepancy is not found any more after a 'Data Collection' will it be automatically deleted from the table?
Are vlanTrunkPortVlansEnabled, ...2k, 3k,4k the only OIDs polled for calculating this discrepancy?
Please post your modified file. Discrepancies are only stored in memory. When you restart ANIServer, they all return to 0. They are recreated every time Data Collection runs. Yes, the vlanTrunkPortVlansEnabled* objects are polled amongst others to determine active and allowed VLANs on a trunk.
but the information about the found discrepancies must be stored in the DB as the column 'first found' does have a date a few days in the past for most entries, or where is this information stored?
attached is the modified devices.xml...
No, the data is not persisted. It is kept in ANIServer memory. Try it out. Note the number of discrepancies and best practice deviations on the Campus Manager homepage. Restart ANIServer. Then refresh the homepage. The counts will drop to 0 for each. Now run a new Data Collection, and the counts will return to their previous values.
This type of modification is not typically done, and it occurred to me that simply re-running Data Collection might not be sufficient. Try deleting this device from Campus, then re-run Data Collection to get it back.
Successfull! As a test, one of the devices that was listed in the report was delete from the topology map and a new Data Collectio was done. After that the discrepancy report for that device was gone !
For the rest (around 130) they were completely deleted from DCR and rediscovered. After the preceeding Data Collection the false positives where gone from Discrepancy Reports.
... those that are still there, are the ones for the cat2950 (12.1.(22)EA9) ...
it is clear that they are still there, but this could be resolved as well because I can get the relevant info through SNMP (vlanTrunkPortVlansEnabled*);
but currently I hope the code will be changed to get rid of that issue, - or could I also move the cat2950 to the cat2970 section? I feel that this is not a good idea as I assume it could have impact on other functions of LMS...
I filed CSCsq79950 to track this. I wrote code to add support for 4K VLANs on all 2950s running 12.1(9)EA1 code or higher. It appears this was the release that introduced extended VLAN support.
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!
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).
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?
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.