AT&T U-verse IRC, SSH и т. Д. Удаление сеансов
AT&T U-verse волокно 24 Мбит вниз / 3 Мбит вверх
2-проводной маршрутизатор, модель 3800HGV-B
Версия программного обеспечения 6.1.9.24-enh.tm
Наша скорость как рекламируется. Интернет-соединение AT & T быстрое. Проблема не в скорости.
Проблема в том, что наши сеансы IRC и SSH с удаленными хостами в общедоступном интернете не длятся не более нескольких секунд или максимум нескольких минут. Время ожидания сеанса TCP на 2Wire настроено на 86400. Сеансы SSH с серверами в нашей локальной сети ведут себя как положено. Наша ЛВС не является проблемой. Похоже, проблема в маршрутизаторе 2Wire. Я не могу получить оболочку на маршрутизаторе 2Wire, поэтому не могу запустить там tcpdump и т. Д. Tcpdump в локальной сети показывает нам, что каждое прерывание сеанса вызвано сбросом TCP, инициированным удаленным сервером. Из моего поискового запроса я понимаю, что сброс TCP отправляется, потому что удаленный хост решил, что что-то пошло не так с сеансом TCP, что снова заставляет меня задуматься о том, что происходит на маршрутизаторе 2Wire. Сеансы IRC и SSH на этих же удаленных серверах из других интернет-соединений многих типов, с помощью мобильного модема, кабеля Time Warner, нашего T1 в другом офисе и т. Д. Ведут себя, как и ожидалось, без проблем.
Все это работало нормально, пока мы не переключились на AT & T и не начали использовать 2Wire. Все время у нас было AT&T, 2 недели, у нас была эта проблема.
В часы пик в нашем офисе у нас есть около 50 устройств, ноутбуков, настольных компьютеров, мобильных устройств, использующих это интернет-соединение. В нашей локальной сети я пробовал несколько известных (с другими провайдерами) работающих управляемых коммутаторов среди прочего. Я пытался подключить всех только к беспроводному SSID 2Wire и т. Д. Ни одна из этих попыток изолировать проблему не изменила проблему, которая, по-видимому, указывает на маршрутизатор 2Wire.
В целом, когда в офисе очень мало людей, наши сеансы IRC и SSH будут работать дольше, более нескольких минут. Иногда сеансы по-прежнему падают через 5 секунд, но иногда я могу держать один открытым в течение 10 или более минут, если я один в офисе.
Если проблема в маршрутизаторе 2Wire, я не уверен, что это такое и как его решить. Я также не уверен, как даже устранить неполадки и выяснить, что это такое.
Выходные данные tcpdump перехвачены в нашей локальной сети после завершения сеанса 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 одновременных сеанса.
Кроме того, поиск в поиске "таблицы перегиба" дал мне несколько полезных результатов поиска.
2 ответа
Будучи частным устройством, моя первоначальная инстинктивная реакция заключалась в том, что он не может поддерживать все одновременные TCP-соединения и трансляции NAT, которые в него брошены (и подделывать пакеты сброса для тех, которые превышают лимит).
Мне трудно найти технические характеристики этого устройства, чтобы подтвердить мои подозрения, но при их поиске, кажется, есть много неподтвержденных доказательств в поддержку этой теории.
Есть ли способ проверить, сколько соединений он работает?
Вы честно рассмотрели свои проблемы с помощью устранения неполадок. Я бы позвонил в ATT и попросил их выполнить диагностику соединения, сосредоточившись на проблемах уровня 1 и уровня 2. У вас есть доступ к шлюзу? Предоставляет ли он какую-либо диагностику для устранения неполадок?
Я знаю, что это другая технология, но когда я иногда поддерживал DSL, если клиент находился слишком далеко от DSLAM и имел проблему с проводкой, вызвавшую затухание, вы могли увидеть нечто подобное. Я бы начал там у шлюза (подключил прямо к нему, без беспроводной связи!) И поработал бы. Если это линия бизнес-класса, ATT должна быть в состоянии устранить неисправность всех вас из своей передовой команды вплоть до NOC и посмотреть, есть ли проблема.