Сети Для Самых Маленьких
  • Сети для самых маленьких
  • 0. Планирование
    • 0. Документация сети
    • 1. Схемы сети
    • 2. IP-план
    • 3. Список VLAN
    • 4. План подключения оборудования по портам
    • 5. Заключение
  • 1. Подключение к оборудованию cisco
    • 0. Среда
    • 1. Способы подключения
    • 2. Управление по консоли
    • 3. Первичная настройка
    • 4. Настройка доступа
    • 5. Сброс пароля
  • 2. Коммутация
    • Теория
      • СКС, ЛВС, LAN
      • IP-адресация
      • Широковещательный домен
      • OSI
      • Путь пакета
      • VLAN
      • FAQ
    • Практика
      • Порты доступа (access)
      • Транковые порты (trunk)
      • Сеть управления и первичная настройка
      • Резюме
  • 3. Статическая маршрутизация
    • InterVlan Routing
    • Планирование расширения
    • Принципы маршрутизации
    • Настройка
    • Дополнительно
    • Материалы выпуска
  • 4. STP
    • Широковещательный шторм
    • STP
    • RSTP
    • MSTP
    • Агрегация каналов
    • Port security
    • Практика
    • Материалы выпуска
  • 5. ACL и NAT
    • Access Control List
      • Практика
    • NAT
      • Практика
    • Материалы выпуска
    • Бонусы
    • Спасибы
  • 6. Динамическая маршрутизация
    • Теория протоколов динамической маршрутизации
    • OSPF
      • Теория
      • Теория-2
      • Практика OSPF
      • Задача 1
      • Практика. Продолжение
      • Задача 2
      • Задача 3
    • EIGRP
      • Теория
      • Практика
      • Задача 4
    • Настройка передачи маршрутов между различными протоколами
    • Задача 5
    • Маршрут по умолчанию
    • Задача 6
    • Полезные команды для траблшутинга
    • Задача 7
    • Материалы
    • Полезные ссылки
  • 7. VPN
    • Введение в VPN
    • GRE
      • Абстрактная топология
      • Настройка
      • Механизм работы протокола
      • Итого
    • IPSec
      • Теория
        • Security Association
        • Трансформ-сет
      • Режимы работы IPSec
        • Туннельный режим работы IPSec
        • Практика
          • Настройка на локальной стороне
          • Настройка на обратной стороне
          • Настройка. Завершение
        • Задача 1
        • Теория
        • Задача 2
        • Транспортный режим работы IPSec
        • Задача 3
    • GRE over IPSec
      • Практика
      • Теория
      • Задача 4
      • Задача 5
    • IPSec VTI
    • DMVPN
      • Теория и практика DMVPN
      • OSPF
        • Практика
        • Теория
      • IPSec
      • NAT-Traversal
      • Задача 6
    • TShoot IPSec
    • MTU
    • Материалы выпуска
    • Полезные ссылки
  • 8. BGP и IP SLA
    • Автономные системы
    • PI и PA адреса
    • BGP
      • Теория
      • Установление BGP-сессии и процедура обмена маршрутами
      • Настройка BGP и практика
        • Настройка BGP и практика
        • Задача 1
        • Full View и Default Route
        • Задача 2
        • Looking Glass и другие инструменты
        • Control Plane и Data Plane
        • Выбор маршрута
        • Задача 3
      • Управление маршрутами
        • AS-Path ACL
        • Prefix List
        • Route Map
        • Задача 4
      • Балансировка и распределение нагрузки
        • Балансировка нагрузки
        • Задача 5
        • Распределение нагрузки
          • Исходящий
          • Задача 6
          • Входящий
        • AS-Path Prepend
        • MED
        • Анонс разных префиксов через разных ISP
        • BGP Community
        • Задача 7
        • Общая таблица по видам балансировки и распределения нагрузки
    • PBR
      • Теория
      • PBR
      • Практика
      • Задача 8
    • IP SLA
      • Настройка
      • Задача 9
      • Задача 10
    • Полезные ссылки
  • 8.1 IBGP
    • IBGP
    • Различия IBGP и EBGP
    • Проблема Эн квадрат
      • Route Reflector
        • Правила работы RR
        • Практика RR
          • Проблема резервирования
      • Конфедерации
    • Атрибуты BGP
      • Хорошо известные обязательные (Well-known Mandatory)
      • Хорошо известные необязательные (Well-known Discretionary)
      • Опциональные передаваемые/транзитивные (Optional Transitive)
      • Опциональные непередаваемые/нетранзитивные (Optional Non-transitive)
      • Community
        • Теория Community
        • Задача 7
        • Практика Community
        • Задача 8
        • Задача 9
      • Задача 6
    • Материалы выпуска
    • Задача 1
    • Задача 2
    • Практика
      • EBGP
      • iBGP
      • iBGP
      • Задача 3
      • Настройка внутренней маршрутизации. OSPF
      • Настраиваем BGP
      • Задача 4
      • Что мы можем улучшить?
      • Задача 5
      • Задача 6
      • Задача 7
      • Задача 8
      • Задача 9
    • Послесловие
  • 9. Multicast
    • Общее понимание Multicast
      • Пример I
      • Пример II
    • IGMP
      • Теория IGMP
      • Querier
      • Ещё пара слов о других версиях IGMP
      • Повторим ещё раз
      • И ещё раз
    • PIM
      • PIM Dense Mode
      • PIM Sparse Mode
      • Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной
      • Разбор полётов
        • RP
        • Бритва Оккама или отключение ненужных ветвей
        • SPT Switchover — переключение RPT-SPT
        • Задача 1
        • Задача 2
      • DR, Assert, Forwarder
      • Выбор RP
      • Завершение
    • SSM
    • BIDIR PIM
    • Мультикаст на канальном уровне
      • Мультикастовые MAC-адреса
      • IGMP Snooping
      • Задача 3
      • IGMP Snooping Proxy
      • Multicast VLAN Replication
    • Заключение
  • 10. Базовый MPLS
    • Что не так с IP?
    • Заголовок MPLS
    • Пространство меток
    • Что такое MPLS
    • Передача трафика в сети MPLS
    • Терминология
    • Распространение меток
      • Методы распространение меток
        • DU против DoD
        • Ordered Control против Independent Control
        • Liberal Label Retention Mode против Conservative Label Retention Mode
        • PHP
      • Протоколы распространения меток
        • LDP
          • Практика
        • Применение чистого MPLS в связке с BGP
        • RSVP-TE
          • Практика
    • ВиО
    • Полезные ссылки
    • Спасибы
  • 11. MPLS L3VPN
    • VRF, VPN-Instance, Routing Instance
      • VRF-Lite
    • MPLS L3VPN
      • Data Plane или передача пользовательских данных
      • Роль меток MPLS
        • Транспортная метка
        • Сервисная метка
      • Терминология
      • Control Plane или передача служебной (маршрутной) информации
      • Протоколы маршрутизации
      • MBGP
        • Route Distinguisher
        • Route Target)
    • Практика
      • VRF-Lite
      • MPLS L3VPN
      • Взаимодействие между VPN
    • Трассировка в MPLS L3VPN
    • Доступ в Интернет
      • NAT на CE
        • Практика
        • Теория
        • Повторим шаги настройки
      • VRF Aware NAT
        • Практика
        • Теория
      • Common Services
    • ВиО
    • Полезные ссылки
  • 12. MPLS L2VPN
    • О технологиях L2VPN
    • VPWS
      • Data Plane
      • Control Plane
      • Практика
      • Теория
      • Виды VPWS
    • VPLS
      • Data Plane
      • Control Plane
      • VPLS Martini Mode (targeted LDP)
        • Практика
        • Теория
      • VPLS Kompella Mode (BGP)
        • Обнаружение соседей или Auto-Discovery
        • Передача префиксов
        • Распределение меток и механизм Label Block
        • Практика
        • Теория
      • Martini vs. Kompella
      • Иерархический VPLS (H-VPLS)
        • Практика H-VPLS
        • Теория
    • Проблемы VPLS
    • Полезные ссылки
    • Спасибы
  • 12.1. MPLS EVPN
    • Вспоминаем VPLS
    • Базовая часть технологии EVPN
    • Лаборатория для тестов и конфигурации
    • Маршруты EVPN
      • Маршрут типа 3 (Inclusive Multicast Ethernet Tag Route)
      • Маршрут типа 2 (MAC/IP Advertisement Route)
        • Изучение MAC-адресов
      • Маршрут типа 1 (Ethernet Auto-Discovery Route)
        • Автоматический поиск multihomed PE и ESI label
        • MAC Mass Withdrawal
        • Aliasing label
      • Маршрут типа 4 (Ethernet Segment Route)
        • Механизм выбора DF
    • L3-функционал в EVPN
      • IRB synchronisation
      • Маршрутизация между bridge-доменами
      • Выход в другие VRF и внешние сети
    • Зачем это всё-таки нужно?
    • Заключение
  • 12.2. EVPN Multihoming
    • Практический пример
    • Проблемы Multihoming-га.
    • Что такое DF и зачем он нужен?
    • Зачем нужен маршрут типа 1 per-ESI?
    • Зачем нам маршрут типа 1, сгенерированный per-EVI?
    • А нужен ли нам MC-LAG в EVPN?
    • Заключение
  • 13. MPLS Traffic Engineering
    • Предпосылки появления MPLS TE
    • Принципы работы MPLS Traffic Engineering
    • Способы направления трафика в TE-туннель
    • Способы управления туннелями
  • 14. Packet Life
    • 0. Коротко о судьбе и пути пакета
    • 1. Уровни и плоскости
      • Forwarding/Data Plane
      • Control Plane
      • Management Plane
      • Краткий итог
    • 2. История способов обработки трафика
      • Что с тобой не так, IP?!
      • О дивный новый мир
    • 3. Типов-чипов
      • CPU — Central Processing Unit
      • RAM — Random Access Memory
      • CAM — Content-Addressable Memory
      • TCAM — Ternary Content-Addressable Memory
      • ASIC — Application Specific Integrated Circuit
      • Programmable ASIC
      • FPGA — Field Programmable Gate Array
      • NP — Network Processor
    • 4. Аппаратная архитектура коммутирующего устройства
      • Общая шина
      • Управляющий модуль
      • Интерфейсный модуль или линейная карта
        • PIC — Physical Interface Card
        • FE — Forwarding Engine
        • QoS или TM — Traffic Management
        • SerDes — Serializer, Deserializer
        • Распределённая плоскость управления (Distributed Control Plane)
      • Фабрика коммутации
    • 5. Путешествие длиною в жизнь
      • Транзитные пакеты
      • Локальные пакеты
    • Заключение
    • Спасибы
  • 15. QoS
    • 0. Чем определяется QoS?
      • Потери
      • Задержки
      • Джиттер
      • Неупорядоченная доставка
      • Полоса пропускания
    • 1. Три модели обеспечения QoS
      • Best Effort (BE)
      • IntServ
      • DiffServ
    • 2. Механизмы DiffServ
    • 3. Классификация и маркировка
      • Behavior Aggregate
      • Interface-based
      • Multi-Field
      • Маркировка внутри устройства
      • Рекомендации IETF (категории трафика, классы сервиса и модели поведения)
      • Короткий итог по классификации
    • 4. Очереди
    • 5. Предотвращение перегрузок
      • Tail Drop и Head Drop
      • RED — Random Early Detection
      • WRED — Weighted Random Early Detection
    • 6. Управление перегрузками
      • FIFO — First In, First Out
      • PQ — Priority Queuing
      • FQ - Fair Queuing
      • RR — Round-Robin
      • Короткий итог про механизмы диспетчеризации
    • 7. Ограничение скорости
      • Traffic Policing
      • Traffic Shaping
      • Шейпинг против полисинга
      • Практика Полисинг и шейпинг
      • Механизмы Leaky Bucket и Token Bucket
        • Алгоритм Leaky bucket
        • Алгоритм Token Bucket
      • Короткий итог по ограничению скорости
    • 8. Аппаратная реализация QoS
    • Полезные ссылки
    • Спасибы
  • Инструкция для контрибьютеров
Powered by GitBook
On this page
  1. 12. MPLS L2VPN
  2. VPLS
  3. VPLS Kompella Mode (BGP)

Распределение меток и механизм Label Block

Помните фразу "Хочешь накормить человека один раз — дай ему рыбу. Хочешь накормить его на всю жизнь — дай ему удочку"? Для выделения меток в VPLS Kompella mode используется механизм блоков меток. Один PE другому не сообщает точное значение — он даёт ему информацию для её вычисления.

Я по себе я знаю, что пытаться понять что-то пока ты не знаешь, зачем оно нужно — путь к несварению и трата лишнего времени. В конце этой главы я расскажу, зачем нужна такая странная схема, а пока вы разбираетесь, просто поверьте мне и Кирити Компелле — нужна.

Есть мнение, что видео перед текстом помогает лучше разобраться.

Если не вдаваться в конфигурацию, то выглядит это так:

  1. В каждом VSI настраивается RD и RT — их функции ровно те же самые, что в L3VPN. На CSR1000V это происходит автоматически, не требуя ручной настройки.

    RD позволяет разделять информацию разных VSI при передаче.

    RT позволяет маршрутизатору-получателю определить, в какой VSI нужно эту информацию транслировать.

    RD и RT позже будут передаваться в сообщении BGP Update.

  2. В секции BGP настраивается новая адрес-фэмили L2VPN VPLS, внутри которой поднимается соседство со всеми PE.

    Вообще-то нужно создать полносвязную топологию соседства. Но мы же помним, что механизм Route-Reflector'ов позволяет обойти это требований, установив соседство только с одним RR (или несколькими в случае кластера RR)?

  3. Под каждый VSI PE-маршрутизатор выделяет блок из пространства меток. И вот тут-то и начинается интересное. В BGP Update от локального PE удалённому передаётся следующая информация:

    • RD

    • RT

    • Порядковый номер узла в VPLS-домене.

    • Блок меток MPLS

      • VE ID

      • VE Block Offset

      • VE Block Size

      • Label Base

Напомню, что VE — VPLS Edge — граница сети VPLS — PE-маршрутизатор на котором запущен VPLS.

Прежде чем я ударюсь во все тяжкие про формулы и значения, я считаю себя обязанным объяснить на пальцах в общем как это работает, потому что потратил кучу времени и нервов, чтобы разобраться.

Я искренне верю, что RFC является источником безусловной ясности, но порою в том же виде, в каком им является формула эквивалентности массы и энергии для Ньютона.

Когда на PE приходит L2VPN кадр со стороны MPLS сети, нужно точно знать, от какого он соседа — это нужно, чтобы изучить MAC-адрес, поэтому как и в случае с режимом Martini основная идея заключается в том, что PE каждому соседу в конкретном VSI должен сообщить уникальную метку, чтобы видеть, от кого пришёл кадр.

Пусть R1 за главного. 0. В Kompella mode R1 не передаёт метку в явном виде своим соседям R2 и R3. 1. Вместо этого он им сообщает из какого диапазона нужно метки выбирать, чтобы идентифицировать данный VC. 2. У каждого РЕ есть свой порядковый номер n в VPLS-домене. Зная свой номер и диапазон меток, соседи вычисляют исходящую сервисную метку: отсчитывают n-ую по счёту с начала. То есть R2 взял вторую (2), а R3 — третью (3). 3. R2 и R3 сообщают свои номера R1, и он тоже вычисляет, какая входящая сервисная метка будет от R2, какая от R3, отсчитывая от начала диапазона 2 и 3. 4. Аналогично свои собственные диапазоны определяют R2 и R3 и сообщают их друг другу и R1. И цикл вычислений повторяется. 5. В конце концов все будут знать и исходящие метки для данного VPLS и входящие.

Теперь вторая итерация: поглубже копнём, какой матан лежит под этой простой идеей.

VE ID настраивается вручную — это идентификатор PE-маршрутизатора в домене VPLS (его порядковый номер). Должен быть уникален в пределах одного VSI. LB — Label Base — это начало диапазона, первая метка, которая может быть использована. VBS — VE Block Size — это длина блока меток — или проще, минимальное количество меток в этом VSI. Для Cisco по умолчанию это 10. Для Juniper — 8 (может быть уменьшен до 2 или увеличен).

Вот как будет выглядеть набор меток: {LB, LB+1, .., LB+VBS-1}.

На этой анимации показан процесс распределения меток на PE1: Если PEX хочет отправлять трафик на PE1, он должен использовать соответствующую метку X.

То есть имеем строгое соответствие: узлу с VE ID (VBO+n) соответствует метка (LB+n).

Третья итерация — на реальном примере.

Возьмём клиента с десятью сайтами. VBS у нас стандартный — 10. VE-ID соответствуют номеру маршрутизатора: PE1 — 101, PE2-102,… PE 10 — 110. Рассмотрим как будут взаимодействовать PE1 и PE5.

1. PE1 выбирает в качестве Label Base 1000 — то есть 1000-1009 — это блок меток, из которого его соседи смогут взять себе по одной. 2. PE1 вычисляет VBO. VBO=ЦЕЛОЕ(101/10)*10=100. 3. PE1 передаёт собирает все данные в BGP Update всем своим соседям: LB: 1000, VBS:10, VBO:100, VE-ID:101. Ну и всякие RD, RT, которые нам сейчас не интересны. Сам PE1 пока никаких меток не считает — он ждёт Update от соседей. 4. BGP Update от PE1 достигает PE5. Его VE-ID: 105. И сейчас ему нужно вычислить исходящую метку для данного VSI (чей RT указан так же в BGP Update)в сторону PE1. 5. Первое, что делает PE5 — проверяет, а умещается ли он в блок, анонсированный PE1. Вот здесь и понадобится VBO. Должно выполниться неравенство VBO ≤ PE5 VE-ID ≤ VBO+VBS-1. И оно выполняется 100≤105≤109. Поясню. PE1 вычислил, что его ID в диапазоне 100-109 (со смещением 100 и длиной 10) — соответственно все узлы с VE ID из этого набора будут выбирать метку из первого блока. 6. Итак PE5 в пределах анонсируемого диапазона, поэтому он может идти дальше и вычислить свою исходящую метку по формуле (PE1 LB + PE5 VE-ID — VBO) = (1000 + 105 — 100) = 1005. Ещё раз вся эта арифметика, означает, что от LB нужно отсчитать столько меток, каким по счёту идёт VE-ID от VBO. Значит, PE5, чтобы отправить L2 кадр данного VSI на PE1 вставит в MPLS-заголовок VPN-метку 1005. PE1 пока не знает, про метку 1005 — ему предстоит её вычислить, как это сделал PE5. А для этого нужно узнать его VE ID. 7. Теперь PE5 тоже должен отправить BGP Update всем соседям (технически, не надо дожидаться 7 шага — такую последовательность я взял для примера. PE5 отправляет свой BGP Update как только всё было настроено).

  • а. Выбрал LB, например, 5000.

  • б. Вычислил VBO = RND(105/10)*10=100.

  • в. Скомпоновал BGP Update. LB: 5000, VBS:10, VBO:100, VE-ID: 105.

  • г. Отправил его всем PE.

8. Когда PE1 узнал VE-ID соседа (из BGP Update), он может посчитать входящую метку для данного соседа и VSI. И он делает то же самое:

  • а. Проверяет неравенство по полученным VBO И VBS: VBO ≤ PE1 VE-ID ≤ VBO+VBS. 100≤101≤109. Отлично.

  • б. Вычисляет входящую метку: (PE1 LB + PE5 VE-ID — VBO) = (1000 + 105 — 100) = 1005 — то же самое число, что посчитал и PE5 для исходящей метки. То есть когда PE1 получит кадр с меткой VPN 1005, он будет знать сразу и то, какому VPN он предназначен и от какого соседа пришёл, то есть как изучить его MAC, если необходимо.

9. Но это ещё не всё. PE1 должен теперь вычислить и исходящую метку к PE5. И все данные у него для этого имеются. (PE5 LB + PE1 VE-ID — VBO) = (5000 + 101 — 100) = 5001. То есть PE1 при отправке кадров в этот VSI к PE5 вставит в них VPN-метку 5001. 10. PE5 вычисляет входящую: (PE5 LB + PE1 VE-ID — VBO) = (5000 + 101 — 100) = 5001.

Вот это я называю взаимовыручкой!

Интересна судьба PE10, которая окажет своё влияние на жизни всех других PE. Дело в том, что он не укладывается в блок 100-109 со своим VE ID 110. Его VBO будет 110=ЦЕЛОЕ(110/10)*10. А в качестве LB он выбрал 10000. Когда PE10 пришлёт результаты своих калькуляций PE5, неравенство не выполнится: 110 ≤ 105 ≤ 119. В этом случае запускается процесс выделения нового блока. 1. PE5 выбирает новый LB 5030, VBS уже выбран PE10 — 10. 2. Имея уже данные от PE10,

  • А. PE5 вычисляет исходящую метку к PE10: (PE10 LB + PE5 VE-ID — PE5 VBO) = (10000 + 105 — 100) = 10005. Обратите внимание, что отнимается локальный VBO.

  • Б. Вычисляет входящую метку от PE10: (PE5 New LB + PE10 VE-ID — PE10 VBO) = (5030 + 110 — 110) = 5030. Используется новый LB и VBO PE10.

3. PE5 высылает PE10 новый BGP Update, анонсируя уже два префикса: первый — старый, а второй — LB: 5030, VE ID: 105, VBS:10, VBO:110. 4. VE-ID PE10 в этот раз входит в новый диапазон 110-119,

  • А. поэтому он может вычислить исходящую метку: (PE5 LB + PE10 VE-ID — PE10 VBO) = (5030 + 110 — 110) = 5030. То есть PE10 при отправке кадра этого VSI на PE5 должен вставить VPN-метку 5030.

  • Б. Может он вычислить и входящую от PE5: (PE10 LB + PE5 VE-ID — PE5 VBO) = (10000 + 105- 100) = 10005. Здесь он использует тот VBO, в который входит PE5, а не PE10.

5. Каждый PE должен будет выделить по второму блоку меток, чтобы общаться с PE10. Вычисления продолжаются.

И в этот момент должно стать жутко. Во-первых мы только что потеряли 10 меток на КАЖДОМ PE (9 не использовано из второго блока и одна метка из первого — которая для самого этого PE). Во-вторых, от того, как мы назначим VE-ID, зависит, насколько рационально будут использованы метки. В-третьих, мы должны своими собственными руками настроить VE-ID и VE-range! Вот этими вот руками, которыми мы MPLS поднимали в пару команд!

Должны быть очень веские доводы, почему протокол реализован именно так, а не по аналогии с LDP или MBGP для L3VPN.

Using a distinct BGP Update message to send a demultiplexor to each remote PE would require the originating PE to send N such messages for N remote PEs. The solution described in this document allows a PE to send a single (common) Update message that contains demultiplexors for all the remote PEs, instead of N individual messages. Doing this reduces the control plane load both on the originating PE as well as on the BGP Route Reflectors that may be involved in distributing this Update to other PEs.

Не очень понятно, какие там нагрузки на Control Plane.

Как это водится в СДСМ, дальше вы читаете эксклюзив. Причём на этот раз, вероятно, не только рунетовского уровня, но и вообще во всём Интернете я не нашёл адекватного пояснения, зачем эта система блоков была изобретена. Не смейтесь сильно, но я даже писал Компелле, когда ни один из окружающих меня CCIE не ответил на этот вопрос.

Всё это из-за столь желанной функции Auto-discovery (про которую уже было выше) и специфики L2, а именно изучения MAC-адресов. И всё будет понятнее в сравнении с L3VPN, где про назначения блока меток никто даже не думал.

Итак, как работает Auto-Discovery в L3VPN? Некоторый PE страждет рассказать всему миру о двух вещах — во-первых, о том, какие префиксы он знает, во-вторых о том, кому они предназначены. И он хочет рассказать об этом всем сразу без разбора — все, кто являются его MBGP соседями получат его Update, а по RT поймут, интересны ли им эти анонсы. На нет — и суда нет — отбросят. А если интересны, то в свою таблицу маршрутизации VPN занесут полученный префикс и его VPN-метку.

Всё то же самое верно и для L2VPN. За исключением одного: изучения MAC-адресов. BGP в L3VPN сообщает всем одну и ту же метку — ему совершенно без разницы, откуда потом придёт пакет с данными, главная его забота — передать его в правильный клиентский интерфейс. Но не таков VPLS. Чтобы в будущем отправлять данные конкретному соседу, нужно сначала изучить MAC-адреса клиента, подключенного к этому соседу. И сделать это можно только, если от разных соседей приходят кадры с разными метками. И здесь-то и кроется дьявол. В BGP Auto-Discovery происходит в тот же момент, что и анонс префикса. И, во-первых, совершенно не в духе BGP будет, если сначала отсылать пустой Update с целью поиска всех участников VPLS-домена, а потом отдельно то же самое, но с конкретными метками каждому из них. И даже, если вы приемлете «во-первых» (Фуфуфу), появляется, «во-вторых». Во-вторых, анонс конкретных меток найденным соседям. Хорошо, когда нет RR, и один PE может отправить другому Update адресно. Тогда каждый PE получит только своё сообщение и только свою метку. Но реальность такова, что RR стали её (реальности) частью и, имея соседство только с RR, PE шлёт Update ему, а тот рассылает всем своим клиентам. А если PE шлёт несколько Update'ов, то все они разлетятся по всем. Получается, что каждый его сосед получит не только свою метку, но и все остальные, которые ему даром не сдались. Просто представьте себе дамп в котором вы видите сотню Update'ов для левых устройств.

И вот тут механизм автоматического вычисления меток выходит на первый план, как весьма элегантное решение этой проблемы. Здесь стоит отдать должное гибкости мысли Кирити Компеллы.

Label blocks and label values are managed by the PEs. As sites get added and removed, labels are allocated and released. The easiest way to manage these is to use fixed-size label blocks rather than variable-size blocks, although the signaling described here supports either. If an implementation uses fixed-size blocks, then allocating a label for a new site may requiring allocating a new block; similarly, freeing a label may require freeing a block. If the implementation requires fixed-size blocks, there is probably a default block size, but the implementation SHOULD allow the administrator to choose a size. Larger label block sizes mean more potential «wasted» labels but less signaling overhead, a trade-off that the administrator might want to control.

PreviousПередача префиксовNextПрактика

Last updated 6 years ago

Вот на такой простой картинке посмотрим поподробнее:

В целом, схема простая: VE ID 100-109 взяты от балды для примера

Вот ещё пример для PE5:

Метки выделяются по порядку — первая из блока — соседу с наименьшим VE-ID. Вторая — второму по величине итд. То есть такая ситуация невозможна:

Однако если выделенного количества меток мало, то поможет параметр VBO — VE Block Offset — смещение блока. Он позволяет создать несколько блоков. И тем соседям, кому не хватило, метки распределяются по тому же принципу, но из нового блока, с новым LB. Необходимый VBO вычисляется по формуле: VBO = ЦЕЛОЕ(VE-ID/VBS)*VBS. Хочется заметить, что VBO — это не про смещение меток, это про диапазон, в который попадает порядковый номер VE. Если попал в первый диапазон — берётся первый блок меток, если во второй — то второй итд. Таким образом в случае использования нескольких блоков, набор меток будет выглядеть так же, как и прежде {LB, LB+1,… LB+VBS-1}, но LB при этом зависит от VBO. То есть у нас связка

К сожалению, довольно очевидный и в корне своём логичный механизм я могу описать только таким сложным языком. Если вы ещё не эволюционировали до понимания механизма Label Block, вернитесь к .

Скрупулёзное объяснение механизма Label Block от виновников: .

Знаете, что по этому поводу, говорит ?

И знаете, пока эта концепция блока меток не сформировалась в непротиворечивый набор синапсов в моём мозге, я с пренебрежением относился к ней. Она казалась мне топорной и устаревшей. Примерно, как . Но теперь я проникся идеей и даже несколько удивлён тому, что внятного объяснения нигде нет.

Замечу также, что ситуацию с потерянными метками несколько пересмотрели с выпуском (в котором, кстати, Компелла тоже принял непосредственное участие):

И более того, режим позволяет совместить достоинства обоих методов. Хотя и появляется вот этот самый двухшаговый механизм — сначала изучаем соседей, потом рассылаем метки.

видео четырьмя экранами выше
Juniper
RFC 4761
DVMRP
RFC 6624
LDP-Signalling + BGP Auto-Discovery