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