1 00:00:08,320 --> 00:00:13,520 Хорошо, прежде чем мы углубимся в мельчайшие детали PIM как многоадресной рассылки. 2 00:00:13,520 --> 00:00:17,920 протокол маршрутизации, давайте посмотрим на действительно высокий уровень того, что такое многоадресная рассылка 3 00:00:17,920 --> 00:00:22,100 протоколы маршрутизации, зачем они нам нужны, для какой проблемы они были разработаны 4 00:00:22,100 --> 00:00:28,500 решать. Итак, мы знаем, что у нас есть концепция источников и приемников. 5 00:00:28,500 --> 00:00:31,880 источником является какой-то сервер, который перекачивает многоадресный трафик 6 00:00:31,880 --> 00:00:35,740 и ударяем по вашему маршрутизатору, тот отбрасывает его, потому что нет 7 00:00:35,740 --> 00:00:38,000 идея, куда это должно идти. 8 00:00:38,000 --> 00:00:41,380 А на другом конце сети у вас есть приёмники, ноутбуки, 9 00:00:41,380 --> 00:00:45,760 ваши компьютеры, которым нужен этот многоадресный трафик, но их шлюз по умолчанию имеет 10 00:00:45,760 --> 00:00:47,300 понятия не имею, где источник. 11 00:00:47,300 --> 00:00:49,720 Так как же нам соединить эти два понятия? 12 00:00:49,720 --> 00:00:54,140 И это единственная причина, по которой нам нужны протоколы многоадресной маршрутизации для 13 00:00:54,140 --> 00:00:58,140 построить эту ветку, чтобы соединить их, чтобы построить эту многоадресную рассылку 14 00:00:58,140 --> 00:01:04,360 дерево. Итак, нам нужно создать это дерево. 15 00:01:04,360 --> 00:01:07,580 И в предыдущем видео я говорил, что у нас есть два базовых уровня высокого уровня. 16 00:01:07,580 --> 00:01:09,160 способы сделать это. 17 00:01:09,160 --> 00:01:13,380 Один метод, называемый моделью push, который используется в плотном режиме. 18 00:01:13,380 --> 00:01:17,440 протоколов, просто означает, что давайте просто заполним сеть этой многоадресной рассылкой 19 00:01:17,440 --> 00:01:21,700 трафик. Вы обязательно займетесь приемниками и всем остальным 20 00:01:21,700 --> 00:01:26,460 ветки дерева, где маршрутизаторам предстоит их обрезать 21 00:01:26,460 --> 00:01:30,080 ответвления, чтобы сказать: «Эй, восходящий маршрутизатор, прекрати отправлять мне это». 22 00:01:30,080 --> 00:01:34,220 У меня нет никого, кто действительно этого хочет. 23 00:01:34,220 --> 00:01:40,280 Другая модель представляет собой разреженный режим, что означает: «ОК», как только приемники покажут 24 00:01:40,280 --> 00:01:44,900 их интерес к шлюзу по умолчанию, шлюз по умолчанию теперь должен 25 00:01:44,900 --> 00:01:48,520 вызвать какое-то сообщение о присоединении к многоадресной рассылке, в котором говорится: «ОК, я собираюсь отправить 26 00:01:48,520 --> 00:01:51,400 сообщение в восходящем направлении: «Эй, маршрутизатор надо мной». 27 00:01:51,400 --> 00:01:56,100 Если вы когда-нибудь получите это сообщение, этот многоадресный поток, я здесь. 28 00:01:56,100 --> 00:02:01,820 Я хочу чтобы. Тогда возникает вопрос: ОК, а где находится ваш стандартный 29 00:02:01,820 --> 00:02:03,120 шлюз отправляет это? 30 00:02:03,120 --> 00:02:08,020 Потому что, возможно, у него есть пять или шесть маршрутизаторов, расположенных выше него. 31 00:02:08,020 --> 00:02:10,760 Кому он отправляет это соединение? 32 00:02:10,760 --> 00:02:15,620 Чтобы ответить на этот вопрос, я придумал хорошую аналогию. 33 00:02:15,620 --> 00:02:18,600 Подумай о свиданиях, да? 34 00:02:18,600 --> 00:02:21,540 Парни и девушки встречаются, пытаются найти друг друга. 35 00:02:21,540 --> 00:02:27,880 Таким образом, протокол плотного режима будет выглядеть примерно так: ты парень, ты ходишь 36 00:02:27,880 --> 00:02:31,460 в ночной клуб, и чтобы найти свою идеальную пару, ты просто идешь 37 00:02:31,460 --> 00:02:34,580 до каждой девушки, которая здесь говорит: эй, я люблю тебя. 38 00:02:34,580 --> 00:02:35,660 Ты выйдешь за меня? 39 00:02:35,660 --> 00:02:37,380 Я тебя люблю. Ты выйдешь за меня? 40 00:02:37,380 --> 00:02:40,220 Конечно, за это тебя бьют несколько раз. 41 00:02:40,220 --> 00:02:43,120 Но, надеюсь, в конце концов вы найдете свой приемник, верно? 42 00:02:43,120 --> 00:02:46,180 Вон тот дальний угол, девушка, которая пьет много пива, скажет: 43 00:02:46,180 --> 00:02:47,400 да, я хочу жениться на тебе. 44 00:02:47,400 --> 00:02:49,980 И вот вы нашли свой приемник. 45 00:02:49,980 --> 00:02:50,680 Ты источник. 46 00:02:50,680 --> 00:02:51,300 Она получатель. 47 00:02:51,300 --> 00:02:54,160 Сначала нужно было пройти через всех остальных и отсечься. 48 00:02:54,160 --> 00:02:56,820 Но в конце концов вы нашли того, кого искали. 49 00:02:56,820 --> 00:02:59,040 Это похоже на протокол плотного режима. 50 00:02:59,040 --> 00:03:02,680 Протокол разреженного режима вместо того, чтобы делать это и рисковать всем 51 00:03:02,680 --> 00:03:06,140 что отказ, вы используете службу знакомств. 52 00:03:06,140 --> 00:03:09,660 Итак, у вас есть посредническая компания, которая называется службой знакомств, ну, вы знаете. 53 00:03:09,660 --> 00:03:15,140 что угодно, eharmony.com или какой-то другой популярный сайт в наши дни. 54 00:03:15,140 --> 00:03:19,540 И источник, вы заходите на службу знакомств и создаете профиль. 55 00:03:19,540 --> 00:03:21,260 И ты говоришь: эй, это я. 56 00:03:21,260 --> 00:03:22,400 Я такой замечательный и замечательный. 57 00:03:22,400 --> 00:03:23,900 Я зарабатываю 5 миллионов долларов в год. 58 00:03:23,900 --> 00:03:24,880 Я вожу Феррари. 59 00:03:24,880 --> 00:03:26,160 Пожалуйста, выходи за меня. 60 00:03:26,160 --> 00:03:28,340 Верно? Итак, вы публикуете свои вещи там, на службе знакомств. 61 00:03:28,340 --> 00:03:31,800 Получатели, ну, вы знаете, из всех 50 миллионов женщин, которые употребляют 62 00:03:31,800 --> 00:03:35,180 эта служба знакомств, их может быть трое, которые ходят на эту службу знакомств 63 00:03:35,180 --> 00:03:38,020 сервис и говорю: о да, это именно то, что я ищу. 64 00:03:38,020 --> 00:03:38,800 Он какой-то придурок. 65 00:03:38,800 --> 00:03:39,600 У него много денег. 66 00:03:39,600 --> 00:03:40,920 У него есть Феррари. 67 00:03:40,920 --> 00:03:41,640 Мне понравится этот парень. 68 00:03:41,640 --> 00:03:45,140 И вот вы двое знакомитесь через службу знакомств и изначально 69 00:03:45,140 --> 00:03:47,700 вы не можете разговаривать друг с другом, верно? 70 00:03:47,700 --> 00:03:50,340 Сначала служба знакомств говорит, нет, ну знаешь, чтобы убедиться, что этот парень 71 00:03:50,340 --> 00:03:53,420 она не сталкер и не сумасшедшая, знаешь, мы не дадим 72 00:03:53,420 --> 00:03:56,380 вы, ребята, обмениваетесь номерами телефонов, адресами и всем остальным. 73 00:03:56,380 --> 00:03:59,740 Для общения вам придется использовать нашу систему чата и нашу систему электронной почты. 74 00:03:59,740 --> 00:04:03,900 друг другу. Но в конечном итоге после того, как вы обменялись сообщениями через 75 00:04:03,900 --> 00:04:07,580 служба знакомств, теперь вы можете узнать, где живут друг друга. 76 00:04:07,580 --> 00:04:10,120 Вы можете обменяться телефонными номерами и прекратить их использование. 77 00:04:10,120 --> 00:04:12,460 Вы можете общаться напрямую. 78 00:04:12,460 --> 00:04:15,160 Вот как работают протоколы разреженного режима. 79 00:04:15,160 --> 00:04:19,080 При использовании протоколов разреженного режима у вас есть маршрутизатор, сидящий где-то в 80 00:04:19,080 --> 00:04:23,180 ваша сеть, которая выполняет функции службы знакомств. 81 00:04:23,180 --> 00:04:28,200 Итак, получатели, как только ваш ноутбук отправит сообщение IGMP маршрутизатору, 82 00:04:28,200 --> 00:04:32,880 ваш шлюз по умолчанию, ваш шлюз по умолчанию говорит: хм, окей, я знаю, что у меня есть 83 00:04:32,880 --> 00:04:40,060 приемник здесь, понятия не имею, где находится источник. 84 00:04:40,060 --> 00:04:44,720 получатель хочет. Но я знаю, где находится служба знакомств в условиях 85 00:04:44,720 --> 00:04:48,700 протокола многоадресной маршрутизации, эта служба знакомств — это то, что мы называем 86 00:04:48,700 --> 00:04:51,160 место встречи, РП. 87 00:04:51,160 --> 00:04:54,660 Итак, в сети есть какой-то маршрутизатор, на котором все маршрутизаторы поддерживают многоадресную рассылку. 88 00:04:54,660 --> 00:04:57,380 знай, что это тот парень, к которому мы идем. 89 00:04:57,380 --> 00:04:59,460 Это и есть точка встречи. 90 00:04:59,460 --> 00:05:03,060 Итак, теперь ваш маршрутизатор скажет: «Хорошо, я собираюсь создать что-то под названием 91 00:05:03,060 --> 00:05:05,380 соединение, сообщение о присоединении к многоадресной рассылке. 92 00:05:05,380 --> 00:05:09,520 И я отправлю его в сторону места встречи, сказав: эй, 93 00:05:09,520 --> 00:05:12,520 У меня здесь парень, который ищет эту группу. 94 00:05:12,520 --> 00:05:17,460 И в конечном итоге это соединение доходит до точки встречи. 95 00:05:17,460 --> 00:05:20,900 Возможно, источник еще не начался, но точка встречи уже есть. 96 00:05:20,900 --> 00:05:25,000 построил ветку вниз по дереву от места встречи до 97 00:05:25,000 --> 00:05:27,120 эти маршрутизаторы до шлюза по умолчанию. 98 00:05:27,120 --> 00:05:32,320 Теперь мы открыли путь, и если многоадресная рассылка все-таки начнется, она будет 99 00:05:32,320 --> 00:05:34,240 направление, в котором оно может течь. 100 00:05:34,240 --> 00:05:38,040 Теперь запускается источник, источник, сервер. 101 00:05:38,040 --> 00:05:41,900 Итак, этот сервер начинает отправлять многоадресную рассылку и попадает на маршрутизатор, 102 00:05:41,900 --> 00:05:45,580 какой-то маршрутизатор, подключенный к этому сегменту, стучит по задней части 103 00:05:45,580 --> 00:05:47,580 голову с этим мультикастовым трафиком. 104 00:05:47,580 --> 00:05:50,440 И снова тот маршрутизатор там, в другом углу сети. 105 00:05:50,440 --> 00:05:55,300 говорит, я никогда не слышал ни от каких приемников, но знаю, где знакомство 106 00:05:55,300 --> 00:06:03,540 сервис есть. Я знаю, где место встречи. 107 00:06:03,540 --> 00:06:07,080 И мы углубимся в это подробнее, но в основном это инкапсулирует 108 00:06:07,080 --> 00:06:12,500 это в одноадресной рассылке. Он принимает этот многоадресный пакет и оборачивает его в одноадресный. 109 00:06:12,500 --> 00:06:16,500 заголовок и передает его в точку встречи. 110 00:06:16,500 --> 00:06:20,920 Как только точка встречи получает его, он деинкапсулирует его и говорит: о, вот 111 00:06:20,920 --> 00:06:24,240 многоадресная рассылка. О да, я знаю, к чему это приведет, потому что я получил приглашение 112 00:06:24,240 --> 00:06:27,360 за это он и отправляет его на дерево. 113 00:06:27,360 --> 00:06:31,020 Так вот как в протоколах разреженного режима мы их изначально подключаем, верно? 114 00:06:31,020 --> 00:06:33,460 Эта точка встречи — служба знакомств. 115 00:06:33,460 --> 00:06:37,460 Но, как и в моей аналогии, вам не нужен источник и приемник. 116 00:06:37,460 --> 00:06:41,360 постоянно проходим через место встречи, чтобы поговорить друг с другом. 117 00:06:41,360 --> 00:06:43,400 Это не обязательно эффективно, верно? 118 00:06:43,400 --> 00:06:49,980 Что, если этот получатель находится во Флориде, источник — в Северной Каролине, 119 00:06:49,980 --> 00:06:52,680 но место встречи в Калифорнии? 120 00:06:52,680 --> 00:06:55,700 Ну, из-за того, что пробки сильно затруднены, чтобы добраться до места встречи. 121 00:06:55,700 --> 00:07:00,300 точку и обратно. Прямо между источником путь гораздо короче. 122 00:07:00,300 --> 00:07:02,140 и ресивер. 123 00:07:02,140 --> 00:07:06,080 Но нам нужно было сначала запустить эту многоадресную рассылку, прежде чем мы сможем обнаружить 124 00:07:06,080 --> 00:07:10,320 откуда оно исходит, что оно исходит из Северной Каролины. 125 00:07:10,320 --> 00:07:13,280 И теперь Роджерсы могут перейти на этот путь. 126 00:07:13,280 --> 00:07:15,060 Они могут сказать: «ОК, спасибо, служба знакомств». 127 00:07:15,060 --> 00:07:16,380 Спасибо, место встречи. 128 00:07:16,380 --> 00:07:17,760 Ты мне больше не нужен. 129 00:07:17,760 --> 00:07:20,240 Теперь я точно знаю, где находится источник. 130 00:07:20,240 --> 00:07:24,040 Мы можем получить трафик напрямую от него и переключиться на него. 131 00:07:24,040 --> 00:07:29,360 путь. Так что это действительно высокий уровень работы протоколов разреженного режима. 132 00:07:29,360 --> 00:07:33,540 Сначала мы должны присоединиться к месту встречи, выразить свою заинтересованность, 133 00:07:33,540 --> 00:07:35,440 построить эту ветку. 134 00:07:35,440 --> 00:07:39,680 Трафик должен начать идти к точке встречи, а затем он переключается. 135 00:07:39,680 --> 00:07:44,620 так что он идет прямо между источником и приемником, рандеву 136 00:07:44,620 --> 00:07:49,260 точка больше даже не является частью уравнения. 137 00:07:49,260 --> 00:07:56,680 Таким образом, протоколы разреженного режима используют так называемые деревья на основе ядра или деревья RP. 138 00:07:56,680 --> 00:07:58,500 потому что у нас есть место встречи. 139 00:07:58,500 --> 00:08:01,140 Итак, точка встречи — это ядро ​​дерева. 140 00:08:01,140 --> 00:08:05,620 Все начинают с того, что идут к нему, а потом это довольно быстро от него отходит. 141 00:08:05,620 --> 00:08:16,700 быстро. Хорошо, если вы, конечно, не знакомы с RPF, RPF может 142 00:08:16,700 --> 00:08:16,880 переключитесь на дерево. 143 00:08:16,880 --> 00:08:20,780 Это много разных вещей, но в данном конкретном случае это означает 144 00:08:20,780 --> 00:08:23,260 переадресация обратного пути. 145 00:08:23,260 --> 00:08:27,060 Теперь подумайте об одноадресном трафике. 146 00:08:27,060 --> 00:08:29,840 Давайте на секунду отойдем от многоадресной рассылки. 147 00:08:29,840 --> 00:08:36,720 Маршрутизатор получает одноадресный пакет, направляющийся в некоторый пункт назначения 9.9.9.9. 148 00:08:36,720 --> 00:08:38,560 Что делает роутер? 149 00:08:38,560 --> 00:08:43,420 Маршрутизатор говорит: «Хорошо, я посмотрю IP-адрес назначения». 150 00:08:43,420 --> 00:08:47,920 зайди в мою таблицу маршрутизации и посмотри, есть ли у меня какой-нибудь маршрут, который сообщает 151 00:08:47,920 --> 00:08:49,940 мне, где этот пункт назначения. 152 00:08:49,940 --> 00:08:54,740 Обычно для того, чтобы направить этот пакет и отправить его в путь, 153 00:08:54,740 --> 00:08:58,060 маршрутизатор заботится об источнике этого пакета? 154 00:08:58,060 --> 00:09:01,320 Нет, вам плевать, что это за адрес источника. 155 00:09:01,320 --> 00:09:05,260 На самом деле, вы можете указать 0, 0, 0, 0 в качестве источника, маршрутизатора. 156 00:09:05,260 --> 00:09:09,220 было бы все равно. Для маршрутизации этого пакета все, что ему нужно, это 157 00:09:09,220 --> 00:09:13,920 место назначения. Теперь, конечно, вы можете реализовать списки доступа и другие 158 00:09:13,920 --> 00:09:17,120 подобные вещи, чтобы заставить его посмотреть на источник. 159 00:09:17,120 --> 00:09:20,580 И вы также можете реализовать что-то под названием RPF. 160 00:09:20,580 --> 00:09:25,720 Например, а что, если я, ну, скажем, мой ноутбук прямо сейчас сидит 161 00:09:25,720 --> 00:09:32,120 в сети 11 — 11.что-то, так что у меня был адрес 11, 11.555. 162 00:09:32,120 --> 00:09:34,820 Это адрес моего ноутбука. 163 00:09:34,820 --> 00:09:38,280 И я узнаю, я узнаю через виноградную лозу, что я собираюсь быть 164 00:09:38,280 --> 00:09:41,080 сегодня уволен. Я говорю, что? 165 00:09:41,080 --> 00:09:43,260 Чувак, я провел в этой компании много лет. 166 00:09:43,260 --> 00:09:44,340 Я работал сверхурочно. 167 00:09:44,340 --> 00:09:46,520 Я пожертвовал своими детьми ради этой компании. 168 00:09:46,520 --> 00:09:47,560 Они собираются меня уволить. 169 00:09:47,560 --> 00:09:49,260 Это действительно меня раздражает. 170 00:09:49,260 --> 00:09:50,440 Я говорю: знаете что? 171 00:09:50,440 --> 00:09:56,140 Прежде чем уйти, я узнаю IP-адрес веб-сервера моей компании. 172 00:09:56,140 --> 00:10:00,000 Это 77777. Так что я немного, достаточно подкован. 173 00:10:00,000 --> 00:10:00,560 Я говорю, знаешь что? 174 00:10:00,560 --> 00:10:01,720 Я собираюсь отключить этот сервер. 175 00:10:01,720 --> 00:10:05,040 Я собираюсь завалить этот сервер, не знаю, каким-то трафиком. 176 00:10:05,040 --> 00:10:07,300 Может быть, запросы на синхронизацию TCP, верно? 177 00:10:07,300 --> 00:10:11,080 Я просто собираюсь поразить его 5 миллионами TCP-синхронизаций каждую секунду. 178 00:10:11,080 --> 00:10:12,440 Принеси это. Так что ха-ха-ха. 179 00:10:12,440 --> 00:10:13,540 Ты хочешь меня уволить? 180 00:10:13,540 --> 00:10:15,780 Я заставлю вас, ребята, потерять миллионы долларов за следующую пару 181 00:10:15,780 --> 00:10:18,100 часов, пока ваш сервер не работает. 182 00:10:18,100 --> 00:10:22,240 Что ж, если я решу это сделать, я не хочу, чтобы люди отслеживали эти пакеты. 183 00:10:22,240 --> 00:10:23,580 вернись ко мне, да? 184 00:10:23,580 --> 00:10:27,360 Потому что меня не только уволят, теперь я буду сидеть в тюремной камере с 185 00:10:27,360 --> 00:10:29,060 кто-то, кого я не особенно люблю. 186 00:10:29,060 --> 00:10:30,280 Так что я этого не хочу. 187 00:10:30,280 --> 00:10:34,080 Поэтому я говорю: хм, если я собираюсь отправить эти запросы синхронизации TCP на этот сервер 188 00:10:34,080 --> 00:10:37,480 чтобы попытаться подавить его, я хочу убедиться, что исходный адрес 189 00:10:37,480 --> 00:10:41,160 не я. Я не хочу быть 11555, которым являюсь я. 190 00:10:41,160 --> 00:10:44,940 Я хочу подделать этот исходный адрес, чтобы он выглядел как что-то другое. 191 00:10:44,940 --> 00:10:49,000 Так что, если они найдут эти пакеты, они никогда не узнают, что они исходили от меня. 192 00:10:49,000 --> 00:10:53,000 Поэтому я дам ему поддельный IP-адрес, потому что я знаю, когда эти пакеты поступают. 193 00:10:53,000 --> 00:11:00,260 маршрутизаторы, маршрутизаторы не заботятся о том, какой адрес источника. 194 00:11:00,260 --> 00:11:02,260 И оно рухнет. 195 00:11:02,260 --> 00:11:06,960 Что ж, если я сетевой администратор, я могу сделать одну вещь, чтобы предотвратить 196 00:11:06,960 --> 00:11:12,540 люди от этого, я могу использовать так называемую одноадресную проверку RPF, 197 00:11:12,540 --> 00:11:16,740 это означает, что когда пакет поступает в интерфейс маршрутизатора, прежде чем 198 00:11:16,740 --> 00:11:21,460 Я даже смотрю на адрес назначения, я собираюсь посмотреть на источник 199 00:11:21,460 --> 00:11:25,440 адрес, и я задам себе очень простой вопрос. 200 00:11:25,440 --> 00:11:31,180 Этот исходный адрес, если бы я хотел вернуться в обратном направлении к 201 00:11:31,180 --> 00:11:36,280 этот источник, буду ли я использовать этот интерфейс там, где он только что появился? 202 00:11:36,280 --> 00:11:38,480 Теперь я сижу здесь. 203 00:11:38,480 --> 00:11:44,100 У меня 11.555. Я намеренно изменил исходный адрес моего пакета 204 00:11:44,100 --> 00:11:49,320 на что-то совершенно фальшивое, например, 12, 12, 12, 12. 205 00:11:49,320 --> 00:11:51,060 Ну, это вошло в этот интерфейс. 206 00:11:51,060 --> 00:11:53,580 Оно пришло быстро, Итан, в 00 на маршрутизаторе. 207 00:11:53,580 --> 00:11:57,720 Согласно таблице маршрутизации этого роутера, говорит он, чтобы добраться до 12, 12 208 00:11:57,720 --> 00:12:01,120 сети, я бы не стал торопиться, Итан в 00. 209 00:12:01,120 --> 00:12:03,740 Я бы вышел на 11 серию. 210 00:12:03,740 --> 00:12:08,120 Итак, если этот сетевой администратор настроил одноадресную проверку RPF 211 00:12:08,120 --> 00:12:11,260 маршрутизатор, маршрутизатор скажет, что с этим пакетом что-то не так. 212 00:12:11,260 --> 00:12:15,660 По моему обратному пути, я бы не пошел по этому пути, чтобы добраться до 12. 213 00:12:15,660 --> 00:12:16,700 Я бы пошел этим путем. 214 00:12:16,700 --> 00:12:21,280 Пакет пришел не по тому интерфейсу и будет отброшен. 215 00:12:21,280 --> 00:12:22,340 Это будет отброшено. 216 00:12:22,340 --> 00:12:25,760 И теперь мой сервер никогда не получит этот пакет. 217 00:12:25,760 --> 00:12:27,980 Это никогда не повредит серверу. 218 00:12:27,980 --> 00:12:29,900 Это не включено по умолчанию. 219 00:12:29,900 --> 00:12:33,580 Проверка Unicast RPF — это то, что вам нужно включить, если вы хотите сделать 220 00:12:33,580 --> 00:12:36,840 что. Ну и какое отношение это имеет к этому? 221 00:12:36,840 --> 00:12:43,420 Когда вы включаете многоадресную рассылку, протоколы многоадресной маршрутизации выполняют проверку RPF. 222 00:12:43,420 --> 00:12:45,780 источник по умолчанию. 223 00:12:45,780 --> 00:12:48,140 На самом деле, вы не можете помешать им сделать это. 224 00:12:48,140 --> 00:12:50,400 Они это делают. Почему они это делают? 225 00:12:50,400 --> 00:12:52,940 Они делают это для обнаружения петель. 226 00:12:52,940 --> 00:12:56,240 Идея в том, что когда приходит многоадресный пакет, вам не нужно просто обводить его кружком. 227 00:12:56,240 --> 00:12:58,600 по сети навсегда. 228 00:12:58,600 --> 00:13:04,280 Итак, маршрутизаторы говорят: «ОК, маршрутизатор работает в разреженном режиме». 229 00:13:04,280 --> 00:13:08,840 протоколы. Итак, если я маршрутизатор, находящийся в сети, скажем так, я 230 00:13:08,840 --> 00:13:09,700 шлюз по умолчанию. 231 00:13:09,700 --> 00:13:14,020 Я шлюз, подключенный к этому ресиверу, к моему ноутбуку прямо здесь. 232 00:13:14,020 --> 00:13:18,800 И мне только что сообщили через IGMP, что этот получатель хочет получать 233 00:13:18,800 --> 00:13:22,240 какая-то многоадресная рассылка. 239-777. 234 00:13:22,240 --> 00:13:27,780 Давайте просто нарисуем это, чтобы было понятно. 235 00:13:27,780 --> 00:13:39,460 Хорошо. Итак, вот, ох, подожди секунду. 236 00:13:39,460 --> 00:13:42,820 Тогда я просто сделаю это вот так. 237 00:13:42,820 --> 00:13:47,540 Вот мой приемник в виде квадрата. 238 00:13:47,540 --> 00:13:50,920 Мы назовем это маленьким Р. 239 00:13:50,920 --> 00:13:58,180 А вот шлюз по умолчанию, к которому он подключен. 240 00:13:58,180 --> 00:14:01,940 Шлюз по умолчанию. 241 00:14:01,940 --> 00:14:08,900 И у него есть несколько интерфейсов, ведущих вверх по течению. 242 00:14:08,900 --> 00:14:14,720 Мы просто скажем интерфейс один, два и три. 243 00:14:14,720 --> 00:14:16,320 Не важно, какие они. 244 00:14:16,320 --> 00:14:19,840 Последовательный порт Fast Ethernet, для данного обсуждения это не имеет значения. 245 00:14:19,840 --> 00:14:27,300 Теперь этот маршрутизатор только что получил отчет о членстве в IGMP от 246 00:14:27,300 --> 00:14:39,060 получатель. И этот получатель хочет получить трафик на номер 239-777. 247 00:14:39,060 --> 00:14:41,740 Это группа, в которой он хочет участвовать. 248 00:14:41,740 --> 00:14:46,020 Теперь этот маршрутизатор использует протокол маршрутизации в разреженном режиме. 249 00:14:46,020 --> 00:14:47,280 Итак, мы просто скажем, что это PIM. 250 00:14:47,280 --> 00:14:51,420 Он использует независимый от протокола протокол многоадресной маршрутизации. 251 00:14:51,420 --> 00:14:54,120 Итак, в рамках PIM, чтобы заставить PIM работать, он говорит: ладно, я знаю. 252 00:14:54,120 --> 00:14:55,420 где-то есть какой-то роутер. 253 00:14:55,420 --> 00:15:00,660 Мы назовем это отсюда, это моя точка встречи. 254 00:15:00,660 --> 00:15:04,140 И поэтому я должен сообщить месту встречи, что у меня есть приемник. 255 00:15:04,140 --> 00:15:05,860 здесь внизу, кто этого хочет. 256 00:15:05,860 --> 00:15:10,240 Допустим, эта точка встречи — 8888. 257 00:15:10,240 --> 00:15:14,580 Так вот этот роутер, говорит, ладно, я знаю. 258 00:15:14,580 --> 00:15:17,400 Давайте просто создадим здесь небольшой мысленный пузырь. 259 00:15:17,400 --> 00:15:22,220 Он говорит, я знаю, что PIM RP — 8888. 260 00:15:22,220 --> 00:15:26,960 Теперь он говорит: ладно, как мне добраться до PIM RP? 261 00:15:26,960 --> 00:15:30,260 Здесь он использует свой протокол одноадресной маршрутизации. 262 00:15:30,260 --> 00:15:35,100 Я несколько раз упоминал, что многоадресная маршрутизация работает рука об руку с 263 00:15:35,100 --> 00:15:36,920 ваш протокол одноадресной маршрутизации. 264 00:15:36,920 --> 00:15:39,560 Он говорит: ладно, позвольте мне зайти в мою таблицу маршрутизации. 265 00:15:39,560 --> 00:15:42,980 И согласно моей таблице маршрутизации, у меня есть маршрут EI-JRP, который говорит: 266 00:15:42,980 --> 00:15:49,800 доступ к сети 8.8 осуществляется через интерфейс 2. 267 00:15:49,800 --> 00:15:56,920 Поэтому он отправляет интерфейс соединения PIM 2. 268 00:15:56,920 --> 00:16:04,620 И в конечном итоге это соединение PIM проходит через сеть и получает 269 00:16:04,620 --> 00:16:06,420 до места встречи. 270 00:16:06,420 --> 00:16:09,840 Итак, теперь это общее дерево, верно? 271 00:16:09,840 --> 00:16:14,600 Это дерево, идущее от точки встречи до шлюза по умолчанию. 272 00:16:14,600 --> 00:16:19,960 Теперь этот шлюз по умолчанию, поскольку он использует разреженный режим PIMS, говорит он, 273 00:16:19,960 --> 00:16:27,080 окей, я ожидаю, что когда многоадресная рассылка действительно начнется, когда бы она ни начиналась, 274 00:16:27,080 --> 00:16:31,260 он должен спуститься с места встречи. 275 00:16:31,260 --> 00:16:35,640 Допустим, многоадресная рассылка все же началась, и вот она. 276 00:16:35,640 --> 00:16:38,680 Здесь это происходит следующим образом. 277 00:16:38,680 --> 00:16:44,540 Итак, источник 7777. 278 00:16:44,540 --> 00:16:48,660 Адресат: 239.777. 279 00:16:48,660 --> 00:16:54,700 Ну, поскольку этот парень использует разреженный режим PIMS, он выполняет проверку RPF. 280 00:16:54,700 --> 00:16:55,660 Но вот как это работает. 281 00:16:55,660 --> 00:17:01,200 Он говорит: ну, потому что я ожидал, что эта многоадресная рассылка придет через 282 00:17:01,200 --> 00:17:06,740 точка встречи, говорит он, через какой интерфейс она должна была войти? 283 00:17:06,740 --> 00:17:10,820 Ну, согласно моей таблице маршрутизации, чтобы добраться до точки встречи, мне 284 00:17:10,820 --> 00:17:12,540 зайдите через интерфейс 2. 285 00:17:12,540 --> 00:17:16,860 Ха, эта многоадресная рассылка не дошла до точки встречи. 286 00:17:16,860 --> 00:17:19,000 Это не пришло из интерфейса 2. 287 00:17:19,000 --> 00:17:21,820 Угадайте, что? Я собираюсь убить его. 288 00:17:21,820 --> 00:17:24,240 Это сбой ПФР. 289 00:17:24,240 --> 00:17:29,080 Не возникло того, что мы называем общим деревом, деревом, которое является общим. 290 00:17:29,080 --> 00:17:31,620 между точкой встречи и этим шлюзом по умолчанию. 291 00:17:31,620 --> 00:17:35,460 Он просто не прошел проверку RPF. 292 00:17:35,460 --> 00:17:38,740 Теперь предположим, что все произошло вот так. 293 00:17:38,740 --> 00:17:41,820 Хорошо, значит, он пошел по правильному пути. 294 00:17:41,820 --> 00:17:43,960 Проверка RPF завершится успешно. 295 00:17:43,960 --> 00:17:48,020 Это пройдет. Он говорил: «ОК, меня интересует эта группа», и так оно и было. 296 00:17:48,020 --> 00:17:52,640 зайдите на правильный интерфейс, на интерфейс 2, который является интерфейсом 297 00:17:52,640 --> 00:17:55,100 ведущий к РП. 298 00:17:55,100 --> 00:17:56,760 Теперь происходит нечто интересное. 299 00:17:56,760 --> 00:17:58,480 Итак, давайте просто продолжим и вернем это сюда. 300 00:17:58,480 --> 00:18:04,080 Источник — 777. Назначение — 239,777. 301 00:18:04,080 --> 00:18:09,460 Хорошо, он может переслать эту многоадресную рассылку клиенту, получателю. 302 00:18:09,460 --> 00:18:14,760 Теперь впервые этот маршрутизатор говорит: «О, наконец-то я знаю, кто 303 00:18:14,760 --> 00:18:21,480 источник есть. Фактический адрес сервера — 777. 304 00:18:21,480 --> 00:18:25,860 Теперь ПИМС-СПАР-СМО говорит: окей, я мог бы и дальше получать это от рандеву. 305 00:18:25,860 --> 00:18:28,640 точка, но есть ли лучший путь? 306 00:18:28,640 --> 00:18:32,880 Есть ли на самом деле более короткий путь, чтобы добраться до этого источника, который был бы более 307 00:18:32,880 --> 00:18:36,900 эффективный? Поэтому он возвращается к своей таблице маршрутизации. 308 00:18:36,900 --> 00:18:42,140 Он говорит: «Хорошо, теперь позвольте мне провести поиск по этому вопросу в RPF». 309 00:18:42,140 --> 00:18:48,060 И он говорит: ох, и вот, у меня есть маршрут, который соответствует этому, этому 310 00:18:48,060 --> 00:18:49,880 Я учился через EIGRP. 311 00:18:49,880 --> 00:18:52,620 Опять же, это можно узнать через RIP или OSPF. 312 00:18:52,620 --> 00:18:58,240 Нам все равно. Он говорит, что через интерфейс 1. 313 00:18:58,240 --> 00:19:00,740 Итак, теперь PIM делает что-то особенное. 314 00:19:00,740 --> 00:19:04,940 Таким же образом он отправляет еще одно соединение PIM. 315 00:19:04,940 --> 00:19:09,720 Мы собираемся разобраться во всех подробностях этого дела. 316 00:19:09,720 --> 00:19:17,340 И он говорит, это для источника 777 назначения 239.777. 317 00:19:17,340 --> 00:19:21,820 И это соединение PIM идет до конца. 318 00:19:21,820 --> 00:19:25,960 Допустим, источник находится здесь. 319 00:19:25,960 --> 00:19:31,360 Собственно, там и находится сервер. 320 00:19:31,360 --> 00:19:34,540 И посередине была куча маршрутизаторов. 321 00:19:34,540 --> 00:19:36,000 Итак, вот роутер. 322 00:19:36,000 --> 00:19:37,760 Вот роутер. 323 00:19:37,760 --> 00:19:38,940 И вот роутер. 324 00:19:38,940 --> 00:19:41,000 И они все связаны вот так. 325 00:19:41,000 --> 00:19:47,760 Если предположить, что все эти маршрутизаторы знают, как попасть в сеть 777, то 326 00:19:47,760 --> 00:19:52,620 специальное соединение PIM прошло бы весь путь и, наконец, добралось бы до 327 00:19:52,620 --> 00:19:55,560 этот маршрутизатор, подключенный к источнику. 328 00:19:55,560 --> 00:19:59,240 И это теперь открыло дерево кратчайшего пути. 329 00:19:59,240 --> 00:20:00,780 Обратите внимание, что у нас здесь два разных дерева. 330 00:20:00,780 --> 00:20:04,520 У нас есть синий и зеленый. 331 00:20:04,520 --> 00:20:08,560 А синяя точка до шлюза по умолчанию называлась общим деревом. 332 00:20:08,560 --> 00:20:11,280 или иногда называемое деревом RP. 333 00:20:11,280 --> 00:20:14,400 Иногда вы можете увидеть аббревиатуру RPT. 334 00:20:14,400 --> 00:20:19,240 Это сработало, но, возможно, это не самый эффективный путь. 335 00:20:19,240 --> 00:20:23,720 Это зеленое дерево — дерево кратчайшего пути. 336 00:20:23,720 --> 00:20:28,320 Но мы не знали, что это было, пока не узнали, где находится источник, пока 337 00:20:28,320 --> 00:20:31,140 мы получили наш самый первый многоадресный пакет. 338 00:20:31,140 --> 00:20:35,360 Итак, теперь, когда мы открыли это дерево, маршрутизатор говорит: окей, 339 00:20:35,360 --> 00:20:42,380 в этот момент, на небольшой момент времени, в следующий раз я получу многоадресную рассылку 340 00:20:42,380 --> 00:20:45,660 пакет, он может прийти из одного из двух мест. 341 00:20:45,660 --> 00:20:50,200 Я приму его на втором интерфейсе, потому что оно все еще может исходить от 342 00:20:50,200 --> 00:20:51,800 место встречи. 343 00:20:51,800 --> 00:20:55,680 И теперь, если это произойдет на первом интерфейсе, я тоже приму это, потому что я 344 00:20:55,680 --> 00:20:57,000 пытался открыть этот путь. 345 00:20:57,000 --> 00:21:01,560 Я намеренно пытался открыть этот путь, надеясь, что многоадресный трафик 346 00:21:01,560 --> 00:21:04,100 спустится сюда. 347 00:21:04,100 --> 00:21:09,320 Итак, если многоадресная рассылка поступает на третий интерфейс, это будет сбой RPF. 348 00:21:09,320 --> 00:21:12,660 Потому что маршрутизатор говорит: «Эй, интерфейс третий, это не общее дерево». 349 00:21:12,660 --> 00:21:16,180 и это не дерево кратчайшего пути. 350 00:21:16,180 --> 00:21:20,720 Но в любом из этих случаев он пройдет проверку RPF. 351 00:21:20,720 --> 00:21:25,920 И как только многоадресная рассылка действительно начнет течь и поступать на интерфейс 352 00:21:25,920 --> 00:21:30,500 номер один, теперь шлюз по умолчанию скажет: отлично! 353 00:21:30,500 --> 00:21:33,940 Я получаю многоадресный трафик наиболее эффективным способом. 354 00:21:33,940 --> 00:21:36,260 через дерево кратчайших путей. 355 00:21:36,260 --> 00:21:39,340 Мне больше не нужно забирать его с места встречи. 356 00:21:39,340 --> 00:21:44,380 Таким образом, он на самом деле отправит сообщение PIM об обрезке таким образом, которое обрежет 357 00:21:44,380 --> 00:21:51,460 с этого дерева. И теперь мультикаст будет идти по кратчайшему пути 358 00:21:51,460 --> 00:21:56,100 дерево путей до тех пор, пока получатель больше не захочет его использовать. 359 00:21:56,100 --> 00:21:59,760 Так что это очень высокий уровень того, как работает разреженный режим PIM. 360 00:21:59,760 --> 00:22:04,280 Но я сделал все это для того, чтобы показать вам, что проверки ПФР происходят. 361 00:22:04,280 --> 00:22:09,860 Все зависит от того, откуда маршрутизатор ожидает получить многоадресную рассылку. 362 00:22:09,860 --> 00:22:13,480 Если он ожидает, что звук придет с места встречи, он собирается 363 00:22:13,480 --> 00:22:17,860 скажем, смотри, точка встречи находится на интерфейсе один или интерфейсе семь, 364 00:22:17,860 --> 00:22:20,640 и он узнает об этом по своему протоколу маршрутизации. 365 00:22:20,640 --> 00:22:24,280 Именно здесь я ожидаю изначально получить многоадресную рассылку. 366 00:22:24,280 --> 00:22:27,800 Если оно исходит из любого другого интерфейса, я его убью. 367 00:22:27,800 --> 00:22:28,820 Я собираюсь бросить это. 368 00:22:28,820 --> 00:22:31,340 Это не должно было произойти таким образом. 369 00:22:31,340 --> 00:22:34,880 Но как только он узнает источник и попытается открыть этот кратчайший путь 370 00:22:34,880 --> 00:22:39,500 дерево путей, теперь RPF увенчается успехом. 371 00:22:39,500 --> 00:22:46,420 Это пройдет, если многоадресная рассылка пройдет по дереву кратчайшего пути. 372 00:22:46,420 --> 00:22:51,840 Так как же нам определить правильный входной интерфейс? 373 00:22:51,840 --> 00:22:56,480 Как мы можем гарантировать, что RPF завершится успешно или пройдет в зависимости от типа? 374 00:22:56,480 --> 00:22:58,800 дерева, которое мы ожидаем? 375 00:22:58,800 --> 00:23:02,460 Ожидаем ли мы, что он спустится по основному дереву, также известному как 376 00:23:02,460 --> 00:23:09,940 РП-дерево? Или мы ожидаем, что этот трафик пойдет вниз по дереву источников? 377 00:23:09,940 --> 00:23:16,400 Теперь это может зависеть от конкретного типа IGP. 378 00:23:16,400 --> 00:23:18,620 О чем я там говорю? 379 00:23:18,620 --> 00:23:21,980 PIM — не единственный протокол многоадресной маршрутизации. 380 00:23:21,980 --> 00:23:22,800 Есть и другие. 381 00:23:22,800 --> 00:23:27,120 Например, MOSPF, многоадресная рассылка OSPF. 382 00:23:27,120 --> 00:23:31,440 Вы, наверное, догадались, использую ли я многоадресную рассылку OSPF, чтобы выяснить 383 00:23:31,440 --> 00:23:35,140 какой правильный интерфейс для перехода к RP или правильный интерфейс 384 00:23:35,140 --> 00:23:39,480 для перехода к источнику используются маршруты OSPF. 385 00:23:39,480 --> 00:23:44,120 MOSPF не может выполнять проверку RPF на основе RIP или EIGRP. 386 00:23:44,120 --> 00:23:50,500 Ему нужен OSPF. Есть еще один вариант, DVMRP, Distance Vector Multicast. 387 00:23:50,500 --> 00:23:51,940 Протокол маршрутизации. 388 00:23:51,940 --> 00:23:53,120 Это как-то странно. 389 00:23:53,120 --> 00:23:59,660 Фактически он создает свою собственную отдельную одноадресную таблицу только для проверки RPF. 390 00:23:59,660 --> 00:24:01,140 Таблица DVMRP. 391 00:24:01,140 --> 00:24:02,920 Он не использует ничего другого. 392 00:24:02,920 --> 00:24:08,720 Замечательная вещь в PIM, независимой от протокола многоадресной рассылке. 393 00:24:08,720 --> 00:24:13,000 Независимый от протокола означает, что PIM говорит: «Мне все равно». 394 00:24:13,000 --> 00:24:16,100 Когда я выполняю проверку RPF, я собираюсь зайти в таблицу маршрутизации. 395 00:24:16,100 --> 00:24:19,960 Меня не волнует, смогу ли я найти статический маршрут, связанный маршрут, 396 00:24:19,960 --> 00:24:21,540 EIGRP, RIP, OSPF. 397 00:24:21,540 --> 00:24:27,160 Мне все равно. Пока я могу найти что-нибудь для проверки RPF, 398 00:24:27,160 --> 00:24:32,040 Я буду счастлив. Вот почему PIM так популярен, потому что он позволяет использовать 399 00:24:32,040 --> 00:24:35,100 любой протокол маршрутизации IGP, который вы хотите. 400 00:24:35,100 --> 00:24:36,860 Это не зависит от этого.