Русские Блоги

Вчера меня спросили о концепции Keep-Alive в HTTP. Глядя на название, я знаю только, что оно используется для поддержания соединения, но не очень понятно, как он завершает соединение и почему он его использует. Я проверил информацию сегодня и резюмировал.

Затем я обнаружил, что существует два типа сообщений поддержки активности:

  • KeepAlive в TCP
  • Keep-Alive в HTTP

Концепция KeepAlive в TCP

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

739727-20180731111413455-342028304.png

SYN / ACK — это все сообщения TCP, и передача данных не начнется, пока соединение не будет установлено, то есть после этого будет задействована концепция запроса и ответа в HTTP. Таким образом, в модели TCP / IP (OSI) задействована концепция многоуровневости: HTTP относится к прикладному уровню, а TCP — к сетевому уровню.

Итак, что, если приложение не отправляет данные после установления TCP-соединения? Или он публикуется один раз в течение длительного времени, что делать серверу? Чтобы справиться с этой ситуацией, протокол TCP отправит пустое сообщение другой стороне через определенный период времени (может быть установлен). Если есть ответ, другая сторона будет в сети и сохранит соединение; если есть нет ответа, он повторит попытку.После определенного количества раз, подумайте, что соединение было потеряно, и его больше не нужно поддерживать.

Вышеупомянутый процесс является концепцией KeepAlive в TCP.

Keep-Alive в HTTP

Полная транзакция HTTP выглядит следующим образом:

739727-20180731111357349-1664304008.png

Транзакция включает в себя процессы установления связи / запроса / ответа / разъединения. Ранние данные передачи HTTP были в основном на основе текста. В основном все данные могут быть возвращены в одном запросе, но более поздние типы данных становятся все более и более сложными и одна ссылка может быть не работает, но каждый раз перестраивать TCP-соединение немного расточительно, поэтому в HTTP есть Keep-Alive.

Эта функция по умолчанию отключена в HTTP1.0, и вам нужно добавить «Connection: Keep-Alive» в заголовок HTTP, чтобы включить ее; HTTP 1.1 включен по умолчанию, и вы можете отключить его, если добавите «Connection» : Закрыть".

Итак, как определить, были ли переданы данные? Есть 2 способа:

  • Используйте поле Content-Length заголовка сообщения, что означает добавление длины.Если длины содержимого достаточно, передача завершена.
  • Когда нет Content-Length (когда сложно определить размер данных), вы можете использовать метод «Transfer-Encoding: chunked» для передачи данных; то есть при кодировании фрагментов данные будут передаваться фрагментами, и, наконец, используйте блок длиной 0, чтобы указать конец

Кроме того, нужно обратить внимание на:

739727-20180731111328490-1194427766.png

подводить итоги

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

Сценарий применения

Если не используется keep-alive Компонент, страница все равно будет повторно отображаться при откате страницы, вызывая created Крючок, впечатления не из лучших. Используется в следующих сценариях keep-alive Компоненты значительно улучшат пользовательский интерфейс:

  1. Щелкните продукт на странице списка продуктов, чтобы перейти к сведениям о продукте, и исходная информация будет отображаться после возврата.
  2. Список заказов переходит к деталям заказа, возврату и т. Д.

Основные настройки

MBSSID, BSSID и другие спецификации сетевой аутентификации у D-Link

  • Включить беспроводную сеть – если убрать галочку, то вай-фай перестанет работать совсем.
  • Вещать беспроводную сеть – если убрать галочку, то интернета при подключении по вай-фай не будет. Он будет только при коннекте по проводу.
  • BSSID – MAC-адрес беспроводной сети. Простому пользователю этот пункт не особо нужен.
  • Скрыть точку доступа – если убрать галочку, то она будет существовать, но станет невидимой, а подключаться к ней можно будет только, если ввести имя вручную.
  • SSID – имя вай-фай сети.
  • Страна – в разных регионах и странах есть ограничение на мощность сигнала. Данное ограничение регламентируется законом данной страны. Поэтому лучше выбрать свой регион. Говорят, в Японии самое минимальное ограничение, поэтому можно попробовать эту страну.
  • Канал – у частот 2,4 и 5 ГГц есть свои каналы, на которых работает выделенный роутер. Это нужно для того, чтобы соседские маршрутизаторы вам не мешали. Можно выбрать канал по загруженности, но лучше установить режим «Auto», в таком случае аппарат будет выбирать самый незагруженный канал автоматический при включении маршрутизатора.

MBSSID, BSSID и другие спецификации сетевой аутентификации у D-Link

  • Беспроводной режим – данная настройка нужна для того, чтобы выбрать, какие стандарты вай-фай будут использоваться. У 2,4 ГГц это B, G, N, а у 5 ГГц это обычно N, AC и в редких случаях AX. Если у вас нет старых устройств, выпущенных до 2009 года, то можно выбрать N на частоте 2,4 ГГц. Про стандарты можете почитать тут.
  • Минимальное количество клиентов – тут все и так понятно. Этот параметр показывает ограничение по подключениям к вай-фай. Можно уменьшить или увеличить эту цифру в зависимости от загруженности роутера.

Настройка PPtP (VPN) при автоматическом получении локального IP адреса (DHCP)

  1. В поле Тип соединения (Connection Type): выберите PPTP (PPTP и L2TP — туннельные протоколы типа точка-точка, позволяющие компьютеру устанавливать защищённое соединение с сервером за счёт создания специального туннеля в стандартной, незащищённой сети.)
  2. В поле MAC вводите номер вашей сетевой карты (узнать его можно в состоянии подключения по локальной сети или через командную строку «ipconfig /all»)
  3. PPP имя пользователя(PPP Username): Ваш логин из договора
  4. Пароль (Password): Ваш пароль из договора
  5. Подтверждение пароля (Confirm Password): повтор пароля
  6. Имя сервиса(Service name): — IP/Имя сервера провайдера
  7. Значение MTU — 1372
  8. Алгоритм аутентификации: Auto
  9. Keep alive — ставим галочку для постоянного подключения
  10. Сохраняем настройки кнопкой Save кнопкой Перезагрузка перезагружаем роутер.

Шаг 3 — Проверка изменений

После того, как режим Keep-Alive полностью включен, запустите еще один анализ в GTMetrix или любом другом сайте по анализу производительности. Вот результаты тестового сайта после включения режима Keep-Alive:

Также можно узнать работает ли Keep-Alive проверив header вашего HTTP. Это может быть сделано через терминал, используя следующую команду:

Часть кода Connection: keep-alive означает, что режим Keep-Alive полностью функционирует.

Во-первых, вы должны проанализировать ваш сайт с помощью таких инструментов как GTMetrix, чтобы определить включен ли режим Keep-Alive на вашем сервере. Вот результаты после анализа тестовой страницы:

gtmetrix scan keep alive

На некоторых серверах или провайдерах услуг хостинга режим Keep-Alive включен по умолчанию. Если ваши результаты выдают 100%, значит вам нет необходимости производить какие-либо действия.

Таймер keep-alive

Принцип работы этого таймера предельно прост. Если канал между клиентом и сервером пассивен некоторое время (по умолчанию 2 часа), то посылается служебное сообщение, если ответа на него не поступило, через 75 секунд (обычно) сообщение посылается повторно и так несколько раз. Если ответ получен – таймер сбрасывается, и отчёт начинается заново. Если после нескольких повторов ответа так и не поступило, то соединение разрывается. Число повторов зависит от реализации стека TCP/IP, в некоторых реализациях может изменяться, в некоторых – нет…

При использовании сокетов в Windows keep-alive сообщения по умолчанию выключены. Включить их можно с помощью функции setsockopt :

В качестве параметров в функцию передаются:

  • s – дескриптор сокета, с которым будет связано соединение;
  • level – уровень, для которого определена требуемая опция (SOL_SOCKET, IPPROTO_TCP,…);
  • optname – опция, значение которой нужно изменить;
  • optval – указатель на буфер со значением опции;
  • optlen – размер буфера optval в байтах.
Читайте также:  Компьютер не видит диск Д что делать

Для включения/выключения посылки keep-alive используется опция SO_KEEPALIVE уровня SOL_SOCKET. Параметр optval интерпретируется функцией как булево значение, для включения посылки он должен иметь значение TRUE, иначе – FALSE.

На практике нет никакого смысла ждать 2 часа до посылки keep-alive сообщения, куда интереснее более реальные интервалы времени (несколько десятков секунд или минут). Для изменения этого интервала в Winsock2 предусмотрена функция WSAIoctl :

В качестве параметров в функцию передаются:

  • s – дескриптор сокета, с которым будет связано соединение;
  • dwIoControlCode – код выполняемой операции;
  • lpvInBuffer – указатель на входной буфер;
  • cbInBuffer – размер входного буфера в байтах;
  • lpvOutBuffer – указатель на выходной буфер;
  • cbOutBuffer – размер выходного буфера;
  • lpcbBytesReturned – указатель на число байт, которые реально возвращены;
  • lpOverlapped – указатель на структуру WSAOVERLAPPED;
  • lpCompletionRoutine – указатель на функцию завершения операции;

Для изменения интервалов времени нужно передать функции структуру tcp_keepalive с кодом операции SIO_KEEPALIVE_VALS, которые определены в заголовочном файле mstcpip.h .

Поле onoff отвечает за включение/выключение посылки keep-alive сообщений. Если его значение отлично от нуля – посылка будет осуществляться, иначе – нет. Поле keepalivetime определяет интервал между посылкой сообщений при пассивном состоянии канала. Поле keepaliveinterval определяет интервал посылки сообщений, если ответ не получен. Интервалы задаются в миллисекундах. Значения интервалов имеют силу только в пределах соединения, связанного с сокетом s.

Прежде чем переходить к нестандартным способам применения, расскажу, как работает keep-alive . Процесс на самом деле прост донельзя — вместо одного запроса в соединении посылается несколько, а от сервера приходит несколько ответов. Плюсы очевидны: тратится меньше времени на установку соединения, меньше нагрузка на CPU и память. Количество запросов в одном соединении, как правило, ограничено настройками сервера (в большинстве случаев их не менее нескольких десятков). Схема установки соединения универсальна:

  1. В случае с протоколом HTTP/1.0 первый запрос должен содержать заголовок Connection: keep-alive.
    Если используется HTTP/1.1 , то такого заголовка может не быть вовсе, но некоторые серверы будут автоматически закрывать соединения, не объявленные постоянными. Также, к примеру, может помешать заголовок Expect: 100-continue. Так что рекомендуется принудительно добавлять keep-alive к каждому запросу — это поможет избежать ошибок.

Expect принудительно закрывает соединение

Хакер #196. Все о Docker

Иногда даже после корректного завершения запроса схема keep-alive не отрабатывает из-за неопределенных магических особенностей сервера и сценария, к которому обращен запрос. В таком случае может помочь принудительная инициализация соединения путем передачи в первом запросе HEAD.

Запрос HEAD запускает последовательность keep-alive

Протокол VRRP

VRRP — это аббревиатура Virtual Redundant Router Protocol. Группа физических маршрутизаторов объединяется в один виртуальный. Каждый участник группы может находиться в 3 состояниях:

  • неопределенном (initialize)
  • основном (master)
  • резервном (backup)

У всех участников группы в настройках присутствует 1 или несколько виртуальных адресов. У основного эти адреса присвоены сетевой карте, а у других — просто ждут своего часа.

Прежде всего надо сказать, что VRRP работает поверх IP, а не напрямую поверх канального уровня. Если быть точным, он использует групповой (multicast) адрес 224.0.0.18. Поскольку multicast по умолчанию не маршрутизируется, взаимодействие возможно только в пределах одной физической сети.

Это значит, что, помимо общего виртуального адреса, каждому маршрутизатору на каждом сетевом интерфейсе, где вы настраиваете VRRP, должен быть присвоен основной, с которого он будет отправлять соседям служебные пакеты.

Надо сразу сказать, что основной (служебный) адрес совсем не должен быть из одной сети с виртуальными. Если у вас недостаточно публичных адресов для тех сетевых карт, которые смотрят в интернет, вы вполне можете использовать частные адреса из RFC 1918 в качестве служебных. Ну, если настройки вашего провайдера этого не запрещают.

У каждой группы маршрутизаторов есть VRID — Virtual Router Identifier. Это просто число в диапазоне от 1 до 255. С каждой такой группой может быть ассоциирован 1 или несколько виртуальных адресов. На уровне протокола список адресов передается, но только для отладочных целей. Процесс VRRP их никак не использует, тем более что передаются они без маски подсети, так что за идентичностью настроек виртуальных адресов надо следить самому.

Группы с разным VRID друг с другом не взаимодействуют, поэтому в одной физической сети может быть любое количество независимых групп резервирования, главное — настроить.

При загрузке или первичной настройке VRRP участники группы оказываются в неопределенном состоянии (initialize) и выбирают, кому быть основным, а кому резервным. В настройках VRRP можно указать приоритет (priority) — маршрутизатор с наибольшим приоритетом выигрывает выборы.

Если приоритет у нескольких маршрутизаторов одинаковый, выигрывает тот, у кого самый большой адрес IP. Я сам стараюсь не полагаться на случай и всегда указываю приоритет явно.

Маршрутизатор, который выбрали основным, присваивает своей сетевой карте виртуальные адреса и начинает посылать остальным пакеты VRRP advertisement. Таким образом он сообщает, что еще функционирует и работоспособен.

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

Что будет, если бывший основной маршрутизатор вернется к жизни? Все зависит от опции в настройках. Если она включена, то он повторно инициирует выборы и вернет себе былую славу. Если нет, так и останется резервным.

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

Введение

ПРИМЕЧАНИЕ

В данной статье речь будет идти о реализациях стека TCP/IP в Microsoft Windows NT/2000/XP и более поздних версиях, а также реализации Windows Sockets версии 2 и более поздних.

Будучи однажды создан, канал TCP может существовать «вечно». Если клиент и сервер пассивны, то при разрыве соединения, например, при проблемах со средой передачи, сетевой атаке, крахе сервера или клиента, участники соединения (либо один из них) не подозревают о возникших проблемах. Конечно, проблема рано или поздно будет выявлена — когда клиент или сервер попытаются послать какую-то информацию.

В архитектуре клиент-сервер довольно часто встречаются реализации, в которых клиент, отправив запрос на сервер, долгое время ожидает ответа сервера. Еще более актуальная ситуация — в реализациях TCP-сервера необходимо точно знать, сколько из соединившихся клиентов реально существуют. Многие из прикладных протоколов применяют для этого «пустую операцию» (NOP), которая время от времени производится между клиентом и сервером для проверки наличия соединения. Данный подход хорош тем, что он не зависит от реализации стека TCP/IP. Есть и другой метод – таймер контроля работоспособности (keep-alive).

Шаг 2 — Включение режима Keep-Alive

Существует несколько способов включения режима Keep-Alive и их выбор зависит от вашего сервера или провайдера услуг хостинга. Вот несколько вариантов:

Вариант 1 — Редактирование файла .htaccess

Добавление данного кода в ваш файл .htaccess должно помочь включить режим Keep-Alive. Включение режима Keep-Alive через .htaccess заменит собой любые настройки сервера и включит постоянное соединение.

Этот метод должен работать на большинстве виртуальных хостингов на базе Linux. В случае, если вы не знаете где найти файл .htaccess, обратитесь к этому руководству.

Читайте также:  Что значит FYI в письме

Вариант 2 — Включение режима Keep-Alive в Apache через файл httpd.conf

Если у вас есть доступ к файлу настроек Apache, вы можете включить режим оттуда. Вот как должны выглядеть настройки:

  • KeepAlive On включает режим Keep-Alive.
  • MaxKeepAliveRequests устанавливает максимальное количество запросов для одного соединения. 50 запросов для одного соединения считается оптимальным.
  • KeepAliveTimeout определяет, как долго сервер будет ожидать запрос от клиента. Рекомендуется начать с меньших значений, таких как 5 или 10 секунд и увеличивать их по мере необходимости. Выставление слишком больших значений может увеличить нагрузку на сервер.

Если вы не можете найти файл httpd.conf, запустите следующую команду в командной строке:

Вариант 3 — Включение Keep-Alive в NGINX

В NGINX, Keep-Alive по умолчанию обычно включен. Однако в некоторых случаях он может быть выключен. Вы можете включить его используя HttpCoreModule. Найдите значение keepalive_disable, которое в большинстве случаев является причиной его отключения. Перед внесением каких-либо изменений убедитесь, что узнали причину по которой он был отключен.

Вариант 4 — Сервер Windows (IIS)

Если вы используете сервер на базе Windows, вы можете легко включить режим Keep-Alive используя командную строку.

Данная команда включит режим Keep-Alive:

На случай если вы захотите его отключить используйте эту:

Вы также можете обратиться к официальному руководству от Microsoft на эту тему.

изменение таймаутов TCP

к сожалению, поскольку TCP-соединения управляются на уровне ОС, Java не поддерживает настройку таймаутов на уровне сокета, например в java.net.Socket . Я нашел несколько попыток 3 использовать собственный интерфейс Java (JNI) для создания сокетов Java, вызывающих собственный код для настройки эти варианты, но ни один из них, по-видимому, не имеет широкого принятия или поддержки сообщества.

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

текущие настройки TCP Keep-Alive можно найти в

  • /proc/sys/net/ipv4/tcp_keepalive_time
  • /proc/sys/net/ipv4/tcp_keepalive_probes
  • /proc/sys/net/ipv4/tcp_keepalive_intvl

вы можете обновить любой из них так:

такие изменения не будут сохраняться при перезапуске. Чтобы внести постоянные изменения, используйте sysctl :

текущие настройки можно просмотреть с помощью sysctl :

обратите внимание, Mac OS X определяет keepidle и keepintvl в единицах МС в отличие от Linux, который использует секунды.

свойства можно задать с помощью sysctl который сохранит эти настройки при перезагрузке:

кроме того, вы можете добавлять их в /etc/sysctl.conf (создает файл, если он не существует).

у меня нет машины Windows для подтверждения, но вы должны найти соответствующие настройки TCP Keep-Alive в реестре at

1. См. man tcp для получения дополнительной информации.

2. Этот пакет часто называют пакетом» Keep-Alive», но в спецификации TCP это просто обычный ACK пакета. Такие приложения, как Wireshark, могут маркировать его как пакет» Keep-Alive » путем метаанализа последовательности и номеров подтверждения, которые он содержит в ссылка на предыдущие сообщения в сокете.

3. Некоторые примеры, которые я нашел в базовом поиске Google, -lucwilliams / JavaLinuxNet и flonatel/libdontdie.

вы ищете опцию сокета SO_KEEPALIVE.

на API сокета Java предоставляет» keep-alive » для приложений через setKeepAlive и getKeepAlive методы.

EDIT: SO_KEEPALIVE реализован в стеках сетевых протоколов ОС без отправки каких-либо» реальных » данных. Интервал keep-alive зависит от операционной системы и может быть настроен через параметр ядра.

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

TCP keepalive и HTTP keepalive — очень разные понятия. В TCP keepalive-это административный пакет, отправленный для обнаружения устаревшего соединения. В HTTP keepalive означает постоянное состояние соединения.

Это из спецификации TCP,

пакеты Keep-alive должны быть отправлены только тогда, когда никакие данные или пакеты подтверждения не были получены для соединения в течение интервала. Этот интервал должен быть конфигурируемым и иметь значение по умолчанию не менее двух несколько часов.

Как вы можете видеть, интервал TCP keepalive по умолчанию слишком длинный для большинства приложений. Возможно, вам придется добавить активности в свой протокол.

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

Это и другие подобные проблемы (в любом месте между двумя конечными точками) могут означать, что соединение больше не будет «работать», если вы попытаетесь отправить данные после разумного периода простоя. Тем не менее, вы не можете обнаружить это, пока вы попробовать для отправки данных.

использование keepalives оба уменьшается вероятность того, что соединение будет прервано где-то по линии, а также позволяет узнать о сломанном соединении раньше.

вот некоторая дополнительная литература по keepalive, которая объясняет это гораздо более подробно.

поскольку Java не позволяет вам контролировать фактическое время keepalive, вы можете использовать примеры для их изменения, если вы используете ядро Linux (или ОС на основе proc).

Протоколы группы FHRP (First Hop Redundancy Protocols)

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

Что за первый переход такой?. У нас есть коммутируемая среда (SW1) и есть Internet . Internet это маршрутизируемая среда . И для того чтобы перейти из коммутируемой среды , в маршрутизируемую среду для того чтобы выйти в интернет , как раз эти роутеры(R1,R2,VR — Virtual Router) обеспечивают данный переход и для того ,чтобы обеспечить отказоустойчивость этого перехода , его нужно резервировать . А потому и называется протоколы резервирования первого перехода.

И все протоколы группы FHRP будут работать в единой логике: R1 , R2 будут прикидываться VR и в случае отказа одного из маршрутизаторов, то его работу возьмет другой.

  • Forwarding Router ( FR ) — это роутер ,который данный момент активен и маршрутизирует трафик .
  • Standby Router ( SR ) — это роутер ,который стоит в резерве и ждет , когда накроется FR ,чтобы перехватите его работу на себя , в случае сбоя маршрутизатора.
  • FHRPs — это группа ,а значит пришло время познакомить вас с этими протоколами.
    • HSRP (Hot Standby Router Protocol) — Проприетарный протокол разработанный Cisco;
    • VRRP (Virtual Router Redundancy Protocol) — Свободный протокол ,сделан на основе HSRP;
    • GLBP (Gateway Load Balancing Protocol) — Проприетарный протоколCisco , обеспечивающий распределение нагрузки на несколько маршрутизаторов( шлюзов) используя 1 виртуальный адрес.
    • CARP( Common Address Redundancy Protocol) — свободный , разработан как часть OpenBSD , портирован во FreeBSD.

    Итак начнём с HSRP

    Коротко табличка с адресацией:

    Протокол HSRP рассчитан на 2 роутера, 3 это уже лишний и с этим уже справиться протокол GLBP

    Предположим ,что R3 это маршрутизатор выхода в интернет и для этого мы поднимем на нём Loopback 1 с адресом 200.200.200.200 и пропишем его в маршруте по умолчанию. Между маршрутизаторами будет настроен RIPv2 и будут анонсированы 2 классовые сети( network 10.0.0.0 и network 192.168.0.0) для простоты анонсирования маршрутов.

    R2,R0 настраивается также. А теперь по порядку , настроим HSRP:

    • Router(config)# interface fa 0/1 — переходим на интерфейс fast ethernet 0/1 (этот интерфейс смотрит в локальную сеть на коммутатор )
    • Router(config-if)# ip address 192.168.0.2 255.255.255.0 — задаем ip адрес для физического интерфейса
    • Router(config-if)# standby 1 ip 192.168.0.254 — задаем виртуальный ip адрес (который будет основным шлюзом для свитчей, смотрящих на конфигурируемый роутер). У обоих роутеров он одинаковый
    • Router(config-if)# stanby 1 priority 110 — устанавливаем приоритет данного роутера в 110 (по умолчанию приоритет 100)
    • Router(config-if)# standby 1 preempt — задаем режим приемтинга
    • Router(config-if)# standby 1 authentication md5 key-string MyPassword — задаем аутентификацию, если необходимо. Пароль будет передаваться с защитой алгоритмом хеширования md5, пароль будет MyPassword
    • R3(config-if)# standby 1 timers 100 255 — регулировка таймеров hsrp, где 100 — hello интервал в секундах (как часто посылаются пакеты hello пакеты keep-alive) и 255 — hold interval в секундах (через какой промежуток времени признавать соседа недоступным)
    • Router(config-if)# standby 1 preempt delay minimum 300 — настройка времени задержки (в секундах), через которое роутер будет становиться главным. Эта команда требуется для того,чтобы сначала отработали другие протоколы,прежде чем заработает HSRP . Пример: OSPF включенный на роутере в большой сети не успеет передать маршруты все ,а тут сразу заработает HSRP ,естественно он знать все маршруты не будет,а значить и стабильно гнать трафик тоже. Как раз время delay он будет использовать для того,чтобы дать OSPF передать все маршруты и после этого вкл HSRP.

    TRACKING

    Также полезно вешать TRACK на интерфейсы ,так как HSRP работает только в сторону ,куда направлен интерфейс ,то он не сможет отработать,когда упадут линки ,смотрящие на роутеры выше.(в данном случае это R3)

    • Router(config)# track 1 interface fa0/1 line-protocol — отслеживаем состояние интерфейса fa0/1, если он падает, то сработает объект отслеживания track 1.
    • Router(config-if)# standby 1 track 1 decrement 15 — если сработает объект отслеживания track 1, то текущий приоритет будет понижен на 15 единиц.
    • Router(config-if)# standby 1 track 1 fa0/1 20 — работает только в HSRP. Позволяет отслеживать интерфейс без дополнительного создания объекта отслеживания.

    R1,R2,R0 будут настраиваться одинаково, принцип сохраняется.

    А теперь нюансы HSRP

    При работе нескольких VLAN , HSRP может идти трафик не совсем рационально. Представим ,что R1 это root primary за 10 VLAN, а R3 это ACTIVE router в HSRP . Это значит ,что любой трафик за этот VLAN будет идти следующим образом:VPC — R3 — R1 — R4 вместо того,чтобы идти напрямую VPC — R3 — R4

    Поэтому рекомендуют использовать HSRP version 2(по умолчанию вкл 1 максимум 255 процессов,а во 2 их 4095) и использовать наилучший приоритет для того роутера, который сейчас в сети root primary за текущий VLAN. И хорошей практикой будет если номер VLAN будет совпадать с номером процесса HSRP. ( № HSRP = VLAN )

    3 Роутера в HSRP не имеет смысла держать,так как он всё равно будет в состоянии Listen и включиться только тогда,если active пропадет, standby займет его место , и только тогда он перейдет в состоянии standby.(речь идет о 3 роутере) Тоже самое будет касаться 4,5 . n роутеров.

    Бывает и другая ситуация ,когда не сам линк от R1 падает ,а устройство находящиеся за ним,к примеру SW2 упал link до R3. Проблему способен решить сервис SLA — Service Level Agreement.

    Суть его проста,он ping сервис до провайдера и если он падает ,то отрабатывает track.

    • Router(config)# ip sla 1 — создаем зонд
    • Router(config-ip-sla)# icmp-echo 215.215.215.2 source-interface e0/2 — посылаем icmp echo ping на 215.215.215.2
    • Router(config-ip-sla-echo)# frequency 10 — посылаем icmp echo ping с частотой каждые 10 секунд
    • Router(config)# ip sla schedule 1 start-time now life forever — задаем расписание работы ip sla. В данном случае зон будет запущен прямо сейчас, при этом время окончания не задано (навсегда)
    • Router(config)# track 1 ip sla 1 reachability — устанавливаем объект отслеживания на доступность того хоста, на который посылаем icmp echo ping
    • Router(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1 — направляем трафик по этому маршруту если объект трекинга track 1 работает (хост пингуется)
    • Router(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10 — если не пингуется, направляем трафик в интернет по другому маршруту (Внимание! Здесь важно задать именно плохую метрику, например 10, иначе будут работать оба маршрута! (балансировка))
    • Router# show track 1 — показать состояние объекта отслеживания

    Настройка VRRP не сильно отличается от HSRP . Настраивается он также как и HSRP, только вместо standby используется vrrp. Router(config-if)# vrrp 1 ip 192.168.1.1 — включение vrrp. Проще пройтись по отличиям ,чем заново описывать все команды.

    1. У VRRP тоже только 2 состояния Master и Backup(HSRP active и standby)
    2. Preempt включен по умолчанию (HSRP он отключен)
    3. При падении линка VRRP проводит выборы роутера(HSRP имеет запасной). Главного выбирают по IP адресу, когда проводят выборы.
    4. Поддержка Аутентификации в VRRP отсутствует (RFC отсутствует),но в Cisco она реализована(HSRP по умолчанию)
    5. VRRP по умолчанию hello таймер равен 1 секунде , dead таймер равен 3(у HSRP 3 и 10 соответственно)
    6. Виртуальный адрес может совпадать с адресом интерфейса(HSRP такой адрес не даст прописать)
    7. Использует Multicast HSRP равен 224.0.0.2 ( version 1) 224.0.0.102 (version 2) ,а VRRP 224.0.0.18
    8. Может отслеживать только объекты , а HSRP и интерфейсы , и объекты.(смотри раздел tracking)

    Сб июл 18, 2020 22:59:36

    Короче разобрался я со своим роутером)) Всё работает. Тут подсказали — https://gamedev.ru/code/forum/?id=50491&page=2

    Для проверки я взял простой роутер и посмотрел как там работает UDP (проброска портов отключена). Измерил все тайминги))

    Схема такая: сервер (10.0.0.1) — (WAN | роутер | LAN) — сервер (192.168.0.1)

    1. Из внешней сети (10.0.0.1) во внутреннюю (192.168.0.1) попасть невозможно так как порты на роутере закрыты.
    2. Из внутренней сети (192.168.0.1) во внешнюю сеть (10.0.0.1) попасть можно.))
    3. Допустим сервер (192.168.0.1) отправляет UDP пакет серверу (10.0.0.1).
    4. Роутер делает запись в таблице NAT (связка «порт == IP» ).
    5. После отправки UDP пакета роутер включает таймер примерно на 20 секунд.
    6. Если по истечении 20 секунд ответ так и не пришёл, роутер удаляет из таблицы NAT запись о сокете. После этого из внешней сети (10.0.0.1) во внутреннюю (192.168.0.1) попасть невозможно.
    7. Допустим ответ пришёл. Тогда роутер устанавливает таймер примерно на 30 секунд.

    9. При каждом новом пакете роутер автоматически устанавливает таймер примерно на 2. 3 минуты.
    10. Если пакетов больше нет, то через 2. 3 минуты срабатывает тайм-аут и роутер удаляет из таблицы NAT запись о сокете. После этого из внешней сети (10.0.0.1) во внутреннюю (192.168.0.1) попасть невозможно.
    11. При передачи пакетов порты (Source port и Destination port) роутер не меняет. Роутер меняет только IP (Source IP и Destination IP).

    12. Вывод: Для поддержания связи по UDP надо непрерывно что-то передавать. например пустые пакеты. не реже чем каждые 2. 3 минуты )) Чтоб не срабатывал тайм-аут и роутер удаляет из таблицы NAT запись о сокете.

    По сути это получается тот же самый keep-alive как в TCP. или как в браузере. или как в HTTP(S)/WebSockets.
    Пипец))

Ссылка на основную публикацию