Просишь — получаешь. Так получилось, что у меня в GNS3 как раз есть лабораторка, которая идеально это иллюстрирует:
Детали конфигурации:
R1, R2 и R3 все настроены на iBGP-пиринги друг с другом в полном меше (без route reflectors).
В качестве router ID у них используются IP-адреса loopback.
В качестве адреса пиринга — loopback удалённого роутера.
Источник трафика — loopback-интерфейс.
Внутри AS100 используется OSPF как IGP.
Почему для iBGP нужно пириться по loopback IP:
Предположим, что R2 и R3 настроены пириться по IP, назначенным на линк (10.2.3.2 и 10.2.3.3). И вот этот линк падает. R2 перестанет видеть 10.2.3.3, R3 — 10.2.3.2. Сессия iBGP между ними разорвётся.
Так как это полный меш iBGP-пирингов внутри AS, R2 узнаёт про существование AS600 только от R3. Когда сессия R2<>R3 падает, R2 теряет путь BGP к AS600, а значит, AS500 больше не сможет достучаться до AS600. Аналогично R3 теряет маршруты к AS500.
Это нелепо, ведь R2 всё ещё может добраться до R3 через R1, а OSPF внутри ASN быстро найдёт этот альтернативный путь. То есть путь от AS500 до AS600 есть — но он не работает из-за неправильной настройки iBGP в AS100.
Почему OSPF не спасёт ситуацию?
Кто-то может спросить: «Если OSPF видит обход через R1, почему R2 не может достучаться до 10.2.3.3 через R1?»
Потенциально может, но только не используя исходный IP 10.2.3.2 — сейчас разберёмся. Есть три варианта отказа линка:
1. Линк падает так, что оба роутера видят интерфейс как down — тогда IP-адреса недоступны, так как сеть неактивна.
2. Линк физически поднят, но передача пакетов не работает — тогда оба роутера считают сеть 10.2.3.0/24 локально подключённой и всегда пытаются слать пакеты напрямую, а не через OSPF-обход.
3. R2 видит интерфейс как down, а R3 — как up. В таком случае R2 узнаёт о сети 10.2.3.0/24 через OSPF по R1 и может пинговать 10.2.3.3, но не с IP 10.2.3.2 — вместо этого будет использовать IP другого интерфейса. Но даже если R2 будет использовать 10.2.3.2, R3 не сможет нормально ответить, отправляя пакеты напрямую по link’у, который уже не работает.
То же самое если R3 видит интерфейс down, а R2 — up.
В любом случае нет полноценной двунаправленной связи между 10.2.3.2 и 10.2.3.3. Если iBGP настраивается на эти IP-адреса интерфейсов, iBGP сессия упадёт при отказе линка.
Loopback IP всегда доступен
Если хотя бы один сосед OSPF активен, loopback адрес объявляется в OSPF и всегда доступен, независимо от изменений топологии. Если R2 и R3 используют для iBGP свои loopback IP, сессия между ними не упадёт даже при изменениях физической топологии.
Помните: iBGP не работает как IGP, например OSPF.
Next hop в iBGP — это всегда IP, полученный от исходного eBGP пира. Например, когда R3 узнаёт о 6.0.0.0/8 от AS600, next hop будет 10.3.6.6, который он потом передаёт R1 и R2. В базе R1 next hop стоит 10.3.6.6, который должен быть доступен через другие маршруты (обычно OSPF).
Вот почему iBGP использует «рекурсивный next hop» — роутер может принимать решение, оценивая расстояние до next hop. В маленькой топологии это не очевидно, но в большой сети с множеством путей к удалённым AS это важно. Например, роутер X выбирает между двумя путями до Google от пиров Y и Z через iBGP. Если метрики равны, выбор делается по расстоянию до Y или Z. Обычно путь до Y ближе, но если топология поменяется и Z станет ближе, X выберет маршрут через Z и оповестит об этом eBGP соседей. Если соседям не понравится то, что через Z, они могут выбрать другой пир, и когда снова станет короче путь через Y, X обновит маршрут и eBGP соседи опять предпочтут ваш маршрут.
Я не хотел столько вдаваться в теорию BGP, но важно понять, почему iBGP сохраняет next hop IP, тогда как IGP меняет next hop на адрес соседа. Из-за этого ваш iBGP сосед должен быть доступен в любых условиях — вот почему для iBGP используют loopback интерфейсы.
