06-10-2008 07:17 AM
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.
06-16-2008 09:21 AM
I have not produced a patch for this bug as it requires some architectural changes, and more code testing is required before releasing. This bug should be fixed in CM 5.0.4.
06-10-2008 09:09 AM
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.
06-11-2008 04:30 AM
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
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.
06-11-2008 09:49 AM
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.
06-11-2008 12:22 PM
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.
06-12-2008 05:51 AM
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?
06-12-2008 07:07 AM
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.
06-12-2008 07:24 AM
06-12-2008 07:27 AM
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.
06-12-2008 07:31 AM
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.
06-12-2008 09:09 AM
Thanks! hI will do these steps tomorrow.
06-13-2008 08:18 AM
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...
06-13-2008 10:23 PM
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.
06-16-2008 02:08 AM
Thank you very much! I opened SR 608872037 to get the patch.
06-16-2008 09:21 AM
I have not produced a patch for this bug as it requires some architectural changes, and more code testing is required before releasing. This bug should be fixed in CM 5.0.4.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide