Лабораторная работа №3: Управление входящим трафиком (MED)

Создана 28.07.2026
Отредактирована 31.07.2026

Цель работы: Научиться управлять входящим трафиком с помощью атрибута MED (Multi-Exit Discriminator), когда у вас есть два физических подключения к одному и тому же провайдеру.

1. Топология и сценарий

Представьте, что ваш провайдер (R2) подведен к вам (R1) двумя разными линками для надежности. Мы хотим сказать провайдеру: "Заходи ко мне в основном через Линк 1 (он быстрый), а Линк 2 используй только как резервный (на случай, если Линк 1 упадет)".

Рис. 1.Топология сети

Примечание:

На R1 порт Eth1/1 уже занят соединением с R3 (внутренним роутером) из предыдущих лабораторных работ. Поэтому для резервного линка мы используем Eth1/3.

На R2 для резервного линка используем Eth1/1 (так как у R2 нет других внутренних соседей).

2. Шаг 1: Базовая настройка интерфейсов и BGP

Настройка R1:

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

R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.0.2 description ISP_Link1_AS65002
R1(config-router)# neighbor 10.0.0.14 remote-as 65002
R1(config-router)# neighbor 10.0.0.14 description ISP_Link2_AS65002

Настройка R2:

R2(config)# interface Ethernet 1/1
R2(config-if)# ip address 10.0.0.14 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# exit

R2(config)# router bgp 65002
R2(config-router)# neighbor 10.0.0.1 description Client_Link1_65001
R2(config-router)# neighbor 10.0.0.13 remote-as 65001
R2(config-router)# neighbor 10.0.0.13 description Client_Link2_65001

3. Шаг 2: Анализ текущей ситуации (без MED)

На R2 (провайдер) посмотрите, как он видит маршрут до сети 1.1.1.1/32 :

R2# show ip bgp 1.1.1.1

Скорее всего, вы увидите два пути с одинаковыми атрибутами (оба с одинаковой метрикой 0).
BGP на R2 выберет лучший путь по Router ID (самый младший IP-адрес соседа) — это случайный выбор. Мы хотим управлять этим выбором.

4. Шаг 3: Управление входящим трафиком с помощью MED

Задача: Сделать так, чтобы R2 (провайдер) всегда выбирал Линк 1 (10.0.0.1) для входящего трафика.

Теория:

MED — это метрика, которую мы (клиент) отправляем провайдеру.

Правило: Чем меньше значение MED, тем предпочтительнее маршрут.

MED передается только между соседними AS (не идет дальше в Интернет).

Решение:

Мы создадим политику на R1, которая будет устанавливать разные метрики (MED) для маршрутов, отправляемых по двум линкам:

Линк 1 (Основной): Отправляем с MED = 10 (маленькое число — хорошо).

Линк 2 (Резервный): Отправляем с MED = 100 (большое число — хуже).

Поскольку провайдер увидит, что через Линк 1 метрика меньше, он выберет его.

Команды для настройки:

1. Создаем Route-Map для Линка 1 (10.0.0.2):

R1(config)# route-map SET_MED_LINK1 permit 10
R1(config-route-map)# set metric 10
R1(config-route-map)# exit

2. Создаем Route-Map для Линка 2 (10.0.0.14):

R1(config)# route-map SET_MED_LINK2 permit 10
R1(config-route-map)# set metric 100
R1(config-route-map)# exit

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

R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.0.2 route-map SET_MED_LINK1 out
R1(config-router)# neighbor 10.0.0.14 route-map SET_MED_LINK2 out
R1(config-router)# end

4. Перезапускаем сессии:

R1# clear ip bgp 10.0.0.2 R1# clear ip bgp 10.0.0.14

5. Сохраняем настройки:

R1# copy running-config startup-config

5. Шаг 4: Проверка результата (Критерии успеха)

Теперь посмотрите на R2 (провайдер):

R2# show ip bgp 1.1.1.1

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

BGP routing table entry for 1.1.1.1/32, version 17 Paths: (2 available, best #2, table default) Advertised to update-groups: 1 Refresh Epoch 1 65001 10.0.0.13 from 10.0.0.13 (1.1.1.1) Origin IGP, metric 100, localpref 100, valid, external rx pathid: 0, tx pathid: 0 Refresh Epoch 1 65001 10.0.0.1 from 10.0.0.1 (1.1.1.1) Origin IGP, metric 10, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0

Пояснение:

Вы видите, что маршрут через 10.0.0.1 (Линк 1) имеет metric 10 и помечен как best.

Маршрут через 10.0.0.13 (Линк 2) имеет metric 100 .

R2 выбрал Линк 1, потому что MED = 10 < 100.

6. Шаг 5: Проверка резервирования

Теперь самое интересное: убедимся, что если Линк 1 упадет, провайдер переключится на Линк 2.

Выключите интерфейс на R1 (или на R2) — shutdown для Линка 1.

На R2 снова посмотрите таблицу BGP:

R2# show ip bgp 1.1.1.1

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

Маршрут через Линк 1 исчезнет.

Маршрут через Линк 2 (с MED = 100) станет best автоматически.

BGP routing table entry for 1.1.1.1/32, version 18 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 65001 10.0.0.13 from 10.0.0.13 (1.1.1.1) Origin IGP, metric 100, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0

Обратите внимание на то, что переключение на другой линк произошло не мгновенно, так как стандартные значения: Keepalive = 60 секунд, Hold Time = 180 секунд, что дает до 3-х минут на обнаружение проблемы. В конце лабораторной работы мы рассмотрим визуализацию процесса обнаружения сбоя по таймерам Hold Time, и как уменьшить время переключения.

7. Возможные проблемы и их решение

Проблема	Вероятная причина	Решение
На R2 не видно MED (стоит 0).	Route-Map не применён к соседу на R1.	Проверьте neighbor ... route-map ... out .
После clear ip bgp MED не изменился.	Не сброшена сессия с нужным соседом.	Убедитесь, что вы ввели clear ip bgp [IP-адрес] .
R2 выбирает Линк 2, даже если MED на Линке 1 меньше.	На R2 настроена другая политика (например, Local Preference).	Проверьте, нет ли других политик на R2.
R2 не видит маршруты от R1.	Не настроен network 1.1.1.1 mask 255.255.255.255 на R1.	Добавьте network и перезапустите сессии.
После выключения Линка 1 трафик не переключается на Линк 2	На R2 не настроен neighbor 10.0.0.5 remote-as 65001	Проверьте настройки BGP на R2.

8. Итог лабораторной работы

1. Вы научились управлять входящим трафиком с помощью MED, когда у вас несколько линков к одному провайдеру.

2. Вы закрепили понимание, что меньше MED = лучше, и что MED применяется на исходящие маршруты ( out ).

3. Вы проверили, что при падении основного линка трафик автоматически переключается на резервный.

9. Контрольные вопросы

Вопрос	Ответ
1. Какое значение MED присваивается маршрутам по умолчанию?	По умолчанию MED = 0 (или не установлен).
2. Почему при настройке MED мы использовали ключевое слово out , а не in ?	MED — это метрика, которую мы отправляем провайдеру, чтобы повлиять на то, как он выбирает маршрут к нам. Поэтому мы изменяем исходящие маршруты ( out ).
3. Может ли MED влиять на выбор маршрута внутри нашей AS (на R3)? Почему?	Нет. MED передается только между соседними AS (eBGP). Внутри AS (по iBGP) этот атрибут не передается.

10. Визуализация процесса: Обнаружение сбоя по таймерам (Hold Time)

Сценарий: Линк 1 (Eth1/0 на R1) падает

Пояснение к схеме

Этап	Что происходит	Время (по умолчанию)
1. Падение линка	Физический обрыв или shutdown на R1 (Линк 1). R1 не может отправить Keepalive R2.	0 сек
2. Ожидание Keepalive	R2 ждёт очередное Keepalive-сообщение от R1 (по умолчанию раз в 60 секунд).	0–60 сек
3. Hold Time истекает	R2 не получает Keepalive в течение всего Hold Time (по умолчанию 180 секунд).	60–180 сек
4. Закрытие сессии	R2 отправляет R1 NOTIFICATION (Hold Timer Expired) и закрывает BGP-сессию.	180 сек
5. Переключение	R2 удаляет маршруты через Линк 1 из таблицы и выбирает Линк 2 как лучший.	180 сек

Почему это важно для лабораторной работы?

Вы увидели в GNS3, что после shutdown интерфейса трафик переключается не мгновенно, а с задержкой.

Теперь вы знаете, почему: BGP не опрашивает линк постоянно (как OSPF с Hello-пакетами), а полагается на таймеры Keepalive и Hold Time.

Это сделано для стабильности: BGP не должен "дергаться" при каждом микроотключении, чтобы не флапить маршруты по всему Интернету.

Как ускорить переключение (Дополнительно)

Если вы хотите сократить время переключения в лабораторной работе (и в реальной жизни), можно настроить таймеры вручную:

На R1 и R2 (для соседа):

R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.0.2 timers 10 30
R1(config-router)# neighbor 10.0.0.14 timers 10 30
R1(config-router)# end

Перезапускаем сессии

R1# clear ip bgp 10.0.0.2 R1# clear ip bgp 10.0.0.14

R2(config)# router bgp 65002
R2(config-router)# neighbor 10.0.0.1 timers 10 30
R2(config-router)# neighbor 10.0.0.13 timers 10 30
R2(config-router)# end

Перезапускаем сессии

R2# clear ip bgp 10.0.0.1 R2# clear ip bgp 10.0.0.13

Быстрый способ убедиться, что изменения применились, например для соседа 10.0.0.2 — используйте команду ниже:

R1# show ip bgp neighbors 10.0.0.2

Перезапускаем сессии

Это установит:

Keepalive = 10 секунд

Hold Time = 30 секунд

Результат: R2 обнаружит сбой через 30 секунд вместо 180.

Более продвинутый способ: Использовать BFD (Bidirectional Forwarding Detection), который обнаруживает сбой за миллисекунды, но это уже отдельная тема.

Дополнительная визуализация: Сравнение времени переключения

Таблица: Время переключения при разных настройках таймеров

Настройка таймеров	Время переключения
По умолчанию - (Keepalive 60, Hold 180)	180 секунд
Быстрые таймеры - (Keepalive 10, Hold 30)	30 секунд
BFD (рекомендуется в продакшене)	60-300 мс