Давайте составим некий алгоритм действий, который нужен нам для того чтобы выявить проблему наиболее быстро:

1. Не стартует LDP сессия, что нужно делать?

- show mpls lap discovery — не отображает необходимого соседа.

Мы предполагаем что на соседе не включен MPLS, на соседнем роутере необходимо посмотреть на каких интерфейсах запущен процесс mpls:

show mpls lap interface

-  Для установления LDP сессии необходимо чтобы с обоих сторон был указан что используется протокол LDP.

Если на одной стороне указан LDP, а на другой TDP то сессия установлена не будет.

Тут нам опять поможет команда show mpls lap interface, там видно, какой протокол на каком интерфейсе запущен.

- если все выше проделано и все равно нет соседства mpls, необходимо проверить, а не дропаются ли пакеты фильтрами.

Напомню, что порт необхоимые 646.

- Соседство обнаруживается, но соседство по прежнему не устанавливается. Необходимо проверить достижимы ли router-id (лупбаки), иными словами необходимо проверить настройку протокола IGP (например OSPF).

Здесь немного поясню, чем отличается show mpls ldp discovery от show mols ldp neighbor.

discovery это некий аналог cdp протокола, но в MPLS, тоесть если роутеры увидят друг друга по hello пакетам, то можно сказать что discovery заработает и роутеры увидят друг друга.

В то время как neighbors это уже установленная TCP сессия.

2. Сессия установлена, но метки не выделяются. Может быть две причины:

- выключен cef, нужно его включить. Напомню, нужно задать глобально ip cef (по умолчанию включен)

- вы указывали диапазон меток, и этот диапазон был исчерпан.

3. Не распространяются метки. В LIB мы их видим (show mpls ldp bindings), но они не распространяются соседям.

Используется фильтр: mpls ldp advertise-labels [for prefix-access-list] [to peer-access-list]

4. Не работает MPLS, после того как интерфейс упал. Всспоминаем, что у нас пиринги должны быть по лупбакам и это нужно говорить MPLS с помощью:

mpls ldp router-id lo0

5. Не ходят большие пакеты.

Так как MPLS у нас вставляет метку в пакет, значит и пакет у нас увеличивается, значит необходимо увеличить MTU, делается это на интерфейсах следующими командами:

mtu 1512

ip mtu 1512

mpls mtu 1512 (в 7200 : mpls mtu overrite 1512)

Отпуск закончился, праздники прошли, теперь можно продолжить изучение сетевых технологиях, мы остановились с Вами на MPLS, немного рассмотрели теорию, теперь займемся немного практикой, а именно базовой настройкой MPLS, а именно в режиме Frame-Mode.

Вот топология, с которой мы будем с Вами работать в этой заметке и всех последующих:

Для начала мы настроим базовый MPLS между всему P устройствами:

На всех роутерах прописываем такую конфигурацию:

conf t
mpls ip
mpls label protocol ldp
mpls ldp router-id loopback0
mpls ldp advertise-labels
!
int s1/0
mpls ip
exit
int s1/1
mpls ip
exit

Для удобной и быстрой настройки не забываем пользоваться блокнотом, как мы делали это в BGP.

Так же необходимо включить mpls на интерфейсах f0/0 на роутерах p9-p10 и на интерфейсах E3/0 на роутерах PE4 и PE6.

Теперь давайте рассмотрим команды.

Первое, что необходимо сделать, это включить MPLS глобально. Это делается с помощью mpls ip в режиме глобальной конфигурации.

Далее, необходимо выбрать протокол, в нашем случае мы используем протокол LDP, (cisco протокол TDP уже устарел, сейчас используется везде LDP).

Далее, помним правило, что пиринг лучше всего строить по лупбакам, это так же распространяется и на MPLS, поэтому мы должны сказать роутеру, что router-id у нас будет равен IP адресу лупбеку - mpls ldp router-id loopback0.

mpls ldp advertise-labels — говорит роутеру, что все интерфейсы у нас отсылают mpls метки.

И далее на каждом интерфейсе мы активируем mpls дополнительно.

Вот собственно и вся базовая конфигурация.

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

Например, посмотрим на каких интерфейсах у нас включен mpls с помощью команды show mpls interface:

Видим задействованные интерфейсы, протокол, используется ли BGP и так далее.

Можно более детально посмотреть информацию о каком-то интерфейсе:

Можно просмотреть параметры LDP :

Далее давайте посмотрим какие же у нас есть соседи mpls:

Из вывода видим, что у нас есть соседство с тремя роутерами, router-id которые равны 10.10.10.10, 8.8.8.8, 4.4.4.4. И соответсвенно интерфейсы, через которые доступны эти роутеры.

Можно вывести информацию более подробно, если это необходимо:

Есть практически аналог этого вывода:

Можно сделать детально для какого-то определенного соседа, в общем как всегда, не буду этого здесь писать, все понятно

Ну чтож, теперь давайте посмотрим сами метки.

Для начала как посмотреть базу LIB? (Label Information Base)

PE-6#show mpls ldp bindings
lib entry: 2.2.2.2/32, rev 6
local binding: label: 18
remote binding: lsr: 10.10.10.10:0, label: 16
remote binding: lsr: 8.8.8.8:0, label: 16
remote binding: lsr: 4.4.4.4:0, label: 16
lib entry: 4.4.4.4/32, rev 4
local binding: label: 17
remote binding: lsr: 10.10.10.10:0, label: 17
remote binding: lsr: 8.8.8.8:0, label: 17
remote binding: lsr: 4.4.4.4:0, label: imp-null
lib entry: 6.6.6.6/32, rev 26
local binding: label: imp-null
remote binding: lsr: 10.10.10.10:0, label: 24
remote binding: lsr: 8.8.8.8:0, label: 18
remote binding: lsr: 4.4.4.4:0, label: 17
lib entry: 8.8.8.8/32, rev 18
local binding: label: 24
remote binding: lsr: 10.10.10.10:0, label: 25
remote binding: lsr: 8.8.8.8:0, label: imp-null
remote binding: lsr: 4.4.4.4:0, label: 18
lib entry: 9.9.9.9/32, rev 20
local binding: label: 25
remote binding: lsr: 10.10.10.10:0, label: 26
remote binding: lsr: 8.8.8.8:0, label: 19
remote binding: lsr: 4.4.4.4:0, label: 19
lib entry: 10.10.10.10/32, rev 22
local binding: label: 26
remote binding: lsr: 10.10.10.10:0, label: imp-null
remote binding: lsr: 8.8.8.8:0, label: 20
remote binding: lsr: 4.4.4.4:0, label: 20
lib entry: 172.16.34.0/24, rev 34
remote binding: lsr: 4.4.4.4:0, label: imp-null
lib entry: 172.16.43.0/24, rev 35
remote binding: lsr: 4.4.4.4:0, label: imp-null
lib entry: 172.16.56.0/24, rev 28
local binding: label: imp-null
lib entry: 172.16.78.0/24, rev 33
remote binding: lsr: 8.8.8.8:0, label: imp-null
lib entry: 191.66.24.0/24, rev 2
local binding: label: 16
remote binding: lsr: 10.10.10.10:0, label: 23
remote binding: lsr: 8.8.8.8:0, label: 21
remote binding: lsr: 4.4.4.4:0, label: imp-null
lib entry: 191.66.29.0/24, rev 14
local binding: label: 22
remote binding: lsr: 10.10.10.10:0, label: 22
remote binding: lsr: 8.8.8.8:0, label: 22
remote binding: lsr: 4.4.4.4:0, label: 21
lib entry: 191.66.46.0/24, rev 30
local binding: label: imp-null
remote binding: lsr: 10.10.10.10:0, label: 21
remote binding: lsr: 8.8.8.8:0, label: 23
remote binding: lsr: 4.4.4.4:0, label: imp-null
lib entry: 191.66.49.0/24, rev 16
local binding: label: 23
remote binding: lsr: 10.10.10.10:0, label: 20
remote binding: lsr: 8.8.8.8:0, label: 24
remote binding: lsr: 4.4.4.4:0, label: imp-null
lib entry: 191.66.60.0/24, rev 24
local binding: label: imp-null
remote binding: lsr: 10.10.10.10:0, label: imp-null
remote binding: lsr: 8.8.8.8:0, label: 25
remote binding: lsr: 4.4.4.4:0, label: 22
lib entry: 191.66.68.0/24, rev 32
local binding: label: imp-null
remote binding: lsr: 10.10.10.10:0, label: 19
remote binding: lsr: 8.8.8.8:0, label: imp-null
remote binding: lsr: 4.4.4.4:0, label: 23
lib entry: 191.66.80.0/24, rev 12
local binding: label: 21
remote binding: lsr: 10.10.10.10:0, label: imp-null
remote binding: lsr: 8.8.8.8:0, label: imp-null
remote binding: lsr: 4.4.4.4:0, label: 24
lib entry: 191.66.90.0/24, rev 8
local binding: label: 19
remote binding: lsr: 10.10.10.10:0, label: imp-null
remote binding: lsr: 8.8.8.8:0, label: 26
remote binding: lsr: 4.4.4.4:0, label: 25
lib entry: 191.66.91.0/24, rev 10
local binding: label: 20
remote binding: lsr: 10.10.10.10:0, label: 18
remote binding: lsr: 8.8.8.8:0, label: 27
remote binding: lsr: 4.4.4.4:0, label: 26
PE-6#

И базу данных LFIB:

Давайте рассмотрим на примере, например нас интересует сетка 9-ок, начнем с того места, где эта сеть создана:

Видим что меток нет, т.к. тут она пораждается, давайте посмотрим на другом роутере.

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

Посмотрим еще на PE8:

Видим что локальная метка 19, а отправлять будем на 26-ую.

Можно просмотреть traceroute и увидеть какие LSR мы проходим:

Traceroute это и есть LSP.

Так как у нас работает CEF, а он работает для MPLS всегда, мы можем посмотреть что там в нем происходит:

Здесь мы видим, что локальная метка 19, метка следующего хопа — 26, собственно так будем коммутироваться пакет.

Все это происходит с помощью протокола LDP — Label Distribution Protocol.

Итак, сперва наперво на все интерфейсы MPLS отправляется Hello сообщение (каждые 5 секунд). Hello сообщение отправляется по транспортному протоколу UDP на порт 646.

Далее, сосед получивший такое сообщение пытается установить сессию. Сессия устанавливается по протоколу TCP, а порт остается тем же — 646. TDP протокол использует порт 711.

Hello сообщение отправляется всем роутерам по мультикасту: 224.0.0.2.

LPD Identifier состоит из 6 байт, 4 байта определяют router-id, а 2 последние определяют область меток.

Что такое область меток? (Label Space)

Выделяют два вида области меток:

• per-interface label space — это когда метки генерируются в зависимости от интерфейса, то есть для каждого интерфейса своя метка.
• per-platform label space — когда метка генерируется одна на весь маршрутизатор, то есть для каждого интерфейса одинаковая метка.

per-interface может использоваться например когда у нас есть линки ATM (помните, там mpls строится исходя из vpi/vci, а они на интерфейсах разные, соответсвенно разные MPLS метки).

Давайте теперь посмотрим, как согласовываются эти lable space:

LSR устанавливает одно LDP соединение на каждое Label Space. Таким образом для per-platform требуется только одно LDP соединение, даже если есть несколько параллельных линков между LSR.

Например, LPD ID: 10.1.0.1:0, последний «0″ говорит о том, что используется Per-Platform, «1″ укажет, что используется Per-Interface.

Соседи бывают:

• Directly connected — тоесть когда сосед имеет связь с роутером по L2.
• Non-directly connected — когда между соседями нет L2 соединения. Проводим аналогию с BGP, когда мы использовали multihop.

Для того что бы non-directly connected у нас работало, необходимо указать это через команду: mpls ldp neighpor {vrf} {ip} 

То есть, мы указали, что необходимо пробросить LDP сессию на указанный IP или VRF.

Где это может понадобиться?

• MPLS Fast Reroute — это фича, которая создает бекапный LSP и в случае отказа первого, бекапный сразу начинает работать.
• MPLS Non Stop Forwarding (NSF) — в случае отказа Control Plane, форвардинг продолжается.
• MPLS LDP Session Protection — это часть Fast Reroute.
• Any Transport over MPLS (AToM)

Hello по умолчанию, ходят между разными соседями по разному, например между directly соседями по умолчанию ходит каждые 5 секунд, и holdtime = 15, между non-directly — 60 секунд, holdtime = 180.

Рекомендуется все эти линки строить по Loopback, и не только MPLS, но и BGP, OSPF и так далее.

Да, и еще очень важный момент, TCP сессию начинает тот роутер, у которого больше LDP ID.

После того, как сессия установлена, посылаются hello сообщения и  keepalive, по умолчанию keepalive = 60 секунд, если через 180 секунд не будет принят keepalive, то соседство будет разорвано.

Для того, чтобы изменить таймеры, можно воспользоваться командой: mpls ldp discovery {hello | targered-hello} {holdtime | interval} XX seconds

Исходя из этого можно сказать, что hello сообщениями обмениваются per-link, а keepalive обмениваются только per-neighbor.

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

Представим, что за роутером D есть сеть X. Нам нужно от этой сетки обратиться к сетке роутера A. Как это делается ?

Роутер C у нас является edge LSR (не все интерфейсы mpls), этот роутер создает локальную метку с номером 47 для сети X, после чего эту метку по протоколу LDP распространяет своим соседям: B и E.

B создает локальную метку 25, а E — 47 и так же все это распространяется своим соседям.

Роутер А получает метку 25 от соседа B, и формирует локальную метку 12 для этого маршрута, но так как это пограничный роутер, то эта метка отбрасывается, и дальше все идет по обычному IP forwarding.

LFIB:

После того как таблица LIB заполнена, выбираются лучшие записи и помещаются в LFIB.

Лучшие маршруты определяются на основе IGP протокола.

FIB:

На edge роутерах, к маршруту мы должны привязать метку:

Далее рассмотрим сходимость MPLS.

Графически это можно представить так.

Теперь давайте чуть чуть более подробно посмотрим каждое приложение.

1. Основной MPLS, построенный на unicast ip routing. Здесь FEC является сеть назначения. Ради этого приложения внедрять MPLS не целесообразно. Получается MPLS ради MPLS’а. Да, это немного убыстрит сеть, но это ускорение будет не существенным, и сервисов новых не будет.
2. Multicast Ip Routing, в данном приложении FEC будет равен пакетам с определенным Group Address, эту технологию тоже не совсем целесообразно применять, так как IP Multicast так же хорошо справляется с этими вещами.
3. MPLS Traffic Engeneering, а вот здесь уже интересно. Здесь FEC тоже является сеткой назначения, но тут прибавляется еще такой параметр как обеспечение ресурсами. Например нам нужно построить путь не просто как стандартно по кратчайшему от источника до назначения, а необходимо сделать этот канал скажем в 8мегабит, и исходя из этого будет строиться маршрут. Здесь протоколами IGP могут выступать только OSPF или IS-IS.
4. QOS MPLS — Здесь FEC зависит от сети назначения а так же класса сервиса (COS). То есть получается расширенный Unicast IP Routing засчет QOS.
5. MPLS L3 VPN — высоко масштабируемое приложение, которое поддерживает такие IP сервисы как: Мультикаст, QOS, Телефония. Здесь FEC’ом является VPN дескриптор. Технология достаточно большая, мы ее обязательно будем рассматривать подробно в дальнейшем.
6. MPLS L2 VPN или Any Transport over MPLS — L2 VPN со всеми ее недостатками и достатками

Сейчас мы с Вами рассмотрим что же представляют из себя метки MPLS.

Ну во первых метка занимает фиксированное число байт, 4 байта.

• 20 бит выделено под саму метку (просто число)
• 3 бита выделено под QOS (IP Prec)
• 1 бит для групповых меток (узнаем чуть позже)
• и 8 бит — TTL (который может быть свой, а может браться из IP)

Кммутация MPLS может быть двумя способами:

1. Frame-Mode — наша метка инкапсулируется в фрейм. Вставка метки происходит между заголовком Layer 2 и Layer 3.
2. Cell-mode — применяется в сетях ATM, тут не используется 4 байтовая метка, а вместо них используются vpi/vci

Мы уже знаем, что маршрутизация происходит по Layer 3 адресам, а затем идет коммутация пакета (переписывание L2, и так далее).

Так вот, MPLS работает не по IP адресам, а по специально созданным меткам. То есть для каждого маршрута, MPLS создает специальную метку и тем самым четко определяет что это за маршрут, нам не нужно искать next hop, интерфейс и так далее, нам нужна только метка и больше ничего.

Тем самым у нас увеличивается скорость обработки данных, но как показывает практика скорость эта вырастает не в разы, как обещалось, а значительно меньше, так как все по прежнему работает через CEF, а CEF и так очень быстр

То есть, если вы хотите внедрить MPLS только для того чтобы повысить производительность, то этого делать не стоит.

Таким образом, можно выделить, то на чем основывается MPLS:

• На IP роутинге и CEF
• Форвардинг происходит по специально созданным  меткам.
• MPLS метка обычно показывает нам сеть назначения. Метка так же может нести в себе такой параметр как например QOS
• MPLS основывается на IGP протоколах.

Из прошлой заметке мы уяснили что роутер состоит из Control Plane и Data Plane, которые в свою очередь состоят из Routing Protocol, RIB и FIB, Adj-table.

С использованием MPLS все это у нас немного расширяется.

В Control Plane добавляется протокол создания и обмена метками Label Exchange Protocol (LDP или TDP), далее все это помещается в базу Label Information Base (LIB).

Далее все это передается в Data Plane, а именно создается кеш, которые называется Label Forwarding Table (LFIB).

И на основании метки происходит коммутация пакета.

Все очень похоже на ip forwarding и ip routing, только делается еще такая надстройка ввиде меток.

Если представить графически, как в прошлой статье, то получится нечто такое:

Давайте чуть подробнее рассмотрим процесс, который происходит в MPLS.

Control Plane на основе протокола маршрутизации создает таблицу RIB, далее, на основе этой таблицы работает протокол Label Exchange Protocol, который создает метки для маршруток пришедших по IGP и обменивается этими метками с соседними маршрутизаторами.

Далее формируется Label Information Base, которая состоит из Метка — Сетка. Метки разносятся по соседям используя один из протоколов LDP (стандартизированный протокол), TDP (Cisco протокол, устаревший), либо через BGP.

Далее в Data Plane создается LFIB, где содержится метка и интерфейс через который выпускать этот пакет.

Data Plane не зависит от того, какие протоколы распространения меток используется. В Data Plane происходит очень простой процесс посдтавления из кеша нужной записи по метке.

В сети MPLS различают два вида роутеров:

- Label Switch Router (LSR) — на всех интерфейсах включен MPLS.

Основной задачей такого роутера является обмен метками между другими LSR роутерами и передача пакетов с метками.

- edge LSR — не на всех интерфейсах включен MPLS. Так же этот роутер можно назвать как граничный роутер MPLS домена. Такой роутер передает пакеты с метками в MPLS домен, и IP пакеты вне MPLS домена.

Так же есть еще такое понятие как LSP — Label-Switched Path — это совокупонсть LSR, которые пакет прошел от начала до конца. Некий такой аналог AS-Path, который мы помним из BGP.

Для каждого класса трафика создается свой LSP. Такой класс трафика в MPLS называют Forwarding Equivalence Class или FEC.

FEC — это группа пакетов, которые передаются по одинаковому пути, имеют одинаковый LSP, одинаковый destination адрес. Так же FEC может создаваться и по другим критериям.

Графикчески все это можно отобразить так:

На этой картинке изображны и различные приложения (FEC) и LSR и eLSR, и что такое LSP. Думаю теперь стало все более понятно.

В маршрутизаторе различают два разных процесса, это routing (маршрутизация) и forwarding (коммутация пакетов).

В архитектуре маршрутизатора выделяют две плоскости:

1. Control Plane (routing) - получает все маршруты от всех протоколов маршрутизации и далее по специальным алгоритмам лучшие маршруты попадают в таблицу RIB (Route Information Base). Это выполняется на процессоре роутера.
2. Data Plane (Forwarding) — из RIB информация попадает в кеш (Data Plane), на cisco это реализовано с помощью CEF (Cisco Express Forwarding).

Data Plane обрабатывается с помощью forwarding engine. В зависимости от платформы, этот forwarding engine может быть централизованным (объединенным с route process) или распределенным (разносятся по процессорам на  интерфейсах).

Как происходит передача пакета?

Сначала происходить этап маршрутизации (routing), на этом этапе находится next hop, а так же интерфейс через который нужно передать пакет. Это все делается в Control Plane.

Определение пути коммутации и формирование Layer 2. Этим занимается Data Plane.

Теперь давайте рассмотрим режимы коммутации:

1. Process Switching (процессорная коммутация) — это режим, при котором каждый пакет обрабатывается центральным процессором, тем самым очень сильно нагружая его.

Этот режим на данный момент не используется и по умолчанию выключен. Если вы найдете в конфигурационном файле команды: no ip route-cache и no ip cef , то это скажет нам о том, что режим коммутации Process Switching.

2. Fast Switching — идея этого режима заключается в использовании cache таблиц. Первый пакет потока идет через route process, затем создается кеш и все последующие пакеты этого потока идут путем подставления этого кеша в пакет (вместо того чтоб делать Layer 2 rewrite для каждого пакета потока).

Основной проблемой здесь является то, что каждый новый поток в начале будет «тормозиться», так как первый пакет у нас по прежнему идет через Process Switching.

К слову сказать, если в сети используется Policy Base Routing, то все пакеты идут в режиме Process Switching и тем самым сильно нагружают маршрутизатор. Для того что бы этого избежать, необходимо в route-map для этого PBR прописать: ip route-cache policy.

3. Cisco Express Forwarding — этот режим создан для того чтобы избавиться от недостатков с первым пакетом, как у Fast Switching, засчет того, что роутер сразу создает кеш для каждого маршрута, еще до начала того когда начался поток. И при приходе первого пакета маршрутизатор «достает» сразу заготовку и подставляет ее, минуя Route Process.

В CEF есть две таблицы:

- таблица соседей (adj-table) в ней содержатся готовые заголовки второго уровня.

- FIB (Forwarding Information Base) — таблица в которой указывается то, как происходит коммутация пакета. Эту таблицу можно посмотреть show ip cef.

CEF по умолчанию включен (ip cef).

Если у нас платформа выше 7500, там используется распределенная архитектура, для того чтобы скопировать этот CEF на каждый интерфейс (либо line card), необходимо дать команду ip cef distrebuted.

Это существенно  ускоряет процесс коммутации.

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

- RIB

- PBR (Policy Base Routing)

- TE/FRR

Первые два нам знакомы, последнее мы рассмотрим еще, но позже.

Это знание нам очень хорошо поможет, когда мы будем делать траблшутинг.

Смотрим show ip route, определяем что трафик должен идти через один роутер, смотрим traceroute видим совсем другую картину.

Здесь нам и нужно смотреть то, как коммутируется пакет, сделать это можно так: sh ip cef exact-route {Source IP} {Destination IP}

Так мы сможем четко посмотреть как пакет будет скоммутирован.

Буквально на днях начнем изучение MPLS Base, и все станет в свое русло.

Если  peer-group полностью описывало всю политику обновлений и сессий, то template разделяется на две группы, это параметры сессии и параметры обновлений, peer session и peer policy соответственно.

Давайте для наглядности рассмотрим пример:

router bgp 1

template peer-policy POLICY

route-reflector-client

weight 300

exit peer-policy

!

template peer-session iBGP

remote as 1

update-source lo0

exit peer-session

!

neighbor 2.2.2.2 inherit peer-session iBGP

neighbor 2.2.2.2 inherit peer-policy POLICY

Таким образом, мы сначала описали два шаблона, один сессий, другой политик, и потом привязали их с помощью inherit к соседям.

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

При описании peer-session или peer-policy можно делать вложенные шаблоны, таким образом:

template peer-session iBGP

remote as 1

update-source lo0

inherit peer-session 1BGP

exit peer-session

Более подробно о возможностях bgp template можно почитать на сайте Cisco. 

Сейчас мы поговорим о том, как реализовывается QOS в сетях BGP.

Community,  которые мы не так давно с Вами изучили очень тесно взаимодействует с QOS под BGP.

Расскажу о смысле этой технологии, на примере рассматривать не будем и в конце дам ссылку на PDF где более подробно описано.

Итак, у нас есть премиум клиент, трафик от которого мы должны каким-то образом маркировать, будь то IP Prec, или QOS Group, не суть важно.

Провадер на роутере, который смотрит в сторону это клиента, должен сделать community на эту сеть, например 12:17, далее необходимо эту Community распространить у себя по сети (community ведь не передается по умолчанию соседям).

На роутерах провайдера, которые обеспечивают выход из своей AS необходимо включить CEF маркирование, далется это с помощью table-map, пример такой:

router bgp 1

table-map Premium

!

route-map Premium permit 10

math community 1

set precedence flash

!

route-map Premium 20

set precedence 0

!

ip community-list 1 permit 12:17

 

Таким образом сеть помеченная community 12:17 будет промаркирована IP Prec flash.

Теперь на интерфейсах необходимо указать bgp политику маркирования.

На интерфесе смотрящих из сеть провайдера к другим AS мы указываем

bgp-policy destination ip-prec-map

На интерфейсе, который смотрит внутрь провайдера:

bgp-policy source ip-prec-map

Вот собственно и вся настройка.

Более подробно почерпнуть информацию можно здесь.