Logo
  • ГЛАВНАЯ
  • ОБО МНЕ
  • СЕРТИФИКАТЫ
nocip.ssh@mail.ru
Главная  >  Cisco Routing

Лабораторная работа №2: Управление трафиком (BGP Policy)


Создана 22.07.2026
Отредактирована 27.07.2026
Цель работы: Научиться управлять исходящим и входящим трафиком в автономной системе с помощью атрибутов BGP: Local Preference и AS_PATH Prepending.
Рис. 1. Топология сети
1. Топология:
  • R1 (AS 65001) — пограничный маршрутизатор.
  • R2 (AS 65002) — внешний провайдер №1 (ISP1).
  • R4 (AS 65004) — внешний провайдер №2 (ISP2).
  • R3 (AS 65001) — внутренний маршрутизатор.
  • OSPF используется для связности Loopback-адресов внутри AS 65001.
2. Шаг 1:  Добавьте маршрутизатор R4, это будет второй провайдер ISP2.
 Выполните базовую настройку интерфейсов между R1 <-> R4.
На R1:

R1(config)# interface Ethernet 1/2 R1(config-if)# ip address 10.0.0.9 255.255.255.252 R1(config-if)# no shutdown R1(config-if)# exit

На R4:

R4(config)# interface Eth1/2 R4(config-if)# ip address 10.0.0.10 255.255.255.252 R4(config-if)# no shutdown R4(config-if)# exit R4(config)# interface loopback 0 R4(config-if)# ip address 4.4.4.4 255.255.255.255 R4(config-if)# exit

Настройка BGP
На R1 (AS 65001):

R1(config)# router bgp 65001 R1(config-router)# neighbor 10.0.0.10 remote-as 65004 R1(config-router)# neighbor 10.0.0.10 description ISP2_AS65004 R1(config-router)# exit

На R4 (AS 65004):

R4(config)# router bgp 65004 R4(config-router)# bgp router-id 4.4.4.4 R4(config-router)# network 4.4.4.4 mask 255.255.255.255 R4(config-router)# neighbor 10.0.0.9 remote-as 65001 R4(config-router)# neighbor 10.0.0.9 description Client_AS65001 R4(config-router)# exit

3. Шаг 2: Анализ текущей ситуации
Задание: Изучите вывод команды show ip bgp на R1. Обратите внимание на атрибуты LocPrf и Path.
Ожидаемый вывод: Оба маршрута до внешних сетей (2.2.2.2 и 4.4.4.4) имеют одинаковый Local Preference (100) и одинаковую длину AS_PATH. BGP выбирает лучший путь по другим критериям (например, по Router ID).
Вывод по шагу: По умолчанию BGP не отдает предпочтение ни одному из провайдеров, если не настроены политики.

4. Шаг 3: Управление исходящим трафиком (Local Preference)

Задача: Настроить политику, чтобы весь исходящий трафик от R1 и R3 уходил через провайдера R4 (AS 65004).
Теория: Local Preference (LocPrf) — это атрибут, который работает внутри AS. Чем выше значение LocPrf, тем предпочтительнее маршрут. По умолчанию LocPrf = 100.
Команды для настройки:
1. Создаем Route-Map, который назначает маршрутам от R4 приоритет 150:

R1(config)# route-map SET_PREF_R4 permit 10 R1(config-route-map)# set local-preference 150 R1(config-route-map)# exit

2. Применяем Route-Map к соседу R4 на входящие маршруты (in):

R1(config)# router bgp 65001 R1(config-router)# neighbor 10.0.0.10 route-map SET_PREF_R4 in R1(config-router)# end

3. Перезапускаем BGP-сессию с R4:

R1# clear ip bgp 10.0.0.10

5. Шаг 4: Управление входящим трафиком (AS_PATH Prepending)

Задача: Настроить политику, чтобы внешние сети (например, R2) предпочитали заходить в вашу AS (к сетям 1.1.1.1 и 3.3.3.3) через R4, а не через R2.
Теория: AS_PATH Prepending — это метод искусственного удлинения AS_PATH для конкретного соседа. BGP выбирает путь с самым коротким AS_PATH. Чем длиннее путь, тем менее привлекателен маршрут.
Команды для настройки:
1. Создаем Route-Map, который добавляет два лишних номера AS 65001 в путь:

R1(config)# route-map PREPEND_TO_R2 permit 10 R1(config-route-map)# set as-path prepend 65001 65001 R1(config-route-map)# exit

2. Применяем Route-Map к соседу R2 на исходящие маршруты (out):

R1(config)# router bgp 65001 R1(config-router)# neighbor 10.0.0.2 route-map PREPEND_TO_R2 out R1(config-router)# end R1#copy running-config startup-config

3. Перезапускаем BGP-сессию с R2:

R1# clear ip bgp 10.0.0.2

6. Шаг 5: Проверка работоспособности (Критерии успеха)
Чтобы убедиться, что обе политики работают корректно, выполните команды на соответствующих роутерах. Ниже приведены ожидаемые результаты:
1. Проверка Local Preference (исходящий трафик) на R1:

R1# show ip bgp

Ожидаемый результат:

Network Next Hop Metric LocPrf Weight Path *> 4.4.4.4/32 10.0.0.10 0 150 0 65004 i *> 2.2.2.2/32 10.0.0.2 0 0 65002 i

Пояснение: У маршрута до 4.4.4.4/32 должен быть LocPrf = 150, а у 2.2.2.2/32 — стандартное значение 100. Теперь R1 будет отправлять трафик через R4.
2. Проверка AS_PATH Prepending (входящий трафик) на R2:

R2# show ip bgp

Ожидаемый результат:

Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.0.0.1 0 0 65001 65001 65001 i *> 3.3.3.3/32 10.0.0.1 0 65001 65001 65001 i

Пояснение: AS_PATH для маршрутов до 1.1.1.1/32 и 3.3.3.3/32 теперь выглядит как [65001, 65001, 65001] вместо [65001]. Это значит, что R2 видит удлинённый путь.
4. Проверка таблицы маршрутизации R3 (что маршрут до внешней сети установлен):

R3# show ip route bgp

Ожидаемый результат:

B 2.2.2.2 [200/0] via 1.1.1.1, 00:15:13

Пояснение: R3 знает, как добраться до сети 2.2.2.2 через R1.
5. Флаг RIB-failure (r):
Если на R1 или R3 в show ip bgp для маршрута до Loopback-адреса соседа стоит флаг r — это не ошибка. Это значит, что в таблице маршрутизации уже есть лучший маршрут (от OSPF). BGP при этом считается изученным.
7. Возможные проблемы и их решение
Проблема
Вероятная причина
Решение
На R1 нет маршрута до 4.4.4.4/32.
На R4 забыли настроить network 4.4.4.4 mask 255.255.255.255 или Loopback-интерфейс находится в состоянии shutdown.
Проверьте show ip route 4.4.4.4 на R4. Добавьте network и поднимите интерфейс (no shutdown).
После настройки Local Preference маршрут до 4.4.4.4 не имеет LocPrf 150.
Route-Map не применён к соседу R4 или не сброшена сессия.
Проверьте neighbor 10.0.0.10 route-map SET_PREF_R4 in. Выполните clear ip bgp 10.0.0.10.
На R2 не видно удлинённого AS_PATH.
Route-Map не применён к соседу R2 в направлении out.
Проверьте neighbor 10.0.0.2 route-map PREPEND_TO_R2 out. Выполните clear ip bgp 10.0.0.2.
BGP-сессия с R4 не устанавливается (Idle/Active).
Нет IP-связности между R1 и R4 или не совпадают номера AS.
Проверьте ping 10.0.0.10 с R1. Убедитесь, что на R1 указан remote-as 65004, а на R4 — remote-as 65001.
На R3 нет маршрута до внешней сети (2.2.2.2).
На R1 не настроен next-hop-self для iBGP-соседа R3.
На R1 добавьте neighbor 3.3.3.3 next-hop-self и выполните clear ip bgp 3.3.3.3.
Маршрут до 4.4.4.4 есть в BGP-таблице R1, но не в таблице маршрутизации R1.
Флаг r (RIB-failure) из-за отсутствия маршрута до Next-Hop (10.0.0.10).
Убедитесь, что физический интерфейс с R4 поднят (no shutdown) и IP-адрес настроен корректно.
8. Итог лабораторной работы:
1. Вы научились управлять исходящим трафиком с помощью Local Preference, указав предпочтительного провайдера (R4).
2. Вы научились управлять входящим трафиком с помощью AS_PATH Prepending, сделав маршрут через R2 менее привлекательным для внешнего мира.
3. Вы закрепили понимание разницы между атрибутами, которые передаются внутри AS (iBGP) и теми, которые видны только снаружи (eBGP).
9. Контрольные вопросы (с ответами для самопроверки)
Вопрос
Ответ
1. Какое значение Local Preference присваивается маршрутам по умолчанию?
По умолчанию LocPrf = 100.
2. Почему при настройке Local Preference мы использовали ключевое слово in, а при настройке Prepending — out?
Local Preference применяется к входящим маршрутам (мы получаем их от провайдера и назначаем приоритет).
Prepending применяется к исходящим маршрутам (мы изменяем их перед отправкой провайдеру).
3. Увидит ли R3 (внутренний роутер) изменённый AS_PATH, который мы применили к R2? Почему?
Нет, не увидит. Политика out применяется только к маршрутам, отправляемым конкретному внешнему соседу (R2). Внутри AS (по iBGP) маршруты передаются без изменений.
10. Расширенные ответы
Вопрос:
Почему при настройке Local Preference мы использовали ключевое слово in ?
Короткий ответ:
Local Preference — это внутренний атрибут BGP. Он назначается маршруту в момент его получения от внешнего соседа (eBGP) и затем передается внутри вашей AS (по iBGP). Поэтому мы применяем политику к входящим маршрутам ( in ).
Развернутое объяснение (для понимания)
Чтобы понять, почему используется  in , нужно разобраться в направлении движения маршрута и где живет атрибут:
1. Маршрут приходит от провайдера (R4):
  • R4 отправляет R1 объявление о сети 4.4.4.4/32.
  • Для R1 этот маршрут — входящий (он получает его от соседа).
2. Мы хотим повлиять на этот маршрут:
  • Чтобы R1 понял, что этот маршрут предпочтительнее других, мы должны изменить его атрибуты.
  • Это можно сделать только в момент получения маршрута, пока он еще "сырой". Если мы попытаемся изменить его после того, как он уже попал в BGP-таблицу, это будет поздно (хотя есть механизмы, но это сложнее).
3. Local Preference — это "внутренний ярлык":
  • LocPrf не передается за пределы AS. Он имеет смысл только внутри вашей сети.
  • Когда R1 получает маршрут от R4, он назначает ему LocPrf и запоминает его.
  • Затем R1 передает этот маршрут с LocPrf всем своим iBGP-соседям (например, R3).
❌ Почему нельзя использовать  out  для Local Preference?
Если бы вы применили политику с  out  для соседа R4:

R1(config-router)# neighbor 10.0.0.10 route-map SET_PREF_R4 out

Это означало бы: "R1, когда ты будешь отправлять маршруты своему соседу R4, измени их".
Но R4 — внешний провайдер, которому вообще не должно быть дела до вашего Local Preference (он его игнорирует). Более того, LocPrf не передается по eBGP, поэтому эта политика просто не сработает.
Аналогия для запоминания
Представьте, что вы — таможенник на границе (R1).
  • К вам приезжают фуры с товарами (маршрутами) от двух поставщиков (R2 и R4).
  • Вы решаете, что товары от поставщика R4 должны проходить через границу быстрее (высокий LocPrf).
  • Вы наклеиваете на фуры от R4 желтую наклейку (LocPrf = 150), а на фуры от R2 — зеленую (LocPrf = 100).
  • Это можно сделать только когда фура въезжает ( in ). Вы не можете наклеить наклейку, когда фура уже уехала вглубь страны.
Визуализация процесса
Визуализация процесса Local Preference
Итог (Запомните!)
Ключевое слово
Когда применяется
Для чего
 in 
К маршрутам, полученным от соседа.
Назначаем атрибуты (LocPrf, Weight, MED) в момент получения.
out 
К маршрутам, отправляемым соседу.
Изменяем атрибуты (AS_PATH Prepending, MED) перед отправкой.
Local Preference назначается на входе ( in ), потому что это внутренний атрибут, который должен быть присвоен маршруту до того, как он попадет в вашу BGP-таблицу и будет передан другим маршрутизаторам внутри AS.
Вопрос:
Почему при настройке AS_PATH Prepending мы использовали ключевое слово out ?
Короткий ответ:
AS_PATH Prepending — это атрибут, который изменяет маршруты перед отправкой их внешнему соседу (провайдеру). Мы "портим" маршрут на выходе ( out ), чтобы внешний мир увидел его искусственно удлинённым и выбрал альтернативный путь.
Развернутое объяснение (для понимания)
Чтобы понять, почему используется  out , нужно разобраться в направлении движения маршрута и где применяется изменение:
1. Маршрут готовится к отправке провайдеру (R2):
  • R1 собирается анонсировать свои сети (1.1.1.1/32 и 3.3.3.3/32) провайдеру R2.
  • Для R1 эти маршруты — исходящие (он отправляет их соседу).
2. Мы хотим повлиять на то, как провайдер увидит этот маршрут:
  • Чтобы R2 (и другие внешние сети) считали этот маршрут менее привлекательным, мы должны искусственно удлинить AS_PATH.
  • Это можно сделать только перед отправкой маршрута, пока он еще "в пути" к соседу. Если мы изменим его после отправки, это уже не имеет смысла.
3. AS_PATH Prepending — это "внешний" инструмент:
  • Prepending не влияет на маршруты внутри вашей AS. Он работает только для внешних соседей (eBGP).
  • Когда R1 получает маршрут от R3 по iBGP, он видит оригинальный AS_PATH ( [65001] ).
  • Только перед отправкой R2 R1 добавляет лишние номера AS ( [65001, 65001, 65001] ).
❌ Почему нельзя использовать  in  для AS_PATH Prepending?
Если бы вы применили политику с  in  для соседа R2:

R1(config-router)# neighbor 10.0.0.2 route-map PREPEND_TO_R2 in

Это означало бы: "R1, когда ты будешь получать маршруты от R2, измени их".
Но AS_PATH Prepending применяется к маршрутам, которые вы отправляете, а не к тем, которые получаете. Вы не можете "испортить" маршрут, который вам прислал провайдер, потому что вы не контролируете его AS_PATH. Ваша задача — испортить свой маршрут перед отправкой.
Аналогия для запоминания
Представьте, что вы — отправитель посылок (R1).
  • Вы отправляете посылки (маршруты) двум курьерским службам (R2 и R4).
  • Вы хотите, чтобы клиенты (внешний мир) реже заказывали доставку через службу R2.
  • Чтобы это сделать, вы наклеиваете на посылки для R2 лишние наклейки с адресом (удлиняете путь).
  • Это можно сделать только когда вы отдаете посылку курьеру ( out). Вы не можете наклеить наклейки на посылку, когда она уже уехала или когда вы получаете посылку от кого-то.
Визуализация процесса
Визуализация процесса AS_PATH Prepending
Почему Prepending не виден внутри AS (на R3)?
Это ключевой момент, который вы уже правильно отметили в лабораторной работе. Вот почему так происходит:
  1. R1 получает от R3 маршрут с AS_PATH = [65001] (оригинал).
  2. R1 применяет Prepending только для соседа R2 (направление  out ).
  3. R1 хранит в своей BGP-таблице оригинальный маршрут (AS_PATH = [65001]).
  4. Когда R1 передает этот маршрут другим iBGP-соседям (например, обратно R3), он передает оригинал, а не измененную версию.
Поэтому R3 никогда не увидит Prepending. Это внешняя политика, которая применяется только к конкретному eBGP-соседу.
Итог (Запомните!)
Ключевое слово
Когда применяется
Для чего
 in 
К маршрутам, полученным от соседа.
Назначаем атрибуты (LocPrf, Weight, MED) в момент получения.
out 
К маршрутам, отправляемым соседу.
Изменяем атрибуты (AS_PATH Prepending, MED) перед отправкой.
AS_PATH Prepending применяется на выходе ( out ), потому что это внешний атрибут, который должен быть изменен до того, как маршрут покинет вашу AS. Он не передается по iBGP и влияет только на выбор пути внешними соседями.
Сравнительная таблица (для быстрого повторения)
Атрибут
Направление
Почему
Local Preference
  in 
Назначается маршрутам при получении от eBGP-соседа. Используется внутри AS.
AS_PATH Prepending
out 
Изменяет маршруты перед отправкой eBGP-соседу. Влияет на внешний мир.

Приветствуем всех любителей ретро-игровой индустрии на канале RetraR
Сувенирная и брендированная продукция с персонажами из любимых игр.
RetraR — Компьютерные игры для Nintendo Game Boy
RetraR - Computer games for Nintendo Game Boy 🌌🛸👽👾☄️🤖
RetraR - 任天堂ゲームボーイ用コンピュータゲーム 🎮🕹️👾

RetraR в VK
Канал - RetraR в Telegram
Канал - RetraR в Telegram

Оформить заказ

Нажимая на кнопку, вы даете согласие на обработку персональных данных

Спасибо за заказ

Ваш заказ принят в обработку. 

Мы свяжемся с вами в ближайшее время.