CCNP Route "Full Scale" Лаба: IPv6

Пришло время разобраться с IPv6. На самом деле, не так-то все просто с точки зрения конфигурации. Давайте разбираться.

7. IPv6
- Configure RIPng
- OSPFv3 migration (new configuration approach)
- Named EIGRP migration
- BGP IPv6 over IPv6
- BGP IPv6 over IPv4

Итак, в рамках CCNP Route нам предлагается настроить четыре протокола маршрутизации на работу с IPv6. 

• В RIPng все довольно просто. По сути, настраиваем все тот же RIP, только наконец-то процесс можно запускать прямо на интерфейсах.

• OSPF в этом плане интереснее. IPv6 можно настроить классическим путем, просто запустив отдельный OSPF процеc для IPv6. Второй вариант более гибок и позволяет сократить и упростить конфигурацию. Запускается один OSPFv3 процесс, в котором IPv4 и IPv6 разделены с помощью address-family. В IPv6 не получится использовать команду network.

• В EIGRP примерно такая же ситуация, однако тут пошли ещё дальше и ввели так называемый Named тип конфигурации. Принцип схож с OSPF, только вот тут можно настраивать и параметры интерфейсов. Идея в том, чтобы вынести вообще весь конфиг EIGRP в отдельную область. В случае IPv4 все еще придется давать команду network.

• В BGP аналогично можно передавать IPv6 префиксы "нативно", а можно устанавливать соседство по IPv4, а уже внутри передавать свои IPv4 префиксы.

Уже традиционная картинка ниже (только IGP)

RIP

Начнем с простого - с RIP. Нам нужно просто рядом запустить ещё один процесс для IPv6. Все в целом просто, но есть и пару тонкостей.

1. Отсутсвует passive interface. Якобы эта опция уже не нужна, потому что RIP теперь включается прямо на интерфейсах. Если нужно добавить какую-то сеть на интерфейсе и запретить установление соседства анонс RIP маршрутов через этот интерфейс, придется редистрибуцировать...
2. Нет аутентификации. Предполагается, что мы будем использовать нативный механизм построения IPSec туннелей в IPv6. 

Конфиг выглядит примерно следующим образом. Ниже R3. В целом проще и аккуратнее, но вот добавить сюда аутентификацию или добавить сети с других интерфейсов не так просто как раньше.

ipv6 router rip RIP_DOMAIN
!
interface Loopback21
  ipv6 address 2001:A:0:2003::1/64
  ipv6 rip RIP_DOMAIN enable
!
interface Ethernet0/0
 ipv6 address 2001:A:0:2013::B/127
 ipv6 rip RIP_DOMAIN enable
!
interface Ethernet0/1
  ipv6 address 2001:A:0:2023::B/127
  ipv6 rip RIP_DOMAIN enable
!
interface Ethernet0/2
  ipv6 address 2001:A:0:2034::A/127
  ipv6 rip RIP_DOMAIN enable

Верификация проходит почти так же как и раньше.

Во всем остальном это то же RIP с hop-count, infinite metric равным 16 и все такое прочее.

OSPF

Согласно схеме мы можем использовать классический подход. Тут примерно как в RIP, просто запускаем параллельный процесс. Мы же смигрируем IPv4 и настроим IPv6 в одну address-family конфигурацию.

Тут тоже есть пара тонкостей:

1. Аутентификация поддерживается, но снова на уровне IPSec.
2. IPv4 конфигурация, которая настроена в  address-family и просто IPv4 процесс не одно и тоже. Два таких роутера не установят отношения соседства. По той причине, что в первом случае сами кадры будут несколько отличаться по формату и содержать Address-family бит как минимум.
3. OSPFv3 это новый протокол, который был сделан для поддержки IPv6. Для удобства в него добавили обратную совместимость с IPv4. Таком образом запустить OSPFv3 в address-family варианте только для IPv4 не получится. На интерфейсе должен быть хотя бы link-local адрес для того чтобы была возможность установить соседство. Вся коммуникация идет по IPv6.
4. OSPFv3 в варианте address-family не поддерживает virtual-link в явном виде... RFC5838 говорит примерно следующее: "OSPFv3 control packets sent over a virtual link are IPv6 packets and may traverse multiple hops. Therefore, there MUST be a global IPv6 address associated with the virtual link so that OSPFv3 control packets are forwarded correctly by the intermediate hops between virtual link endpoints. Although this requirement can be satisfied in IPv6 unicast AFs, it will not function in other AFs as there will not be a routable global IPv6 address or forwarding path. Therefore, virtual links are not supported in AFs other than IPv6 unicast." Обойти такой подвох можно не настраивая address-family а запускать два отдельных процесса...
5. Забавно, но при настройке passive-interface default автоматически добавляются строки no passive-interface. Но только не на Ethernet интерфейсы...

Возьмем конфиг с О3 и "перелопатим" его в новый. Ниже я привожу два конфига рядом - старый и новый. Я выделил две строки, которые сейчас не получится вот так просто реализовать. Также видно, что на каждом интерфейсе мы включаем либо IPv6, либо IPv4, либо оба сразу.

Блокноту очень не нравятся слова ospf и ipv6...

Аналогичную процедуру делаем на всех OSPF роутерах... надо было Ansible поднимать. В целом, все довольно запутанно, но разобраться можно. Так же добавляем все "стабзоны" и прочее со старой конфигурации.

Верификация особо не отличается от привычного OSPF. Ниже вывод с O6. Замечу, что строятся две разных таблицы соседей. Одна для IPv4, вторая - IPv6.

Virtual-Link

Помним, что наш О9 одиноко сидит на отшибе, потому что он не имеет прямого коннекта с нулевой областью. Виртуал линка тоже нет... К слову, здесь можно наблюдать разницу в поведении Cisco и Juniper. В аналогичной ситуации в Juniper на O9 будут маршруты из area1. Это я подтверждал здесь. Дело в том, что ABR в Juniper это роутер имеющий линки в разные области. Таким образом O6 как честный ABR возьмет данные из одной зоны (area1) и передаст в другую (area9). А вот в Cisco такой O6 ABRом не является, потому что у него нет линка в backbone область. Таким образом на O9 вообще нет ни единого маршрута. Он даже в первую область попасть не может.

Такая ситуация меня расстраивает. Жалко беднягу... Виртуальный линк напрямую не поддерживается.... но мы же знаем, что такое GRE... Растянем нулевую область до O9 настроив туннель от O3.

На O3 настраиваем:

interface Tunnel0
 ip address 10.10.39.1 255.255.255.252
 ipv6 address 2001:A:0:1039::A/127
 ospfv3 110 ipv4 area 0
 ospfv3 110 ipv6 area 0
 tunnel source Ethernet0/1
 tunnel mode gre ipv6
 tunnel destination 2001:A:0:1069::B
!
router ospfv3 110
 !
 address-family ipv4 unicast
  no passive-interface Tunnel0
 exit-address-family
 !
 address-family ipv6 unicast
  no passive-interface Tunnel0
 exit-address-family
!
ipv6 route 2001:A:0:1069::B/128 2001:A:0:1036::B

На O9 симметричный конфиг:

interface Tunnel0
 ip address 10.10.39.2 255.255.255.252
 ipv6 address 2001:A:0:1039::B/127
 ospfv3 110 ipv4 area 0
 ospfv3 110 ipv6 area 0
 tunnel source Ethernet0/0
 tunnel mode gre ipv6
 tunnel destination 2001:A:0:1036::A
!
router ospfv3 110
!
 address-family ipv4 unicast
  no passive-interface Tunnel0
 exit-address-family
 !
 address-family ipv6 unicast
  no passive-interface Tunnel0
 exit-address-family
!
ipv6 route 2001:A:0:1036::A/128 2001:A:0:1069::A

Первое, что нужно заметить - туннель поднимается между линковыми адресами, а не между loopback, как это делается обычно. Почему так? Поднять туннель на loopback'ах легко, но после этого соседство на этом интерфейсе начнет "дребезжать". IOS будет ругаться на то, что внутри туннельного интерфейса будет изучен такой же адрес, но уже на lo интерфейсе.

Второй момент, т.к. O3 ничего не знает про линковый интерфейс между O6 и O9 (и наоборот), придется добавить маленький статический маршрут.

Ну, можно проверять. Соседство есть, данные в LSDB есть. Можно переходить к EIGRP.

EIGRP

Нюансы:

1. Запускать EIGRP IPv4 на интерфейсах можно, но не совсем. Все равно придется указывать команду network. Например, так network 0.0.0.0

На мой скромный вкус, Named EIGRP - боль. Да, все в одном месте, но вот прыгать по конфигу все же приходится, просто внутри одной секции. Так что по сути, ничего и не поменялось.

Ниже пример конфига с E2. Сначала определяем первую "фэмили" для IPv4. По умолчанию, все интерфейсы в passive, EIGRP на них не запущено (shutdown). Далее для каждого интерфейса указываем комбинацию shutdown и passive. Для lo интерфейсов это no shutdown, таким образом мы добавим сети с этого интерфейса в процесс. А вот для линковых интерфейсом включаем EIGRP и указываем no passive. Далее указываем network 0.0.0.0. Без этой команды ничего не заработает. По сути, это такой трюк, чтобы все-таки получить возможность настраивать EIGRP IPv4 per interface. Для IPv6 все аналогично.

router eigrp EIGRP_DOMAIN
 !
 address-family ipv4 unicast autonomous-system 90
  !
  af-interface default
   shutdown
   passive-interface
  exit-af-interface
  !
  af-interface Ethernet0/2
   no shutdown
   no passive-interface
  exit-af-interface
  !
  af-interface Ethernet0/0
   no shutdown
   no passive-interface
  exit-af-interface
  !
  af-interface Loopback3
   no shutdown
  exit-af-interface
  !
  af-interface Loopback30
   no shutdown
  exit-af-interface
  !
  topology base
  exit-af-topology
  network 0.0.0.0
  eigrp router-id 10.0.30.2
 exit-address-family
 !
 address-family ipv6 unicast autonomous-system 90
  !
  af-interface default
   shutdown
   passive-interface
  exit-af-interface
  !
  af-interface Ethernet0/0
   no shutdown
   no passive-interface
  exit-af-interface
  !
  af-interface Ethernet0/2
   no shutdown
   no passive-interface
  exit-af-interface
  !
  af-interface Loopback31
   no shutdown
  exit-af-interface
  !
  topology base
  exit-af-topology
  eigrp router-id 10.0.30.2
 exit-address-family

Простая верификация на E7 показывает, что все вроде бы нормально.

 Верификация и прочее проходят аналогично классическому EIGRP.

BGP

Обратим взоры на BGP. Для начала посмотрим что у нас твориться на, скажем, B4.

router bgp 64500
 bgp log-neighbor-changes
 network 100.0.0.0 mask 255.255.252.0
 neighbor 10.0.30.2 remote-as 64500
 neighbor 10.0.30.2 update-source Loopback3
 neighbor 10.0.30.2 next-hop-self
 neighbor 101.10.10.5 remote-as 64501
 neighbor 101.10.10.5 soft-reconfiguration inbound
 neighbor 101.10.10.5 prefix-list TEST in
 neighbor 101.10.10.5 distribute-list OUR_PREFIXES out
 neighbor 101.10.10.5 route-map INCREASE_LP_FOR_103 in
 neighbor 101.10.10.5 route-map MED10 out
 neighbor 102.10.10.9 remote-as 64502
 neighbor 102.10.10.9 distribute-list OUR_PREFIXES out
 neighbor 102.10.10.9 route-map MED10 out

Попробуем модифицировать сессию с 101.10.10.5 и передать в рамках неё наш IPv6 префикс 2001:A::/48.

Для начала добавить маршрут в Null.

ipv6 route 2001:A::/48 Null0

Теперь заходим в процесс BGP и включаем там вторую address-family, указываем соседа и сеть. Сразу после этого наша конфигурация примет несколько иной вид.

Весь конфиг секции разбился на три части. Сначала определяем соседей и какие-то базовые настройки. Далее, весь основной конфиг переходит в address-family ipv4. Ну и самым последним определяем address-family ipv6. 

На соседе сделаем симметричную настройку.

address-family ipv6
  network 2001:1::/48
  neighbor 101.10.10.6 activate
!
ipv6 route 2001:1::/48 Null0

Но в итоге, ничего не заработает. Нужно сделать небольшой трюк. Смысл в том, что сосед B2 получит анонс от IPv4 адреса, что не является валидным в IPv6 address-family. Напишем простой роут-мап, где будем менять IPv4 адрес на IPv6.

route-map NEXT-HOP permit 10
 set ipv6 next-hop 2001:1:1000::B

router bgp 64500
 address-family ipv6
  neighbor 101.10.10.5 route-map NEXT-HOP out

Теперь B2 видит наш анонс. В такой ситуации мы переиспользуем уже существующую IPv4 сессию. Вторым вариантом, как я уже говорил, будет поднятие отдельной сессии для передачи IPv6. Настроим такую сессию между B5 и B3.

На B5 конфиг выгядит так

router bgp 64500
 neighbor 2001:2:1000::A remote-as 64502
 !
  address-family ipv6
  network 2001:A::/48
  neighbor 2001:2:1000::A activate
!
ipv6 route 2001:A::/48 Null0

На B3

router bgp 64502
 neighbor 2001:2:1000::B remote-as 64500
  address-family ipv6
  neighbor 2001:2:1000::B activate




Результат будет тот же. Разница лишь в том как именно передаются IPv6 префиксы.

Через IPv4 на B2 (смотрим колонку neighbor)

Или "нативно" через IPv6.

Redistribution

В Official Guide про это ничего нет, но я не могу не настроить простую редистриюуцию.

Из EIGRP в RIP и обратно для обоих address-family.

router eigrp EIGRP_DOMAIN
 !
 address-family ipv4 unicast autonomous-system 90
  topology base
   redistribute rip metric 1000 200 255 1 1500
 !
 address-family ipv6 unicast autonomous-system 90
  topology base
   redistribute rip RIP_DOMAIN metric 1000 200 255 1 1500
!
router rip
 redistribute eigrp 90 metric 6
!
ipv6 router rip RIP_DOMAIN
 redistribute eigrp 90 metric 5

Из EIGRP в OSPF и обратно для обоих address-family.

router eigrp EIGRP_DOMAIN
 !
 address-family ipv4 unicast autonomous-system 90
  topology base
   redistribute ospfv3 110 metric 2000 200 255 1 1500
 !
 address-family ipv6 unicast autonomous-system 90
  topology base
   redistribute ospf 110 metric 2000 200 255 1 1500
!        
router ospfv3 110
 address-family ipv4 unicast
  redistribute eigrp 90 metric-type 1
 !
 address-family ipv6 unicast
  redistribute eigrp 90 metric-type 1

Для EIGRP почему-то ключи немного разнятся. ospfv3 в случае IPv4 и просто ospf в случае IPv6...


7. IPv6
- Configure RIPng
- OSPFv3 migration (new configuration approach)
- Named EIGRP migration
- BGP IPv6 over IPv6
- BGP IPv6 over IPv4