Что это такое?

Это механизм GRE keepalive.

Зачем это нужно?

Для контроля работоспособности туннеля.

Как это настроить?

no

Не использовать keepalive.

yes

Использовать keepalive.

По стандарту, протокол GRE не предусматривает встроенного механизма keepalive, однако у различных производителей имеются собственные реализации этого механизма. В программном обеспечении NSG Linux используется механизм, предложенный компанией Cisco Systems; подробное описание этого алгоритма приведено в документе Cisco Systems: GRE Tunnel Keepalives (Document ID: 64565) и доступно по адресу:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml

Суть данного механизма состоит в том, что на удаленную сторону посылается специально сформированный пакет GRE с инкапсулируемым протоколом IP. Внутри него, однако, находится не просто IP-пакет, а еще один GRE-пакет, имеющий адресом назначения IP-адрес системы-инициатора запроса. Такая конструкция не противоречит спецификации GRE, поскольку пакет GRE является частным случаем IP-пакета. В качестве идентификатора протокола в этом пакете указан 0, что позволяет отличить его от остальных пакетов GRE-туннеля.

Инициатор посылает запросы GRE keepalive через установленные промежутки времени. Удаленная сторона туннеля разбирает внешний пакет GRE, извлекает из него вложенный пакет и обрабатывает его в соответствии со своей таблицей маршрутизации. Поскольку этот пакет представляет собой готовый пакет GRE-туннеля, он маршрутизируется обратно инициатору. Тот, получив пакет, разбирает его заголовок, по идентификатору протокола определяет, что это не пакет с полезными данными, а ответ на keepalive, и считает запрос отвеченным.

ПРИМЕЧАНИЕ. Механизм keepalive предусмотрен только для туннелей типа IP-over-GRE.

При отключенном механизме keepalive интерфейс посылает данные в туннель "наугад", не имея никакой информации о доступности и работоспособности удаленной стороны. В этом случае реализация GRE совместима с продуктами любых других сторонних производителей. Однако, чтобы туннель не превратился в "черную дыру", для контроля целостности данных следует использовать механизмы вложенных протоколов.

ВНИМАНИЕ! Для работы механизма keepalive обязательно должен быть указан source или device.

ВНИМАНИЕ! Для работы механизма keepalive создаются служебные правила в цепочках .ip.mangle.GRE_KA и .ip.mangle.INPUT. После включения/выключения keepalive необходимо отдельно применить изменения в этом узле. Настройка данных правил пользователем не предусмотрена.

Запросы посылаются через каждые keepalive-interval секунд. В случае keepalive-retry неудачных запросов подряд интерфейс GRE переходит в состояние DOWN. При этом удаляются маршруты через этот интерфейс и др. Пакеты с данными, поступающие от удаленной стороны туннеля, сбрасываются с сообщением proto unreachable (как если бы туннеля не было вовсе).

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

Наличие потока данных (в любую сторону) никак не влияет на алгоритм поднятия и опускания туннеля, т.е. если ответы на keepalive не приходят, то интерфейс перейдет в состояние DOWN независимо от того, что данные вроде как идут.

В частности, для того, чтобы система отвечала на запросы удаленной стороны, в ней должен быть создан туннельный интерфейс, для него указано административное состояние UP и указан адрес удаленной стороны. На входящие запросы туннель отвечает всегда, даже если сам он находится в фактическом состоянии DOWN (например, из-за отсутствия ответов keepalive от удаленной стороны). Кроме того, прохождение пакетов GRE keepalive должно быть не запрещено фильтрами на обеих сторонах.

ВНИМАНИЕ! Обычные Linux-системы не поддерживают keepalive и не отвечают на него, несмотря на то, что туннели поддерживаются. Это следует из общего правила, гласящего, что система не может принимать пакеты, которые якобы исходят от неё самой (а именно такой трюк используется в данном случае).
Маршрутизаторы Cisco Systems поддерживают ответ на keepalive даже в том случае, если сами не умеют его посылать, но умеют создавать туннели.
Для продуктов других производителей возможна одна из двух вышеописанных ситуаций, в также иные фирменные реализации GRE keepalive.

Ещё одно расширение механизма keepalive относится к случаю, когда туннели идентифицируются по ключу.