отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Описание принципов работы и конфигурации механизма PIMv2 Bootstrap router

New Member
При решении задач маршрутизации мультикастного трафика посредством протокола PIM в режиме sparse есть необходимость назначения каких-то маршрутизаторов на роль Randezvous point (RP). Каждый маршрутизатор, вовлеченный в форвардинг мультикастного трафика, должен знать, какое именно устройство выполняет роль RP. На данный момент существует три механизма, посредством которых происходит назначение маршрутизаторов на роль RP, а также распространение информации об активных RP:
1. Статическая конфигурация.
2. Алгоритм Auto-RP.
3. Механизм Bootstrap router.
В этой статье мы остановимся на рассмотрении последнего механизма, который является встроенным для протокола PIMv2 и который позволяет автоматически выбирать RP из множества кандидатов, балансировать нагрузку между несколькими RP, а также автоматически сообщать всем маршрутизаторам домена PIM об активных RP. Работу механизма bootstrap router мы будем рассматривать на примере топологии, приведенной ниже:
Работа механизма основана на выборе так называемого Bootstrap Router (BSR) из некого множества кандидатов на эту роль (Bootstrap candidate). Выбор BSR важен, поскольку именно он будет собирать (систематизировать) информацию обо всех кандидатах на роль RP и распространять ее всем маршрутизаторам в домене PIM. Таким образом, среди маршрутизаторов домена PIM администратором должны быть выбраны и настроены Bootstrap candidate и PR candidate. При этом в домене могут остаться маршрутизаторы,не назначенные ни на ту, ни на другую роль.
Впоследствии выбранный BSR "расскажет" всем маршрутизаторам PIM домена, какие RP кандидаты существуют, и какие группы они могут обслуживать. Поскольку BSR является критическим элементом, несколько остановимся на процессе его выбора среди множества Bootstrap кандидатов.

Выбор BSR
Каждый маршрутизатор, который был назначен на роль Bootstrap candidate, начинает рассылать со своего адреса специальные сообщения Bootstrap протокола PIMv2. Эти сообщения рассылаются на адрес 224.0.0.13 (зарезервирован за протоколом PIMv2) каждые 60 секунд и содержат информацию о каждом Bootstrap кандидате. В частности там будет указан адрес Bootstrap кандидата и его приоритет. Эти сообщения обрабатываются маршрутизаторами PIM домена следующим образом: каждый маршрутизатор, принявший сообщение Bootstrap, применяет к нему правила RPF check и передает его всем PIM соседям, кроме того, от которого сообщение было только что получено. RPF check сообщений Bootstrap позволяет предотвратить ненужный флудинг этих сообщений и повторную их обработку (сообщения Bootstrap, не прошедшие RPF check маршрутизаторами PIM домена попросту игнорируются).
В результате информация о Bootstrap кандидатах становится известна каждому маршрутизатору, вовлеченному в PIM домен, включая других Bootstrap кандидатов. Одновременно с этим происходит выбор одного из Bootstrap кандидатов на роль BSR. Выбор производится на основании сравнения приоритетов кандидатов. Bootstrap кандидат с наибольшим приоритетом должен стать BSR. Если приоритеты совпадают, то выбор производится в пользу маршрутизатора с наибольшим IP адресом. Кандидаты, принимающие Bootstrap сообщения от других таких же Bootstrap кандидатов, самостоятельно сравнивают приоритет (или IP адрес) другого кандидата со своим локальным. Если алгоритм выбора BSR решает не в пользу локального Bootstrap кандидата, то он (кандидат) перестает рассылать собственные сообщения Bootstrap. Благодаря этому через какое-то время в PIM домене останется только один Bootstrap кадидат, рассылающий сообщения Bootstrap (по-прежнему каждые 60 секунд). Именно он и будет выполнять роль BSR.
Следует отметить, что алгоритм выбора BSR вполне естественным образом позволяет "вытеснить" текущий BSR, если вдруг в сети появится другой маршрутизатор, назначенный на роль Bootstrap candidate, с бОльшим приоритетом или бОльшим IP адресом.

Сбор информации о RP кандидатах
Выбрать BSR на сети нужно для того, чтобы каждый маршрутизатор, назначенный на роль RP кандидата, мог сообщить об этой своей роли, а также о списке групп, которые он собирается обслуживать, маршрутизатору BSR. Происходит это посредством рассылки юникастных сообщений Candidate-RP-Advertisement от каждого RP кандидата на адрес BSR. Рассылка эта имеет периодический характер, и период отправки сообщений составляет 60 секунд по умолчанию. В результате BSR получает список всех RP кандидатов и соответствующих им диапазонов групп. Здесь следует отметить, что нет никаких правил в распределении диапазона мультикастных групп по RP кандидатам. То есть все пространство мультикастных групп 224.0.0.0/4 может быть распределено между RP кандидатами таким образом, чтобы каждый RP кандидат обслуживал какую-то свою и только свою часть этого пространства (то есть диапазоны групп, назначенные на разных RP кандидатов, не будут пересекаться). Или же можно заставить разных RP кандидатов обслуживать одни и те же или пересекающиеся диапазоны групп. Например, все пространство 224.0.0.0/4 может быть назначено для каждого RP кандидата, сколько бы их ни было.
Особенностью механизма Bootstrap router является то, что маршрутизатор, выбранный в качестве BSR, не производит выбора активных RP из всего множества кандидатов. После получения всего множества сообщений Candidate-RP-Advertisement от всех RP кандидатов BSR систематизирует полученную информацию и вносит ее в собственные сообщения Bootstrap, рассылаемые по-прежнему с периодом 60 секунд. Таким образом, все маршрутизаторы PIM домена начинают периодически получать информацию обо всех RP кандидатах и списках их групп.

Назначение активной RP
Далее начинается самое интересное. Маршрутизаторы по специальному алгоритму определяют, какие именно RP кандидаты будут назначены на роль активной RP для каждой мультикастной группы. Алгоритм берет адрес группы и список всех RP кандидатов, которые заявляют о возможности обслуживать эту группу. Далее выполняются следующие шаги:
1. Ищутся те RP кандидаты, которые заявляют наиболее специфичный диапазон групп, включающий рассматриваемую группу.
2. Если в результате остается несколько RP кандидатов, то выбираются те, для которых настроен численно меньший приоритет. Здесь стоит остановиться и сказать, что приоритет в механизме bootstrap router задается не только для Bootstrap кандидатов, но и для RP кандидатов. Именно этот приоритет и является решающим на данном этапе.
3. Если после пунктов 1 и 2 все еще осталось несколько RP кандидатов для конкретного адреса, маршрутизатор вычисляет результат hash функции, которая в качестве входных данных использует адрес группы, адрес RP кандидата и так называемую hash mask. Тот RP кандидат, для которого значение полученного hash получилось численно больше, будет назначен в качестве активной RP для рассматриваемой группы.
4. Если после пункта 3 все равно осталось несколько RP кандидатов, то кандидат с бОльшим IP адресом становится активным RP.
Рассмотрим пример работы этого алгоритма для сети, топология которой приведена выше.
На роль Bootstrap кандидатов назначены R4 и R5. Делалось это следующими командами.

R4:
R4(config)#ip pim bsr-candidate lo0 32 10
R5:
R5(config)#ip pim bsr-candidate lo0 32 5


Синтаксис команды выглядит следующим образом:
ip pim bsr-candidate interface-type interface-number [ hash-mask-length [priority] ]

В качестве интерфейсов заданы loopback0, длина hash mask равна 32 битам (об этом параметре чуть позже), приоритеты заданы 10 и 5 соответственно.
В выборах BSR победит маршрутизатор R4, поскольку для него был задан приоритет 10, а для R5 - всего лишь 5. Это хорошо видно в выводе команды sh ip pim bsr-router.

 
R6#sh ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 4.4.4.4 (?)
Uptime:      01:48:27, BSR Priority: 10, Hash mask length: 32
Expires:     00:01:17
R6#
 
На роль RP кандидатов были назначены следующие маршрутизаторы:
HostnameIP addressGroup rangePriority
R11.1.1.1224.0.0.0/41
R22.2.2.2238.0.0.0/810
R33.3.3.3238.0.0.0/810
Соответствующие команды для этой конфигурации представлены ниже:

R1:
R1(config)#ip pim rp-candidate lo0 group-list 1 priority 1
R2:
R2(config)#ip pim rp-candidate lo0 group-list 1 priority 10
R3:
R3(config)#ip pim rp-candidate lo0 group-list 1 priority 10


Пример конфигурации ACL 1, который используется для обозначения диапазона групп на R3:
R3(config)#access-list 1 permit 238.0.0.0 0.255.255.255

 
Возникает задача определить, какой RP кандидат будет назначен на роль активной RP для, например, группы 238.1.1.1.
В соответствии с первым шагом алгоритма, R1 не подходит, потому что другие кандидаты анонсируют диапазоны групп, более точно подходящие для 238.1.1.1. На основании второго шага определиться с выбором кандидата тоже не удается, поскольку R2 и R3 настроены с одинаковым приоритетом. Далее алгоритму придется посчитать два значения hash функции.
Сама функция выглядит следующим образом
Value(G,M,C(i))=(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31, где
G - адрес рассматриваемой мультикастной группы;
M - hash mask (этот параметр мы обсудим чуть позже);
C(i) - адрес RP кандидата.
Для нашего случая получаются следующие значения хешей:
R2 - 1479713549
R3 - 1916634234
Это хорошо видно из следующего вывода:
 
R6#sh ip pim rp-hash 238.1.1.1
RP 3.3.3.3 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:54:23, expires: 00:00:42
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 1479713549
RP 3.3.3.3, via bootstrap, priority 10, hash value 1916634234
R6#
 
Собственно на этом шаге понятно, что для группы 238.1.1.1 в качестве активного RP будет назначен R3.
В этом примере предполагается, что hash mask имеет длину 32 бита. На этом параметре мы остановимся поподробнее.
Сама длина hash mask, как мы уже видели, задается на Bootstrap кандидатах при их настройке, и после выбора BSR рассылается всем маршрутизаторам в сообщении bootstrap. Этот параметр служит для распределения нагрузки между всеми RP кандидатами. Фактически изменяя длину hash mask можно повлиять на то, сколько групп в среднем будет обслуживать каждый RP кандидат (то есть примерно для скольки групп RP кандидат станет активным RP). Стоит обратить внимание, что в hash функции hash mask и адрес группы объединены логическим "И". Значит, hash mask определяет, сколько первых бит из адреса группы будут взяты в учет hash функцией. Результат работы функции приводит к тому, что все объявленное пространство групп будет распределено между всеми кандидатами, и каждая RP получит примерно 2^[32-hash_mask_length] групп при условии, что количества кандидатов будет достаточно для такого распределения. В нашем примере это означает, что при длине hash mask, равной 32, каждая RP получила бы примерно по 2^[32-32], то есть 1 группе при условии, что у нас есть достаточное количество кандидатов (2^24). Для наших оставшихся после первых двух шагов алгоритма кандидатов произойдет распределение всего пространства заявленных групп (238.0.0.0/8) примерно поровну.
Если посмотреть, какие RP занимаются обслуживанием других групп, то можно увидеть, что группы распределяются по RP действительно примерно поровну.
 
R6#sh ip pim rp-hash 238.1.1.4
RP 2.2.2.2 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:56:15, expires: 00:01:53
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 657697788
RP 3.3.3.3, via bootstrap, priority 10, hash value 220777103
R6#sh ip pim rp-hash 238.1.1.5
RP 3.3.3.3 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:56:16, expires: 00:01:53
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 239255729
RP 3.3.3.3, via bootstrap, priority 10, hash value 1313710622
R6#sh ip pim rp-hash 238.1.1.13
RP 3.3.3.3 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:55:59, expires: 00:02:10
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 285971449
RP 3.3.3.3, via bootstrap, priority 10, hash value 1572032358
R6#sh ip pim rp-hash 238.1.1.14
RP 2.2.2.2 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 10, holdtime 150
Uptime: 01:56:01, expires: 00:02:06
PIMv2 Hash Value (mask 255.255.255.255)
RP 2.2.2.2, via bootstrap, priority 10, hash value 1287682658
RP 3.3.3.3, via bootstrap, priority 10, hash value 155107061
 
Стоит отметить, что по умолчанию длина hash mask равна 0. Это означает, что номер группы функцией вообще не учитывается, и все группы попадают на одну RP.
В качестве итога рассмотрим настраиваемые параметры, влияющие на работу механизма в целом:
1. bsr-candidate priority. Влияет исключительно на выбор BSR.
2. rp-candidate priority. Позволяет более очевидно (нежели воздействие на hash функцию) распределить группы по активным RP.
3. длина hash mask. Позволяет контролировать среднее количество групп, доставшихся каждой RP.
 
---
Андрей Петрунин
заместитель технического директора ООО "Фаст Лейн"
1 Комментарий
New Member

Спасибо, познавательно.

235
Просмотры
10
Полезный материал
1
Комментарии