Каковы возможности ядра Linux (?) Для работы с конечной точкой Cisco, включающей поддержку активности GRE? У нас есть туннель GRE IPsec, настроенный с другой компанией. Мы хотели бы иметь резервный туннель, который должен быть активен, когда умирает основной. Таким образом, они включают поддержку активности GRE на первом, который обнаружит сбой и переключит маршрутизацию на резервный туннель. Мы зависим от предлагаемой ими технологии (другие решения использовать нельзя). Как мы можем осуществить такое общение? Я был удивлен, не обнаружив ничего об этом ни в iproute2, ни в ядре. Только этот появилось, но не кажется надежным для использования в производстве.
ОБНОВИТЬ:
Наша текущая конфигурация:
Мы должен используйте GRE keep-alives. Они сказали нам, что нет способа (ну, технически, но я предполагаю, что это их политика) установить резервный туннель, если мы не включим поддержку активности.
Вопрос в том, можно ли использовать конфигурацию сервера, упомянутую выше?
Это только частично связано с сообщениями поддержки активности. По сути, вам нужно установить второй туннель GRE и реализовать некоторый механизм для обнаружения сбоев туннеля (хотя это можно сделать с помощью сообщений поддержки активности, обычно это делается с помощью HELO протокольные сообщения или BFD уровень протокола поверх динамической маршрутизации, разработанный специально для этой цели). Обычным подходом будет использование любого вида динамической маршрутизации, но не ПОКОЙСЯ С МИРОМ (независимо от его версии) - поскольку ПОКОЙСЯ С МИРОМ не подходит для многопутевых операций и в основном содержит только один маршрут для пункта назначения. OSPF будет хорошо, EIGRP (но поскольку он проприетарный, вы не можете использовать его в Linux, так как нет его открытых реализаций), IS-IS, iBGP.
Вы также можете подумать об избавлении от GRE и реализовать VTI туннель, поскольку ядро Linux на это способно.