Далее по плану у нас следующее
9. Infrastructure
- NAT
- PBR
- IP SLA
- IPv6 (ND, SLAAC, DHCP)
- DHCP Server and Relay (IPv4/IPv6)
- NAT
- PBR
- IP SLA
- IPv6 (ND, SLAAC, DHCP)
- DHCP Server and Relay (IPv4/IPv6)
NAT
В терминологии Cisco есть три варианта
- Dynamic NAT - это NAT типа "один-к-одному", когда группа внутренних IP транслируется в группу внешних.
- Static NAT - это NAT "один-к-одному", но соотношения адресов (т.е. сами трансляции) нужно указывать руками.
- PAT - трансляция группы адресов в один, для отличия клиентов друг от друга используются номера портов.
Помимо этого, трансляцию адресов можно разделить ещё на две группы:
- Source NAT - когда транслируется адрес источника
- Destination NAT - когда транслируется адрес назначения
Выше обозначенные типы часто сокращают до DNAT и SNAT, что вводит в заблуждение, заставляя SourceNAT путать со StaticNAT. Короче, каждый вводит свою терминологию в это дело. Как-нибудь расскажу про Chekpoint, там вообще красота.
Приступим к настройке.
"Натить", понятное дело, можно где угодно, но в нашей топологии логично было бы делать это где-то в ядре. Либо на самих бордерах B4/E1/R1 и B5/E2/01 (самый очевидный вариант), либо на E3/R2 и E4/О2. В нашем случае так себе вариант...
В рамках CCNP Route нет ни слова про отказоустойчивость. Поэтому можно просто выделить по одному "белому" адресу на каждый NAT роутер и натить через него. В таком случае, возможна ситуация, когда трафик ушел с одного роутера, а вернулся на другой. У того, само собой, нет никаких соответствующих NAT трансляций, поэтому трафик будет сброшен. Мы, конечно же, можем проигнорировать этот факт, ведь в экзаменационных темах его нет. Если бы я руководствовался таким подходом, то я бы уже, наверное, давно закончил лабу... Но мы попробуем сделать все более или менее правильно и не особо запариваясь одновременно.
Также добавим один дополнительный линк, я достаточно наигрался с кривизной дизайна. В текущем варианте у нас нет прямого линка между бордерами.
Приводит это к ряду нежелательных последствий:
- Возможность возникновения петель маршрутизации, когда трафик от одного бордера направляется к другому. В таком случае, трафик начнет двигаться назад в "глубину" ядра (ух, сказанул...) сети и может вернуться на тот же бордер под действием маршрута по умолчанию.
- В такой топологии ядро сети перегружено лишним трафиком.
- Использование HSRP между бордерами сильно затрудняется, потому что по факту нет такой подсети, в которой находились бы сразу два бордера одновременно.
Добавим линк, который соединяет B4/E1/R1 и B5/E2/01.
Само собой его нужно настроить. Сначала на E1, а потом и на E2.
interface Ethernet1/3
ip address 10.30.12.1 255.255.255.248
!
router eigrp EIGRP_DOMAIN
address-family ipv4 unicast autonomous-system 90
af-interface Ethernet1/3
no shutdown
no passive-interface
exit-af-interface
interface Ethernet1/0
ip address 10.30.12.2 255.255.255.248
!
router eigrp EIGRP_DOMAIN
address-family ipv4 unicast autonomous-system 90
af-interface Ethernet1/0
no shutdown
no passive-interface
exit-af-interface
Далее настроим HSRP на первом и на втором устройстве. Первый будет активным членом группы, второй на подхвате с приоритетом 90.
interface Ethernet1/3
standby 1 preempt
standby 1 ip 10.30.12.3
standby 1 preempt
standby 1 ip 10.30.12.3
interface Ethernet1/0
standby 1 preempt
standby 1 ip 10.30.12.3
standby 1 preempt
standby 1 ip 10.30.12.3
standby 1 priority 90
Теперь можно настраивать NAT.
Dynamic NAT
- Создаем ACL для того чтобы определить те адреса, которые будем транслировать.
- Определяем pool адресов в которые будем транслировать адреса из ACL.
- Распределение интерфейсов на inside/outsude
- Ассоциируем ACL с пулом командой ip nat inside.
Сначала на E1
access-list 1 permit 10.0.0.0 0.255.255.255
access-list 1 permit 192.168.0.0 0.0.255.255
access-list 1 permit 192.168.0.0 0.0.255.255
!
ip nat pool DynNAT 100.0.0.10 100.0.0.20 netmask 255.255.254.0
!
interface Ethernet0/0
ip nat inside
!
interface Ethernet0/1
ip nat outside
!
interface Ethernet0/2
ip nat inside
!
interface Ethernet0/3
ip nat outside
!
interface Ethernet1/3
ip nat inside
!
ip nat inside source list 1 pool DynNAT
ip nat inside
!
interface Ethernet0/1
ip nat outside
!
interface Ethernet0/2
ip nat inside
!
interface Ethernet0/3
ip nat outside
!
interface Ethernet1/3
ip nat inside
!
ip nat inside source list 1 pool DynNAT
Т.к. Е1 у нас сейчас активная HSRP нода, можно даже попробовать NAT на работоспособность. С самого дальнего и кривого O9 попингуем 103.0.0.1, который находится в глобальной сети на B1.
Трансляция тоже появилась.
Хочу заметить, что наш пул несоразмерно мал по отношения к тем адресам, который мы собрались транслировать, так что буквально 10 трансляций его истощат. В реальной жизни так делать не надо.
На E2 делаем симметричный конфиг, затем переводим его в состояние Active повышением приоритета до 150 и тестируем.
С O9 все работает, не буду утомлять читателя лишними скриншотами.
Теперь давайте сделаем все по-человечески. Ведь сейчас у нас два отдельных устройства, которые натят устройства во внешний мир. Как я уже говорил, трафик может выйти в публичную сеть с одного устройства, а попасть назад на другое. Сейчас такой трафик будет сброшен, потому как второе устройство не сможет произвести обратный NAT, ведь у него нет соответствующей трансляции. Попробуем эти самые трансляции синхронизировать между устройствами.
Для начала дадим нашим HSRP процессам имя. Конфигурация интерфейса теперь будет выглядеть следующим образом.
interface Ethernet1/3
ip address 10.30.12.1 255.255.255.248
ip nat inside
ip virtual-reassembly in
standby 1 name NAT_HA
standby 1 ip 10.30.12.3
standby 1 preempt
end
Далее, запускаем Statefull NAT процесс на каждом устройстве.
ip nat Stateful id 100
redundancy NAT_HA
mapping-id 1
protocol udp
Далее, нам надо модифицировать команду ip nat inside source list 1 pool DynNAT таким образом, чтобы процесс NATа начал использовать stateful конфигурацию. Поэтому на каждом устройстве выполняем
no ip nat inside source list 1 pool DynNAT
ip nat inside source list 1 pool DynNAT mapping-id 1
После чего в консоли можно заметить приятные инженеру строки.
*Nov 1 06:50:43.874: %SNAT-5-PROCESS: Id 100, System starts converging
*Nov 1 06:50:46.083: SNAT (Receive): CONVERGENCE Message from Router-Id: 100 for Router-Id: 0's entries
*Nov 1 06:50:46.083: %SNAT-5-PROCESS: Id 100, System fully converged
*Nov 1 06:50:48.091: %SNAT-5-PROCESS: Id 100, System starts converging
*Nov 1 06:50:48.958: %SNAT-5-PROCESS: Id 100, System fully converged
Также можно проверить тот факт, что роутеры друг друга видят и все хорошо.
Конфигурация:
Ну тут все понятно, трансляция будет присутствовать всегда, потому как создана статически.
POOL тут тоже не нужен, а вот ACL пригодится.
Конфигурация.
ip nat inside source list 1 interface et0/1 overload
Таким нам предлагается настроить NAT в рамках CCNP Route. Во-первых, указать два интерфейса не получится. Во-вторых, указать mapping-id тоже...
По традиции немного дополним курс CCNP Route. Для начала настроим NAT не в интерфейс, а в POOL, но укажем ключ overload. Таким образом NAT будет происходить в несколько адресов, но при этом не в соотношении один-к-одному. А в каком? Это пожалуй, предмет, отдельного поста. )
После такой конфигурации все будет работать. Безусловно можно создать и пул состоящий только из одного адреса. Например так.
ip nat pool ONE_IP 100.0.0.11 100.0.0.11 netmask 255.255.255.0
Небольшая визуализация.
На смену классическому подходу пришел NVI - NAT Virtual Interface. На самом деле он всегда и был, просто на него никто не обращал внимания...
У NVI подхода есть одно большое отличие - порядок обработки трафика и оно следующее routing - NAT - routing. Маршрутизация выполняется два раза. NVI вообще это такой виртуальный интерфейс, в который просто запихиваешь трафик и он его выплевывает уже отначеным.
Возвращаясь с прошлому примеру. Теперь обратный трафик приходит от сервера на роутер, тот смотрит есть ли для него трансляции (если NAT включен на интерфейсе). Трансляция есть, трафик уходит на NVI и "разначивается", а потом снова роутится согласно таблице маршрутизации.
Сама конфигурация отличается только заменой ip nat inside и ip nat outside на ip nat enable.
Что же умеет PBR? Если кратко, то он дает возможность вмешиваться в процесс маршрутизации. Если какой-то трафик просто нужно взять и отправить в другое место, то это про PBR.
Для конфигурирования используется route-map со всм богатством match правил.
А вот set правил используется несколько. Для каждого правила можно указывать несколько сущностей. Например, set ip next-hop 192.168.0.1 192.168.2.10
Быстренько настроим на O4.
Куда пойдет трафик на 103.0.0.1? По дефолтному маршруту к 10.10.0.1. А что если направить его в другую сторону? Скажем, в сторону О6 на адрес 10.10.46.2. Для этого создаем ACL, пишим route-map и применяем его на интерфейс.
ip access-list extended VIA_O6
permit ip any host 103.0.0.1
!
route-map PBR permit 10
match ip address VIA_O6
set ip next-hop 10.10.46.2
!
route-map PBR permit 20
!
interface Ethernet0/2
ip policy route-map PBR
Стоить помнить, что настроенный policy-map применяется только на транзитный трафик. Если трафик был сгенерирован самим роутером, то конструкция должны быть несколько другой. Поэтому тестить нужно с другого устройства, например с О7. Ниже трассировки до и после применения PBR.
А что если именить роут-мап и добавить ключ default?
route-map PBR permit 10
match ip address VIA_O6
set ip next-hop 10.10.46.2
set ip default next-hop 10.10.46.2
Изменится ли трасировка? Ключ этот означает, что сначала будет попытка "обычной" маршрутизации, а в случае неудачи будет произведен PBR. Но в нашем случае трасировка останется прежней, потому что у O4 есть только маршрут по умолчанию до 103.0.0.1, а он в такой ситуации в счет не идет.
Что касается локальных пакетов. Чтобы PBR применился к трафику, который генерируется локально, нужно применять политику следующей командой глобально.
ip local policy route-map PBR
IP SLA позволяет брать некие пробы в сети. Такой объект как tracking позволяет отслеживать состояние такой пробы.
В IP SLA довольно много проб. Начиная от простых, где не нужен responder на втором конце (icmp например). И заканчивая измерением задержек, джиттера и прочего такого. В таком случае на удаленном конце должен быть настроен процесс, который будет работать в паре с опрощиком.
С O9 все работает, не буду утомлять читателя лишними скриншотами.
Теперь давайте сделаем все по-человечески. Ведь сейчас у нас два отдельных устройства, которые натят устройства во внешний мир. Как я уже говорил, трафик может выйти в публичную сеть с одного устройства, а попасть назад на другое. Сейчас такой трафик будет сброшен, потому как второе устройство не сможет произвести обратный NAT, ведь у него нет соответствующей трансляции. Попробуем эти самые трансляции синхронизировать между устройствами.
Для начала дадим нашим HSRP процессам имя. Конфигурация интерфейса теперь будет выглядеть следующим образом.
interface Ethernet1/3
ip address 10.30.12.1 255.255.255.248
ip nat inside
ip virtual-reassembly in
standby 1 name NAT_HA
standby 1 ip 10.30.12.3
standby 1 preempt
end
Далее, запускаем Statefull NAT процесс на каждом устройстве.
ip nat Stateful id 100
redundancy NAT_HA
mapping-id 1
protocol udp
Далее, нам надо модифицировать команду ip nat inside source list 1 pool DynNAT таким образом, чтобы процесс NATа начал использовать stateful конфигурацию. Поэтому на каждом устройстве выполняем
no ip nat inside source list 1 pool DynNAT
ip nat inside source list 1 pool DynNAT mapping-id 1
После чего в консоли можно заметить приятные инженеру строки.
*Nov 1 06:50:43.874: %SNAT-5-PROCESS: Id 100, System starts converging
*Nov 1 06:50:46.083: SNAT (Receive): CONVERGENCE Message from Router-Id: 100 for Router-Id: 0's entries
*Nov 1 06:50:46.083: %SNAT-5-PROCESS: Id 100, System fully converged
*Nov 1 06:50:48.091: %SNAT-5-PROCESS: Id 100, System starts converging
*Nov 1 06:50:48.958: %SNAT-5-PROCESS: Id 100, System fully converged
К слову, вся эта Stateful NAT конструкция может работать и без HSRP. Ну да ладно, посмотрим на команды верификации. Но перед этим запустим какой-нибудь трафик через NAT.
Итак, таблица трансляций на обоих роутерах синхронизировалась.
Также можно проверить тот факт, что роутеры друг друга видят и все хорошо.
Static NAT
До этого мы рассматривали динамическую трансляцию адресов, теперь посмотрим статическую. Отличается она отсутствием ACL и POOLа.Конфигурация:
1. Создаем static маппинг адресов.
2. Распределение интерфейсов на inside/outsude
Я удалил ip nat inside source list 1 pool DynNAT, можно попробовать настроить Static NAT. Как видно, для синхронизации снова используем наш Stateful NAT процесс.
ip nat inside source static 10.10.39.2 100.0.0.20 mapping-id 1
Я удалил ip nat inside source list 1 pool DynNAT, можно попробовать настроить Static NAT. Как видно, для синхронизации снова используем наш Stateful NAT процесс.
ip nat inside source static 10.10.39.2 100.0.0.20 mapping-id 1
Ну тут все понятно, трансляция будет присутствовать всегда, потому как создана статически.
PAT/NAT Overload
Теперь настроить PAT и будет транслировать целые подсети всего лишь в один адрес. Прошлый ip nat inside source static я удалил, само собой.POOL тут тоже не нужен, а вот ACL пригодится.
Конфигурация.
1. Создаем ACL для того чтобы определить те адреса, которые будем транслировать.
2. Распределение интерфейсов на inside/outsude
3. Запускаем NAT на ACL с ключом overload.
Первые два пункта у нас уже готовы, поэтому нужно дать следующие команды.
На B4/E1/R1 натим сразу в два интерфейса... хм... а вот указать можно только один...
ip nat inside source list 1 interface et0/1 overload
На B5/E2/O1 в один.
Первые два пункта у нас уже готовы, поэтому нужно дать следующие команды.
На B4/E1/R1 натим сразу в два интерфейса... хм... а вот указать можно только один...
ip nat inside source list 1 interface et0/1 overload
На B5/E2/O1 в один.
ip nat inside source list 1 interface et0/1 overload
Таким нам предлагается настроить NAT в рамках CCNP Route. Во-первых, указать два интерфейса не получится. Во-вторых, указать mapping-id тоже...
По традиции немного дополним курс CCNP Route. Для начала настроим NAT не в интерфейс, а в POOL, но укажем ключ overload. Таким образом NAT будет происходить в несколько адресов, но при этом не в соотношении один-к-одному. А в каком? Это пожалуй, предмет, отдельного поста. )
ip nat inside source list 1 pool DynNAT mapping-id 1 overload
После такой конфигурации все будет работать. Безусловно можно создать и пул состоящий только из одного адреса. Например так.
ip nat pool ONE_IP 100.0.0.11 100.0.0.11 netmask 255.255.255.0
NVI
У всех предыдущих примеров настройки NATа есть один большой косяк. Допустим, к роутеру подключен ещё и сервер, который находится в DMZ. Для него настроен статический NAT. Проблема в том, что клиент из локальной сети до такого сервера не будет иметь доступ. Причина в том, как работает NAT в его классическом варианте. Трафик от клиента попадет на роутер в inside интерфейс, смаршрутизируется на outside интерфtйс, там произойдет трансляция, после чего трафик уйдет на сервер. Проблема в обратном трафике. Трафик от сервера попадет на интерфейс в который подключен сервер. Тут должна произойти обратная последовательность NAT и затем routing. Но обратный трафик не попадет на outside интерфейс, весь сервер подключен к inside. А значит обратная трансляция не произойдет. Таким образом, трафик не будет натится и обратный трафик не дойдет до пользователя.Небольшая визуализация.
На смену классическому подходу пришел NVI - NAT Virtual Interface. На самом деле он всегда и был, просто на него никто не обращал внимания...
У NVI подхода есть одно большое отличие - порядок обработки трафика и оно следующее routing - NAT - routing. Маршрутизация выполняется два раза. NVI вообще это такой виртуальный интерфейс, в который просто запихиваешь трафик и он его выплевывает уже отначеным.
Возвращаясь с прошлому примеру. Теперь обратный трафик приходит от сервера на роутер, тот смотрит есть ли для него трансляции (если NAT включен на интерфейсе). Трансляция есть, трафик уходит на NVI и "разначивается", а потом снова роутится согласно таблице маршрутизации.
Сама конфигурация отличается только заменой ip nat inside и ip nat outside на ip nat enable.
PBR
Штука интересная, но довольно сомнительная. Не уверен насчет новых платформ, но вот на старых выполнялась на CPU, что могло эффективно положить устройсто. Важно понимать, что PBR срабатывает сразу после деинкапсуляции пакета, сразу перед попаданием в CEF.Что же умеет PBR? Если кратко, то он дает возможность вмешиваться в процесс маршрутизации. Если какой-то трафик просто нужно взять и отправить в другое место, то это про PBR.
Для конфигурирования используется route-map со всм богатством match правил.
А вот set правил используется несколько. Для каждого правила можно указывать несколько сущностей. Например, set ip next-hop 192.168.0.1 192.168.2.10
- set ip next-hop - трафик может быть перенаправлен в connected подсеть. Если указано несколько адресов, то будет выбран первый доступный. В случае неудачи, маршрутизация будет происходит согласно таблице маршрутизации.
- set ip default next-hop - трафик будет отправлен согласно таблице маршрутизации (default route учитываться не будет!), в случае неудачи, будет применен PBR.
- set interface - трафик будет перенаправлен в первый поднятый в списке интерфейс. В случае неудачи, маршрутизация будет происходит согласно таблице маршрутизации.
- set default interface - трафик будет отправлен согласно таблице маршрутизации (default route учитываться не будет!), в случае неудачи, будет применен PBR.
Быстренько настроим на O4.
Куда пойдет трафик на 103.0.0.1? По дефолтному маршруту к 10.10.0.1. А что если направить его в другую сторону? Скажем, в сторону О6 на адрес 10.10.46.2. Для этого создаем ACL, пишим route-map и применяем его на интерфейс.
ip access-list extended VIA_O6
permit ip any host 103.0.0.1
!
route-map PBR permit 10
match ip address VIA_O6
set ip next-hop 10.10.46.2
!
route-map PBR permit 20
!
interface Ethernet0/2
ip policy route-map PBR
Стоить помнить, что настроенный policy-map применяется только на транзитный трафик. Если трафик был сгенерирован самим роутером, то конструкция должны быть несколько другой. Поэтому тестить нужно с другого устройства, например с О7. Ниже трассировки до и после применения PBR.
А что если именить роут-мап и добавить ключ default?
route-map PBR permit 10
match ip address VIA_O6
set ip next-hop 10.10.46.2
set ip default next-hop 10.10.46.2
Изменится ли трасировка? Ключ этот означает, что сначала будет попытка "обычной" маршрутизации, а в случае неудачи будет произведен PBR. Но в нашем случае трасировка останется прежней, потому что у O4 есть только маршрут по умолчанию до 103.0.0.1, а он в такой ситуации в счет не идет.
Что касается локальных пакетов. Чтобы PBR применился к трафику, который генерируется локально, нужно применять политику следующей командой глобально.
ip local policy route-map PBR
IP SLA
PBR это хорошо, но в связке с IP SLA лучше.IP SLA позволяет брать некие пробы в сети. Такой объект как tracking позволяет отслеживать состояние такой пробы.
В IP SLA довольно много проб. Начиная от простых, где не нужен responder на втором конце (icmp например). И заканчивая измерением задержек, джиттера и прочего такого. В таком случае на удаленном конце должен быть настроен процесс, который будет работать в паре с опрощиком.
Как я уже упоминал, можно настроить tracking на IP SLA, который будет отслеживать его состояние. А уже на это состояние можно полагаться, скажем, PBR при выполнении маршрутизации. Tracking объекты можно использовать и в обычных маршрутах, и в HSRP и вообще много где.
Итак, за О8 находится сервер, к которому должна иметь доступ вся сеть. Проблема в том, что про его существование мы узнаем только по статическому маршруту, который редистрибуцирован в OSPF процесс. Даже если сервер станет недоступен, маршрут до него все равно останется и трафик будет просто уходить в никуда. Здесь ситуацию можно элегантно подправить с помощью IPSLA + Tracking + route.
Настраиваем IP SLA на простой пинг хоста и запускаем его отныне и навсегда. Далее создаем tracking объект, где указываем небольшую задержку на срабатывание. Следующим шагом добавляем этот объект к статическому маршруту.
ip sla 1
icmp-echo 192.168.0.100
!
ip sla schedule 1 life forever start-time now
!
track 1 ip sla 1 state
delay down 3 up 3
!
ip route 192.168.0.0 255.255.255.0 10.10.100.2 track 1
Судя по выводу, сейчас все хорошо. А значит маршрут сущесвтует и добавлен в OSPF процесс.
Выключаем сервер и смотрим, что произойдет. Видим сообщение об изменении состояния tracking объекта. Смотрим, SLA в timeout состоянии, tracking в down. Соотвественно, маршрут ушел из таблицы, а значит не будет анонсирован всей сети. Таким образом, мы не будем "блэкхолить" трафик.
Придумать относительно нормальный и ненадуманный варинат использорвания PBR + IP SLA в моей топологии у меня не получилось...Поэтому просто дополним PBR конфигцрацию из прошлого примера.
route-map PBR permit 10
match ip address VIA_O6
set ip next-hop 10.10.46.2
Для того чтобы добавить сюда верификацию того, что достич 10.10.46.2 все же можно, надо добавить соотвесвтующий ключ, tracking object и IP SLA.
route-map PBR permit 10
match ip address VIA_O6
set ip next-hop verify-availability 10.10.46.2 1 track 1
!
ip sla 1
icmp-echo 103.0.0.1
!
track 1 ip sla 1
delay down 3 up 3
IPv6 (ND, SLAAC, DHCP)
Тема IPv6 мне очень нравится, но в все эти способы получения адресов у меня держаться плохо... Давайте консолидируем как же можно настраивать IPv6. В будущем нужно написать об этом отдельный пост. Очень большое упущение в блоге. К слову, речь идет не только про роутеры и прочие сетевые железки, но так же и про конечныые хосты.- Руками. Я это уже делал.
- SLAAC или Stateless address autoconfiguration. Позволяет конфигурировать адреса клиентов без участия DHCP только нативными средствами IPv6. Это очень крутая фича в IPv6. Если кратко, то роутеры шлют специальное сообщение RA в подключенную сеть, где рассказывают про префикс и вообще о себе. Клиенты получив такое сообщение понимают, какой префикс нужно использовать и генерируют хостовую часть адреса из своего MAСа с помощью EUI-64.
- Stateless DHCP. Работает в комбинации с SLAAC. Хост получает префикс, генерирует адрес, понимает кто из роутеров является default gateway. Далее роутер ему рассказывает, что за дополнительной конфигурацией стоит обратиться к DHCP серверу. Последний выдает ему DNS, дополнительные опции и прочее. Если SLAAC не сработал, то клиент начинает сам искать DHCP и пытаться у него узнать все детали.
- Stateful DHCP. Этот способ самый привычный. После старта, хост ищет DHCP сервер и получает от него все необходимые данные. Хотя не совсем так, хост получает RA от роутера, который рассказывает ему, что нужно использовать DHCP сервер. Хостовая часть по прежнему генерируется EUI-64.
Есть клиент VPC, он подключен к двум роутерам E5 и E6. Оба они будут анонсировать свои RA. Далее настроим Stateless DHCP. Сам DHCP будет настроен на E3/R2 и E4/O2. После чего отсавим на E5 и E6 только relay, все настройки будут приходить с Stateful DHCP серверов E3/R2 и E4/O2.
SLAAC
Нам нужно чтобы E5 и E6 стали выполнять функцию SLAAC "сервера". Такого термина на самом деле я не встречал, но это отражает суть их поведения. В роли клиента роутер должен посылать RS для того чтобы найти на линке другие роутеры, которые расскажут ему про префикс и прочее. В роли сервера роутер должен отвечать на такие RS своими сообщениями RA.
Перед настройкой нужно немного изменить конфигурацию E5 и E6. Расширяем подсеть до /64 и отключаем на интерфейса e0/1 EIGRP. Теперь на этих интерфейсах 2001:A:0:3056::/64 подсеть. Включаем клиента.
Уоу!.. Я вообще ничего не делал... Видим, что клиент настроил себе адрес с нужным префиксом, а хостовая часть была сгенерирована из MAC адреса.
Ладно, выкинем этот эмулятор и поставим туда роутер в режиме клиента. Нужна возможность более детальной диагностики. Например, мы можем посмотреть все роутеры в сети и их параметры. Вот preference довольно интересный параметр, например.
На какой из роутеров будет отправлен трафик? Кто маршрутизатор по-умолчанию? В данном случае, маршрутизатор E5. Просто потому что он прислал свой RA раньше.
Можно управлять этим процессом. Например, увеличив приоритет на E6 командой ipv6 nd router-preference high. Теперь трафик будет отправлен на E6.
Зацените мощь SLAAC. Вы просто добавляете несколько роутеров в сеть с одинаковым префиксом и... все. Клиенты получают префикс, назначают адреса и выбирают главный роутер. А что если он упадет? Начнет работать второй. Никаких HSRP.
Stateles DHCP
Для начала настроим DHCP сервер на E3/R2 и E4/O2. Будем выдавать DNS и доменное имя.
ipv6 dhcp pool IPV6-STATELESS
dns-server 2001:A:0:3003::1
domain-name ccnp.lab
!
interface e0/1
ipv6 dhcp server IPV6-STATELESS
Теперь проинструктируем наши SLAAC сервера E5 и E6. Они должны рассказать клиентам, что им нужно обратиться к серверу для дополнительной информацией. Для этого нужно послать соответсвующий флаг other-config-flag. Он инструктирует хосты получать адрес через SLAAC, а за остальными настройками идти на DHCP. Также придется настроить relay, который будет перенаправлять DHCP запросы на сервер.
interface Ethernet0/1
ipv6 nd other-config-flag
ipv6 dhcp relay destination 2001:A:0:3003::1
interface Ethernet0/1
ipv6 nd other-config-flag
ipv6 dhcp relay destination 2001:A:0:3003::1
Клиент подключается и получает в дополнение к SLAAC ещё и DNS сервер c доменом.
Statefull DHCP
Теперь уберем SLAAС и настроим полноценный DHCP. Сервер будет там же, да и релей в общем то там же. Нужно передать клиентам флаг managed-config-flag, котороый рассказывает клиентам, что SLAAC использовать не надо, все настройки должны быть получены от DHCP.
На E5 и E6 меняется только флаг.
interface Ethernet0/1
ipv6 nd managed-config-flag
На сервере теперь нужно указать префикс.
ipv6 dhcp pool IPV6-STATELESS
address prefix 2001:A:0:3056::/64
К сожалению, тут ещё и на клиенте придется включить dhcp в дополнении к autoconfig.
interface Ethernet0/0
ipv6 address dhcp
Теперь переталкиваем клиента и видим, что все хорошо. Сервер предоставил и префикс тоже. В чем плюс такой конфигурации? В том, что на сервере ведется статистика адресов, которые были предоставлены клиентам.
Все!
Лабу я закончил!
Комментариев нет:
Отправить комментарий