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, инициированным удаленным сервером. Насколько я понимаю, из Google, сброс 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 одновременных сеанса.
Кроме того, поиск в Google по запросу "таблица сеансов uverse" дал мне несколько полезных результатов.
Моя первоначальная инстинктивная реакция заключалась в том, что он был обычным устройством, и поэтому он не может поддерживать все параллельные TCP-соединения и трансляции NAT, которые ему задают (и подделывают пакеты сброса для тех, которые превышают лимит).
Мне трудно найти характеристики этого устройства, чтобы подтвердить мои подозрения, но при их поиске, похоже, есть много анекдотических свидетельств, подтверждающих эту теорию.
Есть ли способ проверить, сколько подключений у него запущено?
Вы честно покрыли свои базы поиском и устранением неисправностей. Я бы позвонил в ATT и попросил их провести диагностику соединения, сосредоточив внимание на проблемах уровня 1 и уровня 2. У вас есть доступ к шлюзу? Предоставляет ли он вам какую-либо диагностику для устранения проблем?
Я знаю, что это другая технология, но когда я иногда поддерживал DSL, если клиент находился слишком далеко от DSLAM и имел проблемы с проводкой, вызывающие затухание, вы бы увидели нечто подобное. Я бы начал там со шлюза (подключайтесь прямо к нему, без беспроводной связи!) И проложил бы себе путь к выходу. Если это линия бизнес-класса, ATT должна иметь возможность устранить неполадки всех вас, начиная со своей группы обслуживания и заканчивая NOC, и посмотреть, есть ли проблема.