Поддержите жизнь в роутере, что это такое

Обновлено: 21.11.2024

В этом разделе описывается, как включить в Gorouter поддержку соединений проверки активности с серверными частями, а также рекомендации по настройке.

Включить Keep-Alive подключения от Gorouter к внутренним серверам

По умолчанию поддержка соединений проверки активности с серверными частями отключена. Оператор может включить эту функцию, задав ненулевое значение для свойства манифеста router.max_idle_connections .

Соображения по настройке максимального количества неактивных соединений для поддержания активности

Каждый процесс Gorouter ограничен 100 000 файловых дескрипторов. Каждый входящий запрос использует не более двух файловых дескрипторов: один для подключения от клиента и один от Gorouter к серверной части. По этой причине рекомендуемое Cloud Foundry максимальное количество незанятых подключений составляет 50 000 или меньше. Поскольку при нормальной работе процесс потребляет несколько других файловых дескрипторов, это ограничение больше похоже на 49 900.

Чтобы определить, сколько неиспользуемых подключений необходимо, учтите, что пиковые подключения можно рассчитать, умножив пропускную способность на время отклика. Например, если один Gorouter получает 1000 запросов в секунду, а время ответа составляет 1 секунду, в любой момент времени, вероятно, будет 1000 открытых соединений с серверными частями. Учитывая двукратный рост, оператор может настроить не более 2000 незанятых подключений на каждый Gorouter.

Гороутер был жестко закодирован с ограничением в 100 неактивных подключений на серверную часть. Настраиваемое свойство max_idle_connections управляет бездействующими соединениями во всех серверных частях.

Вопросы для приложений при включении Keep-Alive Connections

Примечание. При включенной поддержке активности Gorouter закрывает незанятые соединения через 90 секунд. Вы должны настроить серверы приложений с тайм-аутом простоя поддержания активности, превышающим 90 секунд, чтобы убедиться, что Gorouter всегда первым закрывает соединения. Тайм-аут простоя для проверки активности сервера приложений зависит от языка, и часто необходимо изменить значение по умолчанию, чтобы оно соответствовало этому требованию.

В этом документе описываются различные механизмы поддержания активности в Cisco IOS®.

Справочная информация

Сообщения Keepalive отправляются одним сетевым устройством через физический или виртуальный канал, чтобы сообщить другому сетевому устройству, что канал между ними все еще функционирует. Для работы Keepalive необходимы два важных фактора:

Интервал проверки активности — это период времени между каждым сообщением проверки активности, отправляемым сетевым устройством. Это всегда можно настроить.
Количество повторных попыток проверки активности — это количество попыток, которые устройство продолжает отправлять пакеты проверки активности без ответа, прежде чем состояние изменится на «отключено». Для некоторых типов сообщений поддержки активности это можно настроить, а для других существует значение по умолчанию, которое нельзя изменить.

Механизмы проверки активности интерфейса

Интерфейсы Ethernet

На широковещательных носителях, таких как Ethernet, поддержка активности несколько уникальна. Поскольку в сети Ethernet существует множество возможных соседей, функция проверки активности не предназначена для определения доступности пути к какому-либо конкретному соседу в проводной сети. Он предназначен только для проверки того, что локальная система имеет доступ для чтения и записи к самому кабелю Ethernet. Маршрутизатор формирует пакет Ethernet с собой в качестве MAC-адреса источника и получателя и специальным кодом типа Ethernet 0x9000. Аппаратное обеспечение Ethernet отправляет этот пакет по проводу Ethernet, а затем немедленно получает этот пакет обратно. Это проверяет передающее и принимающее оборудование на адаптере Ethernet и базовую целостность провода.

Последовательные интерфейсы

Последовательные интерфейсы могут иметь различные типы инкапсуляции, и каждый тип инкапсуляции определяет тип используемых пакетов проверки активности.

Введите команду keepalive в режиме конфигурации интерфейса, чтобы установить частоту, с которой маршрутизатор отправляет пакеты ECHOREQ своему партнеру:

Чтобы восстановить в системе интервал проверки активности по умолчанию, равный 10 секундам, введите команду keepalive с ключевым словом no.
Чтобы отключить поддержку активности, введите команду отключения поддержки активности.

Примечание. Команда keepalive применяется к последовательным интерфейсам, использующим высокоуровневое управление каналом передачи данных (HDLC) или инкапсуляцию PPP. Он не применяется к последовательным интерфейсам, использующим инкапсуляцию Frame Relay.

Примечание. Для типов инкапсуляции PPP и HDLC нулевое значение проверки активности отключает поддержку активности и сообщается в выходных данных команды show running-config как отключена поддержка активности.

Проверки активности HDLC

Еще один известный механизм проверки активности — это последовательная поддержка активности для HDLC. Последовательные сообщения поддержки активности передаются туда и обратно между двумя маршрутизаторами, и сообщения проверки активности подтверждаются.Используя порядковые номера для отслеживания каждой проверки активности, каждое устройство может подтвердить, получил ли его одноранговый узел HDLC отправленную им поддержку активности. Для инкапсуляции HDLC три игнорируемых сообщения поддержки активности приводят к отключению интерфейса.

Включите команду отладки последовательного интерфейса для соединения HDLC, чтобы пользователь мог видеть создаваемые и отправляемые сообщения проверки активности:

Keepalive HDLC состоит из трех частей, чтобы определить, что он работает:

"myseq", который является нашим собственным возрастающим числом.
"MineSeen", который на самом деле является подтверждением другой стороны (увеличенным), в котором говорится, что они ожидают от нас этого числа.
То, что вы видели, означает наше признание другой стороне.

Примечание. Когда разница в значениях полей myseq и mineseen превышает три на маршрутизаторе 2, линия отключается, а интерфейс сбрасывается.

Поскольку сообщения проверки активности HDLC являются сообщениями проверки активности типа ECHOREQ, важна частота сообщений проверки активности, и рекомендуется, чтобы они точно совпадали с обеих сторон. Если таймеры не синхронизированы, порядковые номера начинают выходить из строя. Например, если вы установите одну сторону на 10 секунд, а другую на 25 секунд, это все равно позволит интерфейсу оставаться активным до тех пор, пока разница в частоте не будет достаточной, чтобы вызвать отклонение порядковых номеров с разницей в три. .

В качестве иллюстрации того, как работает поддержка активности HDLC, маршрутизатор 1 и маршрутизатор 2 напрямую подключены через Serial0/0 и Serial2/0 соответственно. Чтобы проиллюстрировать, как сбойные сообщения поддержки активности HDCL используются для отслеживания состояний интерфейса, Serial 0/0 будет отключен на маршрутизаторе 1.

Маршрутизатор 1

Маршрутизатор 2

Поддержка активности PPP

Проверки активности PPP немного отличаются от проверок активности HDLC. В отличие от HDLC, поддержка активности PPP больше похожа на эхо-запросы. Обе стороны могут пинговать друг друга на досуге. Правильный согласованный ход - ВСЕГДА отвечать на этот "пинг". Таким образом, для поддержки активности PPP частота или значение таймера имеют значение только локально и не влияют на другую сторону. Даже если одна сторона отключит поддержку активности, она все равно будет ОТВЕЧАТЬ на эти эхо-запросы со стороны, у которой есть таймер проверки активности. Однако он никогда не будет инициировать что-то свое.

Включите команду debug ppp packet для соединения PPP, чтобы пользователь мог видеть отправляемые сообщения проверки активности PPP:

и полученные ответы:

Сообщения поддержки активности PPP состоят из трех частей:

Идентификационный номер — используется для определения того, на какой ECHOREQ отвечает партнер.
Тип проверки активности: ECHOREQ – это сообщения поддержки активности, отправляемые исходным устройством, а ECHOREP – ответы, отправляемые одноранговым узлом.
Магические числа — уведомления включают магические числа как сервера, так и удаленного клиента. Узел проверяет магический номер в пакете LCP Echo-Request и передает соответствующий пакет LCP Echo-Reply, содержащий магический номер, согласованный маршрутизатором.

Для инкапсуляции PPP пять проигнорированных сообщений поддержки активности приводят к отключению интерфейса

Туннельные интерфейсы GRE

Механизм поддержания активности туннеля GRE немного отличается от механизма для Ethernet или последовательных интерфейсов. Это дает возможность одной стороне создавать и получать пакеты проверки активности на удаленный маршрутизатор и от него, даже если удаленный маршрутизатор не поддерживает поддержку активности GRE. Поскольку GRE представляет собой механизм туннелирования пакетов для туннелирования IP внутри IP, пакет туннеля IP GRE может быть встроен в другой пакет туннеля IP GRE. Для поддержки активности GRE отправитель предварительно создает ответный пакет проверки активности внутри исходного пакета запроса проверки активности, так что удаленному концу нужно только выполнить стандартную декапсуляцию GRE внешнего IP-заголовка GRE, а затем переслать внутренний пакет IP GRE. Этот механизм заставляет ответ проверки активности перенаправлять физический интерфейс, а не туннельный интерфейс. Дополнительные сведения о работе протоколов проверки активности туннеля GRE см. в разделе Как работают протоколы поддержки активности GRE.

Криптовалюты Keepalives

Поддержка активности IKE

Проверки активности Internet Key Exchange (IKE) — это механизм, используемый для определения того, работает ли одноранговый узел VPN и может ли он получать зашифрованный трафик. В дополнение к сообщениям поддержки активности интерфейса требуются отдельные криптоподдержки, поскольку одноранговые узлы VPN, как правило, никогда не подключаются друг к другу, поэтому сообщения поддержания активности интерфейса не предоставляют достаточной информации о состоянии однорангового узла VPN.

На устройствах Cisco IOS поддержка активности IKE активируется с помощью проприетарного метода, который называется Обнаружение мертвых узлов (DPD). Чтобы разрешить шлюзу отправлять DPD партнеру, введите эту команду в режиме глобальной конфигурации:

Чтобы отключить поддержку активности, используйте форму "нет" этой команды. Дополнительные сведения о том, что делает каждое ключевое слово в этой команде, см. в разделе Crypto isakmp keepalive.Для большей детализации пакеты поддержки активности также можно настроить в профиле ISAKMP. Дополнительные сведения см. в разделе Обзор профиля ISAKMP [Cisco IOS IPsec].

Поддержка активности NAT

В случаях, когда один узел VPN находится за трансляцией сетевых адресов (NAT), для шифрования используется NAT-Traversal. Однако в периоды простоя возможно истечение времени ожидания записи NAT на вышестоящем устройстве. Это может вызвать проблемы, когда вы запускаете туннель, а NAT не является двунаправленным. Поддержка активности NAT включена, чтобы поддерживать динамическое сопоставление NAT во время соединения между двумя одноранговыми узлами. Подтверждения активности NAT представляют собой пакеты UDP с незашифрованной полезной нагрузкой в один байт. Хотя текущая реализация DPD похожа на поддержку активности NAT, есть небольшая разница: DPD используется для определения статуса однорангового узла, а проверки активности NAT отправляются, если объект IPsec не отправлял или не получал пакет в указанный период времени. Допустимый диапазон: от 5 до 3600 секунд.

Совет. Если поддержка активности NAT включена (с помощью команды crypto isamkp nat keepalive), пользователи должны убедиться, что значение бездействия короче, чем время истечения срока действия сопоставления NAT, равное 20 секундам.

Чтобы понять, что делает протокол TCP Keepalive (который мы будем называть просто Keepalive), вам нужно всего лишь прочитать его название: Keep Alive TCP. Это означает, что вы сможете проверить подключенный сокет (также известный как сокеты TCP) и определить, работает ли соединение по-прежнему или оно разорвано.

Концепция проверки активности очень проста: при настройке TCP-соединения вы связываете набор таймеров. Некоторые из этих таймеров связаны с процедурой поддержания активности. Когда таймер проверки активности достигает нуля, вы отправляете своему узлу тестовый пакет проверки активности без данных и включенным флагом ACK. Вы можете сделать это из-за спецификаций TCP/IP, как своего рода дубликат ACK, и удаленная конечная точка не будет иметь аргументов, поскольку TCP является потоково-ориентированным протоколом. С другой стороны, вы получите ответ от удаленного хоста (который вообще не должен поддерживать поддержку активности, только TCP/IP) без данных и с набором ACK.

Если вы получили ответ на запрос проверки активности, вы можете утверждать, что соединение все еще установлено и работает, не беспокоясь о реализации на уровне пользователя. На самом деле TCP позволяет вам обрабатывать потоки, а не пакеты, поэтому пакет данных нулевой длины не опасен для пользовательской программы.

Эта процедура полезна, потому что, если другие одноранговые узлы теряют соединение (например, при перезагрузке), вы заметите, что соединение разорвано, даже если на нем нет трафика. Если партнер не отвечает на проверки активности, вы можете заявить, что соединение нельзя считать действительным, а затем предпринять правильные действия.

Вы можете вполне счастливо жить без поддержки активности, поэтому, если вы читаете это, возможно, вы пытаетесь понять, является ли поддержка активности возможным решением ваших проблем. Либо так, либо у вас действительно больше нет ничего интересного, и это тоже нормально. :)

Keepalive неинвазивен, и в большинстве случаев, если вы сомневаетесь, вы можете включить его, не рискуя сделать что-то не так. Но помните, что это создает дополнительный сетевой трафик, который может повлиять на маршрутизаторы и брандмауэры.

Короче говоря, используйте свой мозг и будьте осторожны.

В следующем разделе мы проведем различие между двумя целевыми задачами для проверки активности:

Проверка мертвых узлов

Предотвращение отключения из-за отсутствия активности в сети

Keepalive можно использовать, чтобы сообщать вам, когда ваш одноранговый узел умирает, прежде чем он сможет уведомить вас. Это могло произойти по нескольким причинам, таким как паника ядра или резкое завершение процесса, обрабатывающего этот одноранговый узел. Другой сценарий, который иллюстрирует, когда вам нужно поддерживать активность для обнаружения смерти однорангового узла, — это когда одноранговый узел все еще жив, но сетевой канал между ним и вами вышел из строя. В этом сценарии, если сеть снова не заработает, вы получите эквивалент смерти однорангового узла. Это одна из тех ситуаций, когда обычные операции TCP бесполезны для проверки состояния соединения.

Представьте себе простое соединение TCP между узлом A и узлом B: есть начальное трехстороннее рукопожатие с одним сегментом SYN от A к B, обратным SYN/ACK от B к A и окончательным ACK от A. к B. В это время мы находимся в стабильном состоянии: соединение установлено, и теперь мы обычно ждем, пока кто-то отправит данные по каналу. И здесь возникает проблема: отключите источник питания от B, и он мгновенно отключится, не посылая ничего по сети, чтобы уведомить A о том, что соединение будет разорвано. А со своей стороны готов к приему данных и понятия не имеет о том, что Б потерпел крах. Теперь восстановите подачу питания на B и дождитесь перезагрузки системы. Теперь A и B снова вернулись, но, хотя A знает о все еще активном соединении с B, B не имеет ни малейшего представления.Ситуация разрешается сама собой, когда A пытается отправить данные B через разорванное соединение, а B отвечает пакетом RST, в результате чего A наконец закрывает соединение.

Keepalive может сообщить вам, когда другой одноранговый узел становится недоступным, без риска ложных срабатываний. На самом деле, если проблема связана с сетью между двумя одноранговыми узлами, действие проверки активности состоит в том, чтобы подождать некоторое время, а затем повторить попытку, отправив пакет проверки активности, прежде чем пометить соединение как разорванное.

_____ _____ | | | | | А | | Б | |_____| |_____| ^ ^ |--->--->--->--------------- SYN -------------->--->- -->---| |--- --->--->-------------- ACK -------------->--->---> ---| | | | системный сбой ---> X | | перезагрузка системы ---> ^ | | |--->--->--->-------------- ПШ -------------->--->--- >---| |---

Еще одна полезная цель проверки активности – предотвратить отключение канала из-за бездействия. Это очень распространенная проблема, когда вы находитесь за прокси-сервером NAT или брандмауэром, и вас отключают без причины. Такое поведение вызвано процедурами отслеживания соединений, реализованными в прокси-серверах и брандмауэрах, которые отслеживают все соединения, проходящие через них. Из-за физических ограничений этих машин они могут хранить только конечное число соединений в своей памяти. Наиболее распространенная и логичная политика — сохранять самые новые подключения и в первую очередь отбрасывать старые и неактивные подключения.

Вернувшись к узлам A и B, повторно подключите их. Как только канал открыт, подождите, пока не произойдет событие, а затем сообщите об этом другому узлу. Что, если событие подтверждается через длительный период времени? Наше соединение имеет свою область действия, но прокси-серверу она неизвестна. Поэтому, когда мы, наконец, отправляем данные, прокси-сервер не может правильно их обработать, и соединение разрывается.

Поскольку обычная реализация помещает соединение в начало списка, когда приходит один из его пакетов, и выбирает последнее соединение в очереди, когда необходимо удалить запись, периодическая отправка пакетов по сети — это хороший способ всегда быть в полярной позиции с незначительным риском удаления.

Поддержка активности NAT может оказать большое влияние на вашу телефонную систему VoIP. Вот что может сделать эта функция, а также некоторые распространенные проблемы с телефоном, которые она может решить.

Иногда возникают необъяснимые проблемы с вашим настольным телефоном. Входящие вызовы не проходят или, возможно, звонки поступают прямо на голосовую почту. Все эти проблемы могут возникнуть из-за тайм-аута соединения между вашим телефоном VoIP и вашей локальной сетью. Один из способов решить эту проблему — включить и настроить функцию телефона, которая называется NAT keepalive.

Распространенные проблемы с VoIP-телефонами для бизнеса

Существует множество проблем с телефонной связью, которые могут серьезно нарушить работу бизнеса. К ним относятся:

Сброшенные звонки
Входящие вызовы перенаправляются прямо на голосовую почту.
Принимаются только некоторые входящие звонки, но не все.
Входящие вызовы без ответа
Входящие вызовы, которые автоматически завершаются сбоем

Вызовы, которые автоматически терпят неудачу, и вызовы, которые не звонят, являются классическими признаками того, что трафик входящих вызовов никогда не доходил до VoIP-телефона. Поддержка активности NAT служит потенциальным решением подобных проблем.

Что такое NAT Keepalive?

Трансляция сетевых адресов (NAT) и порты маршрутизатора

Каждому устройству (компьютерам, служебным телефонам, мобильным телефонам и планшетам) в локальной сети назначается внутренний IP-адрес. В дополнение к IP-адресам устройствам также назначается так называемый «порт» или канал в Интернет.

Когда устройство хочет подключиться к Интернету, маршрутизатор должен "преобразовать" внутренний IP-адрес устройства в общедоступный IP-адрес. Этот процесс преобразования называется преобразованием сетевых адресов (NAT).

NAT также используется для преобразования портов. Если два или более устройств пытаются использовать один и тот же порт, NAT использует прокси-порт для вторичного устройства. Маршрутизатор отслеживает все эти преобразования с помощью так называемой таблицы NAT.

Регистрация VoIP-телефона и поддержка NAT

Когда вы регистрируете телефон VoIP в службе VoIP, телефон VoIP передает свой IP-адрес/порт в службу VoIP.Затем служба VoIP отправляет все вызовы на это устройство и с него через зарегистрированный IP-адрес/порт. После регистрации телефона служба VoIP будет считать, что IP-адрес/порт телефона остается прежним, если телефон не зарегистрирован с другой конфигурацией.

В целях безопасности маршрутизаторы обычно закрывают порты, которые кажутся бездействующими. Если маршрутизатор ошибочно закрывает порт, который использует телефон VoIP, служба VoIP, не зная об изменении, продолжит отправлять вызовы на этот закрытый порт. Это приводит к сброшенным и прерванным звонкам.

Проверка активности NAT — это функция, которая отправляет очень маленькие пакеты данных, называемые пакетами UDP, с телефона VoIP на маршрутизатор, чтобы показать, что порт все еще используется. Телефон будет отправлять эти небольшие пакеты через временные интервалы, установленные вашим телефоном или вашей телефонной системой. Пакеты UDP незначительны и не влияют на пропускную способность, поэтому они не окажут никакого влияния на качество связи.

Когда телефон зарегистрирован в службе VoIP, он будет периодически проходить процесс регистрации на прокси-сервере. Как часто это происходит, полностью настраивается, но не редкость — раз в час. Однако срок действия большинства таблиц NAT истекает в течение 60 секунд, поэтому поддержка активности NAT позволяет телефонным портам оставаться открытыми, отправляя пакет UDP каждые 25–50 секунд.

NAT Keepalive: поддержание активности телефонов

Если вы боретесь с пропущенными вызовами, автоматическими сбоями, отсутствием входящих вызовов или другими проблемами, которые внезапно прерывают ваше соединение с другой стороной, вам может потребоваться включить поддержку активности NAT на вашем телефоне. Эта небольшая, но полезная функция помогает держать порты, используемые вашими VoIP-телефонами, открытыми в вашей локальной сети.

Однако не все проблемы с качеством связи можно решить, включив поддержку активности NAT. Проблемы могут возникнуть из-за сбоев в работе оборудования, изменений в конфигурации сети, плохого интернет-соединения и других проблем. Чтобы получить дополнительные советы по устранению неполадок, ознакомьтесь с нашим блогом о том, что делать в случае сбоя службы VoIP.

Читайте также: