Allowas-in: приём апдейтов с собственной AS

В этом уроке мы рассмотрим такую ситуацию, когда у вас получается некая разрозненная автономная система, подключенная, например, к двум разным сервис-провайдерам, либо к одному сервис-провайдеру. Но при этом моштизаторы внутри одной автономной системы могут располагаться, скажем, на разных сайтах. Так, что я сейчас имею в виду? Для симуляции того, что автономная система, в нашем случае это уже будет AS2.2.3, разнесена как-то там географически, я сейчас просто погашу, например, вот этот вот линк. И в этом случае единственным путем для BGP-апдейтов от амортизатора 1, амортизатор R2 станет путь через желтого сервис-провайдера.

Через желтого сервис-провайдера. Давайте посмотрим, к чему это может... А, единственное, я погашу сразу, например, интерфейс между амортизаторами R2 и R3. Вот здесь. Давайте посмотрим, к чему это приведет. На мошатре R1 я должен погасить 12 интерфейс. И там нам нужно погасить 23. Вот так, интерфейс G2.12 shutdown. Интерфейс G2.12 shutdown. Интерфейс G2.23 shutdown. Здесь интерфейс G2.23 shutdown.

Так, у нас разрушилось все SPF-соседство. Обратите внимание, что мы погасили 23-й интерфейс. То есть у нас теперь showIPCF3333 недоступен. То есть это no route. Но при этом showIPBGP summary. Обратите внимание, что BGP-сессия с амортизатором R3 до сих пор поднята. И как раз это будет тема нашего следующего урока о том, как ускорить BGP-конвергенцию. Вот такие ситуации. Смотрим showIPBGP-neighbor3333. Обратите внимание, hold timer is 180 секунд. То есть нам придется в любом случае подождать некоторое время. Я пока приостановлю запись до момента, пока BGP-соседство не разрушится.

Итак, я дождался момента, когда BGP-соседство пропадет между амортизаторами. Hold time expired. Занял этот процесс приблизительно 3 минуты. То есть время 17.31. Когда у нас развалилось SPF-соседство, время было 17.28. Таким образом, BGP у нас довольно-таки долго конвергировал. Но, тем не менее, мы добились того, что наше соседство находится в состоянии idle. Иммунициатор R2 имеет связанность только с мусседатором R5. А к чему это приводит? Обратите внимание. Show IPBGP. И сравним его с выводом, например, на амортизаторе R1. Теперь, видите, на амортизаторе R1 есть префикс, скажем, 4 единички.

Есть префикс 4 единички. А данного префикса нет на амортизаторе R2. Почему так происходит? Давайте сделаем debug IPBGP. BGP updates. И скажем clear IPBGP 10.255. Теперь, внимание, амортизатор R2 отклоняет префикс мусседатора R1. Из-за чего? Из-за того, что внутри атрибута ISPath присутствует наша собственная IS. А как же быть в такой ситуации? Ведь по факту, по факту, мы-то знаем, что у нас не может быть никакой петли. Наши сайты физически разнесены. И нам нужно принимать апдейты друг от друга. Вариант номер один.

Вариант номер один. Что вы можете сделать? В теории, в теории, вы можете построить, например, GRE-туннель, либо IP-to-IP-туннель. То есть на точке терминации выступить вот этот интерфейс и вот этот интерфейс. То есть у вас будет GRE-туннель поверх, например, желтого провайдера. То есть будет GRE-туннель вот так вот сделано. Внутри этого туннеля вы построите IBGP-сессию. То есть по факту, по факту, это будет просто замена вот этому прямому лин. То есть вы можете пустить ваш BGP внутри туннеля. Это первый вариант. Есть второй вариант. Есть второй вариант. Мы можем прийти на мышкизатор R2 и сказать router BGP 123. Извините, 223.

И сказать следующую вещь. Neighbor 10255. И у нас здесь должна быть команда. Hello. Hello. ISEIN. И обратите внимание, что мы получаем апдейт теперь 1.1.1.1. И инсталируем его в RIP-таблицу. Show IBGP. И, смотрите, внимание, появился префикс. Хоть и в автономном, и хоть и в ISEPAS содержится наш собственный номер автономной системы. Что это за команда такая? Hello. ISEIN. Работает она следующим образом.

Работает она следующим образом. Так. Наш мышкизатор R1. Наш мышкизатор R2. И вот здесь есть какое-то облако. Да, там сервис провайдер. Мужкизатор R1 передает апдейт с ISEPAS равным 223. Далее этот ISEPAS как-то модифицируется, когда апдейт ходит по различным сервис провайдерам. И в итоге в сторону мышкизатора R2 вылетает ISEPAS следующего вида. В начале строки стоит 223, а потом номера автономных систем. X, Y и Z. Если на мышкизаторе R2 введена команда LOISIN, то мышкизатор R2 начинает просматривать ISEPAS.

Начинает просматривать ISEPAS. И если внутри ISEPAS содержится номер нашей автономной системы, то есть номер 223, и при этом номер автономной системы стоит в начале ISEPAS, не посередине, не в конце, а только в начале, то в таком случае апдейт разрешается. Что значит, когда автономка стоит первой? Это значит, что префикс там был и сгенерирован. Если вдруг так получится, скажем, что 223 будет стоять где-нибудь вот здесь, то такой апдейт будет отброшен. Давайте в этом с вами убедимся. Как мы можем убедиться в том, что мы будем принимать апдейты, которые начинаются на 223,

и отбрасывать автоматически все остальные? Я думаю, что все очень просто. Например, на мышкизаторе R5. На мышкизаторе R5. Нет, наверное, не хорошо на мышкизаторе R5. Лучше сделать это дело на мышкизаторе R9, например. Да, давайте сделаем на мышкизаторе R9. То есть это устройство, которое у нас стоит вот здесь. Я на мышкизаторе R9 сделаю просто препенды вот сюда, и внутрь этих препендов где-нибудь поставлю номер 223, то есть где-нибудь вот в серединке. Проверим show ip в gpsummary. Idle. Я сначала создаю route map.rep.prepend. Пермит 10. Говорю set.

Aspass.prepend. И какой-нибудь произвольный 7.6.5. 1.3456. Где-нибудь там 789.0. И где-нибудь здесь, например, 223. Скажу 7.6.5. 4.9.2. То есть вот такой вот Aspass генерирую. И дальше говорю router bgp. 9. И начинаю препендить данные автономки, например, в сторону мышкизатора R8. Единственное, я хочу сначала обратить ваше внимание, что после того, как я поднял сессию, у меня должны были, наверное, появиться какие-то префиксы. Сейчас я хочу видеть в том, что есть префикс do show ip vgp. Например, префикс, например, за этот 200.009.

А 200.009 префикс он отдает смурсиатору R6. А вот у мурсиатора R6 show ip vgp summary. Видите, здесь потушена сессия с R4. Давайте ее вернем. Neighbor 10.464. Shutdown. No shutdown. Так. На мурсиаторе R9. На мурсиаторе R9 сделали препенд. Теперь говорим no neighbor shutdown. No neighbor shutdown. Хорошо. Сейчас на мурсиаторе ко мне начали прилетать различные префиксы. В частности, скоро должен будет прилететь префикс от мурсиатора R9.

И теперь я говорю neighbor 10.6.9.6 route map rm prepend на out и говорю clear ip vgp 10.6.9.6 out Соответственно, по идее, сейчас я должен буду... А, это в сторону R6. Да. Хорошо. Давайте проверим на мурсиаторе R0.7. Show ip vgp summary. Так, я получаю этот префикс. Здесь show ip vgp. Так, нам сейчас R9. Show run section vgp.

Раутер vgp 9. Neighbor 10.8.9.8. И поставлю ту же самую route map. Clear ip vgp out сделаем. Извиняюсь. Сейчас на мурсиаторе R9 должны вот эти AS-ки поменяться. Да. Как видите, то есть теперь у меня поменялись эти вот AS-ки. Вот они стали... Например, для префикса 200.0.0.9 эти они стали вот такими. Теперь на мурсиаторе R5 давайте посмотрим. Show ip vgp. Мурсиатор R5 ничего не имеет. Почему? Давайте посмотрим мурсиатор R7. Он добавил. Здесь show ip vgp. На мурсиаторе R7 есть префикс 200.0.0.9. Обратите внимание,

что он получен... Он никому не адвертайзится из-за того, что у нас еще со старой лаба стоит community новодвертайз. Поэтому нам в сатуре R8 давайте снимем это community новодвертайз. Раутер vgp. 457.8. Скажем, no neighbor no... То есть применим такую вещь. Окей, скажем, clear ipvgp 77777777 в направлении out. Окей. Так. Единственное, что маршрутизатор R2 мне пишет, что он инсталлирует префикс 200.0.0.9 в свою таблицу маршрутизации

show ipvgp. Хотя номер ASPAS только лишь здесь. Знаете, возможно, возможно поведение данной команды было изменено в какой-то момент времени. Я честно говорю, я всегда считал, что будет проверяться только если ASK стоит в начале. И команда hello ASK accept ASPAS with my ASPresent internet. Да, как вы видите, что сейчас маршрутизатор будет принимать ASK, он будет принимать update, даже в том случае, если номер автономной системы

стоит где-то в середине. Я должен привести свои извинения за некоторую неточность с моей стороны. я на всякий случай еще уточню данный момент в configuration guide и сделаю потом некоторый update. ippi о записал послер克 лř