Re: События с линком Wireguard
On Sun, Aug 07, 2022 at 05:57:03PM +0300, Andrey Jr. Melnikov wrote:
> IL Ka <kazakevichilya@gmail.com> wrote:
> > У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,
> Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
> инженегры накостыляли GRE со всеми его проблемами.
GRE это протокол, который с точки зрения payload'a является программным
аналогом 2-го уровня модели OSI, то есть это уровень изернетовских фреймов.
Если посмотреть на номера пейлоадов в исходном RFC1701 (1994 год), там
значения совпадают с изернетовскими номерами. А 2-му уровню нет дела
до доступности получателя. Его задача -- упаковать пришедший пакет и
отправить дальше. Примерно так, наверное, рассуждали авторы GRE.
Спецификация GRE не регламентирует поведение инкапсулятора, который
может мониторить состояние туннеля, либо нет, по своему усмотрению.
Так что вендоры вольны реализовать над GRE любые модели поведения:
как голый GRE (stateless), так и l2tp (например) со своими таймерами.
Но задача, которая обсуждается здесь, более высокого уровня: что делать,
если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
И даже если он мониторит состояния линка и может передать его на уровень
дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
--
Eugene Berdnikov
Reply to: