質問: 3wayハンドシェイクによるsyn+ackがng ■接続状況 <クライアント(1)>──<l3sw(2)>──<lb(3)>──<vpn装置(4)>──~~──> ─>──~~──<ftpサーバ(solaris)(5)> ■環境 (1):linux(red hat v5.6) (2):catalyst l3sw (3):lb(ロードバランサー:nat変換含む) (4):vpn装置 (5):対向先のftpサーバ(solaris) ■業務接続状況 5分周期のバッチで動いている。 クライアント(1)⇒対向先(5)のftpサーバに対して、ftp接続をしており ファイルのrename等を実施している。(tcp接続) ■障害状況 1ヶ月に2,3回の割合で、クライアントsvから対向先へのftp接続において ftpエラーが発生している。 ■調査状況 <各キャプチャ設定状況> (1)クライアントsvにて、tcpdump取得、i/f調査の観点でnic周り調査 (2)l3swに対しては、ミラーポートキャプチャーをしかけ、キャプチャを採取 (3)lbに対しても、対象ipアドレス、ポートを絞ってネットワークキャプチャを採取 (4)vpnに対しても、対象ipアドレス、ポートを絞ってネットワークキャプチャを採取 ftpエラー時のパケットキャプチャを見ると、3wayハンドシェイクにおける 対向先(5)からのsyn+ackがクライアントsv(1)に届いていない状況が判明。 クライアントsvからのsynに対して、対抗先のftpサーバからの応答で syn+ackがl3sw(2)から出力している(届いている)ところまでは確認済み。 途中経路のlb、vpn含め、パケットドロップ等のエラーカウントアップは されていないのも確認。 肝心のクライアントsvのnicドライバー層を確認するもパケットドロップも カウントしていない為、osとしては、受け取っていない状況。 ftpエラー時のパケットを見ると、必ずクライアントsv側で5万台の 特定ソースポートで接続するときに限って、syn+ackが届いていないことが分かった。 他のport取得時は正常にftp処理されている。 ただし、osやnw専門部署に確認するも特定portのみ、3wayハンドシェイクが 確立しないような設定や事例もないの見解を聞いており、手詰まり状態となっている。 特定のportに関しては、クライアントsvのlinux(os)が自動で採番できる port範囲からrandomで取得しているport番号なのは分かっている。 また、その特定port番号に関して、アプリ観点等で固定のport指定や、 エラー発生前に違うプロセスが掴んでしまっているような 競合もとくに見受けられなかった。(定期的に取っているnetstatコマンドより) 似たような事象に陥った方で、何か手がかりになりそうなヒントがあれば ご教授いただけると助かります。
回答: "redhat syn ack failure"で検索して一番最初にこういうのが出てきましたが... https://access.redhat.com/solutions/304073 自分はredhatのサブスクリプションを持っていないので、詳細は見られませんが。 その現象が起きるのはrhel 5.xからつないだ時だけとかだったりすると、rhelのバグという線が濃厚だと思います。