BGP multihop - cпециальная функция используемая для установления BGP соседства с роутером, который не является directly connect для данного. Есть несколько фич, которые необходимо рассмотреть. Это касается проверок, которые выполняются при создании EBGP-сессии.

• Во-первых, сессия должна быть инициирована с IP-адреса, прописанного в команде neighbor.
• Во-вторых, этот IP-адрес должен жить в directly connected сети.
• В-третьих, поле IP TTL должно быть не равно 0 (TTL > 0)

Итак, при создании eBGP сессии проверяется, что peer - directly connected, т.е. живет в той же IP-подсети что и интерфейс маршрутизатора. Если это не так, то циска даже не пытается инициировать соединение, а принятые запросы на установку соединения игнорируются. Отключить проверку на «directly connected» можно двумя способами:

neighbor ebgp-multihop или neighbor disable-connected-check

neighbor ebgp-multihop

1. Устанавливает IP TTL = ttl в отправляемых eBGP-пакетах.
2. Для данного нейбора отключает проверку «directly connected», но не отключает IP TTL проверку принимаемых от него сообщений.

neighbor disable-connected-check

1. Пакеты, уходящие на пира, имеют TTL=1 (если не переопределено предыдущей командой)
2. Для данного пира отключаются проверки «directly connected» и IP TTL.

Рассмотрим следующую топологию. Внутри работает IGP, так что все роутеры знают о сетях и Loopback'ах друг друга. Нас интересует только возможность установить EBGP-сессию. Все EBGP-сессии устанавливаются между Loopback’ами.

EBGP: R2 <-> R4

Здесь подходят оба описанных выше способа:

neighbor RX ebgp-multihop 2 или neighbor disable-connected-check

NOTE: Вариант «neighbor RX ebgp-multihop 1» не проходит, т.к. эта команда не отключает IP TTL проверку.

EBGP: R1 <-> R4

Команда «neighbor disable-connected-check» здесь не подойдет по той причине, что в отправляемых сообщениях IP TTL = 1, и R2 будет дропить пакеты. Однако следующий вариант работает:

router bgp XXX

neighbor RX ebgp-multihop 2

neighbor disable-connected-check

R1 отправляет пакет с TTL=2. R4 принимает его с TTL=1 и маршрутизирует на свой Loopback, уменьшая TTL до 0. С таким TTL пакет должен быть отброшен, но благодаря второй команде данная проверка игнорируется и сессия устанавливается.

По умолчанию eBGP передает пакет с TTL=1. Это гарантирует, что TTL «протухнет» после первого же хопа и пакет не пойдет дальше directed connected пира. EBGP следует обычному алгоритму и проверяет, что IP TTL > 0, т.е. обычный EBGP пакет с TTL=1 пройдет эту проверку. Для BGP роутеров, смотрящих во внешний мир, существует угроза spoofing'а. Например, хосты, живущие на расстоянии в 10 хопов, могут подделывать eBGP-пакеты, устанавливать в них TTL>0 и наш роутер примет их, т.к. проверка валидна. Обработка большого количества таких пакетов создаст нагрузку на CPU и может наступить полная DoS'а.

Для борьбы с подобными атаками существует фича ttl-security. (Сразу стоит заметить, что если она включена, то роутер отправляет EBGP-сообщения с TTL=255). Работает она так: допустим между пирами А и В существуют 5 хопов. Отправляя EBGP-сообщение роутер A устанавливает TTL=255. На пир В это сообщение приходит с TTL=250. Выполняя вычитание (255 -250) пир В узнает, что пакет прошел путь в 5 хопов. Если мы заранее указали ему, что это допустимое значение, то пакет принимается. Указать валидное кол-во хопов как раз и позволяет фича ttl-security.

router bgp XXX

neighbor A remote-as YYY

neighbor A ttl-security hops 5

NOTE: Если результат вычитания меньше или равен 5, то пришедший пакет считается валидным. Т.к. вычитание выполняется из 255, то пакет также должен быть отправлен с TTL=255, т.е. нужно включать фичу с обеих сторон, либо на одной из сторон использовать фичу, а на другой «ebgp-multihop 255». И ещё «ttl-security» и «ebgp-multihop» взаимоисключающие фичи, т.е. их нельзя одновременно применять к одному соседу.

Сводная таблица: