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.

http://www.cisco.com/en/US/docs/switches/blades/cgesm/software/release/12.2_25_se/configuration/guide/CGESMSCG.pdf

[...]

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.) for these types of switches (CIGESM -and cat2950?) regardless the VTP mode of the switch;

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. for cat2950 switch types i think that in does a comparison whith different count of items.

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

or

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.

Thanks! hI will do these steps tomorrow.

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.

Thank you very much! I opened SR 608872037 to get the patch.