For some reason duplicate DCF interfaces are generated occasionally within our Cisco CBR-8 driver:
In the driver, we create DCF interfaces with the line below, and in table 44000 we only have 1 line per primary key (as expected):
In another element running the same driver, we do not have this problem.
What could be causing this problem, and how could we resolve it?
It looks like all the duplicates have 1 item in range 100 000 and one item in range 150 000. This indicates they were created at very different times but don't know the other existed at the time of creation.
One of the key guidelines for efficient use of DCF is to keep the amount of interfaces as static as possible.
A DCF Interface provides a lot of information and is useful in many of DataMiner's modules which is why creation & deletion can be considered a heavy operation.
The creation & deletion of a DCF Interfaces takes a bit of time to bubble through all the processes.
It is likely that because of the amount of interfaces in your setup something may have gone wrong during cleanup or addition of so many interfaces. Perhaps the dma was restarted while it was still busy processing the interfaces or something similar happened that caused a race condition.
Retriggering cleanup & addition and waiting on it to finish is indeed the way to fix the problem. As you did through turning dve creation on & off (this retriggers parts of the DCF code to do with interfaces on dve's).
Could you provide the full driver name and version?
The Cisco CBR-8 has different ranges with different implementations.
Normally dynamically created interfaces start at ID 100000.
I’m seeing interfaces with an id of 150000 and higher. Are there over 50000 interfaces being created?
This is good information. At one point in the past, there were over 5000 DCF interfaces being generated. We noticed this caused problems, and so we adding some conditionals to generate fewer interfaces about a month ago. However, this was for a different interface type, not the RPDs.
Hi Jan, indeed. This is the 3.0.0.1 version of the driver, a customer specific range.
I neglected to mention one thing – table 44000 is also creating DVEs. You should see that within the driver. To fix the issue, we simply turned off DVE creation within the driver, and turned it back on.
Of course, I am still curious as to the cause and if that can be prevented.