Данная статья является частью исследования на тему «Методики внедрения сетевого протокола IPv6 в сетях провайдеров».
Ключевые слова:IPv4, IPv6, построение таблиц FIB, LFIB, OSPF, временные характеристики, сходимость.
В сети провайдера сетевого доступа протокол маршрутизации является средством автоматического контроля достоверности информации о маршрутизации и средством применения изменений в топологии к структуре маршрутизации.
В качестве базового протокола маршрутизации для исследования и сравнения особенностей работы IP протоколов 4-ой и 6-ой версий был выбран протокол OSPF, как единственный широко используемый непроприетарный IGP протокол. В качестве характеристик исследования выбраны основные – латентность пропагации изменений и время сходимости топологии.
Время принятия решения о маршрутизации пропорционально размеру таблиц FIB и производной LFIB таблицы для топологий с использованием MPLS – потому в качестве фактора оценки временных характеристик применения изменений был выбран размер создаваемой протоколом маршрутизации таблицы без ручной агрегации маршрутов.
Временем сходимости протокола является время, за которое протокол маршрутизации сможет обработать событие изменения в топологии и установить во все маршрутизаторы домена протокола записи таблицы маршрутизации, соответствующие текущему состоянию. Это время будет измеряться временным промежутком с момента возникновения этих изменений до момента внесения окончательных корректных изменений в таблицу маршрутизации крайнего в топологии маршрутизатора.
В качестве топологии исследования была выбрана схема с рисунка 1- три маршрутизатора, каждый из которых имеет собственную тупиковую сеть и соединён с каждым из двух остальных двумя сетевыми сегментами.
Рис. 1. Топология исследования особенностей работы протокола маршрутизации OSPF с IP протоколами 4-ой и 6-ой версий
Согласно правилам работы протокола IPv4 каждое звено графа IP сети должно быть отдельным IP сегментом. Учитывая наличие на каждом из звеньев по 2 активных абонента-маршрутизатора, общая потребность в IP-сегментах составляет 4 адреса на звено (2 абонента, броадкаст адрес и адрес сети) – сети с маской 30 (или 255.255.255.252 в побитово-десятичном представлении). Адреса логических петлевых интерфейсов могут иметь маску 32 (255.255.255.255 в побитово-десятичном представлении). В целом, на организация топологии необходимо выделение 9-ти сетевых сегментов. На рисунке 2 представлены настройки топологии IP протоколом версии 4:
Рис. 2. Схема настройки топологии IP протоколом версии 4
Использование IPv6 не требует обязательной адресации каждого сегмента сети явными адресами. Объясняется это тем, что каждый интерфейс поумолчанию обладает собственным «link-local» адресом из пространства адресов fe80:: /10, что при автоконфигурации может дополняться МАС-адресом интерфейса в расширенной форме с добавлением сегмента FF:FE (или МАС-адреса первого ethernet-интерфейса). Этот адрес никогда не пропагируется (информация о нём не распространяются протоколами маршрутизации) – что не позволяет обращаться к хосту по этому адресу никому, кроме устройства, разделяющего один канал с интерфейсом маршрутизатора, на котором находится этот адрес. Для конечных сетей маршрутизации это создаёт необходимость существования ещё одного (глобального) адреса интерфейса. Но в ядре сети провайдера, где нет необходимости раскрытия структуры сети конечным хостам и делать доступной структуру сети для соединения извне для задач класса мониторинга, необходимость предоставления глобального адреса интерфейсу отпадает.
Наличие «link-local»-адреса позволяет работать передаче пакетов между двумя соседними хостами сети . Адресация в сети необходима только петлевым интерфейсам, что являются кольцевыми сетями. Схема адресации сети исследования для IP протокола версии 6 приведена на рисунке 3.
Рис. 3. Схема настройки топологии IP протоколом версии 6
Для упрощения настройки протокола маршрутизации OSPF и обработки балансировки нагрузки на интерфейсах, интерфейсы могут быть объединены в ether-группы или настроены по «unnumbered» сценарию. Но, учитывая, что данная топология исследует общий случай подключения с учётом универсальности подхода, без акцента на Ethernet-природу соединений, данные типы усовершенствований не использовались.
Таблицы маршрутизации устройств сети симметричны с точностью до номера подсети – количество записей, что содержатся согласно соответствующим сетевым протоколам, на каждом маршрутизаторе одинакова. Ниже приведена сравнительная таблица 1 полученных таблиц маршрутизации для IP протоколов версии 4 и версии 6:
Таблица 1
Таблицы маршрутизации в симметричной топологии исследования для IP протоколов версии 4 и версии 6
Таблица маршрутизации устройства R3 в IPv4 сети з протоколом маршрутизации OSPFv2 |
Таблица маршрутизации устройства R3 в IPv6 сети с протоколом маршрутизации OSPFv3 |
R3(config)#do show ip route 10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks O 10.0.0.1/32 [110/11] via 10.0.13.5, 00:00:28, Eth0/3 [110/11] via 10.0.13.1, 00:00:28, Eth0/2 O 10.0.0.2/32 [110/11] via 10.0.23.5, 00:00:28, Eth0/1 [110/11] via 10.0.23.1, 00:00:28, Eth0/0 C 10.0.0.3/32 is directly connected, Loopback0 O 10.0.12.0/30 [110/20] via 10.0.23.5, 00:00:28, Eth0/1 [110/20] via 10.0.23.1, 00:00:28, Eth0/0 [110/20] via 10.0.13.5, 00:00:28, Eth0/3 [110/20] via 10.0.13.1, 00:00:28, Eth0/2 O 10.0.12.4/30 [110/20] via 10.0.23.5, 00:00:28, Eth0/1 [110/20] via 10.0.23.1, 00:00:28, Eth0/0 [110/20] via 10.0.13.5, 00:00:28, Eth0/3 [110/20] via 10.0.13.1, 00:00:28, Eth0/2 C 10.0.13.0/30 is directly connected, Eth0/2 L 10.0.13.2/32 is directly connected, Eth0/2 C 10.0.13.4/30 is directly connected, Eth0/3 L 10.0.13.6/32 is directly connected, Eth0/3 C 10.0.23.0/30 is directly connected, Eth0/0 L 10.0.23.2/32 is directly connected, Eth0/0 C 10.0.23.4/30 is directly connected, Eth0/1 L 10.0.23.6/32 is directly connected, Eth0/1 |
R3_ipv6#show ipv6 route O 2001::1/128 [110/10] via FE80::A8BB:CCFF:FE00:B30, Ethernet0/3 via FE80::A8BB:CCFF:FE00:B20, Ethernet0/2 O 2001::2/128 [110/10] via FE80::A8BB:CCFF:FE00:C20, Ethernet0/0 via FE80::A8BB:CCFF:FE00:C30, Ethernet0/1 LC 2001::3/128 [0/0] via Loopback0, receive L FF00::/8 [0/0] via Null0, receive |
Таблица маршрутизации по IP протоколу версии 4 составляет 21-у запись, в то время как таблица маршрутизации по IP протоколу версии 6 состоит из 6-ти записей. Это означает, что размер FIB и LFIB таблиц при меточной маршрутизации и время на её компиляцию будет существенно меньше при использовании IP протокола версии 6 учитывая рекурсивность и n2-порядок задачи компиляции LFIB таблицы.
Время сходимости топологии для протоколов «состояния звена», которым является протокол OSPF, зависит только от скорости формирования, доставки и применения обновлений об изменениях в топологии, так как каждый из маршрутизаторов самостоятельно обрабатывает информацию обновления об изменениях в топологии и не зависит от временного фактора обработки обновлений другими маршрутизаторами (что свойственно дистанционно-векторным протоколам). Потому для исследования был выбран метод отключения активного в протоколе OSPF логического петлевого интерфейса на маршрутизаторе «R1» и отладка процесса установки изменений в таблицу маршрутизации по временному фактору на маршрутизаторе «R3». Время на маршрутизаторах было синхронизировано средствами протокола «NTP».
Вывод команд отладки отключения интерфейса «Loopback0» в сети IP протоколу версии 4 приведено в таблице 2
Таблица 2
Отладка отключения интерфейса «Loopback0» в сети IP протокола версии 4
Логи маршрутизаторов R1 и R3 |
|
Маршрутизатор R1 |
R1(config)#int lo 0 R1(config-if)#shut R1(config-if)# *May 5 00:02:25.299: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down *May 5 00:02:26.299: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down |
Маршрутизатор R3 |
R3#debug ip routing IP routing debugging is on R3# *May 5 00:02:29.454: RT: del 10.0.0.1 via 10.0.13.1, ospf metric [110/11] *May 5 00:02:29.454: RT: del 10.0.0.1 via 10.0.13.5, ospf metric [110/11] *May 5 00:02:29.454: RT: delete subnet route to 10.0.0.1/32 |
Суммарное время внесения изменения составляет 3.155 секунд. Такое время объясняется 2-мя секундными задержками:
искусственной программной задержкой перед отправкой обновления,
искусственной программной задержкой перед обработкой обновления.
Все эти задержки описаны в стандарте имплементации протокола OSPF и необходимы для обработки исключений нестабильных интерфейсов.
Для IP протокола версии 6 время эксперимент на время сходимости топологии указан в таблице 3 3:
Таблица 3
Отладка отключения интерфейса «Loopback0» в сети IP протокола версии 6
Логирование работы протокола маршрутизации |
|
Маршрутизатор R1 |
R1_ipv6(config)# *May 4 23:58:20.719: %LINK-5-CHANGED: Interface Loopback1, changed state to administratively down *May 4 23:58:21.719: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to down |
Маршрутизатор R3 |
R3_ipv6# *May 4 23:58:24.163: IPv6RT[default]: ospf 1, Route add 2001::2/128 [owner] *May 4 23:58:24.163: IPv6RT[default]: ospf 1, Route add 2001::2/128 [owner] *May 4 23:58:24.163: IPv6RT[default]: ospf 1, Route add 2001::1/128 [owner] *May 4 23:58:24.163: IPv6RT[default]: ospf 1, Route add 2001::1/128 [owner] *May 4 23:58:24.163: IPv6RT[default]: ospf 1, Delete all next-hops for 2001::11/128 *May 4 23:58:24.163: IPv6RT[default]: ospf 1, Delete 2001::11/128 from table *May 4 23:58:24.167: IPv6RT[default]: Event: 2001::11/128, Del, owner ospf, previous None |
Суммарное время внесение измененений составляет 3.458 секунд. Время обработки – 3.458 сек. против 3.155 секунд часу IP протокола версии 4 и формирует разницу сходимости по времени в 8.78 %. Это разница обусловлена большей размерностью матриц обработки по алгоритму SPF для протокола версии 6. Величина задержки зависит и от количества подсетей в домене протокола маршрутизации – обработки изменений каждым из маршрутизаторов выполняется отдельно после массовой рассылки обновлений с изменениями топологии, но матрицы SPF-алгоритма формируются на каждую подсеть. Потому это время будет увеличиваться с увеличением количества сетевых сегментов.
В целом, с точки зрения маршрутизации, IP протокол версии 6 значительно сокращает временные характеристики и ресурсоёмкость принятия решения о маршрутизации или меточной маршрутизации и значительно уменьшает требования к адресному пространству и длине таблицы маршрутизации. Это делает его более приоритетным для использования в большой стабильной сети класса ядра провайдера. Обработка изменений в сети занимает большие временные задержки – в эксперименте они составили порядка 10% - что создаёт предусловия необходимости отладки процесса сходимости за счёт уменьшения аддитивных 2-х секундных таймеров-задержек.
Учитывая тот факт, что стабильная работа составляет большую часть работы сети провайдера, IP протокол версии 6 имеет преимущества перед IP протоколом версии 4. Проявляется это, прежде всего в аспекте издержек на принятие решения о маршрутизации. Это весьма существенно в учете вопросов ресурсоёмкости для больших сетей и экономит время генерации LFIB таблиц ввиду уменьшения количества меток, необходимых для индексации соединений между маршрутизаторами в ядре сети.
Литература:
1. IPv4 Address Report. Під ред. Geoff Huston Centre for Advanced Internet Architectures [Блог] – Режим доступа: http://www.potaroo.net/tools/ipv4 .
2. DDoS and Security Reports: The Arbor Networks Security Blog. Под ред. Bill Cerveny What Will Trigger Widespread Worldwide IPv6 Deployment? [Блог]: Режим доступа: http://ddos.arbornetworks.com/2011/12/what-will-trigger-widespread-worldwide-ipv6-deployment/.
3. Google Official Blog. Під ред. Lorenzo Colitti World IPv6 Day begins 24 hours from now. Websites, start your engines. [Блог] : Режим доступа: http://googleblog.blogspot.com/2011/06/world-ipv6-day-begins-24-hours-from-now.html
4. Google over IPv6 Под ред. Lorenzo Colitti. Access Google services over IPv6 [Блог] . – Режим доступа: http://www.google.com/intl/en/ipv6/