1 00:00:08,460 --> 00:00:12,500 Итак, до этого момента в предыдущих видео мы говорили о 2 00:00:12,500 --> 00:00:18,280 как строится общее дерево, вплоть до точки встречи и 3 00:00:18,280 --> 00:00:19,760 затем остановимся на этом. 4 00:00:19,760 --> 00:00:22,720 А потом последнее видео, о котором мы говорили, ладно, как только этот источник, этот 5 00:00:22,720 --> 00:00:27,040 сервер, начинает рассылать свой многоадресный трафик, самый первый маршрутизатор 6 00:00:27,040 --> 00:00:30,960 к которому он подключен, и который вы считаете шлюзом по умолчанию для 7 00:00:30,960 --> 00:00:36,960 источник, возьмет эти многоадресные пакеты и зарегистрирует их в PIM. 8 00:00:36,960 --> 00:00:38,160 место встречи. 9 00:00:38,160 --> 00:00:41,020 И мы говорили о том, как это в основном принимает пакеты многоадресной рассылки. 10 00:00:41,020 --> 00:00:45,800 и обернуть их внутри заголовка PIM, а затем обернуть их внутри 11 00:00:45,800 --> 00:00:51,340 одноадресного IP-заголовка от маршрутизатора к RP. 12 00:00:51,340 --> 00:00:58,220 Итак, теперь мы рассмотрим объединение дерева кратчайших путей. 13 00:00:58,220 --> 00:01:05,960 Теперь вспомните, я упоминал в другом видео, что у каждого маршрутизатора есть свой 14 00:01:05,960 --> 00:01:10,460 собственный взгляд на то, что такое дерево кратчайшего пути, верно? 15 00:01:10,460 --> 00:01:14,460 Как только маршрутизатор получает многоадресный пакет, он внезапно 16 00:01:14,460 --> 00:01:18,320 это пробуждение, оно говорит ага, это то, что я искал и сейчас 17 00:01:18,320 --> 00:01:21,840 Я знаю критический компонент, которого раньше не знал. 18 00:01:21,840 --> 00:01:23,520 Я знаю, кто источник. 19 00:01:23,520 --> 00:01:29,000 Так что этот роутер, извините, тогда RP не смотрит вверх. 20 00:01:29,000 --> 00:01:33,160 Он заходит в свою таблицу одноадресной маршрутизации и говорит мне, какое самое короткое сообщение 21 00:01:33,160 --> 00:01:35,500 путь обратно к этому источнику? 22 00:01:35,500 --> 00:01:39,520 Теперь это может заставить вас задать вопрос: хорошо, значит ли это, что 23 00:01:39,520 --> 00:01:43,940 в любом месте дерева от источника до получателя, 24 00:01:43,940 --> 00:01:48,220 если где-нибудь есть ответвления, которые на самом деле являются самыми короткими 25 00:01:48,220 --> 00:01:52,000 путь, означает ли это, что любой маршрутизатор в любом месте на этом пути разрешен 26 00:01:52,000 --> 00:01:56,180 переключиться на дерево кратчайшего пути и оставить это основное дерево и 27 00:01:56,180 --> 00:01:57,980 покинуть дерево точек встречи? 28 00:01:57,980 --> 00:02:00,560 Не совсем. И поэтому мы собираемся поговорить об этом здесь. 29 00:02:00,560 --> 00:02:05,780 Но в данной конкретной ситуации место встречи имеет разрешение 30 00:02:05,780 --> 00:02:09,240 сделать это, потому что помните, что в этот момент точка встречи принимает 31 00:02:09,240 --> 00:02:13,800 регистрировать пакеты, из-за чего его процессор работает немного тяжелее 32 00:02:13,800 --> 00:02:19,940 чем должно. Обычно нам действительно нужно, чтобы многоадресный пакет 33 00:02:19,940 --> 00:02:25,140 приходит, мы просто хотим найти запись в таблице mRout и вперед 34 00:02:25,140 --> 00:02:28,720 оно уже в пути. На самом деле, если вы используете SEP, Cisco Express 35 00:02:28,720 --> 00:02:32,440 При пересылке вы даже можете делать все это, не прерывая 36 00:02:32,440 --> 00:02:36,100 ЦП вообще, как например на свитчах. 37 00:02:36,100 --> 00:02:40,640 Если у вас многоуровневый коммутатор с Т-кулачками и переадресацией А6 и переадресацией 38 00:02:40,640 --> 00:02:46,720 двигатели и прочее, ЦП и коммутатор выполняют всю обработку PIM. 39 00:02:46,720 --> 00:02:51,280 Поэтому, когда вы присоединяетесь к PIM, PIM сокращается, пакеты PIM регистрируются, им приходится 40 00:02:51,280 --> 00:02:53,740 перейти к процессору для обработки. 41 00:02:53,740 --> 00:02:58,240 Итак, если этот многоуровневый коммутатор, который действует как маршрутизатор, 42 00:02:58,240 --> 00:03:02,800 получает тонны пакетов регистров, и все это поступает в процессор. 43 00:03:02,800 --> 00:03:06,620 А если бы это была просто собственная многоадресная рассылка, все это могло бы 44 00:03:06,620 --> 00:03:10,420 быть реализовано аппаратно на его Т-камерах, его А6 и прочем, и это будет 45 00:03:10,420 --> 00:03:14,700 никогда даже не беспокойте ЦП, даже не позволяйте ЦП его видеть. 46 00:03:14,700 --> 00:03:17,300 В идеале это то, чего мы хотим. 47 00:03:17,300 --> 00:03:22,460 Поэтому мы хотим остановить этот процесс регистрации как можно быстрее, чтобы мы 48 00:03:22,460 --> 00:03:24,440 не нужно делать всю эту дополнительную работу. 49 00:03:24,440 --> 00:03:29,660 Итак, мы упомянули, что это произойдет следующим образом: PIM 50 00:03:29,660 --> 00:03:38,380 RP отправит сообщение о присоединении, называемое s, g join upstream, чтобы открыть 51 00:03:38,380 --> 00:03:42,020 свой кратчайший путь. 52 00:03:42,020 --> 00:03:44,920 И это его способ сказать: «Хорошо, я хочу открыть это, чтобы многоадресная рассылка 53 00:03:44,920 --> 00:03:47,360 может стекать в своем естественном виде. 54 00:03:47,360 --> 00:03:51,580 Как только это начнет происходить, и я это увижу, я это подтвержу, тогда 55 00:03:51,580 --> 00:03:53,780 РП говорит: останови регистр. 56 00:03:53,780 --> 00:03:54,840 Я больше этого не хочу. 57 00:03:54,840 --> 00:03:57,940 Прекратите процесс регистрации, и он действительно отправит регистр PIM. 58 00:03:57,940 --> 00:04:00,520 останавливаться. Мы говорили об этом. 59 00:04:00,520 --> 00:04:05,000 Я знаю, что в этом конкретном случае R2 присоединяется к самому короткому 60 00:04:05,000 --> 00:04:09,580 дерево путей. Теперь позвольте мне на мгновение вернуться к моему первоначальному рисунку. 61 00:04:09,580 --> 00:04:14,980 Вот на что похожа наша текущая топология. 62 00:04:14,980 --> 00:04:23,840 Теперь я знаю, поскольку я намеренно разработал это так, чтобы R8 мог 63 00:04:23,840 --> 00:04:28,800 чтобы напрямую добраться до четвертого маршрутизатора, не обращаясь к третьему маршрутизатору. 64 00:04:28,800 --> 00:04:35,660 Итак, можно было бы посмотреть на это и сказать: «Хорошо, тогда я бы предположил, что когда 65 00:04:35,660 --> 00:04:39,260 первый многоадресный пакет, когда первый пакет регистрации, первый 66 00:04:39,260 --> 00:04:46,080 пакет регистрации поступает на третий маршрутизатор, а третий маршрутизатор деинкапсулирует 67 00:04:46,080 --> 00:04:50,620 это и отправляет его как собственную многоадресную рассылку на восьмой маршрутизатор, не только 68 00:04:50,620 --> 00:04:55,340 отправит ли третий маршрутизатор свое соединение вверх по течению, пытаясь присоединиться к своему самому короткому 69 00:04:55,340 --> 00:05:00,300 дерево путей, разве мы не ожидаем, что восьмой маршрутизатор тоже сделает то же самое? 70 00:05:00,300 --> 00:05:04,620 Я имею в виду, в конце концов, восьмой маршрутизатор теперь знает, кто является источником, и ему следует 71 00:05:04,620 --> 00:05:08,140 загляните в его таблицу маршрутизации и скажите: ой, подождите, у меня прямое БАМ-соединение. 72 00:05:08,140 --> 00:05:10,520 сюда, к источнику. 73 00:05:10,520 --> 00:05:12,560 Это мой кратчайший путь. 74 00:05:12,560 --> 00:05:17,540 Разве мы не ожидаем, что он также присоединится к дереву кратчайшего пути? 75 00:05:17,540 --> 00:05:19,200 Что ж, мы собираемся взглянуть на это с помощью сниффера. 76 00:05:19,200 --> 00:05:22,500 Я скажу вам именно то, что говорит RFC. 77 00:05:22,500 --> 00:05:29,160 В RFC для разреженного режима PIMS говорится, что только люди, которым разрешено 78 00:05:29,160 --> 00:05:34,980 для переключения с общего дерева на дерево кратчайшего пути — любое число 79 00:05:34,980 --> 00:05:39,740 первое, место встречи, как мы уже говорили, или последнее 80 00:05:39,740 --> 00:05:44,580 хоп-маршрутизатор. Другими словами, маршрутизатор, который напрямую подключен к 81 00:05:44,580 --> 00:05:49,200 получатель. Итак, согласно RFC, на этой конкретной схеме маршрутизатор 82 00:05:49,200 --> 00:05:53,800 восьми не будет разрешено инициировать этот процесс. 83 00:05:53,800 --> 00:05:58,100 Ему нужно будет получить многоадресную рассылку по общему дереву, а затем просто 84 00:05:58,100 --> 00:06:02,060 продолжайте передавать его вниз по потоку ко второму маршрутизатору. 85 00:06:02,060 --> 00:06:05,500 И поскольку второй маршрутизатор напрямую подключен к приемнику, помните: 86 00:06:05,500 --> 00:06:09,700 мы видели это с небольшим флажком C, потому что он получил отчет о членстве, 87 00:06:09,700 --> 00:06:14,820 это означает, что он будет обязан подключиться к самому короткому 88 00:06:14,820 --> 00:06:19,220 дерево путей, а не ответственность восьмого маршрутизатора. 89 00:06:19,220 --> 00:06:21,760 Итак, мы на самом деле посмотрим на это в трассировке сниффера и посмотрим, так ли это. 90 00:06:21,760 --> 00:06:24,460 это правда, потому что мы знаем, что иногда с маршрутизаторами Cisco и прочим они 91 00:06:24,460 --> 00:06:26,660 не совсем следуйте RFC. 92 00:06:26,660 --> 00:06:28,620 Итак, давайте посмотрим, произойдет ли это. 93 00:06:28,620 --> 00:06:33,120 Но прежде чем мы это сделаем, не хочу забегать вперед. 94 00:06:33,120 --> 00:06:39,400 И, кстати, для этого маршрутизатора номер два в RFC вы можете увидеть термин два. 95 00:06:39,400 --> 00:06:39,880 другое дело. 96 00:06:39,880 --> 00:06:44,300 Я видел его под названием «маршрутизатор последнего перехода», а также видел его под названием «лист». 97 00:06:44,300 --> 00:06:47,040 маршрутизаторы. Это как лист на краю дерева. 98 00:06:47,040 --> 00:06:49,640 Так и есть, дальше этого дерево не идет. 99 00:06:49,640 --> 00:06:53,660 Поэтому они будут называть конечные маршрутизаторы или маршрутизаторы последнего перехода. 100 00:06:53,660 --> 00:07:02,020 Итак, это обзор того, о чем мы уже говорили. 101 00:07:02,020 --> 00:07:04,800 Так что мне не нужно туда заходить. 102 00:07:04,800 --> 00:07:09,840 И я упомянул, как соединения S, G используются для открытия кратчайшего пути. 103 00:07:09,840 --> 00:07:13,860 дерево. И вы все время будете видеть эту аббревиатуру SP T, когда говорите о 104 00:07:13,860 --> 00:07:16,280 PIM, дерево кратчайших путей. 105 00:07:16,280 --> 00:07:21,060 Так что же вызывает соединение S, G? 106 00:07:21,060 --> 00:07:26,260 Что ж, снова есть несколько вещей, которые могут спровоцировать это. 107 00:07:26,260 --> 00:07:30,980 Если вы оказались в точке встречи и получили многоадресный пакет 108 00:07:30,980 --> 00:07:35,920 и регистр, который побудит вас отправить соединение S, G. 109 00:07:35,920 --> 00:07:38,460 Потому что в качестве места встречи вам захочется открыть самый короткий путь. 110 00:07:38,460 --> 00:07:41,260 путь. Так что это одна вещь, которая может спровоцировать это. 111 00:07:41,260 --> 00:07:42,800 Что еще? 112 00:07:42,800 --> 00:07:49,120 Как мы уже говорили, если вы являетесь конечным маршрутизатором при получении многоадресной рассылки 113 00:07:49,120 --> 00:07:52,440 пакет. Здесь также возникает интересный момент. 114 00:07:52,440 --> 00:07:59,460 Итак, вы можете задаться вопросом: а листовой маршрутизатор делает это немедленно? 115 00:07:59,460 --> 00:08:04,800 Только после того, как он получит 10 пакетов или получит определенные бит в секунду. 116 00:08:04,800 --> 00:08:07,400 Знаете, когда листовой маршрутизатор решит это сделать? 117 00:08:07,400 --> 00:08:10,860 Фактический RFC этого не определяет. 118 00:08:10,860 --> 00:08:15,820 В настоящем RFC для PIMS Farsmo просто говорится, что конечный маршрутизатор может, а он нет. 119 00:08:15,820 --> 00:08:17,160 даже придется это сделать. 120 00:08:17,160 --> 00:08:22,100 Конечный маршрутизатор может переключиться на дерево кратчайшего пути после определенного 121 00:08:22,100 --> 00:08:24,640 порог достигнут. 122 00:08:24,640 --> 00:08:25,780 Это все, что здесь сказано. 123 00:08:25,780 --> 00:08:28,400 Как же на самом деле это делают маршрутизаторы Cisco? 124 00:08:28,400 --> 00:08:33,040 Порог для маршрутизаторов Cisco — один пакет, всего один. 125 00:08:33,040 --> 00:08:36,920 Поэтому, когда самый первый многоадресный пакет достигает второго маршрутизатора, маршрутизатор 126 00:08:36,920 --> 00:08:41,380 двое первыми узнают, что это за адрес источника, это его триггер 127 00:08:41,380 --> 00:08:44,480 сказать: хорошо, у меня есть более короткий путь? 128 00:08:44,480 --> 00:08:49,040 Позвольте мне присоединиться к нему. Это пороговое значение для маршрутизаторов Cisco. 129 00:08:49,040 --> 00:08:51,980 Теперь вы можете спросить: есть ли у меня другой вариант? 130 00:08:51,980 --> 00:08:53,120 Могу ли я сделать что-то еще? 131 00:08:53,120 --> 00:08:56,560 Позвольте мне показать вам, какая команда предназначена для изменения этого поведения. 132 00:08:56,560 --> 00:08:59,160 У вас не так много вариантов. 133 00:08:59,160 --> 00:09:02,300 Правда, их всего два. 134 00:09:02,300 --> 00:09:05,160 Вам доступны только два варианта. 135 00:09:05,160 --> 00:09:08,420 Итак, я перейду к листовому маршрутизатору. 136 00:09:08,420 --> 00:09:11,020 И команда IP PIM. 137 00:09:11,020 --> 00:09:18,580 И тогда это порог SPT. 138 00:09:18,580 --> 00:09:20,920 Итак, берег пути порог. 139 00:09:20,920 --> 00:09:23,640 И у вас есть только два варианта. 140 00:09:23,640 --> 00:09:30,060 Ноль, значение по умолчанию, или бесконечность, что означает никогда не переключаться. 141 00:09:30,060 --> 00:09:31,500 по кратчайшему пути. 142 00:09:31,500 --> 00:09:35,220 Вот и все. Ничего посередине. 143 00:09:35,220 --> 00:09:41,960 Таким образом, вы сами можете решить, при каких обстоятельствах вам может понадобиться 144 00:09:41,960 --> 00:09:44,040 выбрать бесконечность. 145 00:09:44,040 --> 00:09:52,440 Но по умолчанию переключение происходит, как только вы получаете самый первый пакет. 146 00:09:52,440 --> 00:09:55,600 Какое состояние они создают в таблице маршрутов M? 147 00:09:55,600 --> 00:09:59,640 Хорошо, если я вернусь к своему маршрутизатору, давайте продолжим и воспользуемся этим 148 00:09:59,640 --> 00:10:04,380 парень. Показать маршрут IP M. 149 00:10:04,380 --> 00:10:12,520 Хорошо, пока у нас есть запись со звездочкой и запятой G. 150 00:10:12,520 --> 00:10:19,300 Теперь запись со звездочкой и запятой G строится на основе общего дерева. 151 00:10:19,300 --> 00:10:24,360 Единственное, что мы знаем, это место встречи. 152 00:10:24,360 --> 00:10:27,620 И как добраться до места встречи. 153 00:10:27,620 --> 00:10:34,600 Поэтому, если многоадресные пакеты начнут течь по общему дереву, это 154 00:10:34,600 --> 00:10:40,080 конструкцию, которую мы собираемся использовать для пересылки этих многоадресных пакетов. 155 00:10:40,080 --> 00:10:44,580 Теперь вы говорите: ну, если многоадресная рассылка действительно начнет течь, и мы сейчас 156 00:10:44,580 --> 00:10:48,720 знаете источник, мы тоже собираемся использовать это? 157 00:10:48,720 --> 00:10:50,640 Ну, посмотрите здесь на пару вещей. 158 00:10:50,640 --> 00:10:54,320 Номер один, входящий интерфейс. 159 00:10:54,320 --> 00:10:56,160 Сосед ПФР. 160 00:10:56,160 --> 00:11:01,140 Все это основано на наших знаниях о месте встречи. 161 00:11:01,140 --> 00:11:07,280 Если бы я действительно получал настоящие многоадресные данные, это не имело бы значения, 162 00:11:07,280 --> 00:11:11,600 верно? Поскольку входящий интерфейс и сосед RPF могут добраться до 163 00:11:11,600 --> 00:11:15,340 фактический источник может быть и не этим. 164 00:11:15,340 --> 00:11:17,260 Это может быть что-то другое. 165 00:11:17,260 --> 00:11:23,260 Кроме того, мне больше не нужна здесь звезда, потому что теперь я буду знать, что 166 00:11:23,260 --> 00:11:25,220 исходный адрес. 167 00:11:25,220 --> 00:11:31,040 Таким образом, в тот момент, когда маршрутизатор фактически получает самый первый многоадресный пакет, 168 00:11:31,040 --> 00:11:38,120 здесь создается вторая запись, которая называется записью S, запятая G. 169 00:11:38,120 --> 00:11:39,320 Итак, давайте продолжим и сделаем это. 170 00:11:39,320 --> 00:11:40,880 Начнем с потока. 171 00:11:40,880 --> 00:11:54,680 В общем, повторите мой пинг. 172 00:11:54,680 --> 00:12:00,120 Хорошо. И вообще-то мне нужно пойти к восьмому маршрутизатору, потому что во время перерыва 173 00:12:00,120 --> 00:12:05,400 Я добавил сюда кое-что, что потенциально могло испортить нашу демонстрацию. 174 00:12:05,400 --> 00:12:18,960 Так что я просто хочу от этого избавиться. 175 00:12:18,960 --> 00:12:21,380 Хорошо, давайте теперь посмотрим на второй маршрутизатор. 176 00:12:21,380 --> 00:12:23,800 Показать IP, М маршрут. 177 00:12:23,800 --> 00:12:32,300 Итак, здесь мы видим то, что называется записью маршрута S, запятая G, M. 178 00:12:32,300 --> 00:12:38,200 S, потому что, эй, мы действительно знаем, кто источник. 179 00:12:38,200 --> 00:12:43,500 Таким образом, входящий интерфейс и сосед RPF сейчас действительно актуальны. 180 00:12:43,500 --> 00:12:47,540 к источнику, а не к месту встречи. 181 00:12:47,540 --> 00:12:56,000 Теперь моя конкретная топология, я фактически сделал так, что на R2 он бы 182 00:12:56,000 --> 00:13:00,540 предпочитают этот последовательный канал для доступа к R4, а не эти быстрые каналы Ethernet. 183 00:13:00,540 --> 00:13:04,920 Я просто сделал это, манипулируя EIGRP, используя списки смещений и тому подобное. 184 00:13:04,920 --> 00:13:09,640 как это. Но R2 говорит: «ОК, чтобы добраться до сети четыре пять, это 185 00:13:09,640 --> 00:13:11,260 предпочтительный путь. 186 00:13:11,260 --> 00:13:15,660 И еще раз, я могу это просто проверить, показать IP RPF, четыре точки пять точек 187 00:13:15,660 --> 00:13:22,100 четыре точки пять. И там написано: я предпочитаю использовать серийный ноль, один ноль, и 188 00:13:22,100 --> 00:13:25,140 это через EIGRP 100. 189 00:13:25,140 --> 00:13:28,700 Вот что мы используем в качестве входящего интерфейса. 190 00:13:28,700 --> 00:13:34,180 А сосед RPF — это, ну, как бы это ни звучало, следующий верхний сосед, который собирается 191 00:13:34,180 --> 00:13:36,140 вверх в этом направлении. 192 00:13:36,140 --> 00:13:45,320 Теперь, когда вокруг этого много правил, которые нам приходится соблюдать. 193 00:13:45,320 --> 00:13:57,900 Итак, во-первых, когда впервые образуется S, запятая G, по сути, это просто занимает 194 00:13:57,900 --> 00:14:02,700 все, что есть в списке исходящих интерфейсов звездочки, запятой G и просто 195 00:14:02,700 --> 00:14:05,140 копирует это сюда. 196 00:14:05,140 --> 00:14:06,800 Так что обычно они одинаковы. 197 00:14:06,800 --> 00:14:10,600 Есть одно обстоятельство, при котором этого не произойдет. 198 00:14:10,600 --> 00:14:16,620 Существует правило PIM, и оно действительно существует как для звездочки, так и для запятой. 199 00:14:16,620 --> 00:14:21,000 G и S, запятая G, которая говорит о том, что у вас никогда не будет входящего интерфейса. 200 00:14:21,000 --> 00:14:24,060 в списке исходящих интерфейсов. 201 00:14:24,060 --> 00:14:28,160 Другими словами, ваш входящий интерфейс не может совпадать с исходящим. 202 00:14:28,160 --> 00:14:34,560 интерфейс. Итак, если вы видите в списке исходящих интерфейсов значение null, это означает 203 00:14:34,560 --> 00:14:38,540 ничего, может быть поэтому. 204 00:14:38,540 --> 00:14:41,440 Но в данном случае нам не о чем беспокоиться. 205 00:14:41,440 --> 00:14:44,980 Итак, входящий интерфейс — последовательный ноль один ноль, и он просто скопировал 206 00:14:44,980 --> 00:14:55,700 это здесь внизу. Хорошо, что означает буква J? 207 00:14:55,700 --> 00:15:02,200 Флаг J означает, что я отправил соединение в этом направлении. 208 00:15:02,200 --> 00:15:06,120 Итак, в данном конкретном случае, поскольку это дерево кратчайшего пути, то 209 00:15:06,120 --> 00:15:13,540 означает, что я отправил S, запятую G, чтобы объединить дерево кратчайшего пути. 210 00:15:13,540 --> 00:15:20,240 Теперь флаг J сам по себе не является доказательством того, что мы действительно получили какие-либо 211 00:15:20,240 --> 00:15:23,860 многоадресные данные с этого направления. 212 00:15:23,860 --> 00:15:34,000 Все это означает, что мы попытались открыть это направление. 213 00:15:34,000 --> 00:15:39,160 То, что мы обычно хотели бы видеть после флага J, и я собираюсь это сделать. 214 00:15:39,160 --> 00:15:44,900 исследуйте это здесь, это будет флаг T. 215 00:15:44,900 --> 00:15:49,940 Обычно мы видим флаг T после флага J, а на самом деле флаг T 216 00:15:49,940 --> 00:15:57,100 означает, что я получил фактические данные многоадресной рассылки из дерева кратчайшего пути. 217 00:15:57,100 --> 00:16:00,200 Почему же мы не видим этого в данном конкретном случае? 218 00:16:00,200 --> 00:16:02,180 Что ж, давайте немного поработаем над устранением неполадок. 219 00:16:02,180 --> 00:16:09,420 Мы знаем, что для получения multicast-трафика в этом направлении, 220 00:16:09,420 --> 00:16:14,640 нам нужен PIM прямо здесь. 221 00:16:14,640 --> 00:16:18,460 Итак, вопрос номер один: есть ли у второго маршрутизатора сосед PIM по последовательному порту? 222 00:16:18,460 --> 00:16:22,680 ноль один ноль? Если у него есть сосед ПИМ, то это доказательство того, что мы на самом деле 223 00:16:22,680 --> 00:16:25,320 включил PIM на маршрутизаторе четыре. 224 00:16:25,320 --> 00:16:30,420 Итак, посмотрим, покажем IP соседу PIM. 225 00:16:30,420 --> 00:16:32,360 И он этого не делает. 226 00:16:32,360 --> 00:16:37,180 Хорошо, у нас есть только сосед по Быстрому Итану с нулевой единицей. 227 00:16:37,180 --> 00:16:41,520 У нас его нет в сериале, поэтому трафик не приходит 228 00:16:41,520 --> 00:16:47,400 сюда. Итак, давайте посмотрим на четвертый маршрутизатор. 229 00:16:47,400 --> 00:16:56,380 Да, и Питер, просто чтобы подтвердить, тебе действительно нужно увидеть флаг T в 230 00:16:56,380 --> 00:17:01,180 эта запись здесь, чтобы убедиться, что вы получили многоадресный трафик 231 00:17:01,180 --> 00:17:03,340 дерево кратчайших путей. 232 00:17:03,340 --> 00:17:08,140 Все, что означает флаг J, это то, что я пытался присоединиться к этому дереву, но мы этого не сделали. 233 00:17:08,140 --> 00:17:08,880 узнайте, работает ли он еще. 234 00:17:08,880 --> 00:17:12,340 И этот конкретный случай явно не работает, потому что у меня даже нет 235 00:17:12,340 --> 00:17:15,600 сосед по этому интерфейсу. 236 00:17:15,600 --> 00:17:21,360 Так почему бы не? Давайте перейдем к четвертому маршрутизатору. 237 00:17:21,360 --> 00:17:25,160 Показать интерфейс запуска: последовательный ноль, один ноль. 238 00:17:25,160 --> 00:17:26,260 И вот мы идем. 239 00:17:26,260 --> 00:17:28,120 Я не включил PIM на этом интерфейсе. 240 00:17:28,120 --> 00:17:40,340 Это объясняет это. 241 00:17:40,340 --> 00:17:44,400 Хорошо, пинг все еще идет или уже закончился? 242 00:17:44,400 --> 00:17:45,960 Да, все еще иду. 243 00:17:45,960 --> 00:17:51,920 Итак, теперь давайте перейдем ко второму маршрутизатору. 244 00:17:51,920 --> 00:17:54,080 И вот мы идем. 245 00:17:54,080 --> 00:17:55,840 Теперь у нас есть флаг T. 246 00:17:55,840 --> 00:18:00,500 Это хорошо. Это означает, что мы действительно начали получать многоадресную рассылку. 247 00:18:00,500 --> 00:18:16,640 трафик из дерева кратчайших путей. 248 00:18:16,640 --> 00:18:21,240 Хорошо. И на тот случай, если вы посмотрите эту запись и 249 00:18:21,240 --> 00:18:26,200 вы пропустили предыдущий раздел о регистрах PIM, в частности 250 00:18:26,200 --> 00:18:30,560 раздел Я сделал фрагментарную трассировку PIM S, давайте просто взглянем на это 251 00:18:30,560 --> 00:18:42,780 очень быстро. Вот как выглядит соединение S, G. 252 00:18:42,780 --> 00:18:47,700 Он по-прежнему осуществляется как многоадресная рассылка с использованием того же адреса назначения PIM. 253 00:18:47,700 --> 00:18:52,000 из 2240013. Итак, шаг за шагом. 254 00:18:52,000 --> 00:18:56,320 Таким образом, исходный адрес будет меняться шаг за шагом. 255 00:18:56,320 --> 00:19:00,500 И в теле сообщения PIM это третий тип, еще раз, присоединяйтесь 256 00:19:00,500 --> 00:19:05,540 чернослив. Сосед вверх по течению, кому это будет? 257 00:19:05,540 --> 00:19:09,820 Кому мой сосед из ОПР, которому я это отправляю? 258 00:19:09,820 --> 00:19:12,600 И там будет написано: количество присоединений, к скольким группам я присоединяюсь? 259 00:19:12,600 --> 00:19:20,320 Итак, что действительно отличает звездообразное соединение G от соединения S, G, так это 260 00:19:20,320 --> 00:19:23,200 флаги прямо здесь. 261 00:19:23,200 --> 00:19:30,480 Мы видели в звездном соединении G, что помимо бита S у нас была буква W. 262 00:19:30,480 --> 00:19:33,420 бит и бит R. 263 00:19:33,420 --> 00:19:38,580 Бит W был подстановочным битом, означающим, что я не знаю, какой источник 264 00:19:38,580 --> 00:19:40,100 потока есть. 265 00:19:40,100 --> 00:19:44,700 Итак, этот IP-адрес, если бы здесь была буква W, это означало бы этот IP-адрес. 266 00:19:44,700 --> 00:19:47,120 это место встречи. 267 00:19:47,120 --> 00:19:51,840 Но исходя из того, что W отсутствует, это означает, что на самом деле это так. 268 00:19:51,840 --> 00:19:54,920 IP-адрес источника самого потока. 269 00:19:54,920 --> 00:19:59,200 Кроме того, бит R отсутствует. 270 00:19:59,200 --> 00:20:02,140 Бит R — это так называемый бит RP. 271 00:20:02,140 --> 00:20:05,600 Если вы действительно заглянете в спецификацию PIM, то увидите, что это бит RP. 272 00:20:05,600 --> 00:20:10,420 И это будет означать, что это сообщение, будь то чернослив или объединение, будет отправлено 273 00:20:10,420 --> 00:20:14,780 вверх по дереву RP. Он поднимается по общему дереву к месту встречи. 274 00:20:14,780 --> 00:20:17,700 Еще раз: здесь этого не хватает, потому что это не поднимается на общий уровень. 275 00:20:17,700 --> 00:20:22,140 дерево. Ему суждено подняться вверх по дереву кратчайшего пути. 276 00:20:22,140 --> 00:20:27,280 В остальном они выглядят по сути одинаково: звездочка, G-соединение и 277 00:20:27,280 --> 00:20:29,440 соединение S, G. Тело выглядит так же. 278 00:20:29,440 --> 00:20:31,660 Вам действительно нужно посмотреть на флаги здесь, чтобы увидеть. 279 00:20:31,660 --> 00:20:35,380 Здесь есть буква W в букве R или они отсутствуют? 280 00:20:35,380 --> 00:20:40,700 Вот что отличает их. 281 00:20:40,700 --> 00:20:49,040 Я упомянул, что одна из вещей, которая может вызвать состояние S, G в 282 00:20:49,040 --> 00:20:55,300 маршрутизатор - это если вы действительно получаете сам многоадресный трафик. 283 00:20:55,300 --> 00:20:58,660 Есть еще одна ситуация, которая может вызвать это. 284 00:20:58,660 --> 00:21:08,860 Например, если вы получили соединение S, G от нисходящего маршрутизатора, давайте 285 00:21:08,860 --> 00:21:11,900 не используйте этот. 286 00:21:11,900 --> 00:21:23,040 Допустим, например, что у нас есть такая ситуация. 287 00:21:23,040 --> 00:21:34,280 Этот парень - РП. 288 00:21:34,280 --> 00:21:40,040 Мы просто назовем этого парня маршрутизатором номер один, маршрутизатором номер два и маршрутизатором номер три. 289 00:21:40,040 --> 00:21:58,400 Мы поместим наш приемник прямо здесь, и мы поместим наш источник прямо здесь. 290 00:21:58,400 --> 00:22:04,420 Итак, мы знаем, что изначально, как только начинается многоадресная рассылка, 291 00:22:04,420 --> 00:22:10,400 течет, оно пойдет в этом направлении к месту встречи, вниз 292 00:22:10,400 --> 00:22:13,020 общему дереву, а затем получателю. 293 00:22:13,020 --> 00:22:17,660 Итак, сейчас второй маршрутизатор вообще не имеет состояния. 294 00:22:17,660 --> 00:22:19,620 У него нет состояния маршрута M для потока. 295 00:22:19,620 --> 00:22:23,720 Никто его об этом никогда не просил, ни IGMP, ни PIM. 296 00:22:23,720 --> 00:22:26,540 Так что, если бы он показал маршрут IPM, мы бы ничего не увидели. 297 00:22:26,540 --> 00:22:29,620 Ничего связанного с потоком. 298 00:22:29,620 --> 00:22:36,360 Но когда первый маршрутизатор пытается присоединиться к кратчайшему пути, если мы предположим, что 299 00:22:36,360 --> 00:22:50,480 что это кратчайший путь, он отправит соединение PIM S, G вверх по течению. 300 00:22:50,480 --> 00:22:55,040 И, как мы видели в теле сообщения, он скажет: соседний маршрутизатор. 301 00:22:55,040 --> 00:22:59,780 во-вторых, IP-адрес второго маршрутизатора, а затем он сообщит источник и пункт назначения, 302 00:22:59,780 --> 00:23:00,880 верно? Он укажет источник потока. 303 00:23:00,880 --> 00:23:04,460 Скажем так, это ххх. 304 00:23:04,460 --> 00:23:13,640 Здесь у него будет источник равен xxx, группа равна, ну вы знаете, что угодно. 305 00:23:13,640 --> 00:23:21,600 это. Итак, теперь, несмотря на то, что у второго маршрутизатора изначально не было состояния M-маршрута в 306 00:23:21,600 --> 00:23:29,820 все, как только он получит это соединение S, G, это фактически создаст состояние S, G 307 00:23:29,820 --> 00:23:32,420 в его таблице маршрутов M. 308 00:23:32,420 --> 00:23:36,340 И тогда он сможет создать свое собственное соединение S, G и отправить его вверх. 309 00:23:36,340 --> 00:23:42,400 Сюда. Еще один ключевой компонент. Возможно, вас протестируют на каком-нибудь