We had been experiencing on again, off again, connectivity errors in our test lab. Sometimes, there wasn't even any load placed on the system when the error occurred. However, the two systems under test that experienced the connectivity issues where BizTalk Server 2006 Enterprise Edition and J.D. Edwards 8.11 with 8.96 tools - I don't remember the exact rev at the moment.
- Connectivity loss for BizTalk would generally show up as a 'General Network Error' (GNE) in the Windows event log while trying to talk to any of the BizTalk databases: EntSSO, BizTalkMsgBoxDb and BizTalkDtaDb.
- Connectivity loss for J.D. Edwards would occur with the message in the log file stating 'Communication Link Error'. Then there would be a cycle of messages as the application re-establishing a connection to the database.
Of course, the SQL Server did not report any connectivity loss, because we believe the connection was never actually established.
In a complete moment of 'doh!' I remembered the TCP/IP registry key SynAttackProtect. We applied it to the lab environment and things have seemed to settled down. However, since I do not have a netmon trace of when the error actually occurred, I couldn't say if the conditions we experienced were indicative of the server refusing connections through a reset, or what. Anyway, we are getting beyond the realm of my experience and I would need to call in our network team to analyze further. While I'm not beyond wanting to confirm, schedules may dictate otherwise...so your mileage may vary. Anyway, our current production BizTalk and Sql tiers deploy with SynAttachProtect=0, so it seemed to be inline with our build server documentation.
The default value of SynAttackProtect under Windows 2003 servers is '1'. Setting it to '0' disables the protection, something you can probably do if you are isolated from a public network.
No comments:
Post a Comment