Turn on suggestions
![]() Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
|
03-03-2010 02:24 AM
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?
03-03-2010 03:54 AM
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?
03-03-2010 04:00 AM
It is similiar to DEFECT000078456 (but it was fixed in 5.x?? ) And those are Brocade 5100.
05-13-2010 07:18 AM
This same thing is happening to my Brocade 48000s running FOS v5.3.1a.
Was there any resolution to your issue ??