AT&T U-verse IRC、SSH 等會話失去
AT&T U-verse 光纖 24Mbit down / 3Mbit up
2Wire 路由器型號 3800HGV-B
軟體版本 6.1.9.24-enh.tm
我們的速度和宣傳的一樣。AT&T 的網際網路連接速度很快。問題不在於速度。
問題是我們在公共網際網路上與遠端主機的 IRC 和 SSH 會話最多不會持續超過幾秒鐘或幾分鐘。2Wire 上的 TCP 會話超時配置為 86400。與我們 LAN 上的伺服器的 SSH 會話按預期執行。我們的區域網路似乎不是問題。問題出現成為2Wire路由器。我無法在 2Wire 路由器上獲取 shell，因此我無法在那裡執行 tcpdump 等。LAN 上的 Tcpdump 向我們表明，每個會話丟棄都是由遠端伺服器發起的 TCP 重置引起的。我通過Google搜尋了解到，正在發送 TCP 重置是因為遠端主機已確定 TCP 會話出現問題，這再次讓我質疑 2Wire 路由器上發生了什麼。從許多類型的其他網際網路連接、移動網路共享、時代華納電纜、我們在另一個辦公室的 T1 等到這些相同的遠端伺服器的 IRC 和 SSH 會話按預期執行，沒有任何問題。
在我們切換到 AT&T 並開始使用 2Wire 之前，所有這些都執行良好。我們有 AT&T 的整個時間，現在 2 週，我們都遇到了這個問題。
在我們辦公室的高峰時間，我們有大約 50 台設備、筆記型電腦、台式機、移動設備使用這種網際網路連接。在我們的區域網路上，我嘗試了幾種已知的（與其他提供商合作）託管交換機。我試過讓每個人都只連接到 2Wire 無線 SSID 等。這些隔離問題的嘗試都沒有改變似乎指向 2Wire 路由器的問題。
一般來說，當辦公室裡的人很少時，我們的 IRC 和 SSH 會話會保持更長時間，超過幾分鐘。有時會話仍會在 5 秒內結束，但有時如果我是辦公室裡唯一的一個，我可以保持一個打開 10 分鐘或更長時間。
如果問題是 2Wire 路由器，我不確定它是什麼或如何解決它。我也不知道如何解決它並弄清楚它是什麼。
tcpdump 輸出在我們的 LAN 上擷取的 SSH 會話丟棄，已從遠端伺服器發送 TCP 重置：
10:51:33.357748 IP (tos 0x10, ttl 63, id 11177, offset 0, flags [DF], proto TCP (6), length 52) 2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd8bb (correct), seq 3878, ack 3193, win 65535, options [nop,nop,TS val 904726345 ecr 194200103], length 0 10:51:33.357757 IP (tos 0x10, ttl 63, id 54768, offset 0, flags [DF], proto TCP (6), length 52) 2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd86b (correct), seq 3878, ack 3273, win 65535, options [nop,nop,TS val 904726345 ecr 194200103], length 0 10:51:33.456382 IP (tos 0x10, ttl 63, id 37832, offset 0, flags [DF], proto TCP (6), length 100) 2wire.ip.53096 > remote.server.ip.22: Flags [P.], seq 3878:3926, ack 3273, win 65535, options [nop,nop,TS val 904726346 ecr 194200103], length 48 10:51:33.493452 IP (tos 0x0, ttl 48, id 35965, offset 0, flags [DF], proto TCP (6), length 100) remote.server.ip.22 > 2wire.ip.53096: Flags [P.], seq 3273:3321, ack 3926, win 157, options [nop,nop,TS val 194200137 ecr 904726346], length 48 10:51:33.493757 IP (tos 0x0, ttl 48, id 35966, offset 0, flags [DF], proto TCP (6), length 132) remote.server.ip.22 > 2wire.ip.53096: Flags [P.], seq 3321:3401, ack 3926, win 157, options [nop,nop,TS val 194200137 ecr 904726346], length 80 10:51:33.494297 IP (tos 0x10, ttl 63, id 12429, offset 0, flags [DF], proto TCP (6), length 52) 2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd7e7 (correct), seq 3926, ack 3321, win 65535, options [nop,nop,TS val 904726347 ecr 194200137], length 0 10:51:33.494485 IP (tos 0x10, ttl 63, id 28130, offset 0, flags [DF], proto TCP (6), length 52) 2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd797 (correct), seq 3926, ack 3401, win 65535, options [nop,nop,TS val 904726347 ecr 194200137], length 0 10:53:04.123228 IP (tos 0x0, ttl 255, id 48599, offset 0, flags [DF], proto TCP (6), length 40) remote.server.ip.22 > 2wire.ip.53096: Flags [R.], cksum 0x9bbf (correct), seq 3401, ack 3926, win 0, length 0有沒有其他人遇到過這個問題，解決了這個問題？或者有人對故障排除、辨識和解決問題有什麼建議嗎？
更新：
首先非常感謝您閱讀這個冗長的問題和您的回复。+1
我也對 NAT 轉換錶感到懷疑，但顯然不夠懷疑。我猜到 2Wire 或任何設備都可以處理 2^16 個會話。我猜錯了：
我之前沒有在 2Wire 上看到會話表，但是根據您的建議，我去尋找它並且很容易找到：
session table 15/1024 available, 0/512 used in inbound sessions:上面的會話表詳細資訊來自下午的某個時間，當時我們辦公室可能有四分之一的人不在辦公桌前使用電腦，而我們已經接近 1024 個並發會話的限制。
Google搜尋“uverse session table”也給了我一些有用的搜尋結果。
作為一個家用設備，我最初的直覺反應是它不能支持所有並發的 TCP 連接和被拋出的 NAT 轉換（並為超過限制的那些偽造重置數據包）。
我很難在該設備上找到規格來證實我的懷疑，但在尋找它們時，似乎有很多軼事證據支持該理論。
有什麼方法可以檢查它正在執行多少個連接？
您已經誠實地進行了故障排除。我會打電話給 ATT，讓他們對連接進行診斷，重點是第 1 層和第 2 層問題。您可以訪問網關嗎？它是否為您提供任何類型的診斷以解決問題？
我知道它是一種不同的技術，但是當我支持 DSL 時，有時如果客戶端離 DSLAM 太遠並且有導致衰減的佈線問題，你會看到類似的東西。我會從網關開始（直接插入它，沒有無線！）然後走出去。如果這是一條商務艙線，ATT 應該能夠從他們的前線團隊一直到 NOC 對你們進行故障排除，看看是否有問題。