no keepalive cisco для чего
How GRE Keepalives Work
Available Languages
Download Options
Contents
Introduction
This document provides an overview of how Generic Routing Encapsulation (GRE) keepalives work.
Prerequisites
Requirements
Readers of this document should have knowledge of these topics:
Components Used
The information in this document is based on these software and hardware versions:
Cisco IOS® Software that supports GRE over IPSec
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Background Information
The GRE keepalive feature enables the keepalive interface command for tunnels, and allows you to configure keepalives for point-to-point GRE tunnels. You can configure keepalives with the keepalive command, and optionally with its new extension.
GRE tunnels provide a method to encapsulate arbitrary packets inside a transport protocol. They also offer an architecture designed to provide the services required to implement any standard point-to-point encapsulation scheme. Here are some of the advantages of GRE tunnels:
GRE tunnels provide multi-protocol local networks over a single-protocol backbone.
GRE tunnels provide workarounds for networks that contain protocols with limited hop counts.
GRE tunnels connect discontinuous sub-networks.
GRE tunnels allow VPNs across WANs.
However, in the current implementation of GRE tunnels, a configured tunnel does not have the ability to bring down the line protocol of either tunnel endpoint, if the far end is unreachable. Thus, the traffic sent from the tunnel is black-holed, and it cannot follow alternative paths because the tunnel always stays up.
This situation is true for tunnels that rely on static routes or on routing protocols that aggregate routes to find a route to the tunnel destination. It is also true in situations where the data in the control plane follows a different path from the data in the data plane.
The Tunnel Keepalive Mechanism
This section provides a functional description for the tunnel keepalive mechanism with the help of an example. This section also lists the software elements that this feature modifies, and discusses the impact on memory and performance.
Functional Description
The tunnel keepalive mechanism enables, extends and implements an interface-specific command for tunnel interfaces, and delivers the ability to bring down the line protocol of a tunnel. For more information, see the Commands and Configuration section.
The tunnel keepalive mechanism also addresses these additional requirements:
The tunnel keepalive mechanism functions even if the far tunnel endpoint does not support keepalives.
The tunnel keepalive mechanism originates keepalives.
The tunnel keepalive mechanism processes keepalives.
The tunnel keepalive mechanism replies to keepalive packets of the far end, even when the line protocol of the tunnel is down.
Here is an example of how the tunnel keepalive mechanism works (see Figure 1):
Figure 1 – Example for the Tunnel Keepalive Mechanism
A keepalive packet that originates from A to B
When you enable keepalives on the tunnel endpoint of Router A, the router at every interval constructs the inner IP header. At the end of the header, the router also appends a GRE header with a Protocol Type (PT) of 0, and no other payload. The router then sends that packet through the tunnel, which results in its encapsulation with the outer IP header, and a GRE header with the PT of IP. The tunnel keepalive counter increments by one. If there is a way to reach the far end tunnel endpoint, and the tunnel line protocol is not down due to other reasons, the packet arrives on Router B. It is then matched against Tunnel 0, is decapsulated, and forwarded to the destination IP, which is the tunnel source, Router A. Upon arrival on Router A, the packet is again decapsulated, and the PT is checked. If the result of the PT check is 0, it signifies that this is a keepalive packet. In such a case, the tunnel keepalive counter is reset to 0, and the packet is discarded.
In case Router B is unreachable, Router A continues to construct and send the keepalive packets along with normal traffic. If the line protocol is down, the keepalives do not come back to Router A. Therefore, the keepalive counter continues to increase. The tunnel line protocol stays up only as long as the tunnel keepalive counter remains zero, or less than a configured value. If that condition is not true, the next time you attempt to send a keepalive to Router B, the line protocol is brought down, as soon as the keepalive counter reaches the configured keepalive value. In the up/down state, the tunnel does not forward or process any traffic apart from the keepalive packets. For this to work for keepalive packets only, the tunnel must be forward-and-receive friendly. So the tunnel lookup algorithm must be successful in all cases, and must discard only the data packets if the line protocol is down. When a keepalive packet is received, it implies that the tunnel endpoint is again reachable. The tunnel keepalive counter is then reset to 0, and the line protocol comes back up.
Memory and Performance Impact
The feature places almost no additional demand on the router system memory and performance is expected to remain unaffected by its addition. Keepalive packets are treated as ordinary packets, and so it is possible that they can be dropped under high traffic conditions. For now, you can change the number of retries to deal with this issue. If this proves to be inadequate eventually, you can put locally generated keepalive packets in a high priority queue for transmission. You can then set the TOS value in the IP headers to a more suitable value, other than the default or configured value.
Packaging Considerations
The feature is included in the basic IP tunnel code and in the GRE subsystem. Therefore, it must be available with a basic IP package that has the tunnel and the GRE subsystems.
Commands and Configuration
This section addresses the keepalive command enabled and extended by this feature only under Cisco bug ID CSCuk26449. Other commands are documented in the respectiveCisco IOS Configuration Guides and Command References. The [no] keepalive period > retries > command is enabled and extended with a second parameter, and is available in Cisco IOS Software Release 12.2(8)T and later. It has also been ported under Cisco bug ID CSCuk29980 and CSCuk29983 to Cisco IOS Software Releases 12.1E and 12.2S.
As keepalive is an interface configuration command that enables keepalives on the tunnel interface, only keepalives for the GRE/IP mode are supported currently. The second parameter of the command ( retries ) is visible and available only for tunnel interfaces. Values of the first parameter can range from 1 to 32767. When the value is 0, it is equivalent to «no keepalive». This parameter has a default value of 10. The values for the second parameter can range from 1 to 255, and it indicates the number of keepalives that are sent but not returned, after which the tunnel interface pulls the line protocol down. Keepalives on tunnel interfaces are disabled by default.
Обзор механизмов поддержки активности на Cisco IOS
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
Этот документ описывает различные механизмы поддержки активности на базе Cisco IOS®.
Общие сведения
Сообщения поддержки активности передаются одним сетевым устройством через физический или виртуальный канал для информирования другого сетевого устройства о том, что между ними функционирует канал. Для обеспечения работы механизмов поддержки активности есть два существенных фактора:
Механизмы поддержки активности
Интерфейсы Ethernet
На средствах широковещания, таких как Ethernet, механизмы поддержки активности отчасти уникальны. Поскольку количество возможных соседей в Ethernet велико, сообщения поддержки активности не предусматривают определения доступности пути по кабелю к какому-то определенному соседу. Данные сообщения позволяют только выполнить проверку доступа локальной системы к кабелю Ethernet для чтения и записи. Маршрутизатор создает Ethernet-пакет, который содержит MAC-адрес источника и назначения самого маршрутизатора и специальный код Ethernet, равный 0x9000. Ethernet Оборудование отправляет этот пакет по кабелю Ethernet и затем немедленно получает этот пакет обратно. Таким образом, выполняется проверка аппаратных средств приема и передачи в адаптере Ethernet, а также проверка целостности кабеля.
Последовательные интерфейсы
Последовательные интерфейсы могут иметь различные разновидности инкапсуляции, и каждая разновидность инкапсуляции определяет тип сообщений поддержки активности, которые будут использоваться.
Введите Поддержка активности команду в режим конфигурации интерфейса для установки частоты, на которой маршрутизатор передает пакеты ECHOREQ своему равноправному узлу:
Примечание: Поддержка активности Команда применяется к последовательным интерфейсам, которые используют управление каналом передачи данных высокого уровня (HDLC) или инкапсуляцию PPP. Это не применяется к последовательным интерфейсам, которые используют инкапсуляцию Frame Relay использования.
Примечание: Для инкапсуляции HDLC и инкапсуляции PPP механизм поддержки активности нулевого уровня отключает сообщения поддержки активности и передается в выходные данные команды show running config как поддержка активности отключают.
Сообщения поддержки активности HDLC
Другой хорошо известный механизм сообщений поддержки активности — серийные сообщения для HDLC. Серийные сообщения поддержки активности пересылаются от одного маршрутизатора к другому (и обратно) и подтверждаются. С использованием порядковых номеров для отслеживания каждого сообщения поддержки активности любое устройство может подтвердить, получил ли этот узел HDLC сообщение поддержки активности, которое было отправлено. Для инкапсуляции HDLC три проигнорированных сообщения поддержки активности приводят к переключению интерфейса в нерабочее состояние.
Включите команду отлаживают последовательный интерфейс для подключения HDLC, чтобы позволить пользователю видеть сообщения поддержки активности, которые генерируются и отправляются:
Сообщения поддержки активности HDLC содержат три компонента, по которым можно определить, как этот механизм работает:
Примечание: Когда отличие значений в полях myseq и mineseen превышает три на маршрутизаторе 2, линия отключается и интерфейс сбрасывается.
Так как сообщения поддержки активности HDLC являются сообщениями типа ECHOREQ, частота сообщений поддержки активности имеет важное значение и рекомендуется, чтобы они точно совпадали на обеих сторонах. Если таймеры не синхронизированы, порядковые номера становятся беспорядочными. Например, при настройке одной стороны на 10 секунд и настройке другой стороны на 25 секунд это все еще позволит интерфейсу сохранять свое состояние, поскольку отличие по частоте недостаточно для отключения порядковых номеров из-за отличия, равного трем.
Как показано на иллюстрации того, как работают сообщения поддержки активности HDLC, маршрутизатор 1 и маршрутизатор 2 напрямую соединены через Serial0/0 и Serial2/0 соответственно. Чтобы проиллюстрировать, как неудачные сообщения поддержки активности HDCL используются для отслеживания интерфейсных состояний, последовательный порт 0/0 будет отключен на маршрутизаторе 1.
Маршрутизатор 1
Маршрутизатор 2
Сообщения поддержки активности PPP
Сообщения поддержки активности PPP немного отличаются от сообщений поддержки активности HDLC. В отличие от HDLC сообщения поддержки активности PPP больше подобны тестовым опросам. Обе стороны могут в тестовом режиме опрашивать в свое свободное время. Надлежащее согласованное перемещение должно ВСЕГДА отвечать на этот тестовый опрос. Таким образом, для сообщений поддержки активности PPP частота и значение таймера имеют только локальное значение и не оказывают никакого влияния на другой стороне. Даже если одна сторона отключает сообщения поддержки активности, то она по-прежнему ОТВЕТИТ на эти эх-запросы со стороны, на которой действительно есть таймер поддержки активности. Вместе с тем это никогда не будет инициировать ничего собственного.
Включите Пакет debug ppp команду для PPP-подключения, чтобы позволить пользователю видеть те сообщения поддержки активности PPP, которые отправлены:
и ответы, которые приняты:
Сообщения поддержки активности PPP содержат три компонента:
Для PPP инкапсуляции пять проигнорированных сообщений поддержки активности переключают интерфейс в нерабочее состояние
Туннельные GRE интерфейсы
Механизм сообщений поддержки активности туннеля GRE немного отличается от механизма Ethernet или последовательных интерфейсов. Он позволяет одной из сторон отправлять пакеты поддержки активности удаленному маршрутизатору и получать их от него даже в том случае, если удаленный маршрутизатор не поддерживает сообщения поддержки активности GRE. GRE Поскольку является механизмом туннелирования пакетов для IP-туннелирования внутри IP-протокола, пакет GRE IP-туннеля может быть создан внутри другого пакета GRE IP-туннеля. Для сообщений поддержки активности GRE отправитель предварительно создает ответный пакет внутри исходного пакета-запроса сообщения поддержки активности, таким образом, удаленной стороне необходимо только выполнить стандартную декапсуляцию GRE внешнего GRE IP-заголовка и затем передать внутренний GRE IP-пакет. Из-за особенностей данного механизма ответные сообщения поддержки активности передаются не по туннельному, а по физическому интерфейсу. Для получения дополнительной информации по работе сообщений поддержки активности туннеля GRE см. Как работают сообщения поддержки активности GRE.
Шифруемые сообщения поддержки активности
Сообщения поддержки активности IKE
Сообщения поддержки активности по протоколу обмена ключами в Интернете (IKE) являются механизмом, который используется для определения того, включен ли равноправный узел VPN и способен ли он принимать зашифрованный трафик. Отдельные шифруемыесообщения поддержки активности необходимы в качестве дополнения к сообщениям поддержки активности интерфейса, поскольку равноправные узлы VPN обычно никогда не подключены вплотную, поэтому сообщения поддержки активности интерфейса не предоставляют достаточно информации о состоянии равноправного узла VPN.
На Cisco IOS устройствах сообщения поддержки активности IKE включаются с помощью собственного метода, который называется методом обнаружения неработающих равноправных узлов (DPD). Чтобы позволить шлюзу отправлять сообщения DPD на равноправный узел, введите эту команду в режиме глобальной конфигурации:
Для отключения сообщений поддержки активности используйте эту команду в форме «no» (нет). Для получения дополнительной информации о том, какая роль возложена на каждое ключевое слово в этой команде, см. crypto isakmp keepalive. Для получения более подробной информации также могут быть настроены сообщения поддержки активности в рамках профиля ISAKMP. Для получения дополнительной информации см. Обзор профиля ISAKMP [Cisco IOS IPsec].
Сообщения поддержания соединения NAT
Для сценариев, в которых один равноправный узел VPN находится после механизма преобразования сетевых адресов (NAT), для шифрования используется протокол прохождение NAT. Тем не менее во время простоя возможно истечение времени ожидания входных данных NAT на устройстве ввода. Это может вызвать проблемы при переводе туннеля в рабочее состояние, и протокол NAT не является двунаправленным. Сообщения поддержки активности включаются для поддержания динамического сопоставления NAT во время соединения между двумя равноправными узлами. Сообщения поддержки активности NAT являются пакетами UDP с незашифрованными полезными данными объем 1 байт. Хотя текущая реализация DPD подобна сообщениям поддержки активности NAT, есть небольшое отличие — DPD используется для обнаружения состояния равноправного узла, в то время как сообщения поддержки активности NAT отправляются, если объект IPSec не передал или не получил пакет в течение указанного периода времени. Допустимый диапазон составляет 5-3600 секунд.
Совет: Если сообщения поддержки активности NAT включены (с помощью команды крипто-isamkp сообщение поддержания соединения NAT), пользователи должны убедиться в том, что свободное значение меньше времени ожидания сопоставления NAT, которое равно 20 секундам.
GRE Tunnel Keepalives
Available Languages
Download Options
Contents
Introduction
This document explains what Generic Routing Encapsulation (GRE) keepalives are and how they work.
Note: GRE keepalives are not supported together with IPsec tunnel protection under any circumstances. This document discusses this issue.
GRE Tunnels
A GRE tunnel is a logical interface on a Cisco router that provides a way to encapsulate passenger packets inside a transport protocol. It is an architecture designed to provide the services in order to implement a point-to-point encapsulation scheme.
GRE tunnels are designed to be completely stateless. This means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint. A consequence of this is that the local tunnel endpoint router does not have the ability to bring the line protocol of the GRE Tunnel interface down if the remote end of the tunnel is unreachable. The ability to mark an interface as down when the remote end of the link is not available is used in order to remove any routes (specifically static routes) in the routing table that use that interface as the outbound interface. Specifically, if the line protocol for an interface is changed to down, then any static routes that point out that interface are removed from the routing table. This allows for the installation of an alternate (floating) static route or for Policy Based Routing (PBR) in order to select an alternate next-hop or interface.
Normally, a GRE Tunnel interface comes up as soon as it is configured and it stays up as long as there is a valid tunnel source address or interface which is up. The tunnel destination IP address must also be routable. This is true even if the other side of the tunnel has not been configured. This means that a static route or PBR forwarding of packets via the GRE tunnel interface remains in effect even though the GRE tunnel packets do not reach the other end of the tunnel.
Before GRE keepalives were implemented, there were only ways to determine local issues on the router and no way to determine problems in the intervening network. For example, the case in which the GRE tunneled packets are successfully forwarded, but are lost before they reach the other end of the tunnel. Such scenarios would cause data packets that go through the GRE tunnel to be «black holed», even though an alternate route that uses PBR or a floating static route via another interface might be available. Keepalives on the GRE tunnel interface are used in order to solve this issue in the same way as keepalives are used on physical interfaces.
How Tunnel Keepalives Work
The GRE tunnel keepalive mechanism is similar to PPP keepalives in that it gives the ability for one side to originate and receive keepalive packets to and from a remote router even if the remote router does not support GRE keepalives. Since GRE is a packet tunneling mechanism for tunneling IP inside IP, a GRE IP tunnel packet can be built inside another GRE IP tunnel packet. For GRE keepalives, the sender prebuilds the keepalive response packet inside the original keepalive request packet so that the remote end only needs to do standard GRE decapsulation of the outer GRE IP header and then revert the inner IP GRE packet to the sender. These packets illustrate the IP tunneling concepts where GRE is the encapsulation protocol and IP is the transport protocol. The passenger protocol is also IP (although it can be another protocol like Decnet, Internetwork Packet Exchange (IPX), or Appletalk).
Сайт ARNY.RU
CISCO GRE — в статье рассмотрено развёртывание туннеля GRE и связанные с этим особенности на роутерах CISCO в виртуальной среде EVE-NG.
Немного о GRE
GRE (Generic Routing Encapsulation), нет ничего проще, чем GRE туннель. Буквально пара настроек и туннель готов. Какой-то большой смысловой нагрузки в этом туннеле нет. Но не всё так просто, дальше будет видно 🙂 GRE «всеядный»: GRE может инкапсулировать мульткаст-трафик, броадкаст-трафик. В этом основное его достоинство. Сам GRE не имеет собственного шифрования, отсюда и пользы от GRE в чистом виде нет. Существовать так он может только где-то внутри большой корпоративной сети. В частности GRE может применяться чтобы соединить 2 области IPv6 через область IPv4.
Состоит GRE из 3 компонентов (на картинке):
Тестовая среда
Средой для тестов как всегда является EVE-NG (кто ещё не настраивал, бежать настраивать). Тестовая схема:
Почему такая вот странная схема? Как раз симулирует «большую» корпоративную среду. Роутеры не граничные, ната на них нет, он там не нужен при таком развёртывании. Зато есть какой-то протокол маршрутизации (IGP). Для определённости на всех роутерах настроен EIGRP:
Поэтому есть полная доступность всех адресов с любого устройства:
Нужно обратить внимание, что подсеть 192.168.2.0/24 находится в 5 переходах (хопах) от подсети 192.168.1.0/24. В качестве хопа считается только входящий интерфейс каждого роутера по пути следования пакета.
Настройка GRE
Туннель прокидывается между интерфейсами роутеров R1 и R4:
Особенности настройки
Посмотрим таблицу маршрутизации:
Из таблицы видно, что на данный момент компьютеры ещё не используют туннель, маршрут EIGRP для подсети 192.168.2.0 указывает на интерфейс GigabitEthernet0/0, а должен на интерфейс Tunnel1. Добавим подсеть туннеля в EIGRP:
Роутеры R1 и R4 сформировали отношения смежности через туннель (а значит мультикаст через туннель ходит):
Но если посмотреть снова таблицу маршрутизации, то ничего ровным счетом не изменилось, смотрим теперь таблицу топологии EIGRP:
Маршрут через туннель имеет бОльшую метрику и не попадает в таблицу маршрутизации. Посмотрим интерфейсы:
Проверим/посчитаем метрику EIGRP для каждого интерфейса по формуле:
Всё верно. Как же заставить трафик идти через туннель?
Recursive Routing
Такое случается если роутер пытается достичь destination туннеля через сам туннель.
Как раз наш случай. Рассмотрим подробнее, можно изменять параметры Bandwidth (Delay) на интерфейсах. Изменять Bandwidth не рекомендуется, так как он участвует в расчётах для QoS, SNMP. Рекомендуется крутить Delay. При изменении данных параметров, одного или обоих, физические характеристики интерфейса не изменяются. Эти параметры нужны только для настройки протоколов.
Попробуем уменьшить Bandwidth на интерфейсе GigabitEthernet0/0:
Как только метрика через туннель становится меньше, чем через гигабитный интерфейс, туннель сразу гасится с сообщениями о петле и рекурсивном роутинге.
Можно менять Bandwidth в настройках самого туннеля:
Не пробовал такую настройку, но скорее всего получится то же самое.
Статическая маршрутизация
Смотрим таблицу маршрутизации:
Что произошло? Статический маршрут, который имеет административное расстояние равное 1, заменил собой маршрут EIGRP, у которого административное расстояние (AD) 90. Проверяем на компьютере:
Другой протокол маршрутизации
Убираем статику, иначе она своей AD = 1 забьёт все другие маршруты:
Настраиваем протокол OSPF на R1 и R4:
Обращаю внимание, что для OSPF совпадение Process ID (1 и 101) необязательно.
Убираем информацию о подсетях 192.168.1.0/24, 192.168.2.0/24 из EIGRP:
Зачем это делать? EIGRP имеет AD = 90, против 110 у OSPF. Поэтому пока существует маршрут EIGRP, у маршрута OSPF нет шансов попасть в таблицу маршрутизации.
Смотрим таблицу маршрутизации:
Policy-Based Routing
Возвращаем как было изначально EIGRP:
Если кто обратил внимание, то подсети были добавлены без обратной маски. Так можно сделать потому, что наши подсети совпадают с подсетью класса C.
Пакеты от PC1 к PC2 и обратно снова ходят мимо туннеля.
Создаём ACL для отбора трафика между PC1 и PC2:
Создаём политику перенаправления трафика:
Политика может быть применена для трафика порождаемого внутри самого роутера, тогда она вводится как локальная в режиме глобальной конфигурации. Или же политика применяется для транзитного трафика, тогда она вешается на интерфейс.
PBR для локального трафика
Запускаем трассировку с роутера R1:
Теперь применяем политику и снова проверяем:
PBR для транзитного трафика
Убираем локальную политику:
Вешаем на внутренний интерфейс:
Теперь все пакеты, проходящие через GigabitEthernet 0/1 проверяются на совпадение с ACL 101 и при таком совпадении перенаправляются в туннель. Проверяем для PC1:
Как видно, пакеты для адресов 10.10.0.0/16 по прежнему ходят мимо туннеля, так и должно быть.
Особенности PBR
С PBR нужно обращаться аккуратно, любая ошибка в настройке может привести к неочевидным последствиям. Удалим «случайно» ACL 101 на R1:
Теперь пакеты для адресов 10.10.0.0/16 (кроме адреса интерфейса роутера R1 10.10.10.1) заворачивают сначала в туннель и уже из него к нужному адресу. Маршрут получается не оптимальный, а кривой.
PBR перехватывает пакеты до стандартной маршрутизации. Другими словами PBR действует на входящий (ingress) трафик:
Поэтому если перевесить политику на GigabitEthernet 0/0 (куда прибывают уже смаршрутизированные пакеты), то политика не отрабатывает, попаданий в ACL 101 нет. Включим дебаг и ещё раз запустим пинг с PC1 на PC2. Что при этом происходит, интересная штука:
Политика не проверяет исходящие с GigabitEthernet 0/0 пакеты PC1, но проверяет ответные от PC2, так как они являются входящими для интерфейса.
Keepalive
Протокол GRE по умолчанию является протоколом без отслеживания состояния, то есть статус одной оконечной точки туннеля неизвестен для другой. Интерфейс туннеля сразу переходит в Up, если в таблице маршрутизации имеется маршрут до destination туннеля. Когда маршрут динамический, туннель полагается на таймеры протокола маршрутизации, чтобы отслеживать состояние маршрута и значит состояние туннеля. Если же это статический маршрут, то и механизмов никаких нет.
Механизм Keepalive исправляет эту ситуацию. И траблшутинге позволит сразу оценить в каком состоянии туннель. Подробно работа Keepalive для GRE в реализации CISCO рассказана тут, значения параметров описаны здесь. Параметры:
Кратко перескажу работу Keepalive: сторона туннеля (R1), на которой настроен Keepalive периодически отправляет «хитрые» пакеты другой стороне (R4), когда хитрый пакет распакуется на R4, то внутри окажется обратный пакет для R1 (пустой, без нагрузки). Когда R1 получит обратный пакет, то он поймёт, что всё в порядке. Если обратный пакет не вернётся, то счетчик увеличивается на 1. Когда счётчик достигнет установленного значения, Keepalive переведёт Line Protocol для интерфейса Tunnel в состояние Down. Пользовательский трафик отправляться не сможет. При этом отправка пакетов Keepalive продолжится. Как только будет получен обратный пакет, Line Protocol будет переведён в UP, а счётчик обнулится.
При работе Keepalive сразу можно увидеть когда есть проблема с туннелем по упавшему Line Protocol. Для нашего примера:
Должно быть по умолчанию keepalive 10 5, на практике немного отличается: keepalive 10 3. Теперь посмотрим WireShark:
Теперь погасим интерфейс Tunnel 1 на R4:
И посмотрим что будет на R1:
После поднятия интерфейса туннеля на R4, туннель полностью поднимается и на R1.
Заключение
Рассмотренные примеры больше умозрительные, чем боевые, так как GRE в чистом виде неинтересен, кроме каких-то очень частных случаев. Рекомендую рассмотреть боевую реализацию GRE over IPSec.