Лабораторная работа 5. Динамическая маршрутизация

Цель

Вы настроите обмен маршрутами внутри одной автономной системы, выберете предпочтительный путь и проверите связь при отказе iBGP-сессии или канала.

Задачи

1. Настройте iBGP-сессии трёх маршрутизаторов в BIRD 2.
2. Сопоставьте маршруты BIRD, NEXT_HOP и таблицу маршрутизации Linux.
3. Проверьте ограничение передачи маршрутов между iBGP-соседями и настройте route reflector.
4. Выберите путь через LOCAL_PREF и проверьте резервный путь.
5. Найдите и исправьте несовпадающий номер автономной системы.

Рабочее окружение

Потребуются ЛБ3–4 и Ubuntu-ВМ. Укажите в отчёте, сколько времени заняла работа. На ВМ:

cd ~/labs-mag/containerlab/lab5
sudo containerlab deploy -t lab5.clab.yml
sudo containerlab inspect -t lab5.clab.yml

                 r2
           eth1 /  \ eth2
       eth2    /    \    eth2
 a ─ eth1:r1 ──────── r3:eth3 ─ b
          eth3      eth1

Все маршрутизаторы входят в AS 65005. Router ID: r1 — 1.1.1.1, r2 — 2.2.2.2, r3 — 3.3.3.3. Сессии строятся между непосредственно соединёнными адресами из таблицы. eth0 используется только для управления; маршрут через него удаляется при deploy. IP forwarding маршрутизаторов включён в топологии.

Образ labs-bird:local содержит пакет bird2. На маршрутизаторах BIRD уже запущен с базовым конфигурационным файлом, без BGP-соседей. Файлы configs/rN/bird.conf редактируйте на ВМ, адреса и диагностические команды выполняйте в контейнерах.

Задание 1. Адресация и проверка BIRD

1. На ВМ откройте клиента a:

sudo docker exec -it clab-labs5-a bash

В a:

ip address add 10.5.1.10/24 dev eth1
ip link set eth1 up
ip route add 10.5.3.0/24 via 10.5.1.1

Аналогично настройте b: адрес 10.5.3.10/24, маршрут в 10.5.1.0/24 через 10.5.3.1.

2. Откройте r1 командой sudo docker exec -it clab-labs5-r1 bash. В r1 назначьте адреса:

ip address add 10.5.1.1/24 dev eth1
ip address add 10.5.12.1/30 dev eth2
ip address add 10.5.13.1/30 dev eth3
ip link set eth1 up
ip link set eth2 up
ip link set eth3 up
bird --version
birdc show status
birdc show protocols
birdc show route

По адресной таблице настройте r2 и r3. На каждом маршрутизаторе проверьте ping до непосредственно подключённых соседей. На a проверьте ping -c 4 -W 2 10.5.3.10: до обмена маршрутами связи с LAN B быть не должно.

3. На ВМ откройте configs/r1/bird.conf. Прочитайте базовую конфигурацию:

• protocol device получает сведения об интерфейсах;
• protocol direct connected4 добавляет в BIRD подключённые учебные подсети;
• protocol kernel kernel4 передаёт выбранные BGP-маршруты в Linux;
• фильтр lab_lans разрешает только 10.5.1.0/24 и 10.5.3.0/24.

Почему наличие маршрута в BIRD ещё не доказывает его наличие в Linux? Почему сеть управления и транзитные /30 не должны анонсироваться этим фильтром?

Задание 2. Полная связность iBGP-сессий

1. На ВМ добавьте в конец configs/r1/bird.conf:

protocol bgp peer_r2 {
    local 10.5.12.1 as 65005;
    neighbor 10.5.12.2 as 65005;
    direct;
    check link yes;
    ipv4 {
        import filter lab_lans;
        export filter lab_lans;
    };
}

protocol bgp peer_r3 {
    local 10.5.13.1 as 65005;
    neighbor 10.5.13.2 as 65005;
    direct;
    check link yes;
    ipv4 {
        import filter lab_lans;
        export filter lab_lans;
    };
}

local as и neighbor as совпадают, поэтому это внутренняя сессия — iBGP. direct задаёт непосредственно подключённого соседа; check link yes связывает состояние сессии с состоянием учебного канала.

2. Аналогично добавьте по две сессии в файлы r2 и r3. Имена протоколов обозначают противоположный маршрутизатор:

Во всех четырёх блоках используйте AS 65005, direct, check link yes и такой же IPv4-канал с фильтром lab_lans. Router ID каждого узла сохраните.

3. После изменения файла в соответствующем контейнере сначала проверьте синтаксис, затем примените:

bird -p -c /opt/lab/bird.conf
birdc configure
birdc show protocols
birdc show protocols all

При ошибке bird -p конфигурацию не применяйте. Если сессия не устанавливается, проверьте адреса, AS, состояние интерфейсов и журнал tail -n 30 /var/log/bird.log. Дождитесь двух BGP-сессий Established на каждом узле. Это full mesh: каждая пара маршрутизаторов имеет собственную сессию.

4. На r1 сравните маршрут и атрибуты BGP с маршрутом ядра:

birdc show route 10.5.3.0/24 all
ip route show 10.5.3.0/24
ip route get 10.5.3.10

На r3 аналогично проверьте 10.5.1.0/24. На a выполните ping и tracepath -n 10.5.3.10, на b проверьте обратное направление. Найдите NEXT_HOP и AS_PATH: при передаче внутри одной AS собственный номер AS не добавляется в путь.

Задание 3. Ограничение iBGP и route reflector

1. На r1 временно отключите только прямую BGP-сессию с r3:

birdc disable peer_r3
birdc show protocols
birdc show route 10.5.3.0/24 all
ping -c 4 10.5.13.2

Сам канал r1–r3 остаётся исправным. После удаления маршрутов отключённой сессии повторите ping с a на b: ping не должен получать ответы. Проверьте, что r2 продолжает получать LAN B от r3, но не передаёт этот iBGP-маршрут другому обычному iBGP-соседу r1. Наличие треугольника физических каналов не снимает это ограничение.

2. На ВМ в configs/r2/bird.conf добавьте rr client; в оба блока protocol bgp, на уровне local, neighbor и direct. В IPv4-канале каждого из этих блоков добавьте:

        next hop self;

r2 становится route reflector, а r1 и r3 — его клиентами. next hop self задаёт адрес r2 на соответствующем канале вместо NEXT_HOP отражаемого маршрута. В этом стенде r2 пересылает и сами клиентские пакеты, поэтому такой NEXT_HOP должен быть доступен и иметь обратный путь.

3. На r2 проверьте файл, примените конфигурацию и посмотрите маршруты. На r1, оставив peer_r3 отключённым, повторите:

birdc show route 10.5.3.0/24 all
ip route get 10.5.3.10

Маршрут должен появиться от peer_r2 через 10.5.12.2. На a проверьте ping b и трассу через r2. На r3 проверьте обратный маршрут в LAN A. Сопоставьте ORIGINATOR_ID, CLUSTER_LIST и NEXT_HOP с ролью route reflector.

4. В r1 верните прямую сессию: birdc enable peer_r3. Дождитесь двух Established-сессий на каждом маршрутизаторе. На r1 и r3 посмотрите оба варианта маршрута командой birdc show route ПРЕФИКС all.

Задание 4. LOCAL_PREF и отказ канала

1. На ВМ в файле r1 замените import filter lab_lans; только в peer_r2 на:

        import filter {
            if net = 10.5.3.0/24 then {
                bgp_local_pref = 200;
                accept;
            }
            reject;
        };

В файле r3 сделайте то же для peer_r2, но для префикса 10.5.1.0/24. На обоих маршрутизаторах проверьте синтаксис и выполните birdc configure. Экспортный фильтр сохраните.

2. На r1 и r3 посмотрите все варианты маршрутов и их BGP.local_pref. У прямого пути LOCAL_PREF по умолчанию 100, у пути от r2 — 200. Проверьте ip route get и трассировку в обе стороны: выбранный путь должен проходить через r2. Число в скобках рядом с маршрутом BIRD — preference протокола; его не путайте с атрибутом BGP.local_pref.

3. На a запустите ping -D -i 0.2 10.5.3.10. На ВМ отключите только учебный канал r1–r2:

sudo docker exec clab-labs5-r1 ip link set eth2 down

На r1 и r3 посмотрите состояние сессий, выбранные маршруты и NEXT_HOP. После отзыва пути через r2 связь должна перейти на прямой канал r1–r3. Измерьте потерю пакетов и время переключения; на разных компьютерах время может различаться.

4. На ВМ восстановите канал:

sudo docker exec clab-labs5-r1 ip link set eth2 up

Дождитесь Established и возврата предпочтительного пути через r2. Проверьте обратное направление, а не только один ping.

Задание 5. Ошибка AS и захват пакетов

1. В r1 начните захват:

tcpdump -i eth2 -w /tmp/lab5.pcap 'tcp port 179'

2. На ВМ в configs/r1/bird.conf временно замените neighbor 10.5.12.2 as 65005; на neighbor 10.5.12.2 as 65006;. Локальный AS и конфигурацию r2 не меняйте. Проверьте синтаксис и примените изменение в r1.

Сессия r1–r2 не должна установиться: заявленный соседом AS не совпадает с ожидаемым. Найдите сообщение об ошибке в birdc show protocols all peer_r2, журнале и BGP NOTIFICATION в PCAP. Клиенты могут сохранить связь по прямой сессии r1–r3: это не подтверждает исправность r1–r2.

3. Верните ожидаемый AS 65005, проверьте файл, примените конфигурацию. Дождитесь Established, остановите захват. В Wireshark найдите TCP-соединение, BGP OPEN, KEEPALIVE и UPDATE с клиентским префиксом. Если маршрут уже передан до начала нужного фрагмента захвата, выполните на r1 birdc restart peer_r2 и запишите повторный обмен. Объясните назначение каждого типа сообщения.

Самостоятельное задание и отчёт

Измените LOCAL_PREF пути от r2 на 50 на r1 и r3. До применения запишите, какой маршрут должен стать лучшим и почему. Проверьте атрибуты и путь пакета, затем верните 200 для итоговой проверки.

Приложите схему, файлы BIRD, состояние сессий, маршруты full mesh и route reflector, проверку отказа связи без прямой сессии, изменение NEXT_HOP и LOCAL_PREF, измерения отказа канала и PCAP.

1. Чем iBGP отличается от eBGP и как BIRD определяет тип сессии?
2. Почему обычный iBGP-сосед не передаёт полученный iBGP-маршрут другому такому соседу?
3. Для чего нужны full mesh, route reflector, ORIGINATOR_ID и CLUSTER_LIST?
4. Чем NEXT_HOP отличается от адреса соседа, передавшего маршрут?
5. Почему BGP-сессия Established ещё не доказывает передачу клиентских пакетов?

Сохранение и завершение

Файлы bird.conf уже находятся на ВМ. В configs/*/startup.sh сохраните адреса интерфейсов и клиентские маршруты. На маршрутизаторах вставьте команды адресации после удаления management-маршрута и перед запуском BIRD. Статические маршруты к удалённым клиентским LAN на r1/r2/r3 не добавляйте: их должен установить BIRD. На r2 оставьте route reflector, на r1/r3 — LOCAL_PREF 200 от r2.

На ВМ создайте ~/reports/lab5 и скопируйте PCAP через sudo docker cp clab-labs5-r1:/tmp/lab5.pcap ~/reports/lab5/. Сохраните конфигурации и вывод диагностики в отчёт. Пересоздайте стенд, дождитесь Established и выполните проверку:

sudo containerlab destroy -t lab5.clab.yml --cleanup
sudo containerlab deploy -t lab5.clab.yml
sudo bash verify.sh
sudo containerlab destroy -t lab5.clab.yml --cleanup

Для полного повторения верните базовые bird.conf без BGP-соседей и уберите свою адресацию из startup.sh. Справочник команд и параметров: руководство BIRD 2.