"Config file change from task:PDMIPC" every 3 minutes

[Anonymous]

Hi,

swFCPortScn is enabled for tracking FC ports going up & down, However brocade is *SENDING SNMP TRAPs* swFCPortScn every 3 minutes which corelates with errdump entries like this:

2010/03/03-10:04:35, , 140828,, INFO, x, Config file change from task:PDMIPC

2010/03/03-10:07:37, , 140829,, INFO, x, Config file change from task:PDMIPC

2010/03/03-10:10:40, , 140830,, INFO, x, Config file change from task:PDMIPC

even having SNMP-TRAP to NO. We have also second identically configured switch (also with swFCPortScn & SNMP-TRAP enabled )and that second one is not throwing traps (sic!), but both are seeying "Config file change from task:PDMIPC"

On both the same:

x> trackchangesshow
Track changes status: ON
Track changes generate SNMP-TRAP: NO
x>

x> snmpconfig --show mibcapability

FE-MIB:YES
SW-MIB: YES
FA-MIB: NO
FICON-MIB: NO
HA-MIB: YES
FCIP-MIB: NO
ISCSI-MIB: NO
SW-TRAP: YES
   swFCPortScn: YES
   swEventTrap: YES
   swFabricWatchTrap: YES
   swTrackChangesTrap: YES
SW-EXTTRAP: YES
HA-TRAP: YES
   fruStatusChanged: YES
   cpStatusChanged: YES
   fruHistoryTrap: YES
x>

Firmware: 6.1.1b. Configshow is not throwing errors. Any help? Is this a bug ? What's the difference between swTrackChangesTrap and "trackchangeset 1,0" (SNMP-TRAP change tracking) ??

How it is possible that 2 identically configured switches are acting differently? Reboot after SNMP configuring would help?

[Anonymous]

Did some more digging:

(from doc)

Parity Data Manager (PDM) is a user space daemon responsible for the replication of persistent configuration files from the primary partition to the  secondary partition and from the active CP Card to the standby CP Card.

This leads to "partition" and "firmware" so I've digged more into it:

(from doc)

configupload
When the local chassis is chosen as the destination, the resulting file is written to both primary and
secondary partitions, and on enterprise-class platforms, to both Active and Standby Control
Processors (CPs).

firmwarecommit
Use this command to commit a firmware download to a CP. This command copies an updated
firmware image to the secondary partition and commits both partitions of the CP to an updated
version of the firmware. This must be done after each firmware download and after the switch has
been rebooted and a sanity check is performed to make sure the new image is fine

The default behavior of the firmwareDownload command is to automatically run the
firmwareCommit command after the reboot. If you decide to disable the autocommit option when
running firmwareDownload, after the CP is rebooted, you must execute one of two commands:
• firmwareCommit copies the primary partition (with new firmware) to the secondary and
commits the new firmware to both partitions of the CP.

The only difference between those 2 switches is that (sw0101 is sending traps as expected)

sw0101:y> firmwaredownloadstatus
: Mon Dec 14 16:17:52 2009
Firmware is being downloaded to the switch. This step may take up to 30 minutes.

: Mon Dec 14 16:22:12 2009
Firmware has been downloaded to the secondary partition of the switch.

: Mon Dec 14 16:23:52 2009
The firmware commit operation has started. This may take up to 10 minutes.

: Mon Dec 14 16:25:22 2009
The commit operation has completed successfully.

: Mon Dec 14 16:25:22 2009
Firmwaredownload command has completed successfully. Use firmwareshow to verify the firmware versions.

sw0101:y> firmwareshow
Appl     Primary/Secondary Versions
------------------------------------------
FOS      v6.1.1b
         v6.1.1b
sw0101:y>

sw0102 is sending flood of traps... it was not upgraded earlier ?

sw0102:y> firmwaredownloadstatus
sw0102:y> firmwareshow
Appl     Primary/Secondary Versions
------------------------------------------
FOS      v6.1.1b
         v6.1.1b
sw0102:y>

So, why PDM daemon (pdmd) is trying to replicate configuration every 3 minutes on both ?

Did also this:

sw0102:root> cat /var/run/pdmd.0.pid
1764
sw0102:root> ps -ef | grep 1764
root      1764  1739  0  2009 ?        00:02:12 superd SWBD66 XLO
root     26235 26070  0 11:39 pts/0    00:00:00 grep 1764
sw0102:root>

sw0102:root> ls -l /proc/1764/fd/
total 28
lr-x------   1 root     root           64 Oct 24 14:22 0 -> /dev/null
lrwx------   1 root     root           64 Oct 24 14:22 1 -> /dev/console
lrwx------   1 root     root           64 Oct 24 14:22 10 -> /dev/swd
lrwx------   1 root     root           64 Oct 24 14:22 11 -> /tmp/.ipc0PDMIPC|
lrwx------   1 root     root           64 Oct 24 14:22 12 -> /dev/fabsys
lrwx------   1 root     root           64 Oct 24 14:22 13 -> /etc/fabos/hil_wwn*
lrwx------   1 root     root           64 Oct 24 14:22 14 -> /dev/switch0
lrwx------   1 root     root           64 Oct 24 14:22 15 -> /dev/portlog
l-wx------   1 root     root           64 Oct 24 14:22 16 -> /tmp/.ipc0EMIPC|
lrwx------   1 root     root           64 Oct 24 14:22 17 -> /dev/portlog
l-wx------   1 root     root           64 Oct 24 14:22 18 -> /tmp/.ipc0TRACKIPC|
l-wx------   1 root     root           64 Oct 24 14:22 19 -> /tmp/.ipc0ISWIPC|
lrwx------   1 root     root           64 Oct 24 14:22 2 -> /dev/console
l-wx------   1 root     root           64 Oct 24 14:22 20 -> /tmp/.ipc0FICUIPC|
l-wx------   1 root     root           64 Oct 24 14:22 21 -> /tmp/.ipc26410cfg_ipc (deleted)
l-wx------   1 root     root           64 Mar  3 11:50 22 -> /tmp/.ipc26796cfg_ipc (deleted)
l-wx------   1 root     root           64 Mar  3 11:50 23 -> /tmp/.ipc0SNMPIPC|
l-wx------   1 root     root           64 Mar  3 11:50 24 -> /tmp/.ipc27486cfg_ipc (deleted)
l-wx------   1 root     root           64 Mar  3 11:50 25 -> /tmp/.ipc26578cfg_ipc (deleted)
l-wx------   1 root     root           64 Mar  3 11:50 26 -> /tmp/.ipc0ZNIPC|
l-wx------   1 root     root           64 Mar  3 11:50 27 -> /tmp/.ipc21859cfg_ipc (deleted)
lrwx------   1 root     root           64 Oct 24 14:22 3 -> /dev/ham
lrwx------   1 root     root           64 Oct 24 14:22 4 -> /dev/trace
lrwx------   1 root     root           64 Oct 24 14:22 5 -> /dev/raslog
lrwx------   1 root     root           64 Oct 24 14:22 6 -> /tmp/.ipcdb
lr-x------   1 root     root           64 Oct 24 14:22 7 -> /dev/platform
lrwx------   1 root     root           64 Oct 24 14:22 8 -> /dev/fssd
lrwx------   1 root     root           64 Oct 24 14:22 9 -> /dev/portlog
sw0102:root>

Any clue?

[Anonymous]

It is similiar to DEFECT000078456 (but it was fixed in 5.x?? ) And those are Brocade 5100.

[Anonymous]

This same thing is happening to my Brocade 48000s running FOS v5.3.1a.

Was there any resolution to your issue ??