I
got an answer i am working on in the juniper board.
Looks like my guess is being substantiated somewhat…
http://forums.juniper.net/jnet/board/message?board.id=wx&thread.id=115
Hi Kevin,
This is James. Long time no speak! I’m in the escalations team now, but i watch cases from time to time.
I looked though your case. It looks like you are running any 5.5 specific features. With that in mind, a downgrade to 5.4.7 will not help as the difference between the to is the new specific featrues. Everything else uses the same modules so if you crashing due to the tCCcore tasks, you’ll still have crashes. The ATAC engineer has made an invalid recommendation to downgrade sorely on stability.
I looked into your diags and I suspect that your crashes have to due with AAP (app acceleration) flow management. Diving into the crash dumps, I was able to see that a contributer to the tCCcore crash may be due to improper flow management. Logs full of these messages back up my analysis:
E37 CCF: Invalid header: Unknown NB session msg type: 0x05: len=191 f=8:172.29.5.119:3484-172.29.204.10:1025
E37 CCF: Invalid header: Unknown NB session msg type: 0x05: len=191 f=62:172.29.5.119:3488-172.29.220.10:1025
E37 CCF: Invalid header: Unknown NB session msg type: 0x05: len=191 f=82:172.29.5.119:3509-172.29.128.10:1025
E37 CCF: Invalid header: Unknown NB session msg type: 0x05: len=191 f=62:172.29.5.119:3530-172.29.236.10:1025
The messages above mean that AAP (CIFS app acceleration) is rejecting a flow it didn’t understand and therefore have to softquit a flow in order to back out of acceleration. Your log messages are full of those. If you look at the ports of each log message, they are constantly from the ports you have defined in this user created application definition:
Active Directory: (Precedence = 20; Type = cifs; SSL Encapsulated = false)
rule 1:
Source Port: 1025,1026
rule 2:
Destination Port: 1025,1026
rule 3:
Source Port: 3268
rule 4:
Destination Port: 3268
Please take note that Type = cifs. Although Active Directory is a Microsoft function, it isn’t CIFS and therefore it is misclassified. Because the app type is defined at CIFS, the WX will ALWAYS send each flow that matches this to the AAP acceleration module, grab resourses, then realize that it is invalid and soft quit the flow.
I suspect flow managent issues in the AAP acceleration module. In fact, in the crash dumps, I see evidence that the module contributed to the tCCcore crashes:
1a9c5a PN_createProcessCCtask+12a: 1b585f ([5dd6da58, 7e296c1e, 8, 206, 0])
1b5904 pnCCInQDequeue +2e4: pnTcpAcclCCCb(PnMblk *, unsigned long, unsigned char *) (7e0f7640, 0, 7e0f7ad0, 1b5666)
3e5486 pnTcpAcclCCCb(PnMblk *, unsigned long, unsigned char *)+76 : PnAapFlowReset(PnMblk *, tpnbool) ([7e0f7640, 1, 7e0f79e0, 64c30b, 7e0f79e0])
Please remedy this misclassification from the Active Directory application definition by changing the app type to ‘default’. The flow will still benefit from AFP and it won’t be misclassified as a CIFS flow and get sent up the AAP module unnecessarily.
Regards,
–James