Сети передачи контента : Пакеты Keepalive

Обзор механизмов поддержки активности на Cisco IOS

21 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

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

Внесенный Атри Бэзу и Майкл Салленбергер, специалисты службы технической поддержки Cisco.

Общие сведения

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

  • Интервалы сообщений поддержки активности — это период времени от отправки устройством сообщения поддержки активности до отправки следующего сообщения тем же сетевым устройством. Это всегда конфигурируемо.
  • Повторы сообщений поддержки активности являются числом раз, что устройство продолжает передавать пакеты keepalive без ответа, прежде чем состояние будет изменено на "вниз". Для некоторых типов пакетов Keepalive это конфигурируемо, в то время как для других существует значение по умолчанию, которое не может быть изменено.

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

Интерфейсы Ethernet

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

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

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

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

  • Для восстановления системы к интервалу проверки активности по умолчанию 10 секунд введите команду keepalive ни с каким ключевым словом.
  • Для отключения пакетов Keepalive войдите, поддержка активности отключают команду.

Примечание: Команда keepalive применяется к последовательным интерфейсам, которые используют Ссылку Высокоуровневого протокола управления каналом Contol (HDLC) или инкапсуляция PPP. Это не применяется к последовательным интерфейсам та Инкапсуляция Frame Relay использования.

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

Сообщения поддержки активности HDLC

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

Включите команду debug serial interface для подключения HDLC, чтобы позволить пользователю видеть пакеты Keepalive, которые генерируются и передаются:

Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up

Сообщения проверки активности HDLC содержат три части, чтобы решить, что это работает:

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

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

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

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

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

Router1#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.1/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
[output is omited]

17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
Router1 (config-if)#shut
17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state
to administratively down

17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0,
changed state to down

Router-2

Router2#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.2/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
[output is omited]


17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up
17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up
17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up
17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up
17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up
17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up
17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up
17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up
17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up
17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up
17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up
17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up
17:23:05.153: HD(0): Reset from 0x203758
17:23:05.153: HD(0): Asserting DTR
17:23:05.153: HD(0): Asserting DTR and RTS
17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up
17:23:15.173: HD(0): Reset from 0x203758
17:23:15.173: HD(0): Asserting DTR
17:23:15.173: HD(0): Asserting DTR and RTS
17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down
17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0,
changed state to down
Router2#
17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down

Сообщения проверки активности PPP

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

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

17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325

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

17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D

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

  • Номер ID - использовал определять, на какой ECHOREQ узел отвечает.
  • Тип проверки активности - ECHOREQ является пакетами Keepalive, передаваемыми исходным устройством, и ECHOREP ответы, передаваемые узлом.
  • Системные коды - уведомления включают системные коды и сервера и удаленного клиента. Узел проверяет системный код в пакете Эхо-запроса LCP и передает соответствующий пакет Эхо-ответа LCP, который содержит системный код, о котором выполняет согласование маршрутизатор.

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

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

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

Крипто-пакеты Keepalive

Пакеты Keepalive IKE

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

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

crypto isakmp keepalive seconds  [retry-seconds]  [ periodic | on-demand ]

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

Сообщения поддержания соединения NAT

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

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

Для получения дополнительной информации об этой функции посмотрите прозрачность NAT IPSec.



Document ID: 118390