Настройка BGP AF-Mode в Cisco IOS

В BGP у нас есть возможность работать с разными адресными семействами. Когда мы сейчас с вами настраивали BGP, мы указывали команду Network, они были очевидно IPv4. Мы прописывали Neighbor, они были очевидно IPv4. Но сегодня IPv4 уже можно считать протоколом устаревшим, потому что есть IPv6, который всё завоёвывает мир. Всё ещё пока не завоевал, но, тем не менее, несомненно, скоро завоюет. Поэтому вы, безусловно, должны будете знать, как BGP работает с IPv6. И для этого нам потребуется новая фича. Это называется BGP AF-Mode. Эта штука позволяет работать в рамках BGP с разными адресными семействами. Так же, как, например, OSPFv3 умеет работать с разными адресными семействами. Та же самая штука есть и в BGP. Протокол тот же самый.

Синтаксис настройки немножко отличается. Если вы включаете AF-Mode, то вы включаете поддержку мультипротокол BGP на вашем роутере. И фактически вы указываете, какие адресные семейства вы согласны реплицировать, согласны синхронизировать с конкретными соседями. Вы поднимаете сессию и в рамках этой сессии заявляете, какие адресные семейства поддерживаете вы. Если сосед поддерживает адресные семейства и вы поддерживаете адресные семейства, вы это в сообщении Open будете передавать, и вы согласуете передачу маршрутов определённого адресного семейства. Если кто-то из вас заявил, что знает некое адресное семейство, а сосед это не понимает, то вы со своей стороны заявили, сосед со своей стороны не заявил, и вы понимаете, что адресное семейство у вас по факту не активировано. Вы маршруты отправлять будете только соседу, который сказал: я понимаю, что ты собираешься мне отправлять. В BGP вы будете заявлять поддержку разных адресных семейств, и вы должны будете понимать, как BGP кодирует те или иные адресные семейства, потому что оборудование разных вендоров.

Эта терминология достаточно стандартная, и часто вы должны будете настраивать и понимать, что именно там пишут, когда пишут всякие страшные слова — AFI, SAFI и так далее. Если вы указываете, что вы хотите реплицировать таблицы IPv4 Unicast, то это будет адресное семейство AF Indicator 1. С IPv4 адресное семейство 1 у нас как раз будет использоваться. Есть так называемый Subsequent AF Identifier, SAFI. Это указывает на то, какие именно маршруты вы будете пытаться реплицировать. Дело в том, что есть IPv4 Unicast таблица, есть IPv4 Multicast таблица. Есть маршруты VPN-клиентов, L3 VPN-клиентов. Соответственно, там всё это будут маршруты, которые должны попадать в разные адресные семейства. И если вы указываете, что у вас есть просто обычные нормальные IPv4 маршруты, то вы указываете AFI, SAFI 1.1.

Если вы указываете, что у вас есть IPv6, просто нормальные маршруты, то Subsequent AF Identifier у вас тоже будет единичка, что это нормальные маршруты. А вот адресное семейство будет код иметь 2. В то же время, если вы хотите передавать маршруты своих клиентов в рамках L3 VPN, а BGP такую штуку умеет делать, и это очень часто используется, то тип маршрута будет единичка, а код таблицы, в которые будут вбрасываться такие маршруты, SAFI, будет 128. Если вы работаете с маршрутами разных адресных семейств, например, IPv4 и IPv6, то, очевидно, у вас будут разные атрибуты, в которые будут вписываться разные адреса. Тот самый NextHop, например. В IPv4 он длиной, очевидно, 4 байта, в IPv6 он будет, очевидно, длиной 16 байт. Как минимум, размер атрибута NextHop, безусловно, в разных адресных семействах различаться будет. Плюс к тому, естественно, сами адреса сетей будут различаться. Они просто по длине будут разные.

В BGP префикс, то, про что BGP может рассказать, единица обмена полезной информацией в BGP, будет называться NLRI, Network Layer Reachability Information. Очевидно, что в IPv4 рассказываем мы про IPv4-сетки, в IPv6 мы рассказываем про IPv6-сетки. И размер того, про что мы рассказываем, того самого NLRI, в IPv4 и в IPv6 тоже будет разный. Дальше. Вы можете взять, запустить BGP в обычном классическом режиме и потом обратиться к этой конфигурации, как будто бы она у вас была настроена в AF-Mode. Так же, как в OSPFv3. Если мы поднимали OSPFv3 для IPv6, а потом говорили, давай попробуем сделать какую-то штуку, чтобы мы поддерживали адресные семейства IPv4, то у вас сразу контекст конфига переезжал из одного режима в другой.

То же самое и здесь. Если вы настроите IPv4 BGP, а потом попытаетесь обратиться к какому-то адресному семейству, например, к IPv6, то у вас просто синтаксис автоматически обновится до нового, до AF-Mode. Вот как выглядит конфигурация с адресными семействами. У нас есть роутер BGP, у него есть нейборы, и эти нейборы прописываются в глобальном контексте роутера. А дальше мы указываем адресное семейство IPv4 Unicast, IPv6 Unicast, и дальше там делаем какие-то настройки, которые нам будут интересны. В настройках адресного семейства, очевидно, нам нужно будет использовать какие-то вещи, которые характерны для этого адресного семейства. Например, Neighbor, например, Network команды, они, естественно, будут специфичны именно для IPv4 или для IPv6. У BGP очень интересная особенность — команда Network есть. В RIP, RIP-NG, в OSPFv3, в EIGRP для IPv6 не было команды Network,

потому что команда Network там на самом деле никакого отношения к сетям не имела. А здесь Network есть в IPv6. Мы в явном виде указываем, какую сетку из таблицы маршрутизации мы забираем и включаем в анонс. Поэтому команда Network IPv6 в BGP делает ровно то, что она должна делать. Она забирает из таблицы маршрутизации сетку, включает её в анонс. Дальше, что ещё тут есть? Если у вас есть роутер, и он дружит с каким-то соседом, и у вас так называемый dual stack, есть и IPv4, и IPv6. Соответственно, есть проводок, в этом проводе у вас и IPv4 бегает, и IPv6 бегает. И возникает вопрос: что делать, как соседство поднимать? Если бы мы запустили какой-нибудь условный EIGRP или OSPFv3, они бы, не сумняшеся, сказали: отдельную сессию для IPv4, отдельную сессию для IPv6. EIGRP даже позволил бы разные автономки прописать.

OSPFv3 сказал бы: автономки, конечно, у нас нет такого понятия, но инстансы разные сделаем. В одном случае инстанс 0, в другом 64. BGP позволяет вам установить одно соседство, и в рамках одного соседства протащить два адресных семейства. За счёт как раз того, что адресные семейства отличаются между собой по AFI и SAFI. Мы прописываем нейборов и можем сказать: мы поднимаем одно соседство, и в рамках него работаем и с IPv4, и с IPv6. Прописываем соседа — Neighbor, дальше IP-шник соседа, можно IPv4, можно IPv6, remote-as, и дальше указываем его автономку. И дальше поднимаем оба адресных семейства. Адресное семейство IPv4 Unicast, адресное семейство IPv6 Unicast. В IPv4 анонсируем какие-то сетки, в IPv6 анонсируем какие-то сетки. Если говорить про адресные семейства, то есть нюанс. По умолчанию IPv4 Unicast семейство активируется для всех пиров.

Если вы указываете, что у вас есть пир, он автоматом получает возможность реплицировать IPv4 Unicast. Если вы этого не хотите, вы должны это отключить в явном виде, сказать, что вот этому пиру IPv4 Unicast отсылать не надо. Или вы можете это на уровне глобального конфига роутера сказать: IPv4 Unicast по умолчанию не прописываем. Но если такой команды нет, то вы включаете IPv4 Unicast для всех-всех-всех соседей. А вот IPv6 Unicast по умолчанию не активируется. Поэтому на каждого нейбора нужно будет в явном виде прописать. Если вы включаете для нейбора IPv6, то нужно зайти в адресное семейство IPv6 Unicast и прописать Neighbor чего-то Activate. Это значит, что вы этому соседу разрешаете реплицировать IPv6 маршруты. Есть нюанс, который заключается в том, что если нейбор у вас всего один, то нужно будет каким-то образом бороться с тем, что в анонсах, которые вы будете посылать по eBGP-шной связи,

у вас будет прописываться ваш собственный IP-шник. Он будет прописываться, вы не поверите, IPv4. Вы отправляете IPv6-маршрут из-под IP-шника 10.0.0.2. В TCP-шной сессии у вас стоит IPv4-адрес. Поэтому вы проставляете свой адрес 10.0.0.2 в качестве шлюза. Вы посылаете указание, например: «Я знаю, как добраться до сети FD00:1:2::/64. NextHop будет 10.0.0.1». Если вам кажется, что это немножко бредово, да, это немножко бредово, но это то, как работает BGP. Естественно, такой NextHop в таблицу маршрутизации поставить будет нельзя. Поэтому вы должны будете при анонсе такого маршрута IPv6 понимать, что маршруты, которые вы отправляете соседу, должны идти с немножко другим NextHop. И вы должны будете его route-map перебить. Указываете Route-map, Update NextHop, Out. И route-map у вас будет по какому-то правилу перебивать NextHop на настоящий IPv6-адрес, который вы хотите NextHop иметь.

Если вы не хотите заморачиваться с route-map, вы можете поднять два разных соседства. Говорите: у нас одно IPv4-соседство, там IPv4 и NextHop IPv4. Рядом поднимаем IPv6, там IPv6 и NextHop IPv6. И ничего дополнительно делать не надо. Просто для нужного соседа мы указываем, что у нас сосед получает адресное семейство Unicast и не получает, соответственно, это адресное семейство сосед, который IPv6. No Neighbor Activate. А в IPv6 мы, соответственно, говорим, что у нас Neighbor вот такой активируется, а Neighbor IPv4 там же не активируется. Здесь не прописано, но вообще, конечно, надо написать No Neighbor чего-то Activate. Такие штуки. Вы должны будете сами решить, что вы хотите сделать. То ли вы хотите на каждого соседа, если у вас dual stack, держать два соседства, то ли вы хотите держать одно соседство, но перебивать NextHop-адреса. В любом случае вы сами ответственны за то, что вы делаете.

BGP позволяет вам это делать. А как вы этот механизм будете использовать, будете ли использовать — это уже ваше дело. Если вы хотите подменять NextHop, то да, вы должны будете создать route-map. И пример такого route-map может быть вот: у нас есть в настройке роутера указание Neighbor 10.0.0.2, route-map чего-то там out. Мы при отправке апдейтов соседу 10.0.0.2, если мы понимаем, что это маршруты IPv6, перебиваем NextHop на какой-то публичный IP-шник. 2001:DB8:2001:2002::2001. Если мы этого не сделаем, то маршруты, которые будут приходить IPv6 от IPv4-соседа, у них NextHop будет вот такой вот. IPv4-mapped адрес. ::FFFF:10.0.0.1. Обратите внимание на синтаксис такого адреса. У него в конце 32 бита записаны не нулями,

а именно через точку в IPv4-виде. Это нормально. Для IPv4-mapped адресов такое допустимо. Соответственно, да. Нам нужно его перебить, чтобы он в таблицу маршрутизации поставился. Мы в исходящих апдейтах указываем этот настоящий маршрутизируемый адрес. В таблице BGP этот адрес маршрутизируемый резолвится. В таблице маршрутизации резолвится. И в таблице маршрутизации видно, что маршрут поставился на какой-то NextHop-адрес. Что делать, если у нас есть BGP, работающий в режиме AF-Mode? Проверяем то, какие у нас настройки BGP. Show BGP IPv4 Unicast Summary покажет список соседей. Show BGP IPv4 Unicast Neighbors покажет детали про каждого конкретного соседа. Это на самом деле бывшая команда Show IP BGP Summary.

И, соответственно, то же самое для IPv6 Unicast. Это Show BGP IPv6 Unicast Summary, Show BGP IPv6 Unicast Neighbors. Я не думаю, что вам нужно сейчас как-то особенно много внимания уделять BGP AF-Mode. Эта тема очень важная. Если вы потом собираетесь идти на CCIE или на провайдерский трек, то там BGP, конечно, нужно будет изучать очень мощно. Но если вы собираетесь идти на CCNP Routing & Switching, то BGP вы просто должны будете понимать, как он работает, и хорошо уметь работать с обычным IPv4 BGP. Там все команды вы должны будете знать просто наизусть. Я не предлагаю вам учить наизусть то, как работает BGP с IPv6.

Хотя, естественно, эта тема довольно перспективная, тем не менее, количество ресурсов, которые у нас есть, ограничено. И поэтому, скорее всего, вам это не понадобится. Я уже подчеркнул, что если вдруг вы потом хотите идти на какие-то более старшие курсы, то там, конечно же, BGP вы должны будете знать и для IPv4, и для IPv6. И особенно для таких штук, как L3 VPN. Это возможность сбросить в таблицу BGP и реплицировать пользовательские маршруты, которые вам присылают ваши юзеры. И они вам могут присылать маршруты, которые пересекаются между собой — два соседа прислали маршрут до сетки 192.168.0.0/24. Вы должны будете их не перепутать, должны будете их среплицировать правильно и отдать правильным маршрутизаторам соседей, опять же, не перепутав. Если вам одна клиентская сетка и другая клиентская сетка, IP-шники у них похожи, вы должны будете их пометить, что это маршрут 192.168.0.0 от одного клиента.

Это точно такой же маршрут, но от другого клиента. И протащить эти маршруты по своей таблице, дойти до какой-то другой выходной точки и другим маршрутизаторам того же самого клиента отдать именно их собственные маршруты. Это не тема трека Routing & Switching CCNP, но это есть в CCIE, поэтому, если вдруг вы будете готовиться к CCIE, то там, конечно же, это нужно будет уметь делать.