FWSM NP Issue (np_logger_query request)

Muhammad Anser Khan · ‎01-31-2010

Dear All,

We have two Cisco 6513 switches with each one FWSM module. FWSM Working as an Active/Passive. After upgrading the FWSM software from 3.1(4) to 3.2(15). This issue has occured second time(on both modules). But we never face this issue before upgrade. Following is the issue:

Both FWSM became Active/Active and shows 'Secondary-failed'. Following are the logs we are getting from problematic FWSM:

FWSM2# show conn
ERROR: Unable to get connection information from NPs0 in use, 0 most used
Network Processor 1 connections
ERROR: np_logger_query request for Show Connections failed Network Processor 2 connections
ERROR: np_logger_query request for Show Connections failedMulticast sessions:
Network Processor 1 connections
ERROR: np_logger_query request for Show Connections failed Network Processor 2 connections
ERROR: np_logger_query request for Show Connections failedIPv6 connections:

FWSM2# clear np all stats
ERROR: np_logger_query request for clearing Slow Path Stats failedERROR: Failed to Clear Slow Path D300 Stats

ERROR: np_logger_query request for clearing Slow Path Stats failedERROR: Failed to Clear Slow Path D300 StatsERROR: np_logger_query request for clearReassemblyStats failedERROR: Failed to clear AAA uCode Stats

FWSM1# show xlate
FWSM1# np_logger_query request for Show Xlate failed

FWSM2# show np blocks
                 MAX   FREE   THRESH_0   THRESH_1   THRESH_2
NP1 (ingress) 32768 32768         0          0                0
    (egress) 521206 521206          0            0                 0
NP2 (ingress) 32768 32768          0          0                0
    (egress) 521206 521206          0            0                 0
NP3 (ingress) 32768    112     700334       12188         517
    (egress) 521206 521205          0             0               0

I have found the bug 'CSCsr94408' relating to this issue. But there is only a workaroung to reload the FWSM. I reloaded it and It solved.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsr94408

FWSM2# show np blocks
                 MAX   FREE   THRESH_0   THRESH_1   THRESH_2
NP1 (ingress) 32768 32768          0          0          0
    (egress) 521206 521204           0          0          0
NP2 (ingress) 32768 32768          0          0          0
    (egress) 521206 521206           0          0          0
NP3 (ingress) 32768 32768          0          0          0
    (egress) 521206 521206           0          0          0

And these are the 4.0(4) release notes in which this bug was fixed:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/release/notes/fwsmrn40.html#wp173021

Can anyone tell me what could be the reason behind this issue?

Regards,

Anser

Kureli Sankar · ‎01-31-2010

That defect is resolved in 4.0.3.x so, pls. upgrade to the latest FWSM code if possible.

http://www.cisco.com/cgi-bin/tablebuild.pl/cat6000-fwsm

Click on the All new releases will be available "here"

Get 4.0.8

The latest in the 3.1.x train 3.1.(17)
The latest in the 4.0 train is 4.0.8
The latest in the 3.2 train is 3.2.(14)
ASDM is asdm-615f.bin

-KS

Muhammad Anser Khan · ‎02-09-2010

Is it normal to see threshold values on the Active FWSM on specific NP like NP3 here or is this will become an issue for Active/Active problem?:

FWSM1# show np blocks
                 MAX   FREE   THRESH_0   THRESH_1   THRESH_2
NP1 (ingress) 32768 32768          0          0          0
    (egress) 521206 521206          0          0          0
NP2 (ingress) 32768 32768          0          0          0
    (egress) 521206 521206          0          0          0
NP3 (ingress) 32768 32768          0       7442     131474
    (egress) 521206 521206          0          0          0

TAC engineer has suggested me to go for 3.2(16) for the bug CSCte48563

Regards,

Anser

Kureli Sankar · ‎02-10-2010

If the NP gets stuck for any reason then an active/active situation is possible.

Yes, pls. upgrade to the code 3.2.16. TAC would like to keep the customers in the same train that they are running.

According to the defect details 3.2.15 is a likely candidate to hit the bug that you indicated. You would not have seen the issue if you were running 3.2.14 or lower.

-KS